Semantic HMC for Big Data Analysis

Semantic HMC for Big Data Analysis - Revenir à l'accueil

Semantic HMC for Big Data Analysis

Thomas Hassan 1 Rafael Peixoto 2 Christophe Cruz 1 Aurlie Bertaux 1 Nuno Silva 2 
 
Abstract : Analyzing Big Data can help corporations to im-prove their efficiency. In this work we present a new vision to derive Value from Big Data using a Semantic Hierarchical Multi-label Classification called Semantic HMC based in a non-supervised Ontology learning process. We also proposea Semantic HMC process, using scalable Machine-Learning techniques and Rule-based reasoning.
Keywords : Index Terms—classification multi-classify Big-Data ontology semantic technologies machine learning
Type de document : 
Poster
2014 IEEE International Conference on Big Data, Oct 2014, Washington, United States.<http://cci.drexel.edu/bigdata/bigdata2014/new.htm>
Domaine :
Informatique / Web
Informatique / Traitement du texte et du document
Informatique / Calcul parallèle, distribué et partagé

 

FICHIERS

poster-SHMC.pdf
Fichiers produits par l'(les) auteur(s)

Source : https://hal.archives-ouvertes.fr/hal-01089741v1

 

 

Autres documents sur la Big Data :

[TXT]

 Big-DATA-effet-de-mo..> 20-Dec-2014 17:28  8.2M  

[TXT]

 Big-Data-Alchemy-Cap..> 20-Dec-2014 17:57  8.1M  

[TXT]

 Big-Data-Analyse-des..> 20-Dec-2014 17:28  8.2M  

[TXT]

 Big-Data-At-the-Big-..> 22-Dec-2014 07:47  1.5M  

[TXT]

 Big-Data-Big-Data-Fo..> 21-Dec-2014 11:00  1.4M  

[TXT]

 Big-Data-Charte-ethi..> 21-Dec-2014 10:38  4.7M  

[TXT]

 Big-Data-Comportemen..> 21-Dec-2014 10:35  1.4M  

[TXT]

 Big-Data-Comportemen..> 21-Dec-2014 10:38  4.6M  

[TXT]

 Big-Data-Donnees-num..> 22-Dec-2014 07:47  1.5M  

[TXT]

 Big-Data-French-Japa..> 21-Dec-2014 10:35  1.4M  

[TXT]

 Big-Data-Institut-Lo..> 20-Dec-2014 18:00  8.2M  

[TXT]

 Big-Data-Introductio..> 20-Dec-2014 17:53  4.1M  

[TXT]

 Big-Data-L-ecosystem..> 21-Dec-2014 10:36  1.3M  

[TXT]

 Big-Data-La-Chaire-A..> 20-Dec-2014 17:54  4.0M  

[TXT]

 Big-Data-Le-big-data..> 20-Dec-2014 18:09  4.5M  

[TXT]

 Big-Data-Le-defi-MAS..> 22-Dec-2014 06:57  1.5M  

[TXT]

 Big-Data-Les-cahiers..> 20-Dec-2014 18:00  8.3M  

[TXT]

 Big-Data-MASTODONS-U..> 21-Dec-2014 10:37  2.3M  

[TXT]

 Big-Data-Marketing-P..> 22-Dec-2014 07:46  1.5M  

[TXT]

 Big-Data-Mastere-Spe..> 20-Dec-2014 17:29  8.1M  

[TXT]

 Big-Data-Synthese-du..> 20-Dec-2014 17:53  4.1M  

[TXT]

 Big-Data-TACKLING-TH..> 20-Dec-2014 17:54  4.0M  

[TXT]

 Big-Data-Telecharger..> 20-Dec-2014 18:09  4.4M  

[TXT]

 Big-Data-Un-etat-des..> 20-Dec-2014 18:07  4.5M  

[TXT]

 Big-Data-Une-approch..> 21-Dec-2014 10:37  2.3M  

[TXT]

 Big-Data-Une-approch..> 21-Dec-2014 11:00  1.4M  

[TXT]

 Big-Data-et-Graphes-..> 21-Dec-2014 10:36  2.3M  

[TXT]

 Big-Data-la-deferlan..> 22-Dec-2014 07:47  1.5M  

[TXT]

 Big-Data-la-vision-d..> 22-Dec-2014 07:46  1.5M  

[TXT]

 Big-Data-un-Master-c..> 20-Dec-2014 18:07  4.5M  

[TXT]

 White-paper-Big-Data..> 20-Dec-2014 17:57  8.1M 
Semantic HMC for Big Data Analysis Thomas Hassan, Rafael Peixoto, Christophe Cruz, Aurlie Bertaux, Nuno Silva To cite this version: Thomas Hassan, Rafael Peixoto, Christophe Cruz, Aurlie Bertaux, Nuno Silva. Semantic HMC for Big Data Analysis. 2014 IEEE International Conference on Big Data, Oct 2014, Washington, United States. . HAL Id: hal-01089741 https://hal.archives-ouvertes.fr/hal-01089741 Submitted on 2 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.Semantic HMC for Big Data Analysis Thomas Hassan Universit de Bourgogne Dijon, France thomas.hassan@checksem.fr Rafael Peixoto Polytechnic of Porto Porto, Portugal rafpp@isep.ipp.pt Christophe Cruz Universit de Bourgogne Dijon, France christophe.cruz@u-bourgogne.fr Aurlie Bertaux Universit de Bourgogne Dijon, France aurelie.bertaux@iut-dijon.u-bourgogne.fr Nuno Silva Polytechnic of Porto Porto, Portugal nps@isep.ipp.pt Abstract—Analyzing Big Data can help corporations to improve their efficiency. In this work we present a new vision to derive Value from Big Data using a Semantic Hierarchical Multi-label Classification called Semantic HMC based in a nonsupervised Ontology learning process. We also proposea Semantic HMC process, using scalable Machine-Learning techniques and Rule-based reasoning. Index Terms—classification; multi-classify; Big-Data; ontology; semantic technologies; machine learning I. INTRODUCTION Nowadays, discovering knowledge and insights over web data is a major task for most corporations to increase their competitiveness. Determining the value of information relative to a particular customer is a complex task addressed by the business intelligence/data-mining field [1]. In the context of Big Data, this task is even more challenging, due to its characteristics. An increasing number of Vs has been used to characterize Big Data [2], [3]: Volume, Velocity, Variety and Value. Volume concerns the large amount of data that is generated and stored through the years by social media, sensor data, etc[2]. Velocity concerns both to the production and the process to meet a demand because Big Data is not only a huge volume of data but it must be processed quickly. Variety relates to the various types of data composing the Big Data. These types include semi-structured and unstructured data representing 90% of his content [4] such as audio, video, webpage, and text, as well as traditional structured data, etc. Value measures how valuable the information to a Big Data consumer is. Value is the most important feature of Big Data and his raison dłtre because if data dont have value then is useless. An IDC report [5] proposes the value extraction from very large volumes of a wide variety of data, by enabling the high-velocity capture, discovery, and/or analysis. Sheth [6] proposes deriving Value via harnessing the challenges posed by Volume, Variety, and Velocity using semantic techniques and technologies. This requires organized ways to harness and overcome the four V-challenges by using metadata and employ semantics and intelligent processing. Our aim is to extract Value from Big Data by harnessing a huge Volume and Variety of data that change constantly (Velocity) by using a novel unsupervised ontology learning process based on HMC called Semantic HMC. Hierarchical Multi-Label Classification (HMC) is the combination of Multi-Label classification and Hierarchical classification [7]. In HMC, the items can be assigned to different hierarchical paths and simultaneously may belong to different class labels in the same hierarchical level [7]. The ontology [8] plays a key role in defining terms and meanings used to represent the knowledge, reducing the gap between the users and the HMC process. This paper does not aim to improve the state of the art in multi-classification, nor the automatic hierarchy construction. Instead it proposes a scalable process to semantically learn the ontology by adopting scalable machine learning processes and Rule-based reasoning [9] to classify the data items and therefore extract value from Big Data. The contributions of this work are twofold: • Scalable ontology learning process based on HMC (Semantic HMC). • Big Data Analysis using a Semantic HMC. The rest of the paper covers three sections. The second section describes how to use the Semantic HMC to extract value from Big Data. The third section describes the Semantic HMC process proposal. Finally, the last section draws conclusions and suggests further research. II. USING SEMANTIC HMC TO DERIVE VALUE IN BIG DATA CONTEXT Our approach is to exploit value from very large volumes of data that are in constant generation using a Semantic HMC approach. The Semantic HMC process learns the Tbox (Taxonomy and Rules) part of the ontology from the huge Volume and Variety of initial data. Once this learning phase is finished, the classification system incrementally learns the Tbox from the new incoming items (Abox) to provide and respond to the Velocity (and the others V) dimension(s). The result of this Semantic HMC process is a rich ontology with the items (instances) classified according to the learned concept hierarchy (i.e. the taxonomy of the ontology). Corporations recurrently use concept hierarchies as taxonomies to represent their valuable information [10]. Our vision is to use the concept hierarchies from corporations to validate the valueBig Data Semantic HMC Ontology Corporation Taxonomies Similarity Fig. 1. Value extraction for corporations of the learned ontology for a specific corporation (Fig. 1). Higher similarity between the concept hierarchy of the learned ontology and the concept hierarchy used by a corporation suggest better alignment between the HMC results and the corporations knowledge and goals. Consequently, data items classified as valuable concepts ultimately present better value to the corporation than those not matching the corporations concepts. III. SEMANTIC HMC PROCESS Our Semantic HMC process is generic for a large Variety of unstructured data items (e.g. text, images) and scalable for a large Volume of data. The process is unsupervised such that no previously labeled/classified examples or rules to relate the data items with the labels exist. The label (i.e. concepts) hierarchy and the rules are automatically learned from the data through scalable Machine Learning techniques. To infer the most specific concepts for each data item and all subsuming concepts we use rule-based reasoning that exhaustively applies a set of rules to a set of triples to infer conclusions [9], i.e. the items classifications. This Rule-based reasoning approach allows the parallelization and distribution of work by large clusters of inexpensive machines through Big Data technologies as Map-reduce [11]. Web Scale Reasoners [12] currently uses Rule-Based reasoning to reach high scalability by load parallelization and distribution, thus addressing the Velocity and Volume dimensions of Big Data. This proposed process consists of 5 individually scalable steps (Fig. 2) matching the requirements of Big Data processing: • Indexation parses and creates an index of data items. • Vectorization calculates term-frequency vectors of the indexed items. • Hierarchization creates a concept hierarchy based on term frequency. • Resolution creates the reasoning rules to relate data items with the hierarchy concepts based on term frequency. • Realization first populates the ontology with items and then for each item determines the most specific hierarchy concept and all his subsuming concepts. 1.Indexation Ontology 2.Vectorization Itens Hierarchy 3.Hierarchization Rules Classified Items 4.Resolution 5.Realization Unclassified Items Indexed Collection Hierarchy Concepts Term-Frequency vectors Fig. 2. Semantic HMC Process A. Indexation The indexation step parses and index data items. As one of our main focus points is the scalability of the architecture, the indexation is a mandatory step. Each item type has its specific parser to efficiently retrieve useful information for the other steps reducing the Limited Context Analysis problem. The Limited Content Analysis problem [13][14] is defined by the difficulty in extracting reliable automated information from various content (e.g. text, images, sound, etc.), which can greatly reduce the quality of the classifications. By reducing the Limited Content Analysis we improve the Semantic HMC capability to handle more Variety of data. B. Vectorization The vectorization step vectorizes the terms in the indexed items by calculating two types of term frequency vectors : • Term frequency in each item using the frequency of a term in an item measured by TF-IDF. TF-IDF uses the frequency of a term in an item (TF) and the inverse number of items in which the term appears (IDF) [15]. • Term frequency in all items using the appearing frequency of a term in all documents [15]. The following steps use the term vectors calculated in this step to learn the concepts Hierarchy and the Rules. C. Hierarchization The hierarchization step will select relevant terms as relevant concepts and also will generate the broader-narrower relations between these concepts. To select the concepts in the hierarchy, a quality measure must be used. There are several methods for creating hierarchical relations between concepts including [16], [17]: • Hierarchical clustering that starts with one cluster and progressively merges clusters that are closest.• Subsumption methods that construct the concept broadernarrower relations based on the co-occurrence of concepts. Any of these methods can be used to create the hierarchical relations. The advantages and drawbacks of each method is deeply studied in [16]. D. Resolution The resolution process will create the ontology rules used to relate the hierarchy concepts and the items using the term-frequency vectors. The rules creation process will use thresholds as proposed in [18] to select the most relevant terms for each hierarchy concept that will be used in the rules. The main difference is that instead of translating the rules into logical constraints of an ontology captured in Description Logic, these rules will be translated into rules in the Semantic Web Rule Language (SWRL). The main interest in using SWRL rules is to reduce the reasoning effort, thus improving the scalability and performance of the system. We aim to use a huge amount of simple SWRL rules that will be applied to the ontology in order to classify items. E. Realization The realization phase will populate the learned concept hierarchy with data items. First the ontology is populated with new items to label in an assertion level (Abox). To do the classification/labeling of the items, the SWRL Rules generated in the Resolution step are used. Then a Rule-Based inference engine will use the SWRL rules and the hierarchy to infer the most specific concepts for each data item and all subsuming concepts. This leads to a multi-label classification of the documents based in a hierarchy of labels (Hierarchical Multi-label Classification). IV. CONCLUSION In this paper we present our vision to extract value from Big Data using a Semantic HMC process and propose a scalable five-step architecture to automatically classify unstructured items. We use machine learning to learn an ontology with SWRL rules to automatically classify items of Big Data. The Semantic HMC process prototype is under development and we expect to show the implementation and results in further work. Our current work consists in evaluating the resulting ontology, considering three different aspects: the process scalability (performance), the quality of the hierarchy, and the quality of the classification process (i.e. concept tagging of items). ACKNOWLEDGMENT This project is founded by the company Actualis SARL, the French agency ANRT and through the Portuguese COMPETE Program under the project AAL4ALL (QREN13852). REFERENCES [1] I. H. Witten and E. Frank, Data Mining: Practical machine learning tools and techniques. Morgan Kaufmann, 2005. [2] M. Chen, S. Mao, and Y. Liu, “Big Data: A Survey,” Mobile Networks and Applications, pp. 171–209, 2014. [3] P. Hitzler and K. Janowicz, “Linked data, big data, and the 4th paradigm,” Semantic Web, vol. 4, pp. 233–235, 2013. [4] A. Syed, K. Gillela, and C. Venugopal, “The Future Revolution on Big Data,” Future, vol. 2, pp. 2446–2451, 2013. [5] J. Gantz and D. Reinsel, “Extracting value from chaos,” IDC iview, pp. 1–12, 2011. [6] A. Sheth, “Transforming Big Data into Smart Data,” 2014 IEEE 30th International Conference on Data Engineering, pp. 2–2, 2014. [7] W. Bi and J. Kwok, “Multi-label classification on tree-and DAGstructured hierarchies,” Yeast, pp. 1–8, 2011. [8] R. Studer, V. R. Benjamins, and D. Fensel, “Knowledge engineering: Principles and methods,” Data & Knowledge Engineering, pp. 161–197, 1998. [9] J. Urbani, F. van Harmelen, S. Schlobach, and H. Bal, “QueryPIE: Backward Reasoning for OWL Horst over Very Large Knowledge Bases,” in ISWC’11. Springer-Verlag, 2011, pp. 730–745. [10] P. Lambe, Organising knowledge: taxonomies, knowledge and organisational effectiveness. Elsevier, 2014. [11] J. Dean and S. Ghemawat, “MapReduce : Simplified Data Processing on Large Clusters,” Communications of the ACM, pp. 1–13, 2008. [12] J. Urbani, “Three Laws Learned from Web-scale Reasoning,” in 2013 AAAI Fall Symposium Series, 2013. [13] P. Lops, M. de Gemmis, and G. Semeraro, “Content-based recommender systems: State of the art and trends,” in Recommender Systems Handbook. Springer, 2011, pp. 73–105. [14] J. Bobadilla, F. Ortega, A. Hernando, and A. Gutierrez, “Recommender ´ systems survey,” Knowledge-Based Systems, pp. 109–132, 2013. [15] G. Salton and C. Buckley, “Term-weighting approaches in automatic text retrieval,” Information processing & management, pp. 513—-523, 1988. [16] J. de Knijff, F. Frasincar, and F. Hogenboom, “Domain taxonomy learning from text: The subsumption method versus hierarchical clustering,” Data & Knowledge Engineering, pp. 54–69, 2013. [17] K. Meijer, F. Frasincar, and F. Hogenboom, “A Semantic Approach for Extracting Domain Taxonomies from Text,” Decision Support Systems, 2014. [18] D. Werner, N. Silva, and C. Cruz, “Using DL-Reasoner for Hierarchical Multilabel Classification applied to Economical e-News,” in Science and Information Conference, 2014, p. 8. Mod´elisation et impl´ementation de parall´elisme implicite pour les simulations scientifiques bas´ees sur des maillages H´el`ene Coullon To cite this version: H´el`ene Coullon. Mod´elisation et impl´ementation de parall´elisme implicite pour les simulations scientifiques bas´ees sur des maillages. Distributed, Parallel, and Cluster Computing. Universit´e d’Orl´eans, 2014. French. HAL Id: tel-01094327 https://hal.archives-ouvertes.fr/tel-01094327 Submitted on 15 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITÉ D’ORLÉANS ÉCOLE DOCTORALE MIPTIS MATHÉMATIQUES, INFORMATIQUE, PHYSIQUE THÉORIQUE ET INGÉNIEURIE DES SYSTÈMES Laboratoire d’Informatique Fondamentale d’Orléans THÈSE présentée par : Hélène COULLON soutenue le : 29 septembre 2014 pour obtenir le grade de : Docteur de l’université d’Orléans Discipline/ Spécialité : Informatique Modélisation et implémentation de parallélisme implicite pour les simulations scientifiques basées sur des maillages THÈSE dirigée par : Sébastien LIMET Professeur des Universités, Université d’Orléans RAPPORTEURS : David HILL Professeur des Universités, Université Blaise Pascal Christian PEREZ Directeur de Recherche INRIA, ENS Lyon JURY : Rob BISSELING Professeur, Université de Utrecht, Pays-Bas Jose-Maria FULLANA Professeur, Université Pierre et Marie Curie Frédéric LOULERGUE Professeur, Université d’Orléans (Président) Daniel PIERRE Directeur pôle scientifique et technique de Antea France (Convention CIFRE)À mes parents “Quand je serai grande, je voudrais inventer des choses”Remerciements Trois ans, une durée qui parait si longue et qui est pourtant si courte ! Voici déjà le moment de remercier toutes les personnes qui ont contribué directement ou indirectement à ce travail de thèse, par des financements, des collaborations, ou tout simplement par l’amitié, le soutien et plus encore. La thèse représente beaucoup de travail, d’implication, voir même d’acharnement, mais on oublie souvent de dire que la thèse c’est aussi une très grande part de chance, comme souvent dans la vie, et certains en ont plus que d’autres. J’ai eu la grande chance de rencontrer Sébastien Limet, mon directeur de thèse, et de travailler avec lui avant et pendant (et j’espère après) la thèse. Sébastien a su me diriger et m’aiguiller dans les bonnes directions, tout en me laissant toujours l’impression de diriger moi même mes recherches ce qui est un travail très subtil et très difficile à réaliser. Bien évidemment, ma thèse n’aurait pas été possible sans la société Géo-Hyd (Antea Groupe) qui l’a financée en convention CIFRE, et sans l’Agence Nationale de la Recherche et de la Technologie (ANRT) qui a subventionné Géo-Hyd pour cette thèse. J’ai eu, encore une fois, la chance d’avoir de bonnes conditions de recherche. Je remercie plus particulièrement Daniel Pierre pour avoir suivi ma thèse en entreprise et pour avoir su protéger mon temps de recherche. Je remercie également l’ensemble des salariés de Géo-Hyd pour leur sympathie, leurs encouragements ou leur amitié, et plus particulièrement mes amies Myriam et Leïla. J’ai passé 5 superbes années au LIFO, d’abord comme ingénieur recherche, puis comme doctorante. Je tiens donc à remercier le LIFO dans sa globalité et sans exception, les anciens comme les nouveaux. Je tiens particulièrement à remercier les personnes qui m’ont fait confiance pour donner des cours au département informatique de l’Université d’Orléans : Ali, Alexandre, Sophie et Sylvain. Enfin, on les oublie souvent, mais un très grand merci aux secrétaires Isabelle et Florence, pour leur bonne humeur et leur travail irréprochable. Merci à mon ancien co-bureau Julien pour ses bons conseils, et aussi merci à Mon SIM, Monsieur Patate, Iko, Matthieu Lopette, Nicducasquette, Peranth, Florent, Le Foulque, Le Legaux, Davide, Shiruba, Le Trôme, El Cennalgo, Guigui etc. et tous les doctorants, ATERs et post-docs passés au LIFO que je pourrais oublier de citer. Toujours dans le contexte du travail, ma thèse a eu la chance d’être enrichie par un grand nombre de collaborations. Un grand merci à Minh, Olivier, Stéphane, Christian, Pierre-Yves, Jose-Maria et Xiaofei pour avoir travaillé avec moi sur des applications de mon travail. Et un grand merci à Rob de m’avoir reçu à l’Université d’Utrecht et d’avoir collaboré avec moi sur des problématiques que je ne connaissais pas. Merci aux personnes qui m’ont aidé à rédiger et relire cette thèse, Sylvain, Pierre-Yves et surtout Caro ! Merci và mes rapporteurs Christian et David, ainsi qu’aux membres de mon jury Frédéric, Rob, Daniel pour leur temps et leur expertise. Apprendre à se remettre en question, à jeter ce sur quoi on travaille depuis des mois pour partir vers autre chose, apprendre à ne pas trouver de voie, à rester bloqué, autant de difficultés qui rendent la thèse si difficile et une réelle formation à la recherche. Il n’est pas rare de déprimer, de vouloir abandonner, de ne pas se sentir à la hauteur, et alors une thèse parait impossible sans soutien, sans amitié. Merci à mes parents et ma grande sœur qui m’ont soutenue, comme toujours, dans cette démarche. Merci à mes amis Simon et Yannick pour les discussions, les pauses, les amusements et les sorties, mais aussi pour leur aide dans les moments difficiles. Merci au Club de Floorball Orléanais, aux Atlantics et aux filles de l’équipe de France, plus particulièrement à Caro, Auréa, Guigui, Juju, Malabar, Élodie, Joss, Pauline etc. Merci au CLTO Hockey sur gazon, plus particulièrement à Pablo, petit Pierre, Neness et Raymond. Pour terminer ces remerciements, je remercie ma moitié, Jean-Hugues. Merci de m’avoir épaulé et supporté pendant ces trois années stressantes et éprouvantes. Merci de me donner la chance de continuer en recherche en faisant le sacrifice de quitter Orléans pour Lyon. viTable des matières Table des matières vii Liste des figures ix 1 Introduction 1 1.1 Contexte de la recherche . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Etat de l’art 7 2.1 Calcul parallèle : architectures et programmation . . . . . . . 8 2.1.1 Architectures parallèles . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Paradigmes et modèles de parallélisation . . . . . . . . . . . . . . . . . 13 2.2 Problèmes numériques et Simulations scientifiques . . . . . . . . 19 2.2.1 Équations aux dérivées partielles . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 Passage du continu au discret . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3 Méthodes numériques basées sur les maillages . . . . . . . . . . . . . . 23 2.2.4 Exemples de méthodes numériques basées sur des maillages . . . . . . . 25 2.2.5 Programmation et parallélisation . . . . . . . . . . . . . . . . . . . . . 31 2.3 Distribution de données . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.1 Modèles de partitionnement . . . . . . . . . . . . . . . . . . . . . . . 35 2.3.2 Cas particulier du partitionnement de matrices . . . . . . . . . . . . . 38 2.3.3 Cas particulier du partitionnement de maillages . . . . . . . . . . . . . 40 2.3.4 Partitionnements particuliers . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Le parallélisme implicite . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.4.1 Classification de problèmes et aide à la parallélisation . . . . . . . . . . 45 2.4.2 Solutions partiellement implicites . . . . . . . . . . . . . . . . . . . . 46 2.4.3 Solutions générales de parallélisme implicite . . . . . . . . . . . . . . . 47 2.4.4 Solutions à patrons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.4.5 Solutions spécifiques à un domaine . . . . . . . . . . . . . . . . . . . . 53 2.5 Calculs de performances et difficulté de programmation . . . 56 2.5.1 Mesures de performances . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.5.2 Effort de programmation . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.6 Conclusion et positionnement du travail . . . . . . . . . . . . . . 61 vii3 SIPSim : Structured Implicit Parallelism for scientific Simulations 63 3.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . 66 3.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . 68 3.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . 68 3.5 Vue utilisateur et vue réelle . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Type de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4 SkelGIS pour des maillages réguliers à deux dimensions 73 4.1 SIPSim pour les maillages réguliers à deux dimensions . . . . . 74 4.1.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 74 4.1.2 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . 77 4.1.3 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.4 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . 80 4.2 Résolution numérique de l’équation de la chaleur . . . . . . . . 82 4.2.1 Équation et résolution numérique . . . . . . . . . . . . . . . . . . . . 82 4.2.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 83 4.2.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.3 Résolution numérique des équations de Saint Venant . . . . . . 89 4.3.1 Équations de Saint Venant . . . . . . . . . . . . . . . . . . . . . . . . 89 4.3.2 Résolution numérique et programmation . . . . . . . . . . . . . . . . . 90 4.3.3 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5 SkelGIS pour des simulations sur réseaux 101 5.1 Les réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.2 SIPSim pour les réseaux . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.2.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 106 5.2.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.2.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . 107 5.2.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . 108 5.2.5 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . 111 5.3 Structure de données distribuée pour les réseaux . . . . . . . . 112 5.3.1 Le format Compressed Sparse Row . . . . . . . . . . . . . . . . . . . . 113 5.3.2 Format pour les DAG distribués . . . . . . . . . . . . . . . . . . . . . 115 5.3.3 Implémentation de SkelGIS pour les réseaux . . . . . . . . . . . . . . . 122 5.4 Simulation 1D d’écoulement du sang dans les artères . . . . . . 123 5.4.1 Simulation 1D d’écoulement du sang dans le réseau artériel . . . . . . . 123 5.4.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 125 5.4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.5 Partitionnement de réseaux . . . . . . . . . . . . . . . . . . . . . . . 137 viii5.5.1 Partitionnement par regroupement d’arêtes sœurs . . . . . . . . . . . . 137 5.5.2 Partitionnement avec Mondriaan . . . . . . . . . . . . . . . . . . . . . 141 5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6 Conclusion 153 6.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Bibliographie 159 Liste des figures 2.1 De la gauche vers la droite : maillage cartésien, curvilinéaire et non-structuré. 21 2.2 Maillages en théorie des graphes. . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 Discrétisation régulière de Ω = {x : x ∈ [0, 1]}. . . . . . . . . . . . . . . . . 26 2.4 Discrétisation régulière de Ω = {(x, y) : (x, y) ∈ [0, 1]2}. . . . . . . . . . . . 27 2.5 Interprétation de la seconde forme intégrale de la loi de conservation. . . . 29 2.6 Discrétisation en cellules à volume fini suivant x et t. . . . . . . . . . . . . 29 2.7 Illustration de la méthode des éléments finis pour un cas simple à une dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.8 Fonctions de base Φj de type “tente”. . . . . . . . . . . . . . . . . . . . . . 31 2.9 Graphe donnant un exemple de partitionnement où la métrique edge-cut ne représente pas le volume de communication. . . . . . . . . . . . . . . . 37 2.10 De gauche à droite : partitionnement en blocs, en blocs-lignes et bissection récursive orthogonale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.11 De gauche à droite et de haut en bas : le maillage non structuré 2D, son graphe nodal, son graphe dual et son graphe dual-diagonal. . . . . . . . . 42 2.12 Placement de notre travail par rapport à l’existant. . . . . . . . . . . . . . 62 3.1 Vue utilisateur (à gauche) et vue réelle (à droite) d’un programme SIPSim. 70 4.1 Deux types de connectivités pour les DMatrix de SkelGIS . . . . . . . . . 75 4.2 Décomposition d’un domaine à deux dimensions. . . . . . . . . . . . . . . 76 4.3 Exemple d’itérateur permettant de se déplacer dans trois éléments contigus puis d’effectuer un saut de deux éléments avant la lecture contiguë suivante. 79 ix4.4 Spécialisation partielle de template pour l’objet DMatrix : T est le type de donnée à stocker dans l’instance, Or est l’ordre de la simulation, et box est le type de connectivité souhaitée. Ce paramètre a une valeur par défaut à false (star est le choix par défaut). . . . . . . . . . . . . . . . . . 81 4.5 Fonction main du programme de résolution de l’équation de la chaleur avec SkelGIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.6 Opération Laplacien pour la résolution de l’équation de la chaleur. . . . . 85 4.7 Logarithme des temps d’exécution de l’expérience 1 pour Heat_MPI et Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.8 Logarithme des temps d’exécution de l’expérience 2 pour Heat_MPI et Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.9 Logarithme des temps d’exécution de l’expérience 3 pour Heat_MPI et Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.10 Accélération de la simulation SkelGIS pour les trois expériences. . . . . . . 88 4.11 Déclaration des variables h, u et v . . . . . . . . . . . . . . . . . . . . . . 92 4.12 Logarithme des temps d’exécution de l’expérience 1 pour FS_MPI et FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.13 Logarithme des temps d’exécution de l’expérience 2 pour FS_MPI et FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.14 Logarithme des temps d’exécution de l’expérience 3 pour FS_MPI et FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.15 Logarithme des temps d’exécution de l’expérience 4 pour FS_MPI et FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.1 Illustration d’un réseau à gauche et d’un exemple de simulation multiphysique à droite avec deux types de discrétisation. Les nœuds subissent une discrétisation cartésienne de l’espace et les arêtes subissent une discrétisation non-structurée de l’espace. . . . . . . . . . . . . . . . . . . . . 103 5.2 Maillages et réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.3 Voisinage d’un nœud et d’une arête d’un réseau. . . . . . . . . . . . . . . . 110 5.4 Voisinage pour le cas particulier d’un maillage 1D dans les arêtes. . . . . . 110 5.5 Définition des objets DPMap_Edges et DPMap_Nodes. . . . . . . . . . . 111 5.6 Spécialisations partielles de template pour l’objet DPMap_Edges . . . . . 112 5.7 Graphe non orienté G et sa matrice d’adjacence Sp(G). . . . . . . . . . . 114 5.8 Graphe orienté acyclique correspondant au graphe 5.7. . . . . . . . . . . . 116 5.9 DAG global partitionné pour quatre processeurs. Le processeur 1 récupère la partie bleue de ce partitionnement. . . . . . . . . . . . . . . . . . . . . . 117 5.10 Sous-graphe géré par le processeur 1 avant et après ré-indexation. . . . . . 118 5.11 Parallélisation de la structure et ré-indexation. . . . . . . . . . . . . . . . 119 5.12 Système de ré-indexation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.13 Déclaration des variables A et Q . . . . . . . . . . . . . . . . . . . . . . . 126 5.14 Déclaration d’une variable nd sur les nœuds du réseau . . . . . . . . . . . 127 x5.15 Accélération de la simulation bloodflow-SkelGIS sans et avec le recouvrement des communications par les calculs. . . . . . . . . . . . . . . . . . . . 131 5.16 Comparaison des temps d’exécution entre bloodflow-OpenMP et bloodflow-SkelGIS avec une échelle logarithmique. . . . . . . . . . . . . . . 132 5.17 Comparaison des accélérations entre bloodflow-OpenMP et bloodflowSkelGIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 5.18 Accélération de bloodflow-SkelGIS sur un DAG de 15k arêtes et nœuds sur le TGCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.19 Accélération de bloodflow-SkelGIS sur des DAGs de 50k et 100k arêtes et nœuds sur Juqueen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.20 Accélération de bloodflow-SkelGIS sur un DAG de 500k arêtes et nœuds sur Juqueen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.21 Exemple de réseau G (à gauche) de type DAG, et du méta-graphe G0 associé (à droite). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.22 Moyenne (moy) et écart type (ect) du nombre d’arêtes obtenu pour chaque processeurs suite au partitionnement. . . . . . . . . . . . . . . . . . . . . . 140 5.23 Moyenne (moy) et écart type (ect) du nombre d’octets à échanger pour chaque processeur, pour chaque DPMap et pour une unique itération de temps de la simulation, suite au partitionnement des arbres de la table 5.8. 140 5.24 Moyenne du nombre d’octets total à échanger pour chaque processeur, dans le cadre de la simulation artérielle de la section 5.4, en utilisant les arbres de la table 5.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.25 Transformation du graphe G d’un réseau en graphe G0 . . . . . . . . . . . . 143 5.26 Étapes de communication 1 et 3. . . . . . . . . . . . . . . . . . . . . . . . 143 5.27 Exemple de réseau G0 avec la matrice A et les hypergraphes Hr et Hc qui y sont associés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.28 Problème de partitionnement pour les nœuds bleus de G0 . . . . . . . . . . 146 5.29 La matrice W et le graphe biparti complet auquel la matrice peut être identifiée Gw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 xi1 Introduction Sommaire 2.1 Calcul parallèle : architectures et programmation . . . . . . . 8 2.1.1 Architectures parallèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Paradigmes et modèles de parallélisation . . . . . . . . . . . . . . . . . . 13 2.2 Problèmes numériques et Simulations scientifiques . . . . . . . . 19 2.2.1 Équations aux dérivées partielles . . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 Passage du continu au discret . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3 Méthodes numériques basées sur les maillages . . . . . . . . . . . . . . . 23 2.2.4 Exemples de méthodes numériques basées sur des maillages . . . . . . . 25 2.2.5 Programmation et parallélisation . . . . . . . . . . . . . . . . . . . . . . 31 2.3 Distribution de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.1 Modèles de partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.3.2 Cas particulier du partitionnement de matrices . . . . . . . . . . . . . . 38 2.3.3 Cas particulier du partitionnement de maillages . . . . . . . . . . . . . . 40 2.3.4 Partitionnements particuliers . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Le parallélisme implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.4.1 Classification de problèmes et aide à la parallélisation . . . . . . . . . . 45 2.4.2 Solutions partiellement implicites . . . . . . . . . . . . . . . . . . . . . . 46 2.4.3 Solutions générales de parallélisme implicite . . . . . . . . . . . . . . . . 47 2.4.4 Solutions à patrons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.4.5 Solutions spécifiques à un domaine . . . . . . . . . . . . . . . . . . . . . 53 2.5 Calculs de performances et difficulté de programmation . . . 56 2.5.1 Mesures de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.5.2 Effort de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.6 Conclusion et positionnement du travail . . . . . . . . . . . . . . . 61 12 Chapitre 1. Introduction 1.1 Contexte de la recherche Les calculs scientifiques, notamment dans le domaine de la simulation numérique, ont toujours été consommateurs de ressources informatiques. Dans les années 60, à l’apparition des premiers super-calculateurs, les calculs les plus demandeurs en ressources étaient déjà les calculs scientifiques. Depuis, ce besoin de puissance de calcul n’a fait qu’augmenter, donnant naissance à des architectures parallèles toujours plus complexes à utiliser. La demande de puissance de calcul, ou de performance dans les architectures parallèles, est a priori sans limites pour plusieurs raisons. Tout d’abord, les données utilisées par les scientifiques sont de plus en plus précises et donc de plus en plus lourdes et longues à traiter. Cette précision des données vient, par exemple, de la progression des techniques d’acquisition, comme pour les données géo-référencées obtenues par des technologies à laser (la télédétection LIDAR, par exemple). Cette précision peut également être obtenue en complexifiant le maillage associé au domaine d’étude dans les simulations numériques. En effet, dans les simulations, le domaine d’étude est généralement discrétisé en un maillage afin de pouvoir être traité numériquement. Plus ce maillage est précis, plus la simulation est précise et plus les calculs à effectuer sont nombreux, et il est en pratique possible d’augmenter très largement la précision du maillage (sous réserve des capacités de précision du matériel). De plus, il est évident qu’il est également possible d’augmenter la taille du domaine d’étude de façon importante, ce qui est également à l’origine des besoins croissants de puissance et de parallélisme. Enfin, si les maillages des simulations numériques peuvent être complexifiés, les méthodes numériques et les calculs peuvent l’être également. Un exemple très parlant de demande croissante de puissance de calcul est le traitement des modèles météorologiques. Il est potentiellement toujours possible d’ajouter des facteurs aux modèles, et de les complexifier, mais également d’augmenter la taille du domaine étudié etc. Toutes ces modifications rendent les calculs plus longs, demandant plus de puissance et plus de parallélisation, mais permettent d’obtenir des prévisions plus précises. Il résulte donc de cette demande croissante de puissance, la création d’architectures parallèles, c’est-à-dire des architectures qui intègrent plusieurs processeurs, voire plusieurs machines. De cette manière, il est possible d’obtenir plus de puissance de calcul sans attendre les prochaines générations de processeurs. L’évolution de ces machines parallèles nous a mené à des architectures matérielles de plus en plus compliquées et parfois hétérogènes, mélangeant alors plusieurs machines (cluster ou cloud computing), plusieurs cœurs et plusieurs processeurs mais aussi des calculateurs graphiques (GPU ). Les scienti- fiques se retrouvent ainsi à devoir utiliser des architectures parallèles très complexes pour pouvoir proposer des résultats pertinents et intéressants pour la communauté, sans en maîtriser l’utilisation, comme d’ailleurs la plupart des informaticiens également. Le calcul parallèle est donc devenu rapidement un domaine d’expertise que peu de personnes maî- trise. Il n’est par conséquent pas envisageable que chaque scientifique non-informaticien apprenne à programmer sur ces architectures et devienne un expert du parallélisme, par manque de temps, d’argent, et de personnes pouvant les former. De plus, si une formation de base est quant à elle envisageable, elle ne sera pas suffisante pour exploiter la pleine1.2. Contributions 3 puissance de ces machines. Même si cela se pratique dans certains cas, il paraît également délicat d’imaginer des collaborations entre des scientifiques non-informaticiens et des experts du parallélisme pour chaque code parallèle nécessaire. Pour ces raisons sont nés, quasiment avec l’apparition des architectures parallèles, des outils et langages facilitant leur programmation. Des modèles de programmation ont tout d’abord été proposés, puis des langages et des bibliothèques parallèles, mais la complexité grandissante des architectures a également fait évoluer ces solutions vers des solutions de parallélisme implicite qui cachent partiellement ou totalement le parallélisme à l’utilisateur. Nous parlons alors de parallélisme implicite partiel, lorsque les outils proposés cachent partiellement les technicités du parallélisme, ou total, lorsque les outils cachent intégralement le code parallèle à l’utilisateur. Nous classons les solutions de parallélisme implicite total suivant trois grands types : les bibliothèques générales ; les solutions à patrons ; et les langages et bibliothèques spécifiques. Dans le premier type une grande flexibilité est proposée et les solutions permettent de s’adresser à tout type de traitements. Le second type propose, quant à lui, un niveau d’abstraction très intéressant, et permet également de structurer le code et de donner des repères simples à l’utilisateur. Enfin, le troisième type de parallélisme implicite total est spécifique à un problème précis et propose des optimisations et une efficacité pour ce problème. Le langage ou la bibliothèque est également plus simple d’utilisation car proche du problème spécifique. Il s’agit des solutions les plus efficaces mais également les moins flexibles. 1.2 Contributions Cette thèse se place dans le cadre du parallélisme implicite pour les simulations numé- riques. Nous proposons, tout d’abord, dans ce travail de thèse un modèle de programmation parallèle implicite, nommé SIPSim pour Structured Implicit Parallelism for scientific Simulations. Ce modèle présente une approche systématique pour proposer des solutions de parallélisme implicite pour les simulations numériques basées sur des maillages. Le modèle est basé sur quatre composants permettant de cacher intégralement le parallé- lisme à l’utilisateur et d’obtenir un style de programmation proche du séquentiel. Le modèle SIPSim se positionne à l’intersection des travaux existants en tentant de conserver les avantages de chacun. Ainsi, le modèle a la particularité d’être à la fois efficace, car spécifique au cas des simulations numériques à maillages, d’un niveau d’abstraction permettant de conserver une programmation proche du séquentiel, ce qui garantit un effort de programmation faible, tout en restant très flexible et adaptable à tout type de simulations numériques. Afin de valider le modèle SIPSim, une implémentation est proposée dans cette thèse, sous le nom de SkelGIS. SkelGIS est une bibliothèque C++ constituée uniquement de fichiers d’en-tête, ou autrement appelée header-only, implémentée en suivant le modèle SIPSim pour deux cas de maillages différents : les maillages cartésiens à deux dimensions, et les compositions de maillages issues des simulations sur des réseaux. Dans le premier cas, de nombreuses solutions de parallélisme implicite existent, toutefois, en suivant le4 Chapitre 1. Introduction modèle SIPSim, SkelGIS se place à l’intersection de plusieurs solutions et mêle à la fois l’efficacité et la flexibilité de façon intéressante. Le deuxième cas, quant à lui, initie un travail sur des simulations d’un genre plus complexe, où une composition de maillages est effectuée. La flexibilité du modèle SIPSim est alors mise en avant, et ce type de travaux n’a, à notre connaissance, jamais été proposé en parallélisme implicite. La bibliothèque SkelGIS est évaluée en termes de performance et d’effort de programmation sur deux cas réels d’application, développés et utilisés par des équipes de recherche en mathématiques appliquées. Ces évaluations permettent donc, tout d’abord, de valider que SkelGIS (et le modèle SIPSim) répond aux besoins de simulations complexes, et donc aux besoins des scientifiques. Les performances obtenues sont comparées à des implémentations MPI et OpenMP des mêmes simulations. Sur l’ensemble de ces évaluations, et pour un effort de programmation beaucoup moins important, les performances obtenues sont très compé- titives et proposent de meilleurs temps d’exécution. Nous montrons ainsi que SkelGIS propose des solutions efficaces et flexibles, tout en cachant intégralement le parallélisme à l’utilisateur et tout en conservant un style de programmation séquentiel. La plupart des travaux présentés dans cette thèse ont fait l’objet de publications. Publications dans des conférences internationales 1. Hélène Coullon, Sébastien Limet. Implementation and Performance Analysis of SkelGIS for Network Mesh-based Simulations. Euro-Par 2014. 2. Hélène Coullon, Jose-Maria Fullana, Pierre-Yves Lagrée, Sébastien Limet, Xiaofei Wang. Blood Flow Arterial Network Simulation with the Implicit Parallelism Library SkelGIS. ICCS 2014. 3. Hélène Coullon, Sébastien Limet. Algorithmic skeleton library for scientific simulations : Skelgis. In HPCS, pages 429-436. IEEE, 2013. 4. Hélène Coullon, Minh-Hoang Le, Sébastien Limet. Parallelization of shallow-water equations with the algorithmic skeleton library skelgis. In ICCS, volume 18 of Procedia Computer Science, pages 591–600. Elsevier, 2013. Publications dans des journaux internationaux 1. Stéphane Cordier, Hélène Coullon, Olivier Delestre, Christian Laguerre, MinhHoang Le, Daniel Pierre, and Georges Sadaka. Fullswof paral : Comparison of two parallelization strategies (mpi and skelgis) on a software designed for hydrology applications. ESAIM : Proceedings, 43 :59–79, 2013. Publications en cours d’évaluation dans des journaux internationaux 1. Hélène Coullon, Minh-Hoang Le, Sébastien Limet. Implicit parallelism applied to shallow-water equations using SkelGIS. In Concurrency and Computation : Practice and Experience.1.3. Organisation du manuscrit 5 1.3 Organisation du manuscrit Ce manuscrit est organisé en cinq chapitres supplémentaires dont voici le contenu : — Nous étudions dans le chapitre 2 l’état de l’art nécessaire à la bonne compréhension de ce manuscrit. Cet état de l’art est composé d’un historique et d’une présentation des architectures parallèles, et des modèles et outils de parallélisation qui y sont associés. Nous donnons ensuite une introduction sur les simulations numériques basées sur des maillages, ce qui permet de rendre plus clairs les cas d’application de cette thèse. Les bases nécessaires pour la compréhension des problèmes de dé- compositions de domaines et de partitionnements de graphes, évoqués dans cette thèse, sont ensuite abordés. Une description détaillée des solutions de parallélisme implicites disponibles dans la littérature est ensuite proposée et permettra le positionnement de notre travail dans ce contexte. Enfin, nous présentons les mesures de performance et d’effort de programmation utilisées dans ce manuscrit. — Le chapitre 3 présente le modèle de programmation implicite SIPSim. Il détaille pour cela les quatre composants qui le constitue et le type de programmation obtenu en adoptant ce modèle. — Dans le chapitre 4 est ensuite détaillé la première implémentation du modèle SIPSim, SkelGIS, pour le cas des maillages à deux dimensions cartésiens. Deux cas d’application réels sont également détaillés et évalués dans ce chapitre. — Le chapitre 5 continue la description de l’implémentation SkelGIS dans le cas des simulations sur les réseaux, afin de valider davantage le modèle SIPSim. Une section particulière précise l’implémentation et l’optimisation de la structure de données distribuée, puis une section supplémentaire offre de nouveau un cas d’application réel afin d’évaluer la solution. Pour terminer ce chapitre, le problème de partitionnement des réseaux est évoqué et deux solutions plus récentes sont présentées. — Enfin, dans le chapitre 6 est présenté un bilan des travaux présentés dans cette thèse, mais également un ensemble de perspectives de recherche.2 Etat de l’art Sommaire 3.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 66 3.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . . 68 3.5 Vue utilisateur et vue réelle . . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Type de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 78 Chapitre 2. Etat de l’art Dans ce chapitre vont être introduites les notions nécessaires à la bonne compréhension de ce manuscrit. Afin, tout d’abord, de comprendre les problématiques engendrées par l’utilisation des machines parallèles, nous étudierons rapidement les évolutions des architectures parallèles, et les modèles algorithmiques et de programmation qui en dé- coulent. Par la suite, nous étudierons des notions sur le calcul et la simulation scientifique, qui représentent les domaines d’application de cette thèse. Deux états de l’art précis seront ensuite nécessaires, sur la décomposition de domaine, et le parallélisme implicite. Ces notions représentent, en effet, les problématiques informatiques principales de cette thèse. Enfin, cette thèse présentera un certain nombre de résultats expérimentaux, nous terminerons donc ce chapitre par une discussion des choix effectués pour l’évaluation des performances et de la difficulté de programmation des solutions. 2.1 Calcul parallèle : architectures et programmation Dans cette première section de l’état de l’art, nous allons introduire les notions de base du parallélisme, nécessaires à la compréhension de cette thèse. Nous commencerons par un historique rapide des architectures parallèles, puis une description des architectures actuelles. Nous décrirons ensuite les principaux modèles de parallélisation disponibles pour programmer ces architectures. 2.1.1 Architectures parallèles C’est en 1965 qu’a été exprimée dans “Electronics Magazine” la première loi de Moore, qui n’était alors qu’un postulat fondé sur une simple observation. En effet, Gordon Moore constata que la complexité des semiconducteurs doublait tous les ans, depuis leur apparition en 1959. Le postulat consistait alors à supposer la poursuite de cette croissance. C’est également dans les années 60 que sont apparus les premiers super-calculateurs, dont le but initial était d’effectuer une exécution la plus rapide possible des instructions d’un programme. Toutefois, bien que le monde informatique se basait alors sur la loi de Moore, et donc sur la montée en puissance des semi-conducteurs (puis plus tard sur la miniaturisation des transistors), l’idée de machine parallèle est apparue très rapidement. En effet, de par la demande grandissante de performances, notamment pour les calculs scientifiques, il est vite devenu difficile de devoir attendre la sortie d’une nouvelle gamme de processeurs pour obtenir plus de puissance de calcul. Il n’était, de plus, pas envisageable de racheter l’ensemble du matériel régulièrement. Ainsi, l’idée de faire collaborer ensemble plusieurs ordinateurs pour obtenir un résultat plus rapidement se concrétisa dans les années 60. On parla alors, pour la première fois, d’architectures multiprocesseurs, un terme qui désignait alors une architecture SMP (Symetric Multi Processor ). Encore utilisée à l’heure actuelle, sous une forme plus moderne, l’architecture SMP représente un ensemble de processeurs identiques dans une même machine, qui partagent une mémoire vive commune. Dans les années 1970, l’architecture des super-calculateurs évolua, proposant l’utilisation de processeurs vectoriels. Ces processeurs furent les plus puissants de leur génération2.1. Calcul parallèle : architectures et programmation 9 et connurent un grand succès. Leur puissance était due à leur capacité à appliquer une même instruction à des parties différentes des données, de façon simultanée. Plusieurs processeurs vectoriels ont ensuite été utilisés en parallèle pour obtenir toujours plus de puissance. Ce n’est qu’en 1975, et suite à l’apparition des transistors, que Gordon Moore ré- évalua sa première loi sous la forme d’une deuxième loi qui supposait que le nombre de transistors sur une puce pouvait doubler tous les deux ans. Une mauvaise interprétation de cette loi fût longtemps énoncée. Un amalgame y était effectué entre le nombre de transistors sur une puce et la fréquence d’horloge d’un processeur. Cette loi erronée s’est pourtant avérée exacte jusqu’au début des années 2000, avant de poser des difficultés de dissipation thermique pour des fréquences trop importantes. Dans les années 80, suite à la miniaturisation des transistors, sont apparus les microprocesseurs. Leur puissance était modeste, mais leur faible encombrement et leur faible consommation ont permis l’apparition, puis la démocratisation, des ordinateurs personnels. Le perfectionnement des techniques de miniaturisation a permis une croissance importante de la puissance des microprocesseurs. Les microprocesseurs sont ainsi devenus très rapidement compétitifs, en terme de performances, face aux processeurs vectoriels. Leur faible coût de fabrication en ont fait les processeurs les plus utilisés dans les architectures parallèles. Nous allons décrire avec plus de précision, dans la suite de cette section, les différentes architectures parallèles issues de l’apparition des microprocesseurs. 2.1.1.1 Architectures à mémoire partagée Architectures SMP. Comme nous l’avons décrit précédemment, cette architecture parallèle (la plus ancienne), consiste à regrouper plusieurs processeurs au sein d’une même machine et de leur faire partager une même mémoire vive. Cette architecture a naturellement été étendue aux microprocesseurs, toutefois, il n’est pas possible d’utiliser cette architecture parallèle en augmentant à l’infini le nombre de processeurs. En effet, les processeurs d’une architecture SMP entrent tous en concurrence pour lire et écrire dans la mémoire commune, ce qui implique que l’ajout de processeurs à cette architecture ne peut être efficace que si la mémoire est capable d’alimenter les processeurs supplémentaires en données à traiter. Les microprocesseurs ont très rapidement été plus rapides que les mémoires, créant une limitation physique à cette architecture. Architectures NUMA. Les architectures à mémoire non uniforme, NUMA (Non Uniform Memory Access), définissent pour chaque processeur (ou petit groupe de processeurs) l’attribution d’une sous-partie de mémoire en accès direct et très rapide. Chaque processeur ne pourra accéder aux données des autres mémoires qu’à travers un bus d’interconnexion, plus lent. Cette architecture vise à améliorer l’architecture SMP en réduisant le goulot d’étranglement dû à la mémoire commune à l’ensemble des processeurs. Architectures multi-cœurs et many-cœurs. Dans le but d’augmenter la puissance des microprocesseurs, sans en augmenter la fréquence, le concept de cœurs multiples10 Chapitre 2. Etat de l’art (multicore) est apparu en 2001. Cette architecture peut être vue comme une unique puce regroupant plusieurs microprocesseurs. Dans cette architecture, la proximité des cœurs de calcul permet une communication plus rapide entre les différentes mémoires des différents cœurs. Certaines architectures proposent même un système de mémoire cache partagée par les cœurs. Le principe de la mémoire cache, ou mémoire tampon, est de fournir dans les architectures modernes une mémoire très proche des processeurs (ou cœurs) et permettant un accès plus rapide aux données. Cette mémoire, comme son nom l’indique sert de tampon entre la mémoire vive et les unités de calcul, elle réduit donc les délais d’accès aux données. La mémoire cache est composée de plusieurs niveaux. Le niveau L1, ou cache interne, est le plus rapide et le plus proche des unités de calcul. La mémoire cache fonctionne par chargement de lignes de cache. Une ligne de cache est de taille limitée et dépend du matériel présent dans le processeur. Lorsqu’un processeur a besoin d’accéder à une donnée pour une opération arithmétique, cette donnée, et ses données contiguës en mémoire, sont chargées dans une ligne de cache (suivant sa limite de taille). Si une donnée non présente dans le cache est nécessaire (on parle alors de défaut de cache), une ligne de cache est invalidée et une nouvelle ligne devra à son tour être chargée etc. Ces nouveaux processeurs ont permis, tout comme l’architecture NUMA, de réduire le goulot d’étranglement des architectures SMP. De plus ces architectures ont permis de démocratiser les architectures parallèles dans les ordinateurs personnels. Plus récemment sont apparus les architectures multiprocesseurs Intel MIC pour Intel Many Integrated Core Architecture, dont, par exemple, le très médiatique accélérateur Xeon Phi. Ces architectures regroupent plusieurs processeurs possédant chacun un très grand nombre de cœurs. On parle alors d’architectures many-cœurs. Le nombre total de cœurs est très important dans ces architectures et donne accès au calcul massivement parallèle (tout comme les accélérateurs graphiques dont nous parlerons par la suite), sans pour autant devoir apprendre de nouvelles interfaces de programmation (contrairement aux accélérateurs graphiques). 2.1.1.2 Architectures à mémoire distribuée Architecture en grappe. L’architecture en grappe, aussi appelée un cluster en anglais, consiste à connecter entre elles, par un réseau d’interconnexion à très haut débit, plusieurs machines (ou nœuds) indépendantes matériellement homogènes. Dans une architecture en grappe, et contrairement à une architecture à mémoire partagée, chaque nœud est indépendant et possède donc sa propre mémoire à laquelle les autres nœuds n’ont pas accès. Les nœuds sont donc amenés, dans ce type d’architectures, à communiquer au travers du réseau d’interconnexion. Un réseau à très haute performance étant très coûteux, les machines d’une grappe sont géographiquement les plus proches possible, dans une même pièce ou dans une même armoire de rangement. Il s’agit d’une approche simple mais très favorable au calcul haute performance pour plusieurs raisons. Tout d’abord, outre la rapidité du réseau, un travail sur la topologie des réseaux peut rendre plus rapides les communications entre certains nœudss du cluster. Une topologie proche de la topologie des données utilisées peut donc, par exemple, favoriser les performances d’un parallélisme de données. De plus, une grappe est composée d’un grand2.1. Calcul parallèle : architectures et programmation 11 nombre de processeurs identiques ce qui permet de favoriser l’optimisation d’un type de matériel donné. Avec la démocratisation des architectures multi-processeurs et multicœurs, les grappes sont aujourd’hui composées d’un certain nombre de nœuds ou d’unités de calcul indépendantes à mémoire partagée. En théorie, ces architectures peuvent donc être considérées comme des architectures à mémoire distribuée, mais également comme des architectures à mémoire hybride. Architecture en grille. Le concept de grille est un concept proche du concept de grappe. Toutefois, une grille consiste à relier entre elles des ressources de calcul hété- rogènes (ordinateurs, grappes, serveurs etc.) et potentiellement distantes. En effet, le but d’une grille est d’utiliser la puissance de calcul disponible à plusieurs endroits pour proposer une unique architecture virtuelle possédant des ressources de calcul très importantes et extensibles. L’utilisateur d’une grille ne fait que soumettre le lancement de calculs et n’aura aucune information sur les machines utilisées pour son calcul. La gestion de ce type d’architecture est donc très complexe et son utilisation est souvent restreinte aux calculs massivement parallèles (embarrassingly parallel), qui consistent à effectuer le même traitement un grand nombre de fois, ce qui ne provoque aucune communication entre les ressources. Pour des calculs parallèles nécessitant des communications entre les ressources de calcul, une unique ressource de la grille est généralement utilisée, on retrouve alors la notion de serveur ou de cluster, par exemple. Les ressources d’une grille pouvant être géographiquement éloignées, le réseau d’interconnexion reliant les ressources n’est généralement pas un réseau à très haut débit, trop coûteux. Toutefois, la plateforme expérimentale Grid’5000 relie, par exemple, une dizaine de grappes de plusieurs villes françaises au travers du réseau à haut débit RENATER (Réseau national de télécommunications pour la technologie, l’enseignement et la recherche). Cloud computing. Le nuage, plus communément appelé le cloud, est un service mettant à disposition des ressources de calcul ou de stockage distantes. Le cloud ressemble donc aux concepts de grille et de cluster. Toutefois, il se distingue par plusieurs points. Tout d’abord, le concept de cloud est un service grand public qui s’ouvre à tous et qui est généralement payant. Les clusters, comme les grilles, sont souvent des outils réservés à des utilisateurs précis sur une période de temps limitée. L’accès y est gratuit mais une demande doit être mise en place pour utiliser ce type d’architectures. De plus, le cloud, contrairement à la grille, n’a pas été pensé pour l’accès à des ressources délocalisées. Très souvent les ressources d’un cloud appartiennent à une unique entité et sont regroupées géographiquement dans un endroit (bien que des travaux regroupant plusieurs cloud existent également). De même, le cloud se distingue de la grille par le fait qu’il n’est pas été mis en place dans l’idée de relier des architectures hétérogènes. Le cloud est donc à la frontière des clusters et des grilles, mais dans une optique de service commercial et grand public.12 Chapitre 2. Etat de l’art 2.1.1.3 Architectures hétérogènes Retour de la vectorisation. Toujours afin d’augmenter la puissance des microprocesseurs, sans en augmenter la fréquence, les capacités de vectorisation ont été réintroduites dans les microprocesseurs scalaires modernes. On peut notamment évoquer les instructions SSE (Streaming SIMD Extension), qui sont associées à des registres de 128 bits sur lesquels il est possible d’effectuer quatre opérations simultanées sur des nombres flottants de 32 bits, ou deux opérations simultannées sur des nombres flottants de 64 bits etc. La version la plus récente SSE4 donne accés à 47 types d’instructions. Les jeux d’instructions AVX2 (Advanced Vector Extensions 2 ) et AVX-512, plus récents, proposent des opérations simultanées sur des registres de 256 et 512 bits, ce qui augmente encore les possibilités de calcul des microprocesseurs. Les registres vectoriels, ajoutés aux microprocesseurs modernes, offrent une hétérogénéité d’architecture proposant des performances très intéressantes. Accélérateurs graphiques. Les processeurs graphiques, ou GPU, sont initialement apparus pour effectuer des calculs performants et spécifiques à l’affichage graphique, comme par exemple le rendu d’images en trois dimensions. Ils ont rapidement été massivement parallélisés, de par la nature répétitive de leurs calculs. Initialement, ces processeurs graphiques étaient cantonnés à un certain nombre de fonctionnalités, puis ils sont devenus programmables, ce qui a initié une déviation de leur utilité première, pour des calculs autres que graphiques. On ne parle alors plus de GPU mais de GPGPU. Un GPGPU propose des unités de calcul alternatives aux CPU, et massivement parallèles. Toutefois, il est important de noter qu’un GPU ne peut complètement s’abstraire d’un CPU pour fonctionner, ce dernier permettant de charger des programmes et des données en mémoire vive. Il s’agit donc d’une architecture parallèle hétérogène. Les GPU étant peu coûteux et consommant peu d’énergie, leur utilisation dans les grands centres de calcul internationaux devient fréquente. Dans ce cas, les GPGPU sont présents sur chaque nœud du cluster et servent à effectuer les calculs. Les CPU, quant à eux servent à charger en mémoire les programmes et les données et également à gérer les communications sur le réseau d’interconnexion. Architectures hybrides. Une architecture hétérogène, ou hybride apparaît comme évidente après la description des architectures précédentes. Il s’agit de réutiliser l’approche à mémoire partagée au sein de l’approche à mémoire distribuée. Cette architecture permet d’augmenter le nombre total de processeurs utilisés et de répartir les faiblesses sur plusieurs goulots d’étranglement au lieu d’un seul. Ce type d’architectures est devenu une référence et est très utilisé parmi les grappes les plus puissantes du monde. Les architectures hétérogènes peuvent être de type grappe/NUMA, grappe/multi-cœurs (ou plus généralement grappe/CPU), mais également grappe/GPU etc.2.1. Calcul parallèle : architectures et programmation 13 2.1.2 Paradigmes et modèles de parallélisation Avec l’apparition des architectures parallèles sont apparus les premiers problèmes de programmation parallèle. En effet, un programme séquentiel en lui même, et sans l’aide particulière du système d’exploitation ou de tout autre système externe de répartition de charge sur les cœurs ou les processeurs, n’exploite pas directement les ressources d’une machine parallèle. Or, la conception d’un programme parallèle peut s’avérer très complexe et très dépendante des architectures utilisées. Avec l’apparition des machines parallèles sont donc apparus également des paradigmes de programmation parallèle, offrant un ensemble d’approches générales pour envisager un programme parallèle, puis des modèles de programmation parallèle, permettant de concevoir de façon plus précise des programmes sur ces machines. Les paradigmes de programmation parallèle représentent donc un niveau d’abstraction plus bas et moins précis que les modèles de programmation parallèle. Les modèles de programmation parallèle, même si certains sont naturellement induits par le matériel, peuvent être implémentés pour différentes architectures parallèles. On distingue donc les modèles de programmation des implémentations qui y sont associées pour un modèle d’exécution donné. Par exemple un modèle de programmation parallèle initialement pensé pour des architectures à mémoire distribuée pourrait être implémenté sur une architecture DSM (Distributed Shared Memory) [79] qui permet de construire un espace mémoire partagé pour tous les processeurs, bien que cet espace mémoire soit physiquement distribué. Nous décrivons dans cette partie quelques uns des paradigmes et des modèles de programmation parallèle les plus utilisés et les plus connus. Nous ne décrirons en revanche pas leurs implémentations pour différents modèles d’exécution. 2.1.2.1 Paradigmes de programmation parallèle Taxinomie de Flynn. En 1972, Michael J. Flynn définit une classification des architectures des ordinateurs [54]. Quatre classes étaient alors répertoriées et sont représentées dans la table 2.1. La première classe, nommée Single Instruction, Single Data (SISD) représente les machines séquentielles n’exploitant aucun parallélisme. La deuxième classe, Singe Instruction, Multiple Data (SIMD), représente les machines pouvant appliquer une unique instruction à un ensemble de données. Cette classe concerne donc typiquement les architectures vectorielles ou GPU. La troisième classe, Multiple Instruction, Single Data (MISD), représente les machines permettant d’appliquer plusieurs instructions à la suite sur un même donnée d’entrée. Cette classe concerne typiquement les programmes de type pipeline ou les systèmes de tolérance aux pannes cherchant à comparer deux résultats issus d’une même donnée. Enfin, la quatrième classe, Multiple Instruction, Multiple Data (MIMD), représente les machines multiprocesseurs qui peuvent exécuter simultanément des instructions différentes sur des données différentes. Cette classification est toujours utilisée dans le parallélisme actuel, mais sous une autre forme. En effet, les différentes classes ne sont plus représentatives d’architectures matérielles particulières, la plupart des machines répondant à l’ensemble de ces classes. En revanche, les classes de Flynn représentent désormais des paradigmes de programmation14 Chapitre 2. Etat de l’art instruction unique instructions multiples donnée unique SISD MISD données multiples SIMD (SPMD) MIMD (MPMD) Table 2.1 – Taxinomie de Flynn parallèle, très souvent associés aux paradigmes de parallélisation de tâches et de données, que nous allons décrire. Parallélisme de tâches. Ce paradigme de programmation cherche à diviser un programme en un ensemble de tâches qui peuvent être dépendantes, mais aussi indépendantes. Dans ce cas c’est l’exécution du programme qui cherche à être parallélisée. Les paradigmes de parallélisation MISD et MIMD peuvent être associés au parallélisme de tâches. Dans le premier cas, des opérations successives sont appliquées sur un jeu de données d’entrée, on appelle communément ce type de calcul un pipeline. L’instruction i + 1 ne peut alors être exécutée qu’une fois l’instruction i terminée. Toutefois, sur des données d’entrées suffisamment nombreuses, le parallélisme peut apparaître en quinconce. En effet étant donné une donnée d’entrée [x1, . . . , xn], une fois x1 calculé pour l’instruction i, il est possible de calculer simultanément x2 pour l’instruction i et x1 pour l’instruction i + 1. Le paradigme MIMD, quant à lui, est rencontré plus fréquemment et offre plus de possibilités de parallélisation. Dans ce cas, on cherchera à identifier des tâches travaillant sur des données différentes, ce qui rend les tâches indépendantes les unes des autres. Toutefois, le développeur devra se charger de synchroniser les différentes tâches ensemble afin de garantir la cohérence des résultats. Nous pouvons enfin noter la paradigme MPMD (Multiple Program, Multiple Data), qui étend le concept MIMD à des programmes. Ainsi, chaque processeur peut appliquer un ou plusieurs programmes qui lui sont propres à des données éventuellement différentes des autres processeurs de façon indépendante. Les synchronisations nécessaires au bon fonctionnement du programme parallèle sont alors à la charge de l’utilisateur. Parallélisme de données. Dans ce paradigme, le parallélisme se focalise sur la façon dont les données sont distribuées sur les différents processeurs. L’ensemble des processeurs effectuent alors le même jeu d’instructions sur des données d’entrée qui leurs sont propres. Dans ce type de parallélisme les tâches effectuées par le programme sont peu modifiées. Il faut toutefois réflechir et consevoir les communications, les échanges ou les synchronisations nécessaires entre les processeurs pour que le programme parallèle soit correct et donne le même résultat qu’en séquentiel. Les paradigmes SIMD et SPMD (Simple Program, Multiple Data) sont associés au parallélisme de données. Ils représentent le même type de parallélisation, toutefois SIMD est associé aux architectures vectorielles et GPU, où la notion d’instruction est clairement définie et synchrone. L’approche SPMD est plus vaste et moins tournée vers la solution matérielle. Elle peut s’appliquer à des architectures à mémoire partagée comme distribuée. Ce paradigme considère une exécution indépendante d’un programme sur chaque processeur, et sur des données différentes,2.1. Calcul parallèle : architectures et programmation 15 et met à la charge du programmeur les synchronisations nécessaires à la cohérence du calcul général. Ce type de parallélisation est l’une des plus utilisée, notamment pour les architectures à mémoire distribuée. Paradigmes induits par le matériel. Nous abordons maintenant deux paradigmes de programmation parallèle connus et induits par le matériel, qui sont utilisés par la plupart des modèles présentés par la suite. Dans les architectures à mémoire partagée, les processus peuvent interagir par l’écriture et la lecture dans des espaces mémoire partagés et communs. Ces architectures permettent donc des interactions entre les processus par la simple utilisation de la mémoire de la machine, mais font intervenir des problèmes de concurrence d’accès aux données ainsi que de cohérence ou d’intégrité des données. Le paradigme de programmation parallèle le plus utilisé pour gérer ces problématiques, et que nous appelons paradigme à verrous, consiste à fournir des mécanismes permettant d’assurer l’exclusion temporaire de l’accès aux données pour en garantir l’intégrité. Le mécanisme le plus couramment utilisé se base sur des verrous d’exclusion mutuelle, appelés mutex. Un verrou sur une variable n’est attribué qu’à un unique processus, ce qui garantit qu’aucun autre processus ne pourra accéder ou écrire dans cette variable jusqu’à l’obtention, à son tour, d’un verrou. Pour ce qui est des architectures à mémoire distribuée, le paradigme le plus naturel, et parmi les plus utilisés, de passage de messages, est venu du simple constat que, dans ces architectures, les processus ne partagent pas d’espace d’adressage commun et qu’il est nécessaire d’échanger des messages pour que ces processus puissent communiquer entre eux. Ce paradigme n’introduit donc pas de problèmes de concurrence et d’intégrité des données, mais un problème de communication. Le niveau d’abstraction le plus bas pour mettre en place ce paradigme consiste à utiliser le réseau des machines et donc à faire, par exemple, appel à la programmation de sockets Unix, qui permettent l’envoi d’octets à destinations d’une adresse réseau spécifique. De nombreux modèles de programmation parallèle sont issus de ce paradigme. 2.1.2.2 Modèles de programmation parallèle Mémoire partagée. Les modèles de programmation induits des architectures à mé- moire partagée sont très souvent basés sur du parallélisme de tâches, mais peuvent également se baser sur du parallélisme de données. Le standard des threads POSIX (ou pthreads) [96] est l’un des modèles les plus répandus du parallélisme pour architectures à mémoire partagée. Ce modèle est basé sur le paradigme de verrous évoqués dans la partie précédente. Il permet de définir la création d’un nouveau processus léger (appelé un thread), dont l’exécution sera gérée par le système, en suivant une politique d’ordonnancement. A sa création, une tâche est assignée au thread et sera effectuée en parallèle du programme principal, qui pourra continuer son exécution. Un certain nombre de routines permettent ensuite des synchronisations entre les processus créés, et permettent de poser des verrous pour la modification de données. Le modèle de directives OpenMP [34], qui sera décrit avec précision dans la suite de cette thèse, est le deuxième modèle très utilisé sur les architectures à mémoire partagée. Il permet d’ajouter du multi-threading (le fait de créer plusieurs processus légers16 Chapitre 2. Etat de l’art pour certaines tâches du programme) dans du code C, C++ ou Fortran, par l’ajout de directives, sans modifications majeures du code, mais avec des résultats de performance limités. Ce modèle est principalement basé sur la parallélisation de boucles, ou sur le parallélisme de tâche dans lequel il est explicitement indiqué quels sont les différents travaux disponibles pour les threads. Il est également demandé à l’utilisateur de déclarer les variables locales et partagées du programme, afin de positionner automatiquement, par la suite, des exclusions mutuelles pour l’accès aux données partagées. Enfin, notons qu’il existe un modèle de programmation parallèle, nommé PGAS [6] (Partitioined Global Adress Space), basé sur le concept d’espace d’adressage mémoire global partitionné. Ce modèle propose une vision distribuée de la mémoire physiquement partagée par les threads. Ce modèle suggère donc la création d’un espace d’adressage virtuel partitionné global, auquel chaque thread a physiquement accès, mais dont les traitements sont partitionnés pour chaque thread. Ce modèle permet donc d’éviter, en grande partie, les problèmes de concurrence d’accès aux données, que l’on peut trouver dans tous les modèles basés sur le paradigme à verrous. Ce modèle de programmation est donc basé sur le paradigme de parallélisme de données, et s’implémente généralement par la parallélisation d’un traitement sur un tableau ou un conteneur. Notons enfin que, dans le modèle PGAS, le partitionnement proposé pour le traitement de données peut changer aucours de l’exécution du programme parallèle. Mémoire distribuée. Le modèle de programmation parallèle Message Passing Interface (MPI) [61] est basé sur la paradigme de passage de messages et définit un protocole de communication entre des processus indépendants et éventuellement distants. Ce modèle a initialement été défini pour les architectures à mémoire distribuée, toutefois il obtient également de très bonnes performances sur des architectures à mémoire partagée et à mémoire hybride distribuée/partagée. Ce modèle est composé de communications point-à-point, permettant de décrire l’envoi d’un message à un processeur précis, et de communications collectives, permettant d’envoyer des informations à l’ensemble ou à une sous-partie des autres processus. Notons que les communications point-à-point peuvent être bloquantes ou non bloquantes pour permettre certaines optimisations dans les programmes parallèles implémentés. Une communication non bloquante rendra la main avant que la communication ne soit terminée, à l’inverse d’une communication bloquante. Il est alors à la charge de l’utilisateur de s’assurer, aux endroits adéquats de son programme, que la communication est terminée. MPI contient également des interfaces permettant de créer des topologies entre les processus, de créer des types d’envois particuliers etc. Il existe plusieurs implémentations génériques de cette norme, comme Open MPI [56] ou MPICH2 [63], et il est de plus possible pour les constructeurs d’écrire leur propre implé- mentation afin de l’optimiser à leur matériel. C’est notamment le cas de Intel MPI [22]. Ce modèle (et ses implémentations) a connu un grand succès depuis sa création dans les années 90, et s’impose aujourd’hui comme l’un des outils de référence de la parallélisation, tout particulièrement dans le domaine du calcul scientifique et de la haute performance. Il est également important, pour la compréhension de cette thèse, de s’attarder sur l’un des modèles de programmation les plus connus et les plus anciens, le modèle Bulk2.1. Calcul parallèle : architectures et programmation 17 Synchronous Parallel [92, 118], proposé par Valiant en 1990. Le modèle architectural de BSP correspond naturellement à une machine à mémoire distribuée. En effet, dans ce modèle la machine modélisée est une machine à mémoire distribuée composée d’un ensemble de processeurs à mémoire indépendante. Toutefois, comme MPI, ce modèle peut tout à fait s’appliquer à une architecture à mémoire partagée. Les caractéristiques d’une machine BSP sont définies par quatre paramètres. Le premier, p, représente le nombre de processeurs sur la machine. Le deuxième, r, représente la puissance d’un processeur (mesurée en nombre d’opérations flottantes par seconde). L représente, quant à lui, le temps nécessaire pour effectuer une synchronisation globale entre tous les processeurs. Et pour finir, g représente le temps nécessaire pour l’envoi d’une donnée, du type souhaité, sur le réseau. L’élément de base d’un algorithme ou d’un programme BSP est appelé une super-étape (ou superstep). Un programme BSP est constitué d’une succession de super- étapes qui peuvent être composées (1) de plusieurs phases de calculs indépendantes, (2) de phases de communications, et (3) de phases de synchronisation entre les processeurs. On distingue plus généralement des super-étapes de calculs, dans lesquelles chaque processeur effectue une séquence d’opérations sur des données locales, et des super-étapes de communications, où chaque processeur envoie et reçoit des messages. Quelle que soit la représentation d’une super-étape, elle est toujours terminée par une synchronisation des processeurs. Dans cette phase de synchronisation chaque processeur vérifie que l’ensemble des tâches à accomplir sont terminées localement, et préviens les autres processeurs. Tous les processeurs attendent les messages de terminaison des autres processeurs avant que la super-étape ne se termine et qu’une autre puisse être commencée. Ce type de synchronisation est appelé bulk synchronisation. L’une des forces du modèle BSP est de proposer une fonction de coût calculée à partir des paramètres de la machine et de l’algorithme BSP formulé en super-étapes. Étant donné une super-étape de calcul s, on note ω (s) le temps d’exécution de la super-étape, qui est égal au temps maximum d’exécution, parmi tous les processeurs. Nous avons alors ω (s) = max 0≤i

0 représente le pourcentage de déséquilibre toléré, et en minimisant le nombre d’arêtes coupées dans ce partitionnement. Cette dernière métrique, qui vise à couper le moins d’arêtes possible lors du partitionnement, est aussi appelée la métrique edge-cut. Le partitionnement standard de graphe est notamment implémenté dans les partitionneurs Chaco [67], METIS [77] et Scotch [100]. La méthode standard de partitionnement de graphe a longtemps été la seule méthode utilisée. Toutefois ses limites ont été très largement évoquées et résumées dans les travaux de Hendrickson et Al [66]. La critique de cette approche repose sur deux faiblesses : la métrique edge-cut et le modèle en lui-même. Nous n’allons pas évoquer ici l’ensemble des faiblesses de la métrique et de la méthode de partitionnement, nous pouvons toutefois noter deux points que nous considérons comme importants, et qui sont résolus par la méthode de partitionnement d’hypergraphe décrite par la suite. La première faiblesse que nous souhaitons évoquer concerne la métrique edge-cut. Cette métrique dénombre les arêtes qui doivent être coupées suite au partitionnement mis en place. La limite de cette métrique vient du fait qu’elle n’est pas proportionnelle au volume de communication nécessaire dans un programme parallèle. En d’autres termes, cette métrique ne modélise pas correctement les communications pour la plupart des problèmes de partitionnement. Prenons un exemple afin d’illustrer cette caractéristique. Étant donné le graphe représenté dans la figure 2.9, partitionné en trois parties, une pour chaque processeur P0, P1 et P2. Étant donné que chaque arête e ∈ E représente un coût de communication c(e) = 1 + 1 = 2 (afin de représenter une communication symétrique), alors un partitionnement de graphe standard trouverait la métrique edge-cut comme égale à c(e)×5 = 10. Dans cet exemple, pourtant, nous pouvons observer que le sommet v2 est relié par deux arêtes à la partition du processeur P1, ce qui signifie qu’un unique2.3. Distribution de données 37 envoi de v2 est nécessaire dans l’implémentation. En procédant ainsi pour les sommets v5 et v8 nous trouvons que le véritable volume de communication est égal à 7. v1 v2 v3 v4 v8 v9 v6 v5 v7 P0 P1 P2 Figure 2.9 – Graphe donnant un exemple de partitionnement où la métrique edge-cut ne représente pas le volume de communication. La deuxième faiblesse que nous évoquerons ici est le fait que la méthode standard de partitionnement de graphe ne permet d’exprimer que des dépendances symétriques. Une arête représente, en effet, un envoi de données des deux sommets la constituant. Ainsi la méthode de partitionnement manque d’expressivité pour certains problèmes asymétriques. 2.3.1.2 Partitionnement d’hypergraphes Un hypergraphe H = (V, N ) est composé d’un ensemble de sommets, ou nœuds, noté V , et d’un ensemble N d’hyper-arêtes. Chaque hyper-arête est un sous-ensemble de V . Une hyper-arête est donc une généralisation de la notion d’arête dans un graphe, où plus de deux sommets de V peuvent être reliés entre eux. Dans le cas spécifique où chaque hyper-arête contient exactement deux sommets, on revient alors à la définition d’un graphe. Tout comme pour un graphe, tout sommet v ∈ V d’un hypergraphe peut être pondéré par ω(v), et chaque hyper-arête n ∈ N peut, elle aussi, être associée à un poids, ou un coût, que l’on note c(n). Ces poids sont généralement des réels positifs, mais dans cette thèse nous considérerons ces poids comme des entiers naturels. Étant donné un sous-ensemble S de V , ω(S) est défini comme la somme des poids de chacun des sommets de S. Le partitionnement p-way d’un hypergraphe H = (V, N ) est défini par p sousensembles de V , V0, . . . , Vp−1 tels que pour tout i ∈ J0, pJ, Vi ⊂ V , Vi 6= ∅, et tels que pour tout i, j ∈ J0, pJ, si i 6= j, alors Vi ∩ Vj = ∅. Le problème de partitionnement d’un hypergraphe est alors de trouver un partitionnement p-way qui satisfasse la38 Chapitre 2. Etat de l’art contrainte d’équilibrage (2.15), et qui minimise la métrique de coût suivante : X n∈N c(n)(λ(n) − 1), (2.16) où λ(n) est le nombre de parties connectées à une même hyper-arête n ∈ N , λ(n) = |{Vi : 0 ≤ i < p et Vi ∩ n 6= ∅}|. (2.17) Cette métrique, que l’on cherche à minimiser, est appelée la métrique-(λ − 1). Le premier modèle de partitionnement d’hypergraphe est apparu dans les travaux de Çatalyürek et Al [26] . Son efficacité pour modéliser certains problèmes de partitionnement a été démontrée [28]. L’avantage principal de ce modèle est sa capacité à représenter exactement le volume de communications, ce qui n’est pas le cas en utilisant la métrique edge-cut du modèle de partitionnement de graphe. Reprenons, par exemple, le graphe G = (V, E) de la figure 2.9, et construisons un hypergraphe H = (V, N ) où |N | = |V |. L’ensemble des hyper-arêtes N est défini de façon à ce que chaque sommet vi ∈ V corresponde à une hyper-arête hi ∈ N qui contient vi et l’ensemble de ses sommets voisins dans G. Par exemple, l’hyper-arête du sommet v2 contient alors les sommets v2, v8, v6 et v5. Cette hyper-arête contient donc des sommets des processeurs P2 et P1, son coût est donc de 2. Lors du partitionnement, on retrouve alors la métrique de coût de communication définie dans l’équation (2.16) qui est bien égale à 7 pour cet exemple. Pour finir, la méthode de partitionnement d’hypergraphe permet la représentation de problèmes asymétriques. 2.3.2 Cas particulier du partitionnement de matrices Le modèle de partitionnement d’hypergraphes a été utilisé dans de nombreux travaux afin de représenter les communications d’une multiplication de matrice creuse par un vecteur [28]. Ce traitement est l’un des plus courants dans les calculs scientifiques et a été très largement étudié. Un ensemble de méthodes de partitionnement, spécifiques à ce problème, a été élaboré. Un parallèle pouvant être fait de plusieurs façons entre un hypergraphe, ou un graphe, et une matrice creuse, les méthodes et les partitionneurs qui ont été développés pour ce type de traitements permettent également de résoudre d’autres problèmes de partitionnement. Dans cette thèse, le partitionneur Mondriaan [120], qui implémente plusieurs de ces techniques, est utilisé. Nous allons donc décrire, dans cette section, l’ensemble des modèles de partitionnement qui ont été mis en place pour le problème de multiplication matrice creuse-vecteur. Nous ne décrirons pas, en revanche, comment utiliser ces modèles sur la multiplication matrice creuse-vecteur en elle-même, puisque cette thèse ne s’intéresse pas particulièrement à ce problème. Ces détails peuvent être trouvés dans les travaux de Bisseling et Al [18]. 2.3.2.1 Partitionnement à une dimension Voyons une première façon de transformer une matrice vers un hypergraphe. Considé- rons une matrice creuse A de taille m×n. Notons alors ai,j ses coefficients avec i ∈ J1, mJ2.3. Distribution de données 39 et j ∈ J1, nJ. On peut alors considérer que chaque colonne j de la matrice A est repré- sentée par un sommet de l’hypergraphe avec un poids ω(j) égal au nombre de valeurs non nulles dans la colonne j. Considérons ensuite que chaque ligne i de la matrice A est représentée par une hyper-arête qui contient les sommets j pour lesquels ai,j 6= 0. Pour finir, considérons que le coût d’une hyper-arête est égal à 1. Cette représentation d’une matrice creuse A par un hypergraphe Hr est appelée le modèle row-net, qui signifie que les hyper-arêtes (net) représentent les lignes de la matrice (row). Dans ce cas un partitionnement p-way de l’hypergraphe Hr amène à un partitionnement à une dimension, ou 1D, de la matrice A. Ce partitionnement distribue donc les colonnes de la matrice A en p parties différentes. Chaque colonne étant pondérée par ω, le nombre de valeurs non nulles dans la colonne, le partitionnement de Hr distribue de façon équilibrée les valeurs non nulles de la matrice A en suivant la contrainte d’équilibrage définie dans l’équation (2.15). Pour finir, le volume de communications causé par la séparation d’une ligne de A dans plusieurs parties est minimisé par le fait qu’une ligne représente une hyper-arête et minimise donc la métrique-(λ − 1) représentée dans l’équation (2.16). Notons, pour terminer, qu’il est également possible de faire un partitionnement 1D de la matrice A par le modèle column-net qui, à l’inverse, associe les lignes de A aux sommets de l’hypergraphe Hc et les colonnes de A aux hyper-arêtes de Hc. 2.3.2.2 Partitionnements à deux dimensions Un partitionnement à deux dimensions, ou 2D, de la matrice A est également possible en procédant de plusieurs façons que nous allons décrire ici. Dans un partitionnement de matrice 2D, les colonnes comme les lignes de la matrice peuvent être découpées en plusieurs parties, ce qui implique des communications dans les deux directions. Le partitionnement 2D d’une matrice creuse a l’avantage de généraliser le problème, ce qui peut conduire à une solution plus intéressante avec un meilleur équilibrage ou moins de communications. Nous évoquerons ici quatre modèles principaux de partitionnement à deux dimensions. Méthode coarse-grain. Pour partitionner une matrice A, la méthode coarse-grain a la particularité d’essayer de conserver les rapprochements naturels des valeurs non nulles de la matrice par colonnes et par lignes, tout comme le fait un partitionnement 1D, mais en prenant en compte les deux dimensions. Il existe plusieurs types de méthodes dites coarse-grain. On peut, par exemple, noter le partitionnement cartésien, très utilisé pour le partitionnement de maillages cartésiens (nous reviendrons plus en détails dessus). Nous pouvons également évoquer l’approche Mondriaan [120] qui consiste à successivement partitionner en deux (ou bipartitionner) la matrice jusqu’à atteindre p parties. A chaque bipartitionnement, les méthodes row-net et column-net sont essayées, et celle proposant le meilleur partitionnement est conservée. Les deux hypergraphes Hr et Hc sont donc partitionnés à chaque itération. Ainsi, cette méthode effectue des partitionnements 1D mais qui peuvent être effectués dans les deux directions ce qui permet d’obtenir un partitionnement 2D et un plus grand nombre de solutions potentielles.40 Chapitre 2. Etat de l’art Méthode fine-grain. À l’inverse de la méthode coarse-grain, qui se base sur l’unité des lignes et des colonnes de la matrice, la méthode fine-grain [30] se propose de partitionner chaque valeur non-nulle de façon indépendante dans p partitions. Pour cela un nouveau type d’hypergraphe, noté Hf , est construit à partir de la matrice A. Chaque sommet de cet hypergraphe représente non plus les lignes ou les colonnes de la matrice, mais chaque élément non nul de la matrice. Deux types d’hyper-arêtes sont alors représentées. Une hyper-arête ligne i contient l’ensemble des sommets correspondants aux valeurs non nulles de la ligne i de A. Une hyper-arête colonne j, quant à elle, contient l’ensemble des sommets correspondants aux valeurs non nulles de la colonne j de A. Le nombre total de sommets dans l’hypergraphe Hf est égal au nombre de valeurs non nulles, et le nombre d’hyper-arêtes est au plus égal à m + n. Une fois cet hypergraphe construit, il peut être partitionné en p sous-ensembles de sommets en suivant la contrainte d’équilibrage (2.15) et en minimisant la métrique de coût (2.16). Méthode hybride. La méthode hybride [18] reprend le principe de l’approche Mondriaan par bipartitionnements successifs, mais en ajoutant aux partitionnements des hypergraphes Hr et Hc le partitionnement de l’hypergraphe Hf de la méthode fine-grain. Méthode medium-grain. La méthode medium-grain a récemment été proposée dans les travaux de Pelt et Al [101]. Cette méthode sépare tout d’abord la matrice A en deux matrices Ac et Ar . La valeur ai,j est ainsi assignée à la matrice Ar si le nombre de valeurs non nulles dans la ligne i est plus grand que dans la colonne j, et à Ac dans le cas contraire. La méthode crée alors une matrice : B =  In (Ar ) T Ac Im  , (2.18) où Im est la matrice identité de taille m × m, et In la matrice identité de taille n × n. La méthode de partitionnement 1D row-net est ensuite utilisée pour partitionner la matrice B. La matrice Ar étant transposée dans B, il s’agit là encore d’un partitionnement à deux dimensions, où la dimension de partitionnement, pour chaque valeur, est choisie en fonction de son attribution dans Ar ou Ac . 2.3.3 Cas particulier du partitionnement de maillages Cette thèse traite de solutions de parallélisme implicite pour le cas des simulations scientifiques dont la résolution est basée sur des maillages. Nous allons, dans cette partie, étudier le cas spécifique, et pratique, du partitionnement de maillages pour les applications parallèles. Nous allons, tout d’abord étudier l’état de l’art pour le cas des maillages réguliers à deux dimensions, puis nous traiterons le cas des maillages non-structurés. 2.3.3.1 Maillages à deux-dimensions réguliers Comme nous l’avons vu, un maillage régulier à deux dimensions peut être de deux types. Soit un maillage cartésien, soit un maillage curvilinéaire, mais qui peut alors être2.3. Distribution de données 41 ramené à un maillage cartésien. Un maillage cartésien est bien souvent représenté, dans les esprits, comme une matrice. Par conséquent un partitionnement fine-grain pourrait, par exemple, être envisagé pour partitionner les éléments non nuls de la matrice (tous les éléments dans le cas d’une matrice dense). Un maillage cartésien étant dense, des mé- thodes plus directes, et plus simples à mettre en œuvre, permettent d’obtenir rapidement des partitionnements équilibrés et contenant peu de communications. Notons par exemple le partitionnement rectiligne [97], qui est obtenu en partitionnant tout d’abord les lignes du maillage en P parties, puis les colonnes en Q parties, tel que p = P Q. On peut ensuite assigner chaque combinaison obtenue à chaque processeur. Une variante de ce partitionnement est d’utiliser la même technique mais suivant une unique dimension. On pourra aussi appeler le partitionnement rectiligne 2D, le partitionnement par blocs, et le partitionnement rectiligne 1D, le partitionnement par blocs-lignes. Dans certains cas, un maillage cartésien peut être non-uniforme. C’est le cas des maillages dits adaptatifs. Ce type de maillage peut être intéressant pour résoudre des EDP, puisqu’il permet d’adapter le maillage avec plus ou moins de précision (de points) suivant les zones d’intérêt du domaine. Dans ce cas, il peut être à la fois plus compliqué d’équilibrer le partitionnement, mais aussi de minimiser les communications. Les travaux de Berger et Al [13] ont introduit en 1987 le partitionnement par bissection ré- cursive orthogonale (ORB) pour ce type de maillages. La figure 2.10 représente les trois partitionnements de maillages 2D introduits ici. Figure 2.10 – De gauche à droite : partitionnement en blocs, en blocs-lignes et bissection récursive orthogonale 2.3.3.2 Maillages non-structurés Nous venons de voir que le partitionnement des maillages réguliers est un cas de partitionnement relativement simple et pour lequel un grand nombre de possibilités de résolution est disponible. Certains maillages sont eux beaucoup plus compliqués à partitionner de par leur structure irrégulière. La méthode des éléments finis, que nous avons décrite dans la partie 2.2.4.3, mène dans la plupart des cas à la création d’un maillage non-structuré qui permet de représenter avec fidélité et avec plus ou moins de précision la surface ou le volume d’un objet. La plupart du temps les cellules de ces maillages représentent des triangles (2D) ou des tétraèdres (3D), ce qui permet, suivant la taille des mailles, de pouvoir représenter très précisément les surfaces ou les volumes. Une maille42 Chapitre 2. Etat de l’art peut avoir une taille quelconque et peut être un triangle de forme quelconque dans l’espace. Le voisinage y est donc régulier, dans le sens où toutes les cellules ont par exemple trois cellules voisines (dans le cas de triangles), mais les structures de données permettant de représenter un maillage non structuré sont elles plus complexes et plus lourdes que dans un maillage cartésien. Par conséquent, là où un maillage cartésien peut facilement être identifié à une matrice, le maillage non-structuré est lui plus facilement représenté par un graphe. Le problème de partitionnement d’un maillage non-structuré repose donc sur le fait de trouver la bonne représentation du maillage en graphe pour ensuite pouvoir le partitionner. Quatre représentations sont très souvent utilisées dans la littérature : — La première, et la plus simple, est de considérer chaque point du maillage comme un sommet d’un graphe, et chaque arête d’une face du maillage comme une arête du graphe. Cette représentation est appelée le graphe nodal du maillage [122]. — La deuxième représentation, appelée le graphe dual du maillage [46, 106], associe chaque cellule du maillage à un sommet du graphe. Deux sommets du graphe sont reliés par une arête si deux cellules du maillage ont un côté, ou une face, en commun. — La troisième représentation combine le graphe nodal et le graphe dual afin d’obtenir une représentation plus précise sur le maillage [122]. — Enfin, le graphe dual-diagonal représente chaque cellule du maillage par un sommet, et deux sommets sont reliés par une arête si les cellules ont un point en commun dans le maillage. Notons que cette représentation peut elle aussi être combinée au graphe dual pour représenter avec plus de précision le maillage. La figure 2.11 illustre le graphe nodal, le graphe dual et le graphe dual-diagonal d’un maillage non structuré 2D. Une fois que la représentation du maillage par un graphe Figure 2.11 – De gauche à droite et de haut en bas : le maillage non structuré 2D, son graphe nodal, son graphe dual et son graphe dual-diagonal.2.3. Distribution de données 43 est choisie, les partitionneurs de graphes peuvent être utilisés, comme par exemple Jostle [122], Metis [46, 106] et Scotch [100, 106]. Dans les travaux de Zhou et Al [131], le partitionnement d’hypergraphe est utilisé pour partitionner un maillage non-structuré 3D contenant 1.07 milliard de cellules, 163840 processeurs. Le maillage y est représenté par un hypergraphe dans lequel chaque sommet est associé à une cellule du maillage, et chaque hyper-arête correspond à une cellule et aux cellules partageant une face avec celle-ci. Le partitionneur Zoltan [27] est ensuite utilisé. Il est donc également possible d’utiliser le modèle de partitionnement d’hypergraphes pour partitionner un maillage non-structuré et représenter plus fidèlement le volume de communications. 2.3.4 Partitionnements particuliers 2.3.4.1 Méthodes à contraintes et objectifs multiples Considérons un problème de partitionnement d’hypergraphe, ou de graphe, défini comme dans les parties précédentes. On peut alors appeler la contrainte d’équilibrage de l’équation (2.15) la contrainte du partitionnement, et la minimisation des métriques (λ − 1) de l’équation (2.16), ou edge-cut, l’objectif du partitionnement. Un partitionnement à contraintes multiples [9, 108] consiste alors à appliquer un tableau de poids à chaque sommet de l’hypergraphe ou du graphe au lieu d’un simple poids. Ce tableau représente les multiples contraintes d’équilibrage à respecter lors du partitionnement. De même un partitionnement à objectifs multiples [58] appliquera un ensemble de coûts de communications à une hyper-arête de l’hypergraphe, ou à une arête du graphe. Pour effectuer un partitionnement à contraintes multiples, Aykanat et Al [108] ont modifié l’algorithme multilevel dans ses trois phases. En effet, les phases de réduction, de bi-partitionnement et de raffinement ont été modifiées pour tenir compte de plusieurs contraintes de partitionnement. Dans les travaux de Schloegel et Al [58], l’algorithme de partitionnement pour objectifs multiples s’effectue en trois phases. Tout d’abord un algorithme de partitionnement k-way du partitionneur METIS [77] est appliqué pour chacun des objectifs séparément. Un nouveau poids est ensuite attribué à chaque arête du graphe initial. Ce poids est calculé comme une fonction des différents poids de l’arête (objectifs multiples), du meilleur résultat de la métrique edge-cut obtenu dans la première phase, et du vecteur de préférence des objectifs précisé par l’utilisateur. Enfin, un dernier partitionnement k-way est opéré sur le graphe avec les nouvelles pondérations d’arêtes. 2.3.4.2 Méthode pour les calculs à phases Certains calculs scientifiques ou simulations ont la particularité d’être organisés en plusieurs phases. Cette organisation peut être de plusieurs types dans une simulation. Tout d’abord, il est possible qu’il s’agisse de différentes phases de calcul, mais toutes exécutées sur l’ensemble du maillage. Dans ce cas, les différentes phases peuvent avoir un impact sur le type de communications et il est alors possible d’utiliser des partitionnements à contraintes ou objectifs multiples. Il est également possible que les différentes44 Chapitre 2. Etat de l’art phases du calcul soient exécutées sur des maillages différents, soit complètement distincts les uns des autres, soit reliés entre eux par une composition de maillages (section 2.2.2.2). Nous traitons plus en détails ce cas dans la section 5.5 de cette thèse. Enfin, il est également possible que les différentes phases d’un calcul agissent sur différentes parties d’un même maillage. Dans ce cas une contrainte d’ordonnancement apparaît à la fois sur les calculs, mais aussi sur le maillage. Les travaux de Walshaw et Al [125] traitent de ce type de calculs à phases. Dans ces travaux de partitionnement, les sommets du graphe vont être classifiés afin de déterminer la phase qui les concerne. Le premier sous-ensemble de sommets est alors partitionné, puis les sous-ensembles suivants seront partitionnés à leur tour en tenant compte des partitionnements précédents, grâce à la notion de point stationnaire introduite dans ces travaux. Notons que la méthode est également capable de traiter des sommets qui appartiennent à plusieurs phases du calcul. Le problème de partitionnement de graphes est un problème qui a largement été étudié et dont quelques représentations ont étés présentées dans cette section. Nous utiliserons, dans le chapitre 5 plus spécifiquement, certaines de ces notions afin de présenter le problème de partitionnement de réseaux, et deux méthodes de résolution. 2.4 Le parallélisme implicite Nous allons désormais aborder le cœur de cette thèse : le parallélisme implicite. Derrière ce terme se cache le fait de vouloir apporter un accès facile, simplifié, voire transparent, au calcul haute performance et au parallélisme à des utilisateurs non spécialistes, et même non-informaticiens. En effet, si la plupart des scientifiques ont de plus en plus besoin des machines parallèles pour obtenir des simulations intéressantes, ils ne savent pas pour autant les utiliser à leur pleine capacité, soit par manque de temps et de ressources humaines, soit par manque de connaissances sur les architectures matérielles utilisées. De nombreux travaux sur le parallélisme implicite ont vu le jour presque simultanément avec l’arrivée d’architectures parallèles, complexes à programmer. Ce domaine de recherche est très actif et le sera probablement de plus en plus étant donné la complexité des architectures parallèles actuelles et à venir (hiérarchie de mémoires complexes, systèmes massivement multi-cœurs, systèmes hybrides etc.). Nous allons présenter, dans cet état de l’art, un aperçu des solutions les plus utilisées et les plus reconnues du parallélisme implicite. Pour cela, nous allons tout d’abord présenter des solutions permettant de classifier les problèmes parallèles, nous évoquerons ensuite quelques-uns des nombreux langages et des nombreuses bibliothèques de parallélisme partiellement implicites. Enfin nous entrerons à proprement parlé dans les solutions de parallélisme implicite totale, que nous essaierons de classer par niveau d’abstraction, le niveau d’abstraction le plus haut (qui ne correspond pas nécessairement au meilleur niveau d’abstraction, et c’est l’une des discussions de cette thèse) étant celui qui cache le plus de technicités et qui demande le moins d’apprentissage à l’utilisateur. Ainsi nous évoquerons les bibliothèques de parallélisme implicite générales, les solutions à patrons, puis pour terminer les solutions spécifiques au domaine du calcul scientifique.2.4. Le parallélisme implicite 45 2.4.1 Classification de problèmes et aide à la parallélisation Le niveau d’abstraction le plus bas du parallélisme est de considérer qu’il est préférable de laisser les utilisateurs coder leurs propres programmes parallèles, mais de les aider dans la conception de ces programmes. Les modèles de programmation tels que BSP [92, 119] ou MPI [61], ainsi que le paradigme SPMD, décrits précédemment, sont des exemples de solutions permettant de simplifier le parallélisme et proposent un niveau d’abstraction plus haut que la programmation parallèle de base. En effet, pour certains types d’architectures parallèles et pour certains types de problèmes, ces modèles de programmation parallèle peuvent être utilisés relativement facilement. Il est d’ailleurs fréquent d’initier les scientifiques à la programmation parallèle par ce type de modèles [17, 87]. Toutefois, lorsque les algorithmes deviennent plus compliqués à mettre en œuvre, comme par exemple dans le cas de problèmes irréguliers, les modèles les plus simples sont souvent limités, et une réflexion différente sur la conception du programme parallèle est souvent nécessaire. Les travaux de Pingali et Al [103] proposent une classification des algorithmes afin de mieux identifier la façon dont ils peuvent être parallélisés effi- cacement. Il a ainsi été proposé The TAO of Parallelism in Algorithms, qui peut être vu comme une abstraction des algorithmes. Cette abstraction permet, d’une part, d’extraire les propriétés importantes pour la parallélisation du problème et, d’autre part, de mettre de côté les propriétés n’entrant pas en compte dans les choix de parallélisation. Dans l’analyse-TAO, la définition d’un algorithme est inspirée de l’aphorisme de Niklaus Wirth [129] : Program = Algorithm + Data structure. L’abstraction proposée par l’analyse-TAO est appelée operator formulation of algorithms. L’algorithme y est traduit comme un graphe représentant les opérations effectuées sur des types de données abstraits, noté graphe ADT. L’analyse-TAO se décompose en trois étapes. Tout d’abord la définition de la topologie, qui représente la structure de données sur laquelle les calculs sont effectués, puis les nœuds actifs, qui représentent les éléments à calculer dans une opération donnée, et enfin les opérateurs, qui représentent les actions à effectuer sur les nœuds actifs. Une simulation scientifique pour laquelle des schémas numériques explicites sont appliqués sur un maillage fixe (à l’inverse d’un maillage adaptatif) est définie comme suit, dans l’analyse-TAO : — Topologie : La topologie nécessaire dépend du type de maillage utilisé. Elle peut être structurée, comme par exemple pour des maillages cartésiens, ou nonstructurée, pour les maillages du même nom. — Nœuds actifs : Dans l’analyse-TAO, l’algorithme d’une simulation scientifique est appelé topology-driven. Cela signifie que l’ensemble des éléments du maillage sont calculés à chaque itération de temps. De plus, si les schémas numériques à calculer sont explicites, leurs calculs ne dépendent que de l’itération précédente et les éléments du maillage peuvent donc être calculés de façon non-ordonnée. — Opérateurs : Les opérations mises en place dans une simulation scientifique repré- sentent les calculs des schémas numériques. Dans le cas d’un maillage non adaptatif, ou fixé, la morphologie du maillage n’est pas modifiée au cours de l’algorithme. L’analyse-TAO appelle ce type de simulation un calcul local (local computation).46 Chapitre 2. Etat de l’art Notons que dans le cas d’une simulation utilisant des schémas numériques implicites, l’algorithme est appelé data-driven, ce qui signifie que les calculs de certains éléments du maillage peuvent rendre calculables d’autres éléments. Enfin, dans le cas d’un maillage adaptatif, les opérateurs sont de type morph, ce qui signifie que le maillage peut être modifié à chaque itération de temps de la simulation. Ce premier niveau d’abstraction vise à simplifier la classification des algorithmes parallèles et permet donc d’obtenir une première approche simplifiée du parallélisme et du calcul haute performance. Toutefois, il ne résout pas le fait que l’utilisateur ne connaît pas suffisamment les architectures et les détails techniques de la programmation parallèle pour écrire des programmes parallèles. Ces modèles de programmation et ces classifications sont, en revanche, très utilisés afin d’élaborer des solutions de parallélisme implicite d’un niveau d’abstraction plus élevé. 2.4.2 Solutions partiellement implicites Il existe un très grand nombre de bibliothèques et de langages permettant de simplifier l’utilisation des machines parallèles, et donc d’écrire des programmes pour ces machines. Toutefois, ces solutions proposent un parallélisme qui n’est que partiellement implicite, laissant à l’utilisateur la charge de quelques notions parallèles, qui peuvent paraître, pour certaines, simples sur de petits programmes, mais qui peuvent s’avérer très compliquées pour des calculs eux-mêmes complexes. Les niveaux de parallélisme implicite proposés sont très variés et nous allons évoquer ici quelques unes de ces solutions. À un niveau d’abstraction relativement bas, on peut tout d’abord noter les langages ou interfaces de programmations à base de directives. Citons deux de ces solutions, High Performance Fortran [93] (HPF) et OpenMP [34]. Les langages de directives, et particulièrement HPF ont été largement critiqués, et notamment accusés de rejeter certains détails du parallélisme, potentiellement très techniques, sur l’utilisateur. En effet, HPF demande, par exemple, à l’utilisateur de préciser les alignements des données entre elles, ce qui garantit leur placement sur un même processeur. De même, HPF demande à l’utilisateur de préciser des directives de distribution de données (en bloc, ou de façon cyclique élément par élément, par exemple). OpenMP, de son côté, a réussi à devenir une réfé- rence pour paralléliser facilement, mais pas nécessairement efficacement, des applications sur architectures à mémoire partagée. Rappelons que si OpenMP est initialement un modèle de programmation induit par et fait pour les architectures à mémoire partagée, son implémentation peut être effectuée sur différents modèles d’exécution et notamment pour des architectures à mémoire distribuée, en utilisant, par exemple, une architecture DSM [79]. Bien que ses performances soient limitées, OpenMP est très utilisé dans les calculs scientifiques. Les directives OpenMP sont, en effet, peu nombreuses et moins techniques que celles proposées par HPF. Deux types de parallélisation sont possibles en utilisant OpenMP. La plus simple, et la plus connue des scientifiques, est la méthode dite fine-grain, ou à grain fin. Elle consiste en la parallélisation automatique de boucles for. L’unique difficulté pour l’utilisateur est alors de détecter quelles variables sont locales à la boucle et quelles variables doivent être partagées par les différents processus2.4. Le parallélisme implicite 47 créés automatiquement. Toutefois, il n’est pas rare que cette parallélisation de boucle, très limitée, ne soit pas suffisante pour obtenir des performances intéressantes, et même parfois acceptables, dans les calculs scientifiques. Le deuxième type de programmation OpenMP est alors utilisé et s’appelle coarse-grain, ou à gros grain. Dans ce cas, on peut noter deux types de solutions. Dans la première l’utilisateur a la charge de définir une zone de code parallèle, en utilisant la directive #pragma omp parallel, où l’ensemble des processus, créés automatiquement, exécuteront la même portion de code. L’utilisateur devra également définir les variables locales et partagées, et on retrouve dans ce type de parallélisation des problèmes de décomposition de domaine. Cette solution coarse-grain peut donc s’apparenter au parallélisme de données. Le deuxième type de programmation coarse-grain qui peut être envisagé est la définition par l’utilisateur de sections pouvant directement être assignées à des processus différents. La directive est alors #pragma omp parallel sections. Dans ce cas l’utilisateur doit identifier des tâches pouvant être effectuées en parallèle par plusieurs processus, cette solution s’apparente donc au parallélisme de tâches. L’utilisation des méthodes coarse-grain, permet souvent d’obtenir de meilleures performances, toutefois le niveau d’abstraction proposé est plus bas, et le parallélisme peu implicite, tout comme dans l’utilisation de HPF. Les langages BSPLib [69] et Co-array Fortan [98] peuvent ensuite être évoqués. Là encore, il ne s’agit pas d’un parallélisme implicite total, toutefois la programmation parallèle y est simplifiée par un nombre de concepts limités et par l’utilisation d’un modèle de programmation proche de BSP. Ces langages permettent notamment de simplifier le paradigme à passage de messages, proposé par exemple par MPI [61]. BSPLib, par exemple, ne demande à l’utilisateur que d’expliciter les envois de données et les synchronisations. Le reste du travail est effectué directement par la bibliothèque grâce au modèle de programmation BSP. ZPL [32] est un langage parallèle basé sur la définition et l’utilisation de tableaux. Il est, pour cette raison, notamment très adapté aux calculs matriciels. La distribution des tableaux est effectuée automatiquement lors de l’exécution, et les programmes implémentés suivent le paradigme SPMD. Si HPF, Co-array, BSPLib et ZPL, par exemple, sont des langages proches du paradigme SPMD, ce qui signifie que chaque thread exécute le même code sur des données différentes, les langages X10 [35] et Chapel [31] proposent, quant à eux, un modèle plus général permettant de contrôler un ensemble d’opérations concurrentes. Notons enfin que les langages Co-array et X10, parmi d’autres langages, utilisent le modèle de programmation parallèle PGAS (Partitioned Global Adress Space) [6], déjà évoqué dans la partie 2.1.2.2. 2.4.3 Solutions générales de parallélisme implicite Le niveau d’abstraction suivant permet, lui, de cacher de façon beaucoup plus prononcée le parallélisme aux utilisateurs. Nous évoquons ici les solutions de parallélisme implicite, que l’on qualifie de générales, à l’inverse des solutions spécifiques que nous évoquerons par la suite. Il s’agit à proprement parlé, de solutions de parallélisme implicite totales. Afin de comprendre cette classe de solutions, nous allons prendre l’exemple de la librairie standard template [95] du C++ (STL). Cette bibliothèque, très générale, per-48 Chapitre 2. Etat de l’art met d’instancier et d’utiliser des conteneurs, comme par exemple des vecteurs, des listes, des dictionnaires etc., et même de les imbriquer entre eux. Un ensemble d’algorithmes peuvent ensuite être appliqués sur ces conteneurs, mais il est également possible d’écrire ses propres programmes au moyen d’un outil principal : l’itérateur. L’itérateur permet, en effet, de se déplacer dans un conteneur, mais aussi d’accéder aux valeurs qui y sont associées. La STL permet d’écrire de façon simplifiée des programmes en C++. En un sens donc, la STL est une solution de “conteneurs implicites”, qui permet de cacher la complexité de gestion de conteneurs en C++ et de faciliter leur utilisation. Nous évoquons, par le terme bibliothèques de parallélisme implicite générales, des bibliothèques équivalentes à la STL mais qui permettent d’écrire des programmes parallèles. Il s’agit donc de solutions permettant de mettre en place le paradigme de parallélisme de données, ou SPMD, par la parallélisation des conteneurs et de leur manipulation. Dans ce cas, les programmes écrits sont très généraux et touchent potentiellement un très grand nombre de domaines scientifiques. Certaines de ces bibliothèques sont plus spécifiquement décrites ici. Bibliothèques sur conteneurs généraux. STAPL [25] signifie Standard Template Adaptative Parallel Library et il s’agit d’une version parallèle de la STL, que nous venons de décrire. Cette bibliothèque emprunte donc un certain nombre de concepts de la STL, et son but est d’offrir autant, ou plus, de possibilités de codage que la STL, tout en produisant des programmes parallèles. STAPL est composée de deux composants principaux, le premier est le concept de pContainer qui représente une structure de données distribuée représentant un conteneur distribué (tableau [113], liste [115], etc.). Le deuxième concept, pAlgorithm, représente, quant à lui, un algorithme à appliquer sur un pContainer. Il est possible dans STAPL, comme dans la STL, d’imbriquer des pContainers et donc d’imbriquer également des appels à des pAlgorithms. Le niveau d’abstraction proposé par STAPL est illustré par le concept de pView [24], qui représente une géné- ralisation du concept d’itérateur. Le concept pView permet le parallélisme via un accès, d’ordre inconnu, à l’ensemble des éléments d’un conteneur. Enfin, le STAPL parallel container framework [114] permet d’écrire de nouveaux pContainers de façon simplifiée. Notons également la bibliothèque PSTL [64], dont les buts sont proches de STAPL. PSTL est une version parallèle de la STL, mais cette bibliothèque cherche à rester compatible avec la STL là où STAPL propose de nouveaux conteneurs qui n’existent pas dans la STL comme les matrices (pMatrix ) et les graphes (pGraph). La bibliothèque Threading Building Blocks (TBB) [105] implémente, elle aussi, certains concepts équivalents à la bibliothèque STAPL mais ne vise initialement que les architectures à mémoire partagée (bien qu’une implémentation utilisant une architecture DSM puisse là encore être envisagée). STAPL, de son côté, fonctionne de base à la fois pour les architectures à mémoire partagée et distribuée. Enfin, Thrust [70] est une bibliothèque proposant elle aussi un équivalent de la STL en parallèle pour des architectures GPU et hybrides CPU-GPU. Bibliothèques sur graphes. Si les bibliothèques STAPL, PSTL et TBB se veulent généralistes pour tout type de conteneurs, certaines bibliothèques, elles aussi basées sur2.4. Le parallélisme implicite 49 des conteneurs et des algorithmes, se concentrent sur les graphes, ce qui représente un problème difficile à gérer en lui-même. Parallel Boost Graph Library (PBGL) [62] est une bibliothèque parallèle générale sur les graphes. PBGL est une version parallélisée de BGL (Boost Graph Library) [1], et reste entièrement compatible avec cette version séquentielle. BGL et PBGL sont des bibliothèques implémentées dans l’ensemble de bibliothèques Boost [3]. Elles en héritent donc les forts concepts de généricité et d’efficacité. BGL, et donc PBGL, sont des bibliothèques C++ génériques visant à pouvoir exprimer un maximum de problèmes, tout en proposant une implémentation efficace. Leur implé- mentation est, pour cela, basée sur les concepts avancés de méta-programmation [3] et de spécialisation de template [5]. Il en résulte, pour des scientifiques non-informaticiens, une programmation techniquement difficile à comprendre, d’autant plus que certains paramètres de spécialisation, permettant de rendre la solution plus efficace, sont loin des préoccupations des scientifiques, comme par exemple des informations sur le type de représentation du graphe souhaité, ou sur la distribution à effectuer pour le parallélisme. En souhaitant être une bibliothèque générale à tous les problèmes de graphes, elle restreint son utilisation à des utilisateurs avancés du C++ (bien qu’aucun code parallèle ne soit demandé à l’utilisateur). La bibliothèque CGMGraph [33] implémente, tout comme PBGL, un certain nombre d’algorithmes sur les graphes, comme par exemple les composantes connexes, les arbres couvrants etc. Toutefois, le paradigme de programmation des deux méthodes est différent. CGMGraph est une bibliothèque orientée objet alors que PBGL est orientée programmation générique. Il peut sembler que ce niveau d’abstraction est idéal. En effet, étant très général, il touche l’intégralité du monde scientifique et permet d’écrire des programmes parallèles en cachant potentiellement intégralement les détails du parallélisme. Cependant, de par la généralité de ces solutions, il est difficile de proposer des optimisations spécifiques à un domaine. Ces solutions peuvent être performantes mais ne peuvent être à la hauteur d’un parallélisme manuel et optimisé pour un problème spécifique de simulation scientifique. De plus, le souhait de généricité de ces solutions, et leurs paramétrages parfois complexes, peut être à l’origine de nouvelles difficultés pour l’utilisateur. Une généricité trop faible, à l’inverse, peut nuire aux performances de la solution. 2.4.4 Solutions à patrons Les bibliothèques de parallélisme implicite générales, comme nous venons de le voir, cherchent à cacher le parallélisme par le biais de conteneurs, d’algorithmes et d’itérateurs (tableaux 1D, 2D, graphes etc.). Nous allons maintenant aborder des solutions proposant un niveau d’absrtaction que nous considérons plus haut puisque davantage de détails sont cachés à l’utilisateur. Ces solutions sont, elles aussi, basées sur des structures de données implicitement distribuées, mais proposent, de plus, d’identifier les opérations effectuées dans un programme comme un ensemble de patrons de programmation (ou patterns). Ces patterns seront ensuite responsables de la parallélisation implicite des opérations séquentielles du code de l’utilisateur. Les patrons proposent un haut niveau d’abstraction. Par exemple, ce type de solutions cache généralement la navigation dans50 Chapitre 2. Etat de l’art les structures de données, la notion d’itérateur n’est alors plus nécessaire. Nous allons décrire ici deux grandes familles de solutions à patrons. Tout d’abord, le domaine des squelettes algorithmiques sera décrit et quelques unes des nombreuses bibliothèques de ce domaine seront étudiées. Puis, quelques autres solutions à patrons seront décrites. 2.4.4.1 Squelettes algorithmiques. Les squelettes algorithmiques parallèles ont été introduits en 1988 par Muray Cole [40]. Ils représentent des patrons de parallélisation fonctionnels, en d’autres termes des abstractions de schémas de parallélisme, que l’on retrouve de façon récurrente dans les applications parallèles. Ainsi, en théorie, n’importe quel programme parallèle peut s’exprimer comme une suite ou une imbrication de squelettes algorithmiques fonctionnels. Aucune norme n’a été définie pour écrire des squelettes, ni même aucun consensus. Toutefois, le travail de Cole [39] indique quelques règles de conception pour produire des squelettes adaptés et donc plus utilisés. Un squelette a idéalement un champ d’application le plus large possible, afin de pouvoir être utilisé dans un grand nombre de cas, sa sémantique doit être compréhensible des utilisateurs, et enfin il ne doit pas être redondant avec d’autres squelettes. Les squelettes algorithmiques se découpent en trois grandes classes, les squelettes pour le parallélisme de données (map, reduce, zip etc.), les squelettes pour le parallélisme de tâches (farm, pipeline etc.), et enfin les squelettes dits de résolution (divide and conquer, branch and bound). Des détails sur l’ensemble de ces squelettes peuvent être trouvés dans la thèse de Legaux [84]. Nous n’allons ici décrire que quelques squelettes pour le parallélisme de données, auxquels nous feront référence dans cette thèse. Nous pouvons, tout d’abord, noter les trois squelettes de base les plus connus et les plus simples à comprendre. Le premier s’appelle map et permet d’appliquer une fonction locale à un ensemble de données d’entrée en parallèle. Une fonction locale est alors une fonction dont le calcul ne dépend que d’un élément d’entrée sans aucune dépendance avec les autres éléments. Le squelette peut alors distribuer la structure de données et appliquer la fonction à chacun des éléments séparément. Le squelette prend alors un vecteur de données d’entrée [x1, x2, . . . , xn], retourne un vecteur de données de sortie [y1, y2, . . . , yn] et applique une fonction f telle que map f [x1, x2, . . . , xn] = [f(x1), f(x2), . . . , f(xn)] = [y1, y2, . . . , yn]. Le second squelette de base est le squelette zip qui est une extension de map pour deux vecteurs d’entrée. Il distribue deux vecteurs de données d’entrée [x1, x2, . . . , xn] et [x 0 1 , x0 2 , . . . , x0 n ], de même taille, et retourne un nouvel vecteur de sortie [y1, y2, . . . , yn] en appliquant une fonction f telle que zip f ([x1, x2, . . . , xn], [x 0 1 , x0 2 , . . . , x0 n ]) = [f(x1, x0 1 ), f(x2, x0 2 ), . . . , f(xn, x0 n )] = [y1, y2, . . . , yn]. Enfin, le squelette reduce permet de réduire un vecteur de données d’entrée [x1, x2, . . . , xn] en un unique élément e suite à l’appel d’une opération de réduction, que nous noterons2.4. Le parallélisme implicite 51 ⊕, telle que reduce ⊕ [x1, x2, . . . , xn] = x1 ⊕ x2 ⊕ . . . ⊕ xn = e. Les squelettes map et zip sont des squelettes qui ne peuvent appliquer que des calculs locaux, de par leur construction. En d’autres termes, il n’est pas possible avec uniquement ces squelettes d’effectuer des calculs de type stencil. La fonction décrite par l’utilisateur ne décrit, en effet, que l’opération à effectuer sur un élément de l’ensemble de départ. Un calcul stencil dépendant d’un certain voisinage de l’élément courant, il est nécessaire de faire appel au squelette shift. Ce squelette va prendre un vecteur d’entrée [x1, x2, . . . , xn], et retourner un vecteur de sortie [y1, y2, . . . , yn] égal à l’ensemble d’entrée décalé (le décalage appliqué étant précisé par l’utilisateur). Par exemple, pour un décalage de un élément vers la droite nous obtiendront [y1, y2, . . . , yn] = [×, x1, x2, . . . , xn−1]. De cette manière en accédant au deuxième élément des ensembles [x1, x2, . . . , xn] et [×, x1, x2, . . . , xn−1], il est possible de faire des opérations sur x2 et x1 en même temps. Avec ces quatre squelettes de base, on peut très facilement observer les limites de l’approche par squelettes pour des simulations scientifiques complexes. Pour cette raison, des squelettes de type stencil sont apparus, notamment dans la bibliothèque SkelCL [21,111]. Cette bibliothèque implémente des squelettes de base pour les GPU et multi-GPU en utilisant le langage OpenCL [112]. Il s’agit donc également d’un code portable. Elle propose un squelette de stencil simple nommé MapOverlap qui permet de décrire une opération de stencil simple, et un squelette de stencil plus complexe, nommé Stencil permettant notamment de décrire des opérations stencil itératives. Afin de pouvoir effectuer les calculs de type stencil, une distribution contenant des éléments fantômes est mise en place dans la bibliothèque de squelettes, et n’existe pas dans les autres solutions. De plus, les échanges à effectuer entre les processeurs sont automatiquement détectés par les arguments utilisés dans le stencil. Notons que SkelCL ne fonctionne que pour les structures de données de type vecteur ou matrices. Parmi les bibliothèques de squelettes permettant de faire du parallélisme de données et écrites en C++, on peut noter OSL [72], SkeTo [76], SkePu [52], et Muesli [37], chacune ayant ses propres particularités. SkeTo, par exemple, est la seule bibliothèque proposant une solution de squelettes sur les arbres [90]. SkePu propose une implémentation GPU, et Muesli une implémentation hybride MPI/OpenMP des squelettes algorithmiques de base. Enfin, OSL propose des optimisations à base de méta-programmation C++ [71,84]. Bien que les squelettes algorithmiques parallèles proposent un niveau d’abstraction intéressant, ce domaine est très peu utilisé pour des simulations scientifiques complexes. A notre connaissance, aucune simulation complexe n’a été écrite avec des squelettes algorithmiques, et leur utilisation se limite à des cas “jouet” comme la résolution de l’équation de la chaleur. Avec l’arrivée de nouveaux squelettes spécifiquement écrits pour le calcul stencil [21], l’utilisation des squelettes algorithmiques est enclin à se développer dans cette discipline. Toutefois, dans le domaine des mathématiques appliquées, les langages de programmation enseignés aux scientifiques sont très souvent des langages impératifs comme Fortran, C et C++. L’utilisation de langages fonctionnels, et donc de squelettes52 Chapitre 2. Etat de l’art algorithmiques parallèles, demande un effort d’apprentissage supplémentaire qui pourrait éloigner certains numériciens. Toutefois, notons qu’un langage fonctionnel peut être appris très rapidement et très facilement par les mathématiciens car il s’agit d’un langage plus proche des mathématiques. 2.4.4.2 D’autres solutions à patrons. L’entreprise Google est à l’origine de la démocratisation de l’utilisation du modèle MapReduce [47]. Dans ce modèle il est considéré que tout calcul peut être décomposé en une série d’association du squelette map et du squelette reduce. Cette solution a permis de démocratiser les squelettes algorithmiques, grâce à l’association intelligente de deux concepts simples, dont la mise en œuvre est facilitée par un certain nombre d’outils. Ainsi, par exemple, le framework Hadoop [127], très connnu et très utilisé, propose un système de fichiers distribués et une implémentation de MapReduce. Il est alors possible de faciliter la création d’applications distribuées ainsi que leur déploiement sur des milliers de processeurs. Enfin, ce type de systèmes embarque généralement la gestion des pannes du programme ou du matériel, ce qui augmente encore l’intérêt des scientifiques, dont les simulations peuvent être très longues et coûteuses. Google est également à l’origine d’un modèle de parallélisme simple pour les traitements parallèles sur les graphes dirigés, Pregel [88]. Dans l’état de l’art de ce travail, Pregel est comparé à PBGL et CGMGraph (décrits précédemment), et le principal argument avancé pour préférer son utilisation est la tolérance aux pannes. Toutefois, le type d’approche est très différent. En effet, Pregel conserve une idée proche des squelettes algorithmiques et se base également sur le modèle BSP pour structurer de façon générale des opérations sur des graphes dirigés. Dans Pregel, le graphe est tout d’abord distribué sur les différents processeurs. Un calcul dans Pregel est ensuite composé de plusieurs itérations, que l’on peut comparer à des super-étapes du modèle BSP. Dans chacune de ces étapes, le framework Pregel appelle une fonction utilisateur qu’il applique sur chaque nœud du graphe distribué. La fonction spécifie le comportement d’un unique nœud général v pour une étape S. Cette fonction peut recevoir des messages envoyés à v à l’étape S − 1, et peut envoyer des messages à d’autres nœuds qui seront reçus à l’étape S + 1. On retrouve alors la notion de fonction utilisateur de MapReduce, ou de tout autre squelette, et l’on retrouve également l’application de cette fonction sur chacun des nœuds, tout comme dans les squelettes algorithmiques. Toutefois le modèle Pregel est une solution plus générale que les squelettes algorithmiques habituels et ne représente pas un patron de parallélisation unique. La fonction utilisateur peut, en effet, décrire des problèmes très variés et offre une plus grande liberté de codage que dans l’utilisation des squelettes algorithmiques. Il est important de noter que les algorithmes sur les graphes peuvent être exprimés comme des chaînes d’appels à MapReduce [38, 75]. Toutefois, le modèle Pregel propose de meilleures performances. En effet, il conserve la même distribution de graphe d’une étape à l’autre du calcul, et utilise uniquement l’envoi et la réception de messages pour obtenir les informations d’autres processeurs. L’utilisation de MapReduce implique, quant à elle, tout d’abord (1) une distribution initiale des données, puis (2) l’application du map, puis pour terminer (3) des communications pour2.4. Le parallélisme implicite 53 l’application du reduce, ce qui revient à communiquer toutes les données résultantes du map à chaque appel d’un mapreduce. Giraph [7] est une alternative à Pregel et utilise les même concepts. Là encore il s’agit de solutions de parallélisme implicite très intéressantes et avec un certain nombre d’avantages. L’utilisation de ce type de solutions semble, tout d’abord, simplifier encore davantage la création de programmes parallèles, et la classification des différentes opérations d’un programme en patrons ne semble pas extrêmement difficile à élaborer. De plus, ces solutions utilisent deux types de spécificités pour mettre au point des optimisations : les structure de données distribuées, et les patrons utilisés. Les possibilités de performances paraissent donc plus importantes que dans les solutions dites générales. Cependant, un certain nombre de problèmes peuvent être notés avec ce type de solution. Tout d’abord, et comme nous l’avons décrit, chaque opération décrite à l’aide d’un patron, ou d’un squelette, est en fait une opération simple. À l’exception de Pregel, ces solutions sont très proches de la programmation fonctionnelle. Ainsi, si des calculs complexes doivent être mis en œuvre, un grand nombre d’appels imbriqués sera nécessaire, ce qui peut complexifier l’écriture, la lecture et la compréhension des programmes. Dans cette solution, de nouveau, il semble possible que la difficulté de programmation parallèle soit déportée vers l’utilisation de nouveaux concepts, et notamment vers les difficultés de la programmation fonctionnelle, non connue de la plupart des scientifiques. 2.4.5 Solutions spécifiques à un domaine Nous avons donc vu que les solutions générales de parallélisme implicite sont uniquement spécifiques aux types de conteneurs utilisés, ce qui peut limiter les optimisations du programme parallèle. Les solutions à patrons de parallélisme sont, quant à elles, spéci- fiques aux types de conteneurs mais aussi aux types de patrons utilisés, ce qui augmente les possibilités d’optimisations pour le problème posé. Dans cette dernière partie, nous allons voir le niveau d’abstraction et de spécificité le plus haut qui est proposé dans les solutions de parallélisme implicite pour le calcul scientifique. Dans ce cas, la solution, qu’elle soit une bibliothèque, un framework ou un langage dédié (noté DSL), est spécifiquement implémentée pour un problème spécifique et propose des optimisations de performances dues à cette spécificité, qu’on ne pourrait donc pas retrouver dans les solutions plus géné- rales. La définition de “spécifique” peut être très variée. Par exemple, STAPL peut être vu comme un langage dédié à la programmation par conteneurs parallèles. Toutefois, nous rattacherons ici, et dans le reste de cette thèse, une solution dite spécifique (de type DSL, bibliothèque etc.) à une solution spécifique au calcul scientifique. Le domaine du calcul scientifique reste un domaine très vaste, même si il est beaucoup plus spécifique que les domaines traités par STAPL, PBGL ou les squelettes algorithmiques. Pour cette raison, de nombreuses solutions spécifiques ont été mises au point pour divers sous-problèmes du calcul scientifique. Certaines solutions sont plus spécifiques que d’autres, tout le problème étant de trouver le niveau d’abstraction idéal pour l’utilisation qui sera faite du langage. Parmi les solutions parallèles spécifiques aux applications scientifiques, on peut tout54 Chapitre 2. Etat de l’art d’abord noter ScaLAPACK [19] qui est une bibliothèque haute performance pour les calculs de l’algèbre linéaire, implémentée pour les architectures parallèles à mémoire distribuée. On peut ensuite noter FFTW [55], pour le calcul parallèle de la transformée de Fourier discrète, et donc notamment pour des problèmes de traitement du signal. Ce DSL est implémenté pour des architectures à mémoire partagée et distribuée. SPIRAL [104] est, quant à lui, un DSL plus récent permettant, de façon plus générale que FFTW, d’effectuer des traitements du signal numérique. Dans cette thèse, nous nous intéressons plus particulièrement à la résolution des EDP par des méthodes numériques basées sur des maillages, et donnant lieu à des schémas numériques explicites. Nous nous intéressons donc aux problèmes stencils pour tout type de maillages, et nous allons évoquer avec plus d’attention, dans le reste de cette section, les DSL, bibliothèques et frameworks spécifiquement développés pour ce type de calculs que l’on peut appeler plus généralement des DSS pour Domain Specific Solutions. 2.4.5.1 EDP et EDO sur maillages structurés Commençons par évoquer les solutions de parallélisme implicite spécifiques au calcul de type stencil sur les maillages structurés. Il en existe en très grand nombre, et il ne s’agit pas ici d’une liste exhaustive de ces solutions mais des quelques travaux qui paraissent proches des solutions présentées dans cette thèse. Notons tout d’abord l’une des solutions les plus utilisées et les plus connues du monde de la simulation scientifiques, PETSc [10–12]. PETSc est une solution très vaste qui permet d’écrire des applications scientifiques, modélisées par des EDP, en parallèle. Cette solution est composée d’outils permettant d’effectuer des opérations sur des vecteurs et des matrices, de solveurs d’équations linéaires et non linéaires, mais également d’outils graphiques permettant la visualisation des résultats de l’application. PETSc est implémenté pour les architectures à mémoire partagée CPU et GPU grâce aux modèles pthreads, CUDA et OpenCL, pour les architectures à mémoire distribuée, grâce à l’utilisation de MPI, et pour les architectures à mémoire hybrides aux travers des associations MPI-pthreads et MPI-GPU. PETSc est basé sur un ensemble de structures de données distribuées et sur un ensemble de fonctions ou routines spécialisées pour ce type de traitements. PETSc est donc identifiable à une bibliothèque sur conteneurs, tout comme STAPL ou PSTL, mais dont les interfaces et les algorithmes sont spécifiques au traitement des EDP. Nous pouvons également noter la bibliothèque spécifique Trilinos [68] qui est très proche de PETSc. Nous pouvons également noter des solutions spécifiques plus récentes, comme par exemple le framework développé à Berkeley permettant de générer automatiquement un code parallèle, adapté à l’architecture à mémoire partagée et au matériel utilisé (dit auto-tuned), uniquement à l’aide de l’expression d’un stencil en Fortran [74]. Dans cette même famille de framework auto-tuned, on peut également noter PATUS [36] qui génère du code parallèle CPU et GPU à partir de l’expression d’un stencil et d’une stratégie de parallélisation. PATUS évalue ensuite la meilleure parallélisation pour le matériel utilisé. Évoquons également Panorama [86] qui utilise des techniques particulières pour minimiser les défauts de cache, et Pochoir [116] qui permet la définition de stencils à n dimensions en C++. Physis [89] ne propose pas de solution auto-tuned mais permet lui aussi de2.4. Le parallélisme implicite 55 définir une expression stencil à l’aide d’un DSL, et d’en produire automatiquement des applications parallèles MPI et CUDA. 2.4.5.2 EDP sur maillages non-structurés De nombreuses solutions de parallélisme implicte, spécifiques aux calculs de type stencil, sont donc disponibles pour les maillages structurés. Lorsque le problème des maillages non-structurés est abordé, les outils se font plus rares, mais il en existe également. Nous pouvons, tout d’abord, évoquer le plus ancien d’entre eux, OP2 [59, 60, 94]. OP2, développé à l’université d’Oxford, est une révision du framework OPlus [23], initié en 1993, qui permettait d’écrire des applications basées sur un maillage non-structuré et sur la méthode des éléments finis. OPlus a notamment été utilisé pour paralléliser, en 1995, une simulation d’écoulement des fluides non visqueux sur un maillage complexe représentant un avion [45]. OPlus était implémenté pour les architectures à mémoire distribuée et implémenté en MPI. OP2 est une version plus moderne et plus récente de OPlus qui est implémentée pour les architectures à mémoire partagée CPU et GPU. Le framework OP2 charge l’utilisateur de quatre parties : (1) définir des ensembles d’éléments qui vont définir les éléments du maillage, (2) définir des liens entre ces ensembles pour former le maillage, (3) définir des données sur les ensembles, et enfin (4) implémenter des opérations sur les ensembles d’éléments. Il est ainsi possible de définir un maillage non-structuré de toute forme, ainsi que sa topologie. Le framework dispose d’un compilateur permettant de transformer le code OP2 en un code C++, qui pourra à son tour être compilé. Le DSL Liszt [50] permet également de coder des simulations sur maillages non-structurés en parallèle. Toutefois, le niveau d’abstraction proposé à l’utilisateur est légèrement différent. En effet, le niveau d’abstraction de OP2 est plus proche du niveau d’abstraction des squelettes algorithmiques puisque l’utilisateur n’a pas à définir ses boucles, alors que Liszt permet de rester plus proche d’un code séquentiel avec la gestion des boucles par l’utilisateur. Le langage Liszt est une sous-partie du langage de programmation Scala [99], et utilise une version modifiée de son compilateur. Liszt supporte une implémentation MPI, OpenMP et CUDA/OpenCL. Dans une solution de parallélisme implicite spécifique, comme celles qui ont été évoquées ici, il est nécessaire de doser convenablement le niveau de spécificité de la solution. D’une part, si le niveau de spécificité est trop important, cela peut nuire au nombre d’utilisateurs. D’autre part, et à l’inverse, si le niveau de spécificité est trop faible, la solution peut s’avérer trop généraliste et risque de ne pas répondre aux attentes des utilisateurs. Toutefois, en trouvant un niveau de spécificité adéquat, ces solutions sont souvent celles qui procurent les meilleures performances, et la plus grande notoriété auprès des utilisateurs non-informaticiens.56 Chapitre 2. Etat de l’art 2.5 Calculs de performances et difficulté de programmation Dans cette thèse est proposée l’implémentation d’une solution de parallélisme implicite pour les simulations basées sur des maillages. L’évaluation de cette implémentation passe donc par deux volets, tout d’abord l’évaluation des performances produites par la solution de parallélisme implicite, mais également l’évaluation de la difficulté de codage liée à l’utilisation cette solution. Il existe un lien fort entre les performances d’une solution de parallélisme implicite et sa simplicité de codage, puisque le fait de cacher des opérations parallèles peut engendrer un certain sur-coût. Une solution de parallélisme implicite idéale sera à la fois performante et très simple d’utilisation. Cette dernière section de notre état de l’art va donc tout d’abord introduire les mesures de performances, puis les métriques d’effort utilisées dans cette thèse. 2.5.1 Mesures de performances En science informatique, on appelle benchmarking une méthode permettant de quantifier et d’évaluer les résultats expérimentaux d’un code ou d’un programme. Plus particulièrement, en calcul parallèle, le benchmarking est souvent associé aux méthodes permettant d’évaluer les performances d’un programme, de façon absolue, ou de façon relative à un autre programme. L’idée de base est de calculer le temps d’exécution d’un programme, ou d’une sous-partie du programme, représentative du problème à évaluer. Ce temps d’exécution peut ensuite être utilisé pour évaluer plusieurs types de métriques comme le temps d’exécution total et moyen du programme, l’accélération du programme, le débit des échanges de données par le programme (exprimés en bits par seconde), ou encore la puissance du programme (exprimé en nombre d’opérations flottantes, par seconde). Certaines de ces métriques peuvent être comparées de façon absolue avec un idéal de référence. C’est le cas, par exemple, de la puissance du programme qui ne peut en théorie pas dépasser les capacités matérielle des machines utilisées. D’autres métriques, en revanche, ne sont utiles que dans le cas d’une comparaison avec d’autres programmes, comme par exemple le temps d’exécution. Dans cette thèse deux métriques en particulier seront utilisées pour évaluer les performances des solutions proposées. La première est la représentation de l’accélération d’un programme, qui nous permettra d’évaluer la montée en charge des programmes parallèles implémentés. Nous appellerons cette métrique la scalabilité. Il existe deux méthodes pour évaluer la scalabilité d’un programme parallèle. La première est appelée la scalabilité faible, la seconde la scalabilité forte. Notons T(p, n) le temps nécessaire pour exécuter un programme en utilisant p processeurs et pour une taille de problème n. On définit alors l’accélération du programme, pour un problème de taille n et pour p processeurs, par speedup(p, n) = Tseq(1, n) T(p, n) , (2.19)2.5. Calculs de performances et difficulté de programmation 57 où Tseq(1, n) représente le meilleur temps séquentiel connu pour la résolution du problème courrant, alors que T(p, n) représente le temps du programme parallèle à évaluer. Il ne s’agit donc pas du même programme et le temps Tseq(1, n) est considéré comme la référence du problème. Cette définition de l’accélération permet d’évaluer une scalabilité dite forte et comparable entre différentes verions parallèles. La taille du problème n’est pas modifiée entre l’exécution séquentielle (sur un unique processeur) et l’exécution parallèle (sur p processeurs). Toutefois, étant donné qu’il est nécessaire de disposer de Tseq(1, n) pour évaluer cette l’accélération, une version modifiée de cette définition est généralement utilisée, et sera utilisée dans cette thèse. L’accélération est alors définie par speedup(p, n) = T(1, n) T(p, n) . (2.20) Dans ce cas c’est le temps séquentiel du programme à évaluer qui est utilisé comme temps de référence. Cette accélération est moins intéressante et ne permet pas une comparaison intéressante de deux versions parallèles différentes. Toutefois, elle permet d’observer la scalabilité du programme à évaluer. Une deuxième définition de l’accélération du programme, pour un problème de taille n et pour p processeurs, est speedup(p, n) = T(1, n) T(p, p × n) . Dans ce cas, la scalabilité évaluée est dite faible car la taille du problème est multipliée par le nombre de processeurs utilisés. Ainsi, la quantité de travail assignée à chaque processeur reste constante et le nombre de processeurs utilisés (et donc la taille du problème général) augmente. Cette accélération est idéale si le temps de calcul reste constant avec l’augmentation du nombre de processeurs et de la taille du problème. Cette accélération peut être utile dans plusieurs cas. Tout d’abord si le programme parallèle contient une fraction de code séquentielle et une fraction de code parallèle, cette accélération peut donner des indications sur le temps représenté par la fraction séquentielle et sur la nécessité de réduire cette fraction. Une fraction de code parallèle que nous appelons classique, c’est à dire utilisant relativement peu de communications (les plus proches voisins par exemple), ne rencontre pas de problème de scalabilité dans le cas d’une accélération faible. Si, en revanche, le programme parallèle utilise des communications très lourdes, telles que des communications collectives dont le coût augmente avec le nombre de processeurs, certains problèmes peuvent être détectés en représentant cette accélération. Enfin, si le programme consomme beaucoup de mémoire et ne peut, par exemple, pas être exécuté en séquentiel, cette accélération peut permettre d’évaluer tout de même son accélération. Dans cette thèse, nous utiliserons la définition de l’accélération forte modifiée (2.20) pour évaluer la scalabilité des programmes. Si l’on évalue l’accélération (2.20) d’un programme parallèle en utilisant P processeurs, on représente généralement une courbe de l’ensemble des valeurs de l’accélération entre 1 et P processeurs. Cette courbe représente donc l’accélération du programme parallèle en fonction du nombre de processeurs utilisés. Étant donné la définition de l’accélération (2.20), il peut être déduit que l’accélération idéale d’un programme est égale58 Chapitre 2. Etat de l’art à p pour tout p dans [1, P]. L’accélération idéale est alors représentée par la fonction f(p) = p. Il en résulte qu’un bon speedup sera idéalement le plus proche possible de la droite f(p) = p, et idéalement linéaire quelque soit le nombre de processeurs utilisés. Toutefois la réalité sur l’accélération d’un programme peut être différente de ces déductions théoriques. Il est en effet possible de dépasser l’accélération idéale théorique. C’est ce qu’on appelle une accélération super-linéaire. Ce phénomène peut être dû à plusieurs facteurs. La première raison concerne les architectures à mémoire distribuées. Imaginons alors que le programme séquentiel utilise trop de mémoire, il est alors possible que les données du programme ne tiennent plus en mémoire vive et soient stockées sur la mémoire disque de la machine (ce qu’on appelle du swapping). Dans ce cas, le temps d’exécution séquentiel peut être anormalement long. Ainsi, en augmentant le nombre de processeurs, et donc en réduisant l’emprunte mémoire du programme pour chaque processeur, l’accé- lération peut être facilement supérieure à p. La deuxième raison qui peut être à l’origine d’une super-linéarité est proche de la première mais non restreinte aux architectures à mémoire distribuée. Elle ne concerne plus le passage de la mémoire vive à l’espace disque, mais le passage de la mémoire cache à la mémoire vive. En réduisant la taille du problème (du fait du nombre de processeurs utilisés), il peut arriver que la taille des structures de données sur lesquelles sont effectués les calculs soit inférieure ou égale à la taille des lignes de cache, ce qui réduit le nombre d’accès à la mémoire vive depuis le cache, et ce qui augmente l’efficacité du programme. Cependant, lorsqu’un phénomène de cache se produit et qu’il conduit à une accélération super-linéaire, il peut être intéressant de modifier l’algorithme séquentiel afin que celui-ci traite des blocs de données plus petits, limitant ainsi les chargements de données en cache pendant les calculs. De cette façon, la super-linéarité est souvent réduite et l’accélération observée sera probablement plus réaliste. L’évaluation de la scalabilité forte d’un programme est un bon indicateur des performances du programme parallèle. Toutefois, l’accélération définie par (2.20), et utilisée dans cette thèse, souffre de certaines faiblesses lorsque l’on cherche à comparer les performances de deux implémentations différentes. Tout d’abord l’accélération d’un programme est liée au temps d’exécution séquentiel du programme. On ne peut donc pas comparer l’accélération de deux implémentations n’ayant pas le même temps d’exécution séquentiel. De même, meilleure est l’implémentation, plus difficile est l’obtention d’une bonne accélération, car la version moins optimisée passera plus de temps dans les calculs et aura probablement une accélération linéaire sur un plus grand nombre de processeurs. Une accélération est donc un bon indicateur de scalabilité pour un programme, mais la définition (2.20) n’est pas une bonne métrique pour comparer deux implémentations différentes. Pour cette raison nous utilisons une deuxième métrique dans cette thèse. Elle représente simplement le temps d’exécution des programmes et nous permettra de comparer de façon objective les temps d’exécution de plusieurs implémentations parallèles d’une même simulation scientifique. Notons que nous avons fait le choix, dans la plupart de nos résultats, de représenter les temps d’exécution avec une échelle logarithmique. Cette échelle nous permet, tout d’abord, de faciliter la lisibilité des temps d’exécution,2.5. Calculs de performances et difficulté de programmation 59 mais permet également de comparer à la fois les temps d’exécution et la linéarité des accélérations des implémentations. 2.5.2 Effort de programmation Il existe diverses métriques permettant d’évaluer l’effort à fournir pour écrire un code. Certaines métriques permettent d’évaluer la difficulté d’un programme à partir du nombre de fonctionnalités à implémenter [4,80]. Ce type de métriques est utilisé dans la conception et le génie logiciel, mais ne nous sera pas utile pour comparer deux versions parallèles possédant les mêmes fonctionnalités. La complexité cyclomatique [91] est une métrique qui base la difficulté de programmation sur le comportement d’un programme. Elle est basée sur un graphe qui représente les différentes exécutions possibles d’un même programme, pour en estimer sa complexité. En d’autres termes, cette métrique s’intéresse aux branches conditionnelles du programme. De nouveau, nous ne pourrons utiliser cette métrique pour comparer deux implémentations d’une même simulation. Nous pouvons noter deux métriques qui pourraient être utilisées dans notre cas. Tout d’abord, la mé- trique SLOC (Source Lines of Code) se base uniquement sur le nombre de lignes dans un code pour évaluer la difficulté d’un programme. Il s’agit d’une première indication sur l’effort à fournir pour écrire un programme. Mais nous allons plus particulièrement nous concentrer sur les métriques de Halstead [65], qui offrent des indicateurs plus révélateurs sur l’effort de programmation à fournir pour écrire un code. Les métriques de Halstead sont basées sur le dénombrement des opérateurs et des opérandes d’un code source. De ce dénombrement, directement appliqué dans le code, sont obtenues quatre mesures représentées dans la table 2.2. Afin d’évaluer correctement ces mesures il est important de définir ce que l’on considère comme un opérateur et un opérande. Peu d’informations sur ce sujet sont données dans la littérature. Dans nos codes C++, nous avons considéré que les opérandes étaient l’ensemble des variables et constantes définies par l’utilisateur. Les opérateurs sont l’ensemble des opérations numériques, affectations et opérateurs de comparaison (+,∗,−,/,=,==,&&,<= etc.), l’ensemble des mots clés du C++ (static, class, template etc.), l’ensemble des types (int, const, float, ∗ etc.), l’ensemble des instructions du C++ (for, while, do, if /elseif /else etc.), les symboles délimiteur ;, les parenthèses et les appels de fonctions. Symbole Mesure N1 Nombre total d’opérateurs N2 Nombre total d’opérandes η1 Nombre d’opérateurs distincts η2 Nombre d’opérandes distincts Table 2.2 – Mesures directes dans le code Grâce à ces quatre mesures, les métriques de Halstead peuvent être calculées et sont représentées dans la table 2.3. La première représente le vocabulaire du programme, la deuxième la longueur du programme, qui n’est pas directement liée aux nombre de lignes60 Chapitre 2. Etat de l’art de code mais au nombre total d’opérandes et d’opérateurs. La troisième métrique repré- sente le volume du programme. Ce volume est le produit de la longueur du programme et du logarithme en base deux du vocabulaire. Comme ce volume est basé sur le nombre d’opérations effectuées et d’opérandes gérées dans le programme, il est moins sensible à la disposition du code que les mesures SLOC. La métrique suivante représente la diffi- culté, et la propension à l’erreur, d’un programme. Cette métrique est calculée comme un produit entre le vocabulaire des opérateurs et la fréquence d’apparition des opérandes. Elle part donc du principe que plus le nombre d’opérateurs distincts est grand, plus il est difficile d’implémenter le programme, et que plus les même opérandes sont utilisées dans le programme, plus la propension à l’erreur est grande. Enfin la dernière métrique représente l’effort nécessaire à l’écriture du programme et est égale au produit du volume par la difficulté. Ainsi, plus un programme est volumineux et difficile, plus l’effort de programmation à fournir sera important. Symbole Valeur Métrique η η1 + η2 Vocabulaire N N1 + N2 Longueur V N × log2 η Volume D η1 2 × N2 η2 Difficulté E D × V Effort Table 2.3 – Métriques de Halstead Les métriques de Halstead proposent donc des concepts intéressants et permettent de pouvoir comparer deux implémentations différentes, en terme d’effort de programmation, ce qui n’est pas le cas des autres métriques. Même si ces métriques ont été proposées pour des programmes séquentiels, elles s’appliquent, de notre point de vue, à des programmes parallèles. Toutefois, notons que ces métriques comportent des faiblesses pour exprimer l’effort de programmation d’un programme parallèle. Tout d’abord, dans un programme parallèle, un effort plus important est demandé aux utilisateurs pour utiliser des opérateurs parallèles et des opérandes distribuées, que pour utiliser des opérateurs et opérandes classiques de la programmation séquentielle. De plus, dans la conception d’un programme parallèle, les appels à des opérateurs parallèles (comme par exemple les routine de MPI), et l’utilisation d’opérandes distribuées ne sont pas les seuls diffi- cultés. En effet, l’un des points les plus difficiles dans la programmation parallèle est la conception du programme. C’est, en effet, le développeur qui doit réfléchir à la façon dont le programme va pouvoir fonctionner en parallèle et ce n’est pas une difficulté qui peut transparaître dans le dénombrement des opérandes et des opérateurs. Il paraît très difficile de pouvoir évaluer ce type de difficulté, aussi les métriques de Halstead restent, de notre point de vue, les métriques les plus adaptées à l’utilisation que nous souhaitons en faire dans cette thèse.2.6. Conclusion et positionnement du travail 61 2.6 Conclusion et positionnement du travail Cette thèse vise à proposer des solutions de parallélisme implicite pour le cas spé- cifique des simulations numériques scientifiques. Pour cette raison, cet état de l’art a, tout d’abord, évoqué les architectures parallèles, les paradigmes et les modèles de programmation et leur évolution au fil du temps, ainsi que la discrétisation et les méthodes numériques de résolution des EDP. Dans les concepts introduits dans la section 2.2 de cet état de l’art, nous nous intéressons plus particulièrement aux résolutions d’EDP basées sur des maillages quelconques, en utilisant les méthodes numériques introduites dans la partie 2.2.4. Le travail présenté dans cette thèse se limite, dans les chapitre 3 et 4, aux calculs de schémas numériques explicites (2.3), toutefois le chapitre 5 évoquera et traitera le cas de schémas numériques implicites (2.4) également. Cette thèse propose des modèles et des implémentations basés sur le paradigme de parallélisme de données et sur le paradigme SPMD. Pour cette raison, le problème de partitionnement des données est un point à aborder et que nous traitons plus particulièrement dans le chapitre 5. Nous présentons dans cette thèse un modèle de programmation implicite nommé SIPSim (pour Structured Implicit Parallelism for Scientific SIMulations ), puis par la suite son implémentation pour des architectures à mémoire distribuée, nommée SkelGIS, qui permet de valider le modèle. L’approche SIPSim s’applique, a priori, à tout type de maillage, toutefois cette thèse s’intéresse à l’implémentation de deux cas particuliers : les maillages cartésiens à deux dimensions et la composition de maillages sous forme de réseaux. Le modèle SIPSim permet de générer des programmes parallèles SPMD du type de l’algorithme 2, en conservant une programmation séquentielle comme introduite dans l’algorithme 1. En- fin, l’implémentation actuelle de l’approche SIPSim (SkelGIS) est effectuée en utilisant le modèle MPI, introduit dans cet état de l’art. C’est dans la partie 2.4 de cet état de l’art qu’a été introduit le cœur de cette thèse en décrivant les modèles et les solutions de parallélisme implicite. Les avantages et les inconvénients de chaque vision du parallélisme implicite ont été donnés et analysés, ce qui nous permet de positionner notre travail dans ce contexte. La figure 2.12 résume ce positionnement, que l’on peut aussi résumer ainsi : — Des bibliothèques générales de parallélisme implicite, notre travail tente de conserver une certaine flexibilité, ou souplesse, qui permet de répondre notamment à des cas particuliers de simulations. Nous héritons par exemple du concept très important d’itérateur de STAPL ou de PSTL, sous une forme différente. — Des solutions à patrons, et des bibliothèques de squelettes algorithmiques, notre travail hérite d’un haut niveau d’abstraction. L’utilisateur définit, en effet, des fonctions séquentielles qui sont appliquées au travers de patrons où les communications entre les processeurs lui sont cachées. Nos travaux sont notamment proches des concepts introduits par le modèle Pregel, proche de BSP. — Enfin, des langages et bibliothèques spécifiques, notre travail cherche à retrouver une efficacité propre aux problèmes spécifiquement traités, par le biais d’optimisations. Le framework OP2 et le DSL Liszt sont les solutions spécifiques les plus proches de nos travaux.62 Chapitre 2. Etat de l’art Solutions spécifiques Patrons et squelettes SIPSim Solutions générales Optimisation Abstraction Flexibilité Figure 2.12 – Placement de notre travail par rapport à l’existant. Enfin, afin de comprendre les résultats présentés dans cette thèse, nous avons terminé cet état de l’art par une présentation des mesures de performance et des mesures de difficulté de programmation.3 SIPSim : Structured Implicit Parallelism for scientific Simulations Sommaire 4.1 SIPSim pour les maillages réguliers à deux dimensions . . . . . 74 4.1.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . . . 74 4.1.2 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.1.3 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.4 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . . . 80 4.2 Résolution numérique de l’équation de la chaleur . . . . . . . . 82 4.2.1 Équation et résolution numérique . . . . . . . . . . . . . . . . . . . . . . 82 4.2.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.2.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.3 Résolution numérique des équations de Saint Venant . . . . . . 89 4.3.1 Équations de Saint Venant . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.3.2 Résolution numérique et programmation . . . . . . . . . . . . . . . . . . 90 4.3.3 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6364 Chapitre 3. SIPSim : Structured Implicit Parallelism for scientific Simulations Dans cette thèse nous nous intéressons aux simulations scientifiques dont les équations aux dérivées partielles sont résolues par des méthodes numériques qui discrétisent l’espace et le temps. On appelle ces simulations des simulations basées sur des maillages. Nous nous intéressons plus précisément, et dans un premier temps, aux simulations dont les schémas numériques sont explicites et donc de la forme de l’équation (2.3) présentée dans la section 2.2.3.2. En informatique, ce type de calcul est appelé un calcul stencil. Le parallélisme implicite pour des calculs de type stencil est un domaine très actif de la recherche en informatique. Dans ce chapitre est présentée la méthode SIPSim, qui signifie Structured Implicit Parallelism for scientific Simulations. SIPSim permet d’obtenir une vision systématique des besoins pour proposer une solution de parallélisme implicite pour ce type de simulations. SIPSim peut donc être considéré comme un modèle de programmation parallèle implicite pour les simulations scientifiques. Afin de définir une approche pertinente pour élaborer des solutions de parallélisme implicite pour les simulations scientifiques, il faut tout d’abord étudier la parallélisation de ces simulations scientifiques. Comme nous l’avons déjà décrit dans l’état de l’art 2.4, Pingali et Al [103] ont défini “The TAO of Parallelism in Algorithms”, qui propose une classification intéressante des différents types de problèmes à paralléliser. Une fois un problème classifié dans le “TAO”, des solutions connues de parallélisation peuvent être appliquées. La parallélisation est donc facilitée grâce à cette classification, mais en aucun cas cachée, comme nous cherchons à le faire. Comme nous l’avons déjà détaillé dans la section 2.4.1 de l’état de l’art, le type de simulations auxquelles nous nous intéressons dans ce travail (sur maillages fixes et schémas numériques explicites) sont classifiées dans le “TAO” comme des algorithmes topology-driven, dont l’ensemble des éléments du maillage sont identifiés comme les nœuds actifs (active nodes) de l’algorithme, et peuvent être traités de façon non-ordonnée dans l’algorithme. Enfin, les calculs sont considérés comme locaux car ne modifiant pas le maillage d’entrée. Comme il l’a déjà été évoqué précédemment, pour des architectures parallèles à mé- moire distribuée, ce genre de simulations est généralement parallélisé en utilisant l’approche SPMD (Simple Program Multiple Data) décrite dans l’état de l’art. Cette approche se prête bien aux simulations basées sur les maillages puisqu’elle consiste alors à partitionner le maillage en plusieurs parties, chacune confiées à des processeurs diffé- rents qui exécuteront le même code sur leur sous-partie du maillage. L’algorithme 2 de la partie 2.2.5 illustre ce type de parallélisation, et représente la base de l’analyse de l’approche SIPSim. Nous rappelons ici cet algorithme avec plus de détails. Nous notons Sb le schéma numérique à appliquer aux éléments de la bordure physique du maillage, qui correspond donc à calculer les conditions limites. Nous notons, de plus, S le schéma numérique permettant le calcul des quantités pour les autres éléments du maillage. Cet algorithme parallèle peut très clairement être apparenté au modèle BSP, introduit lui aussi dans l’état de l’art. En effet, dans cet algorithme peuvent être identifiées trois super-étapes. Tout d’abord une super-étape de communication est effectuée au début de chaque itération de temps. Dans cette étape, chaque processeur reçoit les valeurs sur le voisinage N(x), qu’il ne possède pas dans son sous-maillage, afin de pouvoir calculer, de façon correcte, l’ensemble des nouvelles valeurs pour la nouvelle itération de temps.65 Algorithme 3 : Algorithme parallèle SPMD d’une simulation basée sur un maillage. Création du maillage µ Partitionnement du maillage µ = {µ0, µ1, . . . µp−1} Création des quantités à simuler appliquées à µ Initialisation des quantités et des paramètres Définition du pas de temps, commun à tous les processeurs : t Définition du temps maximal, commun à tous les processeurs : tmax tant que t struct DMatrix template struct DMatrix template struct DMatrix template struct DMatrix Figure 4.4 – Spécialisation partielle de template pour l’objet DMatrix : T est le type de donnée à stocker dans l’instance, Or est l’ordre de la simulation, et box est le type de connectivité souhaitée. Ce paramètre a une valeur par défaut à false (star est le choix par défaut). Trois paramètres de template sont définis pour l’objet DMatrix. Le premier paramètre, T, indique le type de données qui va être stocké dans l’instance de l’objet. Le82 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions paramètre Or indique ensuite l’ordre nécessaire pour l’instance de l’objet DMatrix. Ce paramètre peut sembler inutile pour l’objet DMatrix en lui-même, puisque l’ordre est une indication qui concerne la simulation et non chaque quantité simulée. Toutefois, il est important de demander cette information au niveau de l’objet DMatrix pour rendre la solution plus efficace. En effet, dans une simulation, toutes les quantités à simuler sont nécessaires au calcul du ou des schémas numériques de type (2.3), toutefois, toutes les quantités à simuler ne participent pas aux calculs faisant intervenir N(x). Demander l’ordre pour chaque instance de l’objet DMatrix permet donc d’éviter des communications inutiles lorsque l’instance n’a pas besoin de voisinages. Enfin, le troisième paramètre de la classe template, box, est un booléen avec une valeur par défaut à false. Ce paramètre indique la connectivité du maillage qui va être définie en instanciant l’objet DMatrix. En effet, rappelons ici que l’objet DMatrix a la particularité de regrouper deux composants de la méthode SIPSim, la structure de données distribuée (DDS), et l’application de données sur cette structure de données (DPMap). L’instanciation d’un objet DMatrix correspond donc bien à la définition d’un maillage et il n’est pas impossible qu’une simulation complexe instancie différents types de connectivités pour ses différentes quantités à simuler. Trois spécialisations partielles des paramètres de cette classe sont proposées et données dans la figure 4.4. Tout d’abord, en conservant la valeur par défaut du paramètre box, le paramètre Or est spécialisé avec la valeur 0. Cette spécialisation permet d’indiquer qu’une quantité utilisée dans la simulation ne participe pas aux calculs faisant intervenir N(x). Autrement dit, ce type de quantité est utilisé localement, sans notion de voisinage. Cette spécialisation est très importante pour les performances de la solution puisqu’alors aucune communication MPI ne sera nécessaire. La deuxième spécialisation fixe le paramètre box avec une valeur à true. Cette spécialisation active donc la connectivité box. Dans cette spécialisation, les interfaces de voisinage proposées à l’utilisateur seront différentes. Enfin la troisième spécialisation fixe le paramètre Or à 0 et le paramètre box à true, ce qui combine les deux spécialisations précédemment décrites. Chaque spécialisation de l’objet DMatrix propose une implémentation de la classe qui lui est propre, ce qui alourdit considérablement le code de la bibliothèque (mais pas le code utilisateur). Cependant, cette solution est très intéressante puisque l’utilisateur ne manipule qu’une unique classe. De plus, les performances obtenues sont également très intéressantes puisque, dans le code, les conditions concernant l’ensemble de ces paramètres disparaissent. Enfin, le choix de la bonne implémentation de classe est effectué à la compilation et non à l’exécution ce qui rend cette solution efficace. 4.2 Résolution numérique de l’équation de la chaleur 4.2.1 Équation et résolution numérique L’équation de la chaleur à deux dimensions est définie par ∂u ∂t = ∂ 2u ∂x2 + ∂ 2u ∂y2 ,4.2. Résolution numérique de l’équation de la chaleur 83 où u(x, y, t) représente la température au point (x, y) et à l’itération de temps t. Le schéma explicite des différences finies est le schéma le plus simple pour résoudre l’équation de la chaleur. Il consiste en une discrétisation du domaine en espace avec le maillage {xi , yj}i,j , avec xi = i∆x et yj = j∆y. ∆x = xi+1 − xi et ∆y = yi+1 − yi sont les intervalles en espace suivant les deux dimensions. Soit ∆t l’intervalle de temps entre chaque itération, supposons qu’à un temps tn = n∆t, la valeur u n i,j = u(xi , yj , tn) est connue pour chaque élément du maillage. Alors, en utilisant le développement polynomial de Taylor, la solution à l’instant tn+1 est donnée par le schéma suivant : u n+1 i,j − u n i,j ∆t = u n i+1,j − 2u n i,j + u n i−1,j ∆x 2 + u n i,j+1 − 2u n i,j + u n i,j−1 ∆y 2 . En supposant que ∆x = ∆y, alors le schéma devient : u n+1 i,j = (1 − 4λ)u n i,j + λ(u n i+1,j + u n i−1,j + u n i,j+1 + u n i,j−1 ), (4.9) où λ := ∆t ∆x2 ≤ 1 2 garantit la stabilité du schéma numérique. 4.2.2 Parallélisation avec SkelGIS Le schéma numérique de l’équation (2.3) offre toutes les informations nécessaires pour coder la simulation en utilisant SkelGIS. Tout d’abord, seule la quantité u nécessite d’être manipulée dans le schéma. Ensuite, comme le calcul pour l’itération de temps n+1 dépend des résultats de l’itération de temps n, deux instanciations de l’objet DMatrix sont nécessaires pour stocker successivement les données d’entrée et de sortie. De plus, le schéma nous donne l’indication qu’une connectivité de type star est nécessaire pour chaque calcul. En effet, les éléments (i + 1, j) (droit), (i − 1, j) (gauche), (i, j + 1) (bas) et (i, j − 1) (haut) sont utilisés par le schéma. L’ordre de la simulation est égal à 1 car aucun élément aux positions i ± 2 ou j ± 2 ne sont nécessaires. Enfin, il y a un unique schéma à appliquer à chaque itération de temps, ce qui nous indique qu’un unique appel à un applicateur sera nécessaire pour cette résolution. La figure 4.5 donne le code de la fonction main du programme de résolution de l’équation de la chaleur en utilisant SkelGIS. Deux instanciations de l’objet DMatrix sont tout d’abord effectuées (lignes 12 et 14). Par la suite, la boucle en temps est initialisée (ligne 15). A chaque itération de temps, l’applicateur est appelé avec l’opération laplacien (ligne 17) pour résoudre le schéma. Enfin, les DMatrix d’entrée et de sortie sont échangées pour l’itération en temps suivante (lignes 18 à 20). Notons ici que la création de m3 à la ligne 18 ne fait que copier l’adresse du pointeur qui est caché derrière l’objet m. Cette étape n’est donc pas coûteuse en temps d’exécution. Il reste toutefois quelques détails non précisés dans la figure 4.5. Les instructions INIT SKELGIS et ENDSKELGIS, tout d’abord, permettent d’initialiser de façon implicite la bibliothèque MPI et certaines variables utiles à SkelGIS. La classe HEADER permet simplement de définir l’en-tête d’un maillage cartésien à deux dimensions suivant une largeur et une hauteur (width et height) et suivant une coordonnée en haut à gauche du maillage (x et y). Il est également84 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions 1 #include " s k e l g i s / s k e l g i s . hpp" 2 using namespace s k e l g i s ; 3 4 int main ( int argc , char∗∗ argv ) 5 { 6 INITSKELGIS ; 7 HEADER head ; 8 head . x=0; head . y=0; 9 head . width =100; head . h ei g h t =100; 10 head . s p a ci n g =1; head . nodata=−9999; 11 12 DMatrix m( head , 0 ) ; 13 m. se tGl o b alMid dleV alue ( 1 ) ; 14 DMatrix m2( head , 0 ) ; 15 for ( int i =0; i <100; i++) 16 { 17 ApplyUnary:: apply ( l a p l a c i e n ,m,m2 ) ; 18 DMatrix m3(m) ; 19 m = m2; 20 m2 = m3; 21 } 22 ENDSKELGIS; 23 } Figure 4.5 – Fonction main du programme de résolution de l’équation de la chaleur avec SkelGIS. possible de préciser un nombre flottant représentant la hauteur et la largeur d’une maille, et de pouvoir identifier une valeur qui représente une maille sans donnée. Son nom est historiquement conservé de l’en-tête des fichiers représentant le terrain dans les SIG (Système d’Information Géographiques). Enfin, la méthode setGlobalM iddleV alue(1) permet d’initialiser une valeur à 1 au centre du maillage. Notons qu’il aurait également été possible d’initialiser ce maillage par un fichier. La figure 4.6 donne ensuite le code de l’opération laplacien qui est appliquée dans la fonction main. Cette opération calcule le schéma numérique (4.9) et est appliquée à chaque itération de temps. Tout d’abord un itérateur est initialisé au début de la DMatrix d’entrée. Un autre itérateur est initialisé à la fin de cette même DMatrix (lignes 4 et 5). Pour chaque élément du maillage (ligne 6), le schéma est calculé (ligne 8 à 10) et le résultat est écrit dans la DMatrix de sortie (ligne 11). Les macros C++ “BEGINApplyUnary” et “END” aux lignes 1 et 13, servent à identifier le début et la fin de la définition de l’opération laplacien. Cet exemple illustre que le code SkelGIS reste très proche d’un code séquentiel. Aucune difficulté n’est introduite dans ce code puisque les interfaces et les paramètres demandés sont connus de l’utilisateur. Il peut aussi être noté qu’aucune utilisation de pointeurs n’est nécessaire dans le code SkelGIS, ce qui simplifie son utilisation. La bibliothèque gère en effet elle-même la création et la destruction des pointeurs dont elle4.2. Résolution numérique de l’équation de la chaleur 85 1 BEGINApplyUnary ( l a p l a c i e n ,m, double , 1 ,m2, double , 1 ) 2 { 3 double a = 0 . 0 5 ; 4 i t e r a t o r i t = m. be gi n ( ) ; 5 i t e r a t o r itEnd = m. end ( ) ; 6 for ( i t ; i t h DMatrix u DMatrix v Figure 4.11 – Déclaration des variables h, u et v type double, le paramètre Or est égal à 2 et la valeur par défaut du paramètre box est utilisée. Notons que les autres variables de la simulation sont, pour la plupart, soit du type DM atrix < double, 2 > soit du type local DM atrix < double, 0 >. L’algorithme 7 illustre la fonction principale de la simulation. Bien entendu, FullSWOF2D est un logiciel complexe écrit en langage objet C++, la fonction main de cette application ne ressemble donc pas réellement à celle présentée ici. Toutefois, nous essayons ici de mettre en avant les concepts de l’utilisation de SkelGIS. La fonction principale d’une telle simulation consisterait donc, tout d’abord, en l’instanciation de l’objet DMatrix pour les trois quantités simulées ainsi que pour l’ensemble des variables nécessaires aux calculs de la simulation. Tout comme dans le programme séquentiel, ces variables et quantités seraient ensuite initialisées. Pour cela des opérations peuvent être définies et appelées par l’intermédiaire d’applicateurs. Il est aussi possible de mettre une valeur par défaut dans ces variables, ou encore de les initialiser à l’aide d’un fichier de données. Une fois ces initialisations effectuées, la boucle principale de la simulation en temps est démarrée. Elle est suivie, tout comme dans l’algorithme séquentiel, d’une boucle for de deux itérations permettant d’appliquer les schémas à l’ordre 2 pour plus de précision. Dans cette boucle est ensuite appelé un applicateur. Notons ici qu’un ensemble d’applicateurs aurait aussi pu être appelé pour partitionner la simulation et l’organiser de façon plus4.3. Résolution numérique des équations de Saint Venant 93 claire. Tout dépend du code séquentiel initial et des dépendances entre les données, tout comme dans l’implémentation séquentielle. Nous présentons ici une solution ne faisant appel qu’à un applicateur, pour simplifier l’explication. La véritable implémentation de FullSWOF2D se décompose en plusieurs appels à des applicateurs répartis dans différents objets du code. Pour terminer, un deuxième applicateur est appelé afin d’effectuer les calculs nécessaires pour appliquer le schéma à l’ordre 2. Algorithme 7 : Fonction main codée par l’utilisateur DM atrix < double, 2 > h DM atrix < double, 2 > u DM atrix < double, 2 > v ... Initialisation des quantités et des paramètres Définition du pas de temps : t Définition du temps maximal : tmax while t < tmax do for i dans J0, 2J do apply_list({h,u,v,etc.},fullswof) end apply_list({h,u,v,etc.},heun) end Le premier applicateur appelé dans l’algorithme 7 va donc être en charge d’appliquer une opération contenant le calcul des conditions limites, de la reconstruction, des flux, du schéma numérique et des frottements. Cette opération est décrite dans l’algorithme 8. Pour rappel, la méthode SIPSim recommande de proposer au moins deux itérateurs différents dans l’interface de programmation, le premier pour parcourir les éléments de la bordure physique sans surcoût de conditions, et le deuxième pour les autres éléments du maillage. Cette recommandation a été suivie dans l’implémentation de SkelGIS pour les maillages cartésiens, comme cela a été décrit dans la partie 4.1.3. Pour cette raison, l’opération fullswof va tout d’abord parcourir les éléments de la bordure physique du maillage grâce aux itérateurs adaptés (qui sont en fait au nombre de quatre). L’opérateur [] et les fonctions de voisinage sont ensuite utilisés afin de calculer les conditions limites de la simulation. Par la suite, l’itérateur contigu mis en place dans SkelGIS est utilisé afin de naviguer dans l’ensemble des éléments du maillage qui ne font pas partie de la bordure physique. Une fois encore, l’opérateur [] et les fonctions de voisinage sont utilisés afin de calculer, le schéma de reconstuction, les flux numériques, le schéma numérique et enfin les frottements appliqués à l’écoulement du fluide. Notons, de nouveau, qu’il s’agit d’une simplification de la simulation. En effet, le calcul complet de la reconstruction hydrostatique est nécessaire avant le calcul des flux numériques, par exemple. Il n’est donc en théorie pas possible de calculer les deux informations pour un même élément du maillage dans la même boucle. Comme nous l’avons évoqué précédemment, suivant le code de la simulation, plusieurs applicateurs peuvent être appelés dans la fonction principale.94 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions Algorithme 8 : Opération séquentielle permettant de décrire le calcul des schémas numériques des équations de Saint Venant. Data : {DMatrix} Result : Modification de {DMatrix} ItB := itérateur de début sur les bordures physiques endItB := itérateur de fin sur les bordures physiques while ItB≤endItB do Application des conditions limites avec : h[ItB], u[ItB], v[ItB], h.getRight(ItB,1), v.getX(ItB,2) ... ItB++ end It= itérateur de début sur les éléments du maillage endIt := itérateur de fin sur les éléments du maillage while It≤endIt do Calculs avec h[It], u[It], v[It], h.getRight(It,1), v.getX(It,2) ... Calcul de la reconstruction hydrostatique Calcul des flux numériques Calcul du schéma numérique Calcul des frottements It++ end Chaque applicateur effectuera les boucles et les calculs dont il est responsable. Ces choix d’implémentation sont à la charge de l’utilisateur tout comme s’il codait un algorithme en séquentiel. 4.3.4 Résultats Nous allons maintenant présenter les résultats obtenus sur la simulation des équations de Saint Venant (4.10) décrites précédemment. Ces expériences sont basées sur deux implémentations parallèles du logiciel FullSWOF. Ces deux implémentations ont été effectuées de façon simultanée pendant le projet CEMRACS 2012 (Centre d’Eté Mathématique de Recherche Avancée en Calcul Scientifique) et dans une durée limitée d’environ trois semaines. La première est une version MPI, que nous appellerons FS_MPI, et la deuxième la version SkelGIS, que nous appellerons FS_SK. Ces deux implémentations sont basées sur une même version séquentielle du logiciel FullSWOF2D. FS_MPI a été implémenté par un ingénieur en mathématiques appliquées ayant les connaissances de base sur MPI, la version FS_SK, après une courte période de formation sur les concepts de SkelGIS, a été implémentée par un numéricien. FS_MPI a été implémenté de façon standard en MPI, en utilisant une décomposition de domaine, une topologie cartésienne ainsi que des types dérivés. Cette version MPI part du même code séquentiel que l’implémentation SkelGIS, et tout comme pour l’équation de la chaleur, les codes séquentiels de calculs ne sont ni modifiés ni optimisés dans ces versions parallèles. Seules les struc-4.3. Résolution numérique des équations de Saint Venant 95 tures de données sont ré-implémentées pour être distribuées sur les processeurs. Le code séquentiel de calcul n’a donc pas été modifié ou amélioré, les deux versions parallèles du code sont donc comparables. En revanche, il ne s’agit pas des versions parallèles les plus efficaces possibles pour cette simulation. Nous ne proclamons d’ailleurs pas que SkelGIS soit aussi efficace qu’un code parallèle spécifiquement optimisé pour les équations de Saint Venant. L’objectif du modèle SIPSim, et donc de SkelGIS, est de permettre de coder en séquentiel un programme qui sera parallèle. L’efficacité du programme dépendra donc de l’efficacité du code séquentiel en lui-même. Les expériences menées et présentées ici sont de deux types. Tout d’abord FS_MPI et FS_SK sont comparés en terme de performances sur les nœuds thin nodes du supercalculateur TGCC-Curie du CEA, vingtième dans le classement top500 de novembre 2013. Son architecture matérielle est détaillée dans la table 4.5. Chaque expérience a été effectuée quatre fois et moyennée. L’écart type noté sur l’ensemble des expériences n’a pas excédé 2%. Par la suite, les métriques de Halstead [65], déjà présentées dans la partie 2.5, sont utilisées afin de comparer les deux implémentations en terme de difficulté de codage. Calculateur TGCC Curie Processeur 2×SandyBridge (2.7 GHz) Cœurs/nœud 16 Mémoire/nœud 64 GB Compilateur [-O3] Bullxmpi Réseau Infiniband Table 4.5 – Spécifications matérielles des nœuds thin du TGCC-Curie 4.3.4.1 Performances Nous allons tout d’abord comparer en terme de performances FS_MPI et FS_SK qui sont deux versions parallèles comparables car basées sur le même code séquentiel. Quatre expériences ont été menées pour évaluer les performances de ces simulations parallèles et sont décrites dans la table 4.6. Ces expériences font varier la taille du domaine (expé- riences 1, 3 et 4) ou le nombre d’itérations en temps (expériences 1 et 2). L’ensemble des temps d’exécution obtenus (en secondes) sont présentés dans la table 4.7. Une représentation graphique de ces résultats est également proposée dans les figures 4.12, 4.13, 4.14 et 4.15. Pour l’ensemble des expériences effectuées nous pouvons observer des similarités. Tout d’abord, nous pouvons noter que les temps d’exécution obtenus pour FS_SK sont, hormis les valeurs en rouge, meilleurs que pour FS_MPI. Etant donné que la même version séquentielle de code a été utilisée au départ, il s’agit d’une remarque intéressante pour la solution SkelGIS. En effet, cette performance provient de l’objet DMatrix. Cet objet est le seul objet qui n’est pas utilisé dans la version séquentielle, et qui peut être producteur96 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions Taille du maillage Nombre d’itérations Expérience 1 5k × 5k 5k Expérience 2 5k × 5k 20k Expérience 3 10k × 10k 5k Expérience 4 20k × 20k 5k Table 4.6 – Expériences de performance sur FS_MPI et FS_SK. Cœurs Exp1 (sec) Exp2 (sec) Exp3 (sec) Exp4 (sec) MPI SkelGIS MPI SkelGIS MPI SkelGIS MPI SkelGIS 32 4868.43 3494.92 64 2317.7 1780.4 9353.47 7391.96 128 1154.25 898.219 4578.28 3768.54 45588 31332.9 256 578.65 460.715 2282.53 1988.8 22089.9 17385.6 90974,2 68017.1 512 277.39 284.585 1118.01 1117.09 11299.4 9436.11 45487.1 35112.2 1024 144.26 155.85 557.621 602.66 5739.52 5127.93 22299.1 19821.3 2048 67.49 103.363 273.785 407.73 2930.48 3196.71 11867.4 10986.8 Table 4.7 – Temps d’exécution (en secondes) obtenus pour l’ensemble des expériences sur FS_MPI et FS_SK. d’une amélioration de performances (et non de surcoûts) de la version FS_SK. Dans la version FS_SK, l’utilisateur n’a plus à se soucier de coder ses propres structures de données et leur accès efficace. Ce travail est confié à la bibliothèque SkelGIS, ce qui simplifie tout d’abord le code, et ce qui permet d’obtenir une structure optimisée “gratuitement”, sans aucun effort. Ce constat a d’ailleurs également été fait pour l’équation de la chaleur. Coeurs (log2) Temps d'exécution (log2) SkelGIS 32 64 128 256 512 1024 2048 11 9 7 Figure 4.12 – Logarithme des temps d’exécution de l’expérience 1 pour FS_MPI et FS_SK. Cependant, nous pouvons également noter que la pente des courbes des fi- gures 4.12, 4.13, 4.14 et 4.15 est plus accentuée et donc meilleure pour FS_MPI que4.3. Résolution numérique des équations de Saint Venant 97 Coeurs (log2) Temps d'exécution (log2) MPI SkelGIS 64 128 256 512 1024 2048 13 11 9 Figure 4.13 – Logarithme des temps d’exécution de l’expérience 2 pour FS_MPI et FS_SK. Coeurs (log2) Temps d'exécution (log2) MPI SkelGIS 128 256 512 1024 2048 15 13 Figure 4.14 – Logarithme des temps d’exécution de l’expérience 3 pour FS_MPI et FS_SK. Coeurs (log2) Temps d'exécution (log2) MPI SkelGIS 256 512 1024 2048 16 15 Figure 4.15 – Logarithme des temps d’exécution de l’expérience 4 pour FS_MPI et FS_SK. pour FS_SK. En effet, ces figures représentent les temps d’exécution sur une échelle logarithmique. Cette représentation a la particularité de permettre de comparer les temps d’exécution mais également de connaître la linéarité du speedup de la simulation. Si le temps d’exécution présenté est linéaire, le speedup le sera également, et la pente du98 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions temps d’exécution représente également la pente du speedup. Ainsi, il semble que pour l’ensemble des expériences, le speedup de FS_MPI soit légèrement meilleur que celui de FS_SK. Ce phénomène traduit, à l’inverse, les surcoûts de la solution SkelGIS, comme cela a été noté pour l’équation de la chaleur également. En effet, si l’objet DMatrix peut, de son côté, être à l’origine d’un gain de performances, du simple fait que la structure de données qui y est implémentée est plus efficace, les autres objets SkelGIS tels que les applicateurs et les itérateurs provoquent des appels supplémentaires et donc des surcoûts. Notons que ces surcoûts sont plus accentués sur les expériences 1 et 2, ce qui montre qu’il y a plus d’impact sur le nombre d’itérations en temps que sur la taille du domaine à traiter. Ce phénomène s’explique assez bien. À chaque itération de temps, des applicateurs sont appelés. Comme cela a déjà été expliqué, les applicateurs procèdent, tout d’abord, aux communications nécessaires pour les calculs, puis, appellent l’opération de l’utilisateur. Cette opération va ensuite créer des itérateurs et parcourir le maillage. Si le nombre d’itérations en temps augmente, les surcoûts liés aux applicateurs et aux itérateurs sont multipliés, alors que si la taille du domaine augmente, seul le parcours des éléments du maillage est plus long mais les surcoûts, eux, restent identiques. Pour conclure sur les performances de SkelGIS, il semble tout d’abord évident que, partant d’un code séquentiel commun, SkelGIS obtient de très bonnes performances aussi bien en temps d’exécution qu’en passage à l’échelle. SkelGIS offre des perspectives très intéressantes par le biais de l’objet DMatrix. De façon plus générale, la méthode SIPSim offre des performances intéressantes grâce à son composant DDS. En effet, dans le cas d’un maillage cartésien, la structure de données mise en place reste très simple. Dans le cas de maillages plus complexes, ce composant peut se montrer primordial comme cela sera illustré dans le chapitre 5. Si SkelGIS provoque malgré tout des surcoûts qui peuvent nuire à la linéarité de ses speedup, SkelGIS reste tout de même une solution de parallélisme implicite très efficace sur les maillages cartésiens et qui propose des performances proches d’une version MPI comparable. 4.3.4.2 Effort de programmation L’approche SIPSim vise à proposer des solutions de parallélisme implicite pour les simulations scientifiques. Pour cette raison, SkelGIS se doit d’être une solution simple d’utilisation. Nous allons donc présenter les résultats qui ont été obtenus en terme de difficulté de codage, toujours en comparant FS_MPI et FS_SK. Pour ce faire, les mé- triques de Halstead [65] ont de nouveau été mesurées pour ces deux versions parallèles de FullSWOF. Les résultats obtenus sont présentés dans la table 4.8. Nous pouvons tout d’abord observer, dans ces résultats, que l’effort de programmation E à fournir est environ vingt fois moins important pour FS_SK que pour FS_MPI. Ce résultat montre donc que l’ambition de SIPSim, pour proposer des solutions de parallélisme implicite simples, est atteinte. Rappelons que le résultat de l’effort de programmation dans les métriques de Halstead est égal à la multiplication du volume du programme V par la difficulté de codage du programme D. Nous pouvons observer dans ce résultat que le volume de code V produit dans FS_SK est environ cinq fois moindre que dans FS_MPI et que la difficulté D est environ quatre fois moindre dans FS_SK4.4. Conclusion 99 Métriques MPI SkelGIS Gain % N1 7895 2673 66 N2 45147 8507 81 η1 414 297 28.3 η2 414 353 14.7 V 537.1K 104.5K 80.5 D 13274 3576 73 E 7130M 373M 94.7 Table 4.8 – Métriques de Halstead mesurées pour FS_MPI et FS_SK. que dans FS_MPI. Ce résultat est intéressant puisqu’il montre deux aspects différents de simplicité d’utilisation dans SkelGIS. Tout d’abord, le volume du programme parallèle de FullSWOF écrit avec SkelGIS est cinq fois moins important que le volume du programme MPI. Nous avons d’ores et déjà expliqué ce résultat, il est dû à l’utilisation de l’objet DMatrix. En effet, l’utilisation de cet objet permet de s’abstraire de la programmation d’une structure de données dans le code utilisateur, cette structure de données étant entièrement gérée par SkelGIS. De plus, la répartition de cette structure de données sur les différents processeurs est elle aussi entièrement implicite ce qui allège encore davantage le volume du code final. Le second point de simplicité de SkelGIS, illustré par ces résultats, est qu’il est quatre fois plus difficile de coder FS_MPI que FS_SK. Cette métrique est fortement liée au nombre total et distinct d’opérateurs et d’opérandes dans les deux implémentations. Une solution SIPSim ne fait appel qu’à quatre composants principaux et délègue dans ces quatre composants les structures de données, les décompositions de domaine et les communications MPI. Pour cette raison la complexité du code en terme de nombre de variables et d’appels de fonctions est moins importante dans FS_SK. Pour finir, et comme cela a déjà été abordé dans l’état de l’art, les métriques de Halstead ne s’intéressent qu’à des concepts de programmation séquentiels. Ainsi, l’appel à une fonction MPI aura le même coût que l’appel à une fonction classique d’un code séquentiel. Aucune métrique existante ne tient compte de la difficulté des concepts parallèles et de la difficulté de penser le programme en parallèle. Il est très difficile de mettre en œuvre de telles métriques, toutefois il semble évident, dans ce cas, que la véritable difficulté de programmation D de FS_MPI soit supérieure à celle trouvée par les mé- triques de Halstead. SkelGIS de son côté, ne fait appel à aucune notion de parallélisme et est aussi simple à mettre en œuvre, conceptuellement, qu’un code séquentiel. 4.4 Conclusion Dans ce chapitre nous avons décrit l’implémentation de SkelGIS dans le cas particulier des maillages cartésiens à deux dimensions. Nous avons tout d’abord détaillé l’implémentation de cette solution en suivant les composants du modèle SIPSim, puis nous avons100 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions exposé deux cas d’application réels. Le premier sur la résolution de l’équation de la chaleur, et le deuxième sur la résolution des équations de Saint Venant, en suivant la méthode appliquée dans le logiciel FullSWOF2D. Un ensemble de résultats a été présenté, tout d’abord sur les performances de la solution, mais aussi sur l’effort de programmation à fournir pour utiliser SkelGIS. Ces résultats ont été comparés à ceux d’une implémentation MPI implémentée à partir d’un même code séquentiel. Le modèle SIPSim, et donc la bibliothèque SkelGIS, laissant à la charge de l’utilisateur le code séquentiel qui décrit les schémas numériques à calculer, la performance du code final dépend également du code séquentiel implémenté. Il était donc important de partir pour ces deux implémenetations d’une même version séquentielle sans y ajouter d’optimisations séquentielles particulières mais en proposant toutefois une implémentation MPI efficace. Les résultats obtenus sont très intéressants et montrent qu’il est possible de proposer une implémentation du modèle SIPSim efficace, d’autant plus que toutes les implémentations possibles n’ont pas été mises en place, comme par exemple l’utilisation des registres de vectorisation. Cette première implémentation de SkelGIS a donc illustré la viabilité du modèle SIPSim sur des maillages cartésiens à deux dimensions. Il est donc possible, grâce au modèle SIPSim d’implémenter des solutions de parallé- lisme implicite efficace pour les maillages de type cartésiens. Une extension de ce travail peut d’ailleurs proposer une solution pour des maillages cartésiens à n dimensions. De plus, grâce aux travaux OP2 [59, 60, 94] et Liszt [50], nous savons que les concepts du modèle SIPSim peuvent s’appliquer au cas des maillages non-structurés. En effet, OP2 et Liszt proposent des modèles de programmation parallèle implicite proches de ceux proposés par l’approche SIPSim. Le reste de cette thèse propose une implémentation du modèle SIPSim pour un cas d’application qui n’a, à notre connaissance, jamais été traité dans des solutions de parallélisme implicite : les simulations sur des réseaux.5 SkelGIS pour des simulations sur réseaux Sommaire 6.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 101102 Chapitre 5. SkelGIS pour des simulations sur réseaux Le chapitre précédent a présenté l’implémentation de SkelGIS pour les simulations sur des maillages cartésiens à deux dimensions. Dans ce chapitre est abordé un cas plus complexe d’implémentation de la méthode SIPSim. La bibliothèque SkelGIS a, en effet, été implémentée dans le cas de simulations sur des réseaux pouvant être représentés sous forme de graphes dirigés acycliques (DAG). Un réseau n’est pas considéré comme un maillage, même s’il peut s’y apparenter par certains côtés. Dans ce chapitre sera tout d’abord décrite la notion de réseau afin de comprendre pourquoi la méthode SIPSim peut être appliquée à ce type de simulations. Par la suite, l’implémentation de SkelGIS pour les réseaux sera détaillée. Cette implémentation, plus complexe que le cas des maillages cartésiens à deux dimensions, nécessitera une partie supplémentaire décrivant avec précision l’implémentation de la structure de données distribuée. Un cas d’application réel sera ensuite présenté, afin d’évaluer les performances de SkelGIS. Il s’agit d’une simulation d’écoulement du sang dans le réseau artériel. L’implémentation de cette simulation avec SkelGIS sera comparée avec une version OpenMP, et sera évaluée sur différents types de clusters. Enfin, des travaux plus récents seront présentés sur le problème de partitionnement des réseaux. Nous étudierons l’implémentation actuelle de partitionnement dans SkelGIS, puis deux méthodes plus proches du véritable problème de partitionnement des réseaux. 5.1 Les réseaux Afin de faciliter la compréhension de ce chapitre nous allons définir ce qui est appelé un réseau et les caractéristiques qui en découlent. Cette notion est utilisée dans diverses simulations, toutefois, malgré son utilisation fréquente, les détails sur ce qu’est exactement appelé un réseau sont peu abordés dans la littérature. Nous allons illustrer ici qu’un réseau peut être assimilé, par certains côtés, à un maillage. Toutefois un réseau n’est pas un maillage pour plusieurs raisons qui seront présentées. Tout d’abord, il est évident qu’un réseau, en terme de simulation, est une structure permettant de simuler des phénomènes réels de réseaux tels que les réseaux routiers, sanguins, fluviaux, pétrolifères etc. Un réseau permet de discrétiser le domaine en espace en deux types d’éléments différents : les nœuds et les arêtes. Dans le cas d’une simulation d’écoulement du sang dans le réseau artériel, par exemple, les arêtes du graphe sont assimilées aux artères, et les nœuds du graphe aux points de rencontre de plusieurs artères, aussi appelés conjonctions. Les points de rencontre des artères n’ayant pas tous la même connectivité, un réseau est une structure irrégulière. Cette discrétisation peut être apparentée à un graphe dirigé ou non, avec ou sans cycles et projeté dans R 2 ou R 3 . Les deux types d’éléments sont donc les nœuds et les arêtes et à chacun de ces deux types pourront être appliqués deux discrétisations et deux schémas numériques différents (figure 5.1). Un réseau permet donc de résoudre des problèmes représentant deux phé- nomènes physiques différents mais liés entre eux. La notion de réseau rappelle alors les maillages avancés par blocs ou hybrides, qui ont été évoqués dans la section 2.2.2.2 de cette thèse. Un réseau peut être assimilé à un maillage pour deux raisons :5.1. Les réseaux 103 Figure 5.1 – Illustration d’un réseau à gauche et d’un exemple de simulation multi-physique à droite avec deux types de discrétisation. Les nœuds subissent une discrétisation cartésienne de l’espace et les arêtes subissent une discrétisation non-structurée de l’espace. — La construction d’un réseau consiste en la dicrétisation du domaine en deux types d’éléments. — Un réseau représente une connectivité entre ses éléments sous la forme d’un graphe. Pour ces deux raisons, certaines ressemblances avec un maillage, en particulier avec un maillage irrégulier, peuvent être trouvées et utilisées pour l’implémentation. En revanche, un réseau n’est pas un maillage pour deux autres raisons : — Le graphe formé par un réseau ne représente pas des faces ou des cellules, et les calculs appliqués ne porteront pas sur des cellules, contrairement aux maillages. — Le graphe ne forme pas l’objet simulé mais le représente avec deux types d’élé- ments différents, potentiellement très grands, sur lesquels seront effectués des calculs qui peuvent à nouveau discrétiser l’espace. Afin de rendre plus claire la différence entre un maillage et un réseau nous allons essayer d’en donner des définitions par l’intermédiaire de la théorie des graphes. Nous avons d’ores et déjà vu qu’un maillage est un graphe connexe, sans isthme dont la planarité est systématique dans R 2 mais pas dans R 3 . Un réseau est un graphe connexe mais qui peut contenir des isthmes. Autrement dit, les nœuds d’un réseau ne forment pas des faces, ou cycles élémentaires. De plus un réseau, même s’il est plaqué dans R 2 , n’est pas nécessairement planaire contrairement à un maillage. Prenons deux exemples simples qui montrent qu’un réseau n’est pas obligatoirement un graphe planaire, même sur R 2 . Dans un réseau représentant les fleuves et rivières, par exemple, il arrive qu’il existe des rivières souterraines avec un point d’entrée et un point de sortie en surface, comme c’est le cas pour la résurgence de la Loire, appelée le Loiret, par exemple. Par conséquent les arêtes, qui représentent les rivières et fleuves peuvent se croiser sans pour autant qu’un point de conjonction ne soit présent à cette intersection. La même remarque peut être faite sur un réseau routier dans lequel il y aurait des tunnels souterrains, ce qui superposerait plusieurs routes qui ne se rencontrent pas. Un réseau est donc un graphe connexe quelconque. La figure 5.2(a) illustre un graphe planaire qui ne forme pas un104 Chapitre 5. SkelGIS pour des simulations sur réseaux maillage mais un réseau, et la figure 5.2(b) illustre un réseau où des arêtes peuvent se croiser sans l’existence d’un nœud à la conjonction de ces arêtes. (a) Graphe planaire qui ne repré- sente pas un maillage. (b) Graphe connexe quelconque représentant un réseau. Figure 5.2 – Maillages et réseaux. Dans une simulation sur les réseaux deux discrétisations du domaine peuvent être effectuées. La première pour construire le réseau et la deuxième sur chaque élément du réseau, c’est-à-dire l’ensemble des nœuds et des arêtes. De cette façon il est possible d’appliquer des schémas numériques à l’ensemble du domaine tout en définissant deux comportements différents lors de la simulation. Dans un réseau deux types de schémas numériques différents peuvent donc être appliqués, un à chaque type d’élément, les nœuds et les arêtes. Ces deux schémas numériques ont la particularité d’être liés dans une même itération de temps, c’est-à-dire que l’un des deux impacte le résultat de l’autre. Par conséquent, dans une simulation sur les réseaux, même si chaque schéma numérique est explicite et ne crée pas de dépendance parmi les éléments d’une même itération de temps (comme c’est le cas dans l’équation (2.3)), une dépendance peut être créée entre les deux schémas numériques. Il en résulte, soit l’obtention de nouveaux schémas numériques explicites, soit plus généralement l’obtention de nouveaux schémas numériques implicites (équation (2.4)). Si un ou plusieurs schémas implicites sont obtenus, suite à la mise en réseau de chaque schéma explicite, l’un des deux types d’éléments du réseau devra être calculé avant l’autre et son résultat impactera le deuxième dans une même itération de temps. Ainsi si l’on note T1 et T2 les arêtes et les nœuds du réseau, ou vice-versa, une simulation sur un réseau sera typiquement constituée de quatre étapes : 1. communication des éléments T1 à t − 1, 2. calcul des éléments T2 à t, 3. communication des éléments T2 à t − 1 ou/et t, 4. calcul des éléments T1 à t.5.1. Les réseaux 105 L’étape 3 est l’étape qui caractérise le fait que les schémas numériques sont explicites ou implicites. En effet, si l’étape 4, pour être calculée, a besoin des éléments T2 uniquement à l’instant t−1, nous considérons les schémas comme explicites. Si, en revanche, l’étape 4 nécessite les éléments T2 à l’itération t alors les schémas sont implicites. Notons que si les schémas numériques sont explicites alors les étapes peuvent être organisées différemment : 1. communication des éléments T1 et T2 à t − 1, 2. calcul des éléments T1 et T2 à t, La nature des schémas numériques (explicite ou implicite) n’est pas le seul élément impacté par la liaison des schémas numériques d’un réseau. En effet, la notion de voisinage N(x) (ou stencil) est elle aussi modifiée. Dans les schémas numériques d’un réseau, chaque schéma numérique (implicite ou non) possède un voisinage défini par N(x) = Nin(x) ∪ Nout(x). Nin(x) représente le N(x) que l’on peut trouver dans une simulation classique définissant un seul maillage et un seul schéma numérique, il s’agit des éléments voisins de x dans le maillage local. Nout(x) représente le voisinage issu du réseau. En effet, dans un réseau, comme illustré dans la figure 5.1, les différents maillages, et donc les différents schémas numériques sont liés entre eux. Cette liaison se traduit par Nout(x). Notons qu’un élément interne au maillage local n’est pas concerné par la liaison avec un autre maillage et alors Nout(x) = ∅. La définition du voisinage Nout d’un réseau sera étudiée en détails dans la partie 5.2.4.2, et est illustrée dans la figure 5.3. Enfin une dernière caractéristique des réseaux doit être abordée dans cette partie. Un maillage est concerné par ce qui est appelé une bordure physique. Comme il l’a été expliqué précédemment, lorsqu’une simulation est effectuée, l’espace doit être borné alors que le phénomène réel ne l’est pas. Pour cette raison des conditions limites sont ajoutées aux EDP et permettent de simuler de façon plus réaliste ce qui se passe aux bords du domaine. Un réseau, tout comme un maillage, discrétise le domaine initial, il existe donc également une notion de bordure physique dans un réseau. Dans un réseau général, représenté par un graphe quelconque, dirigé ou non, les bordures physiques vont être représentées par certains nœuds indiqués au préalable comme bordures physiques du domaine. Dans le reste de ce chapitre, la définition générale d’un réseau n’est pas utilisée. En effet, nous nous intéressons ici à une sous-partie des réseaux qui peuvent être représentés par un graphe dirigé acyclique, ou DAG. Dans ce cas, les nœuds représentant la bordure physique du domaine sont les nœuds racines et les nœuds feuilles du DAG. Le reste de ce chapitre s’intéresse également à des simulations où les schémas numériques appliqués aux éléments du réseau sont définis dans une unique dimension. Ce travail donne donc une première solution de parallélisme implicite pour les simulations sur les réseaux et étudie sa faisabilité. A notre connaissance, aucun travail similaire n’existe à l’heure actuelle.106 Chapitre 5. SkelGIS pour des simulations sur réseaux 5.2 SIPSim pour les réseaux Tout comme pour l’implémentation de SkelGIS pour les maillages cartésiens, nous allons tout d’abord décrire l’implémentation des quatre composants de la méthode SIPSim pour le cas des simulations sur les réseaux. 5.2.1 Structure de données distribuée Tout comme pour l’implémentation de la méthode SIPSim pour les grilles carté- siennes à deux dimensions, le premier composant de la méthode SIPSim à implémenter est la structure de données distribuée (DDS) permettant de représenter le maillage et sa connectivité. Comme il l’a été décrit précédemment, un réseau ne peut pas être considéré comme un maillage, toutefois il s’en approche puisque, tout comme un maillage, il consiste à discrétiser le domaine en éléments et à en représenter leur connectivité. Pour cette raison la structure de données distribuée qui représente le réseau doit posséder les mêmes caractéristiques qu’un maillage, et la méthode SIPSim s’applique donc parfaitement à ce type de simulations. La structure de données doit donc garantir un accès efficace aux éléments (nœuds et arêtes) et aux voisinages Nout. Ce DDS, là encore, va être responsable de l’efficacité de la solution, et l’ensemble de l’implémentation de la méthode SIPSim pour les réseaux repose sur ce premier composant. Rappelons que nous nous intéressons ici à la sous classe des réseaux pouvant être représentés sous forme de DAG. La DDS pour ces réseaux est nommée DDAG. L’implémentation de ce DDS est complexe, et la section 5.3 décrira en détails cette implémentation. Bien évidemment, la difficulté majeure se trouve dans le fait qu’un réseau est une structure irrégulière où la connectivité est différente pour chaque élément, là où elle est régulière pour les grilles cartésiennes. Une structure de données irrégulière va donc tout d’abord poser un problème d’efficacité pour accéder aux éléments et à leur voisinage. La résolution de ce premier problème sera entièrement décrite dans la section 5.3. Mais outre cette difficulté, une structure irré- gulière pose un autre problème, qui lui aussi impacte de façon significative l’efficacité de la solution. En effet la méthode SIPSim implémente des solutions SPMD ce qui implique une bonne décomposition de domaine pour obtenir de très bonnes performances. Dans le cas des réseaux, cette décomposition de domaine va se traduire par un problème de partitionnement de graphe. Le problème du partitionnement de graphe est un problème connu et NP-complet, ce qui signifie que des heuristiques sont appliquées pour approcher au mieux la solution idéale en un temps raisonnable. Le partitionnement de réseau est particulier par rapport à un partitionnement de graphe classique où il est considéré que des calculs sont faits soit sur les nœuds, soit sur les arêtes. Dans le cas d’un ré- seau des calculs sont effectués sur les deux types d’éléments et impactent l’équilibrage de charge. L’heuristique implémentée dans le prototype actuel de SkelGIS ainsi que deux autres algorithmes seront étudiés dans la section 5.5. En effet, dans la version actuelle de SkelGIS, une heuristique de rattachement des arêtes sœurs a été implémentée. Cette solution propose des résultats raisonnablement bons, comme nous le verrons dans la partie d’évaluation 5.4, toutefois il est probable qu’avec les deux autres solutions étudiées dans5.2. SIPSim pour les réseaux 107 la section 5.5, qui utilisent du partitionnement d’hypergraphe, les performances soient meilleures. Lors d’un partitionnement de graphe, et donc d’un partitionnement de réseau, la solution idéale n’est que rarement trouvée et il persiste toujours un léger déséquilibre dans la solution de partitionnement. Pour cette raison, un point essentiel pour améliorer les performances de la solution est d’opérer un recouvrement des communications avec les calculs locaux. En effet, dans un programme parallèle de type SPMD pour du calcul stencil, chaque sous-domaine en espace appartenant à chaque processeur peut être dé- composé en deux parties. Une première partie est dite locale-interne. Cette partie peut être calculée sans aucun échange avec les autres processeurs. La deuxième partie localeexterne, en revanche, nécessite des communications avec les autres processeurs afin de connaître les valeurs au bord du domaine local. Dans un mécanisme de recouvrement des communications par les calculs, le programme se découpe alors en quatre étapes : 1. les communications non bloquantes MPI sont initialisées 2. les calculs sur la partie locale-interne sont effectués 3. les communications non bloquantes MPI sont terminées 4. les calculs sur la partie locale-externe sont effectués Ce mécanisme a été mis en place pour l’implémentation de la méthode SIPSim sur les réseaux (SkelGIS pour les réseaux). Ce mécanisme est possible par l’optimisation de la structure de données distribuée qui sera décrite dans la section 5.3. 5.2.2 Application de données L’objet DDAG renferme donc une structure de données lourde et complexe, contrairement à l’implémentation de l’objet DMatrix. Cette complexité est due au fait qu’il est nécessaire, pour chaque élément de la structure, de retenir la connectivité qui lui est propre. Chaque élément a, en effet, potentiellement une connectivité différente. Pour cette raison, l’implémentation de SkelGIS pour les réseaux reste fidèle à la méthode SIPSim. En effet, pour l’implémentation des DMatrix le choix a été fait d’embarquer le composant DPMap dans le DDS lui-même, celui-ci étant léger. Dans le cas des réseaux, le DDS DDAG étant beaucoup plus lourd, il sera instancié une seule fois pour chaque type de réseau de la simulation, puis des objets plus légers se chargeront d’appliquer les données sur ce DDS. Ces objets sont de deux types, un pour appliquer des données sur les nœuds du réseau, et l’autre pour appliquer des données sur les arêtes du réseau. Ils sont nommés respectivement DPMap_Nodes et DPMap_Edges. Ce sont ces objets qui seront instanciés pour définir les quantités simulées dans les schémas numériques et ainsi pour obtenir σ. 5.2.3 Applicateurs et opérations Une fois le DDAG défini et les quantités à simuler instanciées, il faut appliquer les schémas numériques séquentiels. L’utilisateur va alors, comme pour les DMatrix, définir des opérations séquentielles qui vont représenter ses schémas numériques. Libre à lui de108 Chapitre 5. SkelGIS pour des simulations sur réseaux définir autant d’opérations que nécessaire, sa seule contrainte est d’appliquer ses opérations par le biais d’applicateurs. Il en existe deux à l’heure actuelle pour les réseaux, ils s’appellent apply_list et apply_listi. Ce sont des procédures définies par : apply_list : {DPM ap_Edges} × {DPM ap_Nodes} × Op (5.1) apply_listi : {T1} × {T2} × Op1 × Op2 (5.2) où {DPM ap_Edges}, {DPM ap_Nodes}, {T1} et {T2} sont des ensembles d’instances des objets DPM ap_Edges et DPM ap_Nodes, et Op, Op1 et Op2 des opérations. Le premier applicateur effectue tout d’abord les communications afin d’obtenir les valeurs voisines, et non locales, nécessaires aux calculs des quantités (DPMap) indiquées en argument. L’applicateur appelle ensuite l’opération Op de l’utilisateur. Ce premier applicateur peut être particulièrement intéressant pour l’application de schémas numériques explicites car il a la particularité d’offrir beaucoup de libertés à l’utilisateur. En effet, l’utilisateur peut librement écrire une opération qui agira sur les nœuds comme sur les arêtes, dans l’ordre souhaité. Les schémas numériques étant explicites, seules les communications effectuées avant l’appel à l’opération sont nécessaires. Toutefois, ces opérations, très générales, ne peuvent être mises en place pour des schémas numériques implicites, puisqu’alors des communications sont nécessaires entre les phases de calcul. Cependant, il est tout de même possible d’appliquer des schémas numériques implicites avec ce premier applicateur. Dans ce cas, il sera nécessaire d’appeler l’applicateur à chaque phase du calcul afin d’effectuer implicitement les échanges de données nécessaires. Il n’est alors pas évident de définir l’utilisation de l’applicateur, ni de comprendre son utilisation. Pour cette raison, un deuxième applicateur est proposé et permet d’effectuer des calculs implicites en quatre étapes, comme présenté dans la partie 5.1. Cet applicateur commencera par (1) effectuer une première phase de communication des éléments de type T1 (calculés à l’itération t − 1), puis (2) appellera l’opération Op2 sur les éléments de type T2. Par la suite, (3) une deuxième phase de communication aura lieu pour échanger les éléments de type T2 venant d’être calculés ( à l’itération t donc), pour enfin (4) appeler l’opération Op1 qui effectue les calculs sur les éléments T1. Notons, de nouveau, que T1 et T2 peuvent alors être associés indifféremment aux nœuds ou aux arêtes du réseau. 5.2.4 Interfaces de programmation Enfin afin de pouvoir programmer une opération le dernier composant de la méthode SIPSim doit être implémenté. Il s’agit des interfaces de programmation qui sont regroupées en trois types précédemment décrits, les itérateurs, les accesseurs, et les fonctions pour accéder aux voisinages des éléments. 5.2.4.1 Itérateurs Les itérateurs permettent de se déplacer dans des données appliquées à un DDS. Dans le cas des réseaux, les itérateurs permettent donc de se déplacer dans des instances des objets DPMap_Nodes et DPMap_Edges. Il existe huit itérateurs pour les réseaux, trois pour l’objet DPMap_Edges et cinq pour l’objet DPMap_Nodes.5.2. SIPSim pour les réseaux 109 Rappelons que, tout comme pour les DMatrix, l’ordre de parcours de l’ensemble des nœuds ou de l’ensemble des arêtes du réseau n’a pas d’importance, et que la solution obtenue sera la même si l’ordre de parcours est modifié. En effet, comme expliqué dans la partie 5.1, le seul ordre de traitement peut venir des phases de calcul sur les nœuds ou sur les arêtes. Ceci est dû au fait que les deux schémas numériques explicites (2.3) de départ n’introduisent pas de dépendances entre les nœuds d’une même itération de temps, ou entre les arêtes d’une même itération de temps. Nous allons décrire les trois itérateurs communs aux objets DPMap_Nodes et DPMap_Edges. Tout d’abord, un premier itérateur permet simplement de parcourir l’ensemble des nœuds/arêtes du réseau et cet itérateur garantit que l’ensemble des nœuds/arêtes est bien parcouru. Cet itérateur est ensuite divisé en deux itérateurs qui vont permettre de parcourir les nœuds/arêtes locaux-internes et locaux-externes précédemment décrits. Ces deux itérateurs seront utilisés pour effectuer le recouvrement des communications MPI par les calculs locaux dans les applicateurs. Deux itérateurs supplémentaires ont été implémentés afin de naviguer dans la bordure physique du domaine. Il a été décrit dans la section 5.1 que les bordures physiques, dans le cas d’un réseau de type DAG, étaient représentées par deux types particuliers de nœuds, les racines et les feuilles du DAG. Un premier itérateur sur les bordures physiques permet donc de naviguer dans les racines du DAG, et un deuxième dans les feuilles du DAG. Tout comme pour les DMatrix, ces deux itérateurs sont très importants pour éviter des conditions inutiles dans le code utilisateur afin de déterminer si le nœud courant est une racine, une feuille ou un nœud interne. Avec l’ensemble de ces itérateurs, l’utilisateur peut naviguer dans la bordure physique et dans les nœuds internes sans conditions dans le code. Notons que l’implémentation de ces itérateurs est possible, là encore, grâce aux optimisations de la DDS DDAG qui sera décrite dans la section 5.3. 5.2.4.2 Voisinages La notion de voisinage est l’une des notions les plus importantes de la méthode SIPSim puisqu’elle rend possible les calculs stencil et donc la résolution des EDP. Il est important, tout d’abord, de définir quel voisinage Nout est nécessaire autour d’un nœud et d’une arête du réseau pour qu’ils puissent être calculés. La figure 5.3 illustre le voisinage nécessaire. Pour un nœud du réseau, le voisinage nécessaire peut être constitué des arêtes entrantes et sortantes. Pour une arête du réseau, les informations nécessaires sont les nœuds source et destination de l’arête. Par conséquent, les interfaces permettant de connaître le voisinage d’un nœud sont constituées de deux fonctions pour obtenir une liste des arêtes entrantes et sortantes, la première notée getInEdges, et la deuxième notée getOutEdges. Ces fonctions retournent un vecteur d’itérateurs sur les arêtes entrantes et sortantes. Quant aux interfaces pour le voisinage d’une arête il s’agit de deux fonctions, l’une pour connaître le nœud source, notée getSrcNode, et l’autre pour connaître le nœud destination, notée getDstNode. Cependant ce voisinage peut être plus complexe dans certains cas. En effet, comme nous l’avons évoqué précédemment, une simulation sur les réseaux est une sous-partie des simulations multi-physiques. Cela signifie que potentiellement deux discrétisation110 Chapitre 5. SkelGIS pour des simulations sur réseaux ARÊTES ENTRANTES ET SORTANTES NOEUD SOURCE VOISINAGE DES NOEUDS VOISINAGE DES ARÊTES NOEUD DESTINATION Figure 5.3 – Voisinage d’un nœud et d’une arête d’un réseau. différentes peuvent être effectuées dans les nœuds et les arêtes afin de simuler deux phénomènes liés ensemble par un réseau. SkelGIS se limite, comme nous l’avons vu, aux discrétisations à une dimension dans les nœuds et les arêtes. SkelGIS offre donc la possibilité de définir que chaque arête ou nœud contient un tableau et non un unique élément. Cette notion est très importante pour pouvoir appliquer des schémas numériques à une dimension sur les arêtes ou les nœuds. Bien entendu, cette notion pourrait être étendue à un schéma numérique à deux dimensions et plus, mais le prototype actuel de SkelGIS n’implémente pas ces fonctionnalités. Par exemple, dans une simulation sanguine sur le réseau artériel, l’écoulement du sang dans une artère est simulé par des équations d’écoulement des fluides. Par conséquent, il faut simuler l’écoulement dans une artère par un maillage, que nous supposerons à une dimension. Dans ce cas il est important de se demander ce que devient le voisinage nécessaire pour un nœud. Ce voisinage est alors lié, tout comme pour les DMatrix, à l’ordre du schéma numérique appliqué dans les arêtes du réseau. La figure 5.4 illustre ce voisinage dans le cas d’un schéma d’ordre 2. En effet, dans ce cas, le nœud source de l’arête n’a pas besoin de connaître l’ensemble du maillage 1D géré par l’arête, mais uniquement ses deux premières valeurs. De même le nœud destination n’a besoin de connaître que les deux dernières valeurs du maillage de l’arête. ordre=2 Figure 5.4 – Voisinage pour le cas particulier d’un maillage 1D dans les arêtes. Cette notion avancée de voisinage est très importante afin de ne pas échanger des données inutiles lors des communications MPI. En d’autres termes, il est très important, pour l’efficacité du programme parallèle, que les communications MPI effectuées représentent réellement le voisinage Nout nécessaire. Il serait en effet dommage de communiquer tout le tableau deux fois pour chaque arête. Cette notion peut paraître compliquée, toutefois5.2. SIPSim pour les réseaux 111 nous allons voir dans la partie qui suit, que l’utilisation des spécialisations partielles de templates simplifie l’utilisation de ces concepts. 5.2.5 Spécialisation partielle de template Tout comme dans le cas des maillages cartésiens à deux dimensions, le mécanisme de spécialisation de template a été utilisé pour SkelGIS dans son implémentation pour les réseaux. Une fois encore, la détermination des bons paramètres de template permet d’éviter des conditions coûteuses dans le code et permet d’éviter la mise en place du système d’héritage virtuel du C++, coûteux à l’exécution. Nous avons vu pour l’objet DMatrix que ses spécialisations étaient liées à la valeur de son ordre, ainsi qu’à la définition de sa connectivité. Pour les réseaux, les paramètres sont également liés au voisinage nécessaire (l’ordre de la simulation) mais également au type de données appliquées aux arêtes ou aux nœuds du réseau. Tout d’abord, contrairement à l’objet DMatrix de SkelGIS, l’objet DDAG ne concerne que la définition du réseau et sa connectivité et non les données qui lui sont associées. Pour cette raison, conformément à la méthode SIPSim, cet objet est peu manipulé par l’utilisateur. Bien que l’objet DDAG soit responsable de l’efficacité de l’ensemble de la solution, et que l’ensemble de l’implémentation repose sur lui, les spécialisations de templates ne portent pas sur lui mais sur les données qui y sont appliquées, les DPMap. De cette manière, les choix effectués pour les voisinages ne sont pas figés pour toutes les données de la simulation, ce qui laisse plus de liberté à l’utilisateur. Comme nous l’avons vu précédemment, certaines quantités à simuler peuvent en effet participer au schéma explicite (2.3) par le calcul de σ(x, t − 1), mais pas par le calcul de σ(y, t − 1); y ∈ N(x). Il est donc important pour l’efficacité de la solution de laisser la notion de voisinage au niveau des quantités à simuler et non au niveau du réseau. La figure 5.5 donne la définition des objets DPMap_Edges et DPMap_Nodes. Le premier paramètre de template, appelé T, indique le type de données à appliquer sur le réseau. Le deuxième paramètre, appelé node_access va donner des indications sur la participation de l’instance au calcul de N(x). template struct DPMap_Edges template struct DPMap_Nodes Figure 5.5 – Définition des objets DPMap_Edges et DPMap_Nodes. Les deux paramètres T et node_access sont liés dans leur spécialisation. Deux cas de spécialisation se présentent pour le paramètre T, et suivant ce cas la spécialisation de node_access sera différente. Le paramètre T représente le type de données qui va être appliqué au réseau. Ce peut être (1) soit un type de base du C++, comme int, float, double etc., (2) soit un pointeur d’un type de base, autrement dit un tableau à une dimension, comme int∗, float∗, double∗ etc. 1. Dans le premier cas, cela signifie que la donnée associée à chaque nœud ou chaque arête du réseau ne contiendra qu’une unique valeur. Dans ce cas node_access pourra112 Chapitre 5. SkelGIS pour des simulations sur réseaux prendre seulement deux valeurs, 0 ou 1. Si node_access = 0, alors cela signifie que la quantité instanciée n’est pas concernée par les calculs du type N(x), et que cette quantité est donc uniquement utilisée localement. Dans ce cas les échanges MPI n’auront pas lieu sur cette quantité ce qui améliorera les performances. À l’inverse, si node_access = 1, la quantité sera utilisée dans les calculs du type N(x) et les échanges MPI seront effectués. 2. Dans le cas où T est un type pointeur, ce qui signifie que chaque nœud ou chaque arête du réseau est associé à un tableau de valeurs, nous aurons, node_access ∈ J0, nK où n est le nombre d’éléments dans le tableau. Comme dans le cas précédent si node_access = 0 alors la quantité à simuler n’interviendra pas dans les calculs du type N(x) et les échanges MPI n’auront pas lieu. Si node_access > 0 alors la valeur de node_access indique l’ordre du schéma numérique qui sera appliqué dans les nœuds ou dans les arêtes, et indique donc l’échange nécessaire pour effectuer le calcul. Notons que si node_access = 1, il s’agit d’un cas plus simple à gérer, une spécialisation de ce cas est donc implémentée. Les cinq spécialisations de templates nécessaires à l’objet DPMap_Edges, pour gérer ces cas, sont présentées dans la figure 5.6. template struct DPMap_Edges template struct DPMap_Edges template struct DPMap_Edges template struct DPMap_Edges template struct DPMap_Edges template struct DPMap_Edges Figure 5.6 – Spécialisations partielles de template pour l’objet DPMap_Edges Les notions complexes de voisinage présentées dans la section précédente sont donc entièrement gérées grâce à deux paramètres de template spécialisés. L’utilisateur n’a qu’à se soucier du type d’éléments dans les nœuds et les arêtes et de l’ordre du schéma numérique 1D appliqué, pour que l’ensemble soit optimisé en terme de communications MPI. 5.3 Structure de données distribuée pour les réseaux Dans la section précédente, le DDS DDAG pour les simulations sur les réseaux a été présenté. Nous détaillons dans cette partie l’implémentation de cette structure de données distribuée [44]. Comme toute DDS de la méthode SIPSim, cet objet est en grande partie responsable de l’efficacité de la solution. Son implémentation dérive du format Compressed Sparse Row (CSR) que nous allons tout d’abord décrire. L’adaptation et la parallélisation du format CSR seront ensuite présentées pour enfin expliquer comment s’articule l’implémentation générale de SkelGIS pour les réseaux autour de ce DDS. Notons qu’une version parallèle du format CSR a déjà été proposée, et fait partie de5.3. Structure de données distribuée pour les réseaux 113 la bibliothèque PBGL [51, 62]. Toutefois, cette implémentation n’est pas spécifiquement développée pour les simulations scientifiques basées sur des maillages. Notre implémentation propose un certain nombre d’optimisations propres aux réseaux et aux simulations, que nous allons décrire dans cette section. 5.3.1 Le format Compressed Sparse Row La variation à trois tableaux du format Compressed Sparse Row (CSR) permet de stocker des matrices creuses de façon relativement légère puisqu’il permet de ne stocker que les éléments qui ne sont pas des zéros, aussi appelés des éléments non-nuls dans le reste de ce travail. Ce format est donc constitué de trois tableaux dont voici la description : — values contient les valeurs des éléments non-nuls qui sont stockés ligne après ligne. — columns est de même taille que le tableau précédent. L’élément i du tableau columns contient l’index de colonne associé à l’élément i du tableau values. — rowIndex est le dernier tableau du format dans lequel l’élément i contient l’index, dans le tableau values, du premier élément non-nul de la ligne i de la matrice. Notons qu’un premier élément factice, égal à zéro, est ajouté au début du tableau rowIndex de telle sorte que la ligne i contient rowIndex[i+1]−rowIndex[i] éléments nonnuls. Pour pouvoir accéder à un élément non-nul, avec le format CSR, en connaissant ses index de ligne et de colonne (i, j), il faut trouver la valeur j entre les éléments columns[rowIndex[i]] et columns[rowIndex[i + 1] − 1]. L’index k auquel est trouvée la valeur j représente alors l’index dans le tableau values où se trouve l’élément nonnul recherché. Pour cette raison, le format CSR est peu efficace pour manipuler, de façon répétée, des accès aux éléments d’une matrice creuse avec les index de lignes et de colonnes. Cependant, nous allons montrer que ce format peut être très efficace pour stocker la connectivité d’un graphe. Un graphe non-orienté est défini par G = (V, E) où V est un ensemble fini de nœuds et E ⊆ V × V est un ensemble fini d’arêtes. La matrice Sp(G) associée au graphe G représente la matrice d’adjacence du graphe G, comme illustré dans la figure 5.7. Dans une matrice d’adjacence, chaque élément non-nul de la matrice représente une arête e ∈ E du graphe G, et les index de ligne et de colonne représentent les deux nœuds aux extrémités de l’arête. Notons donc que pour un graphe non-orienté, la matrice Sp(G) est symétrique. Dans un graphe G = (V, E), vi et vj ∈ V sont appelés des nœuds voisins si (vi , vj ) ∈ E. En d’autres termes, deux nœuds sont voisins si deux éléments non-nuls existent dans la matrice Sp(G) aux emplacements (vi , vj ) et (vj , vi). Pour tout v ∈ V, N(v) est l’ensemble des nœuds voisins du nœud v. Le degré d’un nœud v ∈ V , noté deg(v), est le nombre d’arêtes incidentes de v, ce qui signifie que deg(v) = |N(v)|. Dans la ligne v de la matrice Sp(G), N(v) représente les index des colonnes où des éléments non-nuls sont présents. Définition 2 Dans un graphe non-orienté G = (V, E) où V = {v0, ..., vn−1}, le degré cumulé d’un nœud vi ∈ V est noté cdeg(vi) et est défini par cdeg(vi) = Pi j=0 deg(vj ).114 Chapitre 5. SkelGIS pour des simulations sur réseaux 0 1 2 3 4 5 6 7 1 1 10 0 0 0 0 01 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Figure 5.7 – Graphe non orienté G et sa matrice d’adjacence Sp(G). Dans la matrice Sp(G), cdeg(vi) représente le nombre d’éléments non-nuls de la ligne vi additionné au nombre d’éléments non-nuls des lignes précédentes. Il est donc possible de représenter G avec deux tableaux : — Le premier, de taille n + 1 = |V | + 1, et appelé cdeg, est défini par cdeg[i + 1] = cdeg(vi), ∀i ∈ J0, nJ, où cdeg[0] = cdeg(v−1) def = 0. — Le deuxième, appelé N est de taille cdeg[n] = cdeg(vn−1) et est défini pour tout vi ∈ V par, N(vi) = {vN[j] |j ∈ [cdeg[i], cdeg[i + 1][}. Cette représentation, en utilisant deux tableaux pour stocker un graphe G, correspond en fait au format CSR pour la matrice Sp(G). En effet, les tableaux cdeg et N de G correspondent aux tableaux rowIndex et columns de Sp(G). La figure 5.7 nous donne un graphe et sa matrice d’adjacence. Dans ce graphe le nœud 0 a deux nœuds voisins, 1 et 2, nous avons alors la deuxième valeur du tableau cdeg égale à 2, et les deux premières valeurs de N égales à 1 et 2. Le nœud 1 a ensuite trois voisins, la troisième valeur de cdeg est alors cdeg[2] = 2 + 3 = 5. En procédant ainsi pour chaque nœud du graphe, nous obtenons, cdeg = [0, 2, 5, 6, 7, 11, 12, 13, 14] et N = [1, 2, 0, 3, 4, 0, 1, 1, 5, 6, 7, 4, 4, 4]. Grâce à cette représentation du graphe avec deux tableaux, il est possible, par exemple, d’accéder très facilement au voisinage du nœud 4. En effet, cdeg[4] = 7 et cdeg[5]−1 = 10 indiquent le premier et le dernier index de N où se trouvent les voisins du nœud 4. Les nœuds voisins du nœud 4 sont donc les nœuds 1, 5, 6 et 7. De façon plus générale, supposons que les données associées à chaque nœud soient stockées dans un troisième tableau X tel que |X| = |V |. Alors, pour accéder aux valeurs voisines d’un nœud vi , il suffit d’accéder aux éléments N[cdeg[i]] à N[cdeg[i + 1] − 1] dans X. Le format CSR, initialement fait pour stocker des matrices creuses, est donc un format très intéressant pour stocker la connectivité d’un graphe et pour retrouver en O(1) les voisins d’un nœud du graphe.5.3. Structure de données distribuée pour les réseaux 115 5.3.2 Format pour les DAG distribués Comme nous l’avons indiqué dans la section 5.1, l’implémentation actuelle de SkelGIS n’a été développée que pour le sous-cas des réseaux pouvant être représentés par des DAG (par exemple celui de la figure 5.8). Cette partie va étudier l’adaptation du format CSR, décrit dans la partie précédente, pour les DAG. Nous allons décrire comment ce format a été optimisé pour le cas des simulations scientifiques, et comment il a été parallélisé. Un graphe orienté G = (V, E) est un graphe pour lequel chaque arête e = (v1, v2) ∈ E est dirigée de v1 vers v2, et où v1 et v2 sont respectivement appelés le nœud source et le nœud destination de l’arête e. Un graphe orienté acyclique (DAG) est un graphe G = (V, E) orienté tel que pour tout v ∈ V , il n’y a pas de chemin, en suivant les arêtes successives, de v vers lui même. Dans les simulations scientifiques sur les DAG, pour être calculé, un nœud peut avoir besoin de ses arêtes entrantes et de ses arêtes sortantes. De son côté, pour être calculée, une arête a uniquement besoin de son nœud source et de son nœud destination (figure 5.3). Dans un DAG G = (V, E), pour un nœud v ∈ V et une arête e ∈ E, S(e) est le nœud source de e et D(e) est le nœud destination de e. N + V (v) décrit l’ensemble des nœuds sortants de v ∈ V et est défini par N + V (v) = {v 0 |(v, v0 ) ∈ E}. N + E (v) est l’ensemble des arêtes sortantes de v ∈ V et est défini par N + E (v) = {e ∈ E|S(e) = v}. De façon symétrique, N − V (v) et N − E (v) sont définis comme les ensembles de nœuds et arêtes entrantes de v ∈ V . Un nœud racine v ∈ V d’un DAG G vérifie que |N − E (v)| = 0. À l’inverse, un nœud feuille v ∈ V vérifie que |N + E (v)| = 0. La définition 2 doit alors être adaptée au cas des DAG pour les éléments entrants dans un nœud et ceux sortants d’un nœud. Dans un DAG G = (V, E), où V = {v0, ..., vn−1}, pour un nœud vi ∈ V , cdeg+(vi) = Pi j=0 |N + E (vj )| définit le degré cumulé sortant pour le nœud vi , cdeg−(vi) = Pi j=0 |N − E (vj )| définit le degré cumulé entrant pour le nœud vi . Notons ici que les degrés cumulés ont la particularité d’être les mêmes pour les arêtes et les nœuds d’un DAG. En effet, pour un nœud v ∈ V , le nombre de nœuds entrants est égal au nombre d’arêtes entrantes. De même le nombre de nœuds sortants est égal au nombre d’arêtes sortantes : ∀vj ∈ V , |N + E (vj )| = |N + V (vj )| et |N − E (vj )| = |N − V (vj )|. Comme dans la partie précédente, les tableaux cdeg+ et cdeg−, de taille |V |+1 = n+1, sont définis par cdeg+[i + 1] = cdeg+(vi) et cdeg−[i + 1] = cdeg−(vi), où cdeg+[0] = cdeg−[0] = 0. Enfin il est également possible de définir les tableaux N + E et N − E de taille cdeg+[n] et cdeg−[n] qui représentent les index de voisinage associés aux degrés cumulés. Enfin, deux tableaux S et D de taille |E| représentent l’ensemble des nœuds sources et destinations pour chaque arête de telle sorte que S[i] = S(ei) et D[i] = D(ei), ∀ei ∈ E. La figure 5.8 représente un DAG simple que nous allons prendre comme exemple pour cette nouvelle structure de données. Le nœud 0 n’a pas de voisin entrant mais a deux voisins sortants. Par conséquent, la deuxième valeur de cdeg− est égale à 0, et la deuxième valeur de cdeg+ est égale à 2. Les index des voisinages associés sont stockés dans N + E et N − E . Nous obtenons les tableaux suivants : cdeg+ = [0, 2, 4, 4, 4, 7, 7, 7, 7], cdeg− = [0, 0, 1, 2, 3, 4, 5, 6, 7] N + E = [0, 1, 2, 3, 4, 5, 6], N − E = [0, 1, 2, 3, 4, 5, 6]116 Chapitre 5. SkelGIS pour des simulations sur réseaux S = [0, 0, 1, 1, 4, 4, 4], D = [1, 2, 3, 4, 5, 6, 7] 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 Figure 5.8 – Graphe orienté acyclique correspondant au graphe 5.7. La structure de données ainsi obtenue est adaptée aux DAG. En revanche, cette structure de données ne comporte aucune optimisation spécifique pour les simulations scientifiques et n’est pas non plus encore une structure de données distribuée. Nous allons décrire ces deux points dans le reste de cette partie. Notons que cette section ne s’intéresse pas au partitionnement d’un graphe orienté acyclique, que nous verrons dans la section 5.5, mais uniquement à la structure de données permettant de stocker les informations locales à chaque processeur de façon efficace. Une fois le partitionnement de graphe effectué, chaque processeur reçoit donc une partie du graphe de départ avec ses index globaux. Étant donné que la structure de données, vue précédemment, repose sur une indexation contiguë commençant à 0 pour les tableaux, cela implique tout d’abord qu’une ré-indexation locale va être nécessaire pour la version distribuée de la structure. La figure 5.9 montre un graphe global partitionné pour quatre processeurs. Nous nous intéressons à la partie bleue de ce graphe global, qui va être distribuée au processeur 1. Ce sous-graphe G1 = (V1, E1) possède |V1| = 8 nœuds et |E1| = 7 arêtes. La partie bleue de ce DAG n’est toutefois pas la seule partie à laquelle devra s’intéresser le processeur 1. En effet, pour gérer comme il se doit les voisinages des nœuds et des arêtes, des informations supplémentaires, provenant d’autres processeurs, seront nécessaires. La figure 5.10(a) montre les nœuds et arêtes dont le processeur 1 aura besoin pour effectuer convenablement ses calculs. On y retrouve la partie bleue du graphe global mais également des nœuds et arêtes additionnels en pointillés. Ces nœuds et ces arêtes sont des données qui ne sont pas locales au processeur 1 mais dont le processeur 1 aura besoin pour effectuer ses calculs. Ces données devront donc être insérées dans la structure pour permettre les calculs et être accessibles efficacement pour assurer de bonnes performances. Le premier point auquel s’intéresser pour distribuer la structure de données est donc5.3. Structure de données distribuée pour les réseaux 117 0 2 0 3 1 6 5 7 6 7 1 2 4 3 5 4 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 21 22 22 23 23 24 24 26 27 25 28 Figure 5.9 – DAG global partitionné pour quatre processeurs. Le processeur 1 récupère la partie bleue de ce partitionnement. de ré-indexer le graphe local de chaque processeur afin de pouvoir utiliser les tableaux présentés précédemment. La ré-indexation des arêtes est la plus simple. Elle peut être quelconque. Dans la figure 5.10 la ré-indexation consiste à numéroter les arêtes de haut en bas et de gauche à droite. La ré-indexation des nœuds locaux, quant à elle, a été pensée afin d’optimiser l’utilisation des lignes de cache et de limiter les défauts de cache. Cette optimisation est liée au fait que l’on cherche à résoudre des simulations scientifiques et à leurs caractéristiques particulières. L’optimisation de la ré-indexation des nœuds consiste à ordonner les nœuds par classe de façon à pouvoir se déplacer dans la classe de nœuds de façon contiguë en mémoire. Quatre classes de nœuds ont été identifiées. Tout d’abord, il a été présenté dans la section 5.2 l’intérêt d’un recouvrement des communications par118 Chapitre 5. SkelGIS pour des simulations sur réseaux 0 2 7 3 7 8 10 11 15 16 17 18 6 0 1 8 2 9 3 9 10 12 4 13 5 14 6 11 12 13 14 15 (a) Partie du graphe global qui intéresse le processeur 1 pour gérer ses données locales et les voisinages nécessaires. 8 2 7 9 3 8 10 11 12 13 14 15 0 0 1 7 2 1 3 9 10 6 4 4 5 5 6 11 12 13 14 15 (b) Ré-indexation du sous-graphe géré par le processeur 1. Figure 5.10 – Sous-graphe géré par le processeur 1 avant et après ré-indexation. les calculs, afin de limiter le déséquilibrage de charge d’un partitionnement du domaine pour les différents processeurs. Cette technique connue du parallélisme repose sur le fait que les communications, nécessaires pour calculer les éléments au bord du domaine local, sont recouvertes par les calculs purement locaux qui peuvent d’ores et déjà être effectués. Pour cette raison les deux premières classes de nœuds de la ré-indexation sont les nœuds locaux-internes du domaine et les nœuds locaux-externes du domaine. Les premiers ne nécessitent pas de communications avec les autres processeurs pour être calculés, à l’inverse des seconds. Il a également été présenté dans les sections 2.2 et 5.1 que les simulations scientifiques, pour être plus réalistes sur le phénomène simulé, opèrent des comportements particuliers pour les éléments de la bordure physique du domaine global étudié. De plus, dans un réseau de type DAG, les nœuds de la bordure physique ne sont autres que les feuilles et les racines du DAG. Les deux autres classes de nœuds concernées par la ré-indexation sont donc les feuilles, puis les racines. Le passage de la figure 5.10(a) à la figure 5.10(b) illustre cette ré-indexation des nœuds locaux (en traits continus) en quatre classes, et la figure 5.11 résume ce système de ré-indexation. Cette ré-indexation des éléments locaux à un processeur possède deux avantages en terme de performances. Tout d’abord, elle favorise la bonne utilisation des lignes de mé- moire cache. En effet, dans une simulation scientifique sur les réseaux, toutes les racines vont être explorées afin de décrire leur comportement, de même pour les feuilles. Ces5.3. Structure de données distribuée pour les réseaux 119 Noeuds locaux-internes Noeuds locaux-externes RacinesFeuilles Noeuds en pointillés sur la Figure 5.12 Arêtes en pointillés sur la Figure 5.12 Arêtes locales Figure 5.11 – Parallélisation de la structure et ré-indexation. explorations d’éléments se feront donc de façon à éviter les défauts de cache en mémoire puisque la lecture entière d’une ligne de cache chargée sera favorisée avant qu’une autre ne se charge. Pour ce qui est des nœuds locaux-internes et locaux-externes le même phé- nomène se produit puisque lors d’un recouvrement des communications par les calculs les nœuds locaux-internes seront tout d’abord explorés, puis par la suite les nœuds locauxexternes. Le deuxième avantage de cette ré-indexation est le fait d’éviter des conditions coûteuses dans le code. En effet, une solution naïve pour les bordures physiques serait d’explorer tous les nœuds du DAG et, pour chacun, de tester si il s’agit d’une racine, d’une feuille, ou d’un nœud interne. Cela signifierait qu’à chaque itération de temps et pour chaque élément du domaine (potentiellement très grand), deux tests seraient effectués. Ces conditions seraient extrêmement coûteuses en performances. Dans cette solution les racines et les feuilles sont regroupées et les itérateurs (expliqués précédemment) seront utilisés pour naviguer dans l’une ou l’autre des classes. De même, pour le recouvrement des communications par les calculs, une solution naïve serait de tester pour chaque élément si il s’agit d’un nœud local-interne ou local-externe ce qui nuirait aux performances. Étant donnée la ré-indexation locale du processeur 1, présentée dans la figure 5.10(b) et sans prendre en compte les nœuds et arêtes en pointillés, les six tableaux de la structure de données locale au processeur 1 sont : cdeg+ = [0, 2, 5, 7, 7, 7, 7, 7, 7], cdeg− = [0, 1, 2, 2, 3, 4, 5, 6, 7] N + E = [2, 3, 4, 5, 6, 0, 1], N − E = [0, 3, 1, 5, 6, 4, 2] S = [2, 2, 0, 0, 1, 1, 1], D = [0, 3, 7, 1, 6, 4, 5] La ré-indexation locale permet donc d’optimiser les performances de la structure de données et permet également de pouvoir exprimer les huit tableaux locaux à chaque processeur. Toutefois il est encore nécessaire de paralléliser cette structure de données en insérant les nœuds et arêtes en pointillés. La première étape de cette parallélisation est de continuer la ré-indexation commencée avec les éléments locaux à chaque processeur, sur les éléments en pointillés. Les index des éléments en pointillés doivent être supérieurs aux index des éléments locaux. Ainsi, étant donnée une arête ei en pointillés, et étant donnée la ré-indexation des arêtes locales E = {e0, e1, ..., em−1} telle que |E| = m, alors120 Chapitre 5. SkelGIS pour des simulations sur réseaux la ré-indexation de ei est notée ej où j ≥ m. De même, étant donné un nœud vi en pointillés, et étant donnée la ré-indexation des nœuds locaux V = {v0, v1, ..., vn−1} tel que |V | = n, alors la ré-indexation de vi est notée vj où j ≥ n. La fin de cette ré- indexation est illustrée de la figure 5.10(a) à la figure 5.10(b) et dans la figure 5.11. En ré-indexant de cette façon les éléments en pointillés, les optimisations mises en place, pour l’utilisation des lignes de cache et les conditions, sont conservées. Pour comprendre l’insertion des éléments pointillés dans la structure de données, continuons à utiliser l’exemple du processeur 1. Dans la figure 5.10(b), il peut être noté que les nœuds 2 et 3 doivent recevoir chacun une arête entrante du processeur 0. Pour cette raison, comme illustré dans la figure 5.12, le tableau cdeg− est modifié aux index 3 et 4 en ajoutant 1 à chacun. Comme cdeg− représente les degrés cumulés, l’addition de ces éléments doit être reportée sur tous les éléments suivants du tableau. Pour continuer cet exemple, le nœud 2 reçoit en entrée l’arête 7 du processeur 0, et le nœud 3 reçoit en entrée l’arête 8 du processeur 0. En d’autres termes, les arêtes 7 et 8 font partie du voisinage entrant des nœuds 2 et 3. Pour cette raison les index 7 et 8 doivent être insérés dans le tableau N − E comme illustré dans la figure 5.12. En procédant comme suit, la structure de données distribuée obtenue pour le processeur 1 est : cdeg+ = [0, 2, 5, 7, 9, 11, 14, 14, 14], cdeg− = [0, 1, 2, 3, 5, 6, 7, 8, 9] N + E = [2, 3, 4, 5, 6, 0, 1, 9, 10, 11, 12, 13, 14, 15], N − E = [0, 3, 7, 1, 8, 5, 6, 4, 2] cdeg - = 0 1 2 2 3 4 5 6 7 cdeg- = 0 1 2 3 5 6 7 8 9 +1 +1 N - E = 0 3 1 5 6 4 2 NE = 0 3 7 1 8 5 6 4 2 Figure 5.12 – Système de ré-indexation. En procédant de cette façon pour paralléliser la structure de données, la caracté- ristique du format CSR qui permet d’accéder au voisinage d’un nœud d’un graphe en O(1), est conservée pour tous les éléments de la structure, qu’ils proviennent d’autres processeurs ou pas. De plus, l’optimisation de cache mise en place est conservée. Il reste un dernier point à aborder afin que la structure de données soit entièrement parallélisée. En effet, le travail décrit jusqu’à présent permet d’exprimer, pour chaque processeur, la connectivité de son DAG local y compris avec les éléments qui vont être communiqués par d’autres processeurs. Afin de pouvoir effectuer les communications nécessaires, une sorte de cartographie des communications est nécessaire. Grâce à elle, chaque processeur saura à qui envoyer et de qui recevoir des nœuds et des arêtes. Cette cartographie va reposer de nouveau sur les degrés cumulés. Le tableau cdegtor, de taille p + 1, où p est le nombre de processeurs, indique le nombre d’éléments à recevoir de5.3. Structure de données distribuée pour les réseaux 121 chacun des autres processeurs de façon cumulée. À l’inverse, le tableau cdegtos, de taille p + 1 indique le nombre d’éléments à envoyer à chacun des autres processeurs, de façon cumulée là encore. Les tableaux complémentaires Ntor E , Ntos E , Ntor V et Ntos V indiquent les index des éléments à recevoir et à envoyer en suivant les tableaux de degrés cumulatifs, comme cela est le cas pour les tableaux déjà détaillés. Étant donné un DAG G = (V, E) partitionné en p sous-graphes Gi = (Vi , Ei), i ∈ [0, p[, tel que V = S i Vi et E = S i Ei , alors la table 5.1 indique la taille des tableaux locaux à chaque processeur mis en place dans le DDS DDAG présenté. Tableau Taille cdeg+ |Vi | cdeg− |Vi | S |Ei | D |Ei | N + E + N − E P|Vi| j=0 deg(vj ) cdegtor p cdegtos p Ntor E cdegtor[p] Ntor V cdegtor[p] Ntos E cdegtos[p] Ntos V cdegtos[p] Table 5.1 – Taille des tableaux du DDS DDAG. La taille totale représentée par cette structure de donnée, pour chaque processeur, est donc T aille = L + P + Conn + Comm, (5.3) avec L = 2 × |Vi | + 2 × |Ei |, P = 2 × p, Conn = X |Vi| j=0 deg(vj ), Comm = 2 × cdegtor[p] + 2 × cdegtos[p]. La taille du DDS DDAG pour chaque processeur dépend donc du partitionnement du réseau pour les opérandes L et Comm, mais également de la connectivité du réseau pour l’opérande Conn, et enfin du nombre de processeurs utilisés pour l’opérande P de l’équation (5.3). La structure de données présentée ici peut fonctionner quel que soit le partitionnement choisi au préalable. Toutefois, nous pouvons très bien noter que le partitionnement va impacter la taille de la structure de donnée locale à chaque processeur. Un bon partitionnement est donc aussi important que l’implémentation de la structure de122 Chapitre 5. SkelGIS pour des simulations sur réseaux données afin d’obtenir de bonnes performances pour la solution de parallélisme implicite. Le partitionnement implémenté dans SkelGIS, ainsi que deux études de partitionnements supplémentaires seront détaillés dans la section 5.5. La suite de cette section permet d’expliquer comment est implémenté chaque composant de la méthode SIPSim dans SkelGIS pour les réseaux, en fonction de l’implémentation de la DDS DDAG qui vient d’être détaillée. 5.3.3 Implémentation de SkelGIS pour les réseaux Nous venons de présenter en détails l’implémentation du DDS DDAG de SkelGIS. Comme cela a été décrit dans le chapitre 3, le DDS est l’objet principal de la solution et tout le reste de l’implémentation repose sur lui. Dans cette section, nous allons expliquer comment chaque composant de la méthode SIPSim utilise l’objet DDAG et sa structure de données. Dans la méthode SIPSim, un DPMap permet d’appliquer des données sur un DDS dans un objet léger. Comme nous l’avons vu, dans un réseau, deux DPMap sont nécessaires, DPMap_Nodes et DPMap_Edges. L’objet DPMap peut alors être comparé au tableau values du format CSR. Les objets DPMap_Nodes et DPMap_Edges stockent leur données dans un simple tableau à une dimension, ce qui permet d’obtenir des objets très légers. Ce tableau à une dimension, dont les indices vont suivre la ré-indexation de l’objet DDAG, vont donc représenter les tableaux à une dimension de la figure 5.11. Pour reprendre l’exemple de la figure 5.10, pour le processeur 1, l’élément 4 du tableau du DPMap_Nodes correspondra donc à une valeur sur le nœud 13 du DAG général. Un DPMap est donc lié à une instance de DDAG à sa création et se servira de cette instance de façon systématique dans son implémentation et pour ses interfaces. L’utilisateur va instancier un certain nombre de DPMap, autant qu’il a besoin de quantités sur le réseau pour sa simulation. C’est à partir des instances de DPMap que l’utilisateur va accéder aux interfaces de programmation afin de coder sa simulation. La première d’entre elles est l’interface d’itération. Les itérateurs présents dans SkelGIS pour les réseaux ont déjà été présentés. L’ensemble de ces itérateurs va pouvoir être initialisé par le biais de deux méthodes des objets DPMap. L’une permettra de se placer au commencement de la classe des éléments et l’autre permettra de se placer à la fin de la classe des éléments. Chaque objet d’itération est ensuite un objet indépendant qui va se charger d’incrémenter le positionnement grâce à l’opérateur ++ et de le comparer grâce aux opérateurs ≤, ≥, et ==. L’opérateur ++ ne peut, bien entendu, être efficace que grâce à l’indexation contiguë des éléments d’une même classe qui a été mise en œuvre dans l’objet DDAG. Enfin, le dernier composant de la méthode SIPSim implémenté dans SkelGIS est lui aussi lié à l’implémentation du DDAG. Il s’agit de l’applicateur qui a été décrit dans la section 5.2.3. Un applicateur permet d’appliquer une opération séquentielle, codée par l’utilisateur grâce aux instances de DPMap et aux interfaces de programmation, sur un ensemble de quantités à simuler. Un applicateur permet de cacher à l’utilisateur les échanges MPI qui se produisent avant une opération. L’applicateur pour les réseaux cache lui aussi les échanges nécessaires à chaque instance de DPMap, en appelant les méthodes5.4. Simulation 1D d’écoulement du sang dans les artères 123 de communication des objets DPMap. Ces méthodes, bien entendu, utilisent directement les tableaux cdegtor , cdegtos , Ntor E , Ntos E , Ntor V et Ntos V décrits dans la section 5.3.2. L’implémentation de la méthode SIPSim mise en place dans SkelGIS, pour le cas des réseaux, est une solution aboutie et optimisée qui cache à l’utilisateur une très grande complexité de code. Tous les composants de la méthode SIPSim dépendent de l’implé- mentation et de l’efficacité de l’objet DDAG et tous ces composants sont liés les uns aux autres pour fournir une solution adaptée à l’utilisateur, et efficace. 5.4 Simulation 1D d’écoulement du sang dans les artères Dans cette section est détaillé un cas d’application réel de SkelGIS pour les réseaux. La simulation présentée étudie l’écoulement du sang dans un réseau artériel. La parallélisation de cette simulation a été effectuée en collaboration avec Pierre-Yves Lagrée, Jose-Maria Fullana et Xiaofei Wang [42]. Dans cette section nous allons tout d’abord expliquer brièvement le modèle mathématique utilisé puis les méthodes numériques appliquées afin de coder la simulation. Nous détaillerons ensuite la parallélisation de la simulation en utilisant SkelGIS et présenterons des résultats expérimentaux. 5.4.1 Simulation 1D d’écoulement du sang dans le réseau artériel Les détails du modèle mathématique et des méthodes numériques utilisées peuvent être trouvés dans les travaux de Wang et Al [126]. Dans cette section, les informations utilisées dans cette thèse seront présentées, mais nous ne rentrerons que peu dans les détails mathématiques de la simulation. 5.4.1.1 Modèle mathématique Le système d’équations de Navier-Stokes [73] a déjà été décrit dans la section 4.3.1, il permet d’étudier l’évolution temporelle d’un fluide dans un domaine Ω de l’espace R 3 . Ces équations peuvent donc également modéliser les écoulements sanguins dans un ré- seau artériel en trois dimensions. Toutefois, cette simulation est connue pour être très coûteuse en temps d’exécution et en mémoire utilisée, ce qui la rend généralement uniquement utilisable de façon locale, sur une unique artère ou sur une confluence de plusieurs artères, par exemple. Le travail de Wang et Al [126] étudie une simulation sur une unique dimension pour plusieurs raisons. Tout d’abord, cette simulation étant plus légère elle peut être exécutée sur un réseau artériel complet. Il est, de plus, possible d’envisager une simulation en temps réel pour la médecine, en couplant la légèreté de cette simulation au parallélisme. Enfin, le système 1D capture de façon intéressante le comportement des ondes sanguines provoquées par les pulsations cardiaques, ce qui donne des informations, elles aussi intéressantes, sur le système cardio-vasculaire. La simulation présentée traite le système d’équations de Navier-Stokes suivant une dimension, en intégrant ces équations sur la section de l’artère, autrement dit en moyennant une solution dans les deux124 Chapitre 5. SkelGIS pour des simulations sur réseaux dimensions représentant la section du tube artériel. La simulation est alors représentée par deux EDP qui font le lien entre trois variables : la section de l’artère noté A, le débit volumétrique Q et la pression artérielle P toutes trois fonctions de x, la dimension spatiale, et t la dimension temporelle. Ces deux équations sont les suivantes : ( ∂A ∂t + ∂Q ∂x = 0 ∂Q ∂t + ∂ ∂x ( Q2 A ) + A ρ ∂P ∂x = −Cf Q A (5.4) où x représente l’axe longitudinal de l’artère, t représente le temps, et −Cf Q A représente le coefficient de frottement (avec Cf le coefficient de frottement de la paroi artérielle) et où ρ représente la densité du sang. 5.4.1.2 Résolution numérique et programmation La simulation proposée dans les travaux de Wang et Al [126] établie une relation entre A et P, telle que P = Pext + β( √ A − √ A0) + νs ∂A ∂t , où β est le coefficient de raideur d’une artère, A0 la section de l’artère non déformée, et Pext la pression extérieure des vaisseaux, et νs le coefficient de viscosité du sang. Ainsi, si nous posons U =  A Q  , Fc = Q Q2 A + β 3ρ A3/2 ! , Fv =  0 −Cv ∂Q ∂x  , F = Fc + Fv et S = 0 −Cf Q A + A ρ ( ∂(β √ A0) ∂x − 2 3 √ A ∂β ∂x! , Cv = Aνs ρ , alors le système d’équations (5.4) s’écrit sous la forme : ∂U ∂t + ∂F ∂x = S. (5.5) Dans cette équation il est considéré que Pext est constant suivant l’axe x. Dans l’équation (5.5), U représente la variable conservative de la loi de conservation présentée à l’équation (2.9) de la section 2.2.4.2, F le flux et S est un terme supplémentaire appelé le terme source. Le problème s’apparente donc à la loi de conservation de la masse et de la quantité de mouvement à une dimension. Les méthodes des différences finies et des volumes finis ont été utilisées dans les travaux de Wang et Al pour obtenir différents schémas numériques de la simulation et comparer les résultats obtenus. La méthode des volumes finis correspond alors à la description qui en a été faite dans la section 2.2.4.2 puisque la même forme d’équation de conservation à une dimension est traitée (hormis le terme source). Un schéma de résolution numérique explicite est donc obtenu pour la simulation au sein de chaque artère (équation (2.14)). Notons que dans cette simulation la variable U est traitée à l’ordre 2. Afin de résoudre les problèmes d’oscillations provoqués par les méthodes utilisées,5.4. Simulation 1D d’écoulement du sang dans les artères 125 la reconstruction MUSCL (Monotonic Upwind Scheme for Conservative Law) est utilisée [126] et engendre l’utilisation de variables supplémentaires et de cinq calculs stencils supplémentaires. Comme dans toute résolution d’EDP, des conditions initiales et des conditions aux limites du domaine sont spécifiées pour permettre de réduire le spectre des solutions. Notons que l’EDP, à résoudre ici, simule l’écoulement du sang dans une unique artère et non sur le réseau. Le calcul des conditions aux limites pour chaque artère est donc nécessaire au calcul de l’EDP. La particularité des conditions limites de cette simulation vient du fait qu’il s’agit d’une simulation sur un réseau. Pour cette raison les conditions limites d’une artère sont liées aux conditions limites des artères auxquelles elle est connectée. Par conséquent, les conditions limites, dans cette simulation ne sont autre que les nœuds du réseau. Il s’agit donc d’un cas simple de simulation sur un réseau, où les nœuds ne représentent pas une simulation à part entière, mais simplement les conditions aux limites de chaque arête arrivant à une conjonction. Afin de comprendre le comportement d’un nœud, prenons l’exemple d’un nœud ayant une artère mère et deux artères filles. Étant donné qu’en chaque artère les quantités A et Q sont simulées, on a alors en ce nœud l’arrivée de six conditions aux limites des artères : An+1 p et Qn+1 p pour les conditions limites de l’artère mère, et A n+1 d1 , A n+1 d2 , Q n+1 d1 et Q n+1 d2 pour les conditions limites des deux artères filles. Un nœud respecte alors la loi de conservation des flux suivante Q n+1 p − Q n+1 d1 − Q n+1 d2 = 0 (5.6) et la conservation de la quantité de mouvement suivante 1 2 ρ Qn+1 p A n+1 p !2 + P n+1 p − 1 2 ρ Q n+1 di A n+1 di !2 − P n+1 di = 0, ∀i ∈ {1, 2} (5.7) L’algorithme 9 reprend l’algorithme 1, de la section 2.2.5, avec les spécificités de la simulation décrite ici. Il représente donc l’algorithme séquentiel de cette simulation. 5.4.2 Parallélisation avec SkelGIS La simulation d’écoulement du sang, qui vient d’être décrite, est donc un cas particulier de simulation sur les réseaux. En effet, dans cette simulation les nœuds servent à exprimer le lien entre les conditions limites des artères du réseau. C’est l’une des façons d’utiliser un réseau, parmi d’autres. Toutefois, cette simulation se prête parfaitement à un premier cas d’application du prototype actuel de SkelGIS. Précisons, tout d’abord que dans cette simulation les types d’éléments T1 et T2 sont respectivement associés aux arêtes et aux nœuds du réseau. La simulation est alors organisée en quatre phases, comme cela a été décrit dans la section 5.1 : 1. communication des arêtes calculées à t − 1, 2. calcul des nœuds à t, 3. communication des nœuds calculés à t,126 Chapitre 5. SkelGIS pour des simulations sur réseaux Algorithme 9 : Algorithme séquentiel de la simulation artérielle. Création ou lecture du réseau Création ou lecture du domaine discrétisé pour chaque artère Création des variables appliquées sur le réseau (artères et nœuds) Initialisation des variables Définition du pas de temps : t Définition du temps maximal : tmax while t < tmax do calcul des conditions limites du réseau (racines et feuilles) pour t for chaque nœud du réseau do calcul des schémas (5.4) et (5.5) end for chaque artère du réseau do for chaque élément du maillage x do calcul du schéma numérique (5.3) pour t et x end end end 4. calcul des arêtes à t. La description de la simulation nous offre ensuite toutes les clés permettant de coder cette simulation en utilisant SkelGIS. Tout d’abord cette simulation n’instancie qu’un unique réseau qui représente le réseau artériel à étudier. Une unique instanciation de l’objet DDAG est donc nécessaire. Il est ensuite possible d’identifier les variables principales de la simulation, à savoir A et Q, qui représentent des données appliquées sur les arêtes du réseau. Elles nécessitent donc deux instanciations de l’objet DPMap_Edges. Au sein d’une arête, une discrétisation suivant une dimension est effectuée et un schéma numé- rique d’ordre 2 est appliqué à chaque itération de temps. Pour cette raison, le paramètre de template T est pour les deux variables double∗ , et le paramètre node_access est égal à 2 comme illustré dans la figure 5.13. Afin d’effectuer les calculs de condition aux limites DPMap_Edges A DPMap_Edges Q Figure 5.13 – Déclaration des variables A et Q sur les nœuds du réseau, l’instanciation d’une donnée plaquée sur les nœuds est ensuite nécessaire, même si les nœuds ne lisent et n’écrivent que des données sur les arêtes. La figure 5.14 illustre cette instanciation qui est très simple. Aucune discrétisation n’est effectuée au sein des nœuds du réseau (équations (5.6) et (5.7)). D’autres variables, qui n’ont pas été détaillées sont nécessaires au codage de la simulation, notamment pour la méthode de reconstruction MUSCL évoquée précédemment. Le principe reste cependant le même pour toutes les variables de la simulation appliquées aux arêtes ou aux nœuds.5.4. Simulation 1D d’écoulement du sang dans les artères 127 DPMap_Nodes nd Figure 5.14 – Déclaration d’une variable nd sur les nœuds du réseau Enfin, outre les instanciations de variables, les paramètres qui caractérisent les arêtes et les nœuds du réseau doivent être instanciés. Dans ce cas, ces données sont utilisées localement et pour cette raison le node_access du DPMap correspondant est positionné à 0. Une fois le réseau, les variables, et les paramètres de la simulation instanciés, les itérations de temps peuvent commencer ainsi que la résolution des schémas numériques. L’algorithme 10 illustre la fonction main codée par l’utilisateur. Cette fonction reste très proche de la version séquentielle, à l’exception près qu’elle définit les objets SkelGIS qui viennent d’être évoqués. Algorithme 10 : Fonction main codée par l’utilisateur Création ou lecture du réseau DDAG Création des variables appliquées sur le réseau (artères et nœuds) : DPM ap_Edges < double∗, 2 > A DPM ap_Edges < double∗, 2 > Q DPM ap_Nodes < double, 0 > nd ... Initialisation des variables de paramètres Définition du pas de temps : t Définition du temps maximal : tmax while t < tmax do apply_listi({A,Q,etc.},{nd,etc.},bloodflow1,bloodflow2) end On peut observer que la différence entre cette fonction principale et sa version sé- quentielle est d’appeler, dans la boucle d’itérations en temps, l’applicateur apply_listi. Comme cela a déjà été expliqué dans la section 5.2, l’applicateur apply_listi permet d’appliquer des schémas numériques implicites en quatre étapes. Cette simulation convient donc à l’utilisation de cet applicateur. Cet appel est très important puisqu’il est en charge de cacher à l’utilisateur les échanges nécessaires aux calculs dans les phases 1 et 3 de la simulation. Les opérations bloodflow1 et bloodflow2, données en paramètres de l’applicateur, sont les fonctions séquentielles utilisateur qui contiennent le code de calcul des phases 2 et 4 décrites précédemment. Les algorithmes 11 et 12 illustrent les opérations bloodflow1 et bloodflow2. Les structures de ces opérations sont, là encore, très proches de la version séquentielle. La seule contrainte imposée à l’utilisateur, tout comme dans la fonction main, est d’utiliser les notions propres à SkelGIS pour manipuler les instances des objets DPMap_Edges et DPMap_Nodes : les itérateurs ; les accesseurs ; et les fonctions de voisinages. La première opération, décrite dans l’algorithme 11 représente donc le code de la phase 2 de la simulation. Ce code consiste, tout d’abord à calculer les conditions limites du128 Chapitre 5. SkelGIS pour des simulations sur réseaux réseau, à savoir les racines et les feuilles. Pour cela, les itérateurs spécifiques à ces deux classes d’éléments sont utilisés ainsi que l’opérateur [] et les fonctions de voisinage d’un nœud. Par la suite, les conditions aux limites des artères sont calculées. Ces calculs se produisent aux points de conjonction (nœuds), et sont effectués en fonction des résultats obtenus à l’itération précédente sur les artères qui se rencontrent en ce nœud. Les autres nœuds du réseau sont donc ensuite calculés dans l’opération en appliquant les schémas numériques (5.6) et (5.7). La deuxième opération, décrite dans l’algorithme 12 repré- Algorithme 11 : Opération bloodflow1 décrivant les calculs effectués à chaque itération de temps sur les nœuds. Data : {DPMap} Result : Modification de {DPMap} ItR := itérateur de début sur les racines endItR := itérateur de fin sur les racines while ItR≤endItR do Application des conditions limites pour les racines avec : A[ItR], Q[ItR], nd[ItR], A.getInEdges(ItR), Q.getOutEdges(ItR) ... ItR++ end ItL := itérateur de début sur les feuilles endItL := itérateur de fin sur les feuilles while ItL≤endItL do Application des conditions limites pour les feuilles avec : A[ItL], Q[ItL], nd[ItL], A.getInEdges(ItL), Q.getOutEdges(ItL) ... ItL++ end ItC= itérateur de début sur les nœuds endItC := itérateur de fin sur les nœuds while ItC≤endItC do Application des schémas numériques des nœuds (5.4) et (5.5) avec : A[ItC], Q[ItC], nd[ItC], A.getInEdges(ItC), Q.getOutEdges(ItC) ... ItC++ end sente, quant à elle, le code de la phase 4 de la simulation. Ce code consiste à appliquer le schéma numérique issu de la méthode des volumes finis appliquée à l’équation (5.5). Pour cela, les itérateurs spécifiques à ces deux classes d’éléments sont utilisés ainsi que l’opérateur [] et les fonctions de voisinage d’une arête. L’utilisation de SkelGIS pour coder cette simulation d’écoulement du sang dans les artères répond donc aux attentes annoncées, et propose une solution très proche du sé- quentiel, aussi bien en terme de structure de programme qu’en terme de programmation. En effet, aucune difficulté technique n’est introduite par la solution et aucun code pa-5.4. Simulation 1D d’écoulement du sang dans les artères 129 Algorithme 12 : Opération bloodflow2 décrivant les calculs effectués à chaque itération de temps sur les arêtes. Data : {DPMap} Result : Modification de {DPMap} ItA= itérateur de début sur les artères endItA := itérateur de fin sur les artères while ItA≤endItA do for chaque élément du maillage de l’artère x do calcul du schéma numérique issu de l’équation (5.4) pour t et x avec : A[ItA], Q[ItA], nd[ItA], A.getSrcNode(ItA), Q.getDstNode(ItA) ... end ItA++ end rallèle n’a été produit par l’utilisateur. Dans la prochaine section vont être étudiés en détails les résultats expérimentaux obtenus sur cette version SkelGIS de la simulation. 5.4.3 Résultats Dans cette section, nous allons présenter les résultats que nous avons obtenus sur la simulation d’écoulement du sang dans le réseau artériel décrite précédemment, et codée avec la bibliothèque SkelGIS. Nous appellerons cette simulation bloodflow-SkelGIS. Les résultats expérimentaux se découpent en trois parties. Tout d’abord, l’efficacité du recouvrement des communications par les calculs a été évaluée. Cette optimisation du code parallèle est, en effet, possible grâce à l’indexation mise en place dans la structure de données. Nous avons décrit ce point dans les sections 5.2 et 5.3.2. Les expériences suivantes utilisent toutes le recouvrement des communications par les calculs. L’implé- mentation bloodflow-SkelGIS sera ensuite comparée à une version OpenMP de la même simulation, que nous noterons bloodflow-OpenMP. Trois comparaisons seront effectuées, les temps d’exécution, les accélérations des programmes ainsi que les métriques de Halstead [65]. Enfin, une dernière phase d’expérimentation donnera les temps d’exécution et les accélérations de bloodflow-SkelGIS sur deux grappes du top500 international de novembre 2013, avec des tailles variables de réseaux. Les machines utilisées dans l’ensemble de ces expériences sont détaillées dans la table 5.2. Il y a tout d’abord la grappe “Babbage”, de l’Institut Jean le Rond d’Alembert UMR CNRS Université de Paris 6, qui est une grappe de taille moyenne mais bien équipée, les nœuds thin du super-calculateur TGCC-Curie classé vingtième dans le top500 de novembre 2013, et enfin les nœuds IBM Blue Gene/Q de super-calculateur Juqueen en Allemagne classé huitième sur la même liste. Notons que Juqueen nous permet également de valider SkelGIS sur une architecture très différente des autres clusters. Ces machines nous ont permis de procéder à des tests de performances allant de 8 à 8192 cœurs. Afin de détailler au mieux les expériences effectuées, notons que la simulation bloodflow-SkelGIS est exclusivement composée d’opérations sur des variables à double-130 Chapitre 5. SkelGIS pour des simulations sur réseaux Calculateur Babbage TGCC Curie Juqueen Processeur 2×Intel Xeon 2×SandyBridge IBM PowerPC (3 GHz) (2.7 GHz) (1.6 GHz) Cœurs/nœud 12 16 16 Mémoire/nœud 24 GB 64 GB 16 GB Compilateur [-O3] OpenMPI Bullxmpi MPICH2 Réseau Infiniband Infiniband 5D Torus 40 GBps Table 5.2 – Spécifications matérielles des machines utilisées précision et que chaque expérience présentée dans cette partie a été lancée quatre fois chacune, puis moyennée. Enfin, l’écart type noté sur l’ensemble des exécutions de la simulation est très faible, et inférieur à 2%. 5.4.3.1 Recouvrement des communications par les calculs La première expérience effectuée est celle qui permet de valider l’optimisation de recouvrement des communications par les calculs. Cette expérience a été menée sur le cluster “Babbage” de l’Université de Paris 6, sur un réseau de type arbre contenant 15.000 arêtes et 15.000 nœuds et un degré maximal très faible de 3. La table 5.3 donne l’ensemble des temps d’exécution obtenus de 16 à 384 processeurs utilisés, et la figure 5.15 illustre, de son côté, l’accélération de la simulation bloodflow-SkelGIS avec et sans l’optimisation de recouvrement. Cœurs Sans recouvrement Avec recouvrement Gain de temps % 16 12715.9 12386.2 2.59 32 6462.38 6189.79 4.22 64 3491.87 3124.74 10.5 128 1912.89 1581.46 17.3 256 1225.55 843.103 31.2 384 1166.18 612.787 47.45 Table 5.3 – Temps d’exécution en secondes de bloodflow-SkelGIS avec et sans l’optimisation de recouvrement des communications par les calculs. Tout d’abord, l’optimisation mise en place est efficace, comme cela pouvait être attendu. On note, en effet, une différence très nette, à la fois pour les temps d’exécution et sur les accélérations, entre la simulation sans le recouvrement et la simulation avec le recouvrement. Cependant, il paraît presque surprenant d’obtenir des gains de performance aussi importants. La version sans recouvrement fait émerger une faiblesse du prototype SkelGIS. En effet, même si de meilleures performances étaient attendues avec cette optimisation de recouvrement, on observe que le speedup de la version sans recouvrement devient moins bon à partir de 128 processeurs. Cette faiblesse n’a pas été étudiée avec précision. Nous pensons que le problème peut venir du partitionnement de graphes mis5.4. Simulation 1D d’écoulement du sang dans les artères 131 Coeurs Accélération sans recouvrement avec recouvrement idéal 16 64 128 256 384 16 64 128 256 384 Figure 5.15 – Accélération de la simulation bloodflow-SkelGIS sans et avec le recouvrement des communications par les calculs. en place dans le prototype actuel de SkelGIS, qui sur un grand nombre de processeurs, fournit une distribution moyennement équilibrée. Les résultats de ce partitionnement seront présentés en détails dans la section 5.5.1. Ce résultat montre, quoi qu’il en soit, l’importance de l’optimisation mise en place dans la structure de données DDAG. 5.4.3.2 Comparaison avec OpenMP La méthode SIPSim et son prototype implémenté SkelGIS, se proclame comme une solution de parallélisme implicite très simple d’utilisation, car adaptée aux simulations scientifiques, et proposant de très bonnes performances parallèles. De son côté, le langage OpenMP est reconnu et utilisé dans les domaines scientifiques de par sa simplicité d’utilisation, tout en sachant que les performances obtenues ne sont pas nécessairement excellentes. Une comparaison des deux approches paraît donc être une bonne expérience, aussi bien en terme de performances qu’en terme de difficulté de programmation. Une version OpenMP de la simulation d’écoulement du sang dans le réseau artériel a été développée par les mathématiciens à l’origine de cette simulation. La parallélisation OpenMP dite à grain fin (fine-grain), est la parallélisation la plus utilisée par les non-informaticiens et consiste à déclarer des boucles parallèles dans le code par la simple directive #pragma omp parallel for. Ces boucles sont alors automatiquement réparties entre les différents processus (threads) créés, ce qui rend la solution totalement implicite. La simulation OpenMP qui a été implémentée ici n’est toutefois pas une implémentation fine-grain. Il s’agit d’une parallélisation à gros grain (coarse-grain), où la directive plus générale #pragma omp parallel est utilisée. Ce type de parallélisation OpenMP n’est pas totalement implicite, et donc plus complexe qu’une parallélisation fine-grain. Une parallélisation coarse-grain ressemble, dans son principe, à une parallélisation MPI. En effet, une zone parallèle générale est déclarée comme entre les fonctions MPI_Init et MPI_Finalize. Dans cette zone parallèle, plusieurs threads sont créés et vont, sauf précision inverse de l’utilisateur, exécuter la même zone de code. Aucun transfert de données n’est nécessaire entre les processus qui partagent la même mémoire, toutefois des syn-132 Chapitre 5. SkelGIS pour des simulations sur réseaux chronisations sont implicitement effectuées entre les processus pour garantir la cohérence des données et pour contrôler leur accès. Ce type de parallélisation permet de mettre en place des programmes parallèles en suivant le paradigme SPMD et le parallélisme de données, tout comme le modèle PGAS le propose. Ce type de parallélisation obtient dans les cas complexes de meilleures performances que la parallélisation fine-grain, mais n’est pas totalement implicite aux yeux de l’utilisateur [109]. En effet, étant donné que tous les threads exécutent le même code, il est nécessaire de gérer une distribution des données entre les threads. Cette distribution est à la charge de l’utilisateur ce qui rend la solution plus complexe à mettre en œuvre. De plus, une réflexion est nécessaire pour déclarer les variables partagées et locales. Cette parallélisation ayant été effectuée par des mathématiciens, elle donne un aperçu des performances qu’il est possible d’obtenir en utilisant OpenMP sans connaissances poussées en informatique. La table 5.4 indique les temps d’exécution obtenus sur un unique nœud thin du super-calculateur TGCC-Curie. Comme indiqué dans la table 5.2, un nœud contient 16 cœurs. La figure 5.16 trace les temps d’exécution obtenus en fonction du nombre de cœurs utilisés, avec une échelle logarithmique, ce qui permet de mieux apprécier cette comparaison. Cœurs OpenMP SkelGIS Gain de temps % 1 2209.77 2006.92 9.2 2 2068.33 959.095 53.6 4 1122.73 497.424 55.7 8 621.72 273.011 56 16 341.95 156.59 54.2 Table 5.4 – Temps d’exécution en secondes de bloodflow-OpenMP et bloodflow-SkelGIS. Coeurs (log2) Temps d'exécution (log2) OpenMP SkelGIS 1 2 4 8 16 250 500 1000 2000 Figure 5.16 – Comparaison des temps d’exécution entre bloodflow-OpenMP et bloodflow-SkelGIS avec une échelle logarithmique. La table 5.4 et la figure 5.16 montrent que la version OpenMP obtient un très mauvais temps d’exécution avec deux cœurs, et que ce problème se répercute, par conséquent, sur5.4. Simulation 1D d’écoulement du sang dans les artères 133 le reste des temps d’exécution. La figure 5.17 montre l’accélération des simulations. On peut alors voir que le speedup obtenu par la version OpenMP n’est pas mauvais, car proche du linéaire, outre le pallier entre 1 et 2 cœurs. La version SkelGIS, de son côté, obtient de très bonnes performances. Le temps d’exécution séquentiel est tout d’abord meilleur que le temps séquentiel de la version OpenMP de 9%. De plus, l’accélération du programme étant quasi linéaire, et proche de l’idéal (figure 5.17), cette performance est conservée en augmentant le nombre de processeurs. Le résultat de la version OpenMP nuit à une bonne comparaison des deux approches. Cependant, notons que la pente de l’accélération de la version OpenMP est moins importante que celle de la version SkelGIS. Pour cette raison, si la version OpenMP était retravaillée afin de résoudre le pallier à 2 cœurs, les temps d’exécution et les accélérations obtenus seraient toujours moins performants pour la version OpenMP. Coeurs Accélération OpenMP SkelGIS idéal 1 2 4 8 16 1 2 4 8 16 Figure 5.17 – Comparaison des accélérations entre bloodflow-OpenMP et bloodflow-SkelGIS. Mais le point de la comparaison n’est pas réellement ici. En effet, qu’une version OpenMP meilleure que la version SkelGIS n’existe ou pas, la version SkelGIS obtient des performances très intéressantes et qui pourraient elles aussi être améliorées. En plus des performances, il paraît intéressant de comparer la difficulté de programmation des deux programmes. Pour expérimenter ce dernier point, les métriques de Halstead ont une nouvelle fois été utilisées pour obtenir une évaluation du volume du programme écrit, de la difficulté de programmation, et de l’effort à fournir. La table 5.5 donne les métriques calculées pour chacune des deux simulations : bloodflow-OpenMP et bloodflow-SkelGIS. L’effort à fournir pour écrire la version SkelGIS est environ 45% moins grand que l’effort à fournir pour écrire la version OpenMP coarse-grain. Pourtant un programme OpenMP ne consiste qu’en un ensemble de directives de compilation à appliquer à son code, alors pourquoi un tel écart ? Comme le montre le tableau des métriques, cet écart vient principalement d’un facteur, celui du volume du programme écrit qui est 30% plus important dans la version OpenMP. Il s’agit d’un point très important pour la méthode SIPSim et pour SkelGIS. En effet, SkelGIS gère, par l’intermédiaire de l’objet DDAG, l’ensemble de la structure de données de façon transparente pour l’utilisateur. Ce point simplifie énormément le code utilisateur puisque celui-ci n’a plus à se soucier de coder une structure de données, qui peut être complexe suivant les cas. Pour les DMatrix, cet134 Chapitre 5. SkelGIS pour des simulations sur réseaux Métriques OpenMP SkelGIS Gain % N1 2607 2692 -3.2 N2 10737 7424 30.8 n1 365 231 36.7 n2 501 282 43.7 V 130213.73 91072.48 30 D 3911.18 3040.68 22.2 E 509.3M 276.9M 45.6 Table 5.5 – Métriques de Halstead pour les versions bloodflow-OpenMP et bloodflow-SkelGIS. avantage était moins évident puisqu’une matrice est une structure de données très simple à coder. Dans le cas des réseaux, l’intérêt du composant DDS, de la méthode SIPSim, prend tout son sens et simplifie de façon significative le code de la simulation. La mé- thode SIPSim étant une solution spécifique de parallélisme implicite en comparaison de OpenMP, ce résultat devait être observé. Cependant, notons qu’un autre phénomène apporte du poids au volume de code à fournir pour la version OpenMP. En effet, le fait que la version OpenMP étudiée produise une parallélisation de type coarse-grain ajoute du travail à l’utilisateur. Comme nous l’avons déjà décrit, cette version de parallélisation OpenMP est proche d’une parallélisation MPI et l’utilisateur doit procéder à la décomposition du domaine par lui-même. Cela nuit au parallélisme implicite, mais cela nuit également au volume de code à fournir. La simulation bloodflow-SkelGIS est donc plus intéressante en tout point par rapport à la version bloodflow-OpenMP. La version SkelGIS obtient, en effet, de très bonnes performances et de très bonnes métriques de Halstead. 5.4.3.3 Performances de SkelGIS La méthode SIPSim et son implémentation SkelGIS sont conçues pour être exécutées sur des architectures à mémoire distribuée. Bien qu’un programme parallèle MPI fonctionne très convenablement sur une architecture à mémoire partagée, comme nous venons de le voir, ce n’est pas son objectif premier. Cette nouvelle série d’expériences permet donc d’estimer les performances de la bibliothèque SkelGIS sur des données de taille importante et variable et sur des machines de configuration et de taille variables. La table 5.6 référence les expériences qui ont été menées. Nombre de nœuds et d’arêtes calculateur utilisé Expérience 1 15k TGCC-Curie Expérience 2 50k Juqueen Expérience 3 100k Juqueen Expérience 4 500k Juqueen Table 5.6 – Expériences de performance sur bloodflow-SkelGIS.5.4. Simulation 1D d’écoulement du sang dans les artères 135 Les temps d’exécution obtenus pour l’ensemble de ces expériences sont réunis dans la table 5.7. Le nombre de cœurs utilisés pour chaque expérience n’est pas le même pour plusieurs raisons. Tout d’abord, la longueur des traitements et le nombre d’heures qui nous étaient allouées sur chaque calculateur ne nous permettaient pas d’effectuer des expériences trop longues. Pour cette raison, les expériences sur les réseaux de taille 50k et 100k ne commencent pas à 8 cœurs, et l’expérience sur un réseau de taille 500k commence elle à 1024 cœurs. De plus, les clusters utilisés sont très demandés et le nombre d’utilisateurs est très important. Des files d’attente pour les expériences sont donc mises en place sur ces machines. Plus il y a de cœurs réservés pour une expérience, plus le délai d’attente pour que l’expérience soit lancée est long. Pour cette raison, nous n’avons pas réservé plus de 1024 cœurs sur le TGCC-Curie, et nous ne sommes pas montés au delà de 8192 cœurs pour Juqueen. Enfin, sur Juqueen notamment, des contraintes très fortes sur l’utilisation des machines sont mises en place. Le temps de calcul alloué à chaque cœur possède un minimum et un maximum à respecter, aussi nous n’avons pu descendre sous 256 cœurs pour les traitements sur les réseaux de taille 50k et 100k. Afin de mieux appréhender les résultats obtenus, les accélérations de la simulation bloodflow-SkelGIS pour chacune des expériences sont représentées dans les figures 5.18, 5.19 et 5.20. Cœurs 15k TGCC 50k Juqueen 100k Juqueen 500k Juqueen 8 10080.1 16 5288.56 32 2680.21 64 1372.12 128 743.103 256 416.919 12602.20 24170.50 512 247.537 6976.98 12650.60 1024 178.8 3869.46 7043.42 30615.20 2048 2624.44 4122.97 16239.50 4096 1254.94 2657.76 8959.82 8192 5606.09 Table 5.7 – Temps d’exécution en secondes de bloodflow-SkelGIS. Concernant la première expérience, le même jeu de données que dans l’expérience sur le recouvrement a été utilisé. Hors, nous pouvons remarquer dans la figure 5.15 que l’accélération est meilleure que dans la figure 5.18. En d’autres termes, l’accélération de l’expérience semble meilleure sur la grappe “Babbage” que sur le TGCC-Curie. Cette différence de performances peut être due au fait que le code SkelGIS réagit mieux à la configuration matérielle du cluster “Babbage”. Toutefois cette explication parait étonnante. Toutefois, notons que les performances sont tout de même très bonnes sur un réseau de taille très modeste. Dans les expériences suivantes, la taille des réseaux est augmentée et l’architecture utilisée reste identique ce qui permet d’analyser le passage à l’échelle de SkelGIS. Il peut être observé dans les figures 5.19 et 5.20 que les accélérations obtenues sont très convain-136 Chapitre 5. SkelGIS pour des simulations sur réseaux Coeurs Accélération 15k idéal 8 64 256 512 1024 8 256 512 1024 Figure 5.18 – Accélération de bloodflow-SkelGIS sur un DAG de 15k arêtes et nœuds sur le TGCC. Coeurs Accélération 50k 100k idéal 256 1024 2048 4098 256 1024 2048 4098 Figure 5.19 – Accélération de bloodflow-SkelGIS sur des DAGs de 50k et 100k arêtes et nœuds sur Juqueen. Coeurs Accélération 500k idéal 1024 2048 4098 8192 2048 4098 8192 Figure 5.20 – Accélération de bloodflow-SkelGIS sur un DAG de 500k arêtes et nœuds sur Juqueen.5.5. Partitionnement de réseaux 137 cantes. Le passage à l’échelle y est clairement bon puisque proche d’un résultat linéaire jusqu’à 4098 processeurs. Sur la taille de réseau la plus importante, les performances sont très bonnes jusqu’à 8192 processeurs. Les résultats analysés dans cette section montrent que SkelGIS est convainquant en plusieurs aspects. Tout d’abord l’optimisation de recouvrement rend la solution très performante, et le passage à l’échelle est vérifié jusqu’à un très grand nombre de processeurs. De plus, en comparaison avec une version coarse-grain OpenMP, SkelGIS montre des performances très bonnes sur une architecture à mémoire partagée. OpenMP étant une référence dans le parallélisme implicite, les résultats des métriques de Halstead montrent que SkelGIS est très simple d’utilisation et qu’il peut même être plus simple qu’une version séquentielle, du fait de la structure de données implicite. Pour finir, le passage à l’échelle d’une simulation implémentée avec SkelGIS est bon et semble robuste sur différentes configurations matérielles. 5.5 Partitionnement de réseaux Dans cette section nous allons expliquer le choix d’implémentation qui a été mis en place pour partitionner un réseau dans SkelGIS. Cette solution a montré des résultats intéressants, comme nous l’avons vu dans la section 5.4.3. Les détails de cette méthode de partitionnement seront décrits dans cette section, et nous verrons qu’elle contient un certain nombre de désavantages. Un travail récent, en collaboration avec Rob Bisseling, a permis d’étudier avec plus de précision le problème de partitionnement qui est posé par les réseaux, mais aussi la façon dont on peut résoudre ce problème en utilisant le partitionneur Mondriaan [120]. Les deux méthodes de partitionnement récemment mises en place sont également introduites et évaluées dans cette section. 5.5.1 Partitionnement par regroupement d’arêtes sœurs Il faut tout d’abord remarquer que dans le type de simulations qui nous intéresse des calculs sont effectués à la fois sur les nœuds et sur les arêtes du graphe qui représente le réseau. Nous avons donc deux solutions pour partitionner le graphe. On peut tout d’abord choisir de distribuer les deux types d’éléments sur les processeurs, ce qui représente le véritable problème de partitionnement d’un réseau. Ce problème est toutefois complexe à résoudre, et il conduit également à une gestion des communications plus complexe. L’autre solution est alors de ne distribuer que les nœuds ou que les arêtes et de dupliquer les nœuds ou les arêtes manquantes aux coupures, afin de permettre les calculs. Dans ce cas, les communications sont moins difficiles à gérer dans la solution de parallélisme implicite. L’implémentation choisie dans le prototype actuel de SkelGIS pour les réseaux a été de partitionner les arêtes sur les processeurs, où le calcul était considéré comme plus lourd, et de dupliquer les nœuds sur les différents processeurs, aux coupures des différentes parties, où le calcul était considéré comme plus léger. Nous avons donc fait le choix, dans un premier temps, de simplifier le problème en ne partitionnant que les138 Chapitre 5. SkelGIS pour des simulations sur réseaux arêtes du réseau et en dupliquant les nœuds. De plus, nous avons également limité, et donc modifié, le problème en considérant une sous-partie des réseaux qui peuvent être représentés par des DAG. Comme cela a déjà été décrit dans l’état de l’art 2.3, un partitionnement de graphe découpe l’ensemble des nœuds d’un graphe G = (V, E) en p parties distinctes V0, . . . , Vp−1 telles que pour i 6= j, Vi∩Vj = ∅ et telles que V = S i Vi . Le partitionnement doit répondre à la contrainte d’équilibrage de charge suivante ω(Vi) ≤ (1 + ) ω(V ) p (5.8) où  est le pourcentage de non-équilibrage accepté.  peut être choisi soit automatiquement par la solution, soit par l’utilisateur. Enfin, le partitionnement doit minimiser le nombre d’arêtes coupées, aussi appelé edge-cut. Dans le prototype de SkelGIS, nous avons choisi de partitionner les arêtes du graphe. Le problème de partitionnement doit donc être transposé aux arêtes. Ce problème n’est pas nouveau et les travaux de Kim et Al [81] se sont, par exemple, intéressés à partitionner les arêtes en coupant les nœuds et en les dupliquant sur chaque processeur. Nous avons toutefois développé notre propre méthode de partitionnement afin d’essayer de tirer parti des DAG et du cas particulier des simulations numériques sur les réseaux. Notre méthode de partitionnement transforme tout d’abord le DAG en un graphe G0 plus grossier que nous appelons méta-graphe. En reprenant les définitions introduites dans la section 5.3, nous allons décrire la construction du graphe G0 . Les arêtes sortantes et entrantes d’un nœud v ∈ V sont respectivement notées N + E (v) et N − E (v). Deux arêtes ei et ej sont considérées comme étant sœurs si S(ei) = S(ej ) et D(ei) 6= D(ej ). L’ensemble des arêtes sœurs d’un nœud v ∈ V est défini comme égal à N + E (v). Le méta-graphe G0 du réseau G est alors défini comme le graphe G0 = (V 0 , E0 ) où V 0 = {N + E (v), ∀v ∈ V } et E0 = {(N + E (v1), N + E (v2)) ∈ V 0 × V 0 , ∀v1 ∈ V, v2 ∈ N + V (v1)}. La figure 5.21 illustre le réseau de type DAG G et le méta-graphe G0 associé. Figure 5.21 – Exemple de réseau G (à gauche) de type DAG, et du méta-graphe G0 associé (à droite).5.5. Partitionnement de réseaux 139 Nombre de nœuds Degré maximum Arbre 1 10k 10 Arbre 2 10k 2 Arbre 3 16k 5 Table 5.8 – Type d’arbres utilisés pour évaluer le partitionnement. Dans le méta-graphe G0 les nœuds sont les blocs d’arêtes sœurs du graphe G, et les arêtes représentent les liens entre ces blocs par l’intermédiaire des nœuds de G. Notons que les nœuds de G0 sont assortis d’un poids, qui est égal au nombre d’arêtes sœurs de G représentées par le nœud de G0 . En d’autres termes, pour un nœud v ∈ V et un nœud v 0 = N + E (v) ∈ V 0 , on associe un poids ω(v 0 ) = |N + E (v)|. En partitionnant ce méta-graphe G0 deux problèmes sont résolus à la fois : — Le problème de partitionnement posé redevient un problème standard de partitionnement des nœuds d’un graphe. — Le partitionnement des nœuds de G0 , en tenant compte de leur poids, revient à un partitionnement de blocs d’arêtes sœurs dans G, ce qui favorise la localité géographique du résultat. En revenant ainsi à un problème de partitionnement standard de type edge-cut, il aurait été possible d’utiliser un partitionneur de graphe comme METIS [77] ou Scotch [100]. Toutefois, nous ne connaissions pas ces solutions au moment du développement de ce prototype de SkelGIS. Cette solution pourra être envisagée dans les prespectives de ce travail pour comparer avec plus de détail les différentes approches de partitionnementpossible. Nous pouvons également noter qu’en envisageant ce prototype de SkelGIS nous avons préféré une solution simple et sans dépendance pour partitionner uniquement les DAG, et non tous les graphes comme le proposent METIS et Scotch. Afin d’évaluer les limites du partitionnement de SkelGIS, nous avons effectué quelques expériences en calculant le nombre d’arêtes dont chaque processeur a la charge, et les communications effectuées par chaque processeur, en terme de nombre d’octets et de temps effectif. Nous avons mené ces expériences sur trois types d’arbres différents, générés aléatoirement, dont la description est résumée dans la table 5.8. Le premier arbre ainsi obtenu est un arbre plutôt large et peu profond alors que le second arbre est à l’inverse un arbre profond et peu large. Enfin, le dernier arbre est un arbre qui peut être considéré comme assez équilibré en profondeur et en largeur. La table 5.22 donne le nombre moyen d’arêtes dont chaque processeur est en charge à chaque itération de simulation, et l’écart type maximal obtenus par rapport à cette valeur moyenne. Ainsi, plus l’écart type est proche de la valeur moyenne, plus l’équilibrage de charge peut être considéré comme mauvais. On peut observer, dans cette table, que l’équilibrage de charge en terme de nombre d’arêtes est bon puisque l’écart type obtenu est très faible comparé à la valeur moyenne. On peut également observer que le partitionnement effectué est meilleur pour les arbres 2 et 3 que pour un arbre large comme l’arbre 1. La table 5.23 représente le nombre moyen d’octets que chaque processeur doit échan-140 Chapitre 5. SkelGIS pour des simulations sur réseaux Arbre 1 Arbre 2 Arbre 3 Nb de processeurs moy ect moy ect moy ect 4 2499.75 2.68 2499.75 0.43 4036.25 0.43 8 1249.87 1.45 1249.87 0.78 2018.12 0.6 16 624.94 1.25 624.94 0.66 1009.06 0.24 32 312.47 1.6 312.47 1.03 504.53 0.83 64 156.23 1.66 156.23 0.88 252.26 0.71 128 78.12 1.52 78.12 0.75 126.13 0.74 256 39.06 1.59 39.06 0.71 63.06 0.65 Figure 5.22 – Moyenne (moy) et écart type (ect) du nombre d’arêtes obtenu pour chaque processeurs suite au partitionnement. ger en une itération de temps et pour un unique DPMap, donc une unique quantité de la simulation. Cette table représente également l’écart type maximal obtenus par rapport à cette valeur moyenne. Ainsi, de nouveau, plus l’écart type est proche de la valeur moyenne, plus l’équilibrage des communications effectuées par chaque processeur peut être considéré comme mauvais. On peut observer ici que l’équilibrage de charge en terme de communications est assez mauvais dans ce partitionnement. Cependant l’équilibrage des communications n’est généralement pas considéré dans les problèmes de partitionnements, où l’on cherche plutôt à minimiser le nombre total de communications (pour le partitionnement de graphes) ou le volume total de communications (pour le partitionnement d’hypergraphes). Tout ce que l’on peut conclure de ce résultat est que tous les processeurs n’ont pas la même charge de communications à effectuer et que cette charge peut même aller du simple au double. Cela explique peut être partiellement l’accélération obtenue dans la figure 5.15, sans recouvrement des communications par les calculs. Arbre 1 Arbre 2 Arbre 3 Nb processeurs moy ect moy ect moy ect 4 616.0 168.09 112.0 53.66 148.0 76.84 8 598.0 377.95 98.0 38.31 128.0 42.14 16 437.0 214.77 107.0 42.41 128.0 49.79 32 390.5 238.87 86.5 40.81 135.0 61.18 64 327.0 214.73 95.75 40.02 111.5 42.33 128 266.12 154.3 94.25 31.29 107.5 39.66 256 209.19 113.43 84.25 31.34 94.0 32.52 Figure 5.23 – Moyenne (moy) et écart type (ect) du nombre d’octets à échanger pour chaque processeur, pour chaque DPMap et pour une unique itération de temps de la simulation, suite au partitionnement des arbres de la table 5.8. Afin de mieux percevoir la charge d’échanges de chaque processeur dans une simulation complète, prenons l’exemple de la simulation artérielle décrite dans la section 5.4, en utilisant les arbres de la table 5.8. Dans la simulation artérielle, il y a onze DPMap néces-5.5. Partitionnement de réseaux 141 sitant des échanges de données, et quatre-vingt mille itérations de temps. La table 5.24 représente alors le nombre moyen total d’octets échangés pour chaque processeur lors de la simulation complète. Nb processeurs Arbre 1 Arbre 2 Arbre 3 4 542 Mo 98.6 Mo 130.2 Mo 8 526.2 Mo 86.2 Mo 112.6 Mo 16 384.6 Mo 94.2 Mo 112.6 Mo 32 343.6 Mo 76.1 Mo 118.8 Mo 64 287.8 Mo 84.3 Mo 98.1 Mo 128 234.2 Mo 82.9 Mo 94.6 Mo 256 184.1 Mo 74.1 Mo 82.7 Mo Figure 5.24 – Moyenne du nombre d’octets total à échanger pour chaque processeur, dans le cadre de la simulation artérielle de la section 5.4, en utilisant les arbres de la table 5.8. Les résultats obtenus sont donc relativement bons en terme d’équilibrage de charge. Et les performances obtenues sur bloodflow-SkelGIS sont elles aussi relativement bonnes grâce à la mise en place d’un recouvrement des communications par les calculs, comme nous l’avons vu dans la section 5.4.3. Cependant, les performances sont également limitées par les choix qui ont été effectués pour mettre en place un partitionnement. Tout d’abord, notre partitionnement actuel ne s’adresse qu’aux réseaux de type DAG. De plus, nous ne profitons pas de l’efficacité et de l’expertise des partitionneurs existants comme Scotch ou METIS, ni de leur version parallélisées. Enfin, en dupliquant les nœuds, nous ne traitons pas le véritable problème de partitionnement des réseaux et nous ne pouvons garantir son efficacité dans tous les types de simulations et sur tous les types de graphes. En effet, nous avons considéré que les calculs sur les nœuds étaient presque négligeables par rapport aux calculs sur les arêtes, ce qui n’est pas toujours le cas suivant les simulations. De plus, les expériences mesurées dans cette section semblent montrer la nécessité d’améliorer le partitionnement du prototype de SkelGIS. C’est la raison pour laquelle nous avons étudié d’autres méthodes de partitionnement, présentées dans la suite de cette thèse. 5.5.2 Partitionnement avec Mondriaan Des travaux plus récents sur SkelGIS s’intéressent au véritable problème de partitionnement posé par les réseaux, sans duplication des nœuds. Nous étudions ici la formalisation du problème et deux méthodes de partitionnement. Notons que le but de ce travail est également de retourner vers une définition plus générale des réseaux. Nous prenons en compte ici tout type de réseau, et non plus seulement ceux pouvant être représentés par un graphe dirigé acyclique. En étudiant le véritable problème de partitionnement, nous évitons également la duplication des nœuds sur les processeurs.142 Chapitre 5. SkelGIS pour des simulations sur réseaux 5.5.2.1 Formalisation du problème de partitionnement des réseaux Comme expliqué précédemment, une simulation sur un réseau implique le calcul de deux schémas numériques différents, reliés entre eux par le réseau, créant une certaine dépendance de calcul aux bordures physiques, Nout. À partir de deux schémas numériques explicites, il est donc possible d’obtenir un ensemble explicite lui aussi, ou à l’inverse implicite. L’ensemble général obtenu dépend de la simulation en elle-même et ne peut être connu à l’avance. Toutefois, il est possible de définir de façon générale, comme nous l’avons décrit dans la section 5.1, quatre super-étapes dans une simulation sur les réseaux, que nous rappelons ici. Notons T1 et T2 les deux types d’éléments du réseau qui peuvent être indifféremment associés aux nœuds ou aux arêtes. Une itération t d’une simulation sur un réseau est alors, de façon générale, représentée par les quatre super- étapes suivantes : 1. Communication des éléments T1 à t − 1 2. Calcul des éléments T2 à t 3. Communication des éléments T2 à t − 1 ou/et t 4. Calcul des éléments T1 à t Il est possible de représenter l’ensemble des cas de simulation sur les réseaux en parallèle avec cette définition en quatre super-étapes BSP. Le partitionnement consiste donc en deux problèmes, tout d’abord équilibrer la charge de travail entre les processeurs pour les étapes 2 et 4, et réduire au maximum le volume de communications nécessaire aux étapes 1 et 3. On peut noter que l’étape 2 consiste à calculer T2 et a besoin au préalable des communications des éléments T1 pour effectuer ce calcul. On parlera alors d’une communication de T1 vers T2. L’équilibrage de charge consiste donc à équilibrer les deux types d’éléments T1 et T2, et la réduction du volume de communication consiste à minimiser les communications de T1 à T2 et de T2 à T1. Ces deux contraintes doivent être résolues de la même façon quelque soit leur ordre d’apparition et quelque soit donc l’association des types T1 et T2 aux nœuds et aux arêtes. Pour simplifier la suite de ce travail, nous étudierons le cas précis de la simulation de l’écoulement du sang dans les artères qui a été décrite dans la section 5.4, et dont les quatre super-étapes sont les suivantes : 1. Communication des arêtes à t − 1 2. Calcul des nœuds à t 3. Communication des nœuds à t 4. Calcul des arêtes à t La particularité du problème de partitionnement pour les réseaux est donc que des calculs et des communications sont effectués à la fois sur les arêtes et sur les nœuds du graphe. Si les équilibrages de charge des nœuds et des arêtes peuvent être traités de façon distincte, les communications engendrées par leur affectation sont, en revanche, non-distinctes et reliées par le réseau. Tout d’abord, afin de pouvoir traiter à la fois le partitionnement des nœuds et des arêtes en utilisant les outils classiques, qui ne traitent5.5. Partitionnement de réseaux 143 que les nœuds d’un graphe, nous commençons par changer la représentation du graphe du réseau. Le graphe G = (V, E) avec n nœuds v0, . . . , vn−1 et m arêtes e0, . . . , em−1 est transformé en un nouveau graphe G0 = (V 0 , E0 ) où |V 0 | = n + m et |E0 | = 2m. Pour chaque arête ek = (vi , vj ) ∈ E, un nœud v 0 n+k est ajouté, et l’arête ek est coupée en deux arêtes e 0 k = (vi , v0 n+k ) et e 0 2k = (v 0 n+k , vj ). Le graphe G0 représente donc les arêtes du graphe G comme des nœuds supplémentaires, tout en conservant la connectivité du graphe G. La figure 5.25 illustre un graphe G et le graphe associé G0 . Notons que G0 Figure 5.25 – Transformation du graphe G d’un réseau en graphe G0 . est un graphe biparti avec deux sous-ensembles de nœuds, les rouges et les bleus. Nous n’avons alors dans ce graphe que des liens du type bleu-rouge mais pas de liens du type bleu-bleu ou rouge-rouge. Dans ce nouveau graphe G0 , les étapes de communications 1 et 3, représentées dans les figures 5.26(a) et 5.26(b), deviennent : — Communication des nœuds rouges vers les nœuds bleus — Communication des nœuds bleus vers les nœuds rouges (a) Étape de communication 1, des nœuds rouges vers les nœuds bleus de G 0 . (b) Étape de communication 3, des nœuds bleus vers les nœuds rouges de G 0 . Figure 5.26 – Étapes de communication 1 et 3.144 Chapitre 5. SkelGIS pour des simulations sur réseaux Dans la suite, les nœuds bleus représenteront donc les nœuds du réseau initial G, et les nœuds rouges les arêtes du réseau initial G. Étant donné le graphe biparti G0 ainsi défini, l’ensemble des nœuds V 0 du graphe est composé de deux parties V r et V b , telles que V 0 = V r ∪V b et V r ∩V b = ∅. Le problème de partitionnement du graphe G0 consiste alors à partitionner V r et V b en p parties telles que V r = S i V r i et V b = S i V b i et telles que pour i 6= j ∈ J0, pJ, V r i ∩V r j = ∅ et V b i ∩V b j = ∅. Le partitionnement de G0 ainsi défini doit minimiser le volume de communications entre les processeurs, tout en répondant aux deux contraintes d’équilibrage de charge suivantes : ω(V r i ) ≤ (1 + ) ω(V r ) p (5.9) ω(V b i ) ≤ (1 + ) ω(V b ) p (5.10) où ω(A) représente le poids total des nœuds d’un ensemble A ∈ V , et où  représente le pourcentage de tolérance dans l’équilibrage de charge. Pour résoudre ce problème de partitionnement, le modèle de partitionnement d’hypergraphe (défini dans la section 2.3 de cette thèse) est utilisé sur le graphe G0 . Deux méthodes de partitionnement différentes sont étudiées et sont détaillées dans les deux sections suivantes. 5.5.2.2 Méthode à partitionnement unique La première méthode qui a été étudiée, appelée la méthode à partitionnement unique, est composée de deux étapes que nous allons expliquer en détails dans cette partie : 1. L’étape de communication des nœuds bleus vers les nœuds rouges est, tout d’abord, transformée en un problème de partitionnement d’hypergraphe, qui permet de distribuer les nœuds rouges sur les différents processeurs. 2. Une heuristique est ensuite appliquée pour distribuer les nœuds bleus sur les processeurs, tout en prenant en compte la distribution des nœuds rouges qui a été faite au préalable. Afin d’effectuer la première étape de cette méthode, une matrice A de taille m×n est créée et a pour but de représenter les communications des nœuds bleus vers les nœuds rouges. Les lignes de la matrice A représentent les nœuds bleus du graphe G0 , et les colonnes de la matrice A représentent, quant à elles, les nœuds rouges du graphe G0 . Si une communication est nécessaire d’un nœud bleu vers un nœud rouge, une valeur 1 est placée dans A aux coordonnées correspondantes. Si l’on distribue les colonnes de la matrice A (les nœuds rouges) aux processeurs, le volume de communication sera minimisé si et seulement si les éléments non nuls de chaque ligne sont répartis sur le minimum de processeurs différents. La distribution des colonnes de la matrice A revient en fait à procéder à un partitionnement d’hypergraphe suivant une dimension. Il s’agit donc du partitionnement row-net model [29], décrit dans l’état de l’art de cette thèse dans la section 2.3, qui consiste à distribuer les colonnes de la matrice A (les nœuds de5.5. Partitionnement de réseaux 145 l’hypergraphe), tout en cherchant à minimiser le nombre de coupures sur une ligne de A (une hyper-arête). La figure 5.27 donne un exemple de réseau, la matrice A qui lui est associée, et enfin l’hypergraphe Hr(A) qui lui est également associé. 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 0 2 3 51 6 4 Figure 5.27 – Exemple de réseau G0 avec la matrice A et les hypergraphes Hr et Hc qui y sont associés Le partitionnement de l’hypergraphe Hr associé à un réseau initial G peut être effectué avec le partitionneur Mondriaan [120] dans un mode à une dimension. Les nœuds rouges de G0 , c’est-à-dire les arêtes du réseau, sont alors distribués en respectant la contrainte (5.9) et en cherchant à minimiser les communications des nœuds bleus vers les nœuds rouges. Une fois cette première étape effectuée, le partitionnement de V r est terminé et respecte la contrainte d’équilibrage (5.9). Les nœuds rouges et bleus de G0 étant connectés par le réseau, il est important de trouver une heuristique permettant de distribuer les nœuds bleus en tenant compte de la distribution des nœuds rouges, afin de minimiser le nombre de communications nécessaires. Le problème de partitionnement pour les nœuds bleus est illustré dans la figure 5.28. En effet, étant donné quatre nœuds rouges déjà distribués aux processeurs p0, p1 et p2, comment choisir parmi ces trois processeurs celui qui sera attribué au nœud bleu. Afin d’expliquer l’heuristique mise en place pour le partitionnement des nœuds bleus, quelques définitions sont nécessaires. Pour un nœud v ∈ V b , deg(v) représente le nombre de nœuds rouges adjacents à v dans G0 , ou en d’autres termes le nombre d’arêtes adjacentes à v dans G. deg(v, Pi) représente le nombre de nœuds rouges adjacents à v et qui ont été distribués au processeur Pi . L’heuristique choisit d’attribuer le nœud v au processeur Pi de façon à maximiser deg(v, Pi), et de façon à vérifier la contrainte d’équilibrage (5.10). Notons que si il existe i, j ∈ J0, pJ qui satisfont deg(v, Pi) = deg(v, Pj ), alors P(v) = Pi si et seulement si ω(V b i ) < ω(V b j ), sinon P(v) = Pj . Grâce à cette heuristique les nœuds bleus de G0 sont partitionnés en tentant de respecter la contrainte d’équilibrage de charge (5.10), tout en minimisant les communications des nœuds rouges146 Chapitre 5. SkelGIS pour des simulations sur réseaux P0 P0 P1 P2 Quel P {P0,P1,P2} ? Figure 5.28 – Problème de partitionnement pour les nœuds bleus de G0 . vers les nœuds bleus. En effet, en reprenant l’exemple de la figure 5.28, l’heuristique décrite choisie idéalement d’assigner le nœud au processeur P0. Dans ce cas seules deux communications des nœuds rouges vers les nœuds bleus sont nécessaires. À l’inverse, si un autre processeur avait été choisi, trois communications des nœuds rouges vers les nœuds bleus auraient été nécessaires. 5.5.2.3 Méthode à partitionnement double La deuxième méthode de partitionnement qui a été étudiée, appelée la méthode à partitionnement double, est elle composée des trois étapes suivantes : 1. Tout comme dans la première méthode, l’étape de communication des nœuds bleus vers les nœuds rouges est transformée en un problème de partitionnement d’hypergraphe, qui permet de distribuer les nœuds rouges sur les différents processeurs. 2. L’étape de communication des nœuds rouges vers les nœuds bleus est ensuite transformée en un problème de partitionnement d’hypergraphe, qui permet de distribuer les nœuds bleus à leur tour. 3. Une dernière étape de permutation est mise en place pour permettre de réaffecter certains processeurs à certaines partitions et ainsi d’améliorer la minimisation du nombre de communications. La première étape de cette méthode est exactement la même que la première étape de la méthode à partitionnement unique décrite précédemment. Les communications des nœuds bleus vers les nœuds rouges y sont exprimées dans une matrice creuse A correspondant à la matrice d’incidence du graphe G. Puis la matrice A est transposée en un hypergraphe Hr, où les lignes de A représentent les hyper-arêtes et les colonnes les nœuds de Hr. Un partitionnement row-net à une dimension est effectué sur l’hypergraphe Hr avec le partitionneur Mondriaan [120]. La deuxième étape de cette méthode est, quant à elle, la transposée de la première étape. Les communications des nœuds rouges vers les nœuds bleus peuvent être représentées par la matrice AT , transposée de la matrice A. Cette matrice pourrait à son tour être transformée en un hypergraphe Hr(AT ) sur lequel serait appliqué un partitionnement à5.5. Partitionnement de réseaux 147 une dimension de type row net. Toutefois, il est plus simple de conserver la matrice A mais d’y appliquer un partitionnement à une dimension de type column net sur un hypergraphe noté Hc(A) = Hr(AT ) qui va, de la même façon, partitionner les nœuds bleus et réduire les communications des nœuds rouges vers les nœuds bleus. La figure 5.27 illustre ces deux premières étapes du partitionnement et les deux hypergraphes Hr(A) et Hc(A). La différence principale entre la première et la deuxième étape de cette méthode est le nombre de nœuds présents dans chaque hyper-arête. En effet, dans la première étape, le nombre de nœuds dans chaque hyper-arête est égal au degré du nœud bleu correspondant. Dans la deuxième étape, en revanche, le nombre de nœuds dans chaque hyper-arête est égal à deux puisque chaque nœud rouge de G0 est uniquement relié à deux nœuds bleus. Par conséquent, le partitionnement d’hypergraphe row-net (columnnet) appliqué dans la deuxième étape de la méthode est équivalent à un partitionnement de graphe standard où le nombre d’arêtes coupées doit être minimisé. Un partitionneur de graphe pourrait donc être utilisé pour résoudre la deuxième étape de la méthode, comme par exemple METIS [77] ou Scotch [100]. Toutefois, il est également possible d’utiliser le même partitionneur d’hypergraphes Mondriaan [120], et ainsi d’en abuser légèrement [53] tout en payant le coût supplémentaire en temps CPU. En effet, le partitionnement d’un hypergraphe n’est qu’une généralisation du partitionnement de graphe, cette méthode peut donc être utilisée pour le partitionnement de graphe mais demandera plus de calculs du fait de la généralisation qui y est appliquée. Une fois la première et la deuxième étape effectuées, les nœuds rouges et les nœuds bleus du graphe G0 sont attribués parmi les processeurs disponibles en respectant les deux contraintes d’équilibrage (5.9) et (5.10). Toutefois les deux partitionnements qui ont été effectués sont totalement indépendants et ne tiennent donc pas compte des connections qui relient les nœuds bleus et les nœuds rouges dans le réseau. La troisième étape va servir à prendre en compte ces liaisons et ainsi à réduire les communications engendrées par les deux partitionnements distincts. On obtient donc deux partitionnements, et l’on souhaite pouvoir réaffecter les processeurs dans ces distributions afin d’améliorer le volume de communications. Il s’agit donc d’un problème d’affectation dans un graphe biparti. Ce problème est équivalent à effectuer une permutation des processeurs de façon optimale. Tout d’abord, nous définissons une matrice W de taille p × p (p étant le nombre de processeurs) pour exprimer le nombre de communications évitées si une permutation était effectuée entre deux processeurs donnés. Le calcul de cette matrice W est basée sur la matrice A, puisque celle-ci représente les communications des nœuds bleus vers les nœuds rouges, et à l’inverse, en utilisant sa transposée, des nœuds rouges vers les nœuds bleus. Dans la matrice A, ai,j = 1 si un nœud bleu i est relié à un nœud rouge j. Une fois le partitionnement des nœuds bleus et rouges effectués, Φ(i) représente le processeur attribué pour le nœud bleu i, et Ψ(j) représente le processeur attribué pour le nœud rouge j. La matrice W est alors définie comme suit ws,t = X i : Φ(i)=s δi(t) (5.11)148 Chapitre 5. SkelGIS pour des simulations sur réseaux δi(t) = ( 1 si ∃j : ai,j = 1 ∧ Ψ(j) = t 0, sinon. (5.12) La taille de la matrice W dépend du nombre de processeurs utilisés et la matrice est généralement dense. L’élément ws,t de la matrice représente le nombre de communications évitées, des nœuds bleus vers les nœuds rouges, si le processeur s est permuté avec le processeur t. La matrice W peut donc être identifiée comme un graphe biparti complet Gw, illustré dans la figure 5.29. Un moyen de calculer la meilleure permutation possible de processeurs est alors de calculer le couplage ou l’appariement (ou le matching en anglais) maximum du graphe biparti complet Gw. p-1 p-1 W = ws,t t s 0 1 s p-1 0 1 t p-1 ws,t Figure 5.29 – La matrice W et le graphe biparti complet auquel la matrice peut être identifiée Gw. Le couplage maximum de Gw est équivalent à un problème d’assignement qui peut être résolu en O(p 4 ) en utilisant l’algorithme Hongrois, publié par Harold Kuhn en 1955 [83] ; et qui peut également être résolu en O(p 3 ) en utilisant une amélioration de cet algorithme. Si le nombre de processeurs p est grand, des approximations linéaires de cet algorithme peuvent également être utilisées. La matrice W représente les communications évitées, mais uniquement pour les communications des nœuds bleus vers les rouges. Le problème similaire peut être résolu pour la matrice AT et permettra de réduire les communications des nœuds rouges vers les nœuds bleus également. Une matrice W0 est alors calculée n’est pas égale à WT . Toutefois, en calculant de la même façon que W la matrice W0 , en utilisant AT au lieu de A, la valeur w 0 (s, t) de W0 représente le nombre de communications évitées en échangeant le processeur t avec le processeur s. Afin de maximiser les communications évitées par permutation, l’algorithme Hongrois doit alors être appliqué sur W = W + (W0 ) T . Cette deuxième méthode respecte donc les deux contraintes d’équilibrage (5.9) et (5.10) en appliquant deux partitionnements d’hypergraphe à une dimension sur la matrice A. Par la suite, afin de lier les deux distributions obtenues et d’en minimiser le volume des communications obtenu, un couplage maximum est appliqué sur la matrice W.5.5. Partitionnement de réseaux 149 5.5.2.4 Résultats A l’heure actuelle aucun résultat n’a encore été établi pour ces deux nouvelles mé- thodes de partitionnement des réseaux. Ces nouvelles méthodes s’inscrivent dans un cadre plus général que l’implémentation actuelle de SkelGIS, puisqu’elles généralisent le problème aux graphes et non plus seulement aux DAG. Un certain nombre d’adaptations est en cours pour permettre l’utilisation de ces méthodes de partitionnement, puis pour les évaluer sur le cas de test présenté dans la section 5.4. Une intuition sur les résultats attendus est toutefois possible. Il semble, à première vue, que la méthode à partitionnement simple soit plus intéressante. En effet, elle répond strictement aux deux contraintes d’équilibrage de charges des équations (5.9) et (5.10), tout comme la méthode à double partitionnement. Toutefois, elle distribue directement les sommets bleus en tenant compte des sommets rouges, alors que la méthode à double partitionnement effectue deux partitionnements totalement indépendants avant d’essayer de les rapprocher par un matching. Cela laisse penser que malgré le matching effectué la méthode à partitionnement double ne pourra être aussi efficace, en terme de volume de communications, que dans la première méthode. Mais essayons de décrire un modèle de coût pour prévoir les résultats de ces méthodes de façon plus formelle. Étant donné une simulation sur les réseaux implémentée en SkelGIS, nous pouvons noter T i comp le temps passé dans les calculs pour le processeur i. Étant donné T i 1comp et T i 2comp , le temps écoulé dans le calcul des nœuds et des arêtes du réseau (ou vice versa), pour le processeur i, nous considérons que T i comp = T i 1comp + T i 2comp . Les deux méthodes présentées dans cette section respectent strictement les deux contraintes d’équilibrage de charges (5.9) et (5.10). Cela signifie que pour tout processeurs i et j, tel que i 6= j, T i 1comp ≈ T j 1comp et T i 2comp ≈ T j 2comp . On peut alors considérer que le temps total de calcul de la simulation, Tcomp, est égale à max 0≤i

. HAL Id: tel-01067475 https://tel.archives-ouvertes.fr/tel-01067475 Submitted on 23 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITÉ PIERRE ET MARIE CURIE ÉCOLE DOCTORALE INFORMATIQUE, TÉLÉCOMMUNICATIONS ET ÉLECTRONIQUE Analyse de sécurité de logiciels système par typage statique — Application au noyau Linux— ÉTIENNE MILLON sous la direction d’Emmanuel Chailloux et de Sarah Zennou THÈSE pour obtenir le titre de Docteur en Sciences mention Informatique Soutenue le 10 juillet 2014 devant le jury composé de Rapporteurs Sandrine Blazy IRISA Pierre Jouvelot MINES ParisTech Directeurs Emmanuel Chailloux Université Pierre et Marie Curie Sarah Zennou Airbus Group Innovations Examinateurs Gilles Muller Université Pierre et Marie Curie Vincent Simonet Google Invité Olivier Levillain ANSSIi “ Many C programmers believe that « strong typing » just means pounding extra hard on the keyboard. Peter van den Linden ”ii REMERCIEMENTS Enfin la dernière page à écrire ! Combien de fois ai-je entendu que "les remerciements, c’est le plus facile". Et pourtant, je suis partagé entre la satisfaction d’arriver au bout de ce travail, et la crainte d’oublier une des nombreuses personnes qui m’ont aidé à y arriver. Je tiens à commencer par remercier mes encadrants de thèse, Emmanuel Chailloux et Sarah Zennou. Sans leurs conseils pertinents et leurs nombreuses relectures, je n’aurais pas pu arriver au bout de ce travail. Merci également à Sandrine Blazy et à Pierre Jouvelot d’avoir accepté de rapporter mon manuscrit, et pour leurs remarques qui ont permis d’améliorer sa qualité. Je veux également remercier les autres membres du jury, Gilles Muller et Vincent Simonet, ainsi qu’Olivier Levillain qui y a sa place en tant qu’invité. Si cette aventure a pu être menée à bien, c’est également grâce au travail réalisé par l’équipe de l’école doctorale, et en particulier à Marylin Galopin et Christian Queinnec qui ont toujours su m’aider dans cette véritable quête administrative qu’est le doctorat. Je souhaite d’ailleurs le meilleur à Bertrand Granado pour reprendre les rênes de l’EDITE. Le pendant du travail de recherche est traditionnellement celui de l’enseignement ; dans mon cas l’expérience pédagogique a été un peu courte, mais elle a été très agréable grâce aux équipes enseignantes des cours de Programmation et Données Génériques (LI220, « l’UE des chefs ») et de Techniques Évenementielles et Réactives (LI357, « l’UE Magnum »). Ce projet a commencé chez Airbus Group Innovations (alors EADS Innovation Works), alors que je n’étais qu’un étudiant ingénieur intéressé par la compilation. Merci à Wenceslas Godard et Charles Hymans de m’avoir offert ce stage, puis de l’étendre à ce projet de thèse. La suite a été plus quelque peu nébuleuse, et je remercie chaudement Axel Tillequin et toute l’équipe SE/IT pour la confiance qu’il ont pu m’offrir en m’accueillant dans un cadre exceptionnel pour un jeune chercheur. Merci une fois de plus à Sarah d’avoir accepté de reprendre ce projet. Mes remerciements vont également à une autre équipe qui m’a accueilli pendant ces années : l’équipe APR, et en particulier sa directrice Michèle Soria. Les différentes thématiques de recherche abordées dans le couloir on permis d’étendre mes horizons de doctorant. Je remercie également le personnel administratif qui a facilité mes conditions de travail durant toutes ces années. Une partie de ce projet a également été financée par le projet CERCLES². Je remercie en particulier Pascal Manoury pour l’accueil qu’il a pu m’apporter dans le laboratoire PPS de Si vous êtes juste là pour l’Université Paris Diderot. les blagues, ça commence ici. Le bureau 26-00-325 a participé à sa manière à l’élaboration de ce document. La pause café et sa pistonnade rituelle annoncée par Alberto ont permis de débattre jour après jour des avantages de la programmation générique (et Ramzy), des foncteurs applicatifs, de la meilleure manière d’écrire un interprète Basic en Rust ou de la stratégie qui nous permettrait d’en venir à bout de ce niveau 5 de Jamestown, le tout bien sûr schémas, rébus et contrepè- teries à l’appui. Merci donc à Vivien (dont je n’écorcherai pas le nom — contrairement à d’autres), Philippe (dont on sait où il se cache), Benjamin (pour son bon goût), Mathias (parce qu’il a la classe), Guillaume (pour ses deals de café du 9-3, tu me remettras 1kg de rouge t’as vu ?), Aurélien (le type-classieux de Rochechouart), Jérémie (λ-traître devant l’éternel) et tous ceux qui sont passés par là un peu moins longtemps.iii On raconte que la thèse c’est un ascenseur émotionnel. C’est cliché, mais pas complètement faux. Pour partager les moments agréables et faciliter les moments de doutes, un grand merci à mes amis qui ont toujours été là. Merci aussi à ma famille qui m’a toujours donné les moyens de poursuivre mes projets. D’ailleurs sans mes premières lignes de code sur l’Amstrad CPC 6128+ familial, j’aurais sûrement tourné différemment ! Enfin, merci à toi, Anaïs. Tu es certainement celle qui a vu le plus les coulisses de ce travail de longue haleine, jouant à la fois le rôle de confidente et d’attachée de presse, en répondant toujours « Bientôt ! » à la question « Alors Étienne, il soutient quand ? ». Aujourd’hui j’ai ma réponse : ça se passe le 10 Juillet et vous êtes tous invités. Spéciale dédicace à Tarpuy, Mato, Lady of the Pad, la dame des crêpes, aux thèmes de Guile et de l’invité surprise ainsi qu’à toute l’équipe de Final Form Games. Aucun λ-terme n’a été maltraité lors de la réalisation de ce document.TABLE DES MATIÈRES Table des matières iv 1 Introduction 1 1.1 Rôle d’un système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Séparation entre espace noyau et espace utilisateur . . . . . . . . . . . . . . . . 3 1.3 Systèmes de types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 L’analyse statique dans l’industrie aéronautique . . . . . . . . . . . . . . . . . . 7 1.6 De l’avionique à l’informatique d’entreprise . . . . . . . . . . . . . . . . . . . . 9 1.7 Objectifs et contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.8 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 I Méthodes formelles pour la sécurité 13 2 Systèmes d’exploitation 15 2.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Tâches et niveaux de privilèges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Appels système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Le Confused Deputy Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 Analyses statiques existantes 21 3.1 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Méthodes syntaxiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Analyse de valeurs et interprétation abstraite . . . . . . . . . . . . . . . . . . . . 22 3.4 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Langages sûrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6 Logique de Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.7 Assistants de preuve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Conclusion de la partie I 31 II Un langage pour l’analyse de code système : SAFESPEAK 33 4 Syntaxe et sémantique d’évaluation 35 4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3 Mémoire et valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4 Interprète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5 Opérations sur les valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.6 Opérations sur les états mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.7 Accesseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 ivTABLE DES MATIÈRES v 4.8 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.9 Valeurs gauches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.10 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.11 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.12 Erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.13 Phrases et exécution d’un programme . . . . . . . . . . . . . . . . . . . . . . . . 58 4.14 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5 Typage 63 5.1 Environnements et notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.3 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.5 Phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.6 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.7 Typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.8 Propriétés du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.9 Progrès et préservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6 Extensions de typage 81 6.1 Exemple préliminaire : les entiers utilisés comme bitmasks . . . . . . . . . . . 82 6.1.1 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.1.2 Exemple : ! x & y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.2 Analyse de provenance de pointeurs . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.2.1 Extensions noyau pour SAFESPEAK . . . . . . . . . . . . . . . . . . . . . 86 6.2.2 Extensions sémantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.3 Insuffisance des types simples . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.4 Extensions du système de types . . . . . . . . . . . . . . . . . . . . . . . 90 6.2.5 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Conclusion de la partie II 95 III Expérimentation 97 7 Implantation 99 7.1 NEWSPEAK et chaîne de compilation . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.2 L’outil ptrtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8 Étude de cas : le noyau Linux 111 8.1 Spécificités du code noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 8.2 Appels système sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 8.3 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 8.4 Premier exemple de bug : pilote Radeon KMS . . . . . . . . . . . . . . . . . . . . 113 8.5 Second exemple : ptrace sur architecture Blackfin . . . . . . . . . . . . . . . . 115 8.6 Procédure expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117vi TABLE DES MATIÈRES Conclusion de la partie III 123 9 Conclusion 125 9.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 9.2 Différences avec C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 9.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A Module Radeon KMS 133 B Syntaxe et règles d’évaluation 137 B.1 Syntaxe des expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 B.2 Syntaxe des instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.3 Syntaxe des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.4 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 B.5 Règles d’évaluation des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 B.6 Règles d’évaluation des valeurs gauches et expressions . . . . . . . . . . . . . . 140 B.7 Règles d’évaluation des instructions, phrases et programmes . . . . . . . . . . 141 B.8 Règles d’évaluation des extensions noyau . . . . . . . . . . . . . . . . . . . . . . 142 C Règles de typage 143 C.1 Règles de typage des constantes et valeurs gauches . . . . . . . . . . . . . . . . 143 C.2 Règles de typage des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 C.3 Règles de typage des expressions et instructions . . . . . . . . . . . . . . . . . . 145 C.4 Règles de typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 C.5 Règles de typage des extensions noyau . . . . . . . . . . . . . . . . . . . . . . . . 146 D Preuves 147 D.1 Composition de lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 D.2 Progrès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 D.3 Préservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 D.4 Progrès pour les extensions noyau . . . . . . . . . . . . . . . . . . . . . . . . . . 156 D.5 Préservation pour les extensions noyau . . . . . . . . . . . . . . . . . . . . . . . 157 Liste des figures 159 Liste des définitions 161 Liste des théorèmes et lemmes 161 Références web 163 Bibliographie 165C H A P I T R E 1 INTRODUCTION Communication, audiovisuel, transports, médecine : tous ces domaines se sont transformés dans les dernières décennies, en particulier grâce à la révolution numérique. En effet le plus petit appareil électrique contient maintenant des composants matériels programmables. En 2014, on pense bien sûr aux téléphones portables dont la fonctionnalité et la complexité les rapprochent des ordinateurs de bureau. Par exemple, le système d’exploitation Android de Google est fondé sur le noyau Linux, destiné à la base aux micro-ordinateurs. Le noyau d’un système d’exploitation est chargé de faire l’intermédiaire entre le maté- riel (processeur, mémoire, périphériques, . . . ) et les applications exécutées sur celui-ci (par exemple un navigateur web, une calculatrice ou un carnet d’adresses). Il doit aussi garantir la sécurité de celles-ci : en tant qu’intermédiaire de confiance, le noyau a un certain nombre de responsabilités et est le seul à avoir accès à certaines informations sensibles. Il est capital de s’assurer qu’il est bien le seul à pouvoir y accéder. En particulier, il faut pouvoir vérifier que les requêtes faites par l’utilisateur au noyau ne peuvent pas, volontairement ou involontairement, détourner ce dernier et lui faire fuiter des informations confidentielles. Le problème est que, comme tous les logiciels, les noyaux de système d’exploitation sont écrits par des humains qui ne sont pas parfaits. Les activités de relecture et de débogage ont beau prendre la majeure partie du temps de développement, il est facile de laisser passer des défauts de programmation. Ces erreurs, ou bugs, peuvent avoir des conséquences dramatiques sur le plan matériel ou humain. À titre d’exemple, un Airbus A320 embarque près de 10 millions de lignes de code : il est capital de vérifier que celles-ci ne peuvent pas mettre en danger la sûreté des passagers. Une technique efficace est de réaliser des tests, c’est-à-dire exécuter le programme sous un environnement contrôlé. On peut alors détecter des comportements non désirés. Mais même avec une grande quantité de tests il n’est pas possible de couvrir tous les cas d’utilisation. Une autre approche est d’analyser le code source du programme avant de l’exécuter et de refuser de lancer les programmes qui contiennent certaines constructions dangereuses. C’est l’analyse statique de programmes. Une des techniques d’analyse statique les plus répandues et les plus simples est le typage statique, qui consiste à associer, à chaque morceau de programme, une étiquette décrivant quel genre de valeur sera produite par son évaluation. Par exemple, si n est le nom d’une variable entière, alors n +2 produira toujours une valeur entière. Cela permet de savoir si les programmes manipuleront des données incompatibles entre elles. 12 CHAPITRE 1. INTRODUCTION Pour en revenir aux noyaux de système d’exploitation, ceux-ci manipulent à la fois des données sensibles et des données provenant du monde extérieur, pour lesquelles on n’a aucune garantie. On veut pouvoir distinguer ces deux classes de données. Plus précisément, un des points cruciaux pour garantir l’isolation d’un noyau de système d’exploitation est de restreindre la manière dont sont traitées les informations provenant des programmes utilisateur. Le but de cette thèse est de montrer que le typage statique peut être utilisé pour détecter et interdire ces manipulations dangereuses. 1.1 Rôle d’un système d’exploitation Un ordinateur est constitué de nombreux composants matériels : microprocesseur, mé- moire, et divers périphériques. Et au niveau de l’utilisateur, des dizaines de logiciels permettent d’effectuer toutes sortes de calculs et de communications. Le système d’exploitation permet de faire l’interface entre ces deux échelles. Au cours de l’histoire des systèmes informatiques, la manière de les programmer a beaucoup évolué. Au départ, les programmeurs avaient accès au matériel dans son intégralité : toute la mémoire pouvait être accédée, toutes les instructions pouvaient être utilisées. Néanmoins cela était un peu restrictif, puisque cela ne permet qu’à une personne d’interagir avec le système. Dans la seconde moitié des années 1960, sont apparus les premiers systèmes « à temps partagé », permettant à plusieurs utilisateurs de travailler en même temps. Permettre l’exécution de plusieurs programmes en même temps est une idée importante, mais elle n’est pas sans difficultés techniques : en effet les ressources de la machine doivent être aussi partagées entre les utilisateurs et les programmes. Par exemple, plusieurs programmes vont utiliser le processeur les uns à la suite des autres ; et chaque programme aura à sa disposition une partie de la mémoire principale, ou du disque dur. Si plusieurs programmes s’exécutent de manière concurrente sur le même matériel, il faut s’assurer que l’un ne puisse pas écrire dans la mémoire de l’autre, et aussi que les deux n’utilisent pas la carte réseau en même temps. Ce sont des rôles du système d’exploitation. Ainsi, au lieu d’accéder directement au matériel via des instructions de bas niveau, les programmes communiquent avec le noyau, qui centralise donc les appels au matériel, et abstrait certaines opérations. Par exemple, comparons ce qui se passe concrètement lors de la copie de données depuis un cédérom ou une clef USB. • Dans le cas du cédérom, il faut interroger le bus SATA, interroger le lecteur sur la pré- sence d’un disque dans le lecteur, activer le moteur, calculer le numéro de trame des données sur le disque, demander la lecture, puis déclencher une copie de la mémoire. • Avec une clef, il faut interroger le bus USB, rechercher le bon numéro de périphérique, le bon numéro de canal dans celui-ci, lui appliquer une commande de lecture au bon numéro de bloc, puis copier la mémoire. Ces deux opérations, bien qu’elles aient la même intention (copier de la mémoire depuis un périphérique amovible), ne sont pas effectuées en extension de la même manière. C’est pourquoi le système d’exploitation fournit les notions de fichier, lecteur, etc : le programmeur n’a plus qu’à utiliser des commandes de haut niveau (« monter un lecteur », « ouvrir un fichier », « lire dans un fichier ») et, selon le type de lecteur, le système d’exploitation effectuera les actions appropriées. En résumé, un système d’exploitation est l’intermédiaire entre le logiciel et le matériel, et en particulier est responsable de la gestion de la mémoire, des périphériques et des pro-1.2. SÉPARATION ENTRE ESPACE NOYAU ET ESPACE UTILISATEUR 3 cessus. Les détails d’implantation ne sont pas présentés à l’utilisateur ; à la place, il manipule des abstractions, comme la notion de fichier. Pour une explication détaillée du concept de système d’exploitation ainsi que des cas d’étude, on pourra se référer à [Tan07]. 1.2 Séparation entre espace noyau et espace utilisateur Puisque le noyau est garant d’une utilisation sûre du matériel, il ne doit pas pouvoir être manipulé directement par l’utilisateur ou les programmes exécutés. Ainsi, il est nécessaire de mettre en place des protections entre les espaces noyau et utilisateur. Au niveau matériel, on utilise la notion de niveaux de privilèges pour déterminer s’il est possible d’exécuter une instruction. D’une part, le processeur contient un niveau de privilège intrinsèque. D’autre part, chaque zone mémoire contenant du code ou des données possède également un niveau de privilège minimum nécessaire. L’exécution d’une instruction est alors possible si et seulement si le niveau de privilège du processeur est supérieur à celui de l’instruction et des opé- randes mémoires qui y sont présentes 1. Par exemple, supposons qu’un programme utilisateur contienne l’instruction « déplacer le contenu du registre EAX vers l’adresse mémoire a », où a fait partie de l’espace mémoire de l’utilisateur. Alors aucune erreur de protection mémoire n’est déclenchée. Ainsi, pour une instruction manipulant des données en mémoire, les accès possibles sont décrits dans le tableau suivant. En cas d’impossibilité, une erreur se produit et l’exécution s’arrête. Par exemple, l’avant-dernière ligne indique que, si un programme tente de lire une variable du noyau, celui-ci sera arrêté par une exception. Mode du processeur Privilège (code) Privilège (données) Accès possible Noyau Noyau Noyau Oui Noyau Noyau Utilisateur Oui Noyau Utilisateur Noyau Oui Noyau Utilisateur Utilisateur Oui Utilisateur Noyau Noyau Non Utilisateur Noyau Utilisateur Non Utilisateur Utilisateur Noyau Non Utilisateur Utilisateur Utilisateur Oui En plus de cette vérification, certains types d’instructions sont explicitement réservés au mode le plus privilégié : par exemple les lectures ou écritures sur des ports matériels, ou celles qui permettent de définir les niveaux de privilèges des différentes zones mémoire. Comme les programmes utilisateur ne peuvent pas accéder à ces instructions de bas niveau, ils sont très limités dans ce qu’ils peuvent faire. En utilisant seulement les seules instructions non privilégiées, on peut uniquement réaliser des calculs, sans réaliser d’opérations visibles depuis l’extérieur du programme. Pour utiliser le matériel ou accéder à des abstractions de haut niveau (comme créer un nouveau processus), ils doivent donc passer par l’intermédiaire du noyau. La communication entre le noyau et les programmes utilisateur est constituée du mécanisme des appels système. 1. Ici « supérieur » est synonyme de « plus privilégié ». Dans l’implantation d’Intel présentée dans le chapitre 2, les niveaux sont numérotés de 0 à 3, où le niveau 0 est le plus privilégié.4 CHAPITRE 1. INTRODUCTION Lors d’un appel système, une fonction du noyau est invoquée (en mode noyau) avec des paramètres provenant de l’utilisateur. Il faut donc être particulièrement précautionneux dans le traitement de ces données. Par exemple, considérons un appel système de lecture depuis un disque : on passe au noyau les arguments (d,o,n,a) où d est le nom du disque, o (pour offset) l’adresse sur le disque où commencer la lecture, n le nombre d’octets à lire et a l’adresse en mémoire où commencer à stocker les résultats. Dans le cas d’utilisation prévu, le noyau va copier la mémoire lue dans a. Le processeur est en mode noyau, en train d’exécuter une instruction du noyau manipulant des données utilisateur. D’après le tableau de la page 3, aucune erreur ne se produit. Mais même si ce cas ne produit pas d’erreur à l’exécution, il est tout de même codé de manière incorrecte. En effet, si on passe à l’appel système une adresse a faisant partie de l’espace noyau, que se passe-t-il ? L’exécution est presque identique : au moment de la copie on est en mode noyau, en train d’exécuter une instruction du noyau manipulant des données noyau. Encore une fois il n’y a pas d’erreur à l’exécution. On peut donc écrire n’importe où en mémoire. De même, une fonction d’écriture sur un disque (et lisant en mémoire) permettrait de lire de la mémoire du noyau. À partir de ces primitives, on peut accéder aux autres processus exécutés, ou détourner l’exécution vers du code arbitraire. L’isolation est totalement brisée à cause de ces appels système. La cause de ceci est qu’on a accédé à la mémoire en testant les privilèges du noyau au lieu de tester les privilèges de celui qui a fait la requête (l’utilisateur). Ce problème est connu sous le nom de confused deputy problem [Har88]. Pour implanter un appel système, il est donc nécessaire d’interdire le déréférencement direct des pointeurs dont la valeur peut être contrôlée par l’utilisateur. Dans le cas du passage par adresse d’un argument, il aurait fallu vérifier à l’exécution que celui-ci a bien les mêmes privilèges que l’appelant. Il est facile d’oublier d’ajouter cette vérification, puisque le cas « normal » fonctionne. Avec ce genre d’exemple on voit comment les bugs peuvent arriver si fréquemment et pourquoi il est aussi capital de les détecter avant l’exécution. 1.3 Systèmes de types La plupart des langages de programmation incorporent la notion de type, dont un des buts est d’empêcher de manipuler des données incompatibles entre elles. En mémoire, les seules données qu’un ordinateur manipule sont des nombres. Selon les opérations effectuées, ils seront interprétés comme des entiers, des adresses mémoire ou des caractères. Pourtant il est clair que certaines opérations n’ont pas de sens : par exemple, multiplier un nombre par une adresse ou déréférencer le résultat d’une division sont des comportements qu’on voudrait pouvoir empêcher. En un mot, le but du typage est de classifier les objets et de restreindre les opérations possibles selon la classe d’un objet : en somme, « ne pas ajouter des pommes et des oranges ». Le modèle qui permet cette classification est appelé système de types et est en général constitué d’un ensemble de règles de typage, comme « un entier plus un entier égale un entier ». Typage dynamique Dans ce cas, chaque valeur manipulée par le programme est décorée d’une étiquette définissant comment interpréter la valeur en question. Les règles de typage sont alors réalisées à l’exécution. Par exemple, l’opérateur « + » vérifie que ses deux opérandes ont une étiquette « entier », et construit alors une valeur obtenue en faisant l’addition des1.3. SYSTÈMES DE TYPES 5 deux valeurs, avec une étiquette « entier ». C’est ce qui se passe par exemple dans le langage Python [☞4]. Typage statique Dans ce cas on fait les vérifications à la compilation. Pour vérifier ceci, on donne à chaque fonction un contrat comme « si deux entiers sont passés, et que la fonction renvoie une valeur, alors cette valeur sera un entier ». Cet ensemble de contrats peut être vérifié statiquement par le compilateur, à l’aide d’un système de types statique. Par exemple, on peut dire que l’opérateur « + » a pour type (INT, INT) → INT. Cela veut dire que, si on lui passe deux entiers (INT, INT), alors la valeur obtenue est également un entier. A contrario, si autre chose qu’un entier est passé à cet opérateur, le programme ne compile pas. Typage fort ou faible Indépendamment du moment où est faite cette analyse, on peut avoir plus ou moins de garanties sur les programmes sans erreurs de typage. En poussant à l’extrême, les systèmes de types forts garantissent que les valeurs ont toujours le type attendu. Avec du typage statique, cela permet d’éliminer totalement les tests de typage à l’exécution. Mais souvent ce n’est pas le cas, car il peut y avoir des constructions au sein du langage qui permettent de contourner le système de types, comme un opérateur de transtypage. On parle alors de typage faible. Polymorphisme Parfois, il est trop restrictif de donner un unique type à une fonction. Si on considère une fonction ajoutant un élément à une liste, ou une autre triant un tableau en place, leur type doit-il faire intervenir le type des éléments manipulés ? En première approximation, on peut imaginer fournir une version du code par type de données à manipuler. C’est la solution retenue par le langage C, ou par les premières versions du langage Pascal, ce qui rendait très difficile l’écriture de bibliothèques [Ker81]. On parle alors de monomorphisme. Une autre manière de procéder est d’autoriser plusieurs fonctions à avoir le même nom, mais avec des types d’arguments différents. Par exemple, on peut définir séparément l’addition entre deux entiers, entre deux flottants, ou entre un entier et un flottant. Selon les informations connues à la compilation, la bonne version sera choisie. C’est ainsi que fonctionnent les opérateurs en C++. On parle de polymorphisme ad hoc, ou de surcharge. Une autre technique est de déterminer la fonction appelée non pas par le type de ses arguments, mais par l’objet sur lequel on l’appelle. Cela permet d’associer le comportement aux données. On parle alors de polymorphisme objet. Dans ce cas, celui-ci repose sur le soustypage : si A1 et A2 sont des sous-types de B, on peut utiliser des valeurs de type A1 ou A2 là où une valeur de type B est attendue. Dans ce cas, la fonction correspondante sera appelée. La dernière possibilité est le polymorphisme paramétrique, qui consiste à utiliser le même code quel que soit le type des arguments. Dans ce cas, on utilise une seule fonction pour traiter une liste d’entiers ou une liste de flottants, par exemple. Au lieu d’associer à chaque fonction un type, dans certains cas on lui associe un type paramétré, instanciable en un type concret. Dans le cas des fonctions de traitement de liste, l’idée est que lorsqu’on ne touche pas aux éléments, alors le traitement est valable quel que soit leur type. Cette technique a été décrite en premier dans [Mil78]. Pour un tour d’horizon de différents systèmes de types statiques, avec en particulier du polymorphisme, on pourra se référer à [Pie02].6 CHAPITRE 1. INTRODUCTION 1.4 Langages Le système Unix, développé à partir de 1969, a tout d’abord été développé en assembleur sur un mini-ordinateur PDP-7, puis a été porté sur d’autres architectures matérielles. Pour aider ce portage, il a été nécessaire de créer un « assembleur portable », le langage C [KR88, ISO99]. Son but est de fournir des abstractions au dessus du langage d’assemblage. Les structures de contrôle (if, while, for) permettent d’utiliser la programmation structurée, c’est- à-dire en limitant l’utilisation de l’instruction goto. Les types de données sont également abstraits de la machine : ainsi, int désigne un entier machine, indépendamment de sa taille concrète. Son système de types, bien que statique (il peut y avoir des erreurs de typage à la compilation), est assez rudimentaire : toutes les formes de transtypage sont acceptées, certaines conversions sont insérées automatiquement par le compilateur, et la plupart des abstractions fournies par le langage sont perméables. Le noyau Linux est écrit dans un dialecte du langage C. Le noyau du système Mac OS X d’Apple est également un dérivé d’Unix, et est donc aussi écrit dans ce langage. Néanmoins ce langage n’est pas facile à analyser, car il est conçu pour être facilement écrit par des programmeurs humains. Certaines constructions sont ambigües 2, et de nombreux comportements sont implicites 3. Si on veut analyser des programmes, il est plus pratique de travailler sur une représentation intermédiaire plus simple afin d’avoir moins de traitements dupliqués. Dans ce cas on ajoute une phase préliminaire à l’analyse, qui consiste à convertir le code à étudier vers cette représentation. On présente quelques langages qui peuvent servir ce rôle : Middle-ends Les premiers candidats sont bien entendu les représentations intermédiaires utilisées dans les compilateurs C. Elles ont l’avantage d’accepter, en plus du C standard, les diverses extensions (GNU, Microsoft, Plan9) utilisées par la plupart des logiciels. En particulier, le noyau Linux repose fortement sur les extensions GNU. GCC utilise une représentation interne nommée GIMPLE [Mer03]. Il s’agit d’une structure d’arbre écrite en C, reposant sur de nombreuses macros afin de cacher les détails d’implantation interne pouvant varier entre deux versions. Cette représentation étant réputée difficile à manipuler, le projet MELT [Sta11] permet de générer un plugin de compilateur écrit dans un dialecte de Lisp. LLVM [LA04] est un compilateur développé par la communauté open-source puis sponsorisé par Apple. À la différence de GCC, sa base de code est écrite en C++. Il utilise une repré- sentation intermédiaire qui peut être manipulée sous forme d’une structure de données C++, d’un fichier de code-octet compact, ou textuelle. Cmm est une représentation interne utilisée pour la génération de code lors de la compilation d’OCaml [LDG+10, CMP03], et disponible dans les sources du compilateur (il s’agit donc d’une structure de données OCaml). Ce langage a l’avantage d’être très restreint, mais 2. Selon qu’il existe un type nommé a, l’expression (a)-(b) sera interprétée comme le transtypage de -(b) dans le type a, ou la soustraction des deux expressions (a) et (b). 3. Par exemple, une fonction acceptant un entier long peut être appelée avec un entier de taille plus petite. Celui-ci sera alors converti implicitement.1.5. L’ANALYSE STATIQUE DANS L’INDUSTRIE AÉRONAUTIQUE 7 malheureusement il n’existe pas directement de traducteur permettant de compiler C vers Cmm. C- - [PJNO97] [☞1], dont le nom est inspiré du précédent, est un projet qui visait à unifier les langages intermédiaires utilisés par les compilateurs. L’idée est que, si un front-end peut émettre du C- - (sous forme de texte), il est possible d’obtenir du code machine efficace. Le compilateur Haskell GHC, par exemple, utilise une représentation intermédiaire très similaire à C- -. Langages intermédiaires ad hoc Comme le problème de construire une représentation intermédiaire adaptée à une analyse statique n’est pas nouveau, plusieurs projets ont déjà essayé d’y apporter une solution. Puisqu’ils sont développés en parallèle des compilateurs, le support des extensions est en général moins important dans ces langages. CIL [NMRW02] est une représentation en OCaml d’un programme C, développée depuis 2002. Grâce à un mécanisme de plugins, elle permet de prototyper rapidement des analyses statiques de programmes C. CompCert C, Clight et Cminor sont des langages intermédiaires utilisés dans Compcert, un compilateur certifié pour C [BDL06, AB07]. C’est-à-dire que les transformations sémantiques sont faites de manière prouvée. Ces langages intermédiaires sont utilisés pour les passes de front-end et de middle-end. 1.5 L’analyse statique dans l’industrie aéronautique En face du problème théorique et technique décrit dans la section 1.2, il faut mettre en perspective les problématiques industrielles liées à celui-ci. Les travaux présentés ici ont en effet été réalisés dans l’équipe de sécurité et sûreté logicielle d’EADS Innovation Works, dans le cadre d’une convention industrielle de formation par la recherche (CIFRE). Aujourd’hui, la réussite de nombreuses missions dépend de logiciels dont la taille est de plus en plus grande. Ainsi, en cas de fautes dans ce genre de logiciel, on peut se retrouver face à de grands impacts économiques, voire risquer des vies humaines. On comprend bien que les phases de vérification et de certification sont au cœur du cycle de vie des logiciels avioniques. A titre d’exemple, l’échec du premier vol d’Ariane 5 aurait certainement pu être évité si le logiciel de contrôle de vol avait été vérifié plus efficacement [Lan96]. Plusieurs méthodes existent pour éliminer les risques de fautes. En fait, deux approches duales sont nécessaires : les tests et les méthodes formelles. La première consiste à mettre le logiciel dans des situations concrètes et à vérifier que la sortie correspond au résultat attendu : c’est la technique des tests. Les tests « boîte noire » consistent à tester en ayant à disposition uniquement les spécifications des modules à différentes échelles (par exemple : logiciel, module, classe, méthode). Au contraire, les tests dits « boîte blanche » sont écrits en ayant à disposition l’implémentation. Cela permet par exemple de s’assurer que chaque chemin d’exécution est emprunté. Cette manière de procéder est similaire à la preuve par neuf enseignée aux enfants : il est possible de prouver l’erreur, mais pas que le programme est correct.8 CHAPITRE 1. INTRODUCTION L’approche des méthodes formelles, au contraire, permet de s’assurer de l’absence d’erreurs à l’exécution. Par exemple, l’analyse statique par interprétation abstraite permet d’étudier les relations exposées entre les variables afin d’en déduire les ensembles de valeurs dans lesquels elles évoluent. En s’assurant que ceux-ci sont « sûrs », on prouve l’absence d’erreurs de manière automatisée. L’interprétation abstraite repose sur l’idée suivante : au lieu de considérer que les variables possèdent une valeur, on utilise un domaine abstrait qui permet de voir les variables comme possédant un ensemble de valeurs possibles. On dit que l’approche est sound si l’abstraction d’un ensemble de valeurs est un surensemble de l’ensemble concret. Autrement dit, on réalise une surapproximation. La zone « sûre » (correspondant aux exécutions sans erreurs) a une forme souvent assez simple compte tenu des erreurs considérées : c’est un produit d’ensembles simples, comme des intervalles. L’ensemble des comportements réels du programme est au contraire d’une forme plus complexe et non calculable. En calculant une approximation de ce dernier, de forme plus simple, on peut tester plus facilement que les comportements sont dans la zone sûre : le fait que l’analyse soit sound, c’est-à-dire que l’approximation ne manque aucun comportement, permet de prouver l’absence d’erreurs. La figure 1.1 résume cette approche : l’ensemble des valeurs dangereuses est représenté par un ensemble hachuré, l’ensemble des valeurs sûres est en blanc, l’ensemble des comportements réels du programme est noté par des points, et l’approximation en gris. Plusieurs cas peuvent se produire. Dans la figure 1.1(a), on a prouvé à la compilation que le programme ne pourra pas comporter d’erreurs à l’exécution. Dans la figure 1.1(b), l’approximation recouvre les cas dangereux : on émet une alarme par manque de précision. Dans la figure 1.1(c) l’approximation n’est pas sound (par construction, on évite ce cas). Enfin, dans la figure 1.1(d), on émet une alarme à raison, car il existe des comportements erronés. Toute la difficulté est donc de construire une surapproximation correcte mais conservant une précision suffisante. Pour construire cette surapproximation, on peut employer divers outils. Par exemple, un entier pourra être représenté par sa valeur minimale et sa valeur maximale (domaine abstrait des intervalles), et un pointeur sur un tableau peut être représenté par un ensemble de variables associé à un décalage (offset) par rapport au début de la zone mémoire (domaine des pointeurs sur tableaux). Le projet Penjili Dans ce sens, des outils fondés sur l’interprétation abstraite ont été développés chez EADS Innovation Works dans le cadre du projet Penjili [AH07]. Ces analyses statiques ne manipulent pas directement du code C, mais un langage intermédiaire appelé NEWSPEAK [HL08]. Celui-ci est suffisamment expressif pour compiler la plupart des programmes C, y compris de nombreuses extensions GNU utilisées dans le noyau Linux (section 8.1), et des traducteurs automatiques depuis C et Ada existent (section 7.1). Ensuite, ses instructions sont orthogonales et minimales : il existe en général une seule manière de faire les choses. Par exemple, le flot de contrôle est restreint à la boucle infinie et au saut en avant (« break » généralisé). Enfin, lorsque certaines constructions sont ambigües, un choix est fait. Par exemple, l’évaluation des arguments d’une fonction est faite dans un ordre précis, les tailles des types sont indiquées à chaque déclaration de variable, etc. Séparer le langage intermédiaire de la phase d’analyse permet de beaucoup simplifier l’analyseur statique. D’une part, les constructions redondantes comme les différents types1.6. DE L’AVIONIQUE À L’INFORMATIQUE D’ENTREPRISE 9 (a) (b) (c) (d) FIGURE 1.1 : Surapproximation. L’ensemble des états erronés est hachuré. L’ensemble des états effectifs du programme, noté par des points, est approximé par l’ensemble en gris. de boucles ne sont traitées qu’une fois. D’autre part, lorsque le langage source est étendu (en supportant une nouvelle extension de C par exemple), l’analyseur n’a pas besoin d’être modifié. Le langage NEWSPEAK, ainsi que les outils permettant de le manipuler, sont disponibles sous license libre sur [☞3]. L’analyseur statique Penjili, reposant sur ces outils, a été utilisé pour analyser des logiciels embarqués critiques de plusieurs millions de lignes de code. Ce dernier n’est pour le moment pas open-source. Tous ces outils sont écrits dans le langage OCaml [LDG+10, CMP03]. 1.6 De l’avionique à l’informatique d’entreprise Vérifier la sûreté des logiciels avioniques est critique, mais cela présente l’avantage que ceux-ci sont développés avec ces difficultés à l’esprit. Il est plus simple de construire un système sécurisé en connaissant toutes les contraintes d’abord, plutôt que de vérifier a posteriori qu’un système existant peut répondre à ces contraintes de sûreté. Néanmoins cette manière de concevoir des logiciels est très coûteuse. Pour des composants qui sont moins critiques, il peut donc être intéressant de considérer des logiciels ou bibliothèques existants, en particulier dans le monde de l’open-source. Ces logiciels sont plus difficiles à analyser, car ils sont écrits sans contraintes particulières. Non seulement toutes les constructions du langage sont autorisées, même celles qui sont difficiles à traiter (transtypage, allocation dynamique, récursion, accès au système de fichiers, etc), mais aussi des extensions non standards peuvent être utilisées.10 CHAPITRE 1. INTRODUCTION Programmes non autosuffisants La grande majorité des programmes ne se suffisent pas à eux-mêmes. En effet, ils interagissent presque toujours avec leur environnement ou appellent des fonctions de bibliothèque. Cela veut dire qu’un fichier en cours d’analyse peut contenir des appels à des fonctions inconnues. Non seulement on n’a pas accès à leur code source, mais en plus on ne connaît pas a priori leur spécification. Une solution peut être de prévoir un traitement particulier pour celles-ci (par exemple en leur attribuant un type prédéfini). Certaines interagissent directement avec le système d’exploitation, comme les fonctions d’ouverture ou d’écriture dans un fichier. D’autres modifient totalement le mode d’exécution du programme. Par exemple, pthread_create(&t, NULL, f, NULL) lance l’exécution de f(NULL) tout en continuant l’exécution de la fonction en cours dans un fil d’exécution concurrent. Extensions du langage Par exemple, la figure 1.2 démontre l’influence de l’attribut packed (supporté par GCC) sur la compilation d’une structure. Sans celui-ci, les champs sont alignés de manière à faciliter les accès à la mémoire, par exemple en faisant démarrer les adresses de chaque champ sur un multiple de 4 octets (en gras). Cela nécessite d’introduire des octets de padding (en gris) qui ne sont pas utilisés. La taille totale de cette structure est donc de 12 octets. struct s { char a; int b; short c; }; a b c struct s { char a; int b; short c; } __attribute__((packed)); a b c FIGURE 1.2 : Utilisation de l’attribut non-standard packed Au contraire, l’utilisation de packed supprime totalement le padding et permet de diminuer alors la taille de la structure à 7 octets seulement. Puisque b et c ne sont pas alignés, leur accès sera fait de manière moins efficace. De manière générale, les compilateurs permettent de personaliser finement le code émis grâce à des extensions. Elles changent parfois le mode d’exécution des programmes d’une manière subtile et pas toujours bien spécifiée ni documentée. 1.7 Objectifs et contributions de la thèse Le but de ce travail est de définir et d’implanter des analyses statiques « légères » sur le langage C (c’est-à-dire plus simples que les analyses de valeurs par interprétation abstraite) pour détecter les utilisations dangereuses de pointeurs utilisateur. Nous proposons d’étendre NEWSPEAK pour analyser des propriétés de sécurité par typage sur du code non avionique. En effet, les types permettent de modéliser l’environnement d’exécution d’un programme (ici, les paramètres d’appels système) avec un grain assez grand, alors qu’être plus fin est difficile et nécessite de modéliser l’environnement.1.8. PLAN DE LA THÈSE 11 Nos contributions sont les suivantes : • Une première étape est de définir un sous-ensemble sûr du langage source. En effet, le langage C permet des conversions non sûres entre données, ce qui limite l’intérêt du typage. On définit alors un langage impératif avec un modèle mémoire de plus haut niveau, interdisant ces constructions : SAFESPEAK. Celui-ci est un modèle inspiré du langage NEWSPEAK, déjà utilisé pour d’autres analyses statiques. • Sur ce langage on définit une sémantique opérationnelle, qui permet de raisonner sur les exécutions des programmes. On profite du caractère structuré des états mémoire pour exprimer cette sémantique en terme de lentilles bidirectionnelles, permettant de décrire la modification en profondeur de la mémoire. • Au cœur de notre travail se trouve un système de types sûrs pour SAFESPEAK, ainsi que deux extensions. La première permet d’illustrer l’approche typage en détectant les entiers utilisés comme ensembles de bits, et la seconde permet de résoudre notre problème de base, qui est la vérification des accès aux pointeurs utilisateur (présentés dans la section 1.2). • Notre formalisation est accompagnée d’un prototype, basé sur NEWSPEAK. Cela permet d’appliquer les règles de typage précédemment définies sur des programmes écrits en C, grâce aux outils existants développés par EADS. En particulier, cela permet d’analyser des parties du noyau Linux. Ce prototype est disponible sous une license libre. 1.8 Plan de la thèse Cette thèse est organisée en trois parties. La première décrit le contexte de ces travaux, ainsi que les solutions existantes. La deuxième expose notre solution, SAFESPEAK, d’un point de vue théorique. La troisième rend compte de la démarche expérimentale : comment la solution a été implantée et en quoi elle est applicable en pratique. Dans la partie I, on présente tout d’abord le fonctionnement général d’un système d’exploitation. On y introduit aussi les problèmes de manipulation de pointeurs contrôlés par l’utilisateur. Ceux-ci sont centraux puisqu’on désire les restreindre. On fait ensuite un tour d’horizon des techniques existantes permettant de traiter ce problème par analyse statique de code source. Dans la partie II, on décrit notre solution : le langage SAFESPEAK. Sa syntaxe y est d’abord décrite, puis sa sémantique ainsi qu’un système de types statiques. À ce niveau on a un bon support pour décrire des analyses statiques sur un langage impératif. On propose alors deux extensions du système de types. La première consiste à bien typer les entiers utilisés comme bitmasks. La seconde capture les problèmes d’adressage mémoire présents dans les systèmes d’exploitation, décrits dans la section 1.2. Pour ce faire, on ajoute des pointeurs contrôlés par l’utilisateur à la sémantique et au système de types. À chaque étape, c’est-à-dire avant et après ces ajouts, on établit une propriété de sûreté de typage reliant la sémantique d’exécution aux types statiques. Dans la partie III, on documente la démarche expérimentale associée à ces travaux. L’implantation du système de types sur le langage NEWSPEAK est d’abord décrite, reposant sur l’algorithme W de Damas et Milner. La manière de compiler depuis du code C est également présentée. Ensuite, on applique cette implantation à deux cas d’étude concrets dans le noyau12 CHAPITRE 1. INTRODUCTION Linux. L’un est un bug ayant touché un pilote de carte graphique, et l’autre un défaut dans l’implantation de la fonction ptrace. Dans chaque cas, un pointeur dont la valeur est contrô- lée par l’utilisateur crée un problème de sécurité, car un utilisateur malveillant peut lire ou écrire dans l’espace mémoire réservé au noyau. En lançant notre prototype, l’analyse de la version non corrigée lève une erreur alors que, dans la version corrigée, un type correct est inféré. On montre ainsi que le système de types capture précisément ce genre d’erreur de programmation. On conclut enfin en décrivant les possibilités d’extensions autant sur le point théorique qu’expérimental.Première partie Méthodes formelles pour la sécurité Après avoir décrit le contexte général de ces travaux, nous décrivons leurs enjeux. Le chapitre 2 explore plus en détail le fonctionnement d’un système d’exploitation, y compris la séparation du code en plusieurs niveaux de privilèges. L’architecture Intel 32 bits est prise comme support. En particulier, le mécanisme des appels système est décrit et on montre qu’une implantation naïve de la communication entre espaces utilisateur et noyau casse toute isolation. Le chapitre 3 consiste en un tour d’horizon des techniques existantes en analyses de programmes. Ces analyses se centrent autour des problèmes liés à la vé- rification de code système ou embarqué, y compris le problème de manipulation mémoire évoqué dans le chapitre 2. On conclut en introduisant notre solution : SAFESPEAK, un langage permettant de typer des programmes impératifs, plus précisément en ajoutant des types pointeurs abstraits. 13C H A P I T R E 2 SYSTÈMES D’EXPLOITATION Le système d’exploitation est le programme qui permet à un système informatique d’exé- cuter d’autres programmes. Son rôle est donc capital et ses responsabilités, multiples. Dans ce chapitre, nous allons voir à quoi il sert, et comment il peut être implanté. Pour ce faire, nous présentons ici de quoi est constitué un système Intel 32 bits et ce dont on se sert pour y implanter un système d’exploitation. 2.1 Architecture physique Un système informatique est principalement constitué d’un processeur (ou CPU pour Central Processing Unit), de mémoire principale (ou RAM pour Random Access Memory) et de divers périphériques. Le processeur est constitué de plusieurs registres internes qui permettent d’encoder l’état dans lequel il se trouve : quelle est l’instruction courante (registre EIP), quelle est la hauteur de la pile système (registre ESP), etc. Son fonctionnement peut être vu de la manière la plus simple qui soit comme la suite d’opérations : • charger depuis la mémoire la prochaine instruction ; • (optionnel) charger depuis la mémoire les données référencées par l’instruction ; • effectuer l’instruction ; • (optionnel) stocker en la mémoire les données modifiées ; • continuer avec l’instruction suivante. Les instructions sont constituées d’un opcode (mnémonique indiquant quelle opération faire) et d’un ensemble d’opérandes. La signification des opérandes dépend de l’opcode, mais en général ils permettent de désigner les sources et la destination (on emploiera ici la syntaxe AT&T, celle que comprend l’assembleur GNU). Les opérandes peuvent avoir plusieurs formes : une valeur immédiate ($4), un nom de registre (%eax) ou une référence à la mémoire (directement : addr ou indirectement : (%ecx) 1 ). On décrit les opcodes les plus utilisés, permettant de compiler un cœur de langage impératif : • mov src, dst copie le contenu de src dans dst ; • add src, dst calcule la somme des contenus de src et dst et place ce résultat dans dst ; 1. Cela consiste à interpréter le contenu du regitre ECX comme une adresse mémoire. 1516 CHAPITRE 2. SYSTÈMES D’EXPLOITATION • push src place src sur la pile, c’est-à-dire que cette instruction enlève au pointeur de pile ESP la taille de src, puis place src à l’adresse mémoire de la nouvelle valeur ESP ; • pop src réalise l’opération inverse : elle charge le contenu de la mémoire à l’adresse ESP dans src puis incrémente ESP de la taille correspondante ; • jmp addr saute à l’adresse addr : c’est l’équivalent de mov addr, %eip ; • call addr sert aux appels de fonction : cela revient à push %eip puis jmp addr ; • ret sert à revenir d’une fonction : c’est l’équivalent de pop %eip. Certaines de ces instructions font référence à la pile par le biais du registre ESP. Cette zone mémoire n’est pas gérée de manière particulière. Elle permet de gérer la pile des appels de fonction en cours grâce à la manière dont jmp et ret fonctionnent. Elle sert aussi à stocker les variables locales des fonctions. À l’aide de ces quelques instructions on peut implanter des algorithmes impératifs. Mais pour faire quelque chose de visible, comme afficher à l’écran ou envoyer un paquet sur le réseau, cela ne suffit pas : il faut parler au reste du matériel. Pour ceci, il y a deux techniques principales. D’une part, certains périphériques sont dits memory-mapped : ils sont associés à un espace mémoire particulier, qui ne permet pas de stocker des informations mais de lire ou d’écrire des données dans le périphérique. Par exemple, écrire à l’adresse 0xB8000 permet d’écrire des caractères à l’écran. L’autre système principal est l’utilisation des ports d’entrée/sortie. Cela correspond à des instructions spé- ciales in %ax, port et out port, %ax où port est un numéro qui correspond à un périphérique particulier. Par exemple, en écrivant dans le port 0x60, on peut contrôler l’état des indicateurs lumineux du clavier PS/2. 2.2 Tâches et niveaux de privilèges Alternance des tâches Sans mécanisme particulier, le processeur exécuterait uniquement une suite d’instructions à la fois. Pour lui permettre d’exécuter plusieurs tâches, un système de partage du temps existe. À des intervalles de temps réguliers, le système est programmé pour recevoir une interruption. C’est une condition exceptionnelle (au même titre qu’une division par zéro) qui fait sauter automatiquement le processeur dans une routine de traitement d’interruption. À cet endroit le code peut sauvegarder les registres et restaurer un autre ensemble de registres, ce qui permet d’exécuter plusieurs tâches de manière entrelacée. Si l’alternance est assez rapide, cela peut donner l’illusion que les programmes s’exécutent en même temps. Comme l’interruption peut survenir à tout moment, on parle de multitâche préemptif. En plus de cet ordonnancement de processus, l’architecture Intel permet d’affecter des niveaux de privilège à ces tâches, en restreignant le type d’instructions exécutables, ou en donnant un accès limité à la mémoire aux tâches de niveaux moins élevés. Le matériel permet 4 niveaux de privilèges (nommés aussi rings) : le ring 0 est le plus privilégié, le ring 3, le moins privilégié. Dans l’exemple précédent, on pourrait isoler l’ordonnanceur de processus en le faisant s’exécuter en ring 0 alors que les autres tâches seraient en ring 3.2.3. APPELS SYSTÈME 17 Mémoire virtuelle À partir du moment où plusieurs processus s’exécutent de manière concurrente, un problème d’isolation se pose : si un processus peut lire dans la mémoire d’un autre, des informations peuvent fuiter ; et s’il peut y écrire, il peut en détourner l’exécution. Le mécanisme de mémoire virtuelle permet de donner à deux tâches une vue différente de la mémoire : c’est-à-dire que vue de tâches différentes, une adresse contiendra une valeur différente (figure 2.1). Processus 1 Mémoire Processus 2 FIGURE 2.1 : Mécanisme de mémoire virtuelle. Ce mécanisme est contrôlé par la valeur du registre CR3 : les 10 premiers bits d’une adresse virtuelle sont un index dans le répertoire de pages qui commence à l’adresse contenue dans CR3. À cet index, se trouve l’adresse d’une table de pages. Les 10 bits suivants de l’adresse sont un index dans cette page, donnant l’adresse d’une page de 4 kio (figure 2.2). Plus de détails sur l’utilisation de ce mécanisme seront donnés dans la section 8.2. 31 2122 1112 0 Répertoire de pages Table de pages Page de 4 kio CR3 FIGURE 2.2 : Implantation de la mémoire virtuelle 2.3 Appels système Avec une telle isolation, tout le code qui est exécuté en ring 3 a une expressivité limitée. Il ne peut pas contenir d’instructions privilégiées comme in ou out, ni faire référence à des périphériques mappés en mémoire. C’est en effet au noyau d’accéder au matériel, et pas au code utilisateur. Il est donc nécessaire d’appeler une routine du noyau depuis le code utilisateur. C’est le but des appels système. Cela consiste à coupler une fonction du ring 3 à une fonction du ring 0 : en appelant la fonction non privilégiée, le flot d’exécution se retrouve dans le noyau avec les bons privilèges.18 CHAPITRE 2. SYSTÈMES D’EXPLOITATION Bien sûr, il n’est pas possible de faire directement un call puisque cela consisterait à faire un saut vers une zone plus privilégiée. Il y a plusieurs manières d’implanter ce mécanisme. Nous décrivons ici la technique historique à l’aide d’interruptions. Le processeur peut répondre à des interruptions, qui sont des événements extérieurs. Cela permet d’écrire du code asynchrone. Par exemple, une fois qu’un long transfert mémoire est terminé, une interruption est reçue. D’autres interruptions dites logicielles peuvent arriver lorsqu’une erreur se produit. Par exemple, diviser par zéro provoque l’interruption 0, et tenter d’exécuter une instruction privilégiée provoque l’interruption 14. On peut aussi provoquer manuellement une interruption par une instruction int dédiée. Une table globale définit, pour chaque numéro d’interruption, quelle est la routine à appeler pour la traiter, avec quel niveau de privilège, ainsi que le niveau de privilège requis pour pouvoir déclencher celle-ci avec l’instruction int. Il est donc possible de créer une interruption purement logicielle (on utilise en général le numéro 128, soit 0x80), déclenchable en ring 3 et traitée en ring 0. Les registres sont pré- servés, donc on peut les utiliser pour passer un numéro d’appel système (par exemple 3 pour read() et 5 pour open()) et leurs arguments. 2.4 Le Confused Deputy Problem On a vu que les appels système permettent aux programmes utilisateur d’accéder aux services du noyau. Ils forment donc une interface particulièrement sensible aux problèmes de sécurité. Comme pour toutes les interfaces, on peut être plus ou moins fin. D’un côté, une interface pas assez fine serait trop restrictive et ne permettrait pas d’implanter tout type de logiciel. De l’autre, une interface trop laxiste (« écrire dans tel registre matériel ») empêche toute isolation. Il faut donc trouver la bonne granularité. Nous allons présenter ici une difficulté liée à la manipulation de mémoire au sein de certains types d’appels système. Il y a deux grands types d’appels système. D’une part on trouve ceux qui renvoient un simple entier, comme getpid qui renvoie le numéro du processus appelant. pid_t pid = getpid(); printf("%d\n", pid); Ici, pas de difficulté particulière : la communication entre le ring 0 et le ring 3 est faite uniquement à travers les registres, comme décrit dans la section 8.2. Mais la plupart des appels système communiquent de l’information de manière indirecte, à travers un pointeur. L’appellant alloue une zone mémoire dans son espace d’adressage et passe un pointeur à l’appel système. Ce mécanisme est utilisé par exemple par la fonction gettimeofday (figure 2.3). Considérons une implantation naïve de cet appel système qui écrirait directement à l’adresse pointée. Si le pointeur fourni est dans l’espace d’adressage du processus, on est dans le cas d’utilisation normal et l’écriture est donc possible. Si l’utilisateur passe un pointeur dont la valeur correspond à la mémoire réservée au noyau, que se passe-t-il ? Comme le déréférencement est fait dans le code du noyau, il est également fait en ring 0, et va pouvoir être réalisé sans erreur : l’écriture se fait et potentiellement une structure importante du noyau est écrasée. Un utilisateur malveillant peut donc utiliser cet appel système pour écrire à n’importe quelle adresse dans l’espace d’adressage du noyau. Ce problème vient du fait que l’appel2.4. LE CONFUSED DEPUTY PROBLEM 19 struct timeval tv; struct timezone tz; int z = gettimeofday(&tv, &tz); if (z == 0) { printf( "tv.tv_sec = %ld\ntv.tv_usec = %ld\n" "tz.tz_minuteswest = %d\ntz.tz_dsttime = %d\n", tv.tv_sec, tv.tv_usec, tz.tz_minuteswest, tz.tz_dsttime ); } FIGURE 2.3 : Appel de gettimeofday système utilise les privilèges du noyau au lieu de celui qui contrôle la valeur des paramètres sensibles. Cela s’appelle le Confused Deputy Problem[Har88]. La bonne solution est de tester dynamiquement la valeur du pointeur : s’il pointe en espace noyau, il faut indiquer une erreur plutôt que d’écrire. Sinon, il peut toujours y avoir une erreur, mais au moins le noyau est protégé. Dans le noyau, un ensemble de fonctions permet d’effectuer des copies sûres. La fonction access_ok réalise le test décrit précédemment. Les fonctions copy_from_user et copy_to_ user réalisent une copie de la mémoire après avoir fait ce test. Ainsi, l’implantation correcte de l’appel système gettimeofday fait appel à celle-ci (figure 2.4). SYSCALL_DEFINE2(gettimeofday, struct timeval __user *, tv, struct timezone __user *, tz) { if (likely(tv != NULL)) { struct timeval ktv; do_gettimeofday(&ktv); if (copy_to_user(tv, &ktv, sizeof(ktv))) return -EFAULT; } if (unlikely(tz != NULL)) { if (copy_to_user(tz, &sys_tz, sizeof(sys_tz))) return -EFAULT; } return 0; } FIGURE 2.4 : Implantation de l’appel système gettimeofday Pour préserver la sécurité du noyau, il est donc nécessaire de vérifier la valeur de tous les pointeurs dont la valeur est contrôlée par l’utilisateur. Cette conclusion est assez contraignante, puisqu’il existe de nombreux endroits dans le noyau où des données proviennent de l’utilisateur. Il est donc raisonnable de vouloir vérifier automatiquement et statiquement l’absence de tels défauts.C H A P I T R E 3 ANALYSES STATIQUES EXISTANTES Dans ce chapitre, nous présentons un tour d’horizon des techniques existantes permettant d’analyser des programmes. En particulier, on s’intéresse à la propriété d’isolation dé- crite dans le chapitre 2, mais on ne se limite pas à celle-ci : il est également intéressant de considérer des analyses développées pour d’autres propriétés (comme par exemple s’assurer de l’absence d’erreurs à l’exécution), celles-ci pouvant potentiellement s’adapter. L’analyse statique de programmes est un sujet de recherche actif depuis l’apparition de l’informatique en tant que science. On commence par en présenter une classification, puis on montrera des exemples pertinents permettant d’analyser du code système ou embarqué. 3.1 Taxonomie Techniques statiques et dynamiques L’analyse peut être faite au moment de la compilation ou au moment de l’exécution. En général on peut obtenir des informations plus précises de manière dynamique, mais cela ne prend en compte que les parties du programme qui seront vraiment exécutées. Un autre problème des techniques dynamiques est qu’il est souvent nécessaire d’instrumenter l’environnement d’exécution (ce qui — dans le cas où cela est possible — peut se traduire par un impact en performances). L’approche statique, en revanche, nécessite de construire à l’arrêt une carte mentale du programme, ce qui n’est pas toujours possible dans certains langages. Les techniques dynamiques sont néanmoins les plus répandues, puisqu’elles sont plus simples à mettre en œuvre et permettent de trouver des erreurs pendant le processus de dé- veloppement. De plus, on peut considérer qu’un programme avec une forte couverture par les tests a de grandes chances d’être correct pour toutes les entrées. Par exemple, dans l’avionique civile, le processus de développement demande d’être très rigoureux pour les tests fonctionnels et structurels afin de détecter le code ou les branchements non atteints. Mais pour s’assurer de la correction d’un programme, on ne peut pas s’appuyer uniquement sur les tests — ou de manière générale sur des analyses dynamiques — car il est souvent impossible d’étudier l’ensemble complet de tous les comportements possibles. Par exemple, si un bug se présente lors d’une interaction entre deux composants qui n’a pas été testée, il passera inaperçu durant la phase de tests unitaires. Pour cette raison, la plupart des analyses présentées ici sont statiques. Cohérence et complétude Le but d’une analyse statique est de catégoriser les programmes selon s’ils satisfont ou non un ensemble de propriétés fixées à l’avance. Malheureusement, 2122 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES cela n’est que rarement possible, car l’ensemble des valeurs possibles lors de l’exécution d’un programme quelconque n’est pas un ensemble calculable (théorème de Rice [Ric53]). Autrement dit, il ne peut exister une procédure de décision prenant un programme et le déclarant correct ou incorrect. Un résultat similaire est qu’on ne peut pas écrire une procédure qui dé- termine si un programme arbitraire boucle indéfiniment ou pas (le problème de l’arrêt). Il n’est donc pas possible d’écrire un analyseur statique parfait, détectant exactement les problèmes. Toute technique statique va donc de se retrouver dans au moins un des cas suivants : • un programme valide (pour une propriété donnée) est rejeté : on parle de faux positif. • un programme invalide n’est pas détecté : on parle de faux négatif. En général, et dans notre cas, on préfère s’assurer que les programmes acceptés possèdent la propriété recherchée, quitte à en rejeter certains. C’est l’approche que nous retiendrons. Tolérer les faux négatifs n’est cependant pas toujours une mauvaise idée. Par exemple, si le but est de trouver des constructions dangereuses dans les programmes, on peut signaler certains cas qui empiriquement valent d’être vérifiés manuellement. Par ailleurs la plupart des techniques ne concernent que les programmes qui terminent. On étudie donc la correction, ou les propriétés des termes convergents. Prouver automatiquement que l’exécution ne boucle pas est une propriété toute autre qui n’est pas ici considérée. 3.2 Méthodes syntaxiques L’analyse la plus simple consiste à traiter un programme comme du texte, et à y rechercher des motifs dangereux. Ainsi, utiliser des outils comme grep permet parfois de trouver un grand nombre de vulnérabilités [Spe05]. On peut continuer cette approche en recherchant des motifs mais en étant sensible à la syntaxe et au flot de contrôle du programme. Cette notion de semantic grep est présente dans l’outil Coccinelle [BDH+09, PTS+11] : on peut définir des patches sémantiques pour détecter ou modifier des constructions particulières. Ces techniques sont utiles parce qu’elles permettent de plonger rapidement dans le code, en identifiant par exemple des appels à des fonctions dangereuses. En revanche, cela n’est possible que lorsque les propriétés que l’on recherche sont plutôt locales. Elles offrent également peu de garantie puisqu’elles ne prennent pas en compte la sémantique d’exécution du langage : il faudra en général vérifier manuellement la sortie de ces analyses. 3.3 Analyse de valeurs et interprétation abstraite L’interprétation abstraite est une technique d’analyse générique qui permet de simuler statiquement tous les comportements d’un programme [CC77, CC92]. Un exemple d’application est de calculer les bornes de variation des variables pour s’assurer qu’aucun débordement de tableau n’est possible [AH07]. L’idée est d’associer à chaque ensemble concret de valeurs une représentation abstraite. Sur celle-ci, on peut définir des opérations indépendantes de la valeur exacte des données, mais préservant l’abstraction (figure 3.1). Par exemple, les règles comme « − » × « − » = « + » définissent le domaine abstrait des signes arithmétiques. Les domaines ont une structure de treillis, c’est-à-dire qu’ils possèdent les notions d’ordre partiel et d’union de valeurs. En calculant les extrêmes limites d’une variable, on obtient le domaine des intervalles.3.3. ANALYSE DE VALEURS ET INTERPRÉTATION ABSTRAITE 23 � − 0 + ⊥ γ (−) = R− γ (0) = {0} γ (+) = R+ FIGURE 3.1 : Domaine des signes De tels domaines ne capturent aucune relation entre variables. Ils sont dits non relationnels. Lorsque plusieurs variables sont analysées en même temps, utiliser de tels domaines consiste à considérer un produit cartésien d’ensembles abstraits (figure 3.2(a)). Des domaines abstraits plus précis permettent de retenir celles-ci. Pour ce faire, il faut modéliser l’ensemble des valeurs des variables comme un tout. Parmi les domaines relationnels courants on peut citer : le domaine des polyèdres [CH78], permettant de retenir tous les invariants affines entre variables (figure 3.2(b)) ; le domaine des zones [Min01a], permettant de représenter des relations affines de la forme vi − v j ≤ c (figure 3.2(c)) ; ou encore le domaine des octogones [Min01b] qui est un compromis entre les polyèdres et les zones. Il permet de représenter les relations ±vi ± v j ≤ c (figure 3.2(d)). (a) Domaine non relationnel (b) Domaine des polyèdres (c) Domaine des zones (d) Domaine des octogones FIGURE 3.2 : Quelques domaines abstraits En plus des domaines numériques, il est nécessaire d’employer des domaines spécialisés dans la modélisation de la mémoire. Cela est nécessaire pour pouvoir prendre en compte les pointeurs. Par exemple, on peut représenter un pointeur par un ensemble de variables possiblement pointées et une valeur abstraite représentant le décalage (offset) du pointeur par rapport au début de la zone mémoire. Cette valeur peut elle-même être abstraite par un domaine numérique. Au delà des domaines eux-mêmes, l’analyse se fait sous forme d’un calcul de point fixe.24 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES La manière la plus simple est d’utiliser un algorithme de liste de travail, décrit par exemple dans [SRH96]. Les raffinements en revanche sont nombreux. Dès [CC77] il est remarqué que la terminaison de l’analyse n’est assurée que si le treillis des valeurs abstraites est de hauteur finie, ou qu’un opérateur d’élargissement (widening) ∇ est employé. L’idée est qu’une fois qu’on a calculé quelques termes d’une suite croissante, on peut réaliser une projection de celle-ci. Par exemple, dans le domaine des intervalles, [0; 2] ∇ [0; 3] = [0;+∞[. On atteint alors un point fixe mais qui est plus grand que celui qu’on aurait obtenu sans cette accélération : on perd en précision. Pour en gagner, on peut redescendre sur le treillis des points fixes avec une suite d’itérations décroissantes [Gra92, GGTZ07]. En termes d’ingéniérie logicielle, implanter un analyseur statique est un défi en soi. En plus des domaines abstraits, d’un itérateur, il faut traduire le code source à analyser dans un langage intermédiaire, et traduire les résultats de l’analyse en un ensemble d’alarmes à présenter à l’utilisateur. Cette technique est très puissante : si un interprète abstrait sound (réalisant une surapproximation, c’est-à-dire ne manquant aucun programme incorrect) analyse un programme et ne renvoie pas d’erreur, alors on a prouvé que le programme est correct (par rapport aux propriétés que vérifient les domaines abstraits). Cela a été appliqué avec succès avec les analyseurs Astrée [Mau04, CCF+05, CCF+09] chez Airbus ou CGS [VB04] à la NASA par exemple. Cependant, ces analyses sont difficiles à mettre en œuvre. Avec des domaines abstraits classiques comme ceux présentés ci-dessus, les premières analyses peuvent remonter un nombre prohibitif de fausses alarmes. Pour « aider » l’analyse, il faut soit annoter le code soit développer des domaines abstraits ad hoc au programme à analyser. Il existe également des analyseurs statiques combinant l’interprétation abstraite avec d’autres techniques et qui ne sont pas sound, c’est-à-dire qu’ils peuvent manquer des comportements erronés. Leur approche est plus d’aider le programmeur à détecter certains types de bugs pendant le développement. On peut citer l’exemple de Coverity [BBC+10], qui publie régulièrement des rapports de qualité sur certains logiciels open-source. Néanmoins, de part leur aspect non sound, les analyses réalisées ne peuvent pas être assimilées à de la vérification formelle en tant que telle. Enfin, l’interprétation abstraite n’est pas la seule technique pour analyser finement les valeurs d’un programme. Par exemple, le système Saturn [ABD+07], conçu pour analyser du code système écrit en C, utilise des clauses logiques et un solveur SAT pour manipuler des invariants sur la mémoire. En particulier il traite le problème des pointeurs utilisateur en utilisant une analyse de forme « pointe-sur » [BA08]. Un autre exemple est le model checking [CE81], qui consiste à explorer l’ensemble des états que peut atteindre un système. Ce graphe est potentiellement infini ; donc il peut être impossible de l’explorer pour détecter les cas d’erreur. Plusieurs techniques permettent de résoudre ce problème. Le bounded model checking [BCC+03] explore uniquement les états atteints en moins de k étapes. Cela peut permettre de trouver des cas d’erreur, mais pas de montrer que le système est correct (seulement qu’il l’est pour les exécutions de moins de k étapes). Il est aussi possible de réduire le nombre d’états de l’automate [Pel93]. Comme l’interprétation abstraite, ces analyses sont très précises, au détriment d’un temps de calcul important à cause de l’explosion combinatoire. 3.4 Typage Le typage, introduit dans la section 1.3, peut aussi être utilisé pour la vérification de programmes. On peut le voir comme une manière de catégoriser les types de données manipulés par la machine, mais également, à plus haut niveau, comme une manière d’articuler les différents composants d’un programme. Mais on peut aussi programmer avec les types, c’est-3.4. TYPAGE 25 à-dire utiliser le compilateur (dans le cas statique) ou l’environnement d’exécution (dans le cas dynamique) pour vérifier des propriétés écrites par le programmeur. Systèmes ad hoc Les systèmes de types les plus simples expriment des contrats esssentiellement liés à la sûreté d’exécution, pour ne pas utiliser des valeurs de types incompatibles entre eux. Mais il est possible d’étendre le langage avec des annotations plus riches, par exemple en vérifiant statiquement que des listes ne sont pas vides [KcS07] ou, dans le domaine de la sécurité, d’empêcher des fuites d’information [LZ06]. Qualificateurs de types Dans le cas particulier des vulnérabilités liées à une mauvaise utilisation de la mémoire, les développeurs du noyau Linux ont ajouté un système d’annotations au code source. Un pointeur peut être décoré d’une annotation __kernel ou __user selon s’il est sûr ou pas. Celles-ci sont ignorées par le compilateur, mais un outil d’analyse statique ad-hoc nommé Sparse [☞6] peut être utilisé pour détecter les cas les plus simples d’erreurs. Il demande aussi au programmeur d’ajouter de nombreuses annotations dans le programme. Cette solution se rapproche de la solution décrite dans ce manuscrit. Ce système d’annotations sur les types a été formalisé sous le nom de qualificateurs de types [FJKA06] : chaque type peut être décoré d’un ensemble de qualificateurs (à la manière de const), et des règles de typage permettent d’établir des propriétés sur le programme. Plus précisément, les jugements de typage de la forme Γ � e : t sont remplacés par des jugements de typage qualifiés Γ � e : t q. Les qualificateurs q permettent d’exprimer plusieurs jugements. Par exemple, on peut étudier le fait qu’une variable soit constante ou pas, que sa valeur soit connue à la compilation, ou encore qu’elle puisse être nulle ou pas. La spé- cificité de ce système est que les qualificateurs sont ordonnés, du plus spécifique au moins spécifique, et que l’on forme alors un treillis à partir de ces informations. Partant des deux caractéristiques précédentes, on forme le treillis de la figure 3.3. Le qualificateur const dé- signe les données dont la valeur ne change pas au cours de l’exécution ; dynamic celles qui ne peuvent pas être connues à la compilation ; et nonzero celles qui ne peuvent jamais être nulles. Le cube sur lequel se trouvent les qualificateurs correspond à une relation d’ordre, du plus spécifique (en bas) au plus général (en haut). ø correspond à un ensemble vide de qualificateurs. dynamic ø const dynamic dynamic nonzero const nonzero const dynamic nonzero const nonzero FIGURE 3.3 : Treillis de qualificateurs Cette relation d’ordre � entre qualificateurs induit une relation de sous-typage � entre les types qualifiés : si q � q� , alors t q � t q� . Ces analyses ont été implantées dans l’outil CQual. Ce système peut servir à inférer les annotations const [FFA99], à l’analyse de souillure pour les chaînes de format [STFW01] (pouvant poser des problèmes de sécurité [New00]) et à déterminer des propriétés dépendantes du flot de contrôle, comme des invariants sur les verrous [FTA02], à rapprocher du concept26 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES de typestates [SY86]. Il a également été appliqué à la classe de vulnérabilités sur les pointeurs utilisateur dont il est question ici [JW04]. Cette approche est assez proche de la nôtre : on donne un type différent aux pointeurs selon leur provenance. Néanmoins cela est très différent. Une première différence est dans le langage considéré. CQual s’applique sur un lambda-calcul à références, alors que, pour étudier du code C, nous présentons un modèle mémoire avec pile explicite plus proche de la machine. D’autre part, le système de types de CQual est fondamentalement modifié pour prendre en compte ces opérations, alors que dans le nôtre il s’agit d’une simple extension qui ne nécessite pas de modifier toutes les règles de typage. La conclusion de la partie II, page 95, sera dédiée à une comparaison entre ces solutions. Le système Flow Caml [Sim03] repose également sur cette approche, en ajoutant une étiquette de sécurité à chaque type. Par exemple, les entiers sont typés ’a int où ’a est le niveau de sécurité associé. Couplé à un système d’effets, cela permet de suivre la provenance de chaque expression. Cette technique d’analyse de flot permet d’encoder de nombreuses propriétés de sécurité [SM03]. Ces techniques de typage sont séduisantes parce qu’elles sont en général simples à mettre en place : à l’aide d’un ensemble de règles, on attribue un type à chaque expression. Si le typage se termine sans erreur, alors on est assuré de la correction du programme (par rapport aux propriétés capturées par le système de types). Le typage statique peut également être implanté de manière efficace. Même si l’inférence peut, dans certains cas, atteindre une complexité exponentielle [Mai90] (voire être indécidable), la plupart des systèmes de types peuvent être vérifiés en pratique dans un temps linéaire en la taille du programme considéré [McA03]. 3.5 Langages sûrs Une autre approche est de concevoir un langage à la fois bas niveau et sûr, permettant d’exprimer des programmes proches de la machine tout en interdisant les constructions dangereuses. Le langage Cyclone [JMG+02] est conçu comme un C « sûr ». Afin d’apporter plus de sûreté au modèle mémoire de C, des tests dynamiques sont ajoutés, par exemple aux endroits où des conversions implicites peuvent poser problème. Le langage se distingue par le fait qu’il possède plusieurs types de pointeurs : des pointeurs classiques (int *), des pointeurs « jamais nuls » (int @ ; un test à l’exécution est alors inséré) et des « pointeurs lourds » (int ? ; qui contiennent des informations sur la zone mémoire pointée). L’arithmétique des pointeurs n’est autorisée que sur ces derniers, rendant impossibles les débordements de tableaux (ceux-ci étant détectés au pire à l’exécution). Le problème des pointeurs fous 1 est résolu en utilisant un système de régions [GMJ+02], inspiré des travaux de Jouvelot, Talpin et Tofte [TJ92, TT94]. Cela permet d’interdire statiquement les constructions où l’on déréfé- rence un pointeur faisant référence à une région de mémoire qui n’est plus allouée (par exemple en évitant de retourner l’adresse d’une variable locale). Cette approche peut également servir à suivre les provenances de données sensibles [BGH10]. Le langage Rust [☞5] développé par Mozilla prend une approche similaire en distinguant plusieurs types de pointeurs pour gérer la mémoire de manière plus fine. Les managed poin- 1. Les pointeurs fous, encore appelés pointeurs fantômes ou dangling pointers, correspondent à une zone mémoire invalide ou expirée. Il y a deux sources principales de pointeurs fous : les variables de type pointeur non initialisées, et les pointeurs vers des objets dont la mémoire a été libérée. C’est par exemple ce qui arrive aux adresses de variables locales une fois que la fonction dans laquelle elles ont été définies retourne.3.6. LOGIQUE DE HOARE 27 ters (notés @int) utilisent un ramasse-miettes pour libérer la mémoire allouée lorsqu’ils ne sont plus accessibles. Les owning pointers (notés ~int) décrivent une relation 1 à 1 entre deux objets, comme les std::unique_ptr de C++ : la mémoire est libérée lorsque le pointeur l’est. Les borrowed pointers (notés &int) correspondent aux pointeurs obtenus en prenant l’adresse d’un objet, ou d’un champ d’un objet. Une analyse statique faite lors de la compilation s’assure que la durée de vie de ces pointeurs est plus courte que l’objet pointé, afin d’éviter les pointeurs fous. Cette analyse est également fondée sur les régions. Une fonction qui retourne l’adresse d’une variable locale sera donc rejetée par le compilateur. Enfin, le dernier type est celui des raw pointers (notés *int), pour lesquels le langage n’apporte aucune garantie (il faut d’ailleurs encapsuler chaque utilisation dans un bloc marqué explicitement unsafe). Ils sont équivalents aux pointeurs de C. Les systèmes de types de ces projets apportent dans le langage différents types de pointeurs. Cela permet de manipuler finement la mémoire, à la manière des smart pointers de C++. Ceux-ci sont des types de données abstraits permettant de déterminer quelle partie du code est responsable de la libération de la mémoire associée au pointeur. De cette approche on retient surtout l’analyse de régions de Rust qui permet de manipuler de manière sûre les adresses des variables locales, et les pointeurs lourds de Cyclone, qui apportent une sûreté à l’arithmétique de pointeurs, au prix d’un test dynamique. Ces techniques sont utiles pour créer des nouveaux programmes sûrs, mais on ne peut pas les appliquer pour étudier la correction de logiciels existants. Dans cette perspective, le langage CCured [NCH+05] a pour but d’ajouter un système de types forts à C (y compris pour des programmes existants). Dans les cas où il n’est pas possible de prouver que le programme s’exécutera correctement, des vérifications à l’exécution sont ajoutées. Cependant, cela né- cessite une instrumentation dynamique qui se paye en performances et interdit la certification, car l’environnement d’exécution doit être inchangé. Le compilateur Fail-Safe C [Oiw09] utilise une approche similaire permettant de garantir la sûreté d’exécution des programmes C tout en respectant la totalité de la norme C89. 3.6 Logique de Hoare Une technique pour vérifier statiquement des propriétés sur la sémantique d’un programme a été formalisée par Robert Floyd [Flo67] et Tony Hoare [Hoa69]. Elle consiste à écrire les invariants qui sont maintenus à un point donné du programme. Ces propositions sont écrites dans une logique L . Chaque instruction i est annotée d’une pré-condition P et d’une post-condition Q, ce que l’on note {P} i {Q}. Cela signifie que, si P est vérifiée et que l’exécution de i se termine, alors Q sera vérifiée. En plus des règles de L , des règles d’inférence traduisent la sémantique du programme ; par exemple la règle de composition est : {P} i1 {Q} {Q} i2 {R} {P} i1;i2 {R} (HOARE-SEQ) Les pré-conditions peuvent être renforcées et les post-conditions relâchées : �L P� ⇒ P {P} i {Q} �L Q ⇒Q� {P� } i {Q� } (HOARE-CONSEQUENCE)28 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES Il est alors possible d’annoter le programme avec ses invariants formalisés de manière explicite dans L . Ceux-ci seront vérifiés à la compilation lorsque c’est possible, sinon à l’exé- cution. La règle de conséquence permet de séparer les propriétés du programme lui-même : plusieurs niveaux d’annotations sont possibles, du moins précis au plus précis. En fait, il est même possible d’annoter chaque point de contrôle par l’ensemble d’annotations vide : {T } i {T } est toujours vrai. Augmenter graduellement les pré- et post-conditions est néanmoins assez difficile, puisqu’il peut être nécessaire de modifier l’ensemble des conditions à la fois. Cette difficulté est mentionnée dans [DRS03], où un système de programmation par contrats est utilisé pour vérifier la correction de routines de manipulation de chaînes en C. Ce type d’annotations a été implanté par exemple pour le langage Java dans le système JML [LBR06] ou pour le langage C# dans Spec# [BLS05]. Il est aussi possible d’utiliser cette technique pour annoter du code assembleur de bas niveau [MG07]. 3.7 Assistants de preuve Avec un système de types classique, le fait qu’un terme (au sens « expression » ou « instruction ») soit bien typé amène quelques propriétés sur son exécution, par exemple, le fait que seulement un ensemble réduit d’erreurs puisse arriver (comme la division par zéro). En enrichissant le langage des types, on peut augmenter l’expressivité du typage. Par exemple, on peut former des types « entier pair », « vecteur de n entiers », ou encore « liste triée d’entiers ». Habituellement, les termes peuvent dépendre d’autres termes (par composition) ou de types (par des annotations). Les types peuvent également dépendre d’autres types (par composition de types : par exemple, un couple de a et de b a pour type a ∗b). Enrichir l’expressivité du typage revient essentiellement à introduire des termes dans les types, comme n dans l’exemple précédent du vecteur de n entiers. C’est pourquoi on parle de types dépendants. Parmi les langages proposant ces types on peut citer Coq [The04], Agda [BDN09] ou Isabelle [NPW02]. Dans un langage classique, la plupart des types sont habités, c’est-à-dire qu’il existe des termes ayant ces types. En revanche, avec les types dépendants ce n’est pas toujours vrai : par exemple « vecteur de −1 entiers » n’a pas d’habitants. Ainsi, pouvoir construire un terme d’un type donné est une information en soi. On peut voir ce phénomène sous un autre angle : les termes sont à leur type ce que les preuves sont à leur théorème. Exhiber un terme ayant un type revient à donner la preuve d’un théorème. À l’aide de cette correspondance, il est possible de voir un algorithme de vérification de typage comme un algorithme de vérification de preuve automatique. Ces preuves ne portent pas forcément sur des programmes. Par exemple, le théorème des 4 couleurs a été prouvé en Coq [Gon07]. Cette technique est très complexe à mettre en œuvre, puisqu’il faut encoder toutes les propriétés voulues dans un formalisme de très bas niveau (du niveau de la théorie des ensembles). De plus, l’inférence de types devient rapidement indécidable. Conclusion Il existe de nombreuses techniques pour vérifier du code système ou embarqué. Il y a divers choix à faire entre l’expressivité, l’intégration de tests dynamiques ou la facilité de mise3.7. ASSISTANTS DE PREUVE 29 en œuvre. Pour résoudre le problème des pointeurs utilisateur dans les noyaux, le typage statique est une solution performante et assez pragmatique, puisqu’elle peut s’appliquer à des programmes existants. Son expressivité limitée nous empêche de reposer entièrement sur elle pour garantir l’absence d’erreur dans les programmes systèmes (par exemple, le typage est mal adapté pour détecter les divisions par zéro). C’est pourquoi nous approchons la sûreté de la manière suivante : • Tout d’abord, on utilise le typage pour manipuler les données de manière compatible : les types des opérations et fonctions sont vérifiés à la compilation. • Ensuite, les accès aux tableaux et aux pointeurs sont vérifiés dynamiquement. Dans le cas où une erreur est déclenchée, l’exécution s’arrête plutôt que de corrompre la mémoire. La pile est également nettoyée à chaque retour de fonction afin d’éviter les pointeurs fous. • Enfin, les pointeurs provenant de l’espace utilisateur sont repérés statiquement afin que leur déréférencement se fasse au sein de fonctions sûres. Cela permet de préserver l’isolation entre le noyau et l’espace utilisateur.CONCLUSION DE LA PARTIE I Nous avons montré que l’écriture de noyaux de systèmes d’exploitation nécessite de manipuler des données provenant d’une zone non sûre, l’espace utilisateur. Parmi ces données, il arrive de récupérer des pointeurs qui servent à passer des données par référence à l’appelant, dans certains appels système. Si on déréférence ces pointeurs sans vérifier qu’ils pointent bien vers une zone mémoire également contrôlée par l’appelant, on risque de lire ou d’écrire dans des zones mémoires réservées au noyau seul. Nous proposons une technique de typage pour détecter ces cas dangereux. Elle est plus adaptée qu’une analyse de valeurs, car le grain pour distinguer les pointeurs sensibles des pointeurs sûrs n’a pas besoin d’être très fin. Pour décrire ces analyses, on commence par définir un langage impératif bien typable que nous appellerons SAFESPEAK. Celui-ci s’inspire du langage NEWSPEAK, qui est un langage intermédiaire développé par EADS dans le but de vérifier la sûreté de programmes C embarqués. À ce titre, il existe un compilateur qui est capable de traduire du code C vers NEWSPEAK. Définir la syntaxe et la sémantique de SAFESPEAK permet d’écrire et d’évaluer des programmes. Mais cela reste trop permissif, car on ne rejette pas les programmes qui manipulent les données de manière incohérente. On définit donc un système de types pour classifier les expressions et fonctions selon la classe de valeurs que leur évaluation produit. Une fois SAFESPEAK défini et étendu d’un système de types, nous lui ajoutons des constructions permettant d’écrire du code noyau, et en particulier on lui ajoute des pointeurs utilisateur. Il s’agit de pointeurs dont la valeur est contrôlée par un utilisateur interagissant via un appel système. Ces pointeurs ont un type distinct des pointeurs habituels. En résumé, le but de cette thèse est de définir un langage intermédiaire proche de C, mais bien typé ; puis de définir une analyse de typage qui vérifie que les pointeurs utilisateur sont manipulés sans causer de problèmes de sécurité. 31Deuxième partie Un langage pour l’analyse de code système : SAFESPEAK Dans cette partie, nous allons présenter un langage impératif modélisant une sous-classe « bien typable » du langage C. Le chapitre 4 décrit sa syntaxe, ainsi que sa sémantique d’exécution. À ce point, de nombreux programmes acceptés peuvent provoquer des erreurs à l’exécution. Afin de rejeter ces programmes incorrects, on définit ensuite dans le chapitre 5 une sémantique statique s’appuyant sur un système de types simples. Des proprié- tés de sûreté de typage sont ensuite établies, permettant de catégoriser l’ensemble des erreurs à l’exécution possibles. Le chapitre 6 commence par étendre notre langage avec une nouvelle classe d’erreurs à l’exécution, modélisant les accès à la mémoire utilisateur catégorisés comme dangereux dans le chapitre 2. Une extension au système de types du chapitre 5 est ensuite établie, et on prouve que les programmes ainsi typés ne peuvent pas atteindre ces cas d’erreur. Trois types d’erreurs à l’exécution sont possibles : • les erreurs liées aux valeurs : lorsqu’on tente d’appliquer à une opération des valeurs incompatibles (additionner un entier et une fonction par exemple). L’accès à des variables qui n’existent pas rentre aussi dans cette catégorie. • les erreurs mémoire, qui résultent d’un débordement de tableau, du déréfé- rencement d’un pointeur invalide ou d’arithmétique de pointeur invalide. • les erreurs de sécurité, qui consistent en le déréférencement d’un pointeur dont la valeur est contrôlée par l’espace utilisateur. Celles-ci sont uniquement possibles en contexte noyau. L’introduction des types simples enlève la possibilité de rencontrer le premier cas. Il reste en revanche toujours possible de rencontrer des erreurs mémoire ainsi que des divisions par zéro. Éliminer ces erreurs dépasse le cadre de ce travail. En présence d’extensions permettant de manipuler des pointeurs utilisateur, une extension naïve du système de types ne suffit pas à empêcher la présence d’erreurs de sécurité. Celles-ci sont évitées par l’ajout de règles de typage supplémentaires. 33C H A P I T R E 4 SYNTAXE ET SÉMANTIQUE D’ÉVALUATION Dans ce chapitre, on décrit le support de notre travail : un langage impératif nommé SAFESPEAK, sur lequel s’appuieront les analyses de typage des chapitres 5 et 6. Le langage C [KR88] est un langage impératif, conçu pour être un « assembleur portable ». Ses types de données et les opérations associées sont donc naturellement de très bas niveau. Ses types de données sont établis pour représenter les mots mémoire manipulables par les processeurs : essentiellement des entiers et flottants de plusieurs tailles. Les types composés correspondent à des zones de mémoire contigües, homogènes (dans le cas des tableaux) ou hétérogènes (dans le cas des structures). Une des spécificités de C est qu’il expose au programmeur la notion de pointeur, c’est- à-dire de variables qui représentent directement une adresse en mémoire. Les pointeurs peuvent être typés (on garde une indication sur le type de l’objet stocké à cette adresse) ou « non typés ». Dans ce dernier cas, ils ont en fait le type void *, qui est compatible avec n’importe quel type pointeur. Son système de types rudimentaire ne permet pas d’avoir beaucoup de garanties sur la sûreté du programme. En effet, aucune vérification n’est effectuée en dehors de celles faites par le programmeur. Le but ici est de définir SAFESPEAK, un langage plus simple mais qui permettra de raisonner sur une certaine classe de programmes C. Tout d’abord, on commence par présenter les notations qui accompagneront le reste des chapitres. Cela inclut la notion de lentille, qui est utilisée pour définir les accès profonds à la mémoire. Cela permet de résoudre le problème de mettre à jour une sous-valeur (par exemple un champ de structure) d’une variable. Les lentilles permettent de définir de manière déclarative que, pour faire cette opération, il faut obtenir l’ancienne valeur de la variable, puis calculer une nouvelle valeur en remplaçant une sous-valeur, avant de replacer cette nouvelle valeur à sa place en mémoire. En pratique, on définira deux lentilles : une qui relie un état mémoire à la valeur d’une variable, et une qui relie une valeur à une de ses sousvaleurs. Avec cette technique, on peut définir en une seule fois les opérations de lecture et d’écriture de sous-valeurs imbriquées. Ensuite, on présente SAFESPEAK en soi, c’est-à-dire sa syntaxe, ainsi que ses caractéristiques principales. En particulier, le modèle mémoire est détaillé, ainsi que les valeurs manipulées par le langage. Enfin, on décrit une sémantique opérationnelle pour ce langage. Cela permet de définir précisément l’exécution d’un programme SAFESPEAK au niveau de la mémoire. L’implantation de ces analyses est faite dans le chapitre 7. Puisque SAFESPEAK n’est qu’un modèle, il s’agira d’adapter ces règles de typage sur NEWSPEAK, qui possède un modèle mé- 3536 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION moire plus bas niveau. 4.1 Notations Inférence La sémantique opérationnelle consiste en la définition d’une relation de transition · → · entre états de l’interprète 1. Cette relation est définie inductivement sur la syntaxe du programme. Plutôt que de pré- senter l’induction explicitement, elle est représentée par des jugements logiques et des règles d’inférence, de la forme : P1 ... Pn C (NOM) Les Pi sont les prémisses, et C la conclusion. Cette règle s’interprète de la manière suivante : si les Pi sont vraies, alors C est vraie. Certaines règles n’ont pas de prémisse ; ce sont des axiomes : A (AX) Compte-tenu de la structure des règles, la dérivation d’une preuve (l’ordre dans lequel les règles sont appliquées) pourra donc être vue sous la forme d’un arbre où les axiomes sont les feuilles, en haut, et la conclusion est la racine, en bas. A1 (R3) A2 (R4) B1 (R2) A3 (R6) B2 (R5) C (R1) Listes X ∗ est l’ensemble des suites finies de X, indexées à partir de 1. Si u ∈ X ∗, on note |u| le nombre d’éléments de u (le cardinal de son domaine de définition). Pour i ∈ [1;|u|], on note ui = u(i) le i-ème élément de la suite. On peut aussi voir les suites comme des listes : on note [ ] la suite vide, telle que |[ ]| = 0. On définit en outre la construction de suite de la manière suivante : si x ∈ X et u ∈ X ∗, la liste x :: u ∈ X ∗ est la liste v telle que : v1 = x ∀i ∈ [1;|u|], vi+1 = ui Cela signifie que la tête de liste (x dans la liste x :: u) est toujours accessible à l’indice 1. 1. Dans le chapitre 5, la relation de typage · � · : · sera définie par la même technique.4.1. NOTATIONS 37 Lentilles Dans la définition de la sémantique de SAFESPEAK, on utilise des lentilles bidirectionnelles. Cette notion n’est pas propre à la sémantique des programmes. Il s’agit d’une technique permettant de relier la modification d’un objet à la modification d’un de ses souscomposants. Cela a plusieurs applications possibles. En programmation fonctionnelle pure (sans mutation), on ne peut pas mettre à jour partiellement les valeurs composées comme des enregistrements (records). Pour simuler cette opération, on a en général une opération qui permet de définir un nouvel enregistrement dans lequel seul un champ a été mis à jour. C’est ce qui se passe avec le langage Haskell [OGS08] : r { x = 5 } représente une valeur enregistrement égale à r sur tous les champs, sauf pour le champ x où elle vaut 5. Utiliser des lentilles revient à ajouter dans le langage la notion de champ en tant que valeur de première classe. Elles ont l’avantage de pouvoir se composer, c’est-à-dire que, si on a un champ nommé x qui contient un champ nommé y, alors on peut modifier le champ du champ automatiquement. Dans ce cadre, les lentilles ont été popularisées par Van Laarhoven [vL11]. Puisque cela sert à manipuler des données arborescentes, on peut aussi appliquer cet outil aux systèmes de bases de données ou aux documents structurés comme par exemple en XML [FGM+07]. Dans notre cas, cela permettra par exemple de modifier un élément d’un tableau qui est un champ de structure de la variable nommée x dans le 3e cadre de pile. Définition 4.1 (Lentille). Étant donnés deux ensembles R et A, une lentille L ∈ LENSR,A (ou accesseur) est un moyen d’accéder en lecture ou en écriture à une sous-valeur appartenant à A au sein d’une valeur appartenant à R (pour record). Elle est constituée des opérations suivantes : • une fonction de lecture getL : R → A • une fonction de mise à jour putL : (A ×R) → R telles que pour tour a ∈ A,a� ∈ A, r ∈ R : putL (getL (r ), r ) = r (GETPUT) getL (putL (a, r )) = a (PUTGET) putL (a� ,putL (a, r )) = putL (a� , r ) (PUTPUT) On note L = 〈getL |putL 〉. GETPUT signifie que, si on lit une valeur puis qu’on la réécrit, l’objet n’est pas modifié ; PUTGET décrit l’opération inverse : si on écrit une valeur dans le champ, c’est la valeur qui sera lue ; enfin, PUTPUT évoque le fait que chaque écriture est totale : quand deux écritures se suivent, seule la seconde compte. Une illustration se trouve dans la figure 4.1. Exemple 4.1 (Lentilles de tête et de queue de liste). Soit E un ensemble. On rappelle que E ∗ désigne l’ensemble des listes d’éléments de E. On définit les fonctions suivantes. Notons qu’elles ne sont pas définies sur la liste vide [ ], qui pourra être traitée comme un cas d’erreur. getT (t :: q) = t putT (t � ,t :: q) = t� :: q getQ(t :: q) = q putQ(q� ,t :: q) = t :: q�38 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION getL ( ) = putL ( , ) = FIGURE 4.1 : Fonctionnement d’une lentille Alors T = 〈getT |putT 〉 ∈ LENSE∗,E et Q = 〈getQ|putQ〉 ∈ LENSE∗,E∗ . On a par exemple : getT (1 :: 6 :: 1 :: 8 :: [ ]) = 1 putQ(4 :: 2 :: [ ], 3 :: 6 :: 1 :: 5 :: [ ]) = 3 :: 4 :: 2 :: [ ] Définition 4.2 (Lentille indexée). Les objets de certains ensembles R sont composés de plusieurs sous-objets accessibles à travers un indice i ∈ I. Une lentille indexée est une fonction Δ qui associe à un indice i une lentille entre R et un de ses champs Ai : ∀i ∈ I,∃Ai ,Δ(i) ∈ LENSR,Ai On note alors : r [i]Δ def == getΔ(i)(r ) r [i ← a]Δ def == putΔ(i)(a, r ) Un exemple est illustré dans la figure 4.2. getΔ(b)( a b c d ) = getΔ(c)( a b c d ) = putΔ(b)( , a b c d ) = a b c d putΔ(c)( , a b c d ) = a b c d FIGURE 4.2 : Fonctionnement d’une lentille indexée4.1. NOTATIONS 39 Exemple 4.2 (Lentille « ne élément d’un tuple »). Soient n ∈ N, et n ensembles E1,...,En. Pour tout i ∈ [1;n], on définit : gi((x1,...,xn)) = xi pi(y, (x1,...,xn)) = (x1,...,xi−1, y,xi+1,...,xn) Définissons T (i) = 〈gi |pi〉. Alors T (i) ∈ LENS(E1×...×En),Ei . Donc T est une lentille indexée, et on a par exemple : (3, 1, 4, 1, 5)[2]T = getT (2)((3, 1, 4, 1, 5)) = 1 (9, 2, 6, 5, 3)[3 ← 1]T = putT (3)(1, (9, 2, 6, 5, 3)) = (9, 2, 1, 5, 3) La notation 3 ← 1 peut surprendre, mais elle est à interpréter comme « en remplaçant l’élément d’indice 3 par 1 ». Définition 4.3 (Composition de lentilles). Soient L1 ∈ LENSA,B et L2 ∈ LENSB,C . La composition de L1 et L2 est la lentille L ∈ LENSA,C définie de la manière suivante : getL (r ) = getL2 (getL1 r ) putL (a, r ) = putL1 (putL2 (a, getL1 r ), r ) On notera alors L = L1≫L2 (« L1 flèche L2 »). getL1 putL2 putL1 getL1 getL2 FIGURE 4.3 : Composition de lentilles Cette définition est illustrée dans la figure 4.3. Une preuve que la composition est une lentille est donnée en annexe D.1.40 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION Constantes c ::= n Entier | d Flottant | NULL Pointeur nul | ( ) Valeur unité Expressions e ::= c Constante | � e Opération unaire | e � e Opération binaire | l v Accès mémoire | l v ← e Affectation | &l v Pointeur | f Fonction | e(e1,...,en) Appel de fonction | {l1 : e1;...;ln : en} Structure | [e1;...;en] Tableau Valeurs gauches l v ::= x Variable | l v.lS Accès à un champ | l v[e] Accès à un élément | ∗e Déréférencement Fonctions f ::= fun(x1,...,xn){i} Arguments, corps FIGURE 4.4 : Syntaxe des expressions 4.2 Syntaxe Les figures 4.4 et 4.5 présentent notre langage intermédiaire. Il contient la plupart des fonctionnalités présentes dans les langages impératifs comme C. Parmi les expressions, les constantes comportent les entiers et flottants, ainsi que le pointeur NULL qui correspond à une valeur par défaut pour les pointeurs, et la valeur unité ( ) qui pourra être retournée par les fonctions travaillant par effets de bord uniquement. Les accès mémoire en lecture et écriture se font au travers de valeurs gauches (left values ou lvalues) : comme en C, elles tiennent leur nom du fait que ce sont ces constructions qui sont à gauche du signe d’affectation. En plus des variables, on obtient une valeur gauche en accédant par nom à un champ ou par indice à un élément d’une valeur gauche, ou encore en appliquant l’opérateur * de déréférencement à une expression. Pour assister le typage, l’accès à un champ doit être décoré du type complet S, mais cette annotation est ignorée lors de l’évaluation. Les valeurs gauches correspondent aussi à l’unité d’adressage : c’est-à-dire que les pointeurs sont construits en prenant l’adresse d’une valeur gauche avec l’opérateur &. Les fonctions sont des expressions comme les autres, contrairement à C où elles sont forcément déclarées globalement. Cela veut dire qu’on peut affecter une fonction f à une va-4.3. MÉMOIRE ET VALEURS 41 Instructions i ::= PASS Instruction vide | i;i Séquence | e Expression | DECL x = e IN{i} Déclaration de variable | IF(e){i}ELSE{i} Alternative | WHILE(e){i} Boucle | RETURN(e) Retour de fonction Phrases p ::= x = e Variable globale | e Évaluation d’expression Programme P ::= (p1,...,pn) Phrases FIGURE 4.5 : Syntaxe des instructions riable x et l’appeller avec x(a1,a2). Il est aussi possible de déclarer une fonction au sein d’une fonction. Cependant cela ne respecte pas l’imbrication lexicale : dans la fonction interne il n’est pas possible de faire référence à des variables locales de la fonction externe, seulement à des variables globales. En mémoire les fonctions sont donc uniquement représentées par leur code : il n’y a pas de fermetures. Enfin, on trouve aussi des expressions permettant de construire des valeurs composées : les structures et les tableaux. Les instructions sont typiques de la programmation impérative. SAFESPEAK comporte bien sûr l’instruction vide qui ne fait rien et la séquence qui chaîne deux instructions. Une expression peut être évaluée dans un contexte d’instruction, pour ses effets de bord. Remarquons que l’affectation est une expression, qui renvoie la valeur affectée. Cela permet d’écrire x ← (y ← z), comme dans un programme C où on écrirait x = y = z. Il est également possible de déclarer une variable locale avec DECL x = v IN{i}. x est alors une nouvelle variable visible dans i avec pour valeur initiale v. L’alternative et la conditionnelle sont classiques ; en revanche, on ne fournit qu’un seul type de boucle et pas de saut (instruction goto). Les opérateurs sont donnés dans la figure 4.6. Ils correspondent à ceux du langage C. La différence principale est que les opérations sur les entiers, flottants et pointeurs sont annotées avec le type de données sur lequel ils travaillent. Par exemple « + » désigne l’addition sur les entiers et « +. » l’addition sur les flottants. Les opérations de test d’égalité, en revanche, sont possibles pour les types numériques, les pointeurs, ainsi que les types composés de types comparables. 4.3 Mémoire et valeurs L’interprète que nous nous apprêtons à définir manipule des valeurs qui sont associées aux variables du programme.42 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION Opérateurs binaires � ::= +,−,×,/,% Arithmétique entière | +.,−.,×.,/. Arithmétique flottante | +p,−p Arithmétique de pointeurs | ≤,≥,<,> Comparaison sur les entiers | ≤ .,≥ .,< .,> . Comparaison sur les flottants | =,�= Tests d’égalité | &,|,^ Opérateurs bit à bit | &&,|| Opérateurs logiques | �,� Décalages Opérateurs unaires � ::= +,− Arithmétique entière | +.,−. Arithmétique flottante | ∼ Négation bit à bit | ! Négation logique FIGURE 4.6 : Syntaxe des opérateurs La mémoire est constituée de variables (toutes mutables), qui contiennent des valeurs. Ces variables sont organisées, d’une part, en un ensemble de variables globales et, d’autre part, en une pile de contextes d’appel (qu’on appellera donc aussi cadres de pile, ou stack frames en anglais). Cette structure empilée permet de représenter les différents contextes à chaque appel de fonction : par exemple, si une fonction s’appelle récursivement, plusieurs instances de ses variables locales sont présentes dans le programme. Le modèle mémoire présenté ici ne permet pas l’allocation dynamique sur un tas. Cette limitation sera détaillée dans le chapitre 9. La structure de pile des variables locales permet de les organiser en niveaux indépendants : à chaque appel de fonction, un nouveau cadre de pile est créé, comprenant ses paramètres et ses variables locales. Au contraire, pour les variables globales, il n’y a pas de système d’empilement, puisque ces variables sont accessibles depuis tout point du programme. Pour identifier de manière non ambigüe une variable, on note simplement x la variable globale nommée x, et (n,x) la variable locale nommée x dans le ne cadre de pile 2. Les affectations peuvent avoir la forme x ← e où x est une variable et e est une expression, mais pas seulement. En effet, à gauche de ← on trouve en général non pas une variable mais une valeur gauche (par définition). Pour représenter quelle partie de la mémoire doit être accédée par cette valeur gauche, on introduit la notion de chemin ϕ. Un chemin est une valeur gauche évaluée : les cas sont similaires, sauf que tous les indices sont évalués. Par exemple, ϕ = (5,x).p représente le champ « p » de la variable x dans le 5e cadre de pile. C’est à ce moment qu’on évalue les déréférencements qui peuvent apparaître dans une valeur gauche. Les valeurs, quant à elles, peuvent avoir les formes suivantes (résumées sur la figure 4.7) : • c� : une constante. La notation circonflexe permet de distinguer les constructions syn- 2. Les paramètres de fonction sont traités comme des variables locales et se retrouvent dans le cadre correspondant.4.4. INTERPRÈTE 43 taxique des constructions sémantiques. Par exemple, à la syntaxe 3 correspond la valeur �3. Les valeurs entières sont les entiers signés sur 32 bits, c’est-à-dire entre −231 à 231 − 1. Mais ce choix est arbitraire : on aurait pu choisir des nombres à 64 bits, par exemple. Les flottants sont les flottants IEEE 754 de 32 bits [oEE08]. Il n’y a pas de distinction entre procédures et fonctions ; toutes les fonctions doivent renvoyer une valeur. Celles qui ne retournent pas de valeur « intéressante » renvoient alors une valeur d’un type à un seul élément noté ( ), et donc le type sera noté UNIT. Cette notation évoque un n-uplet à 0 composante. • &� ϕ : une référence mémoire. Ce chemin correspond à un pointeur sur une valeur gauche. Par exemple, l’expression &x s’évalue en &� ϕ = & (5, � x) si x désigne lexicalement une variable dans le 5e cadre de pile. • [v�1;...; vn] : un tableau. C’est une valeur composée qui contient un certain nombre (connu à la compilation) de valeurs d’un même type, par exemple 100 entiers. On accède à ces valeurs par un indice entier. C’est une erreur (Ωar r ay ) d’accéder à un tableau en dehors de ses bornes, c’est-à-dire en dehors de [0;n − 1] pour un tableau à n élé- ments. Pareillement, [ �·] permet de désigner les valeurs tableau. Par exemple, si x vaut 2 et y vaut 3, l’expression [x; y] s’évaluera en la valeur [2; 3] � • {l1 : v�1;...;ln : vn} : une structure. C’est une valeur composée mais hétérogène. Les différents éléments (appelés champs) sont désignés par leurs noms li (pour label). Dans le programme, le nom de champ li est décoré de la définition complète de la structure S. Celle-ci n’est pas utilisée dans l’évaluation et sera décrite au chapitre 5. Comme précédemment, on note { �·} pour dénoter les valeurs. • f � : une fonction. On garde en mémoire l’intégralité de la définition de la fonction (liste de paramètres, de variables locales et corps). Même si les fonctions locales sont possibles, il n’est pas possible d’accéder aux variables de la portée entourante depuis la fonction intérieure (il n’y a pas de fermetures). Contrairement à C, les fonctions ne sont pas des cas spéciaux. Par exemple, les fonctions globales sont simplement des variables globales de type fonctionnel, et les « pointeurs sur fonction » de C sont remplacés par des variables de type fonction. • Ω : une erreur. Par exemple le résultat l’évaluation de 5/0 est Ωd i v . Les erreurs peuvent être classifiées en deux grand groupes : d’une part, Ωf i eld , Ωvar et Ωt yp sont des erreurs de typage dynamique, qui arrivent lorsqu’on accède dynamiquement à des données qui n’existent pas ou qu’on manipule des types de données incompatibles. D’autre part, Ωd i v , Ωar r ay et Ωp t r correspondent à des valeurs mal utilisées. Le but du système de types du chapitre 5 sera d’éliminer complètement les erreurs du premier groupe. 4.4 Interprète La figure 4.8 résume comment ces valeurs sont organisées. Une pile est une liste de cadres de piles, et un cadre de pile est une liste de couples (nom, valeur). Un état mémoire m est un couple (s, g ) où s est une pile et g un cadre de pile (qui représente les variables globales). On note |m| = |s| la hauteur de la pile (en nombre de cadres). Enfin, l’interprétation est définie comme une relation · → · entre états Ξ ; ces états sont d’une des formes suivantes :44 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION Valeurs v ::= c� Constante | &� ϕ Référence mémoire | {l1 : v�1;...;ln : vn} Structure | [v�1;...; vn] Tableau | f � Fonction | Ω Erreur Chemins ϕ ::= a Adresse | ϕ�.l Accès à un champ | ϕ[ �n] Accès à un élément Adresses a ::= (n, x) Variable locale | (x) Variable globale Erreur Ω ::= Ωar r ay Débordement de tableau | Ωp t r Erreur de pointeur | Ωd i v Division par zéro | Ωf i eld Erreur de champ | Ωvar Variable inconnue | Ωt yp Données incompatibles FIGURE 4.7 : Valeurs Pile s ::= [ ] Pile vide | {x1 �→ v1;...;xn �→ vn} :: s Ajout d’un cadre État mémoire m ::= (s, {x1 �→ v1;...;xn �→ vn}) Pile, globales État d’interprète Ξ ::= 〈e,m〉 Expression, mémoire | 〈i,m〉 Instruction, mémoire | Ω Erreur FIGURE 4.8 : Composantes d’un état mémoire4.5. OPÉRATIONS SUR LES VALEURS 45 • un couple 〈e,m〉 où e est une expression et m un état mémoire. m est l’état mémoire sous lequel l’évaluation sera réalisée. Par exemple 〈3, ([ ], [x �→ 3])〉 → 〈�3, ([ ], [x �→ 3])〉 L’évaluation des expressions est détaillée dans la section 4.10. • un couple 〈i,m〉 où i est une instruction et m un état mémoire. La réduction des instructions est traitée dans la section 4.11. Par exemple, 〈(x ← 3; y ← x),m〉 → 〈y ← x,m[x �→ �3]〉 → 〈PASS,m[x �→ �3][y �→ �3]〉. Dans le cas général, utiliser des instructions pour représenter l’état des calculs ne suffit pas ; il faut utiliser une continuation. C’est ce qui est fait par exemple dans la sémantique de CMinor [AB07]. Ici, le flot de contrôle est plus simple et on peut se contenter de retenir une simple instruction, ce qui simplifie la présentation. • un couple 〈l v,m〉 où l v est une valeur gauche et m un état mémoire. L’évaluation des valeurs gauches est décrite en section 4.9. • une erreur Ω. La propagation des erreurs est détaillée dans la section 4.12. L’évaluation des expressions, valeurs gauches et instructions se fait à petits pas. C’est-à- dire qu’on simplifie d’étape en étape leur forme, jusqu’à arriver à un cas de base : • pour les expressions, une valeur v ; • pour les instructions, l’instruction PASS ou RETURN(v) où v est une valeur ; • pour les valeurs gauches, un chemin ϕ. On considère en fait la clôture transitive de cette relation. Cela revient à ajouter une règle : Ξ1 → Ξ2 Ξ2 → Ξ3 Ξ1 → Ξ3 (TRANS) 4.5 Opérations sur les valeurs Un certain nombre d’opérations est possible sur les valeurs (figure 4.6) : • les opérations arithmétiques +, −, ×, / et % sur les entiers. L’opérateur % correspond au modulo (reste de la division euclidienne). En cas de division par zéro, l’erreur Ωd i v est levée. • les versions « pointées » +., −., ×. et /. sur les flottants. • les opérations d’arithmétique de pointeur +p et −p qui à un chemin mémoire et un entier associent un chemin mémoire. • les opérations d’égalité = et �=. L’égalité entre entiers ou entre flottants est immédiate. Deux valeurs composées (tableaux ou structures) sont égales si elles ont la même forme (même taille pour les tableaux, ou mêmes champs pour les structures) et que toutes leurs sous-valeurs sont égales deux à deux. Deux références mémoire sont égales lorsque les chemins qu’elles décrivent sont syntaxiquement égaux. • les opérations de comparaison ≤,≥,<,> sont définies avec leur sémantique habituelle sur les entiers et les flottants. Sur les références mémoires, elles sont définies dans le cas où les deux opérandes sont de la forme ϕ[·] par : ϕ[n] � ϕ[m] def == n � m. Dans les autres cas, l’erreur Ωp t r est renvoyée. Notamment, il n’est pas possible de comparer deux fonctions, deux tableaux ou deux structures. • les opérateurs bit à bit sont définis sur les entiers. &, | et ^ représentent respectivement la conjonction, la disjonction et la disjonction exclusive (XOR).46 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION • des versions logiques de la conjonction (&&) et de la disjonction (||) sont également présentes. Leur sémantique est donnée par le tableau suivant : n m n && m n || m 0 0 0 0 0 �= 0 0 1 �= 0 0 0 1 �= 0 �= 0 1 1 • des opérateurs de décalage à gauche (�) et à droite (�) sont présents. Eux aussi ne s’appliquent qu’aux entiers. • les opérateurs arithmétiques unaires +, −, +. et −. sont équivalents par définition à l’opération binaire correspondante. Par exemple −4 def == 0−4. • ∼ inverse tous les bits de son opérande. ! est une version logique, c’est-à-dire que !0 = 1 et, si n �= 0, !n = 0. Si ces opérateurs sémantiques reçoivent des données incompatibles (par exemple si on tente d’ajouter une fonction et un entier), l’erreur spéciale Ωt yp est renvoyée. 4.6 Opérations sur les états mémoire Définition 4.4 (Recherche de variable). La recherche de variable permet d’associer à une variable x une adresse a. Chaque fonction peut accéder aux variables locales de la fonction en cours, ainsi qu’aux variables globales. Remarque : le cadre de variables locales le plus récent a toujours l’indice 1. Lookup((s, g ),x) =    (|s|,x) si |s| > 0 et (x �→ v) ∈ s1 x si (x �→ v) ∈ g Ωvar sinon En entrant dans une fonction, on rajoutera un cadre de pile qui contient les paramètres de la fonction ainsi que ses variables locales. En retournant à l’appelant, il faudra supprimer ce cadre de pile. Définition 4.5 (Manipulations de pile). On définit l’empilement d’un cadre de pile c = ((x1 �→ v1),..., (xn �→ vn)) sur un état mémoire m = (s, g ) (figure 4.9(a)) : Push((s, g ),c) = (c :: s, g ) On définit aussi l’extension du dernier cadre de pile, qui sert aux déclarations de variables locales (figure 4.9(b)) : Extend((c :: s, g ),x �→ v) = (((x �→ v :: c) :: s), g ) L’opération inverse de Extend(·,· �→ ·) sera simplement notée « − » : m − x, par exemple. De même on définit le dépilement (figure 4.9(c)) : Pop((c :: s, g )) = (s, g )4.6. OPÉRATIONS SUR LES ÉTATS MÉMOIRE 47 x �→ 0 Push(·, (x �→ 0)) (a) Empilement x �→ 0 x �→ 0, y �→ 3 Extend(·, y �→ 3) (b) Extension de cadre ... Pop (c) Dépilement FIGURE 4.9 : Opérations de pile Définition 4.6 (Hauteur d’une valeur). Une valeur peut contenir une référence vers une variable de la pile. La hauteur d’une valeur est l’indice du plus haut cadre qu’elle référence, ou −1 sinon. H (c�) = −1 H (f �) = −1 H (&� ϕ) = HΦ(ϕ) H ({l1 : v�1;...;ln : vn}) = max i∈[1;n] H (vi) H ([v�1,..., vn]) = max i∈[1;n] H (vi) où : HΦ((x)) = −1 HΦ((n,x)) = n HΦ(ϕ�.l) = HΦ(ϕ) HΦ(ϕ[ �n]) = HΦ(ϕ) Les opérations Extend et Pop ne sont définies que pour une pile non vide. Néanmoins cela ne pose pas de problème, puisque, lors de l’exécution, la pile n’est vide que lors de l’évaluation d’expressions dans les phrases de programme. À cet endroit, seules des expressions peuvent apparaître, et leur évaluation ne manipule jamais la pile avec ces opérations. On définit aussi une opération de nettoyage de pile, qui sera utile pour les retours de fonction. En effet, si une référence au dernier cadre est toujours présente après le retour d’une fonction, cela peut casser le typage. Par exemple, dans la figure 4.10, l’exécution de h( ) donne à p la valeur (1,x). Puis en arrivant dans g , le déréférencement de p va modifier x qui va avoir la valeur 1. x, variable flottante, contient donc un entier. Dans la ligne marquée (*), on réalise donc l’addition d’un entier (contenu dans x malgré le type de la variable) et d’un flottant. Cette opération est bien typée dans le programme mais provoquera une erreur Ωt yp à l’exécution. Pour empêcher cela, on instrumente donc le retour de la fonction f pour que p soit remplacé par NULL. Alors dans h, le déréférencement provoquera une erreur et empêchera la violation du typage.48 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION f = Fun () { Decl x = 0 in return (&x); } g = Fun (p) { Decl x = 0.0 in *p = 1; x <- x + 2.0; // (*) } h = Fun () { Decl p = f() in g(p); } FIGURE 4.10 : Cassage du typage par un pointeur fou Pour définir l’opération de nettoyage, on commence par définir une opération de nettoyage selon un prédicat sur les chemins : CleanVP(p,c�) = c� CleanVP(p, f �) = f � CleanVP(p,&� ϕ) = � NULL si p(ϕ) &� ϕ sinon CleanVP(p,{l1 : v�1,...,ln : vn}) = {l1 : CleanVP(p, v1 �),...,ln : CleanVP(p, vn)} CleanVP(p,[v�1;...; vn]) = [CleanVP(p, v1 �);...;CleanVP(p, vn)] On l’étend ensuite aux cadres de pile, puis aux états mémoire : CleanLP(p, (x1 �→ v1,...,xn �→ vn)) = (x1 �→ CleanVP(p, v1),...,xn �→ CleanVP(p, vn)) CleanP(p, (s, g )) = (s� , g � ) où s� = (CleanLP(p,s1),...,CleanLP(p,s|s|)) g � = CleanLP(p, g ) À l’aide de ces fonctions, on définit quatre opérations permettant de nettoyer des états mémoire ou des valeurs en enlevant tout un niveau de pile ou seulement une variable : Cleanup(m) = CleanP(λϕ.HΦ(ϕ) > |m|,m) CleanVar(m,a) = CleanP(λϕ.ϕ = a,m) CleanVm(v) = CleanVP(λϕ.HΦ(ϕ) > |m|, v) CleanVarV(v,a) = CleanVP(λϕ.ϕ = a, v) Ces 4 fonctions seront utilisées dans plusieurs règles dans la suite de ce chapitre.4.7. ACCESSEURS 49 Remarques Ces opérations ne sont pas toujours bien définies. Par exemple, Extend(·,· �→ ·) ne peut pas s’appliquer à une pile vide, et m − x n’est défini que si une variable x existe au sommet de la pile de m. Ce caractère partiel ne pose pas de problème de par la structure des règles qui vont utiliser ces constructions. Par exemple, à chaque empilement correspond exactement un dépilement. De plus, les phrases d’un programme ne peuvent pas faire intervenir de déclaration de variable (une instruction est forcément dans une fonction), donc Extend(·,· �→ ·) réussit toujours. Un autre problème se pose si deux variables ont le même nom dans un cadre. Elles ne peuvent pas être distinguées. On interdit donc ce cas en demandant aux programmes d’être bien formés : au sein d’une fonction, les paramètres ainsi que l’ensemble des locales déclarées doivent être de noms différents. En pratique, une phase préalable d’α-conversion peut renommer les variables problématiques. De plus, le fait d’ajouter cette étape de nettoyage à chaque retour de fonction peut être assez coûteux. C’est un compromis : si on considère que les programmes se comportent bien et ne créent pas de pointeurs fous (pointant au-dessus de la pile), alors cette phase est inutile et peut être remplacée par l’identité. Autrement dit, il s’agit seulement d’une technique pour s’assurer de ne pas avoir d’erreurs dans la sémantique. L’ajout d’un ramasse-miette, ou une vérification préalable par un système de régions [TJ92], peut garantir qu’il n’y a pas de telles constructions dangereuses. 4.7 Accesseurs Le but de cette section est de définir rigoureusement les accès à la mémoire. À partir d’un état mémoire m et d’une valeur gauche ϕ, on veut pouvoir définir une lentille Φ, permettant d’obtenir : • la valeur accessible au chemin ϕ : m[ϕ]Φ • l’état mémoire obtenu en remplaçant celle-ci par une nouvelle valeur v� : m[ϕ ← v� ]Φ Pour définir cette lentille indexée Φ, on commence par définir des lentilles élémentaires, et on les compose pour pouvoir définir des lentilles entre valeurs. On commence par définir deux lentilles I et L pour accéder aux structures de listes. I accède par indice et L par clef (dans une liste d’association, donc). Cela permet ensuite de définir A, qui extrait une valeur à partir d’un nom de variable et d’une éventuelle hauteur de pile. Pour cela, on compose les lentilles I et L. Les autres travaillent sur des valeurs composées, c’est-à-dire sur les structures et tableaux. La lentille F extrait une sous-valeur correspondant au champ d’une structure. Le fonctionnement est similaire à la lentille L puisqu’on accède par nom à une sous-structure. La lentille T , quant à elle, permet d’accéder au ne élement d’un tableau. De ce point de vue, elle est similaire à I mais en travaillant sur les valeurs. Enfin, on définit Φ pour accéder à n’importe quelle sous-valeur d’une variable dans la mémoire. Cela utilise A, F et T précédemment définis. La figure 4.11 résume ces dépendances. Les lignes pleines indiquent quelles sont les défi- nitions utilisées, et les pointillés relient les lentilles similaires. À droite, on donne un exemple des lentilles de base. La valeur entourée correspond au « curseur » de la lentille, c’est-à-dire la valeur qui peut être renvoyée ou mise à jour.50 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION I L F T A Φ I(3) : (3, 14, 15 , 92, 65) L(toto) : ((toto, 3 ), (t at a, 6), (t i t i, 2)) F(y) : {x : 0; y : -3 } T (0) : [ 1 ; 2; 3; 5] FIGURE 4.11 : Dépendances entre les lentilles Accès à une liste par indice : I On définit une lentille indexée I : N → LENSα∗,α permettant d’accéder aux éléments d’une liste par leur indice. On rappelle que les listes sont des suites finies, définies page 36. En outre, I n’est définie que pour n ∈ [1;|l|]. l[n]I = ln si n ∈ [1;|l|] l[n ← x]I = l � où l � n = x ∀i �= n,l � i = li Accès à une liste d’associations : L Une liste d’association est une liste de paires (clef, valeur) avec l’invariant supplémentaire que les clefs sont uniques. Il est donc possible de trouver au plus une valeur associée à une clef donnée. L’écriture est également possible, en remplaçant un couple par un couple avec une valeur différente. l[x]L = � v si ∃!n ∈ [1;|l|],∃v,ln = (x �→ v) Ωvar sinon l[x ← v� ]L = � l[n ← (x �→ v� )]I si ∃!n ∈ [1;|l|],∃v,ln = (x �→ v) Ωvar sinon Accès par adresse : A Les états mémoire sont constitués des listes d’association (nom, valeur). L’accesseur par adresse [·]A permet de généraliser l’accès à ces valeurs en utilisant comme clef non pas un nom mais une adresse. Selon cette adresse, on accède soit à la liste des variables globales, soit à une des listes de la pile des variables locales. On pose m = (s, g ). Les accès aux variables globales se font de la manière suivante. Si la variable n’existe pas, notons que L retourne Ωvar .4.7. ACCESSEURS 51 A((x)) = Snd≫L(x) Snd désigne la lentille entre un couple et sa deuxième composante. Ainsi, par exemple m[(x) ← v]A = (s, g [x ← v]L). Les accès aux locales reviennent à accéder à la bonne variable du bon cadre de pile. Cela revient naturellement à composer les lentilles L et I. On définit donc une lentille Ls,n,x = I(|s|−n +1)≫L(x) qui accède à la variable x du ne cadre de pile. m[(n,x)]A = � getLs,n,x (s) si n ∈ [1;|s|] Ωvar sinon m[(n,x) ← v]A = � (putLs,n,x (v,s), g ) si n ∈ [1;|s|] Ωvar sinon Les numéros de cadre qui permettent d’identifier les locales (le n dans (n,x)) croissent avec la pile. D’autre part, l’empilement se fait en tête de liste (près de l’indice 1). Donc pour accéder aux plus vieilles locales (numérotées 1), il faut accéder au dernier élément de la liste. Ceci explique pourquoi un indice |s|−n +1 apparaît dans la définition précédente. Accès par champ : F Les valeurs qui sont des structures possèdent des sous-valeurs, associées à des noms de champ. L’accesseur [·]F permet de lire et de modifier un champ de ces valeurs. L’erreur Ωf i eld est levée si on accède à un champ non existant. {l1 : v1;...;ln : vn}[l]F = vi si ∃i ∈ [1;n],l = li {l1 : v1;...;ln : vn}[l]F = Ωf i eld sinon {l1 : v1;...;ln : vn}[l ← v]F = {l1 : v1 ;... ;lp−1 : vp−1 ;lp : v ;lp+1 : vp+1 ;... ;ln : vn} si ∃p ∈ [1;n],l = lp {l1 : v1;...;ln : vn}[l ← v]F = Ωf i eld sinon Accès par indice de tableau : T On définit de même un accesseur [·]T pour les accès par indice à des valeurs tableaux. Néanmoins le paramètre indice est toujours un entier et pas une expression arbitraire. Notons que les accès sont vérifiés dynamiquement : il ne peut pas y avoir de débordement de tableau.52 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION [v1;...; vn][i]T = vi+1 si i ∈ [0;n −1] [v1;...; vn][i]T = Ωar r ay sinon [v1;...; vn][i ← v]T = [v� 1;...; v� n] si i ∈ [0;n −1] où � v� i = v ∀j �= i, v� j = v j [v1;...; vn][i ← v]T = Ωar r ay sinon Accès par chemin : Φ L’accès par chemin Φ permet de lire et de modifier la mémoire en profondeur. On peut accéder directement à une variable, et les accès à des sous-valeurs se font en composant les accesseurs (définition 4.3, page 39) : Φ(a) = A(a) Φ(ϕ.l) = Φ(ϕ)≫F(l) Φ(ϕ[i]) = Φ(ϕ)≫T (i) Remarque Dans toute la suite, lorsque ce n’est pas ambigü, on emploiera la notation m[ϕ] pour désigner m[ϕ]Φ. Il est important de remarquer que m désigne un état particulier et ϕ un chemin particulier, mais que Φ est la lentille indexée globale définie page 52. 4.8 Contextes d’évaluation L’évaluation des expressions repose sur la notion de contextes d’évaluation. L’idée est que, si on peut évaluer une expression, alors on peut évaluer une expression qui contient celle-ci. Par exemple, supposons que 〈f (3),m〉 → 〈2,m〉. Alors on peut ajouter la constante 1 à gauche de chaque expression sans changer le résultat : 〈1+ f (3),m〉 → 〈1+2,m〉. On a utilisé le même contexte C = 1+ •. Pour pouvoir raisonner en termes de contextes, 3 points sont nécessaires : • comment découper une expression selon un contexte ; • comment appliquer une règle d’évaluation sous un contexte ; • comment regrouper une expression et un contexte. Le premier point consiste à définir les contextes eux-mêmes (figure 4.12). Dans cette définition, chaque cas hormis le cas de base fait apparaître exactement un «C ». Chaque contexte est donc constitué d’exactement une occurrence de • (une dérivation de C est toujours linéaire). L’opération de substitution consiste à remplacer ce trou : C�X� est l’objet syntaxique (instruction, expression ou valeur gauche) obtenu en remplaçant l’unique • dans C par X. Par exemple, DECL x = 2+ • IN{PASS}�5� est DECL x = 2+5 IN{PASS} À titre d’illustration, décomposons l’évaluation de e1 � e2 en v = v1 �� v2 depuis un état mémoire m :4.8. CONTEXTES D’ÉVALUATION 53 Contextes C ::= • | C � e | v � C | � C | & C | C ← e | ϕ ←C | {l1 : v1;...;li :C;...;ln : en} | [v1;...;C;...;en] | C(e1,...,en) | f (v1,...,C,...,en) | C.lS | C[e] | ϕ[C] | ∗ C | C;i | IF(C){i1}ELSE{i2} | RETURN(C) | DECL x = C IN{i} FIGURE 4.12 : Contextes d’évaluation 1. on commence par évaluer l’expression e1 en une valeur v1. Le nouvel état mémoire est noté m� . Soit donc 〈e1,m〉 → 〈v1,m� 〉. 2. En appliquant la règle CTX (définie ci-après) avec C = • � e2 (qui est une des formes possibles pour un contexte d’évaluation), on déduit de 1. que 〈e1 � e2,m〉 → 〈v1 � e2,m� 〉 3. D’autre part, on évalue e2 depuis m� . En supposant encore que l’évaluation converge, notons v2 la valeur calculée et m�� l’état mémoire résultant : 〈e2,m� 〉 → 〈v2,m��〉. 4. Appliquons la règle CTX à 3. avec C = v1 � •. On obtient 〈v1 � e2,m〉 → 〈v1 � v2,m� 〉. 5. En combinant les résultats de 2. et 4. on en déduit que 〈e1 � e2,m〉 → 〈v1 � v2,m��〉. 6. D’après la règle EXP-BINOP (page 55), 〈v1 � v2,m��〉 → 〈v1 �� v2,m��〉 7. D’après 5. et 6., on a par combinaison 〈e1 � e2,m〉 → 〈v,m��〉 en posant v = v1 �� v2. Le deuxième point sera résolu par la règle d’inférence suivante. 〈i,m〉 → 〈i � ,m� 〉 〈C�i�,m〉 → 〈C�i � �,m� 〉 (CTX) Enfin, le troisième revient à définir l’opérateur de substitution ·�·� présent dans la règle précédente. Notons que puisque i ::= e et e ::= l v, on peut aussi l’appliquer aux expressions et aux valeurs gauches : l’opération ·�·� est purement syntaxique.54 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION 4.9 Valeurs gauches Obtenir un chemin à partir d’un nom de variable revient à résoudre le nom de cette variable : est-elle accessible ? Le nom désigne-t-il une variable locale ou une variable globale ? a = Lookup(x,m) 〈x,m〉 → 〈a,m〉 (PHI-VAR) Les règles portant sur le déréférencement et l’accès à un champ de structure sont similaires : on commence par évaluer la valeur gauche sur laquelle porte ce modificateur, et on place le même modificateur sur le chemin résultant. Dans le cas des champs de structure, l’annotation de structure S n’est pas prise en compte pour l’évaluation : elle servira uniquement au typage. 〈ϕ.lS,m〉 → 〈ϕ�.l,m〉 (PHI-STRUCT) Enfin, pour évaluer un chemin dans un tableau, on commence par procéder comme pré- cédemment, c’est-à-dire en évaluant la valeur gauche sur laquelle porte l’opération d’indexation. Puis on évalue l’expression d’indice en une valeur qui permet de construire le chemin résultant. 〈ϕ[n],m〉 → 〈ϕ[ �n],m〉 (PHI-ARRAY) Notons qu’en procédant ainsi, on évalue les valeurs gauches en allant de gauche à droite : dans l’expression x[e1][e2][e3], e1 est évalué en premier, puis e2, puis e3. La règle portant sur le déréférencement est particulière. On peut penser que la bonne définition de ϕ consiste à se calquer sur la définition de l v, en remplaçant les noms de variable par leur adresse résolue et en évaluant les indices de tableau, et à ajouter une règle qui transforme ∗ϕ en ∗�ϕ. Or, cela ne fonctionne pas, car alors les déréférencements sont évalués trop tard : au moment de l’affectation dans la valeur gauche plutôt qu’à sa définition. La figure 4.13 illustre ce problème. Decl s0 = { .f : 0 } in Decl s1 = { .f : 1 } in Decl x = & s0 in Decl p = & ((*x).f) in /* (a) */ x <- & s1 /* (b) */ FIGURE 4.13 : Évaluation stricte ou paresseuse des valeurs gauches On s’intéresse à l’évaluation de l’expression *p aux points (a) et (b). Avec une sémantique paresseuse (en ajoutant un ∗�ϕ), la valeur de p est & (( � ∗(1,x)).f ), donc *p est évalué à 0 en (a) et 1 en (b). Au contraire, avec une sémantique stricte (correcte), p vaut & (((1, � s0).f ) et donc *p est évalué à 0 en (a) et en (b). Dans le cas où la valeur référencée n’a pas la forme &�ϕ ou N �ULL, aucune règle ne peut s’appliquer (comme lorsqu’on cherche à réduire l’addition d’une fonction et d’un entier, par4.10. EXPRESSIONS 55 exemple). Cela est préférable à renvoyer Ωp t r car on montrera que ce cas est toujours évité dans les programmes typés (théorème 5.1). v = &� ϕ 〈∗ v,m〉 → 〈ϕ,m〉 (EXP-DEREF) v = N �ULL 〈∗ v,m〉 → Ωp t r (EXP-DEREF-NULL) Par exemple, l v = x.lS[2∗n].gT pourra s’évaluer en ϕ = (2,x).l[4].g . 4.10 Expressions Évaluer une constante est le cas le plus simple, puisqu’en quelque sorte celle-ci est déjà évaluée. À chaque constante syntaxique c, on peut associer une valeur sémantique c�. Par exemple, au chiffre (symbole) 3, on associe le nombre (entier) �3. 〈c,m〉 → 〈c�,m〉 (EXP-CST) De même, une fonction est déjà évaluée : 〈f ,m〉 → 〈f �,m〉 (EXP-FUN) Pour lire le contenu d’un emplacement mémoire (valeur gauche), il faut tout d’abord l’évaluer en un chemin. 〈ϕ,m〉 → 〈m[ϕ]Φ,m〉 (EXP-LV ) Pour évaluer une expression constituée d’un opérateur, on évalue une sous-expression, puis l’autre (l’ordre d’évaluation est encore imposé : de gauche à droite). À chaque opérateur �, correspond un opérateur sémantique �� qui agit sur les valeurs. Par exemple, l’opérateur +� est l’addition entre entiers machine (page 43). Comme précisé dans la section 4.5, la division par zéro via /, % ou /. provoque l’erreur Ωd i v . 〈� v,m〉 → 〈�� v,m〉 (EXP-UNOP) 〈v1 � v2,m〉 → 〈v1 �� v2,m〉 (EXP-BINOP) Il est nécessaire de dire un mot sur les opérations +�p et −�p définissant l’arithmétique des pointeurs. Celles-ci sont uniquement définies pour les références mémoire à un tableau, c’est-à-dire celles qui ont la forme &� ϕ[n]. On a alors : &� ϕ[n] +�p i = &� ϕ[n +� i] &� ϕ[n] ] −�p i = &� ϕ[n −� i] Cela implique qu’on ne peut pas faire d’arithmétique de pointeurs au sein d’une même structure. Autrement c’est une erreur de manipulation de pointeurs 3 et l’opérateur �� renvoie Ωp t r . 3. Cela est cohérent avec la norme C99 : « If the pointer operand points to an element of an array object, and the array is large enough, [. . . ] ; otherwise, the behavior is undefined. » [ISO99, 6.5.6 §8]56 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION Si l’indice calculé (n +� i ou n −� i) sort de l’espace alloué, alors l’erreur sera faite au moment de l’accès : la lentille T renverra Ωar r ay (page 51). Une left-value s’évalue en le chemin correspondant. 〈& ϕ,m〉 → 〈&� ϕ,m〉 (EXP-ADDR) L’affectation se déroule en 3 étapes. D’abord, l’expression est évaluée en une valeur v. Ensuite, la valeur gauche est évaluée en un chemin ϕ. Enfin, un nouvel état mémoire est construit, où la valeur accessible par ϕ est remplacée par v. Comme dans le langage C, l’expression d’affectation produit une valeur, qui est celle qui a été affectée. 〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉 (EXP-SET) Expressions composées Les littéraux de structures sont évalués en leurs constructions syntaxiques respectives. Puisque les contextes d’évaluation sont de la forme [v1;...;C;...;en], l’évaluation se fait toujours de gauche à droite. 〈{l1 : v1;...;ln : vn},m〉 → 〈{l1 : v�1;...;ln : vn},m〉 (EXP-STRUCT) 〈[v1;...; vn],m〉 → 〈[v�1;...; vn],m〉 (EXP-ARRAY) L’appel de fonction est traité de la manière suivante. On ne peut pas facilement relier un pas d’évaluation de i à un pas d’évaluation de fun(a){i}(v1,..., vn), et donc un contexte C ::= fun(a){•}(v1,..., vn) n’est pas à considérer. En effet, l’empilement suivi du dépilement modifie la mémoire. On emploie donc une règle EXP-CALL-CTX qui relie un pas interne 〈i,m1〉 → 〈i� ,m2〉 à un pas externe. Une fois l’instruction interne réduite d’un pas, on évalue les arguments en des valeurs v� i . Ils correspondent aux nouvelles valeurs à passer à la fonction. Les autres règles permettent de transférer le flot de contrôle : en retournant la même instruction pour une instruction terminale, ou en propageant une erreur. Dans le cas où on retourne de la fonction pari = RETURN(v), il faut alors supprimer les références aux variables qui ont disparu grâce aux opérateurs Cleanup(·) et CleanV·(·). On suppose deux choses sur chaque fonction : d’une part, les noms de ses arguments sont deux à deux différents et, d’autre part, son corps se termine par une instruction RETURN(·). Cela veut dire que la dernière instruction doit être soit de cette forme, soit par exemple une alternative dans laquelle les deux branches se terminent par un RETURN(·). C’est une propriété qui peut être détectée statiquement avant l’exécution. Néanmoins, dans la syntaxe concrète, on peut supposer qu’un RETURN(( )) est inséré automatiquement en fin de fonction lorsqu’aucun RETURN(·) n’est présent dans son corps.4.11. INSTRUCTIONS 57 m1 = Push(m0, ((a1 �→ v1),..., (an �→ vn))) 〈i,m1〉 → 〈i � ,m2〉 ∀i ∈ [1;n], v� i = m2[(|m2|,ai)]A m3 = Pop(m2) 〈fun(a1,...,an){i}(v1,..., vn),m0〉 → 〈fun(a1,...,an){i � }(v� 1,..., v� n),m3〉 (EXP-CALL-CTX) m� = Push(m, ((a1 �→ v1),..., (an �→ vn))) 〈i,m� 〉 → Ω 〈fun(a1,...,an){i}(v1,..., vn),m〉 → Ω (EXP-CALL-ERR) m� = Cleanup(m) v� = CleanV|m|(v) 〈fun(a1,...,an){RETURN(v)}(v1,..., vn),m〉 → 〈v� ,m� 〉 (EXP-CALL-RETURN) 4.11 Instructions Les cas de la séquence et de l’évaluation d’une expression sont sans surprise. 〈(PASS;i),m〉 → 〈i,m〉 (SEQ) 〈v,m〉 → 〈PASS,m〉 (EXP) L’évaluation de DECL x = v IN{i} sous m se fait de la manière suivante, similaire à l’appel de fonction. La règle principale est DECL-CTX qui relie un pas d’évaluation sous une déclaration à un pas d’évaluation externe : pour ce faire, on étend l’état mémoire en ajoutant x, on effectue le pas, puis on enlève x. L’instruction résultante est la déclaration de x avec la nouvelle valeur v� de x après le pas d’exécution 4. On suppose qu’il n’y a pas de masquage au sein d’une fonction, c’est-à-dire que le nom d’une variable déclarée n’est jamais dans l’environnement avant cette déclaration. Si i est terminale (PASS ou RETURN(v)), alors on peut l’évaluer en i en nettoyant l’espace mémoire des références à x qui peuvent subsister. Enfin, si une erreur se produit elle est propagée. m� = CleanVar(m − x, (|m|,x)) 〈DECL x = v IN{PASS},m〉 → 〈PASS,m� 〉 (DECL-PASS) m� = CleanVar(m − x, (|m|,x)) v�� = CleanVarV(v� , (|m|,x)) 〈DECL x = v IN{RETURN(v� )},m〉 → 〈RETURN(v��),m� 〉 (DECL-RETURN) m� = Extend(m,x �→ v) 〈i,m� 〉 → 〈i � ,m��〉 v� = m��[(|m��|,x)]A m��� = m�� − x 〈DECL x = v IN{i},m〉 → 〈DECL x = v� IN{i � },m���〉 (DECL-CTX) 〈i,m〉 → Ω 〈DECL x = v IN{i},m〉 → Ω (DECL-ERR) Pour traiter l’alternative, on a besoin de 2 règles. Elles commencent de la même manière, en évaluant la condition. Si le résultat est 0 (et seulement dans ce cas), c’est la règle IF-FALSE 4. On peut remarquer qu’il est impossible de définir un contexte d’évaluation C ::= DECL x = v IN{C}. En effet, puisque celui-ci nécessiterait d’ajouter une variable, il ne préserve pas la mémoire.58 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION qui est appliquée et l’instruction revient à évaluer la branche « else ». Dans les autres cas, c’est la règle IF-TRUE qui s’applique et la branche « then » qui est prise. 〈IF(0){it }ELSE{if },m〉 → 〈if ,m〉 (IF-FALSE) v �= 0 〈IF(v){it }ELSE{if },m〉 → 〈it ,m〉 (IF-TRUE) On exprime la sémantique de la boucle comme une simple règle de réécriture : 〈WHILE(e){i},m〉 → 〈IF(e){i;WHILE(e){i}}ELSE{PASS},m〉 (WHILE) Enfin, si un RETURN(·) apparaît dans une séquence, on peut supprimer la suite : 〈RETURN(v);i,m〉 → 〈RETURN(v),m〉 (RETURN) 4.12 Erreurs Les erreurs se propagent des données vers l’interprète ; c’est-à-dire que si une expression ou instruction est réduite en une valeur d’erreur Ω, alors une transition est faite vers cet état d’erreur. Cela est aussi vrai d’une sous-expression ou sous-instruction : si l’évaluation de e1 provoque une erreur, l’évaluation de e1 + e2 également. La notion de sous-expression ou sous instruction est définie en fonction des contextes C. Notons que, dans EVAL-ERR, C�e� peut être une expression ou une instruction. 〈Ω,m〉 → Ω (EXP-ERR) 〈e,m〉 → Ω 〈C�e�,m〉 → Ω (EVAL-ERR) 4.13 Phrases et exécution d’un programme Un programme est constitué d’une suite de phrases qui sont soit des déclarations de variables (dont les fonctions), soit des évaluations d’expressions. Contrairement à C, il n’y a pas de déclaration de types au niveau des phrases (permettant par example de définir les types structures et leurs champs). On suppose que, dans une étape précédente, chaque accès à un champ de structure a été décoré du type complet correspondant. Par exemple, il est possible de compiler vers SAFESPEAK un langage comportant des accès non décorés, mais où les types de structures sont déclarés. Le compilateur est alors capable de repérer à quel type appartiennent quels champs et d’émettre ces étiquettes. C’est d’ailleurs une des étapes de la compilation d’un programme C. L’évaluation d’une phrase p fait donc passer d’un état mémoire m à un autre m� , ce que l’on note m � p → m� . L’évaluation d’une expression est uniquement faite pour ses effets de bord. Par exemple, après avoir défini les fonctions du programme, on pourra appeler main(). La déclaration d’une variable globale, quant à elle, consiste à évaluer sa valeur initiale et à étendre l’état mémoire avec ce couple (variable, valeur). On suppose que les variables globales ont toutes des noms différents. Notons que ces évaluations se font à grands pas.4.14. EXEMPLE 59 Enfin, l’exécution d’un programme, notée � P →∗ m, permet de construire un état mé- moire final. Cette relation →∗ est l’extension de → sur les suites de phrases, c’est-à-dire les programmes. 〈e,m〉 → 〈v,m� 〉 m � e → m� (ET-EXP) 〈e,m〉 → 〈v,m� 〉 m� = (s, g ) m�� = (s, (x �→ v) :: g ) m � x = e → m�� (ET-VAR) ([ ], [ ]) � p1 → m1 m1 � p2 → m2 ... mn−1 � pn → mn � p1,...,pn →∗ m (PROG) 4.14 Exemple Considérons le programme suivant : (p1) s = { x: 0; y: 0} (p2) f = fun(q) { *q <- 1 } (p3) f(&s.x) Ce programme est constitué des phrases p1,p2 et p3. On rappelle que par rapport à la syntaxe concrète, un RETURN(( )) est inséré automatiquement, donc p2 est en fait f = fun(q){∗q ← 1; RETURN(( ))}. De plus, un prétraitement va annoter l’accès à s.x en rajoutant le type structure de s, noté S. D’après PROG, l’évaluer va revenir à évaluer à la suite ces 3 phrases. Déclaration de x D’après PROG, on part d’un état mémoire m0 = ([ ], [ ]). Pour trouver m1 tel que m0 � s = {x : 0; y : 0} → m1, il faut appliquer la règle ET-VAR. Celle-ci va étendre l’ensemble (vide) des globales mais demande d’évaluer l’expression 0. D’après EXP-CST,〈0,m0〉 → 〈�0,m0〉. Donc m0 � s = {x : 0; y : 0} → m1 en posant m1 = ([ ], [s �→ {x�: 0; y : 0}]). Déclaration de f On se trouve encore dans le cas de la déclaration d’une variable globale. Il faut comme auparavant évaluer l’expression. C’est la règle EXP-FUN qui s’applique : 〈fun(q){∗q ← 1; RETURN(( ))},m1〉 → 〈fun(q){∗q�← 1; RETURN(( ))},m1〉 (ce qui revient à dire que le code de la fonction est directement placé en mémoire). Ainsi m1 � f = fun(q){∗q ← 1; RETURN(( ))} → m2 où : m2 = ([ ], [f �→ fun(q){∗q�← 1; RETURN(( ))};s �→ {x�: 0; y : 0}]) Appel de f Ici, on évalue une expression pour ses effets de bords. La règle à appliquer est ET-EXP, qui a comme prémisse 〈f (&s.xS),m2〉 → 〈v,m3〉. D’après la forme de l’expression, la règle à appliquer va être EXP-CALL-RETURN. Mais il va falloir d’abord réécrire l’expression à l’aide de CTX (pour que l’expression appellée ait la60 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION forme f �et l’argument soit évalué) et EXP-CALL-CTX (pour que le corps de la fonction ait pour forme RETURN(( ))). Tout d’abord on applique donc CTX avec C = •(&s.xS). Comme on a via PHI-VAR puis EXP-LV : 〈f ,m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))},m2〉 On en déduit que : 〈f (&s.xS),m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))}(&s.xS),m2〉 On évalue ensuite &s.xS. Les règles à appliquer sont EXP-ADDR et PHI-STRUCT. On en déduit que 〈&s.xS,m2〉 → 〈&( � s).x,m2〉. Remarquons que l’étiquette de type structure S a été effacée. Une application supplémentaire de CTX permet d’en arriver à la ligne suivante : 〈f (&s.xS),m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))}(&( � s).x),m2〉 La fonction et son argument sont évalués, donc on peut appliquer EXP-CALL-CTX. En posant m� 2 = Push(m2, (q �→ &( � s).x)), le but est de trouver m�� 2 et v tels que : 〈∗q ← 1; RETURN(( )),m� 2〉 → 〈RETURN(v),m�� 2 〉 Puisque l’instruction est une séquence, on va appliquer SEQ. La première partie n’étant pas PASS, il faut l’évaluer grâce à la règle CTX avec C = •; RETURN(( )). Le nouveau but est de trouver un m�� 2 tel que 〈∗q ← 1,m� 2〉 → 〈PASS,m�� 2 〉. En appliquant EXP-DEREF sous C = ∗• ← 1, on obtient 〈∗q ← 1,m� 2〉 → 〈(s).x ← 1,m� 2〉. Puis on applique EXP-CST sous C = (s).x ← • et 〈∗q ← 1,m� 2〉 → 〈(s).x ← �1,m� 2〉. Maintenant que les deux côtés de ← sont évalués, on peut appliquer EXP-SET, et 〈∗q ← 1,m� 2〉 → 〈PASS,m�� 2 〉 où : m�� 2 = ([[q �→ &( � s).x]], [f �→ fun(q){∗q�← 1; RETURN(( ))};s �→ {x�: 0; y : 0}]) Alors, d’après SEQ, 〈∗q ← 1,m� 2〉 → 〈RETURN(()),m�� 2 〉. Avec EXP-CST sous C = RETURN(•), on a donc 〈∗q ← 1,m� 2〉 → 〈RETURN(()), � m�� 2 〉. On peut enfin appliquer EXP-CALL-CTX pour en déduire que : 〈f (&s.xS),m2〉 → 〈fun(q){RETURN(( ))}( � &( � s).x),m��� 2 〉 Donc d’après EXP-CALL-RETURN (car on a m��� 2 = Cleanup(m�� 2 ) et ( )� = CleanV|m��� 2 |(( ))) : � 〈f (&s.xS),m2〉 → 〈( ), � m��� 2 〉 En posant m3 = m��� 2 , on a m2 � f (&s.xS) → m3. Donc pour conclure (grâce à PROG), on a � [p1,p2,p3] →∗ m3. Conclusion On vient de définir un langage impératif, SAFESPEAK. Le but est que celui-ci serve de support à des analyses statiques, afin notamment de montrer une propriété de sécurité sur les pointeurs. Pour le moment, on a seulement défini ce que sont les programmes (leur syntaxe) et comment ils s’exécutent (leur sémantique). Sur ces deux points, on note que nous sommes4.14. EXEMPLE 61 restés suffisamment proches de C, tout en utilisant pour la mémoire un modèle plus structuré qu’une simple suite d’octets. Les définitions de la syntaxe ainsi que de la sémantique sont rappelées dans l’annexe B (sections B.1 à B.7). Afin de manipuler les états mémoire dans la sémantique d’évaluation, nous avons utilisé le concept des lentilles, qui permettent de chaîner des accesseurs entre eux et d’accéder simplement à des valeurs profondes de la mémoire, en utilisant le même outil pour la lecture et l’écriture. Pour le moment, on ne peut rien présager de l’exécution d’un programme bien formé syntaxiquement. Pour la grande majorité des programmes bien formés (à la syntaxe correcte), l’évaluation s’arrêtera soit par une erreur, soit parce qu’aucune règle d’évaluation ne peut s’appliquer. Dans les chapitres 5 et 6, nous allons donc définir un système de types qui permet de rejeter ces programmes se comportant mal à l’exécution.C H A P I T R E 5 TYPAGE Dans ce chapitre, nous enrichissons le langage défini dans le chapitre 4 d’un système de types. Celui-ci permet de séparer les programmes bien formés, comme celui de la fi- gure 5.1(a), des programmes mal formés, comme celui de la figure 5.1(b). Intuitivement, le programme mal formé provoquera des erreurs à l’exécution car il manipule des données de manière incohérente : la variable x reçoit 1, donc elle se comporte comme un entier, puis est déférencée, se comportant comme un pointeur. f = Fun() { Decl x = 0 in x <- 1 return x } (a) Programme bien formé f = Fun() { Decl x = 0 in x <- 1 return (*x) } (b) Programme mal formé FIGURE 5.1 : Programmes bien et mal formés Le but d’un tel système de types est de rejeter les programmes pour lesquels on peut facilement déterminer qu’ils sont faux, c’est-à-dire dont on peut prouver qu’ils provoqueraient des erreurs à l’exécution dues à une incompatibilité entre valeurs. En ajoutant cette étape, on restreint la classe d’erreurs qui pourraient bloquer la sémantique. On emploie un système de types monomorphe : à chaque expression, on associe un unique type. En plus des types de base INT, FLOAT et UNIT, on peut construire des types composés : pointeurs, tableaux, structures et fonctions. Pour typer les structures, on suppose que les accès aux champs sont décorés du type complet de la structure. Cela permet de typer sans ambigüité ces accès. Dans l’implantation dé- crite dans le chapitre 7, ces annotations ne sont pas présentes. On y utilise donc une variante du polymorphisme de rangée [RV98] présent dans OCaml pour unifier deux types structures partiellement connus. Le principe du typage est d’associer à chaque construction syntaxique une étiquette représentant le genre de valeurs qu’elle produira. Dans le programme de la figure 5.1(a), la variable x est initialisée avec la valeur 0 ; c’est donc un entier. Cela signifie que, dans tout le programme, toutes les instances de cette variable 1 porteront ce type. La première instruction 1. Deux variables peuvent avoir le même nom dans deux fonctions différentes, par exemple. Dans ce cas il n’y a aucune contrainte particulière entre ces deux variables. L’analyse de typage se fait toujours dans un contexte précis. 6364 CHAPITRE 5. TYPAGE est l’affectation de la constante 1 (entière) à x dont on sait qu’elle porte des valeurs entières, ce qui est donc correct. Le fait de rencontrer RETURN(x) permet de conclure que le type de la fonction est ( ) → INT (c’est-à-dire qu’elle n’a pas d’arguments et qu’elle retourne un INT). Dans la seconde fonction, au contraire, l’opérateur ∗ est appliqué à x (le début de l’analyse est identique et permet de conclure que x porte des valeurs entières). Or cet opérateur prend un argument d’un type pointeur de la forme t ∗ et renvoie alors une valeur de type t. Ceci est valable pour tout t (INT, FLOAT ou même t� ∗ : le déréférencement d’un pointeur sur pointeur donne un pointeur), mais le type de x, INT, n’est pas de cette forme. Ce programme est donc mal typé. Dans ce chapitre, on commence par poser les notations qui vont servir à définir la relation de typage. Ensuite, on explique les différentes règles de typage sur les composantes de SAFESPEAK : expressions, instructions et phrases. Enfin, dans le reste du chapitre on établit des propriétés qui sont respectées par les programmes bien typés. On conclut par les théorèmes de progrès et de préservation qui établissent la sûreté du typage. 5.1 Environnements et notations Les types associés aux expressions sont décrits dans la figure 5.2. Tous sont des types concrets : il n’y a pas de polymorphisme. Type t ::= INT Entier | FLOAT Flottant | UNIT Unité | t∗ Pointeur | t [ ] Tableau | S Structure | (t1,...,tn) → t Fonction Structure S ::= {l1 : t1;...;ln : tn} FIGURE 5.2 : Types et environnements de typage Pour maintenir les contextes de typage, un environnement Γ associe un type à un ensemble de variables. Plus précisément, un environnement Γ est composé de deux listes de couples (variable, type) : une pour les variables locales, et une pour les variables globales. Cette distinction est nécessaire pour les définitions de fonctions : on remplace la liste des variables locales, mais on conserve le type des variables globales. Si Γ = (ΓG ,ΓL) = ((γi)i∈[1;n], (ηi)i∈[1;m]), avec γi = (gi ,ti) et ηi = (li ,ui), on utilise les notations suivantes :5.2. EXPRESSIONS 65 x : t ∈ Γ def == ∃i ∈ [1;n],γi = (x,t)∨ ∃i ∈ [1;m],ηi = (x,t) dom(ΓG ) def == {gi /i ∈ [1;n]} dom(ΓL) def == {li /i ∈ [1;m]} dom(Γ) def == dom(ΓG )∪dom(ΓL) Γ, global x : t def == ((γ� i) i∈[1;n+1],ΓL) tel que� ∀i ∈ [1;n],γ� i = γi γn+1 = (x,t) Γ,local x : t def == (ΓG , (η� i) i∈[1;m+1]) tel que� ∀i ∈ [1;m],η� i = ηi ηn+1 = (x,t) Le type des fonctions semble faire apparaître un n-uplet (t1,...,tn) mais ce n’est qu’une notation : il n’y a pas de n-uplets de première classe ; ils sont toujours présents dans un type fonctionnel. Le typage correspond à la définition des trois jugements suivants. Les deux premiers sont mutuellement récursifs car une instruction peut consister en l’évaluation d’une expression, et la définition d’une fonction repose sur le typage de son corps. Typage d’une expression : on note de la manière suivante le fait qu’une expression e (telle que définie dans la figure 4.4) ait pour type t dans le contexte Γ. Γ � e : t Typage d’une instruction : les instructions n’ont en revanche pas de type. Mais il est tout de même nécessaire de vérifier que toutes les sous-expressions apparaissant dans une instruction sont cohérentes ensemble. On note de la manière suivante le fait que sous l’environnement Γ l’instruction i est bien typée : Γ � i Typage d’une phrase : De par leur nature séquentielle, les phrases qui composent un programme altèrent l’environnement de typage. Par exemple, la déclaration d’une variable globale ajoute une valeur dans l’environnement. On note de la manière suivante le fait que le typage de la phrase p transforme l’environnement Γ en Γ� : Γ � p → Γ� On étend cette notation aux suites de phrases, ce qui définit le typage d’un programme, ce que l’on note � P. 5.2 Expressions Littéraux Le typage des littéraux numériques ne dépend pas de l’environnement de typage : ce sont toujours des entiers ou des flottants.66 CHAPITRE 5. TYPAGE Γ � n : INT (CST-INT) Γ � d : FLOAT (CST-FLOAT) Le pointeur nul, quant à lui, est compatible avec tous les types pointeur. Cependant, il conserve bien un type monomorphe : le type t n’est pas généralisé. Γ � NULL : t ∗ (CST-NULL) Enfin, le littéral unité a le type UNIT. Γ � ( ) : UNIT (CST-UNIT) Valeurs gauches Rappelons que l’environnement de typage Γ contient le type des variables accessibles du programme. Le cas où la valeur gauche à typer est une variable est donc direct : il suffit de retrouver son type dans l’environnement. x : t ∈ Γ Γ � x : t (LV-VAR) Dans le cas d’un déréférencement, on commence par typer la valeur gauche déréférencée. Si elle a un type pointeur, la valeur déréférencée est du type pointé. Γ � e : t ∗ Γ � ∗e : t (LV-DEREF) Pour une valeur gauche indexée (l’accès à tableau), on s’assure que l’indice soit entier, et que la valeur gauche a un type tableau : le type de l’élement est encore une fois le type de base du type tableau. Γ � e : INT Γ � l v : t[ ] Γ � l v[e] : t (LV-INDEX) Le typage de l’accès à un champ est facilité par le fait que, dans le programme, le type complet de la structure est accessible sur chaque accès. Dans la définition de cette règle on utilise la notation : (l,t) ∈ {l1 : t1;...;ln : tn} def == ∃i ∈ [1;n],l = li ∧ t = ti (l,t) ∈ S Γ � l v : S Γ � l v.lS : t (LV-FIELD)5.2. EXPRESSIONS 67 Opérateurs Un certain nombre d’opérations est possible sur le type INT. � ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>} Γ � e1 : INT Γ � e2 : INT Γ � e1 � e2 : INT (OP-INT) De même sur FLOAT. � ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .} Γ � e1 : FLOAT Γ � e2 : FLOAT Γ � e1 � e2 : FLOAT (OP-FLOAT) Les opérateurs de comparaison peuvent s’appliquer à deux opérandes qui sont d’un type qui supporte l’égalité. Ceci est représenté par un jugement EQ(t) qui est vrai pour les types INT, FLOAT et pointeurs, ainsi que les types composés si les types de leurs composantes le supportent (figure 5.3). Les opérateurs = et �= renvoient alors un INT : � ∈ {=,�=} Γ � e1 : t Γ � e2 : t EQ(t) Γ � e1 � e2 : INT (OP-EQ) EQ(t) t ∈ {INT, FLOAT} EQ(t) (EQ-NUM) EQ(t ∗) (EQ-PTR) EQ(t) EQ(t[ ]) (EQ-ARRAY) ∀i ∈ [1;n].EQ(ti) EQ({l1 : t1;...ln : tn}) (EQ-STRUCT) FIGURE 5.3 : Jugements d’égalité sur les types Les opérateurs unaires « + » et « − » appliquent aux entiers, et leurs équivalents « +. » et « −. » aux flottants. Γ � e : INT Γ � +e : INT (UNOP-PLUS-INT) Γ � e : FLOAT Γ � +.e : FLOAT (UNOP-PLUS-FLOAT) Γ � e : INT Γ � −e : INT (UNOP-MINUS-INT) Γ � e : FLOAT Γ � −.e : FLOAT (UNOP-MINUS-FLOAT) Les opérateurs de négation unaires, en revanche, ne s’appliquent qu’aux entiers. � ∈ {∼,!} Γ � e : INT Γ � � e : INT (UNOP-NOT)68 CHAPITRE 5. TYPAGE L’arithmétique de pointeurs préserve le type des pointeurs. � ∈ {+p,−p} Γ � e1 : t ∗ Γ � e2 : INT Γ � e1 � e2 : t ∗ (PTR-ARITH) Autres expressions Prendre l’adresse d’une valeur gauche rend un type pointeur sur le type de celle-ci. Γ � l v : t Γ � &l v : t ∗ (ADDR) Pour typer une affectation, on vérifie que la valeur gauche (à gauche) et l’expression (à droite) ont le même type. C’est alors le type résultat de l’expression d’affectation. Γ � l v : t Γ � e : t Γ � l v ← e : t (SET) Un littéral tableau a pour type t[ ] où t est le type de chacun de ses éléments. ∀i ∈ [1;n],Γ � ei : t Γ � [e1;...;en] : t[ ] (ARRAY) Un littéral de structure est bien typé si ses champs sont bien typés. ∀i ∈ [1;n],Γ � ei : ti Γ � {l1 : e1;...;ln : en} : {l1 : t1;...;ln : tn} (STRUCT) Pour typer un appel de fonction, on s’assure que la fonction a bien un type fonctionnel. On type alors chacun des arguments avec le type attendu. Le résultat est du type de retour de la fonction. Γ � e : (t1,...,tn) → t ∀i ∈ [1;n],Γ � ei : ti Γ � e(e1,...,en) : t (CALL) 5.3 Instructions La séquence est simple à traiter : l’instruction vide est toujours bien typée, et la suite de deux instructions est bien typée si celles-ci le sont également. Γ � PASS (PASS) Γ � i1 Γ � i2 Γ � i1;i2 (SEQ) Une instruction constituée d’une expression est bien typée si celle-ci peut être typée dans ce même contexte.5.4. FONCTIONS 69 Γ � e : t Γ � e (EXP) Une déclaration de variable est bien typée si son bloc interne est bien typé quand on ajoute à l’environnement la variable avec le type de sa valeur initiale. Γ � e : t Γ,local x : t � i Γ � DECL x = e IN{i} (DECL) Les constructions de contrôle sont bien typées si leurs sous-instructions sont bien typées, et si la condition est d’un type entier. Γ � e : INT Γ � i1 Γ � i2 Γ � IF(e){i1}ELSE{i2} (IF) Γ � e : INT Γ � i Γ � WHILE(e){i} (WHILE) 5.4 Fonctions Le typage des fonctions fait intervenir une variable virtuelle R. Cela revient à typer l’instruction RETURN(e) comme R ← e. Cela rappelle le langage Pascal, où pour retourner une valeur on l’affecte à une variable nommée comme la fonction courante 2. R : t ∈ Γ Γ � e : t Γ � RETURN(e) (RETURN) Pour typer une définition de fonction, on commence par créer un nouvel environnement de typage Γ� obtenu par la suite d’opérations suivantes : • on enlève l’ensemble des locales. Cela inclut le couple R : tf correspondant à la valeur de retour de la fonction appelante. • on ajoute les types des arguments ai : ti • on ajoute le type de la valeur de retour de la fonction appelée, R : t Si le corps de la fonction est bien typé sous Γ� , alors la fonction est typable en (t1,...,tn) → t sous Γ. Γ = (ΓG ,ΓL) Γ� = (ΓG , [a1 : t1;...;an : tn;R : t]) Γ� � i Γ � fun(a1,...,an){i} : (t1,...,tn) → t (FUN) 5.5 Phrases Le typage des phrases est détaillé dans la figure 5.4. Le typage d’une expression est le cas le plus simple. En effet, il y a juste à vérifier que celle-ci est bien typable (avec ce type) dans l’environnement de départ : l’environnement n’est pas modifié. En revanche, la déclaration d’une variable globale commence de la même manière, mais on enrichit l’environnement de typage des globales de cette nouvelle association. 2. Si on n’avait pas introduit la restriction que chaque fonction doit terminer par un RETURN(·) (page 56), alors le type de R pourrait rester inconnu. En pratique cela veut dire que la valeur de retour d’une telle fonction serait compatible avec n’importe quel type t, ce qui briserait la sûreté du typage.70 CHAPITRE 5. TYPAGE Γ � p → Γ� Γ � e : t Γ � e → Γ (T-EXP) Γ � e : t Γ� = Γ, global x : t Γ � x = e → Γ� (T-VAR) Γ � P [ ] � p1 → Γ1 Γ1 � p2 → Γ2 ... Γn−1 � pn → Γn � p1,...,pn (PROG) FIGURE 5.4 : Typage des phrases et programmes 5.6 Sûreté du typage Comme nous l’évoquions au début de ce chapitre, le but du typage est de rejeter certains programmes afin de ne garder que ceux qui ne provoquent pas un certain type d’erreurs à l’exécution. Dans la suite, nous donnons des propriétés que respectent tous les programmes bien typés. Il est traditionnel de rappeler l’adage de Robin Milner : Well-typed programs don’t go wrong. To go wrong reste bien sûr à définir ! Cette sûreté du typage repose sur deux théorèmes : • progrès : si un terme est bien typé, il y a toujours une règle d’évaluation qui s’applique. • préservation (ou subject reduction) : l’évaluation transforme un terme bien typé en un terme du même type. 5.7 Typage des valeurs Puisque nous allons manipuler les propriétés statiques et dynamiques des programmes, nous allons avoir à traiter des environnements de typage Γ et des états mémoires m. La première chose à faire est donc d’établir une correspondance entre ces deux mondes. Étant donné un état mémoire m, on associe un type de valeur τ aux valeurs v. Cela est fait sous la forme d’un jugement m � v : τ. Ces types de valeurs ne sont pas exactement les mêmes que les types statiques. Pour les calculer, on n’a pas accès au code du programme, seulement à ses données. Il est par exemple possible de reconnaître le type des constantes, mais pas celui des fonctions. Celles-ci sont en fait le seul cas qu’il est impossible de déterminer à l’exécution. On le remplace donc par un cas plus simple où seul l’arité est conservée. Remarque Le fait d’effacer les types à l’exécution est un choix permettant d’alléger les valeurs en mémoire. Il serait aussi possible de conserver les types complets à l’exécution, afin de permettre une introspection dynamique des valeurs, mais cela éloignerait le langage de C. Le cas des références (règle S-PTR) utilise le typage des valeurs gauches, codéfini par : m �Φ ϕ : τ def == m � m[ϕ]Φ : τ5.7. TYPAGE DES VALEURS 71 Les règles de définition du typage des valeurs sont données dans la figure 5.5. On rappelle que Φ est la lentille indexée définie page 52. Type de valeur τ ::= INT Entier | FLOAT Flottant | UNIT Unité | τ ∗ Pointeur | τ[ ] Tableau | {l1 : τ1;...;ln : τn} Structure | FUNn Fonction FIGURE 5.5 : Types de valeurs Les règles sont détaillées dans la figure 5.6 : les types des constantes sont simples à retrouver car il y a assez d’information en mémoire. Pour les références, ce qui peut être déréférencé en une valeur de type τ est un τ ∗. Le typage des valeurs composées se fait en profondeur. En- fin, la seule information restant à l’exécution sur les fonctions est son arité. m � v : τ m � n : INT (S-INT) m � d : FLOAT (S-FLOAT) m � ( ) : UNIT (S-UNIT) m � NULL : τ ∗ (S-NULL) m �Φ ϕ : τ m � &� ϕ : τ ∗ (S-PTR) ∀i ∈ [1;n].m � vi : τ m � [v�1;...; vn] : τ[ ] (S-ARRAY) ∀i ∈ [1;n].m � vi : τi m � {l1 : v�1;...;ln : vn} : {l1 : τ1;...;ln : τn} (S-STRUCT) m � fun(x1,...,xn){i} : FUNn (S-FUN) FIGURE 5.6 : Règles de typage des valeurs La prochaine étape est de définir une relation de compatibilité entre les types de valeurs τ et statiques t. Nous noterons ceci sous la forme d’un jugement τ�t. Les règles sont décrites dans la figure 5.7, la règle importante étant COMP-FUN. Notons qu’on garde le même nom pour les types de base, et que par exemple INT peut être vu soit comme un type statique, soit comme un type de valeur. Il y a donc un abus de notation dans la règle COMP-GROUND : quand on note INT�INT, le premier désigne le type des valeurs à l’exécution, et le second le type statique. On définit enfin la notion d’état mémoire bien typé. On dit qu’un état mémoire m est bien typé sous un environnement Γ, ce que l’on note Γ � m, si le type des valeurs à l’exécution présent dans m est « compatible » avec les types présents dans Γ. Cela se fait par induction sur la forme de Γ et m. Fonctionnellement, cela implique que les accès à la mémoire retournent des valeurs en accord avec le type statique (lemme 5.6). Les72 CHAPITRE 5. TYPAGE τ�t t ∈ {INT, FLOAT, UNIT} t �t (COMP-GROUND) τ�t τ ∗�t ∗ (COMP-PTR) τ�t τ[ ]�t[ ] (COMP-ARRAY) ∀i ∈ [1;n].τi �ti {l1 : τ1;...;ln : τn}�{l1 : t1;...;ln : tn} (COMP-STRUCT) FUNn �(t1,...,tn) → t (COMP-FUN) FIGURE 5.7 : Compatibilité entre types de valeurs et statiques [ ] � ([ ], [ ]) (M-EMPTY) Γ � (s, g ) (s, g ) � v : τ τ�t Γ, global x : t � (s, ((x �→ v) :: g )) (M-GLOBAL) Γ � m Γ = (ΓG ,ΓL) Γ� = (ΓG , [x1 : t1,...,xn : tn,R : t]) m � v1 : τ1 τ1 �t1 ... m � vn : τn τn �tn Γ� � Push(m, ((x1 �→ v1),..., (xn �→ vn))) (M-PUSH) Γ = (ΓG ,ΓL) Γ � m m� = Push(m, ((x1 �→ v1),..., (xn �→ vn))) (ΓG , [x1 : t1,...,xn : tn,R : t]) � m� Γ � Cleanup(Pop(m� )) (M-POP) Γ � m m � v : τ τ�t x ∉ Γ Γ,local x : t � Extend(m,x �→ v) (M-DECL) Γ,local x : t � m x ∉ Γ Γ � CleanVar(m − x,x) (M-DECLCLEAN) Γ � m Γ � ϕ : t m � v : τ τ�t m� = m[ϕ ← v] Γ � m� (M-WRITE) FIGURE 5.8 : Compatibilité entre états mémoire et environnements de typage règles définissant cette relation sont données dans la figure 5.8. 5.8 Propriétés du typage On commence par énoncer quelques lemmes utiles dans la démonstration de ces théorèmes. Les démonstrations des lemmes 5.1 et 5.2 sont des analyses de cas laborieuses et sans difficulté ; dans ce cas on n’en donne que des esquisses. Lemme 5.1 (Inversion). À partir d’un jugement de typage, on peut en déduire des informations sur les types de ses sous-expressions. • Constantes • si Γ � n : t, alors t = INT • si Γ � d : t, alors t = FLOAT • si Γ � NULL : t, alors ∃t� ,t = t� ∗5.8. PROPRIÉTÉS DU TYPAGE 73 • si Γ � ( ) : t, alors t = UNIT • Références mémoire : • si Γ � (x) : t, alors x : t ∈ ΓG • si Γ � (n, x) : t, alors x : t ∈ ΓL • si Γ � l v[e] : t, alors Γ � l v : t[ ] et Γ � e : INT • si Γ � l v.lS : t, alors Γ � l v : S • Opérations : • si Γ � � e : t, alors on est dans un des cas suivants : • � ∈ {+,−,∼,!}, t = INT, Γ � e : INT • � ∈ {+.,−.}, t = FLOAT, Γ � e : FLOAT • si Γ � e1 � e2 : t, un des cas suivants se présente : • � ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>}, Γ � e1 : INT, Γ � e2 : INT, t = INT • � ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .}, Γ � e1 : FLOAT, Γ � e2 : FLOAT, t = FLOAT • � ∈ {=,�=}, Γ � e1 : t� , Γ � e2 : t� , EQ(t� ), t = INT • � ∈ {≤,≥,<,>}, t = INT, Γ � e1 : t� , Γ � e2 : t� , t� ∈ {INT, FLOAT} • � ∈ {+p,−p}, ∃t� ,t = t� ∗, Γ � e1 : t� ∗, Γ � e2 : INT • Appel de fonction : si Γ � e(e1,...,en) : t, il existe (t1,...,tn) tels que : � Γ � e : (t1,...,tn) → t ∀i ∈ [1;n],Γ � ei : ti • Fonction : si (ΓG ,ΓL) � fun(a1,...,an){i} : t, alors il existe (t1,...,tn) et t� tels que : � t = (t1,...,tn) → t� (ΓG , [a1 : t1,...,an : tn,R : t� ]) � i • Si Γ � ∗e : t, alors Γ � e : t∗. • Si Γ � l v ← e : t, alors Γ � l v : t et Γ � e : t. • Si Γ � & l v : t, alors il existe t� tel que Γ � l v : t� et t = t� ∗. • Instructions : • Si Γ � i1;i2, alors Γ � i1 et Γ � i2. • Si Γ � e, alors il existe t tel que Γ � e : t. • Si Γ � DECL x = e IN{i}, alors il existe t tel que Γ � e : t et Γ,local x : t � i. • Si Γ � IF(e){it }ELSE{if }, alors Γ � e : INT, Γ � it et Γ � if . • Si Γ � WHILE(e){i}, alors Γ � e : INT et Γ � i. • Si Γ � RETURN(e), alors il existe t tel que Γ � e : t et Γ � R : t. Démonstration (esquisse). Pour chaque forme de jugement de typage, on liste les règles qui peuvent amener à cette conclusion. Il est aussi possible de réaliser l’opération inverse : à partir du type d’une valeur, on peut déterminer sa forme syntaxique. C’est bien sûr uniquement possible pour les valeurs, pas pour n’importe quelle expression (par exemple l’expression x (variable) peut avoir n’importe quel type t dans le contexte Γ = x : t).74 CHAPITRE 5. TYPAGE Lemme 5.2 (Formes canoniques). Il est possible de déterminer la forme syntaxique d’une valeur étant donné son type, comme décrit dans le tableau suivant. Par exemple, d’après la première ligne, si Γ � v : INT, alors v est de la forme n (cf. � figure 4.7, page 44 pour la définition des valeurs). Type de v Forme de v INT n FLOAT d UNIT ( ) t∗ &� ϕ ou NULL t[ ] [v1;...; vn] {l1 : t1;...;ln : tn} {l1 : v1;...;ln : vn} (t1,...,tn) → t fun(a1,...,an){i} Démonstration (esquisse). On procède comme pour le lemme d’inversion : pour chaque forme syntaxique, on fait l’inventaire des règles pouvant arriver à cette dérivation. Lemme 5.3 (Représentabilité). On définit un opérateur de représentation d’un type statique à l’exécution : Repr(INT) = INT Repr(FLOAT) = FLOAT Repr(UNIT) = UNIT Repr(t� ∗) = Repr(t� )∗ Repr(t� [ ]) = Repr(t� )[ ] Repr({l1 : t1;...;ln : tn}) = {l1 : Repr(t1);...;ln : Repr(tn)} Repr((t1,...,tn) → t) = FUNn Supposons que Γ � v : t et Γ � m. On pose τ = Repr(t). Alors m � v : τ et τ�t. Démonstration. On procède par induction sur la forme de t. • INT : D’après le lemme des formes canoniques, v = n. On conclut avec S-INT et COMPGROUND. • FLOAT : Idem avec v = d et S-FLOAT. • UNIT : Idem avec v = ( ) et S-UNIT. • t = t� ∗ : Soient τ� = Repr(t� ) et τ = τ� ∗. D’après le lemme des formes canoniques, deux cas sont possibles : • v = &� ϕ : Par inversion (lemme 5.1), Γ � ϕ : t� . Puisque Γ � m et Γ � ϕ : t� , on obtient par le lemme 5.6 que m[ϕ] est une valeur telle que m � m[ϕ] : τ� où τ� �t� . D’après S-PTR, m � &� ϕ : τ. De plus par COMP-PTR τ�t. • v = NULL : Par induction, τ� �t� . Alors par COMP-PTR, τ ∗�t ∗. En outre, grâce à S-NULL, on obtient m � NULL : τ ∗.5.8. PROPRIÉTÉS DU TYPAGE 75 • t = t� [ ] : Par le lemme des formes canoniques, v = [v�1;...; vn]. Par inversion on obtient que ∀i,Γ � vi : t� . Soient τ� = Repr(t� ) et τ = τ� [ ]. Alors par induction ∀i,m � vi : τ� et τ� � t� . De la première propriété il vient (via SARRAY) m � v : τ, et de la seconde (via COMP-ARRAY) τ�t. • {l1 : t1;...;ln : tn} : Par le lemme des formes canoniques, v = {l1 : v�1;...;ln : vn}. Et par inversion, ∀i,Γ � vi : ti . Soient τi = Repr(ti) et τ = {l1 : τ1;...;ln : τn}. Alors par induction, ∀i,m � vi : τi et τi �ti . On déduit de S-STRUCT que m � v : τ, et de COMP-STRUCT que τ�t. • t = (t1,...,tn) → t� : Par formes canoniques, on a v = fun(a �1,...,an){i}. Soit τ = FUNn : par S-FUN on obtient que m � v : τ. On conclut d’autre part que τ� t grâce à COMP-FUN. Lemme 5.4 (Hauteur des chemins typés). Une valeur typée ne peut jamais pointer au dessus du niveau courant de pile. (H (·) provient de la définition 4.6, page 47). Si m � v : τ, alors H (v) ≤ |m|. Démonstration. On procède par induction sur la forme de v. c�: Alors H (v) = −1. Comme |m| ≥ 0, ce cas est établi. f �: Idem. &� a : On distingue selon la forme de a. Si a = (x), c’est immédiat. Si a = (n,x), alors d’après la forme de v, la dernière règle appliquée dans la dérivation de m � v : τ est S-PTR, et donc m[(n,x)] est une valeur. D’après la définition de a, n ≤ |m|. &� ϕ.l : On procède par induction sur v� = &� ϕ. Comme H (&� ϕ) ≤ |m| et H (&� ϕ.l) = H (&� ϕ), on en déduit que H (&� ϕ.l) ≤ |m|. &� ϕ[n] : Idem. {l1 : v�1;...;ln : vn} : Par induction, ∀i ∈ [1;n],H (vi) ≤ |m|. Donc il en est de même pour leur maximum, et H (v) ≤ |m|. [v�1,..., vn] : Idem. Lemme 5.5 (Accès à des variables bien typées). Soit Adr(ϕ) l’adresse de la variable qui apparaît dans ϕ : Adr(a) = a Adr(ϕ.l) = Adr(ϕ) Adr(ϕ[n]) = Adr(ϕ)76 CHAPITRE 5. TYPAGE Alors, si Γ � m et Γ � ϕ : t, alors Adr(ϕ) est soit une variable globale (x) avec x ∈ dom(ΓG ), soit une variable locale (|m|,x) du plus haut cadre de pile avec x ∈ dom(ΓL). Démonstration. On procède par induction sur la forme de ϕ. • Si ϕ = ϕ� .lS, alors Adr(ϕ) = Adr(ϕ� ), et par inversion Γ � ϕ� : S. On conclut en appliquant l’hypothèse de récurrence à ϕ� . • Si ϕ = ϕ� [n], le cas est similaire. • Si ϕ = a, alors Adr(ϕ) = a. Si a = (x), on a par inversion x : t ∈ ΓG . Si a = (n,x), alors par inversion x : t ∈ ΓL. Il reste à montrer que n = |m|, ce qui peut se prouver par induction sur la dérivation de Γ � m, en notant que dom(ΓL) coincide toujours avec le dernier niveau de pile. Cette étape est ici admise. Lemme 5.6 (Accès à une mémoire bien typée). Si Γ � m et Γ � ϕ : t, alors m[ϕ] est une valeur v et m � v : τ où τ�t. Démonstration. À partir du lemme 5.5, on prouve celui-ci par induction sur une dérivation de Γ � m. M-EMPTY : ΓG = ΓL = [ ], la prémisse Γ � ϕ : t est donc impossible à satisfaire. M-GLOBAL : Soient ϕ tel que Γ, global x : t� � ϕ : t et m� = (s, ((x �→ v) :: g )). Alors la variable référencée par ϕ est soit (x), soit (y) avec y ∈ dom(ΓG ), soit (|m|, y) avec y ∈ dom(ΓL). Dans le premier cas, m� [ϕ] = v, ce qui permet de conclure. Dans les autres cas, m� [ϕ] = m[ϕ], ce qui nous permet de conclure grâce à l’hypothèse d’induction. M-DECL : On part de Γ � ϕ : t� . Alors Adr(ϕ) est soit la locale x, soit une autre variable locale, soit une globale. Dans le premier cas, m� [ϕ] = v et les prémisses nous permettent de conclure. Dans tous les autres cas, m� [ϕ] = m[ϕ] et on applique l’hypothèse d’induction. M-DECLCLEAN : On suppose que Γ � ϕ : t� et m� = CleanVar(m − x,x). Alors Γ,local x : t � ϕ : t� par affaiblissement. On peut donc appliquer l’hypothèse d’induction : m[ϕ] = v où m � v : τ� avec τ� �t� . On distingue alors selon la forme de v. Si v = &� ϕ� où Adr(ϕ� ) = (|m|,x), alors m� [ϕ] = NULL par l’opération CleanVar(·,·). Le type τ� étant un type pointeur par le lemme 5.2, on peut conclure. Dans les autres cas m[ϕ] = m� [ϕ] ce qui termine ce cas. M-PUSH : On procède d’une manière similaire. ϕ peut faire référence soit à un des xi , auquel cas la valeur vi convient, soit à une variable globale, auquel cas on applique l’hypothèse de récurrence. M-POP : On part de Γ � m�� où m�� = Cleanup(Pop(m� )). Deux cas se produisent selon la forme de Adr(ϕ). • Soit Adr(ϕ) = (x) avec x ∈ dom(ΓG ), alors Γ� � ϕ : t où Γ� = (ΓG , [x1 : t1,...,xn : tn,R : t]). On applique alors l’hypothèse de récurrence en partant du jugement Γ � m� : il vient que m� [ϕ] = v où m � v : τ� avec τ� � t� . Comme H (v) ≤ |m� | (lemme 5.4), deux cas peuvent se produire :5.9. PROGRÈS ET PRÉSERVATION 77 • Si H (v) = |m� |, alors m��[ϕ] = NULL et on a bien la compatibilité mémoire (l’argument est similaire au cas DECL-CLEAN). • Sinon, m��[ϕ] = m� [ϕ] et on conclut directement. • Soit Adr(ϕ) = (|m��|,x). On procède alors de la mème manière sauf qu’on invoque alors le cas d’induction sur Γ � m. M-WRITE : On part de Γ � m� où m� = m[ϕ ← v], et on suppose que Γ � ϕ� : t� . Si ϕ = ϕ� : alors il suffit d’appliquer GETPUT à la lentille Φ : m[ϕ ← m[ϕ]] = m, ce qui donne directement la conclusion. Si ϕ �= ϕ� : Γ � ϕ� : t� donc Adr(ϕ� ) est soit une locale soit une globale de m� . Donc m� [ϕ� ] = m[ϕ� ] et on conclut grâce à l’hypothèse d’induction. 5.9 Progrès et préservation Ces lemmes étant établis, on énonce maintenant le théorème de progrès. Contrairement aux langages où tout est expression, il faut traiter séparément les trois constructions principales de SAFESPEAK : les expressions, les valeurs gauches et les instructions. Celles-ci sont mutuellement dépendantes car : • la définition d’une fonction par un bloc est une expression ; • une expression est un cas particulier d’instruction ; • une valeur gauche peut convenir une expression en indice de tableau ; • une valeur gauche est un cas particulier d’expression. Théorème 5.1 (Progrès). Supposons que Γ � i. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants est vrai : • i = PASS • ∃v,i = RETURN(v) • ∃(i� ,m� ),〈i,m〉 → 〈i� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈i,m〉 → Ω � � � Supposons que Γ � e : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants est vrai : • ∃v �= Ω,e = v • ∃(e� ,m� ),〈e,m〉 → 〈e� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈e,m〉 → Ω � � � Supposons que Γ � l v : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants est vrai : • ∃ϕ,l v = ϕ • ∃(l v� ,m� ),〈l v,m〉 → 〈l v� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈l v,m〉 → Ω C’est-à-dire, soit : • l’entité (instruction, expression ou valeur gauche) est complètement évaluée.78 CHAPITRE 5. TYPAGE • un pas d’évaluation est possible. • une erreur de division, tableau ou pointeur se produit. La preuve du théorème 5.1 se trouve en annexe D.2. Théorème 5.2 (Préservation). Soit Γ un environnement de typage et m un état mémoire tels que Γ � m. Alors : • Si Γ � l v : t et 〈l v,m〉 → 〈ϕ,m� 〉, alors Γ � Cleanup(m� ) et m� �Φ ϕ : τ où τ�t. • Si Γ � l v : t et 〈l v,m〉 → 〈l v� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � l v� : t. • Si Γ � e : t et 〈e,m〉 → 〈v,m� 〉, alors Γ � Cleanup(m� ) et m� � v : τ où τ�t. • Si Γ � e : t et 〈e,m〉 → 〈e� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � e� : t. • Si Γ � i et 〈i,m〉 → 〈i� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � i� . Autrement dit, si une construction est typable, alors un pas d’évaluation ne modifie pas son type et préserve le typage de la mémoire. Remarque Dans la formulation classique de ce théorème, on indique que Γ � m implique Γ � m� . Ici, la conclusion est moins forte en indiquant seulement que Γ � Cleanup(m� ). Cela indique que la compatibilité mémoire est établie mais peut localement introduire des pointeurs fous. En fait, comme une étape de Cleanup(·) est faite après chaque appel de fonction et chaque déclaration, la propriété classique est vraie mais uniquement sur un plus grand pas d’exécution. La preuve de ce théorème se trouve en annexe D.3. Cela établit qu’aucun terme ne reste « bloqué » parce qu’aucune règle ne s’applique, et que la sémantique respecte le typage. En quelque sorte, les types sont un contrat entre les expressions et les fonctions : si leur évaluation converge, alors une valeur du type inféré sera produite. Enfin, on donne une version de ces propriétés pour les phrases de programme. Théorème 5.3 (Progrès pour les phrases). Soit Γ un environnement de typage, m un état mé- moire et p une phrase de programme. Supposons que Γ � p → Γ� et Γ � m. On suppose en outre que l’évaluation de p termine. Alors ∃m� .m � p → m� . Démonstration. Ici il n’y a pas de difficulté puisque la contrainte (forte) de terminaison se lit 〈e,m〉 → 〈v� ,m� 〉 où e est l’expression apparaissant dans p. Selon la forme de p, il suffit alors d’appliquer la règle ET-EXP ou ET-VAR. Théorème 5.4 (Préservation pour les phrases). On suppose que les trois propriétés suivantes sont vérifiées :    Γ � m Γ � p → Γ� m � p → m� Alors Γ� � m� . Démonstration. On distingue selon la dernière règle appliquée dans la dérivation de m � p → m� .5.9. PROGRÈS ET PRÉSERVATION 79 ET-EXP : La dernière règle appliquée pour dériver Γ � p → Γ� est donc T-EXP. D’après les prémisses de ces deux règles, on a donc Γ � e : t et 〈e,m〉 → 〈v,m� 〉. Alors, d’après le théorème de préservation, Γ � m� . ET-VAR : Ici, la dérivation de Γ � p → Γ� termine par T-VAR. D’après leurs prémisses, on a donc : Γ � e : t, Γ� = Γ, global x : t, et m�� = (s, (x �→ v) :: g ) où (s, g ) = m� (on cherche à prouver que Γ� � m��). En appliquant le théorème de préservation, on obtient que Γ � v : t et Γ � m� . D’après le lemme 5.3, il existe τ tel que m� � v : τ où τ�t. On peut alors appliquer M-GLOBAL qui nous donne que Γ� � m��. Conclusion En ajoutant un système de types statiques à SAFESPEAK, on peut calculer à la compilation la forme des valeurs produites par chaque expression. Pour ce faire, on a défini un ensemble de règles de typage (regroupées dans l’annexe C) à appliquer selon la forme de celle-ci. Si on considère des programmes qui sont seulement syntaxiquement corrects, on ne peut rien prédire sur leur exécution. Par exemple, fun(x){PASS}+1 est une expression correcte mais pour laquelle il n’y a pas de règle d’évaluation qui s’applique. En ajoutant un système de types, les propriétés de sûreté établies dans ce chapitre assurent que les termes peuvent être évalués, et que les valeurs produites sont en accord avec les types donnés aux différentes parties du programme. Cela permet surtout de s’assurer que les programmes ne peuvent provoquer une erreur d’exécution que dans certains cas particuliers, comme les divisions ou les accès aux tableaux. À l’issue de ce chapitre, on a donc un langage impératif sain pour bâtir des analyses de typage, ce que nous allons faire dans le chapitre suivant.C H A P I T R E 6 EXTENSIONS DE TYPAGE Nous venons de définir un système de types sûrs dans le chapitre 5. Cela permet de mettre en relation les types des expressions avec les valeurs qui leur seront associées. Cela permet une forme d’analyse de flot : si peu de constructions permettent de créer des valeurs d’un type t, alors toutes les valeurs de type t proviennent de ces « sources ». On se propose ici d’enrichir le système de types de plusieurs extensions permettant d’explorer cette idée, en ajoutant de la « signification » dans les types de données des programmes. Ces extensions permettront de détecter des erreurs de programmation communes, appuyées sur des exemples réels. Cela revient à introduire une séparation entre le type des données et sa représentation, c’est-à-dire définir un type abstrait. Dans un système d’exploitation, les pointeurs utilisateur sont en fait des pointeurs classiques déguisés, pour lesquels on interdit l’opérateur de déré- férencement. Cette technique est en fait générique : on peut également l’appliquer à certains types d’entiers. En C, il est commun d’utiliser des int pour tout et n’importe quoi : pour des entiers bien sûr (au sens de Z), mais aussi comme identificateurs pour lesquels les opérations usuelles comme l’addition n’ont pas de sens. Par exemple, sous Linux, l’opération d’ouverture de fichier renvoie un entier, dit descripteur de fichier, qui identifie ce fichier pour ce processus. Le langage autorise donc par exemple de multiplier entre eux deux descripteurs de fichiers, mais le résultat n’a pas de raison a priori d’être un descripteur de fichier valide. En n’offrant pas cette distinction, le langage C permet d’écrire du code qui peut s’exé- cuter mais dont la sémantique n’est, quelque part, pas bien fondée. En effet, le système de types de C est trop primitif pour pouvoir garantir une véritable isolation entre deux types de même représentation : il n’y a pas de types abstraits. Certes, typedef permet d’introduire un nouveau nom pour un type, mais ce n’est qu’un raccourci syntaxique. Le compilateur ne peut en effet pas considérer un programme sans avoir la définition quasi-complète des types qui y apparaissent. La seule exception concerne les pointeurs sur structures : si on ne fait que les affecter, il n’est pas nécessaire de connaître la taille ni la disposition de la structure ; donc la définition peut ne pas être visible. Cette technique, connue sous le nom de pointeurs opaques, n’est pas applicable aux autres types. En ajoutant une couche de typage, on interdit ces opérations à la compilation. Cela permet deux choses : pour le code déjà écrit, de détecter et corriger les manipulations dangereuses ; et, pour le nouveau code, de s’assurer qu’il est correct. Par exemple, si on écrit un éditeur de texte, on peut éviter de nombreuses erreurs de programmation en définissant un type « indice de ligne » et un type « indice de colonne » incompatibles entre eux. Un premier exemple permet de distinguer plusieurs utilisations des entiers, selon s’ils 8182 CHAPITRE 6. EXTENSIONS DE TYPAGE sont utilisés comme entiers arithmétiques ou ensemble de bits. Cela permet de détecter une erreur courante qui consiste à mélanger les opérateurs logiques et bit à bit. Ensuite, on étend de manière indépendante le système de types, cette fois au niveau des pointeurs. Plus précisément, dans le contexte des systèmes d’exploitation, on introduit une différence entre les pointeurs dont la valeur est contrôlée par l’utilisateur et ceux dont elle ne l’est pas. 6.1 Exemple préliminaire : les entiers utilisés comme bitmasks Dans le langage C, les types de données décrivent uniquement l’agencement en mé- moire des valeurs. Ils n’ont pas de signification plus sémantique permettant d’exprimer ce que les données représentent. Par exemple, dans un programme manipulant des dates, on sera amené à manipuler des numéros de mois et d’années, représentés par des types entiers. Le langage C permet de définir des nouveaux types : typedef int month_t; typedef int year_t; Cependant, rien ne distingue le nouveau type de l’ancien. Il ne s’agit que d’une aide à la documentation. Dans cet exemple, month_t et year_t sont tous les deux des nouveaux noms pour le type int ; donc ils sont en fait compatibles. Le compilateur ne peut donc pas détecter qu’on utilise un numéro de mois là où un numéro d’année était attendu (ou vice versa). Cet idiome est commun en C. On manipule notamment certaines données abstraites par des clés entières, et un typedef particulier permet de désigner celles-ci. Par exemple sous Linux, les numéros de processus sont des indices dans la table de processus interne au noyau, et on y accède par une valeur de type pid_t. De même, les utilisateurs sont représentés par un nombre entier du type uid_t. Un autre idiome est répandu : l’utilisation d’entiers comme représentation d’un ensemble de booléens. En effet, un nombre a = �N−1 i=0 ai 2i peut s’interpréter comme la liste d’indices de ses bits égaux à 1 : {i ∈ [0;N − 1]/ai = 1}. Un entier de 32 bits peut donc représenter une combinaison de 32 options indépendantes. C’est de cette manière que fonctionne l’interface qui permet d’ouvrir un fichier sous Unix (figure 6.1). Le paramètre flags est un entier qui encode les options liées à l’ouverture du fichier. On précise son mode (lecture, écriture ou les deux) par les bits 1 et 2 ; s’il faut créer le fichier ou non s’il n’existe pas par le bit 7 ; si dans ce cas il doit être effacé par le bit 8, etc. On obtient le paramètre complet en réalisant un « ou » bit à bit entre des constantes. Le paramètre mode encode de la même manière les permissions que doit avoir le fichier créé, le cas échéant (mode_t désigne en fait unsigned int). int open(const char *pathname, int flags, mode_t mode); int creat(const char *pathname, mode_t mode); FIGURE 6.1 : Interface permettant d’ouvrir un fichier sous Unix Ces fonctions retournent un entier, qui est un descripteur de fichier. Il correspond à un indice numérique dans une table interne au processus. Par exemple, 0 désigne son entrée standard, 1 sa sortie standard, et 2 son flux d’erreur standard. On identifie donc au moins trois utilisations du type int :6.1. EXEMPLE PRÉLIMINAIRE : LES ENTIERS UTILISÉS COMME BITMASKS 83 • entier : c’est l’utilisation classique pour représenter des valeurs numériques. Toutes les opérations sont possibles. • bitmask : on utilise un entier comme ensemble de bits. Seules les opérations bit à bit ont du sens. • entier opaque : on utilise un entier de manière purement abstraite. C’est l’exemple des descripteurs de fichier. Ces utilisations du type n’ont rien à voir ; il faudrait donc empêcher d’utiliser un descripteur de fichier comme un mode, et vice-versa. De même, aucun opérateur n’a de sens sur les descripteurs de fichier, mais l’opérateur | du « ou » bit à bit doit rester possible pour les modes. On décrit ici une technique de typage pour détecter et interdire ces mauvaises utilisations en proposant une version « bien typée » de la fonction open. Plus précisément, on donne à ses deuxième et troisième arguments (respectivement flags et mode) le nouveau type BITS qui correspond aux entiers utilisés comme bitmasks. Le type de retour n’est pas modifié (il reste INT), mais on décrit comment il est possible de rendre ce type opaque. 6.1.1 Modifications On commence par ajouter deux types : d’une part BITS bien sûr, mais également CHAR qui apparaît dans les chaînes de caractères. On ne spécifie pas plus ce dernier mais on suppose qu’il existe des littéraux de chaînes qui retournent un pointeur vers le premier élément d’un tableaux de caractères. Pour rester compatible avec C, on suppose qu’un caractère nul ’\0’ est inséré à la fin de la chaîne. On ajoute ces chaînes uniquement dans le but de pouvoir représenter les noms de fichiers. Au niveau des valeurs, les entiers utilisés comme bitmasks sont représentés par des valeurs entières classiques n�. En particulier, on n’ajoute pas de nouveau type sémantique, mais on ajoute une règle de compatibilité entre le type de valeurs INT et le type statique BITS (cela signifie qu’une valeur de type BITS est représentée par un INT en mémoire, figure 6.2). Par ailleurs, on change le type des « constructeurs » (O_RDONLY, O_RDWR, O_APPEND, . . . ) et du « consommateur » open (figure 6.3). Type t ::= ... | CHAR Caractère | BITS Entier utilisé comme bitmask INT�BITS (COMP-BITS) FIGURE 6.2 : Ajouts liés aux entiers utilisés comme bitmasks Pour que les opérations bit à bit puissent s’appliquer aux bitmasks, on ajoute aux règles s’appliquant à INT les règles suivantes. Cela revient à permettre plusieurs types pour l’opérateur ∼, mais la sémantique d’exécution est la même quel que soit le type, car BITS et INT sont représentés de la même manière. � ∈ { | , & , ^ } Γ � e1 : BITS Γ � e2 : BITS Γ � e1 � e2 : BITS (OP-BITS) Γ � e : BITS Γ �∼ e : BITS (NOT-BITS)84 CHAPITRE 6. EXTENSIONS DE TYPAGE [ ] � O_RDONLY : BITS [ ] � O_RDWR : BITS [ ] � O_APPEND : BITS [ ] � open : (CHAR ∗, BITS) → INT FIGURE 6.3 : Nouvelles valeurs liées aux bitmasks Il reste à permettre d’utiliser les bitmasks dans les contextes où on attend un entier. Par exemple, pour écrire IF(x & 0x80){...}ELSE{...} (test du bit numéro 7). On veut donc exprimer que « un BITS est un INT ». Cette relation entre différents types d’entier correspond à un cas particulier de sous-typage. On ajoute la règle de subsomption suivante. Elle permet d’utiliser une expression de type BITS là où une expression de type INT est attendue. Γ � e : BITS Γ � e : INT (SUB-BITSINT) Cela modifie légèrement l’implantation de l’inférence de types. Le type d’une expression utilisée comme opérande de l’opérateur + n’est donc pas a priori de type INT, mais BITS ou INT. Cela implique aussi qu’on peut additionner un BITS et un INT pour obtenir un INT. Les expressions de la forme fun(x, y){RETURN(x|y)} peuvent donc accepter plusieurs types. Pour l’inférence, cela correspondra à une inconnue de type. Si celle-ci n’est pas résolue à la fin de l’inférence (par exemple si cette fonction n’est pas appelée), une erreur est levée. C’est une limitation du monomorphisme. Ainsi, si Γ � e : BITS, on a par exemple Γ � ! e : INT. On rappelle que la règle permettant de typer ! est inchangée et reste la suivante : � ∈ {∼,!} Γ � e : INT Γ � � e : INT (UNOP-NOT) 6.1.2 Exemple : ! x & y Les nombreux opérateurs de C (repris en SAFESPEAK) posent plusieurs problèmes : • il sont nombreux et il est facile de confondre && avec &, ou ! avec ∼ ; • il y a un opérateur « ou exclusif » bit à bit (^) mais pas d’équivalent logique ; • la priorité des opérateurs semble parfois arbitraire. Par exemple, les opérateurs de dé- calage sont plus prioritaires que les additions, donc x � 2 + 1 est interprété comme (x � 2)+1. Le premier et le dernier point permettent d’expliquer une erreur courante : celle qui consiste à écrire ! x & y au lieu de ! (x & y). En effet, la première expression est équivalente à (! x) & y. Comme ! x vaut 0 ou 1, l’expression résultante vaut y & 1 si x = 0, ou 0 sinon. Il s’agit probablement d’une erreur de programmation. L’alternative ! (x & y) a plus de sens : elle vaut 0 si x et y ont un bit en commun, 1 sinon.6.2. ANALYSE DE PROVENANCE DE POINTEURS 85 On vérifie enfin que la première n’est pas bien typée alors que la seconde l’est. Dans les deux cas suivants on se place dans un environnement Γ comportant deux variables globales x et y de type BITS. Alors (! x)&y n’est pas bien typée. En effet, Γ � ! x : INT et la seule règle qui s’applique à l’opérateur & ne peut pas s’appliquer. En revanche la seconde est bien typée (figure 6.4). Γ = ([x �→ BITS, y �→ BITS], [ ]) Γ � x : BITS Γ � y : BITS Γ � x & y : BITS (OP-BITS) Γ � x & y : INT (SUB-BITSINT) Γ � ! (x & y) : INT (UNOP-NOT) FIGURE 6.4 : Dérivation montrant que ! (x & y) est bien typée Cet exemple préliminaire permet de voir en quoi SAFESPEAK est adapté à des analyses de typage légères. Puisque le typage est sûr, on en déduit que les valeurs d’un certain type ne peuvent être créées que par un certain nombre de constructeurs. Par exemple ici les bitmasks ne proviennent que de combinaisons de constantes. C’est précisément cette idée de détection de source qui est au cœur de l’analyse suivante. 6.2 Analyse de provenance de pointeurs Jusqu’ici SAFESPEAK est un langage impératif généraliste, ne prenant pas en compte les spécificités de l’adressage utilisé dans les systèmes d’exploitation. Dans cette section, on commence par l’étendre en ajoutant des constructions modélisant les variables présentes dans l’espace utilisateur (cf. chapitre 2). Pour accéder à celles-ci, on ajoute un opérateur de déréférencement sûr qui vérifie à l’exécution que l’invariant suivant est respecté : Les pointeurs dont la valeur est contrôlée par l’utilisateur pointent vers l’espace utilisateur. La terminologie mérite d’être détaillée : Un pointeur contrôlé par l’utilisateur, ou pointeur utilisateur, est une référence mémoire dont la valeur est modifiable par le code utilisateur (opposé au code noyau, que nous analysons ici). Ceci correspond à des données provenant de l’extérieur du système vérifié. C’est une propriété statique, qui peut être déterminée à la compilation à partir de considérations syntaxiques. Par exemple, l’adresse d’une variable locale au sein de code noyau est toujours considérée comme étant contrôlée par le noyau. Un pointeur pointant vers l’espace utilisateur fait référence à une variable allouée en espace utilisateur. Cela veut dire qu’y accéder ne risque pas de mettre en péril l’isolation du noyau en faisant fuiter des informations confidentielles ou en déjouant son intégrité. Cette propriété est dynamique : un pointeur utilisateur peut a priori pointer vers l’espace utilisateur, ou non. Pour prouver que l’invariant précédent est bien respecté, on procède en plusieurs étapes. Tout d’abord, on définit une nouvelle erreur Ωsec (pour « sécurité »), déclenchée lorsqu’un pointeur contrôlé par l’utilisateur et pointant vers le noyau est déréférencé (le cas que86 CHAPITRE 6. EXTENSIONS DE TYPAGE l’on cherche à éviter). Il est important de noter que ce cas d’erreur est « virtuel », c’est-à-dire qu’on l’ajoute à la sémantique pour pouvoir le détecter facilement comme un cas d’erreur, mais, dans une sémantique de plus bas niveau, comme en C, l’erreur ne serait pas déclenchée. D’un point de vue opérationnel, cela équivaut à ajouter un test dynamique à chaque déréférencement, ce qui est sûr mais se paye en performances. Ajouter ce cas d’erreur virtuel dans la sémantique d’évaluation permet de transformer un problème de sécurité (empêcher les fuites d’information) en problème de sûreté (empêcher les erreurs à l’exécution). Ensuite, on montre qu’avec cet ajout, si on étend naïvement le système de types en donnant le même type aux pointeurs contrôlés par l’utilisateur et le noyau, le théorème de progrès (5.1) n’est plus valable. Cela signifie que le système de types classique présenté dans le chapitre 5 ne suffit pas à capturer les propriétés de sécurité que nous voulons interdire. L’étape suivante est d’étendre, à son tour, le système de types de SAFESPEAK en distinguant les types des pointeurs contrôlés par l’utilisateur des pointeurs contrôlés par le noyau. Puisqu’on veut interdire le déréférencement des premiers par l’opérateur *, on introduit les constructions copy_from_user et copy_to_user qui réaliseront le déréférencement sûr de ces pointeurs. Enfin, une fois ces modifications faites, on prouve que les propriétés de progrès et de préservation sont rétablies. 6.2.1 Extensions noyau pour SAFESPEAK On ajoute à SAFESPEAK la notion de valeur provenant de l’espace utilisateur. Pour marquer la séparation entre les deux espaces d’adressage, on ajoute une construction ϕ ::= ♦� ϕ� . Le chemin interne ϕ� désigne une variable classique (un pointeur noyau) et l’opérateur ♦� · permet de l’interpréter comme un pointeur vers l’espace utilisateur. En quelque sorte, on ne classifie pas les valeurs selon la variable pointée mais selon la construction du pointeur. Remarquons qu’on n’introduit pas de sous-typage : les pointeurs noyau ne peuvent être utilisés qu’en tant que pointeurs noyau, et les pointeurs utilisateur qu’en tant que pointeurs utilisateur. En plus du déréférencement par * (qui devra donc renvoyer Ωsec pour les valeurs de la forme ♦� ϕ� ), il faut aussi ajouter des constructions de lecture et d’écriture à travers les pointeurs utilisateur. Ceci sera fait sous forme de deux fonctions, copy_from_user et copy_to_user. Celles-ci prennent deux pointeurs en paramètre et renvoient un booléen indiquant si la copie a pu être faite (si le paramètre contrôlé par l’utilisateur pointe en espace noyau, les fonctions ne font pas la copie et signalent l’erreur). Illustrons ceci par un exemple. Imaginons un appel système fictif qui renvoie la version du noyau, en remplissant par pointeur une structure contenant les champs entiers major, minor et patch (un équivalent dans Linux est l’appel système uname()). Celui-ci peut être alors écrit comme dans la figure 6.5. Une fois la structure noyau v remplie, il faut la copier vers l’espace utilisateur. La fonction copy_to_user va réaliser cette copie (de la même manière qu’avec un memcpy()), mais après avoir testé dynamiquement que p pointe en espace utilisateur (dans le cas contraire, la copie n’est pas faite). On peut remarquer que, contrairement aux fonctions présentes dans le noyau Linux, les fonctions copy_from_user et copy_to_user n’ont pas de paramètre indiquant la taille à copier. Cela est dû au fait que le modèle mémoire de SAFESPEAK est de plus haut niveau. L’information de taille est déjà présente dans chaque valeur. Une autre remarque à faire est qu’il n’y a pas de manière de copier des données de l’espace utilisateur vers l’espace utilisateur. Il est nécessaire de passer par l’espace noyau. La raison est que, puisqu’il faut réaliser deux tests dynamiques, les erreurs peuvent arriver à ces6.2. ANALYSE DE PROVENANCE DE POINTEURS 87 sys_getver = fun(p){ DECL v = { major : 3;minor : 14;patch : 15 } IN copy_to_user(p,&v) } FIGURE 6.5 : Implantation d’un appel système qui remplit une structure par pointeur Expressions e ::= ... | ♦ l v Adresse utilisateur | copy_from_user(ed ,es) Lecture depuis l’espace utilisateur | copy_to_user(ed ,es) Écriture vers l’espace utilisateur Contextes C ::= ... | ♦ C | copy_from_user(C,e) | copy_from_user(v,C) | copy_to_user(C,e) | copy_to_user(v,C) Chemins ϕ ::= ... | ♦� ϕ Pointeur utilisateur Erreurs Ω ::= ... | Ωsec Erreur de sécurité FIGURE 6.6 : Ajouts liés aux pointeurs utilisateur (par rapport à l’interprète du chapitre 4) deux endroits. Plutôt que de proposer un opérateur qui réalise cette copie, on laisse le programmeur faire les deux copies manuellement. On commence donc par ajouter aux instructions des constructions copy_to_user(·,·) et copy_from_user(·,·) de copie sûre. copy_from_user(pk ,pu) copie la valeur pointée par pu (qui se trouve en espace utilisateur) à l’emplacement mémoire pointé par pk (en espace noyau). copy_to_user(pu,pk ) réalise l’opération inverse, en copiant la valeur pointée par pk (en espace noyau) à l’emplacement mémoire pointé par pu (en espace utilisateur). Afin de leur donner une sémantique, il faut étendre l’ensemble des valeurs pointeur ϕ aux constructions de la forme ♦� ϕ� . Pour créer des termes s’évaluant en de telles valeurs, il faut une construction syntaxique ♦ e telle que, si e s’évalue en &� ϕ, ♦ e s’évalue en &� ♦� ϕ. Cela demande 2 autres ajouts : un nouveau contexte d’évaluation ♦ C et une règle d’évaluation. Enfin, on ajoute une nouvelle erreur Ωsec à déclencher lorsqu’on déréférence directement un pointeur utilisateur. Ces étapes sont résumées dans la figure 6.6. En résumé, on a deux constructions pour créer des pointeurs à partir d’une valeur gauche :88 CHAPITRE 6. EXTENSIONS DE TYPAGE & · crée un pointeur noyau, et ♦ · crée un pointeur utilisateur. Seule la première est faite pour être utilisée dans le code à analyser. La seconde sert uniquement à modéliser les points d’entrée du noyau. Par exemple, la fonction sys_getver de la figure 6.5 peut être appelée par un utilisateur de la manière décrite dans la figure 6.7. DECL v = { major : 0;minor : 0;patch : 0 } IN sys_getver(♦ v) FIGURE 6.7 : Appel de la fonction sys_getver de la figure 6.5 6.2.2 Extensions sémantiques En ce qui concerne l’évaluation des expressions ♦ ·, on ajoute la règle suivante : 〈♦ ϕ,m〉 → 〈& ( � ♦� ϕ),m〉 (PHI-USER) Dans & ( � ♦� ϕ), l’opérateur &� · indique que la valeur créée est une référence mémoire. Cette référence mémoire, ♦� ϕ, est contrôlée par l’utilisateur. C’est ce qu’indique le constructeur ♦� · Cette règle semble asymétrique. C’est lié au fait qu’habituellement, les valeurs pointeurs (de la forme &� Φ) sont crées en utilisant la règle CTX avec l’opérateur &. Ici une expression crée une valeur pointeur, il faut donc y insérer un &. En effet, � ♦� · n’est qu’une transformation entre chemins, pas une manière de construire une valeur à partir d’un chemin comme &. � Ensuite, il est nécessaire d’adapter les règles d’accès à la mémoire pour déclencher une erreur Ωsec en cas de déréférencement d’un pointeur utilisateur. Les accès mémoire en lecture proviennent de la règle EXP-LV et ceux en lecture, de la règle EXP-SET, rappellées ici : 〈ϕ,m〉 → 〈m[ϕ]Φ,m〉 (EXP-LV ) 〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉 (EXP-SET) Les accès à la mémoire sont en effet faits par le biais de la lentille Φ. Il suffit donc d’adapter sa définition (page 52) de celle-ci en rajoutant les cas suivant : getΦ(♦� ϕ) = Ωsec putΦ(♦� ϕ, v) = Ωsec Enfin, il est nécessaire de donner une sémantique aux fonctions copy_from_user et copy_to_user. L’idée est que celles-ci testent dynamiquement la valeur du paramètre contrôlé par l’utilisateur afin de vérifier que celui-ci pointe vers l’espace utilisateur (c’est- à-dire, qu’il est de la forme ♦� ϕ). Deux cas peuvent se produire. Soit la partie à vérifier a la forme ♦� ϕ� , soit non (et dans ce cas �ϕ� ,ϕ = ♦� ϕ� ). Dans le premier cas (règles USER-*-OK), alors la copie est faite et l’opération de copie retourne la valeur entière 0. Dans le second (règles USER-*-ERR), aucune copie n’est faite et la valeur −1 est retournée. Ce comportement est calé sur celui des fonctions copy_{from,to}_user du noyau Linux : en cas de succès elles renvoient 0, et en cas d’erreur -EFAULT (= −14).6.2. ANALYSE DE PROVENANCE DE POINTEURS 89 v = m[ϕs]Φ m� = m[ϕd ← v]Φ 〈copy_from_user(&� ϕd ,& ( � ♦� ϕs)),m〉 → 〈0,m� 〉 (USER-GET-OK) � ϕs.ϕ = ♦� ϕs 〈copy_from_user(&� ϕd ,&� ϕ),m〉 → 〈−14,m〉 (USER-GET-ERR) v = m[ϕs]Φ m� = m[ϕd ← v]Φ 〈copy_to_user(& ( � ♦� ϕd ),&� ϕs),m〉 → 〈0,m� 〉 (USER-PUT-OK) � ϕd .ϕ = ♦� ϕd 〈copy_to_user(&� ϕ,&� ϕs),m〉 → 〈−14,m〉 (USER-PUT-ERR) Ces règles sont à appliquer en priorité de la règle d’appel de fonction classique, puisqu’il s’agit d’élements de syntaxe différents. En effet ces « fonctions » ne sont pas implantables directement en SAFESPEAK, puisqu’il n’y a pas par exemple d’opérateur permettant d’extraire ϕ depuis une valeur ♦� ϕ. L’opération en « boîte noire » de ces deux fonctions permet d’assurer que l’accès à l’espace utilisateur est toujours couplé à un test dynamique. 6.2.3 Insuffisance des types simples Étant donné SAFESPEAK augmenté de cette extension sémantique, on peut étendre naï- vement le système de types avec la règle suivante : Γ � l v : t Γ � ♦ l v : t ∗ (ADDR-USER-IGNORE) Cette règle est compatible avec l’extension, sauf qu’elle introduit des termes qui sont bien typables mais dont l’évaluation provoque une erreur Ωsec ∉ {Ωd i v ,Ωar r ay ,Ωp t r }, violant ainsi le théorème 5.1. Posons :    e = ∗♦ x Γ = x : INT m = ([[x �→ 0]], [ ]) Les hypothèses du théorème de progrès sont bien vérifiées, mais cependant la conclusion n’est pas vraie : • On a bien Γ � m. En effet : [ ] � ([ ], [ ]) (M-EMPTY) [ ] � 0 : INT INT�INT x : INT � ([[x �→ 0]], [ ]) (M-PUSH) • e est bien typée sous Γ :90 CHAPITRE 6. EXTENSIONS DE TYPAGE x : INT ∈ Γ Γ � x : INT (LV-VAR) Γ � &x : INT∗ (LV-DEREF) Γ � ♦ x : INT∗ (ADDR-USER-IGNORE) Γ � ∗♦ x : INT (LV-DEREF) • L’évaluation de e sous m provoque une erreur différente de Ωd i v , Ωar r ay , ou Ωp t r : m[♦� x] = Ωsec 〈∗♦ x,m〉 → 〈Ωsec ,m〉 (EXP-LV ) 〈Ωsec ,m〉 → Ωsec (EVAL-ERR) 〈e,m〉 → Ωsec Cela montre que le typage n’apporte plus de garantie de sûreté sur l’exécution : le système de types naïvement étendu par une règle comme ADDR-USER-IGNORE n’est pas en adéquation avec les extensions présentées dans la section 6.2.1. Il faut donc raffiner les règles de typage pour interdire ce cas. 6.2.4 Extensions du système de types On présente ici un système de types plus expressif permettant de capturer les extensions de sémantique. In fine, cela permettra de prouver le théorème 6.1 qui est l’équivalent du théorème 5.1 mais pour le nouveau jugement de typage. Définir un nouveau système de types revient à étendre le jugement de typage · � · : ·, en modifiant certaines règles et en en ajoutant d’autres. Naturellement, la plupart des diffé- rences porteront sur le traitement des pointeurs. Pointeurs utilisateur Le changement clef est l’ajout de pointeurs utilisateur. En plus des types pointeurs habituels t ∗, on ajoute des types pointeurs utilisateur t @. La différence entre les deux représente qui contrôle leur valeur (section 2.4). Les différences sont les suivantes (figure 6.8) : • Les types « t ∗ » s’appliquent aux pointeurs contrôlés par le noyau. Par exemple, prendre l’adresse d’un objet de la pile noyau donne un pointeur noyau. Type t ::= ... | t @ Pointeur utilisateur Type de valeur τ ::= ... | τ @ Pointeur utilisateur FIGURE 6.8 : Ajouts liés aux pointeurs utilisateur (par rapport aux figures 5.2 et 5.5)6.2. ANALYSE DE PROVENANCE DE POINTEURS 91 • Les types « t @ », quant à eux, s’appliquent aux pointeurs qui proviennent de l’espace utilisateur. Ces pointeurs proviennent toujours d’interfaces particulières, comme les appels système ou les paramètres passés aux implantations de la fonction ioctl. L’ensemble des notations est résumé dans le tableau suivant : Noyau Utilisateur Syntaxe & x ♦ x Valeur & ( � x) &� ♦� (x) Type t ∗ t @ Accès ∗ x copy_*_user Puisqu’on s’intéresse à la provenance des pointeurs, détaillons les règles qui créent, manipulent et utilisent des pointeurs. Sources de pointeurs La source principale de pointeurs est l’opérateur & qui prend l’adresse d’une variable. Celle-ci est bien entendue contrôlée par le noyau (dans le sens où son déréférencement est toujours sûr). Cette construction crée donc des pointeurs noyau, et on maintient la règle suivante : Γ � l v : t Γ � &l v : t ∗ (ADDR) Manipulations de pointeurs L’avantage du typage est que celui-ci suit le flot de données : si à un endroit une valeur de type t est affectée à une variable, que le contenu de cette variable est placé puis retiré d’une structure de données, il conserve ce type t. En particulier un pointeur utilisateur reste un pointeur utilisateur. Une seule règle consomme un pointeur et en retourne un. Elle concerne l’arithmétique des pointeurs. On ne l’étend pas aux pointeurs utilisateur, car pour effectuer de l’arithmé- rique, il faut observer la forme du pointeur sous-jacent. Si on veut laisser ♦� · opaque, il faut donc interdire l’arithmétique sur les pointeurs utilisateur. Utilisations de pointeurs La principale restriction est que seuls les pointeurs noyau peuvent être déréférencés de manière sûre. La règle capitale est donc la suivante (déjà introduite dans le chapitre 5) : Γ � e : t ∗ Γ � ∗e : t (LV-DEREF) Ainsi, on interdit le déréférencement des expressions de type t @ à la compilation. L’opérateur ♦ · transforme un pointeur selon la règle suivante : Γ � l v : t Γ � ♦ l v : t @ (ADDR-USER)92 CHAPITRE 6. EXTENSIONS DE TYPAGE Les « fonctions » copy_from_user et copy_to_user sont typées de la manière suivante. Il est à remarquer que ce ne sont pas vraiment des fonctions et qu’elles n’ont pas un type en (t1,t2) → t, car il faudrait un type polymorphe pour pouvoir les appliquer à n’importe quel type de pointeurs. Leur typage est donc plus proche de celui d’un opérateur. Γ � ed : t ∗ Γ � es : t @ Γ � copy_from_user(ed ,es) : INT (USER-GET) Γ � ed : t @ Γ � es : t ∗ Γ � copy_to_user(ed ,es) : INT (USER-PUT) 6.2.5 Sûreté du typage Typage sémantique La définition du typage sémantique doit aussi être étendue au cas ϕ = ♦� ϕ� . En essence, S-USERPTR énonce que traverser un constructeur ♦� · transforme un pointeur en pointeur utilisateur. m � &� ϕ : τ ∗ m � &� ♦� ϕ : τ @ (S-USERPTR) τ�t τ @�t @ (COMP-PTR) Propriétés du typage Lemme 6.1 (Inversion du typage). En plus des cas présentés dans le lemme 5.1, les cas suivants permettent de remonter un jugement de typage. • Si Γ � ♦ e : t, alors il existe t� tel que t = t� @ et Γ � e : t� . • Si Γ � copy_from_user(ed ,es) : t, alors t = INT et il existe t� tel que Γ � ed : t ∗ et Γ � es : t @. • Si Γ � copy_to_user(ed ,es) : t, alors t = INT et il existe t� tel que Γ � ed : t @ et Γ � es : t ∗. Démonstration. Pour chaque forme syntaxique, on liste les règles qui ont comme conclusion un jugement de typage portant sur celle-ci. Comme aucune autre règle ne convient, on peut en déduire que c’est l’une de celles-ci qui a été appliquée, et donc qu’une des prémisses est vraie. Progrès et préservation La propriété que nous cherchons à prouver est que le déréférencement d’un pointeur dont la valeur est contrôlée par l’utilisateur ne peut se faire qu’à travers une fonction qui vérifie la sûreté de celui-ci. En fait il s’agit des théorèmes de sûreté du chapitre précédent. Théorème 6.1 (Progrès pour les extensions noyau). Le théorème 5.1 reste valable avec les extensions de ce chapitre. La preuve de ce théorème est en annexe D.4. Théorème 6.2 (Préservation pour les extensions noyau). Le théorème 5.2 reste valable avec les extensions de ce chapitre.6.2. ANALYSE DE PROVENANCE DE POINTEURS 93 La preuve de ce théorème est en annexe D.5. Ces extensions ne modifient pas les théorème de progrès et préservation sur les phrases (théorèmes 5.3 et 5.4). La sûreté du typage étant à nouveau établie, on a montré que l’ajout de types pointeurs utilisateur suffit pour avoir une adéquation entre les extensions de sémantique de la section 6.2.1 et les extensions du système de type de la section 6.2.4. Conclusion En partant de SAFESPEAK tel que décrit dans les chapitres 4 et 5, on décrit une extension de sa syntaxe et de sa sémantique. Cela permet d’exprimer les pointeurs vers l’espace utilisateur, qui sont utilisés pour l’implantation d’appels système (chapitre 2). Une première idée pour le typage de ces nouveaux pointeurs est de leur donner le même type que les pointeurs classiques. On a montré ensuite que ce typage naïf ne suffit pas : il permet en effet de faire fuiter de l’information, ce qu’on note par un cas d’erreur Ωsec . En termes de systèmes de types, cela signifie que le théorème de progrès (théorème 5.1, page 77) n’est plus vérifié. Le langage des types est donc enrichi pour séparer les pointeurs utilisateur des pointeurs noyau : les premiers sont explicitement construits par un ensemble de sources bien déterminé, et les autres sont créés par exemple en prenant l’adresse d’une variable. La règle de typage LV-DEREF assure que seuls les pointeurs noyau peuvent être déréférencés. Pour accéder aux pointeurs utilisateur, il faut appeler les constructions copy_to_user et copy_from_user, qui sont typées adéquatement et vérifient dynamiquement que les pointeurs dont la valeur est contrôlée par l’utilisateur pointent vers l’espace utilisateur.CONCLUSION DE LA PARTIE II On vient de décrire en détail un langage impératif, SAFESPEAK, et tout d’abord sa syntaxe et sa sémantique d’évaluation dans le chapitre 4. Une des spécificités de cette sémantique est l’utilisation de lentilles pour modifier les valeurs composées en profondeur. Il y a plusieurs alternatives à cette présentation. La première est la solution classique qui consiste à décrire les modifications de la mémoire en extension. C’est en général long et laborieux puisqu’il faut définir les accès en lecture et écriture à chaque étape (avec des lentilles on décrit ces deux opérations uniquement sur les briques du calcul, et la composition fait le reste). La seconde solution est d’employer une sémantique monadique. Les transitions sont alors encodées comme des actions monadiques qui représentent les modifications de la mé- moire. Un des avantages de cette solution est qu’elle est très extensible. Par exemple, la propagation des erreurs ou l’ajout de continuations légères (c’est-à-dire le support des fonctions setjmp et longjmp) peuvent facilement être exprimés dans un formalisme monadique. Nous avons préféré une présentation plus directe qui reste plus accessible à une audience habituée à C, et suffisante compte tenu de la simplicité des constructions à interpréter dans le langage. Ensuite, dans le chapitre 5, nous avons ajouté un système de types à SAFESPEAK. Le but est de restreindre le genre d’erreurs qui peuvent arriver lors de l’évaluation d’un programme. Par le théorème de progrès (théorème 5.1 , page 77), on interdit les erreurs qui signalent une manipulation de valeurs incompatibles, l’accès à un champ de structure inconnu, et l’accès à une variable inexistante. Et le théorème de préservation (théorème 5.2, page 78) formalise le résultat classique qu’une étape d’évaluation ne modifie pas le typage. Une particularité de SAFESPEAK est que son état mémoire est structuré, avec une pile de variables locales explicite. On retrouve donc cette distinction dans le typage : les variables globales et les variable locales sont séparées dans les environnements de typage Γ (page 64). Enfin, dans le chapitre 6, on a étendu le langage pour exprimer la notion de pointeurs utilisateur. Cela permet d’écrire des fonctions qui implantent des appels système. On a commencé par montrer qu’une extension naïve du système de types ne suffit pas, car le théorème de progrès est alors invalidé. On ajoute donc un type dédié aux pointeurs utilisateur. Les valeurs de ce type sont créées explicitement et passées aux appels système. La règle de typage du déréférencement est restreinte aux pointeurs noyau, ce qui permet de ré-établir les théorèmes de progrès et préservation. Notre technique de typage permet donc d’exprimer correctement les problèmes liés à la manipulation mémoire lors des appels système, ainsi que décrits dans le chapitre 2 : c’est une méthode simple pour détecter et empêcher les problèmes de sécurité qui proviennent des pointeurs utilisateur. Comme nous l’avons fait remarquer dans le chapitre 3, utiliser une technique de typage pour étudier des propriétés sur les données a déjà été explorée dans l’outil CQual [FFA99], en particulier sur les problèmes de pointeurs utilisateur [JW04]. En effet, si on remplace « t ∗ » par « KERNEL t ∗ » et « t @ » par « USER t ∗ », on obtient un début de système de types qualifiés. En revanche, il y a une différence importante : CQual modifie fondamentalement l’ensemble du système de types, pas SAFESPEAK. Le jugement de typage de CQual a pour forme générale Γ � e : q t (où Γ est un environnement de typage, e une expression, q un qualificateur et t un type), alors que le nôtre a la forme plus classique Γ � e : t. 9596 CHAPITRE 6. EXTENSIONS DE TYPAGE En intégrant q à la relation de typage, on ajoute un qualificateur à chaque type, même les expressions pour lesquelles il n’est pas directement pertinent de déterminer qui les contrôle (comme par exemple, un entier). Dans CQual, ceci permet de traiter de manière correcte le transtypage. Par exemple, si e a pour type qualifié USER INT, alors (FLOAT ∗) e aura pour type qualifié USER FLOAT ∗, et déréférencer cette expression produira une erreur de typage. SAFESPEAK, dans son état actuel, ne permet pas de traiter les conversions de type et ne permet donc pas de traiter ce cas. Nous prenons, au contraire, l’approche de ne modifier le système de types que là où cela est nécessaire, c’est-à-dire sur les types pointeurs. Cela permet de ne pas avoir à modifier en profondeur un système de types existant. Le modèle d’exécution est aussi très différent. CQual s’appuie sur un langage proche de ML : un noyau de lambda-calcul avec des références. Le système de types sous-jacent est proche de celui d’OCaml : du polymorphisme de premier ordre (avec la restriction habituelle de généralisation des références) et du sous-typage structurel. En outre, leur approche repose sur une gestion automatique de la mémoire. De notre côté, nous nous appuyons sur un modèle mémoire plus proche de C, reposant sur une pile de variables et des pointeurs manipulés à la main. Une autre différence fondamentale est que le système de types de CQual fait intervenir une relation de sous-typage. Le cas particulier du problème de déréférencement des pointeurs utilisateur peut être traité dans ce cadre en posant KERNEL � USER pour restreindre certaines opérations aux pointeurs KERNEL. Notre approche, au contraire, n’utilise pas de sous-typage, mais consiste à définir un type abstrait t @ partageant certaines propriétés avec t ∗ (comme la taille et la représentation) mais incompatible avec certaines opérations. C’est à rapprocher des types abstraits dans les langages comme OCaml et Haskell. Les perspectives de travaux futurs sont également très différentes. Dans le cas des pointeurs, même si le noyau Linux (et la plupart des systèmes d’exploitation) ne comportent que deux espaces d’adressage, il est commun dans les systèmes embarqués de manipuler des pointeurs provenant d’espaces mémoire indépendants : par exemple, de la mémoire flash, de la RAM, ou une EEPROM de configuration. Ces différentes mémoires possèdent des adresses, et un pointeur est interprété comme faisant référence à une ou l’autre selon le code dont il est tiré. Lorsqu’il y a plus de deux espaces mémoire, aucun n’est plus spécifique que les autres : le sous-typage, et donc un système de qualificateurs, n’est donc plus adapté. Au contraire il est possible de créer un type de pointeurs pour chaque zone mémoire.Troisième partie Expérimentation Après avoir décrit notre solution dans la partie II, on présente ici son implantation. Le chapitre 7 décrit l’implantation en elle-même : un prototype d’analyseur de types, distribué avec le langage NEWSPEAK sur [☞3]. Il s’agit d’un logiciel libre, distribué sous la license LGPL. La compilation depuis C est réalisée par l’utilitaire C2NEWSPEAK. Celui-ci, tout comme le langage NEWSPEAK, proviennent d’EADS et sont antérieurs à ce projet, mais le support de plusieurs extensions GNU C a été développé spécialement pour pouvoir analyser le code du noyau Linux. L’analyse en elle-même est implantée de la manière classique avec une variation de l’algorithme W de Damas et Milner. Pour des raisons de simplicité et d’efficacité, l’unification est faite en utilisant le partage de références plutôt que des substitutions. L’algorithme d’inférence ne pose pas de problèmes de performance. Ensuite, dans le chapitre 8, on évalue cette implantation sur le noyau Linux. On commence par décrire comment fonctionnennt les appels système sous ce noyau, et comment le confused deputy problem évoqué dans le chapitre 2 peut arriver dans ce contexte. Dans une deuxième partie, on décrit le cas de deux bugs dans le noyau Linux. Le premier porte sur un pilote de carte graphique Radeon et le second sur l’appel système ptrace sur l’architecture Blackfin. Ils manipulent de manière non sécurisée des pointeurs provenant de l’espace utilisateur. On montre que, pour chacun, les analyses précédentes permettent de distinguer statiquement le cas incorrect du cas corrigé. 97C H A P I T R E 7 IMPLANTATION Dans ce chapitre, nous décrivons la mise en œuvre des analyses statiques précédentes. Celles-ci ont été décrites sur SAFESPEAK, qui permet de modéliser des programmes C bien typables. Notre but est d’utiliser la représentation intermédiaire NEWSPEAK, développée par EADS. Cela permet de profiter des nombreux outils existant déjà autour de ce langage, notamment un compilateur depuis C et un analyseur statique par interprétation abstraite. Mais cette représentation utilise un modèle mémoire différent. En effet il colle finement à celui de C, où des constructions comme les unions empêchent la sûreté du typage. Défi- nir SAFESPEAK a précisement pour but de définir un langage inspiré de C mais sur lequel le typage peut être sûr. Il faudra donc adapter les règles de typage des chapitres 5 et 6. On reviendra sur cette distinction entre les deux niveaux de sémantique dans la conclusion de la partie III, page 123. On commence par décrire le langage NEWSPEAK. Ensuite, nous décrivons la phase de compilation, de C à NEWSPEAK, auquel on rajoute ensuite des étiquettes de types. Cellesci sont calculées par un algorithme d’inférence de types à la Hindley-Milner, reposant sur l’unification et le partage de références. Toutes ces étapes sont implantées dans le langage OCaml [LDG+10, CMP03]. Le prototype décrit ici est disponible sur [☞3] sous une license libre, la GNU Lesser General Public License. 7.1 NEWSPEAK et chaîne de compilation NEWSPEAK est un langage intermédiaire conçu pour être un bon support d’analyses statiques, contrairement à des langages conçus pour les programmeurs comme C. Sa sémantique d’exécution (ainsi qu’une partie des étapes de compilation) est décrite dans [HL08]. Sa syntaxe est donnée dans la figure 7.1. La traduction depuis C est faite en trois étapes : prétraitement du code source par un outil externe, compilation séparée de C prétraité vers des objets NEWSPEAK, puis liaison de ces différentes unités de compilation. Il est aussi possible de compiler directement du code Ada vers un objet NEWSPEAK. La première étape consiste à prétraiter les fichiers C source avec le logiciel cpp, comme pour une compilation normale. Cette étape interprète les directives de prétraitement comme #include, #ifdef. À cet étape, les commentaires sont aussi supprimés. 99100 CHAPITRE 7. IMPLANTATION Instruction s ::= Set(l v,e,st) Affectation | Copy(l v,l v,n) Copie | Guard(e) Garde | Decl(var,t,bl k) Déclaration | Select(bl k,bl k) Branchement | InfLoop(bl k) Boucle infinie | DoWith(bl k,x) Nommage de bloc | Goto(x) Saut | Call([(ei ,ti)], f , [(l vi ,ti)]) Appel de fonction Bloc bl k ::= [si] Liste d’instructions Valeur gauche l v ::= Local(x) Locale | Global(x) Globale | Deref(e,n) Déréférencement | Shift(l v,e) Décalage Expression e ::= CInt(n) Entier | CFloat(d) Flottant | Nil Pointeur nul | Lval(l v,t) Accès mémoire | AddrOf(l v) Adresse de variable | AddrOfFun(x, [ti], [ti]) Adresse de fonction | UnOp(unop,e) Opérateur unaire | BinOp(binop,e1,e2) Opérateur binaire Fonction f ::= FunId(x) Appel par nom | FunDeref(e) Appel par pointeur Type t ::= Scalar(st) Type scalaire | Array(t,n) Tableau | Region([(ni ,ti)],n� ) Structure/union Type scalaire st ::= Int(n) Entier | Float(n) Flottant | Ptr Pointeur sur données | FunPtr Pointeur sur fonction FIGURE 7.1 : Syntaxe simplifiée de NEWSPEAK7.1. NEWSPEAK ET CHAÎNE DE COMPILATION 101 Une fois cette passe effectuée, le résultat est un ensemble de fichiers C prétraités ; c’est- à-dire des unités de compilation. Sur cette représentation (du C prétraité), il est possible d’ajouter des annotations de la forme /*!npk [...] */ qui pourront être accessibles dans l’arbre de syntaxe abstraite des passes suivantes. À ce niveau, les fichiers sont passés à l’outil C2NEWSPEAK qui les traduit vers NEWSPEAK. Comme il sera décrit dans la section 8.1, la plupart des extensions GNU C sont acceptées en plus du C ANSI. Dans cette étape, les types et les noms sont résolus, et le programme est annoté de manière à rendre les prochaines étapes indépendantes du contexte. Par exemple, chaque déclaration de variable est adjointe d’une description complète du type. Lors de cette étape, le flot de contrôle est également simplifié (figure 7.2). De plus, les constructions ambigües en C comme i = i++ sont transformées pour que leur évaluation se fasse dans dans un ordre explicite. Un choix arbitraire est alors fait ; par exemple, les arguments de fonctions sont évalués de droite à gauche (la raison étant sur Intel, les arguments sont empilés dans ce sens). Au contraire, NEWSPEAK propose un nombre réduit de constructions. Rappelons que le but de ce langage est de faciliter l’analyse statique : des constructions orthogonales permettent donc d’éviter la duplication de règles sémantiques, ou de code, lors de l’implantation d’un analyseur. Par exemple, plutôt que de fournir une boucle while, une boucle do/while et une boucle for, NEWSPEAK fournit une unique boucle WHILE(1){·}. La sortie de boucle est compilée vers un GOTO [EH94], qui est toujours un saut vers l’avant (similaire à un « break » généralisé). NEWSPEAK est conçu pour l’analyse statique par interprétation abstraite. Il a donc une vue de bas niveau sur les programmes. Par exemple, aucune distinction n’est faite entre l’accès à un champ et l’accès à un élément d’un tableau (tous deux sont traduits par un décalage numérique depuis le début de la zone mémoire). De plus, les unions et les structures sont regroupées sous forme des types « régions » qui associent à un décalage un type de champ. Pour supprimer ces ambiguïtés, il faut s’interfacer dans les structures internes de C2NEWSPEAK, où les informations nécessaires sont encore présentes. int x; x = 0; while (x < 10) { x++; } int32 x; x =(int32) 0; do { while (1) { choose { --> guard((10 > x_int32)); --> guard(! (10 > x_int32)); goto lbl1; } x =(int32) coerce[-2**31,2**31-1] (x_int32 + 1); } } with lbl1: { } FIGURE 7.2 : Compilation du flot de contrôle en NEWSPEAK. Le code source C, à gauche, est compilé en NEWSPEAK, à droite.102 CHAPITRE 7. IMPLANTATION Ensuite, les différents fichiers sont liés ensemble. Cette étape consiste principalement à s’assurer que les hypothèses faites par les différentes unités de compilation sont cohérentes entre elles. Les objets marqués static, invisibles à l’extérieur de leur unité de compilation, sont renommés afin qu’ils aient un nom globalement unique. Cette étape se conclut par la création d’un fichier NEWSPEAK. 7.2 L’outil ptrtype La dernière étape est réalisée dans un autre outil nommé ptrtype, d’environ 1600 lignes de code OCaml, et réalisé dans le cadre de cette thèse. Elle consiste en l’implantation d’un algorithme d’inférence pour les systèmes de types décrits dans les chapitres 5 et 6. Puisqu’ils sont suffisamment proches du lambda calcul simplement typé, on peut utiliser une variante de l’algorithme W de Damas et Milner [DM82]. Cela repose sur l’unification : on dispose d’une fonction permettant de créer des inconnues de type, et d’une fonction pour unifier deux types partiellement inconnus. En pratique, on utilise l’optimisation classique qui consiste à se reposer sur le partage de références pour réaliser l’unification, plutôt que de faire des substitutions explicites. Puisque ces systèmes de types sont monomorphes, on présente une erreur si des variable de type libres sont présentes. Architecture de ptrtype Bâti autour de cette fonction, le programme ptrtype lit un programme NEWSPEAK et réalise l’inférence de types. Si l’argument passé à ptrtype est un fichier C, il est tout d’abord compilé vers NEWSPEAK grâce à l’utilitaire C2NEWSPEAK. En sortie, il affiche soit le programme complètement annoté, soit une erreur. Ce comportement est implanté dans la fonction de la figure 7.3. • Grâce à la fonction convert_unit : Newspeak.t -> unit Tyspeak.t, on ajoute des étiquettes « vides » (toutes égales à () : unit) 1. • L’ensemble des fonctions du programme est trié topologiquement selon la relation � définie par f � g def == « g apparaît dans la définition de f ». Cela est fait en construisant une représentation de � sous forme de graphe, puis en faisant un parcours en largeur de celui-ci. Pour le moment, les fonctions récursives et mutellement récursives ne sont pas supportées. • Les annotations extérieures sont alors lues (variable exttbl), ce qui permet de créer un environnement initial. On peut y introduire les annotations suivantes : Annotation Signification /*!npk f : (Int) -> Int */ f est une fonction prenant comme argument un entier et renvoyant un entier. /*!npk userptr x */ x a pour type a @, où a est une nouvelle inconnue de type. /*!npk userptr_fieldp x f */ x a pour type {f : a @;...} ∗, où a est une nouvelle inconnue de type. • Les types de chaque fonction sont ensuite inférés, par le biais de la fonction suivante : 1. ’a Tyspeak.t est le type des programmes NEWSPEAK où on insère des étiquettes de type ’a à tous les niveaux.7.2. L’OUTIL PTRTYPE 103 let process_npk npk = let tpk = Npk2tpk.convert_unit npk in let order = Topological.topological_sort (Topological.make_graph npk) in let function_is_defined f = Hashtbl.mem tpk.Tyspeak.fundecs f in let (internal_funcs, external_funcs) = List.partition function_is_defined order in let exttbl = Printer.parse_external_type_annotations tpk in let env = env_add_external_fundecs exttbl external_funcs Env.empty in let s = Infer.infer internal_funcs env tpk in begin if !Options.do_checks then Check.check env s end; Printer.dump s FIGURE 7.3 : Fonction principale de ptrtype val infer : Newspeak.fid list (* liste triée de fonctions à typer *) -> Types.simple Env.t (* environnement initial *) -> 'a Tyspeak.t (* programme à analyser *) -> Types.simple Tyspeak.t • S’il n’y a pas d’erreurs, le programme obtenu, de type Types.simple Tyspeak.t, est affiché sur le terminal. Unification La fonction unify prend en entrée deux représentations de types pouvant contenir des inconnues de la forme Var n, et retourne une liste de contraintes indiquant les substitutions à faire. Cet algorithme est décrit en pseudo-code ML en figure 7.4. Pour simplifier, on le présente comme retournant une liste, mais il est implanté de manière destructive : Var n contient une référence qui peut être modifiée, et grâce au partage c’est équivalent à substituer dans tous les types qui contiennent Var n. La fonction d’unification prend un chemin différent selon la forme des deux types d’entrée : • si les deux types sont inconnus (de la forme Var n), on substitue l’un par l’autre. • si un type est inconnu et pas l’autre, il faut de la même manière faire une substitution. Mais en faisant ça inconditionnellement, cela peut poser problème : par exemple, en104 CHAPITRE 7. IMPLANTATION Contrainte c ::= n �→ t Substitution | (l : t) ∈ X Variable de rangée 1: function UNIFY(ta,tb) 2: match (ta,tb) with 3: | VAR na, VAR nb ⇒ 4: if na = nb then 5: return [ ] 6: else 7: return [na �→ tb] 8: end if 9: | VAR na,tb ⇒ 10: if OCCURS(na,tb) then 11: erreur 12: end if 13: return [na �→ tb] 14: | ta, VAR nb ⇒ return UNIFY(tb,ta) 15: | INT, INT ⇒ return [ ] 16: | FLOAT, FLOAT ⇒ return [ ] 17: | a[ ],b[ ] ⇒ return UNIFY(a,b) 18: | a ∗,b ∗ ⇒ return UNIFY(a,b) 19: | a @,b @ ⇒ return UNIFY(a,b) 20: | (la) → ra, (lb) → rb ⇒ 21: r ← UNIFY(ra, rb) 22: n ← LENGTH(la) 23: if LENGTH(lb) �= n then 24: erreur 25: end if 26: for i = 0 to n −1 do 27: r ← r ∪ UNIFY(la[i],lb[i]) 28: end for 29: return r 30: | A = {a1 : t1;...;an : tn;...Xa},B = {b1 : s1;...;bm : um;...Xb} ⇒ 31: r ← � 32: for {(t,u)/∃l.(l : t) ∈ A ∧(l : u) ∈ B} do 33: r ← r ∪ UNIFY(t,u) 34: end for 35: for {(l,t) ∈ A/∀(l� : u) ∈ B.l �= l� } do 36: r ← r ∪[(l : t) ∈ XB ] 37: end for 38: for {(l,u) ∈ B/∀(l� : t) ∈ A.l �= l� } do 39: r ← r ∪[(l : u) ∈ XA] 40: end for 41: return r 42: | _ ⇒ erreur 43: end function FIGURE 7.4 : Algorithme d’unification7.2. L’OUTIL PTRTYPE 105 let unify a b = if !Options.lazy_unification then Queue.add (Unify (a, b)) unify_queue else unify_now a b FIGURE 7.5 : Unification directe ou retardée tentant d’unifier a avec KPtr(a), on pourrait créer une substitution cyclique. Pour éviter cette situation, il suffit de s’assurer que le type inconnu n’est pas présent dans le type à affecter. C’est le but de la fonction occurs(n, t) qui calcule si Var n apparaît dans t. • si les deux types sont des types de base (comme INT ou FLOAT) égaux, on ne fait rien. • si les deux types sont des constructeurs de type, il faut que les constructeurs soient égaux. On unifie en outre leurs arguments deux à deux. • dans les autres cas, l’algorithme échoue. Le traitement des types structures est géré dans l’implantation d’une manière différente de la présentation du chapitre 4. Au lieu d’accéder directement au type complet S à chaque accès x.lS, on n’obtient qu’un nom de champ à chaque accès. C’est-à-dire qu’on va par exemple inférer le type {l : INT;...X} où ...X désigne l’ensemble des champs inconnus (on rappelle que dans la sémantique qui nous intéresse, ceux-ci n’ont pas un ordre défini au sein d’une structure). Plus précisément, si on cherche à unifier les types structures A = {a1 : t1;...;an : tn;...Xa} et B = {b1 : s1;...;bm : um;...Xb}, il faut partitionner l’ensemble des champs en 3 : ceux qui apparaissent dans les deux structures, ceux qui apparaissent dans A mais pas dans B, et ceux qui apparaissent dans B mais pas dans A. • Pour tous les champs l tels que l : t ∈ A et l : u ∈ B, on unifie t et u. • Pour les champs l qui sont dans A mais pas dans B : on ajoute l à Xb. • Pour les champs l qui sont dans B mais pas dans A : on ajoute l à Xa. Cela se rapproche du polymorphisme de rangée [RV98] présent dans les langages comme OCaml. À la fin de l’inférence, on considère que la variable de rangée « ...X » est vide. Elle n’apparaît donc pas dans les types. La fonction unify, appelée dans toutes les fonctions d’inférence, peut retarder l’unification (figure 7.5). Dans ce cas, la paire de types à unifier est mise dans une liste d’attente qui sera unifiée après le parcours du programme. Le but est d’instrumenter l’inférence de types afin de pouvoir en faire une exécution « pas à pas ». Inférence de types Il ne reste plus qu’à remplacer les étiquettes de type unit par des étiquettes de type simple (autrement dit de vraies représentations de types), à l’aide de la fonction unify. Cette étape se fait de manière impérative. Cela permet de ne pas avoir à réaliser de substitutions explicites. À la place, on repose sur le partage et les références, qui représentent les inconnues de type. Lorsque celles-ci sont résolues, il suffit de muter une seule fois la ré- férence, et le partage fait que ce changement sera visible partout. Plus précisément, on peut créer de nouveaux types avec la fonction new_unknown et unifier deux types avec la fonction unify. Leurs types sont :106 CHAPITRE 7. IMPLANTATION val new_unknown : unit -> Types.simple val unify : Types.simple -> Types.simple -> unit La fonction infer s’appuie sur un ensemble de fonctions récursivement définies portant sur chaque type de fragment : infer_fdec pour les déclarations de fonction, infer_exp pour les expressions, infer_stmtkind pour les instructions, etc. Grâce au lemme 5.1, on sait quelle règle appliquer en fonction de l’expression ou instruction considérée. Notons que, même si le programme NEWSPEAK est décoré d’informations de types (celles qui existent dans le programme C), elles ne sont pas utilisées. Les règles de typage sont implantées par new_unknown et unify. Par exemple, pour typer une déclaration (qui n’a pas de valeur initiale en NEWSPEAK), on crée un nouveau type t0. On étend l’environnement courant avec cette nouvelle association et, sous ce nouvel environnement, on type le bloc de portée de la déclaration (figure 7.6). let rec infer_stmtkind env sk = match sk with (* [...] *) | T.Decl (n, nty, _ty, blk) -> let var = T.Local n in let t0 = new_unknown () in let new_env = Env.add (VLocal n) (Some nty) t0 env in let blk’ = infer_blk new_env blk in let ty = lval_type new_env var in T.Decl (n, nty, ty, blk’) (* [...] *) | T.Call (args, fexp, rets) -> let infer_arg (e, nt) = let et = infer_exp env e in (et, nt) in let infer_ret (lv, nt) = (infer_lv env lv, nt) in let args’ = List.map infer_arg args in let rets’ = List.map infer_ret rets in let t_args = List.map (fun ((_, t), _) -> t) args’ in let t_rets = List.map (fun (lv, _) -> lval_type env lv) rets’ in let (fexp’, tf) = infer_funexp env fexp in let call_type = Fun (t_args, t_rets) in unify tf call_type; T.Call (args’, fexp’, rets’) FIGURE 7.6 : Inférence des déclarations de variable et appels de fonction De même, pour typer un appel de fonction, on infère le type de ses arguments et valeurs gauches de retour. On obtient également le type de la fonction (à partir du type de la fonction7.3. EXEMPLE 107 présent dans l’environnement, ou du type du pointeur de fonction qui est déréférencé), et on unifie ces deux informations. Pour additionner deux flottants, par exemple, on unifie leurs types avec FLOAT. Le résultat est également de type FLOAT. Cela correspond à la règle OP-FLOAT. let infer_binop op (_, a) (_, b) = match op with (* [...] *) | N.PlusF _ -> unify a Float; unify b Float; Float Pour prendre l’adresse d’une variable, la règle ADDR s’applique : on prend le type de la valeur gauche et on construit un pointeur noyau à partir de lui. | T.AddrOf lv -> let lv' = infer_lv env lv in let ty = lval_type env lv in (T.AddrOf lv', Ptr (Kernel, ty)) Enfin, pour déréférencer une expression, on unifie tout d’abord son type avec le type d’un pointeur noyau. | T.Deref(e, _sz) -> let (_, te) = infer_exp env e in let t = new_unknown () in unify (Ptr (Kernel, t)) te; t 7.3 Exemple Lançons l’analyse sur un petit exemple (stocké dans le fichier example.c) : int f(int *x) { return (*x + 1); } L’exécution de notre analyseur affiche un programme complètement annoté : % ptrtype example.c 1 f : (KPtr (Int)) -> (Int) 2 Int (example.c:1#4)^f(KPtr (Int) x) { 3 (.c:3#4)^!return =(int32) 4 (coerce[-2147483648,2147483647] 5 ( ( ([(x_KPtr (Int) : KPtr (Int))]32_Int 6 : Int 7 ) 8 + (1 : Int) 9 ) : Int 10 ) : Int 11 ); 12 }108 CHAPITRE 7. IMPLANTATION • Ligne 1 : le type inféré de la fonction f est affiché. Il est calculé entièrement en fonction des opérations effectuées ; on n’utilise pas les étiquettes de type du programme. • Ligne 2 : le code de la fonction est affiché. Les indications de la forme (F:L#C)ˆX correspondent à la déclaration d’une variable X, dans le fichier F, ligne L et colonne C. • Ligne 3 : en NEWSPEAK, la valeur de retour est une variable qui est affectée. On sépare ainsi le flot de données (définir la valeur de retour) du flot de contrôle (sortir de la fonction). C’est un équivalent de la variable R introduite pour le typage des fonctions (page 69). L’affectation est notée =(int32) car en NEWSPEAK elle est décorée du type des opérandes. Cette information n’est pas utilisée dans l’inférence de types. • Ligne 4 : l’opérateur coerce[a,b] sert à détecter les débordements d’entiers lors d’une analyse de valeurs par interprétation abstraite. Dans le cas de notre analyse, les valeurs ne sont pas pertinentes et cet opérateur peut être vu que comme l’identité. • Ligne 5 : le déréférencement d’une valeur gauche e est noté [e]_n. Il est annoté par la taille de l’opérande (32 bits ici). De plus, l’accès à une valeur gauche (pour la transformer en expression) est annoté par son type, ce qui explique la verbosité de cette ligne. • les autres lignes sont des étiquettes de type inférées sur les expressions 1, ∗x, 1, ∗x +1 et la valeur de retour coerce[−231, 231 −1](∗x +1). Un exemple de détection d’erreur sera décrit dans la section 8.6. 7.4 Performance Même s’il est simple en apparence, le problème de l’inférence de types par l’algorithme W est EXP-complet [Mai90], c’est-à-dire que les algorithmes efficaces ont une complexité exponentielle en la taille du programme. Cependant, lorsqu’on borne la « taille » des types, celle-ci devient quasi-linéaire [McA03], ce qui signifie qu’il n’y a pas de problème de performance à attendre en pratique. Dans notre cas, on utilise une variante de l’algorithme W pour un langage particulièrement simple. En particulier il n’y a pas de polymorphisme, ni de fonctions imbriquées, et les types des valeurs globales sont écrites par le programmeur. Cela permet de borner leur taille. En pratique, sur les exemples testés (jusqu’à quelques centaines de lignes de code) nous n’avons pas noté de délai d’exécution notable. En revanche, la compilation de C vers NEWSPEAK peut être plus coûteuse, notamment lorsque le fichier d’entrée est de taille importante. Le temps de traitement est plus long que celui d’un compilateur comme gcc ou clang. C2NEWSPEAK a toutefois été utilisé pour compiler des projets de l’ordre du million de lignes de code source prétraité, et son exécution ne prenait pas plus de quelques minutes. À titre d’illustration, nous avons mesuré les performances de C2NEWSPEAK et ptrtype sur l’exemple « Blackfin » du chapitre suivant. Celui consiste en un fichier prétraité de 853 lignes de code C. Exécuter 1000 fois C2NEWSPEAK sur ce fichier prend 36.3 secondes, alors qu’exé- cuter 1000 fois ptrtype sur le fichier NEWSPEAK résultant ne dure que 8.1 secondes (par comparaison, lancer 1000 fois /bin/true, commande qui ne fait rien, prend 1.6 seconde). Les structures internes de C2NEWSPEAK ont déjà été améliorées, et d’autres optimisations sont certainement possibles, mais la performance n’est pas bloquante pour le moment : une fois que le code est compilé, on peut réutiliser le fichier objet NEWSPEAK pour d’autres analyses. La compilation est donc relativement rare.7.4. PERFORMANCE 109 Conclusion Les analyses de typage correspondant aux chapitres 5 et 6 ont été implantées sous forme d’un prototype utilisant le langage NEWSPEAK développé par EADS. Cela permet de réutiliser les phases de compilation déjà implantées, et d’exprimer les règles de typage sur un langage suffisament simple. On utilise un algorithme par unification, qui donne une forme simple au programme d’inférence. Pour chaque expression ou instruction à typer, on détermine grâce au lemme 5.1 quelle règle il faut appliquer. Ensuite, on génère les inconnues de type nécessaires pour appliquer cette règle et on indique les contraintes en appelant la fonction d’unification. Ce prototype comporte environ 1600 lignes de code OCaml. Il est disponible sous license libre sur [☞3]. Il a été pensé pour traiter un type de code particulier, à savoir le noyau Linux. On montre dans le chapitre suivant que cet objectif est atteint, puisqu’il permet de détecter plusieurs bugs.C H A P I T R E 8 ÉTUDE DE CAS : LE NOYAU LINUX Le noyau Linux, abordé dans le chapitre 2, est un noyau de système d’exploitation développé depuis le début des années 90 et « figure de proue » du mouvement open-source. Au départ écrit par Linus Torvalds sur son ordinateur personnel, il a été porté au fil des années sur de nombreuses architectures et s’est enrichi de nombreux pilotes de périphériques. Dans la version 3.13.1 (2014), son code source comporte 12 millions de lignes de code (en grande majorité du C) dont 58% de pilotes. Même si le noyau est monolithique (la majeure partie des traitements s’effectue au sein d’un même fichier objet), les sous-systèmes sont indépendants. C’est ce qui permet d’écrire des pilotes de périphériques et des modules. Ces pilotes manipulent des données provenant de l’utilisateur, notamment par pointeur. Comme on l’a vu, cela peut poser des problèmes de sécurité si on déréférence ces pointeurs sans vérification. Dans ce chapitre, on met en œuvre sur le noyau Linux le système de types décrit dans le chapitre 6, ou plus précisément l’outil ptrtype du chapitre 7. Pour montrer que le système de types capture cette propriété et que l’implantation est utilisable, on étudie les cas de deux bugs qui ont touché le noyau Linux. À chaque fois, dans une routine correspondant à un appel système, un pointeur utilisateur est déréférencé directement, pouvant provoquer une fuite d’informations confidentielles dans le noyau. On commence par décrire les difficultés rencontrées pour analyser le code du noyau Linux. On décrit ensuite l’implantation du mécanisme d’appels système dans ce noyau, et en quoi cela peut poser des problèmes. On détaille enfin les bugs étudiés, et comment les adapter pour traiter le code en question. 8.1 Spécificités du code noyau Linux est écrit dans le langage C, mais pas dans la version qui correspond à la norme. Il utilise le dialecte GNU C qui est celui que supporte GCC. Une première difficulté pour traiter le code du noyau est donc de le compiler. Pour traduire ce dialecte, il a été nécessaire d’adapter C2NEWSPEAK. La principale particularité est la notation __attribute__((...)) qui peut décorer les déclarations de fonctions, de variables ou de types. Par exemple, il est possible de manipuler des étiquettes de première classe : si « lbl: » est présent avant une instruction, on peut capturer l’adresse de celle-ci avec void *p = &&lbl et y sauter indirectement avec goto *p. 111112 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX Une autre fonctionnalité est le concept d’instruction-expression : ({bloc}) est une expression, dont la valeur est celle de la dernière expression évaluée lors de bloc. Les attributs, quant à eux, rentrent dans trois catégories : • les annotations de compilation ; par exemple, used désactive l’avertissement « cette variable n’est pas utilisée ». • les optimisations ; par exemple, les objets marqués hot sont groupés de telle manière qu’ils se retrouvent en cache ensemble. • les annotations de bas niveau ; par exemple, aligned(n) spécifie qu’un objet doit être aligné sur au moins n bits. Dans notre cas, toutes ces annotations peuvent être ignorées, mais il faut tout de même adapter l’analyse syntaxique pour les ignorer. En particulier, pour le traitement du noyau Linux, il a fallu traiter certaines formes de la construction typeof qui n’étaient pas supportées. De plus, pour que le code noyau soit compilable, il est nécessaire de définir certaines macros. En particulier, le système de configuration de Linux utilise des macros nommées CONFIG_* pour inclure ou non certaines fonctionnalités. Il a donc fallu faire un choix ; nous avons choisi la configuration par défaut. Pour analyser des morceaux plus importants du noyau, il faudrait définir un fichier de configuration plus important. 8.2 Appels système sous Linux Dans cette section, nous allons voir comment ces mécanismes sont implantés dans le noyau Linux. Une description plus détaillée pourra être trouvée dans [BC05] ou, pour le cas de la mémoire virtuelle, dans [Gor04]. Deux rings sont utilisés : en ring 0, le code noyau et, en ring 3, le code utilisateur. Une notion de tâche similaire à celle décrite dans la section 2.2 existe : les tâches s’exé- cutent l’une après l’autre, le changement s’effectuant sur interruptions. Pour faire appel aux services du noyau, le code utilisateur doit faire appel à des appels système, qui sont des fonctions exécutées par le noyau. Chaque tâche doit donc avoir deux piles : une pile « utilisateur », qui sert pour l’application elle-même, et une pile « noyau », qui sert aux appels système. Grâce à la mémoire virtuelle, chaque processus possède sa propre vue de la mémoire dans son espace d’adressage (figure 8.1), et donc chacun gère un ensemble de tables de pages et une valeur de CR3 associée (ce mécanisme a été abordé page 17). Au moment de changer le processus en cours, l’ordonnanceur charge donc le CR3 du nouveau processus. Les adresses basses (inférieures à PAGE_OFFSET = 3 Gio = 0xc0000000) sont réservées à l’utilisateur. On y trouvera par exemple : le code du programme, les données du programme (variables globales), la pile utilisateur, le tas (mémoire allouée par malloc et fonctions similaires), ou encore les bibliothèques partagées. Au dessus de PAGE_OFFSET, se trouve la mémoire réservée au noyau. Cette zone contient le code du noyau, les piles noyau des processus, etc. 0 3 Go 4 Go FIGURE 8.1 : L’espace d’adressage d’un processus. En gris clair, les zones accessibles à tous les niveaux de privilèges : code du programme, bibliothèques, tas, pile. En gris foncé, la mémoire du noyau, réservée au mode privilégié.8.3. RISQUES 113 Les programmes utilisateur s’exécutant en ring 3, ils ne peuvent pas contenir d’instructions privilégiées, et donc ne peuvent pas accéder directement au matériel. Pour que ces programmes puissent interagir avec le système (afficher une sortie, écrire sur le disque. . . ), le mécanisme des appels système est nécessaire. Il s’agit d’une interface de haut niveau entre les rings 3 et 0. Du point de vue du programmeur, il s’agit d’un ensemble de fonctions C « magiques » qui font appel au système d’exploitation pour effectuer des opérations. Par exemple, le programmeur peut appeller la fonction getpid pour connaître le numéro du processus courant. Cela passe par une fonction getpid dans la bibliothèque C, en espace utilisateur. Celle-ci va invoquer (via un mécanisme non pertinent ici) la fonction sys_getpid du noyau (figure 8.2). Comme les piles sont différentes entre les espaces, la convention d’appel est différente : les arguments sont copiés directement par les registres. SYSCALL_DEFINE0(getpid) { return task_tgid_vnr(current); } FIGURE 8.2 : Fonction de définition d’un appel système La macro SYSCALL_DEFINE0 permet de nommer la fonction sys_getpid, et définit entre autres des points d’entrée pour les fonctionnalités de débogage du noyau. Le corps de la fonction fait directement référence aux structures de données internes du noyau pour retourner le résultat voulu. 8.3 Risques Ainsi que décrit dans la section 2.4, cela peut poser un problème de manipuler des pointeurs contrôlés par l’utilisateur au sein d’une routine de traitement d’appel système. Si le déréférencement est fait sans vérification, un utilisateur mal intentionné peut forger un pointeur vers le noyau (en déterminant des adresses valides dans l’espace noyau entre 0xc0000000 et 0xffffffff). En provoquant une lecture sur ce pointeur, des informations confidentielles peuvent fuiter ; et, en forçant une écriture, il est possible d’augmenter ses privilèges, par exemple en devenant super-utilisateur (root). En pratique, il n’est pas toujours possible d’accéder à la mémoire. La mémoire utilisateur peut par exemple avoir été placée en zone d’échange sur le disque, ou swap. À ce moment là, l’erreur provoquera tout de même un déni de service. Plus de détails sur ce mécanisme, et le fonctionnement de la mémoire virtuelle dans Linux, peuvent être trouvés dans [Jon10]. 8.4 Premier exemple de bug : pilote Radeon KMS On décrit le cas d’un pilote vidéo qui contenait un bug de pointeur utilisateur. Il est ré- pertorié sur http://freedesktop.org en tant que bug #29340. Pour changer de mode graphique, les pilotes de GPU peuvent supporter le Kernel Mode Setting (KMS). Pour configurer un périphérique, l’utilisateur communique avec le pilote noyau avec le mécanisme d’ioctls (pour Input/Output Control). Ils sont similaires à des appels système, mais spécifiques à un périphérique particulier. Le transfert de contrôle est similaire à ce qui a été décrit dans la section précédente : les applications utilisateurs appellent la fonction114 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX ioctl() de la bibliothèque standard, qui provoque une interruption. Celle-ci est traitée par la fonction sys_ioctl() qui appelle la routine de traitement dans le bon pilote de périphé- rique. Les fonctions du noyau implantant un ioctl sont donc vulnérables à la même classe d’attaques que les appels système, et donc doivent être écrites avec une attention particulière. Le code de la figure 8.3 est présent dans le pilote KMS pour les GPU AMD Radeon. /* drivers/gpu/drm/radeon/radeon_kms.c */ int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) { struct radeon_device *rdev = dev->dev_private; struct drm_radeon_info *info; struct radeon_mode_info *minfo = &rdev->mode_info; uint32_t *value_ptr; uint32_t value; struct drm_crtc *crtc; int i, found; info = data; value_ptr = (uint32_t *) ((unsigned long)info->value); /*=>*/ value = *value_ptr; /* ... */ } FIGURE 8.3 : Code de la fonction radeon_info_ioctl On peut voir que l’argument data est converti en un struct drm_radeon_info *. Un pointeur value_ptr est extrait de son champ value, et finalement ce pointeur est déréferencé. Cependant, l’argument data est un pointeur vers une structure (allouée en espace noyau) du type donné dans la figure 8.4, dont les champs proviennent d’un appel utilisateur de ioctl(). /* from include/drm/radeon_drm.h */ struct drm_radeon_info { uint32_t request; uint32_t pad; uint64_t value; }; FIGURE 8.4 : Définition de struct drm_radeon_info Pour mettre ce problème en évidence, nous avons annoté la fonction radeon_info_ioctl de telle manière que son second paramètre soit un pointeur noyau vers une structure contenant un champ contrôlé par l’utilisateur, value. L’intégralité de ce code peut être trouvée en annexe A. La bonne manière de faire a été publiée avec le numéro de commit d8ab3557 (figure 8.5) (DRM_COPY_FROM_USER étant une simple macro pour copy_from_user). Dans ce cas, on n’obtient pas d’erreur de typage.8.5. SECOND EXEMPLE : PTRACE SUR ARCHITECTURE BLACKFIN 115 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -112,7 +112,9 @@ info = data; value_ptr = (uint32_t *)((unsigned long)info->value); - value = *value_ptr; + if (DRM_COPY_FROM_USER(&value, value_ptr, sizeof(value))) + return -EFAULT; + switch (info->request) { case RADEON_INFO_DEVICE_ID: value = dev->pci_device; FIGURE 8.5 : Patch résolvant le problème de pointeur utilisateur. La ligne précédée par un signe - est supprimée et remplacée par les lignes précédées par un signe +. 8.5 Second exemple : ptrace sur architecture Blackfin Le noyau Linux peut s’exécuter sur l’architecture Blackfin, qui est spécialisée dans le traitement du signal. Le problème de manipulation des pointeurs utilisateur auquel nous nous intéressons peut également s’y produire. En particulier nous nous intéressons à l’appel système ptrace. Il permet à un processus d’accéder à la mémoire et de contrôler l’exécution d’un autre processus, par exemple à des fins de débogage. Ainsi, ptrace(PTRACE_PEEKDATA, p, addr) renvoie la valeur du mot mémoire à l’adresse addr dans l’espace d’adressage du processus p. Comme pour la plupart des appels système, la fonction ptrace est dépendante de l’architecture. Le deuxième exemple que nous présentons concerne l’implantation de celle-ci pour les processeurs Blackfin, figure 8.6. Dans d’anciennes versions de Linux 1, cette fonction appelle memcpy au lieu de copy_ from_user pour lire dans la mémoire du processus. La ligne problématique est préfixée par /*=>*/. En théorie, si un utilisateur passe un pointeur vers une adresse du noyau à la fonction ptrace, il pourra lire des données du noyau. L’appel ptrace (PTRACE_PEEKDATA, p, addr) permet ainsi non seulement de lire les variables du processus p si addr est une adresse dans l’espace utilisateur (ce qui est le comportement attendu), mais aussi de lire dans l’espace noyau si addr y pointe (ce qui est un bug de sécurité). On peut repérer ce bug par simple relecture pour commencer. On commence par remarquer que l’argument addr, malgré son type long, est en réalité un void * provenant directement de l’espace utilisateur. C’est en effet le même argument addr de l’appel système ptrace. Cet argument correspond à l’adresse à lire dans l’espace mémoire du processus. Comme il est passé à memcpy, aucune vérification n’est faite avant la copie. La valeur pointée par addr sera copiée, même si elle est en espace noyau. En annotant correctement les types, on peut donc détecter ce bug : le type correct de addr est INT @, et celui de memcpy est (INT ∗, INT ∗, INT) → INT ∗. Il est donc impossible de lui passer cet argument. Remarquons que le type de memcpy en C utilise des pointeurs de type 1. Jusqu’à la version 2.6.28 — ce bug a été corrigé dans le commit 7786ce82 en remplaçant l’appel à memcpy par un appel à copy_from_user_page.116 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX /* kernel/ptrace.c */ SYSCALL_DEFINE4(ptrace, long, request, long, pid, unsigned long, addr, unsigned long, data) { struct task_struct *child = ptrace_get_task_struct(pid); /* ... */ long ret = arch_ptrace(child, request, addr, data); /* ... */ return ret; } /* arch/blackfin/kernel/ptrace.c */ long arch_ptrace(struct task_struct *child, long request, long addr, long data) { int ret; unsigned long __user *datap = (unsigned long __user *)data; switch (request) { /* ... */ case PTRACE_PEEKTEXT: { unsigned long tmp = 0; int copied; ret = -EIO; /* ... */ if (addr >= FIXED_CODE_START && addr + sizeof(tmp) <= FIXED_CODE_END) { /*=>*/ memcpy(&tmp, (const void *)(addr), sizeof(tmp)); copied = sizeof(tmp); } /* ... */ ret = put_user(tmp, datap); break; /* ... */ } return ret; } FIGURE 8.6 : Implantation de ptrace sur architecture Blackfin8.6. PROCÉDURE EXPÉRIMENTALE 117 void *. Pour les traiter correctement on pourrait utiliser du polymorphisme, mais dans ce cas précis utiliser le type INT * est suffisant. Remarque En pratique, le problème de sécurité n’est pas si important. En effet, la copie se fait sous un test forçant addr à être entre FIXED_CODE_START et FIXED_CODE_END. Cette zone est incluse en espace utilisateur ; cela empêche donc le problème de fuite de données. Mais cela reste un problème de sécurité : contrairement à copy_from_user, la fonction memcpy ne vérifie pas que l’espace utilisateur est chargé en mémoire. Si ce n’est pas le cas, une faute mémoire sera provoquée dans le noyau. Il s’agit alors d’un déni de service (section 8.3), qui est tout de même un comportement à empêcher. 8.6 Procédure expérimentale Pour utiliser notre système de types, plusieurs étapes sont nécessaires en plus de traduire le noyau Linux en NEWSPEAK. Afin de réaliser l’analyse, il faut annoter les sources pour créer un environnement initial (les annotations possibles sont résumées dans un tableau page 102). Plus précisément, pour chaque source de pointeurs utilisateur, on ajoute un commentaire !npk userptr_fieldp x f, qui indique que x est un pointeur vers une structure contenant un pointeur utilisateur dans le champ f. En fait, il unifie le type de x avec {f : t @;...} ∗ où t est une inconnue de type. Cette annotation est nécessaire car c’est le moyen d’indiquer que la structure contient un pointeur utilisateur. Par rapport au code complet présent dans l’annexe A, l’expression calculant value_ptr est également simplifiée. Dans le code d’origine, info->value est transtypé en unsigned long puis en uint32_t *. En NEWSPEAK, cela correspond à des opérateurs PtrToInt et IntToPtr mais, si on les autorise, on casse le typage puisqu’il est alors possible de transformer n’importe quel type en un autre. De plus, on modifie la définition du type struct drm_radeon_info pour que son champ value ait pour type uint32_t * plutôt que uint64_t. En effet, dans ce cas d’étude, cet entier est uniquement utilisé en tant que pointeur au cours de toute l’exécution. En ce qui concerne les fonctions de manipulation de pointeurs fournies par le noyau (get_user, put_user, copy_from_user, copy_to_user, etc.), on ajoute à l’environnement global leur type correct. Enfin, on peut lancer l’inférence de type. Ainsi, sur l’exemple de la figure 8.7 (page 118), on obtient la sortie suivante : 05-drm.c:19#8 - Type clash between : KPtr (_a15) UPtr (_a8) Cela indique qu’on a essayé d’unifier un type de la forme t ∗ avec un type de la forme t @, en précisant l’emplacement où la dernière unification a échoué (les _aN correspondent à des inconnues de type). En effet, l’annotation de la ligne 10 donne à data le type {value : a @;...} ∗, où a est une nouvelle inconnue de type. La ligne 18 donne donc à value_ptr le type a @. Il y a donc une incompatibilité ligne 19 puisque l’instruction cherche à unifier le type de value_ptr avec b ∗ où b est une nouvelle inconnue de type. La variable value aurait alors le type b.118 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 typedef unsigned long uint32_t; struct drm_radeon_info { uint32_t *value; }; int radeon_info_ioctl(struct drm_device *d, void *data, struct drm_file *f) { /*!npk userptr_fieldp data value*/ struct drm_radeon_info *info; uint32_t *value_ptr; uint32_t value; struct drm_crtc *crtc; int i, found; info = data; value_ptr = info->value; value = *value_ptr; /* erreur */ return 0; } FIGURE 8.7 : Cas d’étude « Radeon » minimisé et annoté 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 typedef unsigned long uint32_t; struct drm_radeon_info { uint32_t *value; }; int radeon_info_ioctl(struct drm_device *d, void *data, struct drm_file *f) { /*!npk userptr_fieldp data value*/ struct drm_radeon_info *info; uint32_t *value_ptr; uint32_t value; struct drm_crtc *crtc; int i, found; info = data; value_ptr = info->value; if (copy_from_user(&value, value_ptr, sizeof(value))) return -14; return 0; } FIGURE 8.8 : Cas d’étude « Radeon » minimisé et annoté – version correcte8.6. PROCÉDURE EXPÉRIMENTALE 119 217 218 255 256 257 258 259 260 261 262 342 343 344 345 346 347 348 349 441 long arch_ptrace(struct task_struct *child, long request, long addr, long data) { /* ... */ if (addr >= FIXED_CODE_START && addr + sizeof(tmp) <= FIXED_CODE_END) { #if FIX copy_from_user_page(0, 0, 0, &tmp, (const void *)(addr), sizeof(tmp)); #else memcpy(&tmp, (const void *)(addr), sizeof(tmp)); #endif copied = sizeof(tmp); /* ... */ if (addr >= FIXED_CODE_START && addr + sizeof(data) <= FIXED_CODE_END) { #if FIX copy_to_user_page(0, 0, 0, (void *)(addr), &data, sizeof(data)); #else memcpy((void *)(addr), &data, sizeof(data)); #endif copied = sizeof(data); /* ... */ } FIGURE 8.9 : Cas d’étude « Blackfin » La version correcte minimisée correspond à la figure 8.8. Pour celle-ci, l’inférence se fait sans erreur. La partie pertinente est la suivante (une explication de la syntaxe est donnée dans la section 7.3, page 107)) : (06-drm-ok.c:19#8)^{ Int tmp_cir!0; (06-drm-ok.c:19#8)^tmp_cir!0 <- copy_from_user ( (focus32 (&(value) : KPtr (d)) : KPtr (d)): KPtr (d), (value_ptr_UPtr (d) : UPtr (d)): UPtr (d), (4 : Int): Int ); } En ce qui concerne l’exemple « Blackfin », on commence par isoler la fonction problématique. Celle-ci utilise de nombreuses constructions propres au noyau. On écrit donc un pré- ambule permettant de les traiter (définitions de type, etc). Ensuite, il est nécessaire de commenter certains appels à memcpy pour lesquelles les adresses sont testées dynamiquement (il n’est donc pas nécessaire d’utiliser les fonctions de copie sûres pour ces sites d’appel). La figure 8.9 montre le reste de la fonction, c’est-à-dire les parties sensibles. Dans le cas où FIX vaut 0, la sortie est la suivante :120 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX bf.c:260#32 - Type clash between : KPtr (Int) UPtr (_a122) Et quand FIX vaut 1, le programme annoté est affiché. Les parties correspondantes aux appels sensibles sont données dans la figurs 8.10. Conclusion Après voir décrit l’implantation de notre solution, on a montré comment celle-ci peut s’appliquer à détecter deux bugs dans le noyau Linux. La première difficulté est de traduire en NEWSPEAK le code source écrit dans le dialecte GNU C. Pour chaque bug, on montre que la version originale du code (incluant une erreur de programmation) ne peut pas être typée, alors que sur la version corrigée on peut inférer des types compatibles. Le prototype décrit dans le chapitre 7 peut donc s’adapter à détecter des bugs dans le noyau Linux. Pour le moment, il nécessite du code annoté, mais des travaux sont en cours pour permettre de passer automatiquement des portions plus importantes du noyau Linux. Le principal obstacle est de devoir réécrire certaines parties du code pour supprimer les constructions non typables.8.6. PROCÉDURE EXPÉRIMENTALE 121 (bf.c:255#3)^guard((! (((coerce[0,4294967295] (((coerce[0,4294967295] (addr_Int : Int) : Int) + (4 : Int)) : Int) : Int) > (1168 : Int)) : Int) : Int)); (bf.c:258#32)^{ Int tmp_cir!7; (bf.c:258#32)^tmp_cir!7 <- copy_from_user_page( (0 : Int): Int, (0 : Int): Int, (0 : Int): Int, (focus32 (&(tmp) : KPtr (Int)) : KPtr (Int)): KPtr (Int), ((ptr) (addr_Int : Int) : UPtr (Int)): UPtr (Int), (4 : Int): Int); } (bf.c:262#4)^copied =(int32) (4 : Int); ... (bf.c:342#28)^guard((! (((coerce[0,4294967295] (((coerce[0,4294967295] (addr_Int : Int) : Int) + (4 : Int)) : Int) : Int) > (1168 : Int)) : Int) : Int)); (bf.c:345#32)^{ Int tmp_cir!5; (bf.c:345#32)^tmp_cir!5 <- copy_to_user_page( (0 : Int): Int, (0 : Int): Int, (0 : Int): Int, ((ptr) (addr_Int : Int) : UPtr (Int)): UPtr (Int), (focus32 (&(data) : KPtr (Int)) : KPtr (Int)): KPtr (Int), (4 : Int): Int); } (bf.c:349#4)^copied =(int32) (4 : Int); FIGURE 8.10 : Traduction en NEWSPEAK du cas d’étude « Blackfin »CONCLUSION DE LA PARTIE III Après avoir décrit notre solution théorique dans la partie II, nous avons présenté ici notre démarche expérimentale. Dans le chapitre 7, nous avons détaillé l’implantation de notre prototype. Pour ce faire, nous avons ajouté des étiquettes de type au langage NEWSPEAK et implanté un algorithme d’inférence de types. Ce prototype est distribué sur [☞3] sous le nom de ptrtype. Ensuite, le but du chapitre 8 est d’appliquer notre analyse (à l’aide de ce prototype) sur le noyau Linux. Après avoir décrit le fonctionnement des appels système sur ce noyau, on présente deux bugs qui ont touché respectivement un pilote de carte graphique et l’implantation d’un appel système. Ils sont la manifestation d’un problème de pointeur utilisateur mal déréférencé dans le noyau, ainsi que décrit dans le chapitre 2. En lançant notre analyse sur le code présentant un problème, l’erreur est détectée. Au contraire, en la lançant sur le code après application du correctif, aucune erreur n’est trouvée. En s’appuyant sur le langage NEWSPEAK, on gagne beaucoup par rapport à d’autres représentations intermédiaires. Le fait d’avoir un langage avec peu de constructions permet de ne pas avoir à exprimer plusieurs fois la même règle (par exemple, une fois sur la boucle for et une autre sur la boucle while). Un des inconvénients de notre système est que le modèle mémoire utilisé par NEWSPEAK est assez différent de celui de SAFESPEAK (ainsi que décrit dans le chapitre 4). NEWSPEAK est en effet prévu pour implanter des analyses précises de valeur reposant sur l’interprétation abstraite, et nécessite donc un modèle mémoire de plus bas niveau (où on peut créer des valeurs à partir d’une suite d’octets, par exemple). Le prototype d’implantation peut évoluer dans deux directions : d’une part, en continuant à s’appuyer sur NEWSPEAK, on peut réaliser des pré-analyses de typage qui permettent de guider une analyse de valeurs plus précise, par exemple en choisissant un domaine abstrait différent en fonction des types de données rencontrés. D’autre part, il est possible de faire une implantation plus fidèle à SAFESPEAK, qui permette d’ajouter de nouvelles fonctionnalités plus éloignées de C. Par exemple, un système de régions comme [TJ92] permettrait de simplifier l’environnement d’exécution en enlevant l’opération de nettoyage mémoire Cleanup(·). Le système de types peut également être enrichi, pour ajouter par exemple du polymorphisme. Cela rapprocherait le langage source de Rust. Le chapitre 9 présente quelques unes de ces extensions possibles. L’expérimentation, quant à elle, est pour le moment limitée, mais on peut l’étendre à des domaines de plus en plus importants dans le noyau Linux. Tout d’abord, le module graphique définit d’autres fonctions implantant des ioctls. Celles-ci reçoivent donc également des pointeurs utilisateur et sont susceptibles d’être vulnérables à ce genre d’erreurs de programmation. Ensuite, d’autres modules exposent une interface similaire, à commencer par les autres pilotes de cartes graphiques. Ceux-ci sont également un terrain sur lequel appliquer cette analyse. De manière générale, toutes les interfaces du noyau manipulant des pointeurs utilisateur gagnent à être analysées. Outre les implantations des ioctls dans chaque pilote et les appels système, les systèmes de fichiers manipulent aussi de tels pointeurs via leurs opérations de lecture et d’écriture. 123C H A P I T R E 9 CONCLUSION On présente ici un résumé des travaux présentés, en commençant par un bilan des contributions réalisées. On réalise ensuite un tour des aspects posant problème, ou traités de manière incomplète, en évoquant les travaux possibles pour enrichir l’expressivité de ce système. 9.1 Contributions Cette thèse comporte 4 contributions principales. Un langage impératif bien typé Le système de types de C est trop rudimentaire pour permettre d’obtenir des garanties sur l’exécution des programmes bien typés. En interdisant certaines constructions dangereuses et en annotant certaines autres, nous avons isolé un langage impératif bien typable, SAFESPEAK, pour lequel on peut définir un système de types sûr. Une sémantique basée sur les lentilles Une des particularités de SAFESPEAK est qu’il utilise un état mémoire structuré, modélisant les cadres de piles présents dans le langage. Pour décrire la sémantique des accès mémoire, nous utilisons le concept de lentilles issues de la programmation fonctionnelle et des systèmes de bases de données. Cela permet de définir de manière déclarative la modification en profondeur de valeurs dans la mémoire, sans avoir à distinguer le cas de la lecture et celui de l’écriture. Un système de types abstraits En partant de ce système de types, on a décrit une extension permettant de créer des pointeurs pour lesquels l’opération de déréférencement est restreinte à certaines fonctions. Dans le contexte d’un noyau de système d’exploitation, cette restriction permet de vérifier statiquement qu’à aucun moment le noyau ne déréférence un pointeur dont la valeur est contrôlée par l’espace utilisateur, évitant ainsi un problème de sécurité. Cette approche peut s’étendre à d’autres classes de problèmes comme par exemple éviter l’utilisation de certaines opérations sur les types entiers lorsqu’ils sont utilisés comme identificateurs ou masque de bits. Un prototype d’analyseur statique Les analyses de typage ici décrites ont été implantées sous forme d’un prototype d’analyseur statique distribué avec le langage NEWSPEAK, développé par EADS. Le choix de NEWSPEAK pour l’implantation demande d’adapter les règles de 125126 CHAPITRE 9. CONCLUSION typage, mais il permet de réutiliser un traducteur existant et à l’entreprise de profiter des ré- sultats. Ce prototype permet d’une part de vérifier la propriété d’isolation des appels système sur du code C existant, et d’autre part fournit une base saine pour implanter d’autres analyses de typage sur le langage NEWSPEAK. Ce prototype a été utilisé pour confirmer l’existence de deux bugs dans le noyau Linux, ce qui permet de valider l’approche : il est possible de vérifier du code de production à l’aide de techniques de typage. Des travaux d’expérimentation sont en cours afin d’analyser de plus grandes parties du noyau. 9.2 Différences avec C SAFESPEAK a été construit pour pouvoir ajouter un système de types à un langage proche de C. Ces deux langages diffèrent donc sur certains points. On détaille ici ces différences et, selon les cas, comment les combler ou pourquoi cela est impossible de manière inhérente. Types numériques En C, on dispose de plusieurs types entiers, pouvant avoir plusieurs tailles et être signés ou non signés, ainsi que des types flottants qui diffèrent par leur taille. Au contraire, en SAFESPEAK on ne conserve qu’un seul type d’entier et un seul type de flottant. La raison pour cela est que nous ne nous intéressons pas du tout aux problématiques de sémantique arithmétique : les débordements, dénormalisations, etc, sont supposés ne pas arriver. Il est possible d’étendre le système de types de SAFESPEAK pour ajouter tous ces nouveaux types. La traduction depuis NEWSPEAK insère déjà des opérateurs de transtypage pour lesquels il est facile de donner une sémantique (pouvant lever une erreur en cas de débordement, comme en Ada) et un typage. Les littéraux numériques peuvent poser problème, puisqu’ils deviennent alors polymorphes. Une solution peut être de leur donner le plus grand type entier et d’insérer un opérateur de transtypage à chaque littéral. Haskell utilise une solution similaire : les littéraux entiers ont le type de précision arbitraire Integer et sont convertis dans le bon type en appelant la fonction fromInteger du type synthétisé à partir de l’environnement. Transtypage et unions Puisque l’approche retenue est basée sur le typage statique, il est impossible de capturer de nombreuses constructions qui sont permises, ou même idiomatiques, en C : les unions, les conversions de types (explicites ou implicites) et le type punning (défini ci-dessous). Les deux premières sont équivalentes. Bien qu’on puisse remplacer chaque conversion explicite d’un type t1 vers un type t2 par l’appel à une fonction castt1,t2 , on ajoute alors un « trou » dans le système de types. Cette fonction devrait en effet être typée (t1) → t2, autrement dit le type « maudit » α → β de Obj.magic en OCaml ou unsafeCoerce en Haskell. Le type punning consiste à modifier directement la suite de bits de certaines données pour la manipuler d’une manière efficace. Par exemple, il est commun de définir un ensemble de macros pour accéder à la mantisse et à l’exposant de flottants IEEE754. Ceci peut être fait avec des unions ou des masques de bits. Dans de tels cas, le typage statique est bien sûr impossible. Pour traiter ces cas, il faudrait encapsuler la manipulation dans une fonction et y ajouter une information de type explicite, comme float_exponent : (FLOAT) → INT. Pour ces conversions de types, on distingue en fait plusieurs cas : les conversions entre types numériques, entre types pointeurs, ou entre un type entier et un type pointeur.9.2. DIFFÉRENCES AVEC C 127 Le premier ne pose pas de problème : il est toujours possible de donner une sémantique à une conversion entre deux types numériques, quitte à détecter les cas où il faut signaler une erreur à l’exécution (comme en cas de débordement). Le deuxième non plus n’est pas un problème en soi : une conversion entre deux types pointeurs revient à convertir entre les types pointés (il faut bien sûr interdire les conversions entre pointeurs noyau et utilisateur). Le vrai problème provient des conversions entre entiers et pointeurs, qui sont des données fondamentalement différentes. Le même problème se pose d’ailleurs si on cherche à convertir une fonction en entier ou en pointeur, même si les raisons valables pour faire cela sont moins nombreuses. Si on s’en tient aux conversions entre entiers et pointeurs, une manière naïve de typer ces opérations est : Γ � e : t ∗ Γ � (INT) e : INT (PTRINT-BAD) Γ � e : INT Γ � (PTR) e : t ∗ (INTPTR-BAD) Tout d’abord, cela pose problème car il est alors possible de créer une fonction pouvant convertir n’importe quel type pointeur en n’importe quel autre type pointeur : � fun(p){RETURN((PTR) (INT) p)} : (ta ∗) → tb ∗ Si on crée une variable du type ta, prend son adresse, la convertit à l’aide de cette fonction, puis déréférence le résultat, on obtient une valeur du type tb (remarquons que ce genre d’opération est tout à fait possible en C). Outre ce problème de typage, il faudrait pouvoir donner une sémantique à ces opérations. Convertir un pointeur en entier revient à spécifier l’environnement d’exécution, c’est-à-dire qu’il faut une fonction de placement en mémoire beaucoup plus précise que notre modèle mémoire actuel. Celle-ci dépend de beaucoup de paramètres : dans quel sens croit la pile, quelle est la taille des types, etc. La conversion dans le sens inverse, d’entier vers pointeur, est encore plus complexe. Entre autres, cela suppose qu’on puisse retrouver la taille des valeurs à partir de leur adresse. Dans de nombreux langages, on résout ce problème en stockant la taille de chaque valeur avec elle. Mais cela fait s’éloigner du modèle mémoire de C, où le déréférencement porte sur une adresse mais également sur une taille (portée implicitement par le type du pointeur). Le langage NEWSPEAK conserve d’ailleurs cette distinction, que nous avons éliminée dans SAFESPEAK. Il y a une incompatibilité entre ces deux approches : dans le cas de C (et de NEWSPEAK), on laisse le programmeur gérer l’organisation de la mémoire alors qu’avec SAFESPEAK ces choix sont faits par le langage. En contrepartie, cela permet d’avoir d’assurer la sûreté du typage. Environnement d’exécution La sémantique opérationnelle utilise un environnement d’exécution pour certains cas. Contrairement à C, les débordements de tampon et les déréfé- rencements de pointeurs sont vérifiés dynamiquement. Mais ce n’est pas une caractéristique cruciale de cette approche : en effet, si on suppose que les programmes que l’on analyse ne comportent pas de telles erreurs de programmation, on peut désactiver ces vérifications et le reste des propriétés est toujours valable. On repose sur l’environnement d’exécution à un endroit plus problématique. À la sortie de chaque portée (au retour d’une fonction et après la portée d’une variable locale déclarée), on parcourt la mémoire à la recherche des pointeurs référençant les variables qui ne sont plus128 CHAPITRE 9. CONCLUSION valides. Supprimer ce test rend l’analyse incorrecte, car il est alors possible de faire référence à une variable avec un type différent. Si on peut avoir une garantie statique que les adresses des variables locales ne seront plus accessibles au retour d’une fonction, alors on peut supprimer cette étape de nettoyage. Cette garantie peut être obtenue avec une analyse statique préalable. Par exemple les régions [TJ92] peuvent être utilisées à cet effet : en plus de donner un type à chaque expression, on calcule statiquement la zone mémoire dans laquelle cette valeur sera allouée. Cela correspond à un ramasse-miette réalisé statiquement. Flot de contrôle Dans le langage C, en plus des boucles et de l’alternative, on peut sauter d’une instruction à l’autre au sein d’une fonction à l’aide de la construction goto. Pour pouvoir traiter ces cas, il est possible de transformer ces sauts d’un programme vers des simples boucles. Cette réécriture peut être coûteuse puisqu’elle peut introduire des variables booléennes et dupliquer du code. En pratique, c’est d’ailleurs ce qui est fait dans l’implantation puisque cette transformation est réalisée par C2NEWSPEAK. Dans le noyau Linux, il est courant d’utiliser les sauts pour factoriser la libération de ressources à la fin d’une fonction. Il est d’ailleurs possible d’utiliser l’outil Coccinelle pour donner cette forme à du code utilisant un autre style de structures de contrôle [SLM11]. On peut imaginer qu’il est possible de l’utiliser pour faire la conversion inverse. En plus de ces sauts locaux, le langage C contient une manière de sauvegarder un état d’exécution et d’y sauter, même entre deux fonctions : ce sont respectivement les constructions setjmp et longjmp. Elles sont très puissantes puisqu’elles permettent d’exprimer de nouvelles structures de contrôle. Il s’agit de formes légères de continuations où la pile reste commune. Cette fonctionnalité peut servir par exemple à implanter des exceptions ou des coroutines. Avec l’interprète du chapitre 4, il n’est pas possible de donner une sémantique à ces constructions. Une des manières de faire est de modifier les états de l’interprète : au lieu de retenir l’instruction à évaluer avec 〈i,m〉, on retient la continuation complète : 〈k,m〉. Pour faciliter ce changement, on peut tout d’abord passer à une sémantique monadique (ainsi qu’évoqué dans la conclusion de la partie II, page 95) puis ajouter les continuations à la monade sous-jacente. En pratique, il est rare de trouver ces constructions plus avancées dans du code noyau ou embarqué, donc ce manque n’a pas beaucoup d’impact. De plus, cela permet une présentation plus simple et accessible. Allocation dynamique La plupart des programmes, et le noyau Linux en particulier, utilisent la notion d’allocation dynamique de mémoire. C’est une manière de créer dynamiquement une zone de mémoire qui restera accessible après l’exécution de la fonction courante. Cette mémoire pourra être libérée à l’aide d’une fonction dédiée. Dans l’espace utilisateur, les programmes peuvent utiliser les fonctions malloc(), calloc() et realloc() pour allouer des zones de mémoire et free() pour les libérer. Dans le noyau Linux, ces fonctions existent sous la forme de kmalloc(), kfree(), etc. Une explication détaillée de ces mécanismes peut être trouvée dans [Gor04]. Ces fonctions manipulent les données en tant que zones mémoires opaques, en renvoyant un pointeur vers une zone mémoire d’un nombre d’octets donnés. Cela présuppose un modèle mémoire de plus bas niveau. Pour se rapprocher de la sémantique de SAFESPEAK, une manière de faire est de définir un opérateur de plus haut niveau prenant une expression et retournant l’adresse d’une cellule mémoire contenant cette valeur (la taille de chaque9.3. PERSPECTIVES 129 valeur fait partie de celle-ci), ou NULL si l’allocation échoue. Le typage est alors direct (on suppose que FREE(e) est une instruction : Γ � e : t Γ � NEW(e) : t ∗ (NEW ) Γ � e : t ∗ Γ � FREE(e) (FREE) En ce qui concerne l’exécution, on peut ajouter une troisième composante aux états mé- moire : m = (s, g ,h) où h est une liste d’association entre des identifiants uniques et des valeurs. Chaque allocation dynamique crée une nouvelle clef entière et met à jour h. La libération de mémoire est en revanche problématique parce qu’il faut faire confiance au programmeur pour ne pas accéder aux zones mémoires libérées, ni libérer deux fois la même zone mémoire. Il est aussi possible d’obtenir cette garantie avec une analyse préalable. Par exemple, il est possible ici encore d’utiliser une analyse basée sur les régions pour vérifier l’absence de pointeurs fous [DDMP10]. 9.3 Perspectives L’importance des logiciels grandit par deux effets : d’une part, ils sont présents dans de plus en plus d’appareils et, d’autre part, leur taille est de plus en plus importante. En une journée, entre les appareils dédiés au calcul, à la communication, au multimédia et au transport, on est facilement exposé au fonctionnement de plus d’une dizaine de millions de lignes de code. Il donc primordial de vérifier que ces logiciels ne peuvent pas être détournés de leur utilisation prévue. Dans le cas de logiciels avioniques ou militaires, les conséquences peuvent en effet être catastrophiques. C’est dans ce contexte industriel que ce travail a été motivé et réalisé. Au cœur de la plupart de ces systèmes informatiques se trouve un noyau qui abstrait les détails du matériel pour fournir aux programmes des abstractions sûres, permettant de protéger les données sensibles contenues dans ce système. Puisqu’une simple erreur de programmation peut briser cette isolation, on voit pourquoi la vérification est si importante. Dans ce but, les systèmes de types sont des outils bien connus de programmeurs. Même dans les langages peu typés comme C, les compilateurs aident de plus en plus les programmeurs à trouver des erreurs de programmation. De très nombreuses analyses peuvent être faites rien qu’en classant les expressions selon le genre de valeurs qu’elles créent à l’exécution — c’est la définition que donne Benjamin C. Pierce d’un système de types [Pie02]. L’utilisation d’un système de types comme analyseur statique léger est donc efficace. Pour des propriétés qui ne dépendent pas de la valeur des expressions, mais uniquement de leur forme, c’est d’ailleurs la solution à préférer. En effet, nous avons montré qu’elle est simple à mettre en œuvre et rapide à exécuter. On peut se poser la question suivante : pourquoi a-t-on besoin d’une analyse statique dé- diée, plutôt que de passer par le langage C lui-même ? Le problème vient du fait que celui-ci considère que les types définissent une représentation en mémoire sans guère plus d’information. On peut définir de nouveaux noms pour un type, mais l’ancien et le nouveau sont alors compatibles. En un mot il est impossible de distinguer le rôle d’un type (son intention) de sa représentation (son extension). Ici, nous avons proposé une solution au problème de pointeurs utilisateur en introduisant un type ayant la même représentation que les pointeurs classiques, mais pour lequel l’ensemble des opérations est différent : c’est un type opaque. Cela suffit déjà à détecter des erreurs de programmation.130 CHAPITRE 9. CONCLUSION Si on ajoutait cette construction au langage, on pourrait définir de nouveaux types partageant la représentation d’un type C existant, mais qui ne soit pas compatible avec le type d’origine. Avec cette fonctionnalité dans un langage, non seulement on peut détecter d’autres classes de problèmes, mais surtout on laisse le programmeur définir de nouvelles analyses lui-même en modélisant les problèmes concrets par des types.Annexes 131A N N E X E A MODULE RADEON KMS On inclut ici le code analysé dans le chapitre 8. On inclut à la suite le contexte nécessaire pour comprendre ce code. /* from drivers/gpu/drm/radeon/radeon_kms.c */ int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) { struct radeon_device *rdev = dev->dev_private; struct drm_radeon_info *info; struct radeon_mode_info *minfo = &rdev->mode_info; uint32_t *value_ptr; uint32_t value; struct drm_crtc *crtc; int i, found; info = data; value_ptr = (uint32_t *)((unsigned long)info->value); value = *value_ptr; switch (info->request) { case RADEON_INFO_DEVICE_ID: value = dev->pci_device; break; case RADEON_INFO_NUM_GB_PIPES: value = rdev->num_gb_pipes; break; case RADEON_INFO_NUM_Z_PIPES: value = rdev->num_z_pipes; break; case RADEON_INFO_ACCEL_WORKING: /* xf86-video-ati 6.13.0 relies on this being false for evergreen */ if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) value = false; else value = rdev->accel_working; break; case RADEON_INFO_CRTC_FROM_ID: for (i = 0, found = 0; i < rdev->num_crtc; i++) { crtc = (struct drm_crtc *)minfo->crtcs[i]; if (crtc && crtc->base.id == value) { struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc); value = radeon_crtc->crtc_id; 133134 ANNEXE A. MODULE RADEON KMS found = 1; break; } } if (!found) { DRM_DEBUG_KMS("unknown crtc id %d\n", value); return -EINVAL; } break; case RADEON_INFO_ACCEL_WORKING2: value = rdev->accel_working; break; case RADEON_INFO_TILING_CONFIG: if (rdev->family >= CHIP_CEDAR) value = rdev->config.evergreen.tile_config; else if (rdev->family >= CHIP_RV770) value = rdev->config.rv770.tile_config; else if (rdev->family >= CHIP_R600) value = rdev->config.r600.tile_config; else { DRM_DEBUG_KMS("tiling config is r6xx+ only!\n"); return -EINVAL; } case RADEON_INFO_WANT_HYPERZ: mutex_lock(&dev->struct_mutex); if (rdev->hyperz_filp) value = 0; else { rdev->hyperz_filp = filp; value = 1; } mutex_unlock(&dev->struct_mutex); break; default: DRM_DEBUG_KMS("Invalid request %d\n", info->request); return -EINVAL; } if (DRM_COPY_TO_USER(value_ptr, &value, sizeof(uint32_t))) { DRM_ERROR("copy_to_user\n"); return -EFAULT; } return 0; } /* from include/drm/radeon_drm.h */ struct drm_radeon_info { uint32_t request; uint32_t pad; uint64_t value; }; /* from drivers/gpu/drm/radeon/radeon_kms.c */ struct drm_ioctl_desc radeon_ioctls_kms[] = { /* KMS */ DRM_IOCTL_DEF(DRM_RADEON_INFO, radeon_info_ioctl, DRM_AUTH|DRM_UNLOCKED)135 }; /* from drivers/gpu/drm/radeon/radeon_drv.c */ static struct drm_driver kms_driver = { .driver_features = DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG | DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED | DRIVER_GEM, .dev_priv_size = 0, .ioctls = radeon_ioctls_kms, .name = "radeon", .desc = "ATI Radeon", .date = "20080528", .major = 2, .minor = 6, .patchlevel = 0, }; /* from drivers/gpu/drm/drm_drv.c */ int drm_init(struct drm_driver *driver) { DRM_DEBUG("\n"); INIT_LIST_HEAD(&driver->device_list); if (driver->driver_features & DRIVER_USE_PLATFORM_DEVICE) return drm_platform_init(driver); else return drm_pci_init(driver); }A N N E X E B SYNTAXE ET RÈGLES D’ÉVALUATION On rappelle ici pour référence la syntaxe de SAFESPEAK, ainsi que sa sémantique d’évaluation. Les règles sont décrites dans les chapitres 4 et 6. B.1 Syntaxe des expressions Constantes c ::= n Entier | d Flottant | NULL Pointeur nul | ( ) Valeur unité Expressions e ::= c Constante | � e Opération unaire | e � e Opération binaire | l v Accès mémoire | l v ← e Affectation | &l v Pointeur | f Fonction | e(e1,...,en) Appel de fonction | {l1 : e1;...;ln : en} Structure | [e1;...;en] Tableau Valeurs gauches l v ::= x Variable | l v.lS Accès à un champ | l v[e] Accès à un élément | ∗e Déréférencement Fonctions f ::= fun(x1,...,xn){i} Arguments, corps 137138 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION B.2 Syntaxe des instructions Instructions i ::= PASS Instruction vide | i;i Séquence | e Expression | DECL x = e IN{i} Déclaration de variable | IF(e){i}ELSE{i} Alternative | WHILE(e){i} Boucle | RETURN(e) Retour de fonction Phrases p ::= x = e Variable globale | e Évaluation d’expression Programme P ::= (p1,...,pn) Phrases B.3 Syntaxe des opérateurs Opérateurs binaires � ::= +,−,×,/,% Arithmétique entière | +.,−.,×.,/. Arithmétique flottante | +p,−p Arithmétique de pointeurs | ≤,≥,<,> Comparaison sur les entiers | ≤ .,≥ .,< .,> . Comparaison sur les flottants | =,�= Tests d’égalité | &,|,^ Opérateurs bit à bit | &&,|| Opérateurs logiques | �,� Décalages Opérateurs unaires � ::= +,− Arithmétique entière | +.,−. Arithmétique flottante | ∼ Négation bit à bit | ! Négation logiqueB.4. CONTEXTES D’ÉVALUATION 139 B.4 Contextes d’évaluation Contextes C ::= • | C � e | v � C | � C | & C | C ← e | ϕ ←C | {l1 : v1;...;li :C;...;ln : en} | [v1;...;C;...;en] | C(e1,...,en) | f (v1,...,C,...,en) | C.lS | C[e] | ϕ[C] | ∗ C | C;i | IF(C){i1}ELSE{i2} | RETURN(C) | DECL x = C IN{i} B.5 Règles d’évaluation des erreurs Ξ → Ω 〈Ω,m〉 → Ω (EXP-ERR) 〈e,m〉 → Ω 〈C�e�,m〉 → Ω (EVAL-ERR) 〈i,m〉 → Ω 〈DECL x = v IN{i},m〉 → Ω (DECL-ERR) m� = Push(m, ((a1 �→ v1),..., (an �→ vn))) 〈i,m� 〉 → Ω 〈fun(a1,...,an){i}(v1,..., vn),m〉 → Ω (EXP-CALL-ERR)140 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION B.6 Règles d’évaluation des valeurs gauches et expressions 〈l v,m〉 → 〈ϕ,m〉 a = Lookup(x,m) 〈x,m〉 → 〈a,m〉 (PHI-VAR) v = &� ϕ 〈∗ v,m〉 → 〈ϕ,m〉 (EXP-DEREF) v = N �ULL 〈∗ v,m〉 → Ωp t r (EXP-DEREF-NULL) 〈ϕ.lS,m〉 → 〈ϕ�.l,m〉 (PHI-STRUCT) 〈ϕ[n],m〉 → 〈ϕ[ �n],m〉 (PHI-ARRAY) 〈e,m〉 → 〈v,m〉 〈c,m〉 → 〈c�,m〉 (EXP-CST) 〈f ,m〉 → 〈f �,m〉 (EXP-FUN) 〈ϕ,m〉 → 〈m[ϕ]Φ,m〉 (EXP-LV ) 〈� v,m〉 → 〈�� v,m〉 (EXP-UNOP) 〈v1 � v2,m〉 → 〈v1 �� v2,m〉 (EXP-BINOP) 〈& ϕ,m〉 → 〈&� ϕ,m〉 (EXP-ADDR) 〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉 (EXP-SET) 〈{l1 : v1;...;ln : vn},m〉 → 〈{l1 : v�1;...;ln : vn},m〉 (EXP-STRUCT) 〈[v1;...; vn],m〉 → 〈[v�1;...; vn],m〉 (EXP-ARRAY) m� = Cleanup(m) v� = CleanV|m|(v) 〈fun(a1,...,an){RETURN(v)}(v1,..., vn),m〉 → 〈v� ,m� 〉 (EXP-CALL-RETURN) 〈e,m〉 → 〈e� ,m� 〉 〈i,m〉 → 〈i � ,m� 〉 〈C�i�,m〉 → 〈C�i � �,m� 〉 (CTX) m1 = Push(m0, ((a1 �→ v1),..., (an �→ vn))) 〈i,m1〉 → 〈i � ,m2〉 ∀i ∈ [1;n], v� i = m2[(|m2|,ai)]A m3 = Pop(m2) 〈fun(a1,...,an){i}(v1,..., vn),m0〉 → 〈fun(a1,...,an){i � }(v� 1,..., v� n),m3〉 (EXP-CALL-CTX)B.7. RÈGLES D’ÉVALUATION DES INSTRUCTIONS, PHRASES ET PROGRAMMES 141 B.7 Règles d’évaluation des instructions, phrases et programmes 〈i,m〉 → 〈i� ,m〉 〈(PASS;i),m〉 → 〈i,m〉 (SEQ) 〈v,m〉 → 〈PASS,m〉 (EXP) m� = CleanVar(m − x, (|m|,x)) 〈DECL x = v IN{PASS},m〉 → 〈PASS,m� 〉 (DECL-PASS) m� = CleanVar(m − x, (|m|,x)) v�� = CleanVarV(v� , (|m|,x)) 〈DECL x = v IN{RETURN(v� )},m〉 → 〈RETURN(v��),m� 〉 (DECL-RETURN) m� = Extend(m,x �→ v) 〈i,m� 〉 → 〈i � ,m��〉 v� = m��[(|m��|,x)]A m��� = m�� − x 〈DECL x = v IN{i},m〉 → 〈DECL x = v� IN{i � },m���〉 (DECL-CTX) 〈IF(0){it }ELSE{if },m〉 → 〈if ,m〉 (IF-FALSE) v �= 0 〈IF(v){it }ELSE{if },m〉 → 〈it ,m〉 (IF-TRUE) 〈WHILE(e){i},m〉 → 〈IF(e){i;WHILE(e){i}}ELSE{PASS},m〉 (WHILE) 〈RETURN(v);i,m〉 → 〈RETURN(v),m〉 (RETURN) m � p → m� 〈e,m〉 → 〈v,m� 〉 m � e → m� (ET-EXP) 〈e,m〉 → 〈v,m� 〉 m� = (s, g ) m�� = (s, (x �→ v) :: g ) m � x = e → m�� (ET-VAR) � P →∗ m ([ ], [ ]) � p1 → m1 m1 � p2 → m2 ... mn−1 � pn → mn � p1,...,pn →∗ m (PROG)142 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION B.8 Règles d’évaluation des extensions noyau 〈♦ ϕ,m〉 → 〈& ( � ♦� ϕ),m〉 (PHI-USER) v = m[ϕs]Φ m� = m[ϕd ← v]Φ 〈copy_from_user(&� ϕd ,& ( � ♦� ϕs)),m〉 → 〈0,m� 〉 (USER-GET-OK) � ϕs.ϕ = ♦� ϕs 〈copy_from_user(&� ϕd ,&� ϕ),m〉 → 〈−14,m〉 (USER-GET-ERR) v = m[ϕs]Φ m� = m[ϕd ← v]Φ 〈copy_to_user(& ( � ♦� ϕd ),&� ϕs),m〉 → 〈0,m� 〉 (USER-PUT-OK) � ϕd .ϕ = ♦� ϕd 〈copy_to_user(&� ϕ,&� ϕs),m〉 → 〈−14,m〉 (USER-PUT-ERR)A N N E X E C RÈGLES DE TYPAGE On rappelle ici l’ensemble des règles de typage décrites dans les chapitres 5 et 6. C.1 Règles de typage des constantes et valeurs gauches Γ � c : t Γ � n : INT (CST-INT) Γ � d : FLOAT (CST-FLOAT) Γ � NULL : t ∗ (CST-NULL) Γ � ( ) : UNIT (CST-UNIT) Γ � l v : t x : t ∈ Γ Γ � x : t (LV-VAR) Γ � e : t ∗ Γ � ∗e : t (LV-DEREF) Γ � e : INT Γ � l v : t[ ] Γ � l v[e] : t (LV-INDEX) (l,t) ∈ S Γ � l v : S Γ � l v.lS : t (LV-FIELD) 143144 ANNEXE C. RÈGLES DE TYPAGE C.2 Règles de typage des opérateurs Γ � � e : t Γ � e : INT Γ � +e : INT (UNOP-PLUS-INT) Γ � e : FLOAT Γ � +.e : FLOAT (UNOP-PLUS-FLOAT) Γ � e : INT Γ � −e : INT (UNOP-MINUS-INT) Γ � e : FLOAT Γ � −.e : FLOAT (UNOP-MINUS-FLOAT) � ∈ {∼,!} Γ � e : INT Γ � � e : INT (UNOP-NOT) Γ � e1 � e2 : t � ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>} Γ � e1 : INT Γ � e2 : INT Γ � e1 � e2 : INT (OP-INT) � ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .} Γ � e1 : FLOAT Γ � e2 : FLOAT Γ � e1 � e2 : FLOAT (OP-FLOAT) � ∈ {=,�=} Γ � e1 : t Γ � e2 : t EQ(t) Γ � e1 � e2 : INT (OP-EQ) � ∈ {+p,−p} Γ � e1 : t ∗ Γ � e2 : INT Γ � e1 � e2 : t ∗ (PTR-ARITH) EQ(t) t ∈ {INT, FLOAT} EQ(t) (EQ-NUM) EQ(t ∗) (EQ-PTR) EQ(t) EQ(t[ ]) (EQ-ARRAY) ∀i ∈ [1;n].EQ(ti) EQ({l1 : t1;...ln : tn}) (EQ-STRUCT)C.3. RÈGLES DE TYPAGE DES EXPRESSIONS ET INSTRUCTIONS 145 C.3 Règles de typage des expressions et instructions Γ � e : t Γ � l v : t Γ � &l v : t ∗ (ADDR) ∀i ∈ [1;n],Γ � ei : ti Γ � {l1 : e1;...;ln : en} : {l1 : t1;...;ln : tn} (STRUCT) Γ � e : (t1,...,tn) → t ∀i ∈ [1;n],Γ � ei : ti Γ � e(e1,...,en) : t (CALL) Γ � l v : t Γ � e : t Γ � l v ← e : t (SET) ∀i ∈ [1;n],Γ � ei : t Γ � [e1;...;en] : t[ ] (ARRAY) Γ = (ΓG ,ΓL) Γ� = (ΓG , [a1 : t1;...;an : tn;R : t]) Γ� � i Γ � fun(a1,...,an){i} : (t1,...,tn) → t (FUN) Γ � i Γ � PASS (PASS) Γ � i1 Γ � i2 Γ � i1;i2 (SEQ) Γ � e : t Γ � e (EXP) Γ � e : t Γ,local x : t � i Γ � DECL x = e IN{i} (DECL) Γ � e : INT Γ � i1 Γ � i2 Γ � IF(e){i1}ELSE{i2} (IF) Γ � e : INT Γ � i Γ � WHILE(e){i} (WHILE) R : t ∈ Γ Γ � e : t Γ � RETURN(e) (RETURN) Γ � p → Γ� Γ � e : t Γ � e → Γ (T-EXP) Γ � e : t Γ� = Γ, global x : t Γ � x = e → Γ� (T-VAR) Γ � P [ ] � p1 → Γ1 Γ1 � p2 → Γ2 ... Γn−1 � pn → Γn � p1,...,pn (PROG)146 ANNEXE C. RÈGLES DE TYPAGE C.4 Règles de typage des valeurs m � v : τ m � n : INT (S-INT) m � d : FLOAT (S-FLOAT) m � ( ) : UNIT (S-UNIT) m � NULL : τ ∗ (S-NULL) m �Φ ϕ : τ m � &� ϕ : τ ∗ (S-PTR) ∀i ∈ [1;n].m � vi : τ m � [v�1;...; vn] : τ[ ] (S-ARRAY) ∀i ∈ [1;n].m � vi : τi m � {l1 : v�1;...;ln : vn} : {l1 : τ1;...;ln : τn} (S-STRUCT) m � fun(x1,...,xn){i} : FUNn (S-FUN) C.5 Règles de typage des extensions noyau Γ � l v : t Γ � ♦ l v : t @ (ADDR-USER) Γ � ed : t ∗ Γ � es : t @ Γ � copy_from_user(ed ,es) : INT (USER-GET) Γ � ed : t @ Γ � es : t ∗ Γ � copy_to_user(ed ,es) : INT (USER-PUT)A N N E X E D PREUVES On présente ici les preuves de certains résultats établis dans le manuscrit : le caractère bien fondé de la composition de deux lentilles, et les théorèmes de sûreté du typage. D.1 Composition de lentilles Démonstration. On cherche à prouver que, si L1 ∈ LENSA,B et L2 ∈ LENSB,C , alors L = L1≫L2 ∈ LENSA,C (≫est la composition de lentilles, définie page 39). Il suffit pour cela d’établir les trois propriétés caractéristiques qui définissent les lentilles : PUTPUT, GETPUT et PUTGET. Cela est essentiellement calculatoire : on utilise la définition de ≫et les propriétés caractéristiques sur L1 et L2. PutPut putL (a� ,putL (a, r )) = putL (a� ,putL1 (putL2 (a, getL1 (r )), r )) { définition de putL } = putL1 (putL2 (a� , getL1 (putL1 (putL2 (a, getL1 (r )), r ))),putL1 (putL2 (a, getL1 (r )), r )) { définition de putL } = putL1 (putL2 (a� ,putL2 (a, getL1 (r ))),putL1 (putL2 (a, getL1 (r )), r )) { GETPUT sur L1 } = putL1 (putL2 (a� , getL1 (r )),putL1 (putL2 (a, getL1 (r )), r )) { PUTPUT sur L2 } = putL1 (putL2 (a� , getL1 (r )), r ) { PUTPUT sur L1 } = putL (a� , r ) { définition de≫} 147148 ANNEXE D. PREUVES GetPut putL (getL (r ), r ) = putL (getL2 (getL1 (r )), r ) { définition de getL } = putL1 (putL2 (getL2 (getL1 (r )), getL1 (r )), r ) { définition de putL } = putL1 (getL1 (r ), r ) { GETPUT sur L2 } = r { GETPUT sur L1 } PutGet getL (putL (a, r )) = getL2 (getL1 (putL (a, r ))) { définition de getL } = getL2 (getL1 (putL1 (putL2 (a, getL1 (r )), r ))) { définition de putL } = getL2 (putL2 (a, getL1 (r ))) { PUTGET sur L1 } = a { PUTGET sur L2 } D.2 Progrès On rappelle l’énoncé du théorème 5.1. Théorème D.1 (Progrès). Supposons que Γ � i. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants est vrai : • i = PASS • ∃v,i = RETURN(v) • ∃(i� ,m� ),〈i,m〉 → 〈i� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈i,m〉 → Ω � � � Supposons que Γ � e : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivant est vrai : • ∃v �= Ω,e = v • ∃(e� ,m� ),〈e,m〉 → 〈e� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈e,m〉 → Ω � � � Supposons que Γ � l v : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants est vrai : • ∃ϕ,l v = ϕ • ∃(l v� ,m� ),〈l v,m〉 → 〈l v� ,m� 〉 • ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈l v,m〉 → Ω C’est-à-dire, soit : • l’entité (instruction, expression ou valeur gauche) est complètement évaluée. • un pas d’évaluation est possible. • une erreur de division, tableau ou pointeur se produit.D.2. PROGRÈS 149 Démonstration. On procède par induction sur la dérivation du jugement de typage. Puisque les jugements Γ � i, Γ � e : t et Γ � l v : t sont interdépendants, on traite tous les cas par récursion mutuelle. Le squelette de cette preuve est une analyse de cas selon la dernière règle utilisée. La plupart des cas ont la même forme : on utilise l’hypothèse de récurrence sur les sous-éléments syntaxiques (en appliquant éventuellement le lemme 5.1 d’inversion pour établir qu’ils sont bien typés). Dans le cas « valeur », on appelle une règle qui permet de transformer une opé- ration syntaxique en opération sémantique (par exemple, on transforme le + unaire en un +� sémantique). Dans le cas « évaluation », on applique la règle CTX avec un contexte particulier qui permet de passer d’un jugement 〈a,m〉 → 〈a� ,m� 〉 à un jugement 〈b,m〉 → 〈b� ,m� 〉 (où a apparaît dans b). Enfin, dans le cas « erreur », on utilise EVAL-ERR avec ce même contexte C. Ceci est valable pour la majorité des cas. Il faut faire attention en particulier aux opé- rations sémantiques qui peuvent produire des erreurs (comme la division, ou l’opérateur Lookup(·,·)). Instructions PASS : Ce cas est immédiat. RETURN : Partant de i = RETURN(e), on applique le lemme d’inversion. Il nous donne l’existence de t tel que Γ � e : t. On applique alors l’hypothèse de récurrence à e. • e = v. Alors i = RETURN(v), ce qui nous permet de conclure. • 〈e,m〉 → 〈e� ,m� 〉. Alors en appliquant CTX avec C = RETURN(•) 1, on conclut que 〈RETURN(e),m〉 → 〈RETURN(e� ),m� 〉. • 〈e,m〉 → Ω. On applique EVAL-ERR avec ce même C. SEQ : Avec i = i1;i2, on applique l’hypothèse de récurrence à i1. • i1 = PASS. On peut donc appliquer la règle SEQ et donc 〈i,m〉 → 〈i2,m〉. • i1 = RETURN(v). Alors on peut appliquer la règle RETURN : 〈i,m〉 → 〈RETURN(v),m〉. • 〈i1,m〉 → 〈i� 1,m� 〉. Soit C = •;i2. Par CTX il vient 〈i,m〉 → 〈i� 1;i2,m� 〉. • 〈i1,m〉 → Ω. Avec ce même C dans EVAL-ERR on trouve 〈i,m〉 → Ω. EXP : Ici i = e. On peut appliquer l’hypothèse de récurrence à e qui est « plus petit » que i (i ::= e introduit un constructeur implicite). • e = v. Alors on peut appliquer EXP : 〈e,m〉 → 〈PASS,m〉. • 〈e,m〉 → 〈e� ,m� 〉. Alors 〈i,m〉 → 〈e� ,m� 〉 (cela revient à appliquer CTX au constructeur implicite mentionné ci-dessus). • 〈e,m〉 → Ω. C’est-à-dire 〈i,m〉 → Ω. 1. Les contextes sont des objets purement syntaxiques : on peut les appliquer entre instructions et expressions indifféremment150 ANNEXE D. PREUVES DECL : Ici i = DECL x = e IN{i� }. On commence par appliquer l’hypothèse de récurrence à e. • e = v. On applique alors l’hypothèse de récurrence à i� sous Γ� = Γ,local x : t et avec m� = Extend(m,x �→ v). • i� = PASS. Dans ce cas la règle DECL-PASS s’applique. • i� = RETURN(v). Idem avec DECL-RETURN. • 〈i� ,m� 〉 → 〈i��,m��〉. On peut alors appliquer la règle DECL-CTX. • 〈i� ,m� 〉 → Ω. On applique DECL-ERR. • 〈e,m〉 → 〈e� ,m� 〉. On pose C = DECL x = • IN{i� } et on conclut avec la règle CTX. • 〈e,m〉 → Ω. Idem avec EVAL-ERR. IF : Ici i = IF(e){i1}ELSE{i2}. On applique l’hypothèse de récurrence à e. • e = v. Si v �= 0, on applique IF-TRUE. Dans le cas contraire, on applique IF-FALSE. • 〈e,m〉 → 〈e� ,m� 〉. On pose C = IF(•){i1}ELSE{i2} et on conclut avec CTX. • 〈e,m〉 → Ω. Avec ce même C et EVAL-ERR. WHILE : Ce cas est direct : on applique la règle d’évaluation WHILE. Expressions CST-INT : e est alors de la forme n, qui est une valeur. CST-FLOAT : e est alors de la forme d, qui est une valeur. CST-NULL : e est alors égale à NULL, qui est une valeur. CST-UNIT : e est alors égale à ( ), qui est une valeur. FUN : Ce cas est direct : la règle EXP-FUN s’applique. OP-INT : Cela implique que e = e1 � e2. Par le lemme 5.1, on en déduit que Γ � e1 : INT et Γ � e2 : INT. Appliquons l’hypothèse de récurrence sur e1. Trois cas peuvent se produire. • e1 = v1. On a alors 〈e1,m〉 = 〈v1,m� 〉 avec m� = m. On applique l’hypothèse de récurrence à e2. • e2 = v2 : alors 〈e2,m� 〉 = 〈v2,m��〉 avec m�� = m. On peut alors appliquer EXPBINOP, sauf dans le cas d’une division par zéro (� ∈ {/;%;/.} et v2 = 0) où alors v1 �� v2 = Ωd i v . Dans ce cas, on a alors par EXP-ERR 〈e,m〉 → Ωd i v . Notons que comme les opérandes sont bien typés, Ωt yp ne peut pas être levée. • ∃(e� 2,m��),〈e2,m� 〉 → 〈e� 2,m��〉. En appliquant CTX avec C = v1 � •, on en déduit 〈v1 � e2,m� 〉 → 〈v1 � e� 2,m��〉 soit 〈e,m〉 → 〈v1 � e� 2,m��〉. • 〈e2,m� 〉 → Ω. De EVAL-ERR avec C = v1 � • vient alors 〈e,m〉 → Ω.D.2. PROGRÈS 151 • ∃(e� 1,m� ),〈e1,m〉 → 〈e� 1,m� 〉. En appliquant CTX avec C = • � e2, on obtient 〈e1 � e2,m〉 → 〈e� 1 � e2,m� 〉, ou 〈e,m〉 → 〈e� 1 � e2,m� 〉. • 〈e1,m〉 → Ω. D’après EVAL-ERR avec C = • � e2, on a 〈e,m〉 → Ω. OP-FLOAT : Ce cas est similaire à OP-INT. OP-EQ : Ce cas est similaire à OP-INT. UNOP-PLUS-INT : Alors e = + e1. En appliquant l’hypothèse d’induction sur e1 : • soit e1 = v1. Alors en appliquant EXP-UNOP, 〈+ v1,m〉 → 〈+� v1,m〉, c’est-à-dire en posant v = +� v1, 〈e,m〉 → 〈v,m〉. • soit ∃e� 1,m� ,〈e1,m〉 → 〈e� 1,m� 〉. Alors en appliquant CTX avec C = + •, on obtient 〈e,m〉 → 〈e� 1,m� 〉. • soit 〈e1,m〉 → Ω. De EVAL-ERR avec C = + • il vient〈e,m〉 → Ω. UNOP-PLUS-FLOAT : Ce cas est similaire à UNOP-PLUS-INT. UNOP-MINUS-INT : Ce cas est similaire à UNOP-PLUS-INT. UNOP-MINUS-FLOAT : Ce cas est similaire à UNOP-PLUS-INT. UNOP-NOT : Ce cas est similaire à UNOP-PLUS-INT. ADDR : On applique l’hypothèse de récurrence à l v. Les cas d’évaluation et d’erreur sont traités en appliquant respectivement CTX et EVALERR avec C = &•. Dans le cas où l v = ϕ, on peut appliquer EXP-ADDR. SET : On applique l’hypothèse de récurrence à l v. • l v = ϕ. On applique l’hypothèse de récurrence à e. • e = v. Alors on peut appliquer EXP-SET. • 〈e,m〉 → 〈e� ,m� 〉. On conclut avec C = ϕ ← •. • 〈e,m〉 → Ω. Idem. • 〈l v,m〉 → 〈l v� ,m� 〉. On conclut avec C = • ← e. • 〈l v,m〉 → Ω. Idem. ARRAY : On va appliquer l’hypothèse de récurrence à e1, puis, si e1 = v1, on l’applique à e2, etc. Alors on se retrouve dans un des cas suivants : • ∃p ∈ [1;n],e� p,m : e1 = v1,...,ep−1 = vp−1,〈ep,m〉 → 〈e� p,m� 〉. Alors on peut appliquer CTX avec C = [v1;...; vp−1;•;ep+1;...;en]. • ∃p ∈ [1;n],Ω : e1 = v1,...,ep−1 = vp−1,〈ep,m〉 → Ω. Dans ce cas EVAL-ERR est applicable avec ce même C. • e1 = v1,...,en = vn. Alors on peut appliquer EXP-ARRAY en construisant un tableau.152 ANNEXE D. PREUVES STRUCT : Le schéma de preuve est similaire au cas ARRAY. En cas de pas d’évaluation ou d’erreur, on utilise le contexte C = {l1 : v1;...;lp−1 : vp−1;lp : •;lp+1 : ep+1;...;ln : en} ; et dans le cas où toutes les expressions sont évaluées, on applique EXP-STRUCT. CALL : On commence par appliquer l’hypothèse de récurrence à e. Dans le cas d’un pas d’évaluation ou d’erreur, on applique respectivement CTX ou EVAL-ERR avecC = •(e1,...,en). Reste le cas où e est une valeur : d’après le lemme 5.2, e est de la forme f = fun(a1,...,an){i}. Ensuite, appliquons le même schéma que pour ARRAY. En cas de pas d’évaluation ou d’erreur, on utilise CTX ou EVAL-ERR avec C = f (v1,..., vp−1,•,ep+1,...,en). Le seul cas restant est celui où l’expression considérée a pour forme f (v1,..., vn) avec f = fun(a1,...,an){i}. Soit Γ� = (ΓG , [a1 : t1,...,an : tn,R : t]) et m1 = Push(m0, (a1 �→ v1,...an �→ vn)) où Γ = (ΓG ,ΓL). On applique alors l’hypothèse de récurrence à Γ� , m1 et i (le lemme d’inversion garantit que Γ� � i). • i = RETURN(v). Alors on applique EXP-CALL-RETURN. • i = PASS. Ce cas est impossible puisqu’on prend l’hypothèse que les fonctions se terminent par une instruction RETURN(·) (page 56). • 〈i,m1〉 → 〈i� ,m2〉. Alors on peut appliquer EXP-CALL-CTX. • 〈i,m〉 → Ω. On peut alors appliquer EXP-CALL-ERR. Valeurs gauches LV-VAR : Le but est d’appliquer PHI-VAR. La seule condition pour que cela soit possible est que Lookup(x,m) renvoie une adresse et non Ωvar . Puisque Γ � x : t, on peut appliquer le lemme 5.5 : x est soit une variable locale, soit une globale. Dans ces deux cas, Lookup(x,m) renvoie une adresse correcte. LV-DEREF : Appliquons l’hypothèse de récurrence à e vue en tant qu’expression. • e = v. Puisque Γ � v : t∗, on déduit du lemme 5.2 que v = NULL ou v = &� ϕ. Dans le premier cas, puisque 〈∗NULL,m〉 → Ωp t r , on a 〈e,m〉 → Ωp t r . Dans le second cas, EXP-DEREF s’applique. • 〈e,m〉 → 〈e� ,m� 〉. De CTX avec C = ∗•, on obtient 〈e,m〉 → 〈∗e� ,m� 〉. • 〈e,m〉 → Ω. En appliquant EVAL-ERR avec C = ∗•, on obtient 〈e,m〉 → Ω. LV-INDEX : De même, on applique l’hypothèse de récurrence à l v. • l v = v. Comme Γ � v : t[ ], on déduit du lemme 5.2 que v = [v1;...; vp]. Appliquons l’hypothèse de récurrence à e. • e = v� . Puisque Γ � e : INT, on réapplique le lemme 5.2 et v� = n. D’après PHIARRAY,〈l v[e],m〉 → 〈[v1;...; vp][ �n],m〉. Deux cas sont à distinguer : si n ∈ [0;p−1], la partie droite vaut vn+1 et donc 〈l v[e],m〉 → 〈vn+1,m〉. Sinon elle vaut Ωar r ay et 〈l v[e],m〉 → Ωar r ay par EXP-ERR. • 〈e,m〉 → 〈e� ,m� 〉. En appliquant CTX avec C = v[•], on en déduit 〈l v[e],m〉 → 〈l v[e� ],m� 〉. • 〈e,m〉 → Ω. Avec EVAL-ERR sous ce même contexte, 〈l v[e],m〉 → ΩD.3. PRÉSERVATION 153 • 〈l v,m〉 → 〈e� ,m� 〉. On applique alors CTX avec C = •[e], et 〈l v[e],m〉 → 〈e� [e],m� 〉. • 〈l v,m〉 → Ω. Toujours avec C = •[e], de EVAL-ERR il vient 〈l v[e],m〉 → Ω. LV-FIELD : On applique l’hypothèse de récurrence à l v. • l v = ϕ Alors PHI-STRUCT s’applique. Puisque (l,t) ∈ S, l’accès au champ l ne provoque pas d’erreur Ωf i eld . Donc 〈e,m〉 → 〈ϕ[l],m〉. • 〈l v,m〉 → 〈l v� ,m� 〉 En appliquant CTX avec C = •.lS, il vient 〈l v,m〉 → 〈l v� ,m� 〉. • 〈l v,m〉 → Ω En appliquant EVAL-ERR avec C = •.lS, on a 〈l v,m〉 → Ω. PTR-ARITH : Le schéma est similaire au cas OP-INT. Le seul cas intéressant arrive lorsque e1 et e2 sont des valeurs. D’après le lemme 5.2 : • e1 = NULL ou e1 = ϕ • e2 = n D’après EXP-BINOP, 〈e,m〉 → 〈e1 �� n,m〉. On se réfère ensuite à la définition de �� (page 55) : si e1 est de la forme ϕ[m], alors e1 �� n = ϕ[m +n]. Donc 〈e,m〉 → 〈ϕ[m +n],m〉. Dans les autres cas (e1 = NULL ou e1 = ϕ avec ϕ pas de la forme ϕ� [m]), on a e1 �� n = Ωp t r . Donc d’après EXP-ERR, 〈e,m〉 → Ωp t r . D.3 Préservation On rappelle l’énoncé du théorème 5.2. Théorème D.2 (Préservation). Soient Γ un environnement de typage, et m un état mémoire tels que Γ � m. Alors : • Si Γ � l v : t et 〈l v,m〉 → 〈ϕ,m� 〉, alors Γ � Cleanup(m� ) et m� �Φ ϕ : τ où τ�t. • Si Γ � l v : t et 〈l v,m〉 → 〈l v� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � l v� : t. • Si Γ � e : t et 〈e,m〉 → 〈v,m� 〉, alors Γ � Cleanup(m� ) et m� � v : τ où τ�t. • Si Γ � e : t et 〈e,m〉 → 〈e� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � e� : t. • Si Γ � i et 〈i,m〉 → 〈i� ,m� 〉, alors Γ � Cleanup(m� ) et Γ � i� . Autrement dit, si une construction est typable, alors un pas d’évaluation ne modifie pas son type et préserve le typage de la mémoire. Démonstration. On procède par induction sur la dérivation de 〈·,m〉 → 〈·,m� 〉. Plusieurs remarques sont à faire : d’abord, en ce qui concerne le typage de la mémoire, il suffit de montrer que Γ � m� car cela implique que Γ � Cleanup(m� ). Ensuite, la règle CTX est traitée à part, car elle peut être appliquée en contexte d’expression, d’instruction ou de valeur gauche. Enfin la règle TRANS ne pose pas de problème, il suffit d’appliquer l’hypothèse de récurrence à ses prémisses. Cas Γ � l v : t et 〈l v,m〉 → 〈ϕ,m� 〉 EXP-DEREF : On sait que Γ � ∗ v : t où v = &� ϕ. Par inversion, Γ � v : t ∗. Alors d’après le lemme 5.3, il existe τ� tel que m � v : τ� et τ� � t ∗. Par inversion de la relation de typage sémantique, τ� = τ ∗ où τ�t. Alors par inversion de S-PTR, on obtient que m �Φ ϕ : τ.154 ANNEXE D. PREUVES PHI-VAR, PHI-STRUCT et PHI-ARRAY : Il n’est pas nécessaire de montrer la compatibilité de m� car la mémoire n’est pas modifiée. De plus, les prémisses de ces règles ont la forme ϕ , donc le lemme 5.6 s’applique avec la conclusion correcte. Cas Γ � e : t et 〈e,m〉 → 〈v,m� 〉 EXP-CST : Toutes les constantes sont des valeurs, donc le lemme 5.3 peut s’appliquer : τ = Repr(t) convient. EXP-FUN : Idem : le lemme de représentabilité nous donne un candidat τ = Repr(t) qui convient. EXP-LV : Puisque Γ � ϕ : t et Γ � m, on a d’après le lemme 5.6 : m � v : τ où v = m[ϕ] avec τ�t. EXP-UNOP : Il vient des définitions des différents opérateurs �� que Γ � �� v : τ avec τ�t. EXP-BINOP : Idem avec les définitions des opérateurs �� . EXP-ADDR : On peut appliquer le lemme 5.3, qui nous donne un τ qui convient. EXP-SET : Deux propriétés sont à prouver. D’une part, Γ � v : t, et d’autre part, Γ � m� où m� = m[ϕ ← v]. Tout d’abord, le lemme d’inversion appliqué à Γ � ϕ ← v : t nous donne que Γ � ϕ : t et Γ � v : t. Ensuite, comme Γ � ϕ : t et Γ � m, on peut appliquer le lemme 5.3 : il existe τ tel que m � v : τ et τ� t. On peut donc appliquer le lemme 5.6, qui nous permet de conclure que Γ � m� . EXP-STRUCT : Le lemme 5.3 s’applique à ce cas. EXP-ARRAY : Idem, on conclut grâce au lemme de représentabilité. EXP-CALL-RETURN : Par inversion, il vient que Γ � fun(a1,...,an){i} : (t1,...,tn) → t� et ∀i ∈ [1;n],Γ � vi : ti . Posons Γ� = (ΓG , [a1 : t1,...,an : tn,R : t� ]) où Γ = (ΓG ,ΓL). Alors par inversions successives on obtient que Γ� � RETURN(v) et Γ� � v : t� . Si on définit m�� = Push(m,a1 �→ v1,...,an �→ vn), alors par M-PUSH on obtient que Γ� � m��. Donc, par le lemme 5.3, il existe τ tel que m�� � v : τ où τ�t� . Il reste à montrer que m� � v� : τ. On distingue selon la forme de v. On applique un raisonnement similaire à celui de la preuve du lemme 5.6 : soit v est une référence au cadre nettoyé, et dans ce cas v� = NULL et τ est un type pointeur, soit v� = v. Dans tous les cas on conclut car m� � v� : τ. Cas Γ � i et 〈i,m〉 → 〈i� ,m� 〉 SEQ : D’après le lemme d’inversion, Γ � i. EXP : D’après PASS, Γ � PASS.D.3. PRÉSERVATION 155 DECL-PASS : Γ � PASS est immédiat, et Γ � m� est établi par M-DECL suivie de M-DECLCLEAN. On a bien x ∉ Γ car les déclarations de variable ne peuvent pas masquer de variables visibles existantes (page 57). DECL-RETURN : La compatibilité mémoire se démontre de la même manière que pour DECL-PASS. Il reste à montrer que Γ � RETURN(v��), ce qui fait de manière analogue au cas EXP-CALL-RETURN. DECL-CTX : On part de Γ � DECL x = v IN{i}. Par inversion, il existe t tel que Γ � v : t et Γ� � i où Γ� = Γ,local x : t. Comme Γ � m, le lemme 5.3 s’applique : il existe τ tel que m � v : τ où τ�t. De plus x ∉ Γ car il n’y a pas de masquage (page 57). En appliquant M-DECL, on obtient donc que Γ� � m� . On applique alors l’hypothèse d’induction à 〈i,m� 〉 → 〈i� ,m��〉. Il vient que Γ� � i� et Γ� � m��. On a donc Γ� � DECL x = v� IN{i� } par DECL et Γ � Cleanup(m���) par M-DECLCLEAN. IF-FALSE : D’après le lemme d’inversion, Γ � if . IF-TRUE : D’après le lemme d’inversion, Γ � it . WHILE : D’après le lemme d’inversion, Γ � e : t et Γ � i. Par SEQ, on a Γ � i;WHILE(e){i}. Enfin par IF il vient Γ � IF(e){i;WHILE(e){i}}ELSE{PASS}. RETURN : Par le lemme d’inversion, Γ � RETURN(v). EXP-CALL-CTX : On sait que Γ � fun(a1,...,an){i}(v1,..., vn) et Γ � m0. D’après le lemme d’inversion, il existe t1,...,tn tels que ∀i ∈ [1;n],Γ � vi : ti , Γ � fun(a1,...,an){i} : (t1,...,tn) → t, donc qu’en posant Γ� = (ΓG , [a1 : t1,...,an : tn,R : t]) où Γ = (ΓG ,ΓL) on a Γ� � i. D’un autre côté, il existe par le lemme 5.3 des types τi tels que ∀i ∈ [1;n],m0 � vi : τi avec τi �ti . En appliquant M-PUSH, on a donc Γ� � m1. On peut alors appliquer l’hypothèse d’induction à 〈i,m1〉 → 〈i� ,m2〉 : la conclusion est que Γ� � i� et Γ� � m2. Comme Γ� � ai : ti , on a ∀i ∈ [1;n],Γ� � v� i : ti . Donc on a bien Γ � fun(a1,...,an){i� }(v� 1,..., v� n) : t. D’autre part, en appliquant M-POP, on obtient que Γ � Cleanup(m3). À propos de la règle CTX L’application de la règle CTX nécessite une explication particulière. En effet, ce cas repose sur un lemme d’inversion des constructions typées sous un contexte, qui est admis ici. Par exemple, traitons le cas où le contexte C est tel que son « trou » soit une valeur gauche l v et C�l v� est une instruction (les autres cas sont similaires). La règle appliquée est alors de la forme : 〈l v,m〉 → 〈l v� ,m� 〉 〈C�l v�,m〉 → 〈C�l v� �,m� 〉 (CTX) Si Γ � C�l v�, on admet qu’il existe Γ� et t tels que : • Γ� � l v : t ;156 ANNEXE D. PREUVES • Quel que soit l v� , si Γ� � l v� : t, alors Γ � C�l v� �. Par exemple, pour C = •[2] = 1, Γ� = Γ et t = INT[ ] conviennent. Pour C = DECL x = 0 IN{• = 3.0}, on prendra Γ� = Γ,local x : INT et t = FLOAT. Le fait de passer « sous » une dé- claration ajoute une variable locale à Γ, et ainsi l’ensemble des variables de Γ� contient celui de Γ. Pour prouver la préservation dans ce cas, on commence par appliquer l’hypothèse de récurrence à la prémisse de CTX, c’est-à-dire 〈l v,m〉 → 〈l v� ,m� 〉. Il vient que Γ� � l v� : t et Γ� � Cleanup(m� ). D’après le précédent lemme d’inversion on en déduit que Γ � C�l v� �. De plus Γ� contient plus de variables que Γ donc Γ � Cleanup(m� ). D.4 Progrès pour les extensions noyau (Théorème 6.1) Démonstration. On procède de la même manière que pour le théorème 5.1 (prouvé en annexe D.2). En fait, puisque le schéma de preuve porte sur les règles de typage, il suffit de traiter les cas supplémentaires. ADDR-USER : Alors e = ♦ l v. On applique l’hypothèse de récurrence à l v. • l v = ϕ. Alors on peut appliquer PHI-USER. • 〈l v,m〉 → 〈l v� ,m� 〉. On conclut en utilisant CTX avec C = ♦ •. • 〈l v,m〉 → Ω. On applique EVAL-ERR avec ce même C. USER-GET : On applique l’hypothèse de récurrence à ed . • ed = vd . On applique l’hypothèse de récurrence à es. • es = vs. D’après le lemme 5.2 adapté aux extensions noyau, vs a pour forme ϕs. On distingue la forme de ϕs : • ϕs = ♦� ϕ. Alors on applique USER-GET-OK. Le lemme 5.6 adapté aux extensions noyau assure que les prémisses sont correctes. • � ϕ,ϕs = ♦� ϕ. Alors on applique USER-GET-ERR. • 〈es,m〉 → 〈e� s,m� 〉. Posons C = copy_from_user(vd ,•). On conclut avec CTX. • 〈es,m〉 → Ω. Idem avec EVAL-ERR. • 〈ed ,m〉 → 〈e� d ,m� 〉. On applique CTX avec C = copy_from_user(•,es). • 〈ed ,m〉 → Ω. On utilise EVAL-ERR avec ce même contexte. USER-PUT : Ce cas est similaire au cas USER-GET, en appliquant les règles USER-PUT-OK et USER-PUT-ERR.D.5. PRÉSERVATION POUR LES EXTENSIONS NOYAU 157 D.5 Préservation pour les extensions noyau (Théorème 6.2) De même, il suffit de prouver les cas correspondant aux nouvelles règles. PHI-USER : On applique le lemme de représentation, qu’on étend avec le cas Repr(t @) = Repr(t) @. USER-GET-OK : Tout d’abord, d’après le lemme 6.1, t = INT, donc la préservation du type est établie car m� � 0 : INT. La compatibilité mémoire est obtenue en appliquant M-WRITE. USER-GET-ERR : La seule partie à prouver est la préservation, qui se fait de la même manière que dans le cas précédent. USER-PUT-OK : Idem que dans le cas USER-PUT-OK. USER-PUT-ERR : Idem que pour USER-GET-ERR.LISTE DES FIGURES 1.1 Surapproximation. L’ensemble des états erronés est hachuré. L’ensemble des états effectifs du programme, noté par des points, est approximé par l’ensemble en gris. 9 1.2 Utilisation de l’attribut non-standard packed . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Mécanisme de mémoire virtuelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Implantation de la mémoire virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Appel de gettimeofday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4 Implantation de l’appel système gettimeofday . . . . . . . . . . . . . . . . . . . . . 19 3.1 Domaine des signes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Quelques domaines abstraits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3 Treillis de qualificateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1 Fonctionnement d’une lentille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Fonctionnement d’une lentille indexée . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3 Composition de lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4 Syntaxe des expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5 Syntaxe des instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.6 Syntaxe des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.7 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.8 Composantes d’un état mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.9 Opérations de pile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.10 Cassage du typage par un pointeur fou . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.11 Dépendances entre les lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.12 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.13 Évaluation stricte ou paresseuse des valeurs gauches . . . . . . . . . . . . . . . . . 54 5.1 Programmes bien et mal formés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Types et environnements de typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.3 Jugements d’égalité sur les types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.4 Typage des phrases et programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5 Types de valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.6 Règles de typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.7 Compatibilité entre types de valeurs et statiques . . . . . . . . . . . . . . . . . . . . 72 5.8 Compatibilité entre états mémoire et environnements de typage . . . . . . . . . . 72 6.1 Interface permettant d’ouvrir un fichier sous Unix . . . . . . . . . . . . . . . . . . . 82 6.2 Ajouts liés aux entiers utilisés comme bitmasks . . . . . . . . . . . . . . . . . . . . . 83 6.3 Nouvelles valeurs liées aux bitmasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.4 Dérivation montrant que ! (x & y) est bien typée . . . . . . . . . . . . . . . . . . . . 85 6.5 Implantation d’un appel système qui remplit une structure par pointeur . . . . . . 87 6.6 Ajouts liés aux pointeurs utilisateur (par rapport à l’interprète du chapitre 4) . . . 87 6.7 Appel de la fonction sys_getver de la figure 6.5 . . . . . . . . . . . . . . . . . . . . . 88 6.8 Ajouts liés aux pointeurs utilisateur (par rapport aux figures 5.2 et 5.5) . . . . . . . 90 159160 Liste des figures 7.1 Syntaxe simplifiée de NEWSPEAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 7.2 Compilation du flot de contrôle en NEWSPEAK . . . . . . . . . . . . . . . . . . . . . 101 7.3 Fonction principale de ptrtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.4 Algorithme d’unification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.5 Unification directe ou retardée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6 Inférence des déclarations de variable et appels de fonction . . . . . . . . . . . . . 106 8.1 Espace d’adressage d’un processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 8.2 Fonction de définition d’un appel système . . . . . . . . . . . . . . . . . . . . . . . . 113 8.3 Code de la fonction radeon_info_ioctl . . . . . . . . . . . . . . . . . . . . . . . . . 114 8.4 Définition de struct drm_radeon_info . . . . . . . . . . . . . . . . . . . . . . . . . 114 8.5 Patch résolvant le problème de pointeur utilisateur. . . . . . . . . . . . . . . . . . . 115 8.6 Implantation de ptrace sur architecture Blackfin . . . . . . . . . . . . . . . . . . . 116 8.7 Cas d’étude « Radeon » minimisé et annoté . . . . . . . . . . . . . . . . . . . . . . . 118 8.8 Cas d’étude « Radeon » minimisé et annoté – version correcte . . . . . . . . . . . . 118 8.9 Cas d’étude « Blackfin » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 8.10 Traduction en NEWSPEAK du cas d’étude « Blackfin » . . . . . . . . . . . . . . . . . . 121LISTE DES DÉFINITIONS 4.1 Définition (Lentille) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Définition (Lentille indexée) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3 Définition (Composition de lentilles) . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4 Définition (Recherche de variable) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.5 Définition (Manipulations de pile) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.6 Définition (Hauteur d’une valeur) . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 LISTE DES THÉORÈMES ET LEMMES 5.1 Lemme (Inversion) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2 Lemme (Formes canoniques) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.3 Lemme (Représentabilité) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.4 Lemme (Hauteur des chemins typés) . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.5 Lemme (Accès à des variables bien typées) . . . . . . . . . . . . . . . . . . . . . . 75 5.6 Lemme (Accès à une mémoire bien typée) . . . . . . . . . . . . . . . . . . . . . . 76 5.1 Théorème (Progrès) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2 Théorème (Préservation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Théorème (Progrès pour les phrases) . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Théorème (Préservation pour les phrases) . . . . . . . . . . . . . . . . . . . . . . 78 6.1 Lemme (Inversion du typage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.1 Théorème (Progrès pour les extensions noyau) . . . . . . . . . . . . . . . . . . . 92 6.2 Théorème (Préservation pour les extensions noyau) . . . . . . . . . . . . . . . . 92 D.1 Théorème (Progrès) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 D.2 Théorème (Préservation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 161RÉFÉRENCES WEB [☞1] The C - - language http://www.cminusminus.org/ [☞2] OCaml – Home http://ocaml.org/ [☞3] Penjili project https://bitbucket.org/iwseclabs/c2newspeak [☞4] Python Programming Language – Official Website http://www.python.org/ [☞5] The Rust Programming Language http://www.rust-lang.org/ [☞6] Sparse - a Semantic Parser for C https://sparse.wiki.kernel.org/index.php/Main_Page 163BIBLIOGRAPHIE [AB07] Andrew W. Appel and Sandrine Blazy. Separation logic for small-step Cminor. In Proceedings of the 20th International Conference on Theorem Proving in Higher Order Logics, TPHOLs 2007, pages 5–21, 2007. [ABD+07] Alex Aiken, Suhabe Bugrara, Isil Dillig, Thomas Dillig, Brian Hackett, and Peter Hawkins. An overview of the saturn project. In Proceedings of the 7th ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering, PASTE ’07, pages 43–48. ACM, 2007. [AH07] Xavier Allamigeon and Charles Hymans. Analyse statique par interprétation abstraite. In Eric Filiol, editor, 5ème Symposium sur la Sécurité des Technologies de l’Information et des Communications (SSTIC’07), 2007. [BA08] S. Bugrara and A. Aiken. Verifying the Safety of User Pointer Dereferences. In Security and Privacy, 2008. SP 2008. IEEE Symposium on, pages 325–338, 2008. [BBC+10] Al Bessey, Ken Block, Ben Chelf, Andy Chou, Bryan Fulton, Seth Hallem, Charles Henri-Gros, Asya Kamsky, Scott McPeak, and Dawson Engler. A few billion lines of code later : using static analysis to find bugs in the real world. Commun. ACM, 53(2) :66–75, 2010. [BC05] Daniel P. Bovet and Marco Cesati. Understanding the Linux Kernel, Third Edition. O’Reilly Media, third edition edition, 2005. [BCC+03] Armin Biere, Alessandro Cimatti, Edmund M. Clarke, Ofer Strichman, and Yunshan Zhu. Bounded model checking. Advances in Computers, 58 :117–148, 2003. [BDH+09] Julien Brunel, Damien Doligez, René Rydhof Hansen, Julia L. Lawall, and Gilles Muller. A foundation for flow-based program matching using temporal logic and model checking. In The 36th Annual ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages, POPL, pages 114–126, 2009. [BDL06] Sandrine Blazy, Zaynah Dargaye, and Xavier Leroy. Formal verification of a C compiler front-end. In FM 2006 : Int. Symp. on Formal Methods, volume 4085 of Lecture Notes in Computer Science, pages 460–475. Springer, 2006. [BDN09] Ana Bove, Peter Dybjer, and Ulf Norell. A brief overview of Agda — a functional language with dependent types. In Proceedings of the 22nd International Conference on Theorem Proving in Higher Order Logics, TPHOLs ’09, pages 73– 78. Springer-Verlag, 2009. [BGH10] Lennart Beringer, Robert Grabowski, and Martin Hofmann. Verifying pointer and string analyses with region type systems. In Proceedings of the 16th International Conference on Logic for Programming, Artificial Intelligence, and Reasoning, LPAR’10, pages 82–102. Springer-Verlag, 2010. [BLS05] Mike Barnett, K. Rustan M. Leino, and Wolfram Schulte. The Spec# programming system : an overview. In Proceedings of the 2004 international conference on Construction and Analysis of Safe, Secure, and Interoperable Smart Devices, CASSIS’04, pages 49–69. Springer-Verlag, 2005. 165166 BIBLIOGRAPHIE [CC77] Patrick Cousot and Radhia Cousot. Abstract interpretation : a unified lattice model for static analysis of programs by construction or approximation of fixpoints. In Proceedings of the 4th ACM SIGACT-SIGPLAN symposium on Principles of Programming Languages, POPL ’77, pages 238–252. ACM, 1977. [CC92] P. Cousot and R. Cousot. Abstract interpretation and application to logic programs. Journal of Logic Programming, 13(2–3) :103–179, 1992. (The editor of Journal of Logic Programming has mistakenly published the unreadable galley proof. For a correct version of this paper, see http://www.di.ens.fr/~cousot.). [CCF+05] Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, David Monniaux, and Xavier Rival. The ASTREÉ analyzer. In Proceedings of the 14th European Symposium on Programming, ESOP 2005, pages 21–30, 2005. [CCF+09] Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, and Xavier Rival. Why does Astrée scale up ? Formal Methods in System Design, 35(3) :229–264, 2009. [CE81] Edmund M. Clarke and E. Allen Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In Dexter Kozen, editor, Logic of Programs, volume 131 of Lecture Notes in Computer Science, pages 52–71. Springer, 1981. [CH78] P. Cousot and N. Halbwachs. Automatic discovery of linear restraints among variables of a program. In Conference Record of the Fifth Annual ACM SIGPLANSIGACT Symposium on Principles of Programming Languages, POPL ’78, pages 84–97. ACM Press, New York, NY, 1978. [CMP03] Emmanuel Chailloux, Pascal Manoury, and Bruno Pagano. Développement d’applications avec Objective CAML. O’Reilly, 2003. [DDMP10] Javier De Dios, Manuel Montenegro, and Ricardo Peña. Certified absence of dangling pointers in a language with explicit deallocation. In Proceedings of the 8th international conference on Integrated formal methods, IFM’10, pages 305–319. Springer-Verlag, 2010. [DM82] Luis Damas and Robin Milner. Principal type-schemes for functional programs. In Proceedings of the 9th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, POPL ’82, pages 207–212. ACM, 1982. [DRS03] Nurit Dor, Michael Rodeh, and Mooly Sagiv. CSSV : Towards a realistic tool for statically detecting all buffer overflows in C. In Proceedings of the ACM SIGPLAN 2003 conference on Programming language design and implementation, PLDI ’03, pages 155–167. ACM, 2003. [EH94] Ana Erosa and Laurie J. Hendren. Taming control flow : A structured approach to eliminating goto statements. In In Proceedings of 1994 IEEE International Conference on Computer Languages, pages 229–240. IEEE Computer Society Press, 1994. [FFA99] Jeffrey S. Foster, Manuel Fähndrich, and Alexander Aiken. A theory of type quali- fiers. In Proceedings of the 1999 ACM SIGPLAN conference on Programming language design and implementation, PLDI ’99, pages 192–203, 1999.BIBLIOGRAPHIE 167 [FGM+07] J. Nathan Foster, Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce, and Alan Schmitt. Combinators for bidirectional tree transformations : A linguistic approach to the view-update problem. ACM Trans. Program. Lang. Syst., 29(3), 2007. [FJKA06] Jeffrey S. Foster, Robert Johnson, John Kodumal, and Alex Aiken. Flow-insensitive type qualifiers. ACM Trans. Program. Lang. Syst., 28 :1035–1087, 2006. [Flo67] Robert W. Floyd. Assigning Meanings to Programs. In J. T. Schwartz, editor, Proceedings of a Symposium on Applied Mathematics, volume 19 of Mathematical Aspects of Computer Science, pages 19–31. American Mathematical Society, 1967. [FTA02] Jeffrey S. Foster, Tachio Terauchi, and Alex Aiken. Flow-sensitive type qualifiers. In Proceedings of the 2002 ACM SIGPLAN Conference on Programming language design and implementation, PLDI ’02, pages 1–12. ACM, 2002. [GGTZ07] Stephane Gaubert, Eric Goubault, Ankur Taly, and Sarah Zennou. Static analysis by policy iteration on relational domains. In Rocco Nicola, editor, Programming Languages and Systems, volume 4421 of Lecture Notes in Computer Science, pages 237–252. Springer Berlin, 2007. [GMJ+02] Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks, Yanling Wang, and James Cheney. Region-based memory management in Cyclone. SIGPLAN Not., 37(5) :282–293, 2002. [Gon07] Georges Gonthier. The four colour theorem : Engineering of a formal proof. In 8th Asian Symposium on Computer Mathematics, ASCM 2007, page 333, 2007. [Gor04] Mel Gorman. Understanding the Linux Virtual Memory Manager. Prentice Hall PTR, 2004. [Gra92] Philippe Granger. Improving the results of static analyses programs by local decreasing iteration. In Proceedings of the 12th Conference on Foundations of Software Technology and Theoretical Computer Science, pages 68–79. SpringerVerlag, 1992. [Har88] Norm Hardy. The confused deputy (or why capabilities might have been invented). ACM Operating Systems Review, 22(4) :36–38, 1988. [HL08] Charles Hymans and Olivier Levillain. Newspeak, Doubleplussimple Minilang for Goodthinkful Static Analysis of C. Technical Note 2008-IW-SE-00010-1, EADS IW/SE, 2008. [Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM, 12(10) :576–580, 1969. [ISO99] ISO. The ANSI C standard (C99). Technical Report WG14 N1124, ISO/IEC, 1999. [JMG+02] Trevor Jim, J. Greg Morrisett, Dan Grossman, Michael W. Hicks, James Cheney, and Yanling Wang. Cyclone : A safe dialect of c. In Proceedings of the General Track of the annual conference on USENIX Annual Technical Conference, ATEC ’02, pages 275–288. USENIX Association, 2002. [Jon10] M. Tim Jones. User space memory access from the Linux kernel. http://www. ibm.com/developerworks/library/l-kernel-memory-access/, 2010. [JW04] Robert Johnson and David Wagner. Finding user/kernel pointer bugs with type inference. In USENIX Security Symposium, pages 119–134, 2004.168 BIBLIOGRAPHIE [KcS07] Oleg Kiselyov and Chung chieh Shan. Lightweight static capabilities. Electr. Notes Theor. Comput. Sci., 174(7) :79–104, 2007. [Ker81] Brian W. Kernighan. Why Pascal is not my favorite programming language. Technical report, AT&T Bell Laboratories, 1981. [KR88] Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language Second Edition. Prentice-Hall, Inc., 1988. [LA04] Chris Lattner and Vikram Adve. LLVM : A Compilation Framework for Lifelong Program Analysis & Transformation. In Proceedings of the 2004 International Symposium on Code Generation and Optimization (CGO’04), 2004. [Lan96] Gérard Le Lann. The ariane 5 flight 501 failure - a case study in system engineering for computing systems, 1996. [LBR06] Gary T. Leavens, Albert L. Baker, and Clyde Ruby. Preliminary design of jml : A behavioral interface specification language for java. SIGSOFT Softw. Eng. Notes, 31(3) :1–38, 2006. [LDG+10] Xavier Leroy, Damien Doligez, Jacques Garrigue, Didier Rémy, and Jérôme Vouillon. The Objective Caml system, documentation and user’s manual – release 3.12. INRIA, 2010. [LZ06] Peng Li and Steve Zdancewic. Encoding information flow in Haskell. In Proceedings of the 19th IEEE Workshop on Computer Security Foundations (CSFW ’06). IEEE Computer Society, 2006. [Mai90] Harry G. Mairson. Deciding ML typability is complete for deterministic exponential time. In Proceedings of the Seventeenth Annual ACM Symposium on Principles of Programming Languages, POPL ’90, pages 382–401, 1990. [Mau04] Laurent Mauborgne. ASTRÉE : Verification of absence of run-time error. In René Jacquart, editor, Building the information Society (18th IFIP World Computer Congress), pages 384–392. The International Federation for Information Processing, Kluwer Academic Publishers, 2004. [McA03] David A. McAllester. Joint RTA-TLCA invited talk : A logical algorithm for ML type inference. In Proceedings of the 14th International Conference on Rewriting Techniques and Applications, RTA, pages 436–451, 2003. [Mer03] J. Merrill. GENERIC and GIMPLE : a new tree representation for entire functions. In GCC developers summit 2003, pages 171–180, 2003. [MG07] Magnus O. Myreen and Michael J.C. Gordon. A Hoare logic for realistically modelled machine code. In Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2007), LNCS, pages 568–582. Springer-Verlag, 2007. [Mil78] Robin Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 17(3) :348–375, 1978. [Min01a] A. Miné. A new numerical abstract domain based on difference-bound matrices. In Proc. of the Second Symposium on Programs as Data Objects (PADO II), volume 2053 of Lecture Notes in Computer Science (LNCS), pages 155–172. Springer, 2001. http://www.di.ens.fr/~mine/publi/article-mine-padoII.pdf.BIBLIOGRAPHIE 169 [Min01b] A. Miné. The octagon abstract domain. In Proc. of the Workshop on Analysis, Slicing, and Transformation (AST’01), pages 310–319. IEEE CS Press, 2001. http: //www.di.ens.fr/~mine/publi/article-mine-ast01.pdf. [NCH+05] George C. Necula, Jeremy Condit, Matthew Harren, Scott McPeak, and Westley Weimer. Ccured : type-safe retrofitting of legacy software. ACM Trans. Program. Lang. Syst., 27(3) :477–526, 2005. [New00] Tim Newsham. Format string attacks. Phrack, 2000. [NMRW02] George C. Necula, Scott McPeak, Shree Prakash Rahul, and Westley Weimer. CIL : Intermediate language and tools for analysis and transformation of C programs. In Proceedings of the 11th International Conference on Compiler Construction, CC ’02, pages 213–228. Springer-Verlag, 2002. [NPW02] Tobias Nipkow, Lawrence C. Paulson, and Markus Wenzel. Isabelle/HOL — A Proof Assistant for Higher-Order Logic, volume 2283 of LNCS. Springer, 2002. [oEE08] Institute of Electrical and Electronics Engineers. IEEE Standard for FloatingPoint Arithmetic. Technical report, Microprocessor Standards Committee of the IEEE Computer Society, 2008. [OGS08] Bryan O’Sullivan, John Goerzen, and Don Stewart. Real World Haskell. O’Reilly Media, Inc., 1st edition, 2008. [Oiw09] Yutaka Oiwa. Implementation of the memory-safe full ANSI-C compiler. In Proceedings of the 2009 ACM SIGPLAN conference on Programming language design and implementation, PLDI ’09, pages 259–269. ACM, 2009. [Pel93] Doron Peled. All from one, one for all : On model checking using representatives. In Proceedings of the 5th International Conference on Computer Aided Verification, CAV ’93, pages 409–423. Springer-Verlag, 1993. [Pie02] Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002. [PJNO97] Simon L. Peyton Jones, Thomas Nordin, and Dino Oliva. C- - : A portable assembly language. In Chris Clack, Kevin Hammond, and Antony J. T. Davie, editors, Implementation of Functional Languages, volume 1467 of Lecture Notes in Computer Science, pages 1–19. Springer, 1997. [PTS+11] Nicolas Palix, Gaël Thomas, Suman Saha, Christophe Calvès, Julia Lawall, and Gilles Muller. Faults in Linux : Ten years later. In Sixteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2011), 2011. [Ric53] H. G. Rice. Classes of recursively enumerable sets and their decision problems. Transactions of the American Mathematical Society, 74(2) :pp. 358–366, 1953. [RV98] Didier Rémy and Jérôme Vouillon. Objective ML : An effective object-oriented extension to ML. In Theory And Practice of Object Systems, pages 27–50, 1998. [Sim03] Vincent Simonet. Flow Caml in a nutshell. In Graham Hutton, editor, Proceedings of the first APPSEM-II workshop, pages 152–165, 2003. [SLM11] Suman Saha, Julia Lawall, and Gilles Muller. An approach to improving the structure of error-handling code in the linux kernel. In Proceedings of the 2011 SIGPLAN/SIGBED conference on Languages, compilers and tools for embedded systems, LCTES ’11, pages 41–50. ACM, 2011.170 BIBLIOGRAPHIE [SM03] Andrei Sabelfeld and Andrew C. Myers. Language-based information-flow security. IEEE Journal on Selected Areas in Communications, 21 :2003, 2003. [Spe05] Brad Spengler. grsecurity 2.1.0 and kernel vulnerabilities. Linux Weekly News, 2005. [SRH96] Mooly Sagiv, Thomas Reps, and Susan Horwitz. Precise interprocedural data- flow analysis with applications to constant propagation. In Selected papers from the 6th international joint conference on Theory and practice of software development, TAPSOFT ’95, pages 131–170. Elsevier Science Publishers B. V., 1996. [Sta11] Basile Starynkevitch. Melt - a translated domain specific language embedded in the gcc compiler. In Olivier Danvy and Chung chieh Shan, editors, DSL, volume 66 of EPTCS, pages 118–142, 2011. [STFW01] Umesh Shankar, Kunal Talwar, Jeffrey S. Foster, and David Wagner. Detecting format string vulnerabilities with type qualifiers. In SSYM’01 : Proceedings of the 10th conference on USENIX Security Symposium, page 16. USENIX Association, 2001. [SY86] R E Strom and S Yemini. Typestate : A programming language concept for enhancing software reliability. IEEE Trans. Softw. Eng., 12(1) :157–171, 1986. [Tan07] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall Press, 3rd edition, 2007. [The04] The Coq Development Team. The Coq Proof Assistant Reference Manual – Version V8.0, 2004. http://coq.inria.fr. [TJ92] Jean-Pierre Talpin and Pierre Jouvelot. Polymorphic type, region and effect inference. Journal of Functional Programming, 2 :245–271, 1992. [TT94] Mads Tofte and Jean-Pierre Talpin. Implementation of the typed call-by-value λ-calculus using a stack of regions. In Proceedings of the 21st ACM SIGPLANSIGACT symposium on Principles of programming languages, POPL ’94, pages 188–201. ACM, 1994. [VB04] Arnaud Venet and Guillaume Brat. Precise and efficient static array bound checking for large embedded c programs. In Proceedings of the 2004 ACM SIGPLAN conference on Programming language design and implementation, PLDI ’04, pages 231–242. ACM, 2004. [vL11] Twan van Laarhoven. Lenses : viewing and updating data structures in Haskell. http://www.twanvl.nl/files/lenses-talk-2011-05-17.pdf, 2011.Résumé Les noyaux de systèmes d’exploitation manipulent des données fournies par les programmes utilisateur via les appels système. Si elles sont manipulées sans prendre une attention particulière, une faille de sécurité connue sous le nom de Confused Deputy Problem peut amener à des fuites de données confidentielles ou l’élévation de privilèges d’un attaquant. Le but de cette thèse est d’utiliser des techniques de typage statique afin de détecter les manipulations dangereuses de pointeurs contrôlés par l’espace utilisateur. La plupart des systèmes d’exploitation sont écrits dans le langage C. On commence par en isoler un sous-langage sûr nommé SAFESPEAK. Sa sémantique opérationnelle et un premier système de types sont décrits, et les propriétés classiques de sûreté du typage sont établies. La manipulation des états mémoire est formalisée sous la forme de lentilles bidirectionnelles, qui permettent d’encoder les mises à jour partielles des états et variables. Un première analyse sur ce langage est décrite, permettant de distinguer les entiers utilisés comme bitmasks, qui sont une source de bugs dans les programmes C. On ajoute ensuite à SAFESPEAK la notion de valeur provenant de l’espace utilisateur. La sûreté du typage est alors brisée, mais on peut la réétablir en donnant un type particulier aux pointeurs contrôlés par l’espace utilisateur, ce qui force leur déférencement à se faire de manière contrôlée. Cette technique permet de détecter deux bugs dans le noyau Linux : le premier concerne un pilote de carte graphique AMD, et le second l’appel système ptrace sur l’architecture Blackfin. Abstract Operating system kernels need to manipulate data that comes from user programs through system calls. If it is done in an incautious manner, a security vulnerability known as the Confused Deputy Problem can lead to information disclosure or privilege escalation. The goal of this thesis is to use static typing to detect the dangerous uses of pointers that are controlled by userspace. Most operating systems are written in the C language. We start by isolating SAFESPEAK, a safe subset of it. Its operational semantics as well as a type system are described, and the classic properties of type safety are established. Memory states are manipulated using bidirectional lenses, which can encode partial updates to states and variables. A first analysis is described, that identifies integers used as bitmasks, which are a common source of bugs in C programs. Then, we add to SAFESPEAK the notion of pointers coming from userspace. This breaks type safety, but it is possible to get it back by assigning a different type to the pointers that are controlled by userspace. This distinction forces their dereferencing to be done in a controlled fashion. This technique makes it possible to detect two bugs in the Linux kernel : the first one is in a video driver for an AMD video card, and the second one in the ptrace system call for the Blackfin architecture. Analyse de mod`eles g´eom´etriques d’assemblages pour les structures et les enrichir avec des informations fonctionnelles Ahmad Shahwan To cite this version: Ahmad Shahwan. Analyse de mod`eles g´eom´etriques d’assemblages pour les structures et les enrichir avec des informations fonctionnelles. Other. Universit´e de Grenoble, 2014. French. . HAL Id: tel-01071650 https://tel.archives-ouvertes.fr/tel-01071650 Submitted on 6 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THESE ` Pour obtenir le grade de DOCTEUR DE L’UNIVERSITE DE GRENOBLE ´ Specialit ´ e : ´ Mathematiques et Informatique ´ Arretˆ e minist ´ eriel : 7 ao ´ ut 2006 ˆ Present ´ ee par ´ Ahmad SHAHWAN These dirig ` ee par ´ Jean-Claude LEON ´ et codirigee par ´ Gilles Foucault prepar ´ ee au sein ´ G-SCOP, Grenoble-INP et de MSTII Processing Geometric Models of Assemblies to Structure and Enrich them with Functional Information These soutenue publiquement le ` 29 ao ˆut 2014, devant le jury compose de : ´ M., John GERO Professor, University of North Carolina, USA, Rapporteur M., Marc DANIEL Professeur, Universite Aix-Marseille, Rapporteur ´ Mme, Marie-Christine ROUSSET Professeur, Universite Joseph Fourier, Examinateur ´ M., Jean-Philippe PERNOT Professeur, Arts et Metiers ParisTech, Examinateur ´ M., Jean-Claude LEON Professeur, Grenoble-INP, Directeur de these ` M., Gilles FOUCAULT Maˆıtre de Conferences, Universit ´ e Joseph Fourier, Co-Directeur de th ´ ese `Processing Geometric Models of Assemblies to Structure and Enrich them with Functional Information Traitement de mod`eles g´eom´etriques d’assemblages afin de les structurer et de les enrichir avec des informations fonctionnellesiii abstract The digital mock-up (DMU) of a product has taken a central position in the product development process (PDP). It provides the geometric reference of the product assembly, as it defines the shape of each individual component, as well as the way components are put together. However, observations show that this geometric model is no more than a conventional representation of what the real product is. Additionally, and because of its pivotal role, the DMU is more and more required to provide information beyond mere geometry to be used in different stages of the PDP. An increasingly urging demand is functional information at different levels of the geometric representation of the assembly. This information is shown to be essential in phases such as geometric pre-processing for finite element analysis (FEA) purposes. In this work, an automated method is put forward that enriches a geometric model, which is the product DMU, with function information needed for FEA preparations. To this end, the initial geometry is restructured at different levels according to functional annotation needs. Prevailing industrial practices and representation conventions are taken into account in order to functionally interpret the pure geometric model that provides a starting point to the proposed method. r´esum´e La maquette num´erique d’un produit occupe une position centrale dans le processus de d´eveloppement de produits. Elle est utilis´ee comme repr´esentations de r´ef´erence des produits, en d´efinissant la forme g´eom´etrique de chaque composant, ainsi que les repr´esentations simplifi´ees des liaisons entre composants. Toutefois, les observations montrent que ce mod`ele g´eom´etrique n’est qu’une repr´esentation simplifi´ee du produit r´eel. De plus, et grˆace `a son rˆole cl´e, la maquette num´erique est de plus en plus utilis´ee pour structurer les informations non-g´eom´etriques qui sont ensuite utilis´ees dans diverses ´etapes du processus de d´eveloppement de produits. Une exigence importante est d’acc´eder aux informations fonctionnelles `a diff´erents niveaux de la repr´esentations g´eom´etrique d’un assemblage. Ces informations fonctionnelles s’av`erent essentielles pour pr´eparer des analyses ´el´ements finis. Dans ce travail, nous proposons une m´ethode automatis´ee afin d’enrichir le mod`ele g´eom´etrique extrait d’une maquette num´erique avec les informations fonctionnelles n´ecessaires pour la pr´eparation d’un mod`ele de simulation par ´el´ements finis. Les pratiques industrielles et les repr´esentations g´eom´etriques simplifi´ees sont prises en compte lors de l’interpr´etation d’un mod`ele purement g´eom´etrique qui constitue le point de d´epart de la m´ethode propos´ee.Scientific Communications Accepted • Shahwan, A., Leon, J.-C., Foucault, G., and Fine, L. ´ Functional restructuring of CAD models for FEA purposes. Engineering Computations (2014). Articles • Boussuge, F., Shahwan, A., Leon, J.-C., Hahmann, S., Fou- ´ cault, G., and Fine, L. Template-based geometric transformations of a functionally enriched DMU into FE assembly models. ComputerAided Design and Applications 11, 04 (2014), 436–449. • Shahwan, A., Leon, J.-C., Foucault, G., Trlin, M., and Palombi, ´ O. Qualitative behavioral reasoning from components’ interfaces to components’ functions for DMU adaption to fe analyses. ComputerAided Design 45, 2 (2013), 383–394. In proceedings • Shahwan, A., Foucault, G., Leon, J.-C., and Fine, L. ´ Deriving functional properties of components from the analysis of digital mockups. In Tools and Methods of Competitive Engineering (Karlsruhe, Germany, 2012). • Li, K., Shahwan, A., Trlin, M., Foucault, G., and Leon, J.- ´ C. Automated contextual annotation of B-Rep CAD mechanical components deriving technology and symmetry information to support partial retrieval. In Eurographics Workshop on 3D Object Retrieval (Cagliari, Italy, 2012), pp. 67–70.Contents Acronyms xiii Introduction xv 1 DMU and Polymorphic Representation 1 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Product model . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Product prototype . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Product digital mock-up . . . . . . . . . . . . . . . . . . . . . 7 1.4.1 Computerized product models . . . . . . . . . . . . . 7 1.4.2 DMUs as models and prototypes at a time . . . . . . 8 1.5 Geometric models and modeling methods . . . . . . . . . . . 9 1.5.1 Geometric validity and the quality of a DMU . . . . . 10 1.5.2 Discrete geometric models . . . . . . . . . . . . . . . . 13 1.5.3 Analytical geometric models . . . . . . . . . . . . . . . 16 1.6 DMU as an assembly . . . . . . . . . . . . . . . . . . . . . . . 18 1.6.1 DMU structure . . . . . . . . . . . . . . . . . . . . . . 19 1.6.2 Components’ positioning . . . . . . . . . . . . . . . . . 20 1.7 Other information associated to a DMU . . . . . . . . . . . . 25 1.8 Application of DMU . . . . . . . . . . . . . . . . . . . . . . . 27 1.9 Basic principles of finite element analyses . . . . . . . . . . . 28 1.9.1 Numerical approximations of physical phenomena . . 28 1.9.2 Generation of a FEM . . . . . . . . . . . . . . . . . . 30 1.10 DMU as polymorphic representation of a product . . . . . . . 30 1.11 Adapted definition of DMU . . . . . . . . . . . . . . . . . . . 31 1.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2 Literature Overview 35 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.2 Function formalization . . . . . . . . . . . . . . . . . . . . . . 36 2.3 Connections between form, behavior, and function . . . . . . 38 2.3.1 Behavior to complete the design puzzle . . . . . . . . 38 2.3.2 Pairs of interacting interfaces . . . . . . . . . . . . . . 38viii Contents 2.3.3 Tools and guidelines to support the design process . . 39 2.4 Constructive approaches to deduce function . . . . . . . . . . 41 2.4.1 Form feature recognition . . . . . . . . . . . . . . . . . 42 2.4.2 Functionality as a result of geometric interactions . . . 44 2.5 Geometric analysis to detect interactions . . . . . . . . . . . . 46 2.5.1 Geometric interaction detection . . . . . . . . . . . . . 46 2.5.2 Importance of a unique geometric representation . . . 47 2.6 CAD and knowledge representation . . . . . . . . . . . . . . . 48 2.6.1 Domain knowledge and model knowledge . . . . . . . 49 2.6.2 Ontologies as an assembly knowledge storehouse . . . 49 2.6.3 Knowledge-based engineering approaches . . . . . . . 53 2.7 From CAD to FEA . . . . . . . . . . . . . . . . . . . . . . . . 55 2.7.1 Pre-processing at the core of the FEM . . . . . . . . . 55 2.7.2 Direct geometric approaches . . . . . . . . . . . . . . . 55 2.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3 Functional Semantics: Needs and Objectives 61 3.1 Taking 3D models beyond manufacturing purposes . . . . . . 61 3.2 Differences between digital and real shapes . . . . . . . . . . 63 3.3 Enabling semi-automatic pre-processing . . . . . . . . . . . . 65 3.3.1 Pre-processing tasks . . . . . . . . . . . . . . . . . . . 65 3.3.2 Pre-processing automation requirements . . . . . . . . 66 3.4 Bridging the gap with functional knowledge . . . . . . . . . . 67 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4 Functional Restructuring and Annotation 73 4.1 Qualitative bottom-up approach . . . . . . . . . . . . . . . . 74 4.2 Common concepts . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2.1 Function as the semantics of design . . . . . . . . . . . 75 4.2.2 Functional Interface . . . . . . . . . . . . . . . . . . . 76 4.2.3 Functional Designation . . . . . . . . . . . . . . . . . 78 4.2.4 Functional Cluster . . . . . . . . . . . . . . . . . . . . 81 4.2.5 Conventional Interface . . . . . . . . . . . . . . . . . . 85 4.2.6 Taxonomies . . . . . . . . . . . . . . . . . . . . . . . . 87 4.3 Method walk-through . . . . . . . . . . . . . . . . . . . . . . 91 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5 Functional Geometric Interaction 95 5.1 Functional surfaces . . . . . . . . . . . . . . . . . . . . . . . . 95 5.2 Geometric preparation and rapid detection of interactions . . 97 5.2.1 Geometric model as global input . . . . . . . . . . . . 97 5.2.2 Maximal edges and surfaces . . . . . . . . . . . . . . . 98 5.2.3 Geometric interaction detection . . . . . . . . . . . . . 99 5.2.4 Local coordinate systems . . . . . . . . . . . . . . . . 103Contents ix 5.2.5 Conventional interface graph . . . . . . . . . . . . . . 104 5.3 Precise detection of interaction zones . . . . . . . . . . . . . . 107 5.4 Form-functionality mapping . . . . . . . . . . . . . . . . . . . 108 5.4.1 Multiple functional interpretation . . . . . . . . . . . . 109 5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6 Qualitative Behavioral Analysis 111 6.1 Behavioral study to bind form to functionality . . . . . . . . 112 6.2 Reference states . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.3 Qualitative representation of physical properties . . . . . . . 114 6.3.1 Qualitative physical dimension . . . . . . . . . . . . . 115 6.3.2 Algebraic structure of qualitative values . . . . . . . . 121 6.3.3 Coordinate systems alignment . . . . . . . . . . . . . . 123 6.4 Reference state I: Static equilibrium . . . . . . . . . . . . . . 124 6.4.1 Static equilibrium equations . . . . . . . . . . . . . . . 124 6.4.2 Graph search to eliminate irrelevant FIs . . . . . . . . 125 6.4.3 Local failure of functional interpretation . . . . . . . . 129 6.4.4 Graph search example . . . . . . . . . . . . . . . . . . 129 6.5 Reference state II: Static determinacy . . . . . . . . . . . . . 130 6.5.1 Statically indeterminate configurations . . . . . . . . . 133 6.5.2 Force propagation and force propagation graphs . . . 137 6.6 Reference state III: Assembly joint with threaded link . . . . 138 6.6.1 Detection of force propagation cycles . . . . . . . . . . 139 6.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7 Rule-based Reasoning 145 7.1 Knowledge at the functional unit level . . . . . . . . . . . . . 146 7.2 Inference rules as domain knowledge . . . . . . . . . . . . . . 146 7.3 Reasoning alternatives . . . . . . . . . . . . . . . . . . . . . . 148 7.3.1 Dynamic formalization of domain specific rules . . . . 148 7.3.2 Problem decidability . . . . . . . . . . . . . . . . . . . 149 7.4 DMU knowledge representation . . . . . . . . . . . . . . . . . 150 7.4.1 Ontology definition through its concepts and roles . . 151 7.4.2 Ontology population with model knowledge . . . . . . 152 7.5 Formal reasoning to complete functional knowledge . . . . . . 154 7.5.1 Inference rules in DL . . . . . . . . . . . . . . . . . . . 155 7.5.2 The unique name assumption . . . . . . . . . . . . . . 157 7.5.3 The open world assumption . . . . . . . . . . . . . . . 158 7.5.4 Integration of DL reasoners . . . . . . . . . . . . . . . 159 7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163x Contents 8 Results and Comparative Study 165 8.1 Application architecture . . . . . . . . . . . . . . . . . . . . . 165 8.2 Application to industrial examples . . . . . . . . . . . . . . . 167 8.3 Integration with FEA pre-processors . . . . . . . . . . . . . . 173 8.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 9 Conclusions and Perspectives 177 9.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 A Fit Tolerancing and Dimensioning 183 B Dual Vectors 187 C Screw Theory 189 D Description Logic 193List of Definitions 1.1 Definition (Product model) . . . . . . . . . . . . . . . . . . . 2 1.2 Definition (Product prototype) . . . . . . . . . . . . . . . . . 4 1.3 Definition (Digital mock-up) . . . . . . . . . . . . . . . . . . . 32 4.1 Definition (Function) . . . . . . . . . . . . . . . . . . . . . . . 75 4.2 Definition (Functional Interface) . . . . . . . . . . . . . . . . 77 4.3 Definition (Functional Designation) . . . . . . . . . . . . . . . 78 4.4 Definition (Functional Cluster) . . . . . . . . . . . . . . . . . 81 4.5 Definition (Conventional Interface) . . . . . . . . . . . . . . . 87 4.6 Definition (Taxonomy) . . . . . . . . . . . . . . . . . . . . . . 88 5.1 Definition (Conventional interface graph) . . . . . . . . . . . 104 5.2 Definition (Functional interpretation) . . . . . . . . . . . . . 109 6.1 Definition (Reference state) . . . . . . . . . . . . . . . . . . . 112 6.2 Definition (Force Propagation Graph) . . . . . . . . . . . . . 137 B.1 Definition (General dual number ring) . . . . . . . . . . . . . 187 B.2 Definition (General dual number semi-ring) . . . . . . . . . . 188 C.1 Definition (Screw) . . . . . . . . . . . . . . . . . . . . . . . . 189 C.2 Definition (Reciprocal screws) . . . . . . . . . . . . . . . . . . 191List of Hypotheses 5.1 Hypothesis (Functional surfaces) . . . . . . . . . . . . . . . . 96 6.1 Hypothesis (Rigid bodies) . . . . . . . . . . . . . . . . . . . . 113 6.2 Hypothesis (Conservative systems) . . . . . . . . . . . . . . . 114 6.3 Hypothesis (Mechanical interactions) . . . . . . . . . . . . . . 114 6.4 Hypothesis (Static equilibrium) . . . . . . . . . . . . . . . . . 124 6.5 Hypothesis (Static determinacy) . . . . . . . . . . . . . . . . 134 6.6 Hypothesis (Force propagation) . . . . . . . . . . . . . . . . . 139Acronyms AI Artificial Intelligence. API Application Programming Interface. ARM Assembly Relation Model. B-Rep Boundary representation. BOM Bill of materials. C&CM Contact and Channel Model. CAD Computer Aided Design. CAM Computer Aided Manufacturing. CAPP Computer Aided Process Planning. CI Conventional interface. CIG Conventional interface graph. CIuG Conventional interface underling undirected graph. CNC Computer Numeric Control. CPM Core Product Model. CSG Constructive Solid Geometry. CWA Closed World Assumption. DIG DL Implementation Group. DL Description Logic. DMU Digital mock-up. DoF Degree of freedom. FBS Function-Behavior-Structure. FC Functional cluster. FD Functional designation. FE Finite element. FEA Finite element analysis. FEM Finite Element Model. FI Functional interface. FOL First Order Logic.xvi Acronyms FPG Force propagation graph. FR Feature Recognition. GARD Generic Assembly Relationship Diagram. GCI General Concept Inclusion. GD&T Geometric Dimensioning and Tolerancing. GPU Graphics Processing Unit. KBE Knowledge Based Engineering. KRR Knowledge Representation and Reasoning. MDB Model-Based Definition. NURBS Non-Uniform Rational B-Spline. OAM Open Assembly Model. OIL Ontology Interchange Language. OWA Open World Assumption. OWL Web Ontology Language. PDP Product development process. PFM Part Function Model. PLM Product Lifecycle Management. RDF Resource Description Framework. RDF-S Resource Description Framework Scheme. RS Reference state. SPARQL SPARQL Protocol and RDF Query Language. SSWAP Simple Semantic Web Architecture and Protocol. UNA Unique Name Assumption. URI Uniform Resource Identifier. VR Virtual Reality. W3C World Wide Web Consortium. XML Extensible Markup Language.Introduction When designing an artifact that is identified by its functionality, it is a common practice to decompose the artifact in question into components, each satisfying a well-defined set of functions that, put together, lead to the satisfaction of the desired functionality of the designed artifact. In the industrial context, components happen to be physical objects, de- fined by their shapes and materials that decide their physical properties and behaviors. In order for an object to deliver a precise function, its shape has to be carefully engineered. The 3D shape of the object dictates its interactions with its environment, i.e., its neighboring components, its neighboring products or a neighboring human being. These interactions define its behavior, thus its functionality. Because of this pivotal importance of components shapes to deliver their functions, tools were provided and conventions established to enable the production and communication of shape design models as part of the product development process (PDP). This emphasis is a natural outcome of a shapeoriented design process. Design intentions, however, are not clearly reflected in design models, in spite of their clear presence in engineers’ minds during the design process. In fact, no robust tools or agreed-upon conventions exist to link a particular design with its rationale. This observation used to be less pronounced at the time blueprints were used to define design models. Blueprints are 2D drawings that aim at unambiguously defining the shape of an object. They have been in use for so long that conventions converged toward globally understood agreements, and standards were put to govern such conventions [16, 183]. Nevertheless, the advent of Computer Aided Design (CAD) systems in early 80s soon provided designers with another geometric dimension that would remarkably influence industrial standards and conventions. 3D solid modelers prevailed as a natural choice for product design, engineers shifted to producing 3D models instead of traditional technical drawings, and mechanical components became dominantly represented as 3D objects in today’s models. This gave birth to the concept of digital mock-up (DMU), which gathered the representation of components of a product assembly in one geometric model. Efforts were paid to centralize the product knowledge in one place, andxviii Introduction the DMU was suggested as a natural candidate as it geometrically defines the product. In spite of attempts to homogenize and standardize the representations of non-geometric knowledge [12], defined standards are still poorly implemented in industrial practices because commercial software products are far from exploiting these standards. In fact, an industrial DMU, as currently available, is no more than a conventional geometric representation of a product assembly. A DMU can at best contain loose textual annotations, which may be interpreted within an organization or a working group, if at all interpretable. This is partially because a textual annotation does not relate precisely to a geometric subset of a component or an assembly. The need of design intentions, however, remained paramount, if the DMU is to be fully exploited in the PDP, and utilized beyond Computer Aided Manufacturing (CAM) applications. In fact, this knowledge is still being mined from geometric models of a product to feed applications such as geometric pre-processing of assembly models for simulation purposes. This is particularly the case of mechanical simulations where the structural behavior is a key issue that is commonly addressed using numerical methods such as the Finite Element Model (FEM). However, and due to conventional representations of functional and technological information in the DMU, the model preparation task for FEM is still mainly manual and resource intensive. This is particularly true for complex products like aircraft structures [1]. The user-intensive functional annotation of a DMU introduces a bottleneck into today’s highly automated PDP. In order to accelerate product development, an automated method should be established that enables the extraction of relevant functional information out of pure geometric representation of product assembly. Function is a key concept for designers and engineers that closely relates to the design activity and, hence, to the socalled design intent [107]. Consequently, it is highly important to provide engineers and designers with this functional information tightly connected with 3D component models, so that they can efficiently process them during the PDP. Furthermore, the desired approach should take into account mainstream industrial practices and conventions when interpreting geometric models. In this work, the focus is placed on the application to structural behavior of a product or, more precisely, of an assembly of components. The proposed method is an enrichment process that mainly aims at a seamless integration with geometric preprocessors for finite element (FE) simulation purposes, even though other applications can also be envisaged. In order for this method to provide an adequate input to finite element analysis (FEA) applications functional annotations and component denominations should be made in tight connection to precise geometric entities that they describe. To this end, geometry processing and reasoning mechanisms applied to mechanical behaviors are set up to adequately structure geometric models ofxix assemblies. In the rest of this document, Chapter 1 provides an introductory presentation of industrial concepts that relate to our work. It particularly presents what can be expected from an industrial DMU nowadays. Literature and work related to the proposed method is reviewed and analyzed in Chapter 2. Chapter 3 sheds more light on the motivation of our work, and the role that the proposed method plays in an efficient PDP. Chapter 4 defines concepts and terminology that are used across this document and upon which the proposed method is founded. It also provides an overview of this method before later chapters develop further on each stage. Chapter 5 develops in more details the geometric analysis of the input model, which is the pure geometric model of a DMU. This chapter shows how interactions between components are reconstituted on a geometric basis and how functional interpretations can be assigned to each of them. At this stage, the shape – function relationship cannot be unambiguously recovered. Chapter 6 then provides the means to functionally interpret those interactions in an unambiguous way, through a qualitative behavioral analysis of the model. This is algorithmic approach achieved through the tight dependencies between shape, function and behavior that produce a unique relation between shape and function for the interactions between components. The concept of reference states is then used to synthesize some component behavior through their interactions in order to reject irrelevant configurations, thus removing ambiguities. Further qualitative behavioral information is derived too. Chapter 7 completes the functional picture of the assembly using domain specific rules and taking the functional interpretation beyond the interaction level, toward the functional unit level, using the effective relationship between shape and function at the interface level and the newly derived behavioral information at the component and component cluster levels. It is an inference-based reasoning approach that can be adapted to the conventional representations of assemblies and meet the current practices observed in industry. Once the input model is geometrically restructured, and functionally annotated, it is made available as input for FEA preprocessors. Chapter 8 shows results of the application of the proposed method on examples varying from illustrative models to industrial scale DMUs. The same chapter also shows how the method successfully lends hand to a template-based geometric preprocessor, generating simulation models that correspond to the simulation objectives. Chapter 9 concludes this document, exploring potentials of future work to extend the proposed method and its application.Chapter 1 Digital Mock-Up and the Polymorphic Representation of Assemblies DMUs constitute a starting point to our research. Thus, it is indispensable to present basic concepts and definitions that are central to this work before detailing our approach. Those concepts are presented from different viewpoints according to the literature and to industrial practices, before an adaption of these concepts to our context is underlined. An analysis of a DMU content also shows how it can refer not only to a single representation of an assembly but to a polymorphic one. 1.1 Introduction In this chapter we provide a general understanding of a DMU, a concept which is central to our research. Then, we formally define this concept as it applies to the current work. To this end, we first present closely related notions that pave the way to the conceptualization of a DMU. We also show what kind of information it holds, and how this information is represented. Sections 1.2 and 1.3 demonstrate and distinguish two concepts: the product model and product prototypes. Though these terminologies are used interchangeably across literature, we clearly make the distinction according to our understanding, and to the context of this work. Then, the concept of DMU is analyzed in the following sections to address its representation from a geometric point of view as well as from a more technological point of view through the concept of assembly. This leads to the analysis of the effective content of an assembly and its relationship with a DMU. Subsequently, the generation of Finite Element Analyses from a DMU is outlined to illustrate into which extent a DMU can contribute to define a Finite Element Model.2 Chapter 1. DMU and Polymorphic Representation This finally leads to the concept of polymorphism of an assembly. 1.2 Product model In the context of product development, manufacturing processes of this product must be precisely defined, so that the resulting product matches its initial requirements, i.e., the product meets designers’ and users’ expectations. To this end, models are used to define the product in enough details as the outcome of an unambiguous and overall manufacturing process. Models consist of documents and schemes that describe the product, often visually. They often use common languages and annotations to refer to resources (materials, quantities, etc.) and processes (parameters, dimensions, units, etc.). Those annotations should be standardized, or at least agreed upon among people involved in the production process. Otherwise a model can be misinterpreted. Definition 1.1 (Product model). A product model is a document, or a set of documents, that uniquely define the manufacturing process of a product in compliance with its specifications [43, 140]. In this sense, models can be viewed as cookbooks showing how to produce instances of the product that conform to the same specifications. Models are closely related the production process for the following reasons: • To persistently capture the know-how of the production process. In the absence of such documentations, the manufacturing knowledge is only present in engineers’ minds, making this process highly dependent on the availability of experts. Models capture this knowledge and reduce the risk associated with such dependency; • To formally define the manufacturing process, leaving no room for ambiguity and multiple interpretations. This formality allows for the reproduction of identical instances of the same ‘pattern’, avoiding undesirable surprises due to miscommunication or improvisation of incomplete specifications. Otherwise, divergence in the final product may drift it away form initial requirements; • To allow tracking of and easy adaption to requirements. A product (or its prototype, as shown in Section 1.3) still may fail to fulfill the desired requirement. In this case, the product should be re-engineered. The existence of a model allows engineers to perform more easily modifications that can be directly mapped to the product characteristics to be amended. Another case when the product, thus its model, is to be re-engineered is when the requirements evolve, which is likely to happen in almost all industries.Product model 3 (a) (b) Figure 1.1: Examples of partial product model: (a) architectural blueprints; (b) software diagram. Product models existed quite early in different engineering domains such as architecture, mechanics, electrics, electronics, and computer software, among others. These models were not digital until a couple of decades ago. Depending on the discipline, some subsets of these models can be referred to as technical drawings, blueprints, draftings, diagrams, etc. Figure 1.1 shows examples of such models in different disciplines and applications. As pointed out earlier, the current concept of product model focuses essentially on manufacturing issues and does neither incorporate properties that ensure the consistency between its set of documents and the product obtained nor cover some parts of the product design process. Product model in the field of mechanical engineering When it comes to mechanical engineering, product models were traditionally referred to as technical drawings or drafting. In fact, those are 2D drawings that represents either a projection of the product onto a given plane according to a given orientation (usually perpendicular to the plane and aligned with a reference direction) and/or a cross section into the product components(s) [70]. These drawings form a part of the product model. As Figure 1.2 shows, precise annotations are used to augment those drawings with complementary information such as Geometric Dimensioning and Tolerancing (GD&T), some of which cannot be geometrically represented on a sheet. Such information is mandatory to allow people manufacturing the product [124]. This figure shows in red, shaft/housing tolerancing and dimensioning symbols explained further in Appendix A. Projection, cross-4 Chapter 1. DMU and Polymorphic Representation Table 1.1: Geometric tolerancing reference chart as per ASME Y14.5 – 1982. straightness planarity cicularity cylindricity line profile surface profile perpendicularity angularity parallelism symmetry position concentricity sectioning and annotations follow agreed-upon conventions that make the model as unambiguous as possible to a knowledgeable reader. Table 1.1 show standard dimensioning and tolerancing symbols as defined by ASME Y14.5 – 1982 [183]. 1.3 Product prototype It is preferable that design defects be outlined as early as possible in the product live cycle. More specifically, it is of high advantage that a shortcoming be reported before a real instance of a product is manufactured and machined. This is due to the high cost of machining and other manufacturing processes. If compliance tests are to be run directly on the real product, without any previous test on some sort of a “dummy” version of it, a considerable risk is involved since the product is likely to be re-engineered. The manufacturing and machining costs can be nearly doubled at each iteration. To this end, a prototype, close enough in its behaviors to the real product but with reduced production costs, is produced first. Then, different tests are run against this prototype to assess its conformity to different requirements and detect potential deficiencies. Whenever such shortcomings are revealed, the product model is adapted accordingly, generating a new prototype. Then, the process is repeated until the prototype is validated by all tests. This can be seen as an iterative process of modeling, prototyping, and evaluation. Subsequently, the product is progressively refined through multiple iterations. Definition 1.2 (Product prototype). A product prototype is a dummy representation of a real product, that is meant to emulate it in one or more aspects. It is used to assess or predict certain behaviors and/or interactions [160, 184]. Prototypes can emulate the product functionally, aesthetically, physically, ergonomically, etc. depending on the intended assessment planned on the prototype. Prototypes are vital in an efficient production process for the following reasons: • To allow early recognition of deficiencies. The earlier the deficiencies are detected, the lower the amendment cost is, since fewer stages are wasted and redone;Product prototype 5 Ø50H7 Ø41H7 Ø15p6 Ø69H8f7 Ø13H7g6 Figure 1.2: Blueprint of a mechanical product, showing a cross-section (top) and a projection (bottom). The projection also shows the cutting plane of the cross-section. The drawing shows in red, shaft/housing tolerance annotations.6 Chapter 1. DMU and Polymorphic Representation • To allow testing on life-critical products. Some highly critical industries, such as aeronautics, tolerate little or no failure once the product is put to operation. Errors can be fatal at this stage. Thus, prototypes allowing virtual tests on the product are necessary in such cases; • To help decision making. Studies show that decisions taken at early stages of a design process are highly expensive [47, 180]. However, oftentimes product behavior and the impact that it may entail cannot be precisely predicted at those stages. Prototypes enables engineers to do a sort of what-if analyses, and benefit form their feedbacks before taking a final decision about the product design. More recently, product prototypes evolved toward digital or virtual ones, which reduces further a product development process and can be achieved using digital simulations. It is worth noticing that tests run against prototypes do not replace quality and compliance tests that should be run on the real product. Product prototypes are just mock-ups, they emulate the products behavior to a certain extent, but not exactly. Prototypes are used in different engineering disciplines. In architecture and interior design scaled-down prototypes are used to give a global perspective of the structure before it is actually implemented (see Figure 1.3a). Architecture prototypes are often used for aesthetic and ergonomic assessments. In software engineering, incomplete versions of the software that fulfill certain requirements are implemented first to satisfy unit tests. Unit testing is in the core of software engineering best practices to avoid bulk debugging. Usually, one module of the software is tested at a time, with the rest replaced by mock modules. Product prototype in the field of mechanical engineering Approximate replicas of a mechanical product may be built to assess its ease of use, functionality, structural behavior, and so on. Those replicas are prototypes that are very similar to the designed product (see Figure 1.3a). However, a product and its prototype differ in how and from what each is made. Materials of the real product are usually costly, thus prototypes are built out of cheaper materials that have similar physical properties according to the intended tests. Moreover, the manufacturing and machining processes of the real product are often expensive as well, partially due to the choice for materials. Then, prototypes are crafted using different methods that reduce costs, keeping the final shapes as close as possible to the original design [160]. Figure 1.4 shows a prototype of a hand navigator [49]. The prototype is made of thermoplastic powder shaped by means of selective heat sintering.Product digital mock-up 7 (a) (b) Figure 1.3: Examples of product prototypes: (a) Architectural scale prototype of the interior of a building; (b) Full-size car prototype. Though the resulting object is perfectly fitted for concept proofing, machining techniques and materials are not suitable for mass production, once the product is approved. Despite their minimized cost, prototypes are often wasteful and nonreusable (apart in some discipline, like software engineering, where prototypes can later be integrated in an operational product). This makes the manufacturing process redundant: one manufacturing process at least for prototyping, and then another one for real production. It would be highly advantageous if some test could be directly run against the models themselves, without the need to create a prototype. 1.4 Product digital mock-up Sections 1.2 and 1.3 introduced product model and product prototype as historically two separate concepts. However, technological advances in information systems allowed engineers to merge those concepts into a single one, introducing little by little what become known as DMU in the domain of mechanical engineering. 1.4.1 Computerized product models With the introduction of information technology and its applications, engineering and production disciplines tended to make the most out of its possibilities. One obvious application was modeling. Engineers and designers soon got convinced to use computers instead of drafting tables to materialize their designs. This gave way to CAD systems, who were based on advances in computer-based geometric modelers. Geometric modelers were first two-dimensional, and offered little advantage over classical draft-8 Chapter 1. DMU and Polymorphic Representation Figure 1.4: Hand navigator prototype (Chardonnet & L´eon [49]). ing, apart their ease of use. Soon, those modelers started to address 3D solid modeling and integrated complementary facilities such as parametric and feature-based modeling [121, 54]. Digital product models became easier to produce and to interpret. With the advent of Model-Based Definition (MDB) paradigm [140, 43], these models were soon imported into the downstream manufacturing process, to allow what is now called CAM. CAD models contained information not only understandable by expert engineers, but also by machine tools to automatically configure some of the product manufacturing processes. An important revolution in the field of CAD was the introduction of 3D modelers, thanks to the fast-paced advancement of computer graphics. This gave the designers a better perception of their work, even tough incomplete. 3D models now allow engineers to perform basic prototyping, at least from an aesthetic point of view, with categories of shapes as prescribed by CAD systems. Indeed, each CAD software enables the generation of component/product shape within a range prescribed by its algorithms. As a result, CAD software can detect some geometric inconsistencies, e.g., self-intersections, invalid topologies, interferences, etc. (see Section 1.5.1 for a discussion on geometric validity of a DMU), when a component shape/product falls outside the range of shapes it can describe. Product models have become more than mere patterns that used to dictate how the product should be manufactured. The line that separated models from prototypes got thinner as more and more product assessments can be readily conducted on the models themselves. 1.4.2 Digital mock-ups as models and prototypes at a time Computerized product models that also played the role of prototypes are commonly called digital mock-ups (DMUs). They mainly contain the 3DGeometric models and modeling methods 9 geometric model of a product, but are not restricted to that. As product models they also incorporate supplementary information about material and other technological parameters. The goal of DMUs is not limited to manufacturing only. Now that they provide detailed geometry alongside material physical properties, different physical simulations can be set up, taking advantage of increasing computational capabilities rather than generating physical prototypes. DMUs can be seen as the result of advances in geometric modeling software and CAx systems. They directly support manufacturing processes, fulfilling the role of product referential models, as well as the basis of simulation mock-ups, and serving as product digital prototypes [177]. By the late 90s, a DMU was seen as a realistic computer simulation of a product, with the capability of all required functions from design engineering, manufacturing, product service, up to maintenance and product recycling [57]. From this perspective, the DMU stems from the merge of product model and product prototype. Product geometry is a key information around which the DMU is organized. Figure 1.5 shows an example of a DMU of a centrifugal pump as visualized by its 3D representation. Other types of information, essential for manufacturing and prototyping purposes are also present in the DMU, and will be discussed in more details in Section 1.7. In this sense, the DMU works as a repository of the engineering knowledge about a product that can be used throughout its life cycle [47]. Thus, DMUs are seen as the backbone of the product development process in todays industries [64]. Figure 1.6 shows how the generation of technical drawings can be partly automated using the 3D geometry of CAD models out of the product DMU. Then, GD&T can be carried out by engineers to add technological data. 1.5 Geometric models and modeling methods Often CAD systems consider a DMU as a set of components, that may also be called parts, assembled together to directly form the 3D representation of a product, or to form modules (sub-assemblies) that in turn are assembled into a product. Section 1.6 explains different methods and viewpoints about component assembly. In this section we are more concerned about how a component is represented geometrically in a CAD system. Geometric modelers are as important to CAD systems as the product geometric model is to DMUs. The geometric modeling process is highly influenced by the category of geometric model attached to a CAD system. Often, engineers choose to represent a component as a volume; a threedimensional manifold [131] that divides the 3D-euclidean space into three sets: its interior C, its boundary ∂C, and its exterior ∼C. Then, the ge-10 Chapter 1. DMU and Polymorphic Representation Figure 1.5: A DMU geometry of a centrifugal pump, showing different parts using colors. For a better understanding of the product shape, the DMU is sectioned by a vertical plane. ometric model commonly used in CAD systems is of type boundary representation (B-Rep) [119, 120]. In this case, the material of a component is described by the topological closure of its interior cl(C), which is the union of its interior and its boundary cl(C) = C ∪ ∂C [120]. 1.5.1 Geometric validity and the quality of a DMU As digital geometric representations of a product, a DMU may contain unrealistic, or unrealizable, configurations. An example configuration that is frequently encountered in industrial models is the volumetric interference between two solids. This configuration can lead to several interpretations: a. It might be a by-product of an imprecise design and it is therefore incorrect; b. It might also be a deliberate artifact to reflect some conventional meaning and, in this case, it has no impact on the correctness of the DMU.Geometric models and modeling methods 11 Figure 1.6: Automated generation of a technical drawing from a DMU that contribute to the definition of a product model.12 Chapter 1. DMU and Polymorphic Representation P Δ H D d Figure 1.7: A cross section of a threaded link between a screw and a nut represented as a simple interference in a 3D assembly geometric model. The sub-figure at the right shows how the cross section may look like in a real product, and the technological parameters it may have conveyed. H: height of the thread; P: pitch; d: minor diameter of external thread; D: minor diameter of internal thread; Δ: nominal diameter. Figure 1.7 shows an example where a threaded link is represented as such an interference, which falls into the interpretation of type b. Furthermore, some geometric modelers let a user create non-manifold configurations (see Figure 1.8). Some of these configurations are useful to produce a simplified representation of the real object that is needed to perform mechanical simulations using the finite element method (see Figure 1.8c and Section 1.9). Those configurations, however, are not physically realizable [131]. These unrealistic or unrealizable geometric arrangements put a question about the quality of DMU. One may ask what geometry to consider as valid, and what to reject or disallow, knowing that these configurations cannot be filtered out by the algorithms of a geometric modeler. In fact, the answer to this question highly depends on conventions being followed by the users or engineers because there is no representation standard that is used in geometric modelers to discard such arrangements. However, studying industrial models showed that there exists a general consensus in the domain of mechanical engineering that geometric degeneracies such as non-manifold configurations (see Figure 1.8a, b) should be avoided in a DMU, as they are often misleading as for how to be interpreted. Meanwhile, volumetric intersections are largely accepted, as they convey a particular meaning.Geometric models and modeling methods 13 (a) (b) (c) Figure 1.8: (a), (b), (c) Geometric models with highlighted non-manifold configurations. (c) is an example of simplified representation that can be used for a mechanical simulation. Manifold or not, digital geometric models defining products in CAD systems have their boundary represented either with faceted models, i.e., piecewise linear surfaces, or with piecewise smooth surfaces. Here, the first category is named discrete geometric models and the second one analytic geometric models. 1.5.2 Discrete geometric models Discrete geometric models consist of a finite set of geometric elements topologically connected to each other to define the boundary of a shape. These elements are manifolds that can be either one, two, or three-dimensional. The very basic geometric element is a vertex : a point lying in 1D, 2D or 3D-space, this is a zero-dimensional manifold. Two vertices connect to each other defining a line segment or edge that is a one-dimensional manifold. An aggregation of edges on the same plane can form a piecewise 1D curve. If every vertex of this aggregation is topologically connected with at most two edges per connection1 the curve is indeed a onedimensional manifold. A 1D closed2 manifold and planar curve with no self-intersection bounds a discrete planar area or face, i.e., a two-dimensional geometric entity. An aggregation of faces connected to each other forms a faceted 2D surface. If every edge of this aggregation is topologically connected with at most two faces, while the connection between faces happens uniquely at their boundary, i.e., at the edge level, the surface is a two-dimensional manifold. A 2D closed3 manifold surface with no self-intersections bounds a solid, 1Connection between edges happens at their boundary, i.e., either of their vertices. 2A closed curve is a curve in which a connection happens at every vertex of each of its edges. 3A closed surface is a surface in which a connection happens at every edge of each of14 Chapter 1. DMU and Polymorphic Representation (a) (b) Figure 1.9: Geometric models of a teapot: (a) discrete model (triangular surface mesh); (b) analytical model (composite free-form shape obtained from a set of surface patches). a three-dimensional geometric entity. Solids can be aggregated to form more complex ones. If this aggregation is topologically connected in a way that connection happens uniquely at face level the resulting solid is manifold. Discretized models are also called meshes. Meshed objects used in a product development process to describe a solid are represented in one of two ways: Surface meshes Using a discrete closed surface to define the boundary between the interior and the exterior of the object. Those surfaces are decomposed of faces, as mention before. Faces can have an arbitrary number of edges each, however, surfaces are usually built out of triangles and/or quadrangles. These models are also called polygon meshes. Figures 1.9a and 1.10b show examples of surface triangular meshes; Volume meshes Using a set of connected simple volumes, such as tetrahedrons and/or hexahedrons. These models are also called polyhedron meshes. Figure 1.10c shows a cut in a tetrahedral volumetric mesh of a fan blade foot. Discrete geometric representations are simple. However, they are not suitable for the up-stream design phases of a PDP for the following reasons: • They are approximate representations that imprecisely capture the designed concept, as they fail to accurately define smooth curves and surfaces that are mandatory for manufacturing processes. Powerful shape modeling algorithms are not available in CAD systems; its faces.Geometric models and modeling methods 15 (a) (b) (c) (d) Figure 1.10: Geometric models of a mechanical part (foot of a fan blade): (a) complete B-Rep analytical model; (b) complete discrete model; (c) a cut into a volume mesh showing tetrahedrons internal to (b); (d) a section into a surface mesh showing that the triangles lie on the surface of the solid.16 Chapter 1. DMU and Polymorphic Representation • Meshes are scale dependent, their level of details, i.e., their roughness, cannot be adjusted to obtain smoother shapes once the model is generated; • The roughness of these models hinder their utilization for machining purposes in the down-stream process, where smooth realizable surfaces are expected unless the roughness is lower than that of the manufactured surface. This constraint however requires a too large amount of storage to be used for complex products. As a result, geometric modelers of CAD systems are rarely discrete, although discrete models can be generated from analytical ones for applications in finite element simulations (see Section 1.9) and prototyping. 1.5.3 Analytical geometric models Analytical geometric models use the same concepts defined for discrete models to describe the topology of their B-Rep model, i.e., vertices, edges, and faces. However, this topological representation is associated with geometric models such that edges need not be linear, and faces need not be planar anymore in these models. This allows for a concise yet precise representation of smooth piecewise curves and piecewise surfaces. While vertices still represent points in the euclidean space, an edge is only partially defined by its two endpoints, since it is also characterized by the curve on which it lies. To this end, curves are represented mathematically, either as canonical geometric shapes such as lines and conic sections, or as parametric equations such as B-splines and B´ezier curves. The same principle applies to faces which are characterized by the surface they lie upon, beyond their boundary edges. Carrier surfaces are also represented mathematically, either as canonical surfaces such as planes, spheres, cylinders, cones, or tori, or as parametric equations such as B-spline or B´ezier surfaces, or as implicit surfaces. Just as in discrete models, two vertices connect to each other forming and edge, a set of edges forms a composite curve, either manifold or not4. A closed manifold composite curve defines the boundary of a face, faces are aggregated to form composite surfaces, again they may or may not be manifold5. A closed, orientable surface, without self-intersection, defines a solid C while forming its boundary ∂C. Analytical geometric models are faithful to the original geometry that a designer had in mind since they are accurate representations of a real object. They are scalable with no information loss. Those properties make 4Manifold composite curves connect at most two edges at each of their vertices. 5Manifold surfaces connect at most two faces at each of their edges, while edges are free to be decomposed into smaller onesGeometric models and modeling methods 17 Figure 1.11: An example of CSG tree where leaves are geometric primitives, ∪ is a Boolean union, ∩ is a Boolean intersection, and − is a Boolean difference. it easier for geometric models to provide a reference for processes located down-stream with respect to the design process. CAD systems use analytical representations of objects because of these favorable properties [120, 121]. Geometric modelers represent analytical models in one of following ways: Generative methods Where the object is defined by the process of its generation. One such method is the Constructive Solid Geometry (CSG) whereby an object is represented as a tree whose root is the geometric object and its leaves are elementary geometric entities, i.e., primitives or geometric objects generated by other generative methods, and internal nodes are geometric Boolean operations, i.e., union, intersection, differences. Other generative methods are sweeping, rotation, extrusion, etc. that generate 3D entities out of 2D sketches. These models are useful to describe products because they keep track of a history of their modeling process and because they allow easy modifications. Geometry modifications are frequent during a product development process, hence the long lasting interest of CAD systems in history trees. Figure 1.11 shows an example of a CSG tree and corresponding geometric shape at each step of its construction; Descriptive methods Such as B-Rep, where the object is defined by its boundary. This object is represented by a set of closed, oriented, non-intersecting surfaces that forms a multiply connected volume. These models keep no track of the construction process, however their data size is smaller18 Chapter 1. DMU and Polymorphic Representation than that of their CSG counterparts. Figure 1.9 shows an example of a teapot analytically represented by its boundary. However, B-Rep models are automatically generated from any CSG description: each CSG boolean operation has a corresponding B-Rep transformation that represent the results in the B-Rep description. Actually, hybrid model are used in the DMU context where different BRep representations are linked: the CAD B-Rep model is the “exact” representation of the geometry, the visualization model is a 3D mesh approximating surfaces of the CAD model for user interaction, while FE mesh model is used for physical simulation using the finite element method. Parametric and feature based methods Which add geometric parameters and shape feature semantics to the primitives of CSG representation and its resulting B-Rep model. Featurebased and parametric model represents the history of the geometry construction process with a tree where leaves are parameterized shape features having shape characteristics and often functionnal and/or manufacturing significance: holes, chamfers, pads, pockets, blends, fastners, etc. Features associate properties and parameters to a set of topological and geometrical entities of the B-Rep model and a CSG primitive shape: • geometric properties (dimensions such as hole diameter, 2D sketches, extrusion direction, revolution axis, sweeping curve, blending radii, etc.); • application-specific properties (machining tool parameters, toolpath, weld beads, threading parameters, glued surfaces). Many feature descriptions have a significance for several applications, e.g. a revolution cut can have a functional meaning (location of a bolted joint), a manufacturing meaning (drilling process), an assembly process meaning (fastening process), or a simulation meaning (definition of boundary conditions for FEA simulation). Unfortunately, manufacturing and functionnal properties are often missing in feature-based models due to various reasons: the time required to describe functions with features is often too long, manufacturing and functional features available in STEP ISO-10303 standard [7] and implemented in commercial software cover a small part of configurations. 1.6 DMU as an assembly Products functionalities are satisfied by mechanical components that are assembled together to function consistently with respect to each others.DMU as an assembly 19 Vehicle Structure Powertrain Body Chassis Gearbox Engine Gearbox Engine Chassis Powertrain Frame Body (a) (b) Figure 1.12: Two possible simple structures of a car DMU: (a) Assembly tree organized as per function; (b) Assembly tree organized as per order of mounting. The DMU reflects this grouping by representing the product as an assembly of parts, each representing one mechanical components. This grouping can occur at different levels to form a tree structure, as components are gathered in sub-assemblies. 1.6.1 DMU structure This multi-level organization gives the assembly a tree-like structure for which the root is the product, nodes are sub-assemblies, and leaves are components. We note that if generative methods are used to model components, the latter are also represented in a tree-like structure in CAD systems, with leaves being the geometric primitives and nodes geometric construction operations (see Section 1.5.3). The hierarchical organization of a DMU using an assembly tree structure is not intrinsic to a product, rather it depends on the criterion used to set up the tree structure, e.g., functional, organizational, or assemblability. This criterion is user-defined and the tree structure is defined interactively by the user. Functional criteria Components may be grouped according to their functional contribution to the product. In this case, sub-assemblies represent functional modules. For example, a car assembly may consist in a structure and a powertrain. While powertrain can be decomposed into engine, gearbox, driveshaft, differential, and suspension (see Figure 1.12a). Each of these denominations represent a functional grouping, a unit that satisfies a specific function of a car6. Functional modules in their turn consist of components interacting to fulfill a function. 6The decomposition is simplified from what a real car assembly is.20 Chapter 1. DMU and Polymorphic Representation Figure 1.13 shows a snapshot of a commercial CAD software (CATIA V5) showing the tree structure of the DMU of a centrifugal pump shown on Figure 1.5. Sub-assemblies are organized according to their functional properties. The tree expands the casing sub-assembly (Carter pompe centrifuge) having as function to contain the fluid, inside which it expands the volute housing part (Volute pompe) having as function to drive the centrifugal movement of the fluid. Organizational criteria Sub-assemblies arrangement may also reflect criteria based on manufacturing and organizational choices rather than internal functional coherence. For instance, if different components of the product are designed and/or manufactured in different companies, those parts are likely to be separated in a sub-assembly, even though they do not constitute a valid functional unit on their own. Figure 1.14 shows how the aircraft structure of an Airbus A380 is divided into subassemblies, each being manufactured at a different facility, possibly in a different country. Assemblability criteria Another aspect that can be encoded in a digital assembly structure is the mounting sequence of components alongside the assembly line. In this case, a sub-assembly represents a set of elements, i.e., components or other sub-assemblies, that are put up together at once. The depth of hierarchy represents the order in which installation occurs. For instance, while chassis and powertrain are two different sub-assemblies of a car, powertrain itself is decomposed into engine and gearbox whose components are mounted separately, and at an earlier stage than the assembly of the powerengine (see Figure 1.12b). It is worth mentioning that no matter what criterion is used to organize a DMU structure, this knowledge is still partial and unreliable. This is not only the subsequence of lack of norms and standards, but also because the strict tree-like structure is incapable of representing certain semantic groupings such as functional clusters where overlapping sets may occur, or kinematic chains where cyclic graphs are expected rather than a tree structure. 1.6.2 Components’ positioning In real configurations, components are positioned relatively to each others through contacts and other assembly techniques, e.g., clamping and welding. In a DMU, however, the product is represented as a geometric model, and its components as digital solids (see Section 1.5). Contacts lose their physical meaning, welding and gluing are rarely represented, and some other unreal-DMU as an assembly 21 Figure 1.13: A snapshot from a commercial CAD software (CATIA V5) showing a DMU as its geometric representation (see Figure 1.5), alongside its tree-structure.22 Chapter 1. DMU and Polymorphic Representation 1 2 3 4 5 6 1 7 1 Hambourg (Germany) 2 Broughton (UK) 3 St. Nazaire/Nantes (France) 4 Stade (Germany) 5 St. Nazaire/M´eaulte (France) 6 Getafe/Puerto Real (Spain) 7 Toulouse (France) Figure 1.14: Airbus A380 airframe sub-assemblies, not organized according to their functions (cockpit, cabin, wings, tail, etc.) but according to the place were they are built (courtesy EADS). istic geometric configurations, such as interferences, may also take part in a DMU (see Section 1.5.1). Therefore, relative positioning should be represented in different means to convey this attachment. A set of welded or glued parts forming a single component, for instance, are usually represented as separate components since they are manufactured separately prior to the welding or gluing process. In this case, a simple contact that would represent the welding or gluing zone in a DMU is not enough to assert that components are fixed in position with respect to each others. This first observation shows that pure geometric information to assess connection between components is ambiguous. Further, this ambiguity is often not removed in a DMU because the complementary information needed does not exist in the DMU. It is up to engineer to interpret the DMU and derive to correct contact information. Now, concentrating on the purely geometric information related to the spatial position of components; let us carry on the analysis of a DMU content. Figure 1.16 shows a model of an internal combustion engine, with a section cut in the combustion chamber showing how the piston (the green object) fits in the cylinder of the chamber. It also shows how the pistonDMU as an assembly 23 links to the crankshaft (the blue object) through multiple pivot links. Different ways can be used to represent components’ positioning and orientation, depending on what to expect from the DMU. Kinematic links For kinematic simulation purposes, where animations of the mechanism are to be generated, kinematic connections define relative positions between objects, leaving some degrees of freedom (DoF). Simple connections, also referred to as lower pair connections are classified into prismatic, cylindric, screw, planar, and spheric connections [83]. In the example of the internal combustion chamber, a sliding pivot joint between the piston and the cylinder, which is a cylindric connection, aligns both axes leaving two DoF: rotation around and translation along the common axis7. The connection between the connecting rod and the crankshaft is defined by a pivot link that allows only a rotation around their common axis B. Figure 1.15 shows the kinematic diagram of the mechanism of a slider-crank. Geometric constraints Manufacturing models give more importance to how components are located with respect to each other, rather than what relative motions they exhibit. Thus, relative positions of components can be defined through geometric constraints such as coincidence, concentricity, coaxiality, distance, etc. These constrains usually leave the object stationary, i.e., with zero DoF. Constraints that are not defined by the designer are assumed by the modeler, usually in terms of linear and angular distances, leading to a static representation of the product. In the example of the combustion chamber shown in Figure 1.16 a coaxiality constraint is defined between the piston and the internal cylinder of the chamber. The distance between the piston and the back end of the chamber is either defined or assumed. Absolute positioning Another way to create the scene of an assembly is to directly position and align objects according to a global coordinate system defined assembly-wise. This is usually achieved using an affine transformation matrix per object. The latest approach is the simplest, though it has many disadvantages: • Setting the parameters of transformation matrices during design is cumbersome. Designers usually define their concepts by means of kinematic or geometric constraints; 7Rotation is eliminated when considering other connections in the mechanism.24 Chapter 1. DMU and Polymorphic Representation 0 1 2 3 A B C 0 1 2 3 0 A B C Figure 1.15: A drawing of a slider-crank mechanism (left) and its corresponding kinematic diagram (right): (0) Chamber; (1) Piston; (2) Connecting rod; (3) Crankshaft. A, B and C are points locating the rotation axes of the crankshaft, connecting rod, and piston, respectively. • Editing of the assembly model is more complicated, since constraints propagation should be considered manually now and the consistency of the assembly model is harder to achieve; • Kinematic links are indicators of relative motion properties between components. This information is lost when fixing components in place in an absolute manner. Nevertheless, standardized formats describing components and assemblies across CAD software, such as STEP [7], still use absolute positioning of assembly components, as it is globally recognized by all geometric modelers. Geometric modelers, in their turn, allow the exportation of models in such formats, even though native models usually use one of the first two methods, or a combination of them to position and align components. While kinematic links explicitly characterize the relative motion between components using rotations axes and sliding directions, geometric constraints are meant to fix components in place, generating an instantaneous representation of the product at a given moment in time. Another distinctive difference between these two methods is that geometric constraints, as per definition, must refer to explicit geometric entities of components, unlike kinematic links, such as helical motion, where certain attributes, such as pitch, can be provided as a parameter, independently from any geometric support. Other kinematic links, e.g., pivot link, do not need to refer to geometric entities of the components, e.g., the cylindrical surfaces of the pivotOther information associated to a DMU 25 link, which means that the existence of a pivot link does not mean that the corresponding components are geometrically consistent, i.e. of same diameter. Considering that a product is subjected to numerous modifications during its design process, this shows that kinematic links alone are not a reliable source of data to ensure that a DMU is consistent with respect to the relative position of its components. Moreover, geometric constraints are of minor significance to design intentions, since designer may use misleading geometric alignments for the sake of ease of use. An example would be the alignment of the piston with the chamber in Figure 1.16. One may assume that the contact between the surface Sp of the piston and the internal one Sc of the chamber could be inferred thanks to a coaxiality constraint, plus an additional diameter check. However, this conclusion is not always achievable as the user-defined positioning can be obtained by aligning, say, the axis Ap of Sp to the axis of any given external cylindric or conic surface, Scy or Sco respectively, of the chamber, leading to the same exact geometric configuration. Kinematic links in turn bear an inherent sense in the context of motion simulation and analysis. They are, however, often disconnected from boundary geometric elements. For instance, if kinematic links are used in the example of the combustion engine, the piston can be linked to the chamber by means of a sliding pivot link. To establish this link, cylinder axes Ap and Ac should be used. Such a link makes no reference to concrete geometric entities such as boundary surfaces Sp and Sc (thus no reference to contact zones) and leads to no avail when geometric interactions detection is sought. As a conclusion, this renders reasoning based on geometric constraints or kinematic links an unreliable approach. Globally, none of the three methods to position components in an assembly is, alone, sufficient to ensure the geometric consistency of an assembly model. 1.7 Other information associated to a DMU So far a DMU is regarded as a set of geometric objects (components) grouped together in a hierarchical structure (sub-assemblies). This representation incorporates geometric information about the product, plus some kinematic properties as seen in Section 1.6.2. However, and in order to efficiently participate to the PDP, the DMU has to integrate other information about the product and its components rather than its geometry, kinematic links, and assembly structure. This information adds up to the geometry of components, but is not part of it. One reason that this “extra” information is needed is the fact that the geometry of the product is often simplified in a DMU (see Figure 1.17), thus differing from the shape of physical components. Standards as well as companies’ practices suggest to compensate this loss of information due to26 Chapter 1. DMU and Polymorphic Representation Figure 1.16: A DMU of an internal combustion engine. A section cut in its combustion chamber shows the piston (in green), and the crankshaft (in blue). geometric simplification by other means of auxiliary annotations. Figure 1.7 shows an example of information lost due to such a simplification. The ISO standard SETP AP214 [12], for instance, provides annotations such as thread, where geometric properties such as major diameter, minor diameter, pitch, number of threads and hand can be expressed explicitly [69]. This allows the threaded part of a screw or a nut to be geometrically simplified, e.g., as cylindric surface. Another kind of such necessary annotations in the context of a PDP is important information that cannot be represented geometrically. An example is component material and its physical properties. Though it relates in more than a way to geometry, kinematic knowledge about the product also falls into this category, since relative motion holds more information thanApplication of DMU 27 (a) (b) Figure 1.17: Screw and nut (a) in real configuration, (b) as simplified geometric model. instantaneous shape snapshots. Integrating materials and their properties in the DMU is necessary to enable the generation of detailed bills of materials (BOM), which design office communicates to other departments such as purchase department [74]. BOM contains detailed information about required parts and material to enable the manufacturing of a product [165]. This information is used to prepare orders and manage inventory. A close look at industrial practices shows that this information is scattered around the DMU in a non-standardized manner, making the task of exploiting such knowledge a challenging one. Iyer et al. [90] show that modern Product Lifecycle Management (PLM) systems provide the DMU with a context that allows annotations such as keywords and part name, etc. Authors, however, show that these annotations are not robust, and of little use for information retrieval. They attribute this inadequacy to reasons among which are the non-unified conventions among design personnel, and the change of industrial context with time. 1.8 Application of DMU DMUs are computerized models that engineers use to communicate their designs to the manufacturing as well as other company departments. Their obvious application then is to provide the pattern upon which the product is to be built. However, they contain enough information that allows engineers to use them at other stages all along a PDP. In the previous section we saw that a DMUs contains supplementary annotations that allow the generation of reports, such as BOM, necessary for inventory and purchase management. Another important application of DMUs is the generation of simulation models. Since they closely represent product geometry as well as other phys-28 Chapter 1. DMU and Polymorphic Representation ical properties, DMUs are good candidate to extract simulation models out of them. Extracted models differ according to the goal of the simulation, we can recognize structural simulation models, thermal simulation models, fluid simulation models, among many others. A prominent simulation method in todays PDP is the finite element method, Section 1.9 sheds more light on this method. Auxiliary annotations, particularly kinematic connections between components, contribute to a special type of simulations that are based on the content of a DMU, this is Virtual Reality (VR) simulations. Some VR simulations have their applications in high risk environments when testing and training is too dangerous to be performed in real environments. In such cases, a DMU can be used to generate a simulation model where the desired tasks can be conducted in a completely virtual setup. As demonstrated in Section 1.6 DMUs also provide a structure that group components into subassemblies that are then grouped themselves into an assembly representing a functional product. In this context, DMUs play also an important role in the assembly/disassembly planning process of PDP. Considering its diverse applications, a DMU shows a prominent presence at different stages of todays PDP. 1.9 Basic principles of finite element analyses The finite element method has shown its merits in different simulation applications. In this section we introduce, in a nutshell, the basic concepts of finite element analysis (FEA). 1.9.1 Numerical approximations of physical phenomena FEA is a numerical method in which certain physical behavioral phenomena are studied and analyzed using numerical approximations of real objects called FEMs. A FEM contains a discrete representation of objects’ materials in space, achieved using one-, two-, or tree-dimensional meshes (see Section 1.5.2). Information about material physical properties are assigned to the mesh at the element level. An element can be an edge, a polygon or a polyhedron. Figure 1.18 shows an example of the results of a FEA on a pump casing to study heat conduction. FEA simulations are in the heart of modern PDPs and product validation practices. The FEM is prominent in most of behavioral studies of a product prototype. The process of FEA consists in three general steps: pre-processing In this phase, the FEM is generated. This can be done from scratch, building the mesh model at first, then assigning it physical attributes. Nevertheless, in today’s industries the CAD model,Basic principles of finite element analyses 29 Figure 1.18: A FEM of a pump casing showing the results of a heat conduction analysis. which is usually an analytical one (see Section 1.5.3), tends to be integrated with a mesh to facilitate the propagation of modifications between these models. Then, the mesh acquired is in turn enriched with material properties, in order to obtain the FEM. This process is not as straightforward as it may seem, since many factors affect the quality of the generated model, thus results’ accuracy when an FE model can be effectively obtained. Such factors are how close the approximate model, i.e., the meshed shape, is to the original objects; how many elements does the model have; what are the distribution and the quality of those elements over the original domains, etc. analysis Now that the FEM is produced, the simulation problem is solved by dividing it into simpler ones at the FE level, using differential equations with boundary conditions. The type of equation used depends on the desired simulated phenomenon. For instance, while EulerBernoulli beam equations are used for structural simulations [82], heat diffusion formulas are applied for thermal behavioral studies [45], and Navier-Stokes equations for fluid simulations [18]. The solution boils down to an error function minimization problem, respecting boundary conditions.30 Chapter 1. DMU and Polymorphic Representation post-processing The analysis phase comes out with observed variables values over the meshed domain, i.e. solution fields. Those fields represent studied changes in physical properties such as displacements, temperatures, etc. To provide a global overview of the underling simulation, those fields can be visualized using color codes, that allow enginners to better estimate zones of interest. In this work we are only concerned about the first step; the pre-processing. 1.9.2 Generation of a FEM Pre-processing has a crucial impact on the efficiency, performance, and accuracy of later steps of FEA. Many choices are made at this stage such as shape simplifications, mesh element dimension (linear, surface, or volume) and mesh element shape, e.g., triangular, quadrangular, tetrahedral, hexahedral, etc. The resulting FEM highly depends on the observed phenomenon and the ultimate goals of the FEA. To this end, simulation objectives should be outlined first, such objectives can be either structural study, with deformable bodies, or thermal behavioral analysis, etc. Once objectives are defined, assumptions about the relevance of geometric areas can be made, leading to simplification hypotheses characterizing some areas as details with respect to the simulation objectives. This enables the reduction of models’ complexity through shape transformations [41]. Entire shapes of objects or a small subset of them can either be simplified (case of dimension-preserving transformations, e.g., hole removal from a volume that transforms a volume into a new one), or idealized (case of dimension-reducing transformations, e.g., replacing a thin and elongated volume with a beam that transforms a volume into a line). The shape transformation process generates what we refer to as simulation model, also called mechanical model in the literature [168, 21, 80]. Alike the DMU, the simulation model contains a geometric representation of the assembly that is dedicated to simulation purposes rather than manufacturing ones. Such differences refer to the concept of product view where the simulation view is distinguished from the design one (see Figure 1.19). Along with the simplification hypotheses and simulation objectives, the simulation model provides essential knowledge to generate the required FEM. Figure 1.19 depicts how, for a given simulation context, geometric transformations generates a simulation model out of an assembly DMU, whose mesh is then generated to produce the FEM [41].DMU as polymorphic representation of a product 31 Simulation Model DMU FEM Simplifications & Idealizations Product Design FE Mesh Generation Simulation Objectives & Hypotheses Upstream Product View Simulation Product View Figure 1.19: A flowchart showing processes and models involved in the preparation of a DMU for FEA. It locates the simulation model as a result of the simplification and idealization processes, and as an input of the FE mesh generation process. 1.10 DMU as polymorphic representation of a product Different applications of a DMU require different types of information, and different levels of details, particularly when geometric representations are included in these applications [71]. For instance, while purely volumetric models are recommended for manufacturing and machining applications since they most accurately represent the real shape of components, reduced-dimension configurations are tolerated, even recommended, for simulation-oriented applications where geometric details become a burden and shape simplicity is prioritized over its accuracy to promote the accuracy of the simulations results. In the same context, GD&T information is vital for manufacturing department, while relative motion properties are usually irrelevant at this stage. However, such kinematic knowledge is essential for rigid body simulations where geometric details such as manufacturing tolerances are meaningless. This diversity of applications requires the DMU to show different forms, or views, according to the level of details that the application implies. In this sense, the DMU acts as a polymorphic representation of the product, where the shapes of components as well as their associated annotations are dependent on the nature of the application.32 Chapter 1. DMU and Polymorphic Representation 1.11 Adapted definition of DMU The concept of DMU has been developed across the literature, and many works have tried to establish a definition. Those definitions all agree that a DMU is a digital representation of a product that contains at least its 3D geometry down to a certain level of details. They also assent that it plays a major role in the PDP. However, they differ in defining to which extent a DMU participates to certain stages such as simulation and validation. Some definitions extend the concept of DMU to the point where it corporates all virtual prototyping, referring to simulation models as part of the DMU since they are indeed a digital representation of the product [57, 177]. Other works restrict DMUs to models that fit directly the purpose of design and manufacturing. While simulation models can be generated based on DMUs, these simulation models are not effectively part of them. In our work we adopt the following definition. Definition 1.3 (Digital mock-up). A DMU is a computerized representation of a product as an assembly of sub-assemblies and components in a hierarchical structure. It represents product geometry, possibly at different levels of details. DMUs also contain supplementary information about the product and its components that is casted in compliance with the intended application. This definition puts forward the polymorphic nature of a DMU since geometry and other associated information are adaptable to the application in which a model fits. It is worth mentioning that although the concept of DMU covers a wide variety of functional, kinematic and technological informations [69], only few efforts are made to standardize non-geometric data. Therefore, in the scope of the present work, we are only considering the geometric information that a DMU holds, where components are positioned absolutely according to a global (product-wide) coordinate system as it is the case for standardized formats such as STEP. Other information such as kinematic links, technological annotations, etc. are not considered because they are ambiguous and unreliable. 1.12 Conclusions DMUs accompany PDP and are now much more than manufacturing issues as analyzed in Sections 1.8 and 1.9, and particularly in Section 1.9.2. Indeed, DMUs have become focal to modern PDPs as they represent a central data repository of a product incorporating models as generated by the engineering design office.Conclusions 33 Further than a product model, DMUs contribute nowadays to the generation of virtual prototypes that feed numerical simulations to assess product functionalities (see Section 1.9). This data repository is organized around a geometric model that forms the kernel of a DMU (see Sections 1.5 and 1.6.1). However, considering the geometric interactions between components of a product, as they are represented in a DMU, Sections 1.5.1 and 1.6.2 have shown that the digital shape of components may significantly differ from that of physical ones and component positioning techniques do not ensure the consistency of an assembly. Engineers’ know-how refers to various conventions and standards to interpret component shapes as well as their relative positions. These conventions and standards are not part of the CAD systems used to produce and modify the geometry of DMUs. In addition, the diversity of processes, e.g. FEA, assembly simulations, requiring a pre-processed DMU as input leads to the concept of polymorphism (see Section 1.10). Complementary information can be attached to components and/or subassemblies (see Section 1.7) or derived from assembly models (see Section 1.6.2) but it appears that the robustness and reliability of these informations do not strengthen a DMU and, in addition, are not easily accessible. Among all these informations, it is important to mention that functional information is not explicit in a DMU and consequently, there is no effective link between any description of a function and some corresponding geometric entities in a DMU. In the present work, the focus is placed on the generation of explicit functional information attached to components and sub-assemblies. The attachment of such information to geometric entities is of strong interest since the polymorphism of DMUs is a key requirement to pre-process them and generate virtual prototypes. Among the virtual prototypes that can take part to a PDP, the structural behavior of a product is of increasing importance. Therefore, the shape transformations taking place during the pre-processing for FEA is of strong interest, especially in the case of assembly behavior. Relating shapes, i.e., the geometry of assemblies, to component functions in order to ease the assembly pre-processing for behavioral simulations is a consistent objective addressed here. To this end, further analyses of prior work that relate shape, function and behavior of a product or, otherwise, address either of these concepts separately is the purpose of the next chapter.Chapter 2 Literature Overview This chapter analyzes existing literature that relates to this work. Work that founded the conceptual or methodological basis of our approach is presented in Section 2.2 that studies product function and Section 2.3 that relates function to shape. Later sections study prior work that addressed problems of interest to our research. Section 2.4 visits works that aimed at the extraction of functional information out of geometric data, showing the important role that components interactions play whenever functionality is sought at the assembly scale. Section 2.5 then studies efforts to define components interactions geometrically. The problem of knowledge representation and its importance to the DMU is addressed in Section 2.6, and works that tackled this problem from different angles are reviewed. Finally, Section 2.7 examines works dedicated to the transformation of CAD models to FEA-friendly simulation models, emphasizing the importance of functional knowledge at this stage. In the aforementioned sections, we also show why already established work failed to provide satisfactory answers to some of the difficulties observed in the previous chapter and hence, why they motivate our work. 2.1 Introduction As mentioned in the introduction of this document, the upcoming chapters will concentrate on formulating the problematic that motivates this work (see Chapter 3), before relevant concepts are defined (see Chapter 4) and the proposed method is detailed (see Chapters 5, 6 and 7). However, and before proceeding likewise, a review of what state of the art offers is imperative. The objectives of such a literature review are twofold: • The major objective of the proposed approach focuses on enriching assembly models with functionally related information, as Chapter 1 has36 Chapter 2. Literature Overview shown that the content of a DMU ends up as a simple geometric model without functional information. It is therefore mandatory to review concepts such as product and/or component functionality and how these concepts can be related to geometry, i.e., product and/or component shape. To this end, design process studies and corresponding design methods that advocate the function–behavior–form relationships, a central paradigm to this research, need to be analyzed to evaluate how a geometric model of an assembly can be related to its functional information. One of the outcome of this analysis shows the prominence of geometric interfaces between components; • Works that associate component geometry with functionally related information such as feature-based approaches, detection of geometric interfaces between components and knowledge-based approaches are also studied since they are part of prior approaches that proposed concepts related to function. Because a particular focus is placed on the use of functional information in the context of FEA, some key approaches that relate to FEA of assemblies and geometric interactions between components are also reviewed to better highlight the challenges in this area. Not only the common denominators with such works are put forward, but also differences that distinguished the approach proposed in this document and made it worthwhile. To the author’s knowledge, none of the existing works addressed and effi- ciently solved the tackled problem of functional enrichment of DMUs for FEA purposes. Such a literature survey prepares the ground for the discussion to come in the successive chapters, and situates them with respect to existing works. Section 2.2 starts this review by showing how functionality is seen from different angles in the domain of mechanical engineering. 2.2 Function formalization Although the concept of function may initially seem self-explanatory, literature has different points of view regarding its definition. Deng et al. provide an overview of different perspectives [62]. Three distinguished standpoints can be identified, from which a function is seen: as a raison d’ˆetre. A function is defined by many scholars from a teleological point of view as the ultimate purpose of a product [60, 29, 46, 84, 136, 163, 172, 178]. An interesting definition to our approach is that of Gero [72] as he defines function to be the semantics of design.Function formalization 37 as a black box. Others considered function as the relationship between the input and the output of a system [105, 129]. as a verbal phrase. Function has also been regarded form a performance perspective as it defines the behavior of a product [174, 172, 77, 85, 167, 162]. Literature suggests modeling functions as verb-object pairs [129, 86], such as ‘reduce speed’ or ‘transfer torque’. Many scholars, however, saw functionality from a midpoint perspective between two or more of the above-mentioned ones. Pahl & Beitz [129] formalized functionality as a verb-object pair, in which the verb expresses the function, while the object represents the flow of material, energy, or signal between the input and the output of a system. Likewise, Qian & Gero [136] describe a function as the purpose of design, while emphasizing its strong ties with behavior. The above-mentioned works viewed functionality independently from any product state. Without going into the details of the meaning of a product state, it can be observed that a state can be related to the input and output of a product. Indeed, a state can be characterized by a set I of physical input parameters and another set O of physical output parameters by the product. I and O are subsets of the whole set of input and output parameters, respectively, that are used to describe all the possible configurations the product can reach during its conventional usage. As pointed out above, input and output parameters of a product are means to define functions through the couples of input, output parameters that a function binds. It is clearly the case when authors consider a function as a ‘black box’, which is a casual standpoint, but also when authors concentrate on a behavior since its purpose is to take parameters as input and modify them to produce output parameters, which clearly underlines the concept of state. When modeling functions through verb-object pairs, the verb expresses also an action, which refers also to the concept of behavior. Therefore, a state can be seen as a collection of functions that pertain to the sets I and O of physical parameters attached to a product. Therefore, the two concepts are closely related to each other, as the products deliver different functions at different states. For instance an operational bike delivers the functionality of transportation, while a dismantled one has a better mobility which makes it easier for shipment. A broken bike, however, delivers no particular function at all. If states and functions are related to each other, it can be observed also that the proposed definitions of a function do not refer explicitly to the shapes of the product or some of its components. In this work function is considered to be the major motivation behind product design, with strong connection to the product state as part of its38 Chapter 2. Literature Overview design. Now that the concept of functionality is well-situated with respect to different literature viewpoints, the next section will develop on how to link this concept to product and component forms. To this end, as the upcoming section will reveal, it is essential to address the behavior of a functional entity. 2.3 Connections between form, behavior, and function The link between form, behavior, and function appeared early, and has been discussed exhaustively, in the literature of engineering. De Kleer [60] intuitively defined function as what a device is for, behavior as what a device does, and structure as what a device is. When applied to mechanical engineering, and from a design point of view, structure, under this understanding, maps to form. In an effort to formalize the relationship between function, behavior and structure, Umeda et al. [174] established the Function-Behavior-Structure (FBS) diagram, with a strong emphasis on a behavioral understanding of functionality. Structure from the authors’ perspective denotes physical attributes of an object. This can be seen as a generalization of object form. 2.3.1 Behavior to complete the design puzzle Design is seen by scholars as a goal-oriented activity that aims at satisfying certain requirement expressing a desired functionality. To this end, the link between function and form, particularly in the domain of mechanical engineering, is to be established. However, no direct mechanism allows for that matching. Gero [72] shows how function can be formulated into an expected behavior, and how form can be analyzed to produce its structural behavior. This reduces the design activity to the process of matching expected and structural behaviors, either through the evaluation of existing forms or the synthesis of new ones. Qian et al. [136] outline the casual relationship between structure and behavior and between behavior and function that allows a product to meet its expectations. This relationship is shown to be bidirectional, as function can be analyzed to infer potentially-multiples behaviors that lead to its satisfaction, then potentially-multiple structures can also be inferred in what is referred to as goal achievement paths. 2.3.2 Pairs of interacting interfaces In Albers et al. [23], the authors do not only emphasize the connection between product geometry and functional attributes, they also demonstrateConnections between form, behavior, and function 39 Hollow wheel Planet gear(s) Sun gear Planet carrier C&CM Conceptual geometry Physical geometry Figure 2.1: An example of a planetary gear modeled using C&CM [23], showing interfaces between components of the corresponding assembly. with concrete examples the correlation between pairs of interfacing geometrical entities, i.e., pairs of surfaces belonging to different components, and the expected purpose of a product. The corresponding design methodology shows, through industrial case studies, how a function is tightly coupled with the geometric properties of interfaces between neighboring components that provide the desired, or even undesired, behavior. Figure 2.1 shows an assembly model using Contact and Channel Model (C&CM) introduced by Albers & Matthiesen in [24]. The example puts forward the important role interfaces between components play in a product assembly to achieve the desired function. 2.3.3 Tools and guidelines to support the design process The aforementioned approaches have been applied to or are part of design methodologies to provide engineers with tools to facilitate the creative activity of design. As an example, the work of [22] builds upon the C&CM to develop a modeling approach as a tool to assist the design process. Authors in [147] present a theoretical framework that builds upon formfunction mapping to provide guidance to engineers along the design process, in an effort to automate, or semi-automate, the transition from user requirements into a functional artifact. In the latter work, authors address the relationships between function, behavior and geometry from a top-down1 1By top-down, we refer to the path from functional specification, to design attributes, particularly, components shapes.40 Chapter 2. Literature Overview Input (i) Function (F) Output (o) Energy Motion Support etc. Energy Motion Support etc. Input (i) Function (F) Output (o) Energy Motion Support etc. Energy Motion Support etc. Behaviour (Functional Relationships) Geometry Physical Laws (a) Traditional model (b) Part Function Model Figure 2.2: A comparison between a traditional conceptual model of part function (a), and PFM introduced by Roy & Bharadwaj [146] (b). perspective, as a goal achievement guide to obtain parts geometry from functional specifications. Roy & Bharadwaj [146] set up a design approach to connect functions to 3D geometry using a Part Function Model (PFM) illustrated and compared with traditional models in Figure 2.2. To acquire the proposed model, a designer should provide a behavioral description of parts using a predefined vocabulary. Along with geometrical properties of parts contacts, this description is used to infer functional interactions between components. The PFM obtained involves functional information down to the level of boundary faces since the behavior model builds upon interfaces between parts, i.e., contact surfaces. This work emphasizes the discontinuity between spacial properties of parts in an assembly model and their function, and advocates the importance of a behavioral description to connect function and shape concepts. It, however, requires the user to manually provide such a description before making any judgment about a part functionality. At the level of complex assemblies with hundreds to thousands of parts, the amount of complementary data defining a behavioral model becomes too tedious to add. Kim et al. [103] provide a formalism that augments a DMU with the design intent of an assembly, particularly the semantics of contacts between assembly components. This is achieved through the Assembly Relation Model (ARM) and an XML-based meta-model that refers to geometric entities in the DMU. Using this formalism, assembly models are annotated by collaborating designers, based on spacial relationship analysis undertook by a geometric kernel. Interactions between components are referred to as joints in the context of assembly design. The nature of interacting form features between components, then called mating feature, is captured in the Generic Assembly Relationship Diagram (GARD) as part of the ARM, in a graph-like manner. Joints in GARD are reduced to global parameters of welded, glued, bolted and riveted connections that define components position with respect to each other. This work is meant to facilitate collaborativeConnections between form, behavior, and function 41 assembly design and enriches a DMU with information relative to this task. However, simulation objectives may require a detailed representation of interfaces functional interactions beyond mere assembly joints. Especially when the purpose is to assess the stress field distribution in a bolted connection with tens or hundreds of bolts. Additionally, one can observe that the relationship between shape and function strongly relates to interfaces between components and, more precisely to contact surfaces, i.e., the real component relative position. Somehow, this relationship is not robustly expressed in a DMU, due to the designer’s choices made about component shapes (see Section 1.5.1 and Section 1.7). Indeed, component shapes are often simplified in a DMU, which can alter the representation of physical contacts between components. As a result of the analysis of prior work, none of them has taken into account this discrepancy, which can be regarded as a fact creating inconsistencies between functional prescriptions of a designer and the content of a DMU. Works examined so far share a common denominator where assemblies are described as geometric models enriched with technological annotations that may qualify as functional information reflecting design rationale [107]. They participate to the enrichment of a DMU as a central repository of PDP activities (see Section 1.7). While each of the unfolded efforts has seen the DMU from a particular standpoint, none of them satisfactorily considered the requirements of a seamless generation of simulation models. Observations showed that the closer the enrichment is to any functional significance, the higher the lack of information external to CAD environments and the greater the need of user interactive input during a design process. As a common observation of all prior works reviewed in this section, they are all heavily dependent upon designer’s input data, i.e., the consistency of functional information. Its relationship with 3D geometric models of components or assemblies are left under the designer control. This is not tractable for large assemblies and hard to set up even for simple products with dozens of components. Although proved bidirectional [136], the function-form relationship is studied from a purpose-oriented viewpoint by the so-far analyzed works, i.e., along the path from intended function to a designed form, oftentimes through physical behavior as a connector. This understanding of the relationship remains dominant in the literature. The following section, however, shows work that made use of the bilateral nature of this relationship, exploiting the causal direction, from form to function, to develop some confidence about product functional properties.42 Chapter 2. Literature Overview 2.4 Constructive approaches to deduce function In this section we walk through some of the existing work that aims at the association of functional properties to different elements of a DMU. The previous section has already highlighted that shape simplifications of components restrict the applicability of approaches strictly based on geometric contacts between components, which is the common feature of prior work. 2.4.1 Form feature recognition Efforts have been paid in the field of Feature Recognition (FR) in solid models as early as 1988 [94]. Zhu & Menq define features, also referred to as form features or machining features, to be ‘the representations of shape aspects of a physical product that can be mapped to generic shapes in a given context and are functionally significant’ [185]. This definition establishes links between form features and functionality, and makes it of a particular interest to our research to shed some light on FR-related studies. Examples of manufacturing features include holes, slots, pockets, and other shapes that can be obtained by material removal operations using Computer Numeric Control (CNC) machining systems [81]. In many occasions, literature shed the light on the gap between the low-level geometric information usually present in CAD models, and the higher level functional semantics needed by CAM systems. Authors in [121] promote features as the link between pure geometry and design semantics, allowing a smooth transaction from CAD to CAM activities. Literature also surveyed a wide range of techniques that participate to the Computer Aided Process Planning (CAPP) automation as a link between CAD and CAM, where FR plays a major role as a communication agent [153, 152, 166]. Authors in [25] address the problem of functional features extraction out of digital models. They classify existing solutions into human assisted approaches, feature-based modeling, and automatic feature recognition and extraction. Han et al. [81] in their turn regroup automated FR algorithms into graph-based techniques, space decomposition approaches, and rule-based geometric reasoning. Falcidieno & Giannini [66] suggest a three-stage solution: recognition, extraction, and organization of features. The proposed system builds a hierarchical structure of a part shape in accordance with level of details. The recognition phase builds on the work of Kyprianou [106] that paved the road of graph-based FR. A graph representation of the geometric model of an object is generated in [94], before graph matching techniques are applied to extract form features, also represented as graphs. Ames in [26] advocates an expert system approach to recognize application-specific features given the product solid model as an input.Constructive approaches to deduce function 43 In Date et al. [58], FR is integrated into the process of simplification as a preliminary step to prepare a meshed model for FE analysis. A technique to detect and remove blending features is presented in [185]. Even though fillet and round are secondary features as they are of little functional significance (they don’t actually conform to Zhu & Menq’s definition) their presence may interfere with the detection process of their parent features. Authors, thus, present their work as a preliminary treatment of the geometric model to enhance the recognition of more significant functional features. Another approach, capable of handling more interacting shape features through an iterative method is presented in [175]. In this work form feature recognition techniques are used to detect features face-sets, and then a feature is removed before passing to the next iteration, where previously interfering features can be detected. In Sunil et al. [164], authors again tackle the problem of features interaction through a hybrid approach for FR that is both graph- and rule-based. A more exhaustive categorization of efforts paid in the area of FR is given by Shah et al. [154]. However, fruitful studied categories did not diverge much from earlier classifications [66, 25, 81]. As a complement, Shah et al. in [154], address recent work that considered the otherwise overlooked free-form features [158, 182, 159]. Sridharan & Shah [159] provide a feature classification method to aid the detection of complex CNC milling features. Figure 2.3 shows an overview of the proposed taxonomy. The preliminary recognition of features uses a rulebased approach independently of any geometric restriction, thus, allowing for the identification of features involving free-form surfaces. At this stage, features are categorized according to the first level of the taxonomy presented in Figure 2.3. A finer classification of recognized features then takes place, to predict feature type more precisely, this time taking into account geometric properties such as surfaces types (cylindric, ruled, free-form, etc.). This corresponds to the categorization of features in the second level of the taxonomy presented in Figure 2.3. Automatic FR techniques aim at the extraction of functional information as design intentions given the pure geometric model, thus contributing to the enrichment of a DMU. They are, however, still limited to a very small set of simple geometric configurations like holes, pockets, slots, rounds and fillets. Most of prior work fits into a bottom-up2 approach where features are extracted from low level geometric entities and a detached volume model is processed as a standalone entity. Whenever product models are referred, they are generally regarded as a collection of components processed with loose or no connections at all between them. 2In contrast to top-down scheme, bottom-up is used to refer to the path from existing design information, such as objects shapes, to a more elaborate knowledge, such as functionality.44 Chapter 2. Literature Overview Figure 2.3: CNC machining feature taxonomy according to [159]. Another common observation regarding features is their sensitivity to interactions with other features. It means that FR processes can be easily perturbed when a feature is not precisely matching its definition or, alternatively, a feature definition is often simplified to avoid referring to the very wide diversity of geometric configurations that occur when a given feature interact with many others. It has also to be observed that feature definitions are not available in DMUs (see Section 1.7) partly because of the previous observation and partly due to the fact that features follow definitions targeting very specific applications, which justifies their absence in a DMU since it is regarded as a common repository to feed a large range of product development tasks. As a complement, FR approaches as well as feature modeling ones process strictly standalone components whereas Section 2.3.1 has shown that functional information requires the geometric interaction between components to be precisely characterized. Therefore, functional features must be addressed at the assembly level, which is the purpose works visited in the following section. 2.4.2 Functionality as a result of geometric interactions The strong ties between geometry and functional semantics are again brought forward by [125] where authors analyze causal kinematic chains of a product based on component-to-component kinematic links deduced from their geometric interfaces. Authors made simple assumptions about the assembly to semi-automatically infer motion functions: • Parts having rotational and translational (partial) symmetry properties enable rotational and translational motion respectively, along theirConstructive approaches to deduce function 45 (a) Analyzed assembly parts (b) Interaction graph Figure 2.4: Mitra et al. [125]. Parts of an assembly with automatically detected axes of rotation or symmetry (a), and the corresponding interaction graph (b). Graph edges encode the types of joints. symmetry axis and direction respectively; • Levers, belts, and chains have few geometric characteristics that enables to identify them automatically: their 1D structure can be analyzed with principal components analysis to infer curvilinear and periodic motion properties; • Kinematic functions as gears are set manually by the user. An interaction graph illustrated in Figure 2.4, and representing contacts between product components and their contact characteristic is used to draw conclusions. Alongside the reasoning process, reduced user input is solicited interactively. Although the work acknowledges exploring components interactions as a great indicator to functional and technical properties of the product, the proposed semi-automatic approach builds on an already meshed model rather than a CAD model, limiting its use to demonstrative kinematic simulations as authors suggest. It should also be noted that the purpose in the abovementioned work is component animation rather than an effective enrichment of an assembly with functional information. Dixon & Shah [63] provide an expert system for FR that is both graphand rule-based. Unlike work presented in Section 2.4.1, emphasis here is put on assembly feature recognition, as opposed to part feature recognition. Authors define an assembly feature as ‘an association between two part features that are on different parts’. The proposed system involves a learningby-example phase in which a user defines assembly features from existing assembly models. The user interactively provides rules that tie together geometric and algebraic parameters of the defined feature. The user-defined46 Chapter 2. Literature Overview patterns are then used to extract features from an unseen assembly model where assembly features are to be found. The suggested work uses twist and wrench matrices [181] to define structural and kinematic properties of assembly features. The work is devoted for application such as reverse engineering and reengineering of legacy spare parts. Although some of the techniques used inspired our simulation-aware approach, no particular attention has been paid to FE application in authors’ work. The developed system accepts assemblies as B-Rep models. However, it does not account for shape simplifications encountered in industrial DMUs (see Section 1.5.1 and Section 1.7). This is a direct implication of the fact that the system only considers contact interaction between parts to generate assembly features. Nonetheless, observation shows that functional interfacing can also be represented, in a simplified manner, as volume intersection, or interference. Finally, this learning-based approach does not refer to the behavior concept of an assembly or sub-assembly, which could improve the robustness of this feature-recognition approach and would conform to the well-established dependency between form-behavior-function (see Section 2.3). Literature studied in this section proved that if any functional information is to be learned, this inquiry should start at the components interaction level. To establish the link between shape and function in the light of the above-mentioned observations, the input geometric model should first be analyzed for candidate geometric interactions. The following section looks at what existing work offers in this regard. 2.5 Geometric analysis to detect interactions Section 2.3 showed the tight link between shape and function. Function, however, is an interactive phenomenon, satisfied by the inevitable interaction of components in a mechanical system [24, 103]. This means that only shapes in interaction produce functionality. If any functional significance is to be deduced from shapes, geometric interactions are to be addressed first to locate their areas, which can influence their function. In this section, we provide an overview of efforts paid in an attempt to analyze assembly models to look for geometric information that is relevant to our research. 2.5.1 Geometric interaction detection Geometric interaction detection often drew the attention of researches from different domains, particularly robotics and computer graphics because of its application to collision detection [101, 39, 44, 139]. Lin & Canny [113] provided an efficient technique to determine closest points between two given 3D objects. The algorithm can make use of anGeometric analysis to detect interactions 47 approximate initialization, when available, to converge faster to an accurate solution. This gives it an advantage when considering dynamic environments such as motion planning and robotics, where closest points between pair of objects can be computed adaptively with respect to time [44]. The local convergence nature of this algorithm, however, makes it limited to convex object shapes. To account for non-convex objects, Quinlan [138] suggested the division of the object into sub-components, which in turn are convex themselves. The problem of finding the closest points, thus the minimal distance, between two non-convex objects reduces to finding closest points between their subcomponents, then considering the pair with minimum distance. To reduce the quadratic complexity inherent to this approach, the author suggests using cheap bounding spheres checks to reduce the number of compared components. Works from Agrawala et al. [20] and Mitra et al. [125] have built on minimal distance detection to efficiently determine geometric interactions in an assembly, such as contacts and clearances. However, all of the abovementioned works considered a discrete geometric model of type polyhedral, a representation that is not commonly used in industrial DMUs (see Section 1.5) and not robust enough to correctly detect unambiguous interactions between components in complex assemblies. This is exemplified in commercial CAD software like CATIA V5, where interaction detection is simply displayed and left to user’s interpretation but cannot be used for further assembly geometry processing. This inconvenience was addressed, and tackled in the work of Iacob et al. [89], where a contact detection algorithm is provided based on analytical Non-Uniform Rational B-Spline (NURBS) surfaces. Detected contacts between components in a DMU are then used for assembly/disassembly planing, and in VR application. Due to its particular application, this method paid no effort to detect interaction zones. Such a geometric knowledge, however, is a key element for processing DMU for FEA purposes. The recent work of Jourdes et al. [95], in the framework of ROMMA project [1], solves the problem of the detection of precise contact zones in a highly efficient manner, making use of discretized techniques that exploit the Graphics Processing Unit (GPU) computational power. Despite its use of internal discrete models to communicate with the GPU, the proposed algorithm still inputs, and efficiently produces, analytical NURBS surfaces. This work, however, did not address interference zones detection. 2.5.2 Importance of a unique geometric representation In the domain of shape recognition, certain criteria have been identified to ensure relevant comparisons between shape descriptions. One property of shape synthesis methods has been outlined that allow shape search and 3D48 Chapter 2. Literature Overview pattern detection. This is representation uniqueness [122, 126, 90]. Uniqueness implies a one-to-one relationship between a shape and its descriptor using a given representation [90]. This means that using an appropriate representation, an object can be geometrically described in only one way. Two different descriptions mean that the underling objects are geometrically distinct. Uniqueness in this sense also implies invariance [126], that is if two object have the same shape, they must have the same geometric description under their descriptor. Uniqueness is a mandatory property to enable the judgment of whether or not two descriptors represent the same shape. Work as early as [122] shed light on this requirement when retrieval of relevant information out of a geometric model is considered. Commercial CAD systems, however, do not account for shape uniqueness. In fact, a given object, such as a simple cylinder, may be represented through different ways and different number of faces and edges even when using the same geometric modeler, as Section 5.2.2 shows. In order to enable a robust geometric interaction analysis, this inconvenience is to be addressed first, which is the topic of Section 5.2.2. Today’s industries regard the DMU as the product knowledge repository. They expect it to tie the product geometric model with related information, such as functionality, in a formally structured manner. Works in this direction join our endeavor to enrich the dmu. with functional knowledge. Similar efforts are thus summarized in the upcoming section. 2.6 CAD and knowledge representation CAD systems are meant to provide a PDP with tools that spare the designers the burden of repetitive tasks, allowing them to concentrate on creativity and core expertise. They are the evolution of drafting tools, that use evergrowing computing capacities and interactive techniques. Design activities are becoming more and more knowledge-greedy. The availability of relevant information is taking a major part in an efficient PDP. Designers reportedly spend up to 60% of their production time searching for the right information [108]. Ullman [171] argues that knowledge reuse is involved in more than 75% of design activities. CAD systems are, thus, more and more required to equip designers with needed engineering knowledge. However, observations show that this knowledge is still scattered around the DMU in a non-structured manner. Most of this knowledge comes in a free text format (see Section 1.7), which is neither reliable nor robust. Section 2.6.2 studies research that tackled this problem by means of general knowledge management tools applying paradigms of the Semantic Web. Section 2.6.3 looks through prior work that utilized an approachCAD and knowledge representation 49 more specific to engineering knowledge. We first make a distinction between knowledge at the domain of discourse level, and knowledge at the current instance level in Section 2.6.1. 2.6.1 Domain knowledge and model knowledge In fact, shortly after CAD systems were introduced and commercialized they were suggested to provide active feedback to the designer, to enhance the engineering process with decision support systems, embedded in their working environment. Those systems made use of engineering knowledge about both the domain and the particular product under development. In the context of a PDP, we identify knowledge about the underlying domain, such as aerospace and automotive industries, or software development, which we refer to as domain knowledge. Another type of knowledge that can be distinguished is the knowledge about a particular product or instance of this product, e.g., car engine, aircraft, or piece of software. We refer to such knowledge as model knowledge. This distinction is purely pragmatic since it allows domain knowledge to represent global expertise independently from any information about a particular case. Model knowledge, however, only makes sense in the context of domain knowledge. 2.6.2 Ontologies as an assembly knowledge storehouse The concept of ontologies as it applies to computer science is closely related to the Semantic Web [35]. The Semantic Web is seen by World Wide Web Consortium (W3C) as the Web of data, as compared to the Web of documents that we know. It enable machines to interact and connect to each other in the same way human beings do through the Web. To this end, a common machine interpretable language, or vocabulary, should exist. Ontologies are the Semantic Web vocabulary [5]. At their simplest understanding, they define concepts and relationships between them in a machine understandable language. Because of their established formalism and their ability to intuitively model the facts we know about a given domain of discourse, ontologies are widely used as knowledge repositories. For a particular domain, knowledge is represented as a set of objects, referred to as individuals, that are grouped in classes that are called concepts. Classes are organized in a hierarchical manner to reflect the generalization relationships between sets of objects. Individuals are connected with relationships that are called roles in the context of ontologies. Individuals, concepts and roles are identified by means of agreed-upon human readable vocabularies. Gruber [76] describes an ontolgy as a commitment to these vocabularies between participants to an Artificial Intelligence (AI) system. Knowledge captured by an ontology is classified in two categories:50 Chapter 2. Literature Overview 1. The terminological box, or TBox, where general concepts and rules are expressed. This typically maps to the domain knowledge; 2. The assertional box, or ABox, where information about instances and their relationships are maintained. The ABox typically maps to the model knowledge. It is important to note that while ontologies formally define the common language necessary for knowledge sharing, they leave the choice open for how this language is represented and communicated. Gruber [76] distinguishes three needs to allow knowledge sharing: • A common representation language format; • A common agent communication protocol; • And a common specification of the content of shared knowledge. An ontology fulfills the last requirement, while the first two items are considered to be implementation details rather than conceptualization problems. The use of an ontology in the Semantic Web compares to the use of a given language, e.g., English, French, or Arabic, in the Web where vocabulary and their semantics are well defined and understood by people speaking the language. A variety of solutions already exist to represent ontologies in a common format. Names include Resource Description Framework Scheme (RDF-S), Ontology Interchange Language (OIL) and Web Ontology Language (OWL) family [14] including variants like OWL Lite, OWL DL and OWL Full. This compares to the use of HTML in the Web to represent documents. Protocols do also exist to allow exchange of facts and queries using ontologies, examples are SPARQL Protocol and RDF Query Language (SPARQL), DL Implementation Group (DIG) [15] and Simple Semantic Web Architecture and Protocol (SSWAP). This compares to the use of HTTP to communicate requests and responses on the Web. Ontologies are often used in different engineering disciplines to capture knowledge. Liang & Paredis [112] provide a port ontology as an unambiguous semantic structure that combines form, function and behavior as design information characterizing subsystems interactions in a given mechatronic product. This ontology, however, makes no connection between these three design aspects. In Rahmani & Thompson [142], the authors build upon the previous work and show how to represent functional interfaces between product subsystems in machine-interpretable manner using a three-layered ontology (two layers for domain knowledge and one layer of model knowledge). They also provide necessary means to verify functional compatibility between system components through their functional interfaces, therebyCAD and knowledge representation 51 called ports. In fact, this work is general and applies to different disciplines beside mechanical engineering. These two works join and extend a heritage of literature in an effort to aid the design process in providing relevant information in a globally understood basis. Kitamura & Mizoguchi [104] suggest a semantic framework to enable conceptual engineering knowledge sharing about functionality. This framework is implemented in terms of layered ontologies where concepts of each layer builds upon those of the layer above. To guarantee the generality and wide coverage of their approach, the authors emphasize the distinction between what a function is and the way it is achieved. This is reflected in a distinctive conceptualization in two separate layers; functional concept ontology and functional way knowledge, respectively. For example, ‘welding’ is more than a function, under the proposed framework, as it implies ‘fusion’ as a way of satisfying the function ‘unification’. This function, however, can be satisfied by other means such as ‘fastening’. Authors promote their ontological framework as an agreement about a common vocabulary to allow designers and engineers to share knowledge. In the continuity of their work [103] presented in Section 2.3.3, Kim et al. [102] developed the AsD ontology to capture design intentions in a heterogeneous collaborative assembly design environment. Authors do not only use advances in the domain of knowledge representation to formally represent ARM presented in [103] using ontologies, they also use inferences to obtain new facts that are not implicitly available in the initial model. Inferred facts, however, dwelt in the domain of consistency checks, joins types, and relative DoF. Figure 2.5 shows an overall structure of the proposed system and its connections to other modules to deliver assistance to engineers during the assembly design process. This figure shows how an inference engine is used to extract implicit knowledge, then assistance is provided mainly through querying, using a semantic search engine. All the previously cited approaches share a common perspective since they address the design assistance in a top-down manner where functional information has to be related to 3D component models or to their interfaces by an engineer. Consequently, this information may be incomplete if an engineer fails to perform some connections during the design process. Few authors have taken advantage of inference mechanisms to automate the connections or check the consistency of the overall design data. Indeed, setting up connections between component geometry and functional informations raises the question of the meaning of this connection. It is essentially a logical connection between data, e.g., functional ones, and an instance of 3D component and it is not clear whether this connection should target a subset of the component and what should be the appropriate geometric entities. If a designer had to query this functional model to highlight a geometric area over the boundaries of components, these approaches cannot process such52 Chapter 2. Literature Overview Figure 2.5: Assembly design information sharing framework as proposed by Kim et al. [102]. query, showing that the proposed connections are not adequate to process 3D components for FEA preparation. Combining this observation with the topdown feature of these approaches we infer that processing a DMU containing essentially geometric models of components (see Section 1.6 and Section 1.7) in a bottom-up manner, cannot be automated with these approaches because the connections between geometric and functional informations are missing. Barbau et al. [32] cover a large spectrum of product description with an ontology, referred to as OntoSTEP, incorporating both geometry and structure of a DMU as available through STEP APs [8, 12], the Core Product Model (CPM) introduced in [67] and the Open Assembly Model (OAM) introduced in [34]. A tool was developed to translate an EXPRESS scheme [13], the scheme that governs STEP files syntax, into an OWL DL ontology, defining its TBox. A STEP file can then be imported into the same ontology, using the same tool, to define an ABox. The tool was implemented in terms of a plug-in to the ontology editor Prot´eg´e [3]. Authors thus define a mapping between EXPRESS primitives (entities, instances and attributes) and those of OWL (classes, individuals and properties, respectively) to enable the import of a TBox. They also implement a syntacticCAD and knowledge representation 53 analyzer that parses the STEP file to create the corresponding ABox of a given model. The work aims at establishing a semantic layer on top of an EXPRESS description. Aligning these semantics with functions and design intents expressed in models such as CPM and OAM allows reasoning and extraction of implicit knowledge. The authors use Description Logic (DL) reasoner Pellet [156]. In spite of a relative success, authors showed that not all EXPRESS language constructs can be expressed using OWL DL. Examples are functions, entity constraints and attribute calculations that may require complex algorithms beyond the expressiveness of DL, the logic upon which OWL DL is built. Authors conclude that not all aspects of STEP can be rigorously reflected through ontologies alone, leading to limitations on reasoning power. These approaches are meant to accompany the design process, and to lend it the necessary tools for modeling and verification, including means to represent knowledge about system components interactions as major actors to such a process. Some of the work analyzed provided means to extract technical or functional implied intention from an existing model through inferences. This information, however, did not go further than interface-wise descriptions of assembly links and kinematic connections. Inferences are also used to align geometric models to functional ones. However, the latter were explicitly provided and reasoners were rarely used to merge knowledge stemming from different models. Even as knowledge capturers, proposed ontologies fail short to encapsulate functional knowledge thoroughly enough to the point that satisfies FEA requirements (see Section 1.9) with precise geometric information about interfaces between components as well as functional information about these areas. 2.6.3 Knowledge-based engineering approaches Engineering knowledge is spread out in different places and forms along a PDP. This includes experts’ minds, worksheets, CAD models, company codes, databases, flowcharts, implicit and explicit conventions and rules of thumb, etc. Knowledge Based Engineering (KBE) aims at gathering all such knowledge in one place, and make it accessible to actors of the PDP at any stage. KBE can be seen as a specific type of experts system as applied to engineering field. They combine geometric modeling, configuration management, and knowledge management into one rule-based system [115]. Domain knowledge is collected and stored into a knowledge management module, then rules derived from this knowledge are applied to CAD models in a parametric-modeling-like manner. This knowledge also governs other engineering and manufacturing aspects rather than geometry through the configuration management module. In this sense, KBE extends traditional CAD systems. DMUs are enriched54 Chapter 2. Literature Overview with information that is persistent, relevant, meaningful, and reusable. This knowledge is then analyzed and used to provide the designer with decision making tools and advisory modules. This is meant to save development time, and allow a designer to focus on innovative aspects rather than mundane tasks. The way knowledge is organized in a KBE system enables also the reusability of pre-existing components or sub-systems, remarkably reducing the cost of products modifications or upgrade. This is particularly useful in industries where the design activity is of an adaptive nature; that is products are rarely redesigned from scratch, but models are often adapted to emerging needs. In this case, KBE aims at capturing the design intent in the model itself, allowing for easier modification and avoiding reverse engineering efforts to guess what engineers had in mind when the model was first created [37]. KBE has its roots back in the late 80s [37, 176]. Many successful applications reaped its fruits in the beginning of the century. Chapman & Pinfold [48] show one application in the domain of automotive industry, applying a standard KBE system in a highly dynamic design environment. In the aerospace industry, La Rocca & van Tooren [145] tell a success story fitting KBE to multi-disciplinary design to enable automatic generation of FE analysis models. Emberey et al. show another application of KBE in the domain of aeronautics [65]. Considering KBE early high potentials, it seems that this approach didn’t yet meet its expectations, despite numerous success stories. This led people to rethink the utility of such investment. Others tried to criticize KBE, studying both failure and success case-studies, and drawing conclusions about where did the applications of KBE go wrong [176]. One argument about the shortcomings of KBE is the lack of explicit methodologies. Although such frameworks exist (MOKA [161], KOMPRESSA [115], KNOMAD [56] and DEE [144]), applications usually don’t commit themselves to any, and tend to be case-based. Verhagen et al. [176] note that more than 80% of KBE applications do not fit in a particular framework, nor do they follow any well-defined methodology. This poor modeling contradicts with KBE basic assumptions and leads to significant loss of knowledge. Another problem is the lack of a semantic link between identified formulae, rules and models on one side, and real-life engineering expertise and understandings on another. This reduces collected knowledge to mere data that still miss the context of application. This contextual gap appears at the level of knowledge collection, as well as knowledge representation. Knowledge representation models are still unable to capture the link between one engineering element and its scope of validity. This shortcoming strongly hinder re-usability, one of major advantages of KBE, making initial overhead of KBE systems unnecessarily costly. The lack of quantitative means to assess the ‘success’ of a KBE systemFrom CAD to FEA 55 is another major inconvenience. A KBE implementation should be compared to its traditional counterpart to truly justify the use of such initially costly approach. Although some work shows serious comparative studies to advocate KBE use [65, 55], this doesn’t apply for the majority of related work [176]. Quantitative measures are also strongly needed to assess the suitability of KBE to a particular project or application. A primary reason that made people drift away from investing in KBE is the failure of inadequate applications that were motivated by early success of such technology. In such situations, extra-cost was often not justified by the little gain, because of the nature of the application in hand [37]. Looking more precisely at the reasons that restrict the extensive use of KBE systems, the connections between technological parameters and geometric entities is similar to the connections observed in Section 2.6.2. Consequently, the connections set up are applicable to a fairly small set of configurations, i.e., when shape modifications are performed the new con- figurations are no longer compatible with the technological parameters they are connected to. This happens because these connections address geometric areas of 3D components that are not precisely reflecting the meaning of their associated technological parameters. The need of robust connections between geometric elements, down to the level of geometric interaction zones, and functional knowledge in terms of agreed-upon semantics is emphasized when considering application such as FEA. The following section walks through recent approaches in this domain. 2.7 From CAD to FEA Section 1.9 introduced the finite element method, and how it contributes to the whole PDP. In this section we analyze efforts paid to automate or semi-automate the generation of the FEM. 2.7.1 Pre-processing at the core of the FEM Haghighi & Kang [79] describe pre-processing as the most time-consuming and expertise-intensive task in the behavioral simulation process. They also argue that expertise and knowledge invested at this stage have a direct implication on the accuracy of analysis results. The error-prone and resourceintensive nature of this task often makes it the bottle-neck in the PDP. Jones et al. [92] attribute the high cost of preprocessing to the many non-trivial subtasks it involves, such as geometry processing, mesh quality control, and the assignment of physical properties to mesh elements.56 Chapter 2. Literature Overview 2.7.2 Direct geometric approaches As pointed out by Thakur et al. [166], most of prior work related to the geometric transformations applied to components to generate a FE model from a B-Rep CAD model, are purely geometric transformations, i.e., the component shape is modified using criteria of morphological type. In Makem et al. [117], a component is subjected to a segmentation process into manifold models to enable the generation of a semi-structured mesh is proposed. The hybrid mesh of structured and unstructured zones allows for efficient anisotropic structural simulations. Few contributions take into account FE sizes to modulate the geometric transformations applied [109]. Quadros et al. [137] use de-featuring techniques to reduce model complexity. They therefore generate an intermediate discrete model, keeping backward links to the original CAD model to allow information flow such as boundary condition attributes. In the present context, the focus is placed on assemblies as a representation of a DMU. There, few research works have addressed the FEA preparation of assemblies. Specific operators have been provided to compute contact zones between components. These operators fall into two categories depending on whether the geometric model used to describe the components is an analytical B-Rep model or a discretized mesh. In case of B-Rep CAD models, Clark et al. [52] have developed a specific operator to compute the imprint of a component onto another one and use the corresponding imprint to subdivide the boundary of each component so that they share a common geometric area that reflects the contact area between the components. As a result, this common area can be used to generate conformal FE meshes in this area, which greatly improves the FE mesh generation process of an assembly model. In case of meshed or faceted CAD models, several approaches have been proposed [50, 114] to compute the common areas between components representing their contact areas and to process FE meshes generated on a component basis so that their common area can be identified and their FE meshes in that region can be modified to produce a conformal mesh. Obviously, these approaches are of great interest to process assembly models for FEA. However, those referring to a faceted model are not robust since the operators are rather sensitive to discretized representation they use as input. More precisely, it becomes difficult to make a distinction between a discretized representation of two cylinders in contact with each other along a cylindrical surface and a discretized representation of two interfering cylinders as it can happen in a DMU with screws and nuts. For this reason, this approach is not suited in the present context. Regarding Clark’s approach, it has been addressed using Boolean type operators inside a specific CAD software and it is restricted to contact configurations. As a result, it is not generic compared to Jourdes’s [95] approach that uses a STEP file as input and projection-type operators that can adapt to accuracyConclusions 57 of relative position of each component. All these approaches, however, did not show any connection to the functional attributes of a geometric interaction between components, leaving an open question of how adequate those adaptations are with respect to a given simulation process under prescribed simulation objectives. In the context of the ROMMA [1] project, work has focused on assembly processing for FEA and has highlighted the need to specifically process the interfaces between components since they are directly related to the simulation objectives. Work studied in the context of CAD-to-FEA transformations showed that assembly models are rarely considered as a whole, instead, components models are processed and transferred between the two domains individually. Methods that accounted for interaction between components are also uncommon in the literature, and those who did, only considered geometric contacts as functional interaction indicators, leaving prevailing industrial conventions, such as volumetric interferences, uninterpreted. This is a natural consequence of the shortage we pointed out in Section 2.4. This shortage reflects the need for a concrete approach that translates product geometry to simulation-relevant functional properties, while taking into account mainstream industrial practices, and the integrity of an assembly model. 2.8 Conclusions In this chapter, concepts such as functionality and the relationship between function, behavior and form are considered from literature standpoint. These three concepts are inter-related, which means that adding functional information to a purely geometric model of a system should refer, somehow, to the behavior of this system. In addition to these three concepts, the concept of state, though not mentioned in the relationships between function, behavior and form, can be related to function. In later chapters, these concepts will be revisited, extended, or narrowed down to a more specific context or definition. Examining work that compares to ours, in terms of problem tackled, showed that though it is possible to recognize some basic manufacturing features by merely considering local geometric properties of components, the detection of more complicated functional properties, such as these required for simulation preprocessing, requires that the geometric model be regarded from a wider angle, that also covers the interaction between different components. In addition, the feature recognition approaches essentially concentrate on standalone components which prevent them from addressing functional issues since their interfaces with other components are not taken into account. Knowledge repositories and reasoning methods used in the context of a DMU are also examined, to determine that, although ontologies showed58 Chapter 2. Literature Overview Non-conformal mesh (a) Contact imprint mesh (b) Conformal mesh (c) Figure 2.6: A demonstration of the work of Clark et al. [52]. (a) A nonconformal mesh of an assembly of two components. (b) Components imprint onto the each other represents the contact zone, a shared mesh is generated at this region. (c) A conformal mesh of the same assembly, where the mesh of the rest of each volume is generated after the mesh of the shared surface (the imprint).Conclusions 59 promising abilities to faithfully represent engineering knowledge, and to reason upon it to a certain extent, they are still inadequate for the type of reasoning that requires heavy calculations or complex algorithms, as it is the case in 3D geometry processing. This is a strong requirement to be able to process complex industrial assemblies. In spite of its potentials, little efforts have been paid to exploit the Semantic Web reasoning capabilities to extract new functional knowledge from merely geometric one to the level where the former can be used in the preparation of a model for FEA purposes. Alternatively, the use of engineering-specific approaches such as KBE enables flexible adaption to reasoning needs. However, such approaches still miss the semantic connection to design rationale, and come at a yet unjustified high cost with a very limited capability to adapt to product variants and even more to an acceptable range of products. At the origin of this limitation stands the structure of the geometric model supporting the KBE application and how it is connected to knowledge representation. Attempts to automate the preprocessing of a FEA showed that only few works made the necessary connection to the functional properties of components and their interfaces. These approaches are still needed for automated function enrichment of DMUs and must produce an accurate geometric representation of the interface areas between components to be useful for FEA preparation.Chapter 3 From Geometry to Functional Semantics: Needs and Objectives This chapter sets the objectives of our work, shedding the light on the prominence of functional knowledge, and on the importance of its inference at different levels of the DMU structure, while minimizing user’s interactions. We also show the applications and implications such an inference have on the acceleration and enhancement of a PDP, particularly in the context of FEA preparation. This chapter is organized as follows: Section 3.1 presents the need for automatic and intelligent preparation tools to adapt DMU data to FE simulations, Section 3.2 shows that geometric assumptions are made about the DMU, reflecting a variety of industrial conventions. These conventions are to be taken into account if the shape of a DMU is to be interpreted for FE simulation applications. In Section 3.3, efficient methods for timely preparations of simulation models are shown to require an enrichment of the DMU content to incorporate critical functional knowledge, while preserving connections between functional and geometric entities. Section 3.4 enumerate three different levels at which this functional enrichment of a DMU content must take place, namely, the component interface level, the component level, and the group of components level. 3.1 Taking 3D models beyond manufacturing purposes With the development of 3D modeling techniques, industrial blueprints, their 2D counterparts, have become less prevalent across the production62 Chapter 3. Functional Semantics: Needs and Objectives process. This technical leap enabled the utilization of a reference model, now referred to as a DMU, at different stages of a PDP, especially as an entry point to simulation processes (see Section 1.4.2). However, this advent also came at a cost: technological and functional information are scattered around the DMU in a disorganized manner (see Section 1.7), the abstraction of assembly geometry stopped being standardized (see Section 1.5.1) and thus, became unreliable, unlike the way it used to be with 2D technical drawings. This technological and functional knowledge remains a core requirement for the use of a DMU in product development tasks such as finite element analyses and simulations [42]. Huge manual efforts are being paid by engineers on daily basis to reconstitute such information [108]. Geometric modelers, as part of CAD software products, provide tools for intuitive authoring and manipulation of DMUs. These substantial advantages over two-dimensional drawings provoked a tremendous change in the field of geometric modeling. As a result, traditional blueprints gave way to 3D models in today’s design offices. In this section, we outline the potential that a DMU has to actively participate to the leverage of the PDP. As a central component to a PDP, its DMUs allows engineers to design components shapes and position them before the product is actually manufactured and put to operation. Section 1.4 explains the focal role the DMU plays in a PDP with the increasing tendency in today’s industries to relate different tasks to the DMU content, all along the PDP. Reciprocally, there is also a tendency to adapt the DMU content to the PDP requirements. A DMU shows its capacity to contain further information rather than pure geometry. Examples are component materials and their properties, kinematic connections between components, geometric constraints and functional zones to name only few (see Section 1.7). Considering this viewpoint, a DMU can do better than barely providing references for manufacturing, since it is, indeed, communicated all across a PDP. One can expect DMUs to serve as entry points for simulation purposes, e.g., allowing the generation of digital product prototypes. It would be convenient if the same model, i.e. the DMU, could be enriched with necessary knowledge for subsequent stages of the PDP, that would definitely accelerate preparation processes, e.g. FEA ones and others [64]. Nonetheless, DMUs, the way they are designed, are subjected to manufacturing requirements. This is mainly because designers oftentimes have this consideration in mind while they’re also bounded by the solid modeler capabilities when creating 3D models [102]. For this reason, the DMU is not promptly ready to play its polymorphic role in the PDP, in a reference to this concept set at Section 1.10. In fact, to process a DMU for FEA, geometric transformations are still required to adapt it to simulation requirements. Section 2.7.1 pointed out that this high skill demanding task still poses a problem to the efficiency of a PDP, and that automating it asDifferences between digital and real shapes 63 much as possible gets in the way of timely simulations. Most of today’s vendors ship their industrial CAD systems with modules such as kinematics simulation, FE simulation for structural, thermal, and flow analyses. These modules provide tools for additional tasks of a PDP rather than mere geometric modeling during the design process. However, the lack of automated and intelligent adaptation methods hinders the utilization of these FE analysis modules. Some sort of intelligence is thus required in order to adapt a DMU for development phases other than manufacturing along a PDP. Section 2.7 however, showed the shortage in the state of the art of an robust approach that functionally interprets the geometry of a DMU as an assembly of interacting components, down to the level of interacting surfaces, while taking into account dominant industrial conventional representation of such interactions (see Sections 1.5.1 and 1.7). Such an approach would faithfully bridge the gap between CAD offerings and FEA needs. A major objective of the proposed approach stands in exploiting the DMU content for simulation purposes. This content must be processed in a bottom-up manner since a DMU content reduces to robust information only for mere geometric models of components. Section 2.6 has shown that topdown approaches don’t bring a tight connection between 3D models and the technological, functional data associated to components and assemblies, and they have not emerged in commercial CAD systems. More precisely, this objective addresses the generation of a simulation model (as introduced in Section 1.9.2) that is suitable for timely and accurate FEA under prescribed simulation objectives. 3.2 Differences between digital and real shapes The geometric model of each component in a DMU is meant to provide a precise product model to enable its manufacture, as mentioned earlier in Section 1.4. Inaccurate digital models are therefore little tolerated, as such inaccuracy puts the manufacturing process at stake. However, particular geometric configurations, e.g. helical threads and involute gear profile, are not used as input of manufacturing processes. Also, modeling such surfaces and volumes as carbon copies of real shapes is a tedious and inefficient task that is of little or no interest to the PDP. In fact, the geometric accuracy of such features has no impact on the manufacturing process of the components due to at least one of the following reasons: • Components such as threaded bolts, nuts, and profiled gears are often imported as third-party components [4] that comply to specific standards1; 1Naturally, precise detailed geometry of complex surfaces such as threads and gear teeth on molded plastic components may be however important when manufactured in-house.64 Chapter 3. Functional Semantics: Needs and Objectives (a) (b) Figure 3.1: Two engaged spur gears: (a) representation of real surfaces, showing involute profiles, and a simple contact between two gears; (b) simplified representation as simple cylinders, leading to an unrealistic interference. • The machining of profiled gears, threads, spline profile, etc. can be a generative process that is prescribed by tooling parameters set later in a PDP than the design stage. Consequently, at design and simulation stages in a PDP, these shapes need not be accurate. Other examples can be easily observed in industrial DMUs since these differences between digital and real shapes is current practice. Consequently, and for the sake of efficiency, complicated surfaces that are part of imported components, or that comply to predefined implicit or explicit standards are often simplified. For instance, threads and gear profiles are modeled as simple cylindric surfaces as shows Figure 3.1. This simpli- fies the geometric modeling task, while preserving technical informations for manufacturing. Those simplifications, however, imply an interpretation from the engineers. For instance, both a brake disc and a gear may be represented as a simple cylinder after geometric simplification. Hence, the mechanical component has to be studied in its environment to clarify its nature, i.e., the component must be analyzed along with its interaction with neighboring components (see Figure 3.1). It is also worth observing that, as a consequence of these simplifications, the geometric interactions between neighboring digital components is not limited to contacts or clearances, as it is the case between real components. Indeed, digital models of components may exhibit volume interference (see Figure 3.1) while still conventionally representing a consistent configuration of their real counterpart. In addition to geometric simplifications, another inconvenience about geometric models of a DMU is the way geometric interactions are handled. We have seen in Section 1.6.2 that geometric constraints such as contact and coaxiality may be deliberately dropped and replaced by absolute positioning,Enabling semi-automatic pre-processing 65 for the sake of conciseness or re-usability. Even when positioning constraints are kept, they are still incomplete to infer geometric interactions between components, as previously established in Section 1.6.2. For instance, the simple fact that two cylindric surfaces are coaxial does not necessarily mean that corresponding faces are in contact, at play, or having an interference. These shape differences and representation shortcomings render the judgment about functional intentions of elements of a DMU a non-trivial task, even to a knowledgeable eye. This implies the incorporation of different industrial conventions into the knowledge base of an expert system, if any meaningful functional information is to be extracted. It is a second objective of the proposed approach to structure the knowledge related to component and assembly representation so that it can be processed reliably and effectively connected with 3D shapes of components and assemblies. 3.3 Enabling semi-automatic pre-processing To speed up a PDP, aeronautical, automotive and other industries face increasing needs in setting up timely FE simulations of large sub-structures of their products. The challenge is not only to study standalone components but also to simulate the structural behavior of large assemblies containing up to thousands of components [1, 41]. DMUs are widely used during a PDP as the virtual geometric product model (see Section 1.4.2). This model contains a detailed 3D representation of the whole product structure available for simulation purposes. To prepare large sub-structure models for simulation (such as wings or aircraft fuselage structures); the DMU offers a complete geometric model as an input (even though not necessarily a faithful one, as seen in Section 3.2). However, speeding up the simulation model generation (see Figure 1.19) strongly relies on reducing the time required to perform the geometric transformations needed to adapt the DMU to FE requirements in the context of the pre-processing step discussed in Section 1.9.2. 3.3.1 Pre-processing tasks Currently, due to the need of geometric transformations required to adapt the shape of a DMU to simulation objectives (see Section 1.9), the corresponding adaption of CAD models to generate FE models still requires time and specific skills because there is a lack of automation of these transformations. The time required to generate FE models often prevents engineers from using structural analyses during early stages of a PDP. Several authors proposed approaches to automate shape transformations required for a standalone component (see Section 2.7). However, very few research work addresses assembly models where similar configurations are duplicated many times, e.g., contact areas, bolted assembly joint FE models. Consequently,66 Chapter 3. Functional Semantics: Needs and Objectives Figure 3.2: Examples of aeronautical DMUs with a variety of bolted junctions [42]. DMU of aeronautical structures are particularly complex to transform due to their large number of joints incorporating bolts or rivets (see Figure 3.2). Domain decomposition and shape transformations mentioned in Section 1.9.2 are examples of interactive and error-prone processes that an engineer must perform tediously to enable efficient FE simulations. Within the available resources and time frames planned in an industrial PDP, engineers are bounded to simulate small models rather than complete assembly structures. It is an objective of the proposed approach to contribute to speed up and automate the shape transformations of assembly models for FE simulations. 3.3.2 Pre-processing automation requirements It can be observed that repetitive tasks originate from similar configurations like bolted junctions and, more generally, interfaces between components. Similar tasks relate to shape similarities as well as behavioral similarities since the shape transformations performed fit into the same simulations objectives for a given FE simulation model. As pointed out in Section 2.3, shape, behavior and function are independent concepts and shape and behavior similarities can refer to function similarity, i.e., similar shapes behaving similarly and contribute to similar functions. Indeed, it is the case when referring to bolted junctions where the underlying function is the ‘assembly of components using bolts’. This analysis shows that functions are good candidates to complement shapes when they have associated interfaces, whereas feature recognition, purely based on component geometry, do not enable a direct connection to component function (see Section 2.4). Here, the targeted FEA preparation aims at producing a quantitative behavioral analysis of an assembly, e.g., the computation of stress, strain, and displacement fields. Therefore, there is no such behavioral informationBridging the gap with functional knowledge 67 available to combine with shape information that can help derive functional information about components in addition to their shape. However, if there is no quantitative behavioral information available for components, it is possible to refer to the design rationale where design solutions emerge from a qualitative assessment of components at the early design stages. Similarly, qualitative behavior assessment is common engineers’ practice when analyzing a mechanism from either blueprints or DMUs. To this end, the above-mentioned principle is a path to another major objective of the proposed approach to automate FEA preparation processes. Indications about components functions, functional groups, and functional interactions can be gained from assembly geometry processing and behavioral information. These indications must be coupled with the product geometry, not only at the component and group of components level, but also at the joints interface level, particularly in connection with functional interactions. This may imply a functional restructuring of components geometry to highlight interaction zones. The following section sheds more light on this issue. 3.4 Bridging the gap with functional knowledge Despite attempts of geometric modelers vendors, as well as efforts paid by data exchange standardization committees, industrial practices in the field of knowledge representation and communication are still far from being standardized, as shown in Sections 1.7 and 2.6. 3D modelers still fall short of providing a unified method to maintain technical and functional properties alongside geometric models of components and assemblies. Figure 1.2 shows precise technical annotations of dimensioning and tolerancing which are standardized for a shaft-housing connection (see Appendix A). Nevertheless, in a platform-independent 3D representation of a product, such as a STEP file [7], this knowledge is lost as both shaft and housing are represented with their nominal diameter, with no further information about dimensional tolerances. Figure 3.3 depicts an example of a 3D model showing a piston fit in a cylinder sleeve. This fit should be loose in order for the crank-piston mechanism to work properly. However, both parts of the fit are represented with the same nominal diameter, leaving the fit nature ambiguous. Even when standards provide auxiliary annotations that may actually hold functional information (as Section 1.7 showed), observations reveal that current CAD modelers do not make use of these facilities, stripping their native models of all information but mere geometry when exporting them in a standardized format [69]. From this perspective, it seems that the evolution from blueprints to 3D digital models and the facilities that 3D modelers offer have come at the cost68 Chapter 3. Functional Semantics: Needs and Objectives Figure 3.3: A 3D geometric model of a crank/piston mechanism. The piston and its cylindric sleeve are represented with the same nominal diameter of 60mm. of the loss of reliability of any other information rather than approximate geometry. The bound between form, behavior and function that was seen in Section 2.3, is not available in modern DMUs. Another observation to be outlined in this context is the lack of the thoroughness of these functional and technological annotations in 3D models, even when they do exist as Sections 1.6.2 and 2.6.2 showed. Many applications, in particular structural simulations, require the association of functional information down to the level of geometric interaction zones, e.g., contact surfaces between components. Those information are still not available in a DMU in a satisfactory manner that allows their involvement in the FEA preparation process, or any other application that would fit into a PDP and use assembly models. Although DMU representations leave room for unconstrained textual annotations, that designer may utilize at different geometric levels, i.e., surfaces, solids, etc., to augment the model with functional and technological information, these annotations are too loose to provide any viable knowledge, as shown in Section 1.7. In fact, the best that we can expect from these annotations is to be coherent enterprise-wise. Reaching this cohesion however, requires engineers time and energy that compare to those needed for the manual pre-processing tasks outlined in Section 3.3.1. Method dependent on such a cohesion [32, 148] have therefore failed to provide a reliable connection to functional properties down to the level of component boundaries. In the proposed approach, its purpose is to minimize the human inter-Bridging the gap with functional knowledge 69 vention during the FEA pre-processing stage, integrating domain knowledge in an inference system that enriches a pure geometric model with technological and functional information necessary for its adaption under the user-specified simulation objectives. This work contributes to a collaborative effort in the framework of the ROMMA project [1] to reduce the FEM preparation time to adapt CAD assembly models derived from DMUs into FE models. In order to enable the semantic enrichment of a DMU that is required by state of the art FEA preparation approaches, the broken function-behaviorshape link should be mended. This recovery happens at three levels, as follows. The functional interface level Function is a result of interactions between components at their interface level. FEA applications need to know what functions are fulfilled by a component with regard to its neighboring components, in order to represent these functional interactions geometrically in a simpli- fied manner, and decide what hypotheses can be made in the light of simulation objectives. A mature approach to functionally supplement the DMU for FEA applications should thus consider the labeling of functional interfaces between components in an assembly. This leverage also requires the isolation of these interfaces as geometrically independent entities, to allow clearly interpretable labeling. Such labeling will be preformed on the basis of reference configurations between components referred to as ‘conventional interfaces’. Conventional interfaces and functional interfaces are introduced in more details in Chapter 4 to produce a taxonomy of functional interfaces as an explicit basis from which reasoning mechanisms will take place. To efficiently support the FEA preparation process, these interfaces need to located accurately over the boundary of DMU components. This objective is addressed in Chapter 5. The functional unit level Each component in an assembly plays one major well-defined functional role within its functional group or groups. Before enabling geometric simplifications, this role should be outlined as it orients the content of suggested transformations. To this end, a fruitful method must classify components into functional classes that deterministically define their functional role. Such classes, referred to as functional designations are introduced in more details in Section 4.2.3 and are based on particular spatial setup of functional interfaces. Indeed, functional designations are the major70 Chapter 3. Functional Semantics: Needs and Objectives result of the proposed approach. Enriching a component with functional designations from functional interfaces needs a reference to the behavior of this component (see Section 3.3.2). Indeed, this objective is addressed using a qualitative reasoning process as described in Chapter 6 that is followed by a rule-based reasoning (see Chapter 7) to infer the functional designation of this component. The purpose of these qualitative analyses and rule-based reasoning is to resolve the multiple interpretations that derive from the DMU input as pure geometric model. Through this approach, the objective is to set up a more generic approach than KBE ones (see Section 2.6.3) that takes advantage of the functional interface level to tightly link 3D geometry information to functional one. The functional group level In an assembly, a function is satisfied through physical interactions between a set of its components. Consequently, we can refer to these functions as internal functions. On a complementary basis, this assembly is characterized by functions with respect to its environment, i.e., these functions are often referred to as primary, secondary and constraint functions. Here, the functions referring to the environment of the assembly fall out of the scope of the present approach. Efficient methods of geometric preparation for simulation purposes use such groups of components as patterns that indicate an entry point to relate geometry to functionality. As an example, Section 3.3.1 has referred to bolted junctions that designate a group of components that contain a screw, a nut and some tightened components, at least (see Figure 3.2). Processing such subsets of an assembly in an efficient manner connects with functional information when a selection process matters. Indeed, the first step to prepare a bolted junction for FEA is the selection of the corresponding components. Accordingly, a beneficial enrichment of a DMU can organize components into functional groups that perform a given function. Those groups can then be labeled by the type of function they deliver. Labeled functional groups, referred to as functional clusters are an outcome of the proposed approach and can efficiently contribute to the desired component selection process as needed for FEA preparation. This objective is addressed in Chapter 8 and illustrated through a template-based selection process. Figure 3.4 shows how functional annotations apply at the three aforementioned levels on the DMU of a centrifugal pump.Bridging the gap with functional knowledge 71 Geometry Functionality Components' Groups Components Components' Interfaces Assembly DMU Coupling Internal Forces generation propagation Nut Stud Planar Support Threaded Link Figure 3.4: A synthetic, bottom-up approach to collect functional informations of a product at different levels, based on its geometric representation provided by its DMU.72 Chapter 3. Functional Semantics: Needs and Objectives 3.5 Conclusion In this chapter we showed that, in spite of its potentials, the DMU content as it is represented in today’s industrial examples is not yet ready to enable its active participation to the preparation process of FEA. On one side, this is because of the shape differences between the real product and its digital representation, shown in Section 3.2. On the other side, another obstacle to the DMU utilization in simulation purposes is the semantic gap, shown in Sections 3.3 and 3.4, that prevents 3D component geometry from being connected to functional an technological annotations required for any robust and efficient geometric transformation. Section 3.4 showed that those gaps should be bridged at three levels, namely the functional group, the functional unit, and the functional interface levels to allow the DMU to play its polymorphic role in the PDP as discussed in Section 1.10. The same section also showed that this task is currently being done manually, in a tedious and time-consuming manner. Therefore, this has introduced the major objective of the proposed approach toward the automation of tasks during DMU preparation for FEA. Section 2.7 showed that current efforts in the field are still unable to feed the functional enrichment required by geometric transformation methods while taking into account today’s industrial practices and conventions. Providing a method to automatically fill this need is one of the more precise objectives set throughout this chapter. While this chapter has outlined the problems and set the objectives of the proposed approach, the following one presents starts presenting the proposed contribution and conceptualize our approach.Chapter 4 Functional Restructuring and Annotation of Components Geometry The proposed approach builds upon the relationship between function, behavior and shape shown in Section 2.3 in order to extract functional information from pure geometry of components for FEM preparation purposes as shown in Section 3.4. Reference states and design rules are introduced to express the behavior of components through a qualitative reasoning process and to complement the assembly geometric model used as input (see Section 3.3.2). These facts and rules reflect the domain knowledge, and enable to check the validity of certain hypotheses that must hold true at a specific state of the product, such as operational, stand-by or relaxed states. Shortly, this bottom-up process starts with the generation of a graph of interfaces between components. Interfaces are initially defined geometrically. They are then populated with physical behavioral properties suggested by the geometry, producing a number of possible interpretations. The validation against reference states, reduces this number to ideally one interpretation per interface. Once components interfaces are identified functionally, domain knowledge rules are applied to group the semantics of those interfaces into one functional denomination per component, and to cluster components into functional groups. As a first step inside this overall process, the purpose of this chapter is to define some initial concepts related to component interfaces, their functional designation and the corresponding taxonomy. From these concepts, the above outline of the bottom-up approach to the functional enrichment of DMUs will be detailed74 Chapter 4. Functional Restructuring and Annotation into an overall schematic description as a guide to the major steps that will be detailed in Chapters 5, 6, and 7. 4.1 Qualitative bottom-up approach Section 2.3 has shown that the link between shape, behavior and function has been well established in the literature [73, 23, 173]. Design methodologies have been built upon this link to boost assembly design and collaborative product development [147, 142], while in another application of this relationship, top-down approaches are suggested to augment DMUs with functional attributes [146, 103]. These approaches, however, failed to functionally interpret commonplace geometric conventions with respect to FEA needs (see Section 2.4.2). The present work proposes a bottom-up approach that takes the pure geometric representation of an assembly as an input. Elementary facts about geometric interactions are first collected. Those facts are then used to induce higher level knowledge about components and components groups in a synthetic manner, as Figure 3.4 shows. Our approach is purely qualitative in a sense that no numerical values are used across the analysis process apart from the geometric parameters of the components, which are the input data. Geometric quantities such as distances are compared to each others, while no assumption about referential values or thresholds are made. This also applies to physical quantities which are described only symbolically with no precise values. This makes our reasoning universal, and independent of the availability of such quantities. These characteristics clearly distinguish the proposed approach compared to KBE (see Section 2.6.3) where quantitative parameter bounds are part of the KBE to perform dimensioning processes. This inductive method allows for the inference of technological knowledge about the product at different levels, starting from components functional interactions, up to their functional groups. As a prerequisite to simulation preparation tasks, the proposed process is performed after the design activity, independently of design choices, and as an automated procedure. In the rest of this chapter, Section 4.2 defines the terminology that is used in the proposed approach. The goal is to bring precise conceptual frames that are applied to notions encountered across the rest of this document. Next, Section 4.3 gives a synthetic description of our method, preparing the ground for in-depth development in chapters to come. 4.2 Common concepts Throughout this manuscript we describe the proposed method using a terminology referring to concepts that are central to this research. Here, weCommon concepts 75 identify reference concepts contributing to all stages of the functional enrichment process, and define each as it applies to this approach. 4.2.1 Function as the semantics of design Functionality is an example of non-geometric knowledge that a DMU still lacks, i.e., functions are essentially stated with natural language expressions. In fact, this knowledge becomes paramount when considering the preparation of a DMU for simulation purposes, as seen in Section 3.3. Section 2.2 examined different perspectives from which a function is seen in the literature. In the context of our work, we join scholars that make clear distinction between function and behavior, while admittedly demonstrating the strong relationship that ties them [136, 73]. This perspective stands at a cross-road between teleological and behavioral viewpoints, as discussed in Section 2.2. Indeed, distinction between behavior and function is an important point in our approach since qualitative models of behaviors are set up and attached to components to infer component function. Consequently, this process relies on an effective distinction between behavior and function—otherwise the inference mechanism set up would be pointless—and a tight connection between them so that the qualitative behaviors can be effectively related to functions with meaningful inferences. A function applies at different levels of the product structure. An interaction between two components delivers precise functionality that adds up to each component functional contribution. A particular function may be attributed to a subset of components that forms a group. As an example, the hydraulic pump illustrated on Figure 3.4 can be assigned a function to its whole set of components: (1) move of a volume of fluid from the pump inlet to the pump outlet1. This function is also designated as the primary function of the product. Considering the group of components featured in Figure 1.5 that contains the hydraulic casing (orange), the two ball bearings (dark brown), the two elastic rings (black), this group can be assigned a function: (2) guide the rotational movement of the shaft (gray). Now, considering a standalone component (see Figure 3.4 top), the stud (yellow) has as function: (3) assemble together the hydraulic casing (orange), the pump housing (gray), the hydraulic flange (brown), and the nut (green). The function of the product is then satisfied as a result of functional groups collaboration. A component can be assigned more than one function and can contribute to several functions through different groups of components, e.g., the hydraulic casing (orange) is part of two groups of components defining functions (1) and (2). 1The hydraulic pump is of type centrifugal for incompressible fluid. Therefore, its function reduces to displacement of a volume of fluid76 Chapter 4. Functional Restructuring and Annotation Figure 4.1: An example of a spline shaft-housing configuration that satisfies two functionalities that are axial positioning and power transmistion. A cut in the housing component is made to show the coupling. Definition 4.1 (Function). A function is a desired effect that a certain intentional configuration produces in a determinant manner. In this sense, the underling configuration is sufficient to produce the effect, hence, fulfill the function. However, it may or may not be unique, as some functions can be satisfied by several different means. For example, a screw-and-nut configuration satisfies the function of tightening a set of components. However, the same function can also be satisfied by other means, such as riveting, or even welding [104]. A screw-and-nut configuration is thus not necessary to tighten components, although it is sufficient. In the same context, one configuration may fulfill more that one function, as it may produce more than one desired effect. An example is a spline shaft-housing configuration that satisfies both axial positioning and power transmission as functions (see Figure 4.1). 4.2.2 Functional Interface Today’s products tend to be modular [30]. Modularity has been established as an important paradigm in almost all design disciplines. Modular systems can be easily analyzed, tested, repaired2 and upgraded. They also offer higher customizability as modules can be replaced to adapt to more specific requirements. 2In the context of mechanical products, repairing refers to the interchangeability of components.Common concepts 77 An important aspect of modularity is loose coupling [128]. This means that each module of the product has only minimal knowledge about the other modules. System parts know about each others as much as necessary to get the system operational. In order to reach a loose coupling, a single module provides a minimal interface that interacts (couples) with other modules to fulfill the product global functionality, while the actual implementation of each module functionality is kept internal. The same concept of interfacing appears in different engineering disciplines. In software engineering modularity consists in logically partitioning the software into different units at different levels, such as software packages and classes. Those units provide public interfaces describing what kind of stimuli they respond to. Communication between units is achieved through stimuli exchange, while internal implementation of each unit is kept private. In electronics, coupling coefficient refers to the amount of energy transferred between integrated circuits, and it is recommended to be the lowest possible in modular designs. In mechanical engineering, modularity applies at different levels as well. Its first clear manifestation occurs at the component level, where a single component is meant to satisfy a very precise functional description. Another sign of modularity appears at the functional group level, where components are grouped to fulfill a higher level functional requirement, even though only partially with respect to the whole product functionality. To allow the decomposition of high level functions into simpler ones, as suggested by modularity, mechanical components interact with each other through interfaces as well. Interactions can either be internal to a product or in connection with its environment. In this work we address the first category of interactions only, and we refer to interfaces that allow this interaction as functional interfaces (FIs). A very basic example of a functionality that is fulfilled by FIs —and is usually kept implicit due to its triviality— is the relative positioning of components with respect to each others. Component shapes are designed so that they offer interfaces standing as obstacles to remove some of the degrees of freedom of some of their neighboring components. In a real product, FIs are satisfied by functional contacts and plays (see Figure 4.2 for an example). Functions are defined by the geometric nature of the interaction between two components, and by their physical properties [118] (see examples in Section 4.2.5). Definition 4.2 (Functional Interface). A functional interface (FI) is an interaction between two neighboring mechanical components that fulfills, or contributes to the fulfillment of a function. An FI is characterized by its ability to propagate internal forces, with respect to the product as a physical system, between components involved78 Chapter 4. Functional Restructuring and Annotation Operating pitch circles Functional play Figure 4.2: A gear train connection as functional interface, showing the functional play between gear teeth. in the interface. A property that enables the FIs to meet its expected functionality from a dynamic standpoint. When functionality is viewed from a kinematic standpoint, FIs are characterized by their abilities to restrict relative motion of components involved in the interface with respect to each others, reducing their respective DoF. Examples of FIs are: threaded link, spline link, planar support, adherent conic support, etc. 4.2.3 Functional Designation Besides loose coupling at the product level, modularity requires tight cohesion at the module level. That is, individual modules should fulfill one or more well-defined function each. Loose coupling and tight cohesion happen in parallel in a highly modular system. When it applies to mechanical engineering, mechanical components are considered as modules, and tight cohesion reduces to assigning a number of precise functions to each component. There is a finite set of functions that a mechanical component can fulfill, considering an upper bound on the number of functions per individual component, the number of combinations is bound as well. However, not all combinations are common, and some, such as tightening and guidance, are not even possible. We refer to the comprehensive set of functions that one mechanical component may satisfy as the functional designation (FD) of this component. Definition 4.3 (Functional Designation). A functional designation (FD) is an equivalence class defined by the binary relation ‘has the same set of functions as’ that is defined on the set of all mechanical components. Given C the set of all mechanical components, and FC = {f1, f2, . . . fn} the set of all functions that any given component may satisfy. Let c1 ∈ CCommon concepts 79 and c2 ∈ C be components and FC 1 ∈ FC and FC 2 ∈ FC the sets of functions that they satisfy, in respective order. We state that c1 has the same set of functions as c2 if and only if FC 1 is equal to FC 2 : c1 ≡C f c2 ⇐⇒ FC 1 = FC 2 . (4.1) We note that ≡C f is indeed an equivalence relation, as it is reflexive, symmetric, and transitive. We call ≡C f the functional equivalence relation on C; the set of all mechanical components. We note that if FC 1 �= FC 2 , it logically follows from Equation 4.1 that c1 �≡C f c2. We thus infer that c1 �= c2, since ≡C f is reflexive. Since an equivalence relation partitions a set into mutually exclusive equivalence classes [40], FDs, as equivalence classes of ≡C f according to Definition 4.3, are indeed mutually exclusive sets. This means that components having a functional designation FC 1 are functionally different from components having a functional designation FC 2 . Indeed, FC c ⊂ FC is unique for a component c ∈ C and it is the identifier of its equivalence class. This identifier is expressed as a character string that uniquely characterizes FC c and can be one of the following3: 1 An expression that relates to one function among the set of functions covered by FC c , e.g., a stop screw. Often, this expression relates to one major function of the component, its primary function; 2 An expression that uniquely designates FC c in the common language, e.g., a stud, and implicitly matches FC c . Figure 4.3 shows examples of selected mechanical components and their respective FDs. FDs relate to FIs in a way that each set of functions at the component level (thus an FD) requires a set of functions at the interaction level (thus at least one FI), i.e. let FC c be the FD of c, FI c is the set of FIs belonging to c and |FI c| ≥ 1. We refer to this one-to-many relation as the functional breakdown. Unlike unreliable textual annotations (see Section 2.6), the concept of FD allows the qualitative reasoning and inference processes to give a component a functional identifier that unambiguously define the functionality of each labeled element. As shown in Section 4.2.6, FDs are organized into super-classes that contain each others, building a hierarchical functional classification. However, FDs are mutually exclusive classes at the leaf level, i.e., a given component can only belong to one FD. This labeling provides assembly components with a brief, yet precise functional description that can be, once assigned, exploited though out later stages of a functional analysis. 3The two categories highlighted may behave differently according to the language used, e.g. a ‘shoulder screw’ fall into category 1 in English whereas it is a ‘axe ´epaul´e’ in French.80 Chapter 4. Functional Restructuring and Annotation cap-screw set screw stud shoulder screw nut cap nut pressure screw flat washer lock washer ball bearing spur gear conic gear Figure 4.3: Functional designations exemplified by instance components of each (courtesy TraceParts [4]). The label under each instance(s) indicates the identifier used as functional designation for each equivalence class.Common concepts 81 Geometrically speaking, this mapping restructures the geometry of a component that belongs to a given FD into interaction zones, each defining a FI, according to the functional breakdown of this component. Figure 4.4 shows an example of the restructuring of a cap-screw. This means that the functional breakdown is not a mere logical relation between a FD and FIs, there is also a strong connection with the geometric representation of the component c, i.e., the B-Rep of the 3D solid model of c must be decomposed into areas that match each FI of FI c. This connection efficiently sets up a consistency between the shape of c, its FIs, and its function with its FD. This consistency will be further enforced through the qualitative analysis and inference processes that will refer to the behavior of c, for the first one, and to the connection between shape, behavior and function, for the second one (see Chapters 6 and 7). Also, it should be observed that the concept of FD is generic and not bounded to any quantitative parameter that may hinder its use for a component as it can happen for KBE approaches (see Section 2.6.3). 4.2.4 Functional Cluster As mentioned earlier in Section 4.2.2; modularity can also apply at a higher level than individual components. A set of components may tie up together to deliver a coherent function or set of functions, while loosely interfacing with other components/groups of components through minimal interfaces. Those groups also form a module each. In the context of our research we refer to each such group of components as a functional group. We refer to the set of functional groups that satisfies one or more particular functions as a functional cluster (FC). Compared to the concept of FD where this concept can be stated for a standalone component c without referring precisely to geometric entities, it is critical to refer to the geometric interfaces between components when addressing FCs. Effectively, each function is not only characterized symbolically by its designation, e.g. set screw, but it is also instanciated through the geometric interfaces it involves between components. Therefore, from the set FC that symbolically represents all the functions any component can satisfy, we can derive Fc = {fc i , fc j , . . .} the set of functions c performs where Fc is an instance of FC and fc i designates the symbolic representation of a function fi ∈ FC associated with the geometric interfaces needed to describe fi on c. fc i is an instance of fi attached to c, an instance of a component class characterized by its geometric representation and its geometric interfaces with other components. Definition 4.4 (Functional Cluster). A functional cluster (FC) is an equivalence class defined by the binary relation ‘has the same set of functions as’ that is defined on the set of all functional groups, G. A particular instance82 Chapter 4. Functional Restructuring and Annotation Initial component FIs involved in an FD Structured component after matching FIs with an FD Figure 4.4: A geometrically restructured cap-screw according to its functional breakdown.Common concepts 83 of this equivalence class is g, a set of components. The set of functions of FC, Fg, is achieved by more than one component and it is an instance of functions performed through some interfaces of components of g. At the difference of a FD that relates to a single component of a DMU, an FC addresses more than one component and not necessarily all the interfaces of each component of this FC, which means that a component of this FC can be involved into other FCs. Let Cd be the set of components contained in a DMU d, and g ⊆ Cd be a minimal non-empty set of components that together satisfy a set of functions Fg. Each function of Fg is associated with one or more interfaces between components of g. Based on that observation, we refer to g as a functional group. We observe that: |g| > 1; (4.2) g ⊆ Cd ⊂ C. (4.3) Given G the set of all functional groups and FG = {f1, f2, . . . , fn} the set of functions that any given functional group may satisfy, FG ⊂ F, where F designates the set of functions all assemblies can satisfy. Similarly to the observations mentioned previously about the set of functions associated with a component through its FD, Fg is the instance of FG for the set g, which is an instance of a FC. Let ci be any component of g and Fg ci the set of functions associated to ci, i.e., Fg ci ⊆ Fg. It has to be observed that Fg ci does not necessarily contains all the functions attached to all the interfaces of ci. Now, let g1 ∈ G and g2 ∈ G be functional groups and Fg1 and Fg2 the sets of functions that they satisfy, in respective order. Fg1 is associated with FG1 ⊆ FG, its symbolic counterpart. Likewise, Fg2 is associated with FG2 . We state that g1 ‘has the same set of functions as’ g2 if and only if FG 1 equals FG 2 : g1 ≡G f g2 ⇐⇒ Fg1 = Fg2 (4.4) We note that ≡G f is indeed an equivalence relation, as it is reflexive, symmetric, and transitive. We call ≡G f the functional equivalence relation on G; the set of all functional groups. It is worth noticing that while FCs are equivalence classes, thus mutually exclusive, functional groups are not. Functional groups being reduced to a set of components ci, cj , . . ., the functions performed by these components would contain functions attached to several FCs because the set of functions attached to either of its components may contain functions related to more than one FC. In fact, functional groups of a given DMU are not equivalence classes because a component c can belong to two different functional groups,84 Chapter 4. Functional Restructuring and Annotation (a) (b) (c) Figure 4.5: Examples of three functional groups belonging to the same FC: disassemblable joint obtained with obstacles and threaded links: (a) Bolted joint, (b) Stud joint (c) Screw joint. g1 and g2. Indeed, if Fg ci ⊂ Fci , it means that (Fci − Fg ci ) �= ∅ and this nonempty set of functions attached to ci can be part of some other FC. This justifies an FC being identified by a set of functions rather than a set of components. The identifier of a FC is expressed as a character string that uniquely characterizes fg = f� (g) and is usually an expression that uniquely designates fg in the common language and may relate one function of fg, e.g., a disassemblable joint obtained with obstacles and threaded links, and implicitly matches fg. Here also, this identifier can be related to the primary function of the cluster. To illustrate more precisely this concept, Figure 1.5 shows a set of components: hydraulic casing (orange), the two ball bearings (dark brown), the two elastic rings (dark blue), this group is assigned a FC whose identifier can be stated as: guide the rotational movement of a shaft, which refers to its primary function. Other illustrations of FCs are found in Figure 4.5 where each group refers to the same category of cluster that can be stated as disassemblable joint obtained with obstacles and threaded links. Indeed, each cluster is a variant of a technological solution that can be used to tighten components together using different categories of connectors, namely a bolt (Figure 4.5a), a stud (Figure 4.5b), or a screw (Figure 4.5c). In this example variants originate from the different connectors that belong to different FDs, respectively (capscrew and nut, stud and nut, capscrew) where each variant contains a different set of FIs. Likewise FDs, FCs also relate closely to FIs. For instance, a functionalCommon concepts 85 Figure 4.6: Examples of CIs as in a bolted joint. group forming a bolted joint (an FC) can be recognized as the set of components that are involved in an internal load propagation cycle generated by a threaded link and propagated through FIs of types planar or conical supports. FDs in their turn relate to FCs in what we refers to as functional aggregation where the union of functionalities offered by FDs produces a more general functionality characterized by the FC. 4.2.5 Conventional Interface The functionality of an interface is decidedly determined by the geometric configuration of the interaction, and the physical properties of components materials, as briefly mentioned in Section 4.2.2. For instance a threaded part of a screw fulfills its function of tightening thanks to the helical shape of its groove and the friction along the thread that produces irreversitibility. The inner tube of a tire does it jobs properly as a result of its toroidal shape and relatively low material stiffness. Subsequently, geometric interactions between adjacent components reveal essential information that guides the identification of functional properties. Objects interactions in the digital model, however, do not accurately reflect reality, as previously demonstrated in Section 3.2. In fact, the way interactions are represented is no more than a convention made by designers, or prescribed by a company, or a common practice since there is no standard referring to the 3D representation of components. We refer to interactions between neighboring components in a DMU as conventional interfaces (CIs). Physical, and functional properties can be attached to this concept. However, a CI is initially identified by a geometric interaction between two components in a DMU. This interaction encapsulates an interaction zone which can be either a contact, an interference, or a clearance (see Figure 4.6). Contact A contact between two components C1 and C2 defines one or more86 Chapter 4. Functional Restructuring and Annotation shared surfaces or shared curves, without any shared volume (see Figure 4.6). The interaction zone of a contact is defined by this set of shared surfaces and/or curves, leading to potential non-manifold con- figurations, i.e. a contact along a surface area connected to a contact along a line4. A contact representation is usually realistic in the sense that a contact in a digital model may reflect the same configuration in the corresponding real product, where C1 and C2 are, indeed, touching each other. However, when a clearance between C1 and C2 becomes small enough in reality, it may conventionally be reduced to a geometric contact as well. Consequently, a cylindrical contact can be functionally interpreted either as a loose or a tight fit (see Figure 3.3 for an example). In some conventions a contact may represent an idealization of more complex settings, like threaded links or gears and sprocket connections. Contacts provide very valuable information to our reasoning, as they usually help defining locations where resulting interaction forces can be transmitted. At the same time they work as motion barriers reducing components DoF. Interference An interference defines a shared volume between two components C1 and C3 . Obviously, an interference is a non-realistic representation in the sense that the two digital shapes of C1 and C3 interfering in a DMU do not represent overlapping volumes of C1 and C3 in a real product, as this leads to non-physical configurations. Therefore, interferences are often the result of local shape simplifications combined with rather complex settings of component locations. For instance, engaged spur gears frequently result in cylindrical interference volumes (see Figure 3.1). Also, when interferences become small enough, e.g., a shaft diameter that is slightly greater than its housing diameter to produce a tight fit between them, it is not represented in the DMU where the two corresponding components have the same diameter and produce a contact. Due to their idealized nature, interferences are harder to interpret than contacts; however, they also provide valuable information about functional attributes of a CI. Clearance A clearance occurs when a distance between surfaces of two components C1 and C2 is less than a defined threshold while staying greater than zero, i.e. C1 does not touch C2 in the area of the corre- 4Though this configuration is not mechanically meaningful, it can be a geometric con- figuration appearing in a DMU.Common concepts 87 sponding surfaces. The distance value acting as a threshold between the two components is a matter of design decision. The interaction zone of a clearance is the set of surfaces of C1 and C2 for which the minimal distance is less than the threshold while staying strictly positive. When this minimal distance conveys a functional intention, the clearance is said to be a functional play (see Figure 4.2). As a convention, when a functional play becomes small enough, it can be represented as a contact in a DMU. Definition 4.5 (Conventional Interface). A conventional interface (CI) is a conceptual entity that represents an interaction between two components in an assembly. It is identified by the geometric interaction of corresponding components in a DMU, and augmented with other semantics such as physical and functional properties. Given I the set of all CIs in a DMU. We define the binary relation ‘forms’ as (∀ c1 ∈ C, i ∈ I) c1�f i if and only if the component c1 forms the conventional interface i with another component c2 ∈ C. As stated in the definition of a CI, this interface is defined from two components. If �f relates one component c1 to a CI, i, this means that another instance of �f relates c2 to the same CI, i. We also define the binary relation ‘links’ as �l = �−1 f . We note that each CI ‘links’ exactly two components. This can be noted: (∀(i, c) ∈ I × C; ∃(x, y) ∈ C2) x �= y ∧ x�f i ∧ y�f i ∧ c�f i =⇒ (c = x ∨ c = y). Since FIs are the result of interactions between components, a CI can be seen as a potential FI, when the interaction it incorporates conveys a functional meaning. There exists no direct one-to-one mapping between CI and FI though. For example a cylindric interference can equally represent a threaded link as well as a spline link. This is due to the simplified nature of CIs. In both cases, either helical threads or meshed teeth and grooves configurations are represented as a simple interference. These ambiguities will be processed with the qualitative behavior to filter out some of them (see Chapter 6). Section 5.4.1 shows how to interpret CIs into their functional counterparts, i.e., their corresponding FIs. 4.2.6 Taxonomies The concepts previously defined in this chapter define equivalence binary relations, that is they divide the global sets of functions, components in-88 Chapter 4. Functional Restructuring and Annotation teractions, components, functional groups, and geometric interactions into mutually exclusive subsets called classes. Examples are: • Function defines reversible tightening as a class of the global set of all functions F. • FI defines threaded link as a class of the global set of all components interactions If . • FD defines cap-screw as a class of the global set of all components C. • FC defines bolted joint as a class of the global set of all functional groups G. • CI defines complete cylindric interference as a class of the global set of all geometric interactions Ig. Those classes, however, can be grouped in their turn into more general ones, i.e., larger mutually exclusive subsets. This grouping is the result of sharing some less discriminant semantic properties, e.g., functional or geometrical ones, across multiple primitive equivalent classes. We note that, for example, reversible tightening is no more that a tightening function which has a more specific property of being reversible. Thus, reversible tightening and irreversible tightening can be grouped in a more general function class called tightening. As a complement, disassemblable joint obtained with obstacles and threaded links is a more specific class that is indirectly related to the reversible tightening class. In the same spirit, complete cylindric interference and partial cylindric interference are grouped in a more general geometric interaction class called cylindric interference. This leads to the structuring of each concept in a hierarchical structure that reflects this generalization relation. We call each of these hierarchies a taxonomy. Definition 4.6 (Taxonomy). A taxonomy is a tree-like structure for which the root is the concept domain of discourse, and the leaves are equivalence classes that the concept defines. At each node, the children of the node are mutually exclusive sets. A concept domain of discourse is the global set that the concept covers. That is F for function, If for FI, C for FD, 2C for FC, and Ig for CI. Organizing FD in a hierarchical structure allows the proposed approach to gradually identify components. For instance, a given component can be first identified as a fastener at an early stage of the reasoning process, as it complies to certain rules, this can be refined further by identifying the component in hand as a screw in later stages. Finally, the component can be precisely assigned the FD of a cap-screw if certain conditions are met.Common concepts 89 Power Transmitter Seal Fastener Bearing Contact Bearing Roller Bearing Screw Nut Set Nut Cap Nut Screw Capscrew Spur Gear Conic Gear Component Gear Sprocket Pinion GasketValve Pressure Stud Screw Shoulder Screw Figure 4.7: A subtree of the taxonomy of FDs. Figure 4.7 shows a portion of the taxonomy of FDs, showing the path to cap-screw. It is now important to note that the taxonomy of FDs uniquely defines the components of a DMU where these FDs are located in the leaves of the taxonomy. It is effectively the place where the taxonomy associates a single component to one FD. The same applies to CIs, where geometric properties of an interface can be narrowed down in an adaptive manner using the taxonomy of CIs, starting with detecting whether it is a contact, interference, or clearance5 down to the precise geometric configuration identification of the CI. Figure 4.8 shows portions of FI taxonomy (left) and CI taxonomy (right), and the relation between each class expressed at the leaf levels. This relationship links each CI to all FIs that it may conventionally represent according to observations in industrial DMUs. As the figure depicts, and as shown in Section 4.2.5, this connection is inherently ambiguous as it relates one CI to possibly more than one FI. It however defines at the outset how CIs must be functionally interpreted knowing only their geometric properties (see Section 5.4). This ambiguity is reduced on a case-by-case basis, as shown in Chapter 6. 5We show later in Chapter 5 that we are only interested in contacts and interferences in the scope of our research.90 Chapter 4. Functional Restructuring and Annotation Spline Link Threaded Link Snug Fit Adhesive Link Loose Fit Conic Support Planar Support Linear Support Radial Circular Contact Axial Circular Contact Cylindric Interference Cylindric Contact Conic Contact Planar Contact Linear Contact Circular Contact Clamp Link Support Kinematic Link FI CI Interference Contact Surface Contact Curve Contact Manifold Interference Figure 4.8: Taxonomies of FIs (left) and CIs (right). Dotted lines show how they relate to each other at the leave level (the figure only shows a partial view of each taxonomy).Method walk-through 91 Extraction of Component´s Interfaces Assignment of Functional Interpretations Qualitative Assessment against Reference States Assignment of Functional Designations Digital Mockup Set of B-Rep models Restructure and Annotated Geometry Geometric representation of components interactions Deriving elemetary functionalities from components interfaces Symoblic expression of component´s behavior Matching function patterns to structured components Figure 4.9: Data and process flow diagram of the proposed approach. 4.3 Method walk-through In this section we define the outlines of our method using the reference concepts introduced in the previous sections. The method takes as only input the geometry of product components as represented in a DMU. The proposed approach treats this model through different stages, as shown in Figure 4.9, and concludes to deliver a restructuring of the initial geometric models of components, with coherent technical and functional annotations at different level of details where the first level is the FD of components. Next, we briefly present each of these stages to synthesize the overall process before details are elaborated in a dedicated chapter per stage in the rest of this document. As depicted on Figure 4.9 the overall scheme is of type linear and its main stages are as follows. Extraction of component interfaces The first step of the process is purely geometric. In this phase geometric interactions between components are detected. A CI is created for each valid interaction, and it is identified by the geometric nature of the interaction zone. CIs are also loaded with information about their location and orientation with respect to the whole assembly. Based on the nature of each CI, the taxonomy of CIs (see Figure 4.8) is populated and a logical connection is set up between the geometric data structure of this CI and its associated instance in the taxonomy. Also, the binary relations between components and CIs are expressed in a graph structure, which is passed to the next stage together with the92 Chapter 4. Functional Restructuring and Annotation taxonomy of CIs, as a result of the geometric analysis. Assignment of functional interpretations In this stage, a first attempt to functionally interpret CIs is made. This is performed strictly using the intrinsic geometric properties of each interface. Generally speaking, more than one functional interpretation is possible per geometric configuration, hence, more than one possible FI is assigned to each CI. This process populates the taxonomy of FIs and set up the connections between this taxonomy and the taxonomy of CIs that has been populated at the previous step. The connection between the taxonomies conforms to Figure 4.8. At this stage, all the functional interpretations of the interfaces between components are expressed and structured to characterize the ambiguities living in a DMU that originate from the conventional representations applied to each of its components. Generating the instances of the taxonomy of FIs sets a link between shape and function at the interface level between components. Because the interfaces are the most elementary areas where components interact, their functions are elementary and the corresponding set of functions is rather small and can be enumerated easily. The behavioral phenomenon used to assign function to each CI is based on the kinematic behavior of the interface, i.e., the relative movements between the components defining this interface. Chapter 5 details the detection and initial interpretations of geometric interactions. Qualitative behavioral assessment In order to reduce the number of function interpretations to one per interface between components, a physical dimension is given to each CI. Since physical properties of interfaces are not yet available, we generate assumptions for each possible interpretation, then the goal shifts to refute some of those assumptions, thus their relative function interpretation. These physical properties are related to a behavior of the DMU that express a transition between reference states assigned to the DMU (see Section 2.2 and Section 2.3). This refutation is made by validating each possible interpretation and checking its physical plausibility and mechanical meaningfulness against a set of established reference states. The corresponding process is based on a qualitative behavior simulation to be independent of physical quantities that are not available with the DMU and/or not available at the stage of a product development process where the DMU is used as input. The output of this stage is a precise functional interpretations of CIs in terms of their respective FIs.Conclusions 93 Chapter 6 describe the details about the qualitative analysis algorithm as well as the concept of state. Assignment of functional denominations Once functional properties of each interface is identified, i.e., the previous step has discarded all unnecessary interpretations to keep only one of them per interface, the functionality of components is investigated based on this knowledge. This is done using rules that describe relations between FDs, FCs, and FIs, in a pattern-matching-like manner. This is the stage where relationships between shape, behavior and function is used (see Section 2.3). The spatial layout of interfaces combined with their functional behavior obtained from the previous stage is used to infer the appropriate function of some components, hence their corresponding FD (see Section 4.2.3). The result of this stage is components classification into their corresponding FDs, and components clustering into FCs. The component clustering derives from the taxonomy generated from FCs. Chapter 7 provides a detailed description of this rule-based reasoning. Semantically-augmented geometric model The previously collected knowledge is finally integrated into a semanticallyenriched and restructured geometric model of the DMU components. The restructuring is the result of the breakdown of model components into geometric entities that reflect the functional interactions between components by means of its CIs (according to the functional breakdown), and the classification of components belonging to the same functional cluster into groups (according to the functional aggregation). Additionally, the geometric decomposition of components can be used to describe precisely the FDs of components, i.e., the FIs of components involved in the FD of a component are also connected to each other and related to the FD of this component. The semantic enrichment is achieved by the functional annotation of interfaces, components, and groups of components. Based on this enrichment, advantages can be gained to select components in a DMU in accordance with their FD and their function and process their neighborhood (see Chapter 8). This is particularly relevant for the pre-processing of DMUs for FEA. 4.4 Conclusions This chapter has introduced some reference concepts of the proposed approach. These concepts outline the knowledge modeling process used throughout the proposed approach. There, the dependencies between shape, behav-94 Chapter 4. Functional Restructuring and Annotation ior and function is precisely analyzed to produce efficient mechanisms that can be used to enrich a purely geometric model of a DMU up to functional information. It has to be observed that the proposed approach is not depending upon a particular morphology of the components that could restrict the range of DMUs that could be processed. Therefore, the proposed enrichment process is more generic than KBE approaches (see Section 2.6). Also, the boundary decomposition of components resulting from the identification of CIs and their enrichment with functional information to obtain FIs show how this process can contribute to the definition of functional features and how these features differ from features encountered in prior work (see Section 2.4). Here, the dependency between shape, behavior and function brings consistency to the functional information obtained from the enrichment process. The proposed constructive bottom-up method has been presented synthetically to emphasize its key steps. It has outlined central concepts (see Section 4.2) and how they contribute to the context of the proposed enrichment process, before we enumerated the major stages of the proposed method in Section 4.3, shedding lights on how these concepts interact and fit into the paradigm of shape - behavior - function dependencies. Introduced concepts are revisited in the upcoming chapters, where we develop our approach in more details.Chapter 5 Functional Geometric Interaction between Components in a DMU Product modules interact through precise interfaces, this applies to all engineering domains as we have shown in Section 4.2.2. When it comes to mechanical engineering those interfaces are the direct result of components geometric interaction, where components play the role of modules in this context. This joins what is referred to in the literature as form-function relationship and shown in Section 2.3. The first indicator to components functions thus is their geometric interactions. In this chapter we show how to efficiently, yet precisely detect those interactions of interest as basis of a thorough functional analysis. 5.1 Functional surfaces As demonstrated in Section 4.2.2, FIs occur at the geometric interactions between components in a DMU such as contacts and interferences. This can theoretically happen between any kind of surfaces at both sides of the interface, resulting in different possible types of interaction zones. Observation shows, however, that geometric interaction of interest to our analysis, that is those who convey a functional meaning, are restricted to a subset of all possible configurations. In fact, studying industrial DMUs showed that functional interaction happens at parts of the components that fall in one of the following two categories. • Simple geometric configuration in the real product such as planar con-96 Chapter 5. Functional Geometric Interaction Figure 5.1: Approximate relative rotational position of components in a spline link; detailed view on the left, global one on the right (courtesy ANTECIM). tacts and cylindric fits. In this case the real geometry is not simplified in the digital model, and surfaces are represented as they should be manufactured. This configuration is quite common. It is preferable as planes, spheres, and ruled surfaces are relatively easy to machine rather than free form surfaces. • Complex repetitive geometric features, like helices and involute teeth. Such profiles are necessary to insure specific physical behavioral properties, allowing the fulfillment of particular functions. A detailed representation of such surfaces potentially leads to inaccurate relative positioning of components when they are assembled together (refer to Figure 5.1 for an example). Moreover, the machining of such profiles are done independently of the digital model, since whole components are often out-sourced, or features are machined using particular tools. For these reasons, such detailed configurations are simplified in the DMU, and reduced to simple contacts or interferences, as shown in Section 3.2. Figure 1.7 shows how a threaded connection between a bolt and a nut is represented as a simple interference. In the lights of the aforementioned observation, we note that only interactions that occur between canonic surfaces in the digital model may hold functional interpretations, hence, only these interactions are of interest to our research. This leads to the following hypothesis. Hypothesis 5.1 (Functional surfaces). In a DMU, FIs are represented using canonical surfaces that can be either planes, spheres, cones, tori, or cylinders. We refer to such surfaces as functional surfaces.Geometric preparation and rapid detection of interactions 97 Free form surfaces, such as B´ezier patches [151] and NURBS [130], are still used in product modeling for different reasons, not the least of which are their precise mathematical representation, intuitive modeling, and their agronomic and aerodynamic qualities. Since free form surfaces do exist in a DMU, interaction between them may indeed occur in an assembly. However, they usually do not connect components functionally. They may though represent function interactions with the product environment, such as aerodynamic drag. Nonetheless, such interaction are out of the scope of our study as external elements such as gases and fluids are usually not present in a DMU. 5.2 Geometric preparation and rapid detection of interactions In this section we describe the very first stage of our method which consist of the geometric analysis to detect components interfaces and their geometric properties. First, the nature of the method input as the geometric model of the product is explained. Before going into details of the optimized detection algorithm. 5.2.1 Geometric model as global input As mentioned in Section 4.3, our analysis and reasoning to reveal functional properties about the product are based solely on the geometric model of this product, as represented in its DMU. In the context of our research we opt to use a standardized portable representation, that is widely used in industry to communicate product models between different CAD systems. This is STEP format as standardized by ISO 10303 [7]. STEP aims to provide a neutral format that represents product data all along its lifecycle, across different platforms. However, and as shown in Section 3.4 industrial practices make little use of STEP support of nongeometric annotations. We are, thus, only concerned about part of the standard that deals with geometric representation and referred to as AP 203 [8]. STEP is implemented using one of the following methods. STEP-File Where product data are represented in and ASCII structured file. This method is defined by ISO 10303-21 [10]. STEP-XML An alternative to the previous method that uses an XML structured file. Both methods have the advantage of being highly portable across different platforms. This method is defined by ISO 10303-28 [9].98 Chapter 5. Functional Geometric Interaction (a) (b) Figure 5.2: Effect of maximal faces and edges generation. Patch boundaries are marked with black edges. Initial boundary decomposition (a), boundary decomposition with maximal faces and edges (b) (courtesy ANTECIM). SDAI An Application Programming Interface (API) that deals with products data, and is defined by ISO 10303-22 [11]. Our methods takes a product DMU represented as a STEP-File formatted file, and passes it to the first stage of our approach: the geometric analysis. 5.2.2 Maximal edges and surfaces STEP describes components geometric models using a B-Rep format. Unfortunately, B-Rep encoding of a geometric object is not unique. That is; two STEP files may represent the same shape differently. This is due to the fact that an edge (then called a wire) can be represented as a set of topologically-connected smaller edges laying on the same curve. The same applies to faces, where a face can be divided into smaller ones that share the same surface and are topologically-connected. This phenomenon originates from component modeling process where functional surfaces are often broken down into smaller pieces because of the constructive nature of the process inherent to industrial CAD modelers. Additionally, geometric modelers are subjected to topological and parametric constraints [111]. This prevent the boundary decomposition from matching the real boundaries of a component. For example, a cylindrical surface can be represented either with two half cylinders or a single cylindrical patch whose boundary contains a functionally meaningless generatrix, since it is not a boundary of any surface on the real component (refer to Figure 5.2). The removal of such unnecessary geometric elements is mandatory to obtain a unique geometric representation of a shape. As shown in Sec-Geometric preparation and rapid detection of interactions 99 tion 2.5.2, representation uniqueness is a must when useful information is to be extracted from a geometric model. As a desirable side effect, the decrease of the number of geometric elements boosts the performance of all subsequent geometric treatments. To obtain this representation of components boundaries, adjacent faces (i.e. topologically-connected ones) that belong to the same analytical surface are merged into one entity; a maximal face. A maximal face is represented by its underlying oriented and topologically-connected faces. Edges are also grouped into maximal edges using the same criterion, where adjacent edges laying on the same analytical curve are merged. A maximal edge is represented by its underlying oriented and topologically-connected edges. As a result, a cylindrical face can end up with a boundary described by two closed edges without vertices. The corresponding data-structure uses hyper-graphs and was introduced by Foucault et al. [68]. The resulting normalized geometric model with maximal edges and surfaces has a minimal number of topological elements (vertices, edges, and faces). 5.2.3 Geometric interaction detection Once the geometric model is normalized, it makes way for the detection of geometrical interaction zones of interest that define CIs. This means the detection of contacts and interferences that potentially convey a functional meaning. Clearances as functional plays Clearances may imply functional intention as shown in Section 4.2.5, this is, however, more intricate to detect than contacts and interferences. This is basically because clearance detection, unlike that of contacts and interferences, is dependent on a parameter which is the play threshold. The play ρ is the minimal distance that two component preserve between their surfaces, and can be defined as ρ = min p1∈∂C1 min p2∈∂C2 �−−→p1p2� as shown in Figure 5.3. If the play between two components is less than or equal to a predefined threshold ρ ≤ P, components C1 and C2 are said to have a clearance. This dependence on an input parameter is contradictory to our assumption of a purely qualitative reasoning (motivations are explained in Section 4.1). Moreover, and in spite of the potential functional implication of plays, they are of less use to later stages of our analysis, as this potential functional contribution is not easy to verify. Finally, functional plays are usually not simplified in any way when preparing a CAD model for100 Chapter 5. Functional Geometric Interaction Figure 5.3: Calculation of the play ρ between two solids C1 and C2, where d is the distance between two given points on the surfaces of C1 and C2, and δ is the minimal distance between a given point on C1 and the surface of C2. simulation, that makes their identification irrelevant to the geometric transformation process. For all these reasons, clearance detection is kept out of the scope of our implementation, while focus was given to efficient detection of contacts and interferences. Early elimination of negatives A naive approach to the geometric interaction detection is to use boolean operators—explained hereafter—between pairs of solids of the model at hand. This can however be enhanced using the early elimination of negatives. Early elimination of negatives filters out candidate pairs that obviously have no interaction zones, this is done using bounding boxes technique. A bounding box of an object C is a minimal box with edges parallel to the global coordinate system, which inclusively contains the object C. Each bounding box is then defined by six values (in 3D): xmin, xmax, ymin, ymax, zmin, and zmax. Bounding boxes interaction check reduces to 6 floatingpoint comparisons at most. If the bounding boxes of two components do not interact geometrically, the two components do not either.Geometric preparation and rapid detection of interactions 101 Boolean operators drawbacks Boolean operators provide an accurate tool to detect contact and interference zones. The intersection between two solids1 C1 and C2 is computed, generating a set of geometrically connected shapes S, where ∀S1, S2 ∈ S, int(S1) ∩ int(S2) = ∅ ∧ � S∈S S = C1 ∩ C2 . where int(S) = S − ∂S is the interior of the solid S. If S is an empty set, the two solids are said to have no geometric interaction. Otherwise, and for each resulting shape S, if the shape is a volume (possibly with non-manifold configurations) the two solids are said to be interfering at S. If the shape is of a lesser dimension (a surface, curve, or point) the two solids are said to be in contact at S. Nevertheless, this tool is costly in time and resources. This cost quickly becomes prohibitive, even for modestly large DMUs. Additionally, even though the precise interaction zone is obtained as a result of the boolean operation, geometric parameters are still to be looked for into those resulting shapes. That means that the cylindric interference between two object, for instance, is returned as a B-Rep shape, and still needs to be studied to obtain the axis and diameters of the interaction, the axis being notably required for further stages of our approach. Canonical face comparison To avoid the burden of boolean operators when not needed, a simpler, yet more efficient, detection technique is utilized, based on the mere comparison of geometric entity of two neighboring objects. We consider two objects to be neighbors if they pass the bounding boxes test (i.e. their bounding boxes interact with one another). In this sens, bounding boxes are used first to filter out non-adjacent solids. The remaining ones are then checked pairwise for geometric interactions. For each pair of solids, maximal faces of one solid that lie on canonic surfaces are compared against those of the other. We adopt a simple, yet extensible approach to extract geometric interactions, based on the comparison of the geometric characteristics of canonic surfaces. This comparison is no more than a secondary filtering of irrelevant interaction candidates surviving the bounding boxes check. The final detection of interaction zone is discussed in Section 5.3. Take two solids C1 and C2 whose bounding boxes are in interaction. Therefore, canonic faces of C1 is to be compared to these of C2. Let us 1Solids here are represented by their closure C = int(C) ∪ ∂C.102 Chapter 5. Functional Geometric Interaction consider a maximal faces F1 ⊂ ∂C1 and F2 ⊂ ∂C2. We need to compare F1 to F2. If both F1 and F2 are planar, we check whether normals of the two faces are opposite to each others, and if the difference between the position vectors of the two faces is orthogonal to the normals. Given n�1 and n�2 the normals of F1 and F2, and p�1 and p�2 their respective position vectors, the above-mentioned check can be stated as follows; n�1 . n�2 = −1 (p�1 − p�2) . n�2 = 0. In this case the two faces are reported as a potential planar contact. If F1 is cylindric while F2 is planar, we check whether the axis of the cylindric face is parallel to the planar surface, and that the distance between the axis and the plan is equal to the radius of the cylinder. Given a�1 the unit vector in the direction of the axis of the cylindric face F1, r1 its radius, n�2 the normal of the planar face F2, p�1 and p�2 the respective position vectors of F1 and F2, the above-mentioned check can be stated as follows; a�1 . n�2 = 0 (p�1 − p�2) . n�2 = r1. In this case the two faces are reported as a potential linear contact. If both F1 and F2 are cylindric, we check whether the two axes coincide. Given a�1 and a�2 the unit vectors in the directions of axes of F1 and F2 respectively, and p�1 and p�2 their respective position vectors, the abovementioned check can be stated as follows; |a�1 . a�2| = 1 |(p�1 − p�2) . a�2| = 1. In this case, and if the radii are equal r1 = r2 the two faces are reported as potential cylindric contact. If the radii are not equal, a further test of surface orientation is done. In this case, if the cylinder with smaller diameter is oriented inwards, while the other one is oriented outwards, the solids of the two faces are reported as potentially in cylindric interference2. It is worth noticing that the above-mentioned criterion only allows for the detection of cylindric interferences for which the axes of the cylindric faces at both sides of the interaction coincide. Although, other configurations can be envisaged where the condition of axes coincidence is relaxed to simple parallelism. In the latter case, an additional condition on the perpendicular distance d between the two axes with respect to cylinder radii should be introduced. More precisely, the distance between axes should be less than 2The inverse case, when the cylinder with smaller diameter is oriented outwards and the other one is oriented inwards would denote a potential clearance. However, clearances are not considered in the scope of this work.Geometric preparation and rapid detection of interactions 103 the sum of radii if partial, as well as complete, interferences are considered d < r1 + r2, and less than the difference of radii if only complete cylindric interferences are considered d < |r1 − r2|. The distance d can be calculated as follows; d = �(p�1 − p�2) − ((p�1 − p�2) · a�1) a�1�. Such a configuration does not reflect an interpretable functional intention. Nonetheless, it may be encountered in industrial models as a result of imprecise geometric representation to what otherwise would be a coaxial configuration. Even if the detection of such configuration is technically possible with a minimal cost, it poses, however, a problem of interpretation. Such a configuration is thus not considered in the actual work, and is left for future extensions. Combinations of other canonic faces such as spheres, cones and tori are also considered and studies, reporting candidates to circular and conic contacts. Up to this stage, geometric interaction filtering is implemented in the class BoundingBoxesGID (for Bounding Boxes Geometric Interaction Detector) in our code. Note however that this class signal all potential candidates, as discussed above, leaving the final decision to boolean operators, as discussed in Section 5.3. A major advantage of this technique is the order of magnitude drop in execution time it exhibits compared to mere boolean operators, as costly solid intersection calculation is avoided when not needed. Furthermore, results obtained by this method readily contain geometric characteristics of the interaction, such as axes and normals, that are used to define a local Cartesian coordinate system, as shown in Section 6.3.1. A drawback of this method is that it only detects interaction between surfaces that have a simple set of geometric characteristics; i.e. canonic surfaces. Contacts and interferences that involve free-form surfaces are not detected using this method, even if the opposite surface is canonic. However, in the context of this research, this is tolerated, and even favorable, given that we are only interested in functional surfaces, as shown in Section 5.1. 5.2.4 Local coordinate systems CIs are shipped with local coordinate systems that are particularly important when assigning physical properties to these interfaces. As Chapter 6 will unfold, dynamic and kinematic behaviours of a CI are expressed with respect to these local coordinate systems. The choice of a local coordinate system is thus not arbitrary. They are, in fact, orthogonal right-handed coordinate systems, conventionally defined3 in as much aligment as possible to geometric characteristics of the interface.104 Chapter 5. Functional Geometric Interaction To this end, coordinate axes are defined based on normals and axes of symmetry whenever available. As an example, for a rectilinear contact (such as the one between a cylinder and a plane shown in Figure 5.4b), the z-axis is defined along the surface normal, while the x-axis is defined by the contact line, the y-axis is then deduced using the right-hand rule, as the vector product of the x- and the z-axes. For planar contacts (shown in Figure 5.4a), only the z-axis is deterministically defined, while the x- and y-axes are left to lie on the contact plane. The choice of the coordinate system origin is also of important significance. In our work, this point is chosen to be the barycenter of the interaction zone, whether it is a curve, a surface or a volume. Figure 5.4 shows more examples of CIs geometries associated with their conventional coordinate systems. It is important to note that the choice of coordinate system is a matter of convention. What does really matter here is the coherence between conventions made at this stage, and those considered when assigning physical properties to the interface. For example, a simple planar contact delimits object translational motion along its normal, while leaving it free to translate parallel to its surface. By making a coherent choice of the local coordinate system, say the one shown on Figure 5.4, one can say that a planar contact eliminates object translational mobility along the positive direction of the z-axis of such a contact. 5.2.5 Conventional interface graph The outcome of this phase is represented as a graph referred to as conventional interface graph (CIG). This is a mathematical model upon which we build our reasoning in phases to come. Definition 5.1 (Conventional interface graph). The CIG is a directed graph G(C,I) that has the set of all components in an assembly C as its nodes, and the set of their CIs I as its edges. Initially, edges of the graph (i.e. CIs) contain information only about the geometric interaction between two nodes (i.e. two components), such as normals, axes, directions and radii, along with the interface local coordinate system transformation matrix with respect to the global coordinate system. Even though some CIs are geometrically and functionally symmetric, such as those resulting from a simple planar contact, the concept of CI is still asymmetric in general. A cylindric contact for instance generates a CI, we can clearly recognize the outer component from the inner one. This recognition can be made for many types of geometric configuration. CI asymmetry makes the CIG 3Conventions are made in the scope of this work.Geometric preparation and rapid detection of interactions 105 y x z y x z (a) Planar Contact (b) Rectilinear Contact y x z y x z (c) Circular Contact (d) Punctual Contact y x z y x z (e) Conic Contact (f) Cylindric Interference Figure 5.4: A set of conventional interfaces with their associated coordinate systems.106 Chapter 5. Functional Geometric Interaction C CI1: Cylindric Interference CI2: Planar Contact A B D CI3: Planar Contact CI4: Conic Contact Figure 5.5: A cross-section in a partial geometric model model of a capscrew and a nut tightening up two plates, showing detected CIs. a directed graph. Even when the geometric nature of the interface makes no distinction between the two components at each side, one of the two orientations is assumed to define the edge orientation in the CIG. We refer to the graph produced by ignoring edge orientations in CIG as the conventional interface underling undirected graph (CIuG). Figure 5.5 shows a cross-section in a model of two plates; A and B, tightened up together by means of a capscrew D and a nut C. It also shows CIs between components as represented in the DMU: a cylindric interference CI1between C and D, two planar contacts CI2 and CI3, between B and C and A and B, respectivly, and a conic contact CI4 between A and D. This information is initially unavailable in the input model; which is the DMU. Figure 5.6 shows the corresponding CIG, where components A, B, C, and D form the nodes, and interfaces CI1, CI2, CI3 and CI4 form the edges, after being detected. While classes Component and ConventionalInterface represent components and CIs respectivley, the CIG is represented by the class Conventional-Precise detection of interaction zones 107 C A CI1: Cylindric Interference Threaded Link Spline Link CI4: Conic Contact Conic Support Self-locking Fit D B CI2: Planar Contact Planar Support CI3: Planar Contact Planar Support Figure 5.6: The CIG of the model represented in Figure 5.5, enriched with functional interpretations, as a set of FIs assigned to each CI. Only relevant edge orientations (those reflecting asymetric geometric interface) are shown on the figure. InterfaceGraph in our implementation. 5.3 Precise detection of interaction zones The technique discussed in Section 5.2.3 is still approximate, it only filters out non-interacting canonic faces based on the comparison of the geometric parameters of their carrying surfaces. Faces that the previous phase reports are likely to interact, nonetheless, another measure is still needed to ensure real interaction. For example, two coaxial cylindric faces that share the same radius are reported as potential cylindric contact, though they may be afar along the axis and no actual contact takes place. Moreover, the simple approach developed above fails short to deliver accurate interaction zones. Even though this shortage can be easily overlooked for the inference process, precise contact and interference zones are108 Chapter 5. Functional Geometric Interaction still required for FEA purposes, as seen in Section 3.3.2. A confirmation stage is hence necessary to validate candidates reported by earlier stages, and to produce precise interaction zones for those that are indeed valid. To this end we use boolean operator applied to pairs of maximal surfaces in case of candidate contacts, and to solids in case of candidate interferences. In spite of their high cost, as mentioned in Section 5.2.3, boolean operators are used to obtain precise geometric zone necessary for further FEA treatment, hence, their cost are justified for positive candidates. Since this is a final verification phase, only small number of false positives survive the previous filters compared to the total number of candidates, minimizing the wasted time computing intersection between non-interacting solids. Candidates resulting from the canonical face comparison are thus validated using intersection operators, if the resulting shape is not empty, the interaction is considered valid, and a CI is created to represent it, adding an edge to the CIG. The newly created CI is associated to a local Cartesian coordinate system as shown in Section 6.3.1. To enable the referencing of precise interaction zones and their annotation with functional semantics, before the model is passed to applications such as FEA, the geometric model of a component is restructured according to those interaction zone. This makes the functional breakdown mentioned in Section 4.2.3 possible as soon as the semantic annotations are available. The OpenCascade software library [149] is used in our implementation to conduct boolean operators whenever needed. The class BooleanBBGID, a subclass of BoundingBoxesGID, implements the final precise detection of interaction zone in our code, overriding the method verifyInteractions(int, int) that constantly returns true in its superclass. 5.4 Form-functionality mapping Section 4.2.5 showed how functionality is satisfied as a direct result of geometric shape and physical material properties of components and their interfaces [118]. Given exact shape and material properties at both sides of an CI we can then deterministically deduce the functional role it plays in an assembly. However, this deduction is not readily possible in the DMU, because of the following reasons. Imperfect geometric representation Section 3.2 showed that the DMU geometrically represents the product through its constituent sub-assemblies and components at different levels of details. That means that many form simplifications may take place, leading to loss of geometric information. Those simplifications are influenced by some sort of conventions, either internal to one company, or agreed upon for a specific 3D models provider or library as mentioned in Section 4.2.5.Form-functionality mapping 109 Some simplification conventions may become a de facto standard, but there has never been a well-defined globally-recognized standardization of such conventions and notions, in contrary with many traditional 2D blueprints notions, as seen in . Incomplete material information A DMU may or may not have a BOM attached to it (see Section 1.7). When a BOM is available, it provides an indication of physical properties that contributes to the functionality of a component or an interface. Once again, this information not reliable, neither in terms of existence (a DMU is not guaranteed to have a BOM), nor in terms of meaningfulness (there is no standards governing what information a BOM should contain, and in which format). Because of this incomplete knowledge about shape and material properties in a DMU, the immediate deduction of functionality is not possible. However, assumptions can be made despite this incompleteness. Those assumption can then be reduced when the missing knowledge is reconstructed form existing one. In this work we only consider pure geometry. We thus assume that the the BOM is unavailable, or uninterpretable, which is the worse case. Assumptions about materials physical properties such as stiffness and adherence are discussed is Section 6.2 when reference states are introduced. 5.4.1 Multiple functional interpretation Considering geometric simplifications conventions observed in the industry, a limited number of assumptions can be made about the real shape when a specific geometric configuration is encountered in a DMU. Section 4.2.5 showed that different FIs, such as threaded links and spline links can be represented as simple cylindric interference in a DMU. Another example of the use of the same geometric interface for different functional meanings is a simple cylindric contact that can refer either to a snug or to a loose fit (see Figure 3.3). This allows us to link a given geometric interface, represented by a CI, to a set of functional interpretations, for each, an assumption is made about the real shape and physical properties of materials. Definition 5.2 (Functional interpretation). A function interpretation is the assignment of one FI to a CI. The assumption made for each interpretation provides the interface with a physical dimension, as developed in Section 6.3.1. More than one interpretation can be made per CI (see Figure 4.8), thus more than one independent physical and behavioral assumption.110 Chapter 5. Functional Geometric Interaction 5.5 Conclusions Our methods takes a pure geometric representation of a product as a set of solids representing components. In this work we adopt an ISO standard that represents the geometric model as a STEP-File [10]. The geometric analysis consists of detecting the geometric interaction between solids, those are contacts and interferences defined in Section 4.2.5. A preliminary approach would be to use geometric boolean operators, preceded by early elimination of negatives by means of bounding boxes checks. We are particularly interested in those interaction occurring between faces that are likely to connect components with a functional bound. Observation shows that those faces happen to lie on canonic surfaces. This observation allows us to optimize our detection algorithm, adding a secondary, relatively fast, elimination filter right after the bounding boxes check. Final validation and generation of interaction zones is still done by means of boolean operators, calculating intersection between potentially interacting elements. This method is able to efficiently detect geometric interactions between canonic surfaces. The intermediate filtering between bounding boxes check and boolean operators validation reduces the detection time by orders of magnitude. Geometric interactions of interest define CIs that link components together generating a directed graph called the CIG. Once CIs are geometrically recognized, they are provided a physical dimension through functional interpretations. Functional interpretations are assumptions about the functional intent of the interface, made in the light of its geometric properties in the DMU. As a result, each CI is interpreted into one or more FI. This imprecision is due to the lack of reliable information about exact geometry and materials physical properties. Checking the validity of those assumptions allows for the elimination of irrelevant interpretations. The elimination process is to be discussed in the following chapter.Chapter 6 Qualitative Behavioral Analysis of Components Functional Interactions The previous chapter has shown that component FI assignment can lead to multiple solutions due to shape simplifications between their real and digital shapes. The corresponding assumptions have used shape – function dependencies. To reduce the number of FI per CI to one, which is the real configuration, the purpose is now to refer to behaviors to filter out FIs. Because the input data is a purely geometric representation of a DMU, it is proposed to set up a qualitative approach to describe behaviors where it is possible to take advantage of the somewhat precise representation of components while reasoning qualitatively with physical parameters. Because this approach is qualitative, it is applicable to a wide range of stages in a PDP, up to early design stages where the physical parameters related to FIs and, more generally, to components, are no yet available. In this chapter, we demonstrate such an approach, defining referential behavioral states against which the validity of functional assumptions is checked to narrow down the number of possibilities to one functional interpretation per CI. This chapter is organized as follows: the concept of reference state and energy preserving hypotheses in assembly joints are presented in Section 6.2, then the qualitative representation of joint forces and velocity properties is introduced in Section 6.3 through the concepts of qualitative wrench and twist screws. Finally, the reasoning scheme to select appropriate functions for each CI, which is based on static equilibrium and statically indeterminate reference states, is presented in Section 6.4 and Section 6.5.112 Chapter 6. Qualitative Behavioral Analysis 6.1 Behavioral study to bind form to functionality The previous chapter showed how to build the CIG that reflects our initial knowledge about the assembly through a graph structure. Even when enriched with functional interpretations, this knowledge still shows functional uncertainty. Uncertainty in the knowledge base stems from the fact that some CIs hold more than one functional interpretation, thus, they cannot yet be mapped to a single FI. To reduce such uncertainty, additional rules and/or facts are to be taken into consideration, before being able to speculate about FDs and FCs of components and component groups. Since the geometric analysis is not sufficient by itself to lead to a decisive functional resolution, as shown in Section 5.4, the concept of mechanical behavior, as discussed in Section 2.3.1, is borrowed here to take advantage of the form–function–behavior dependencies to strengthen the relationship between geometry and functionality so that efficient decisions can be taken over FIs to reduce them to one per CI, wherever needed is the assembly input. Behavior can cover a wide spectrum of physical phenomena. In the scope of FE simulations, mechanical properties of components and their interactions, such as reciprocal forces between components taking place at each CI and force cycles tightening groups of components together are key elements that can be exploited to define behavioral models. Even though these mechanical properties are directly related to boundary conditions required by FE models, they are also of general interest. For example, reciprocal forces express whether a component can or cannot move with respect to its neighbors, which is also of interest in configurations of assembly or disassembly processes. Therefore, the concept of behavior and its qualitative approach can be seen as a generic tool that can be used to probe a DMU. 6.2 Reference states Reference states (RSs) reflect rules that apply to the domain of discourse. In this sense, RSs are domain knowledge, as introduced in Section 2.6.1. This knowledge may clarify ambiguity by reducing uncertainty in the knowledge base, e.g., reducing the number of functional interpretations per CI to ideally one. It also may produce certain new facts, such as the existence of a functional group that ties some subset of components. A RS is formally defined as follows. Definition 6.1 (Reference state). A reference state (RS) is characterized by a set of input and a set of output physical parameters applied to a subset of components of a DMU. This subset may cover the whole DMU and the DMU is processed as given in its input geometric setting. A physicalReference states 113 behavior, consistent with the input and output parameters set up and a set of hypotheses is associated with the DMU to express the corresponding physical phenomenon. This behavior is characterized by a set of equations that takes as input the set of input parameters characterizing the state and the geometric configuration of the DMU and produces as output the set of physical parameters characterizing this state. A reference state can match any specific state) of the product lifecycle, e.g., assembly process, working condition. This definition straightforwardly relates to the notion of function (see Section 2.2) that can be related to sets of input and output parameters of a product or sub-system. Here, the purpose is to characterize a RS with its input parameters, behavior equations, hypotheses and study the output parameters that will characterize functions at some CIs of some components. From the characterized functions, it will be possible then to confront them to the assigned FIs and discard some of them when inconsistencies appear, i.e., the function expressed by a FI differs from the function derived from the output of the state behavior. Indeed, the hypotheses and behavior equations are formed in terms of rules against which our knowledge about the DMU is checked, reducing uncertainty by refutation and producing facts by deduction. It has to be noticed that the principle of qualitative reasoning will explicitly, or implicitly, refer to relative physical values between components or products. Different RSs have been recognized, both static and kinematic. Only static RSs, namely static equilibrium (see Section 6.4), and static determinacy (see Section 6.5), have been implemented in the scope of this work, at a first step, even though others are discussed such as kinematic chains. Initially, all studied RSs consider components as rigid bodies, unless rigidness proves to be impossible, that is, no possible functional interpretation satisfies this hypothesis. Hypothesis 6.1 (Rigid bodies). Unless otherwise stated, components materials are assumed to be of high stiffness such that components are considered as rigid bodies, i.e., the loading conditions of a component do not alter its geometry. It is a common hypothesis for manufactured products where steel and other materials often lead to this hypothesis. It is also a common hypothesis used to define the boundary conditions of FE models prior to the use the deformation models expressed through the FE method. This allows us to safely apply rigid body statics and kinematics throughout our analysis. This means also that the geometry of the DMU can be used straightforwardly. Another common assumption that we make in default of any other clue is that connections between components of the assembly are ideal, thus frictionless. This can be generally formalized as follows.114 Chapter 6. Qualitative Behavioral Analysis Hypothesis 6.2 (Conservative systems). Unless otherwise stated, the set of components of the assembly forms an energy-conservative system. This hypothesis imply that contacts are frictionless, i.e., there is no tangential force between contact surfaces between any two components. We assume the state of contacts is not changing, i.e., a pair of solids having a planar support remain in contact. If not so, this means that the current RS is no valid and a switch to a new one must be operated. This allows us to safely alternate between kinematic and static properties of interfaces, knowing that no work is done when two components move as per DoF allowed by an FI, or when internal loads propagate from one component to another through an FI. Again, this is the default configuration often used during design processes. Friction, however, can be of function importance and, it this particular case, lead to specific models as it will appear later on. In the scope of this work, we only consider mechanical interactions between components in a product. This is because the recognition of other types of interactions, such as electromagnetic ones, require information beyond product geometry. Such information is not available in a DMU the way we consider it as an input to our analysis (see Section 1.11). Indeed, the objective of the proposed approach is to set up a process as automated as possible, in a first place. We state the aforementioned assumption as follows. Hypothesis 6.3 (Mechanical interactions). In the scope of this study, we consider forces internal to a product to be purely mechanical and generated by solid components. This allows us to ignore forces generated by electromagnetic fields, fluids, . . . and to be consistent with the assembly model effectively input, i.e., the geometry of each component is known but there is no explicit representation of fluid and gaz domains in a DMU. 6.3 Qualitative representation of physical properties In order to relate geometry to behavior, as a prerequisite to relate geometry to function, we need first to dress geometry in a DMU with physical properties. Properties of interest can either originate from statics, such as forces and torques1 or kinematics, such as linear and angular velocities. As long as functionality is concerned, this dressing should happen at the component interface level, i.e., the CI level, as it is the place from which 1A torque being the moment of a force vector about a given axis.Qualitative representation of physical properties 115 functionality actually emerges. Section 5.4.1 showed how a functional interpretation of a CI connects it to a geometrically possible FI, in the light of industrial common practices. In fact, physical behavior, such as static and kinematic properties of an interface, directly relates to function [72, 136], as shown in Section 2.3.1. Making a functional assumption about a CI, the way a functional interpretation does, allows us to cast a behavioral – thus physical– dimension on the interface, as will be shown in more details hereafter. Section 4.1 showed the motivation behind a purely qualitative approach. All studied physical attributes should thus support this requirement. In this section, we explain how static and kinematic properties can be expressed as qualitative values, before they are used to reason upon functional properties of components. We therefore provide our method with adequate data structures and their corresponding operations, arithmetics, and inference algorithms. Here, we promote an algorithmic approach since the concept of RS, the static and kinematic behaviors, are independent of a domain knowledge. 6.3.1 Qualitative physical dimension An FI is given a physical dimension by associating it with a characteristic wrench screw2 W = { �f|�t} representing force and torque applied through the corresponding FI from one component onto the other one where FI is defined. This assumption is possible in light of Hypothesis 6.1 and Poinsot’s theory [132] that states that any system of external force exerted on a rigid body can be resolved by one force, and a torque on a plane perpendicular to the force direction. The abstract class Screw represents a general screw as two vectors (objects of the class ScrewVector) in our data structure scheme. Values of force and torque vectors, however, are not scalars, as expected in a general dual vector, but qualitative symbols. These values decide in which direction, for a given vector component, a force or a torque may, or should, propagate. The following is a comprehensive list of nominal values that is used to this end. Not Null: indicates that the underling FI propagates internal force/torque in either orientation along the corresponding axis. Null: indicates that the underling FI does not propagate any internal force/torque along the corresponding axis. Strictly Positive: indicates that the underling FI propagates internal force/torque, in the positive direction only, along the corresponding axis. 2Refer to Appendix C for details on screws and their representation as dual vectors.116 Chapter 6. Qualitative Behavioral Analysis Table 6.1: Qualitative vector values Value Symbol Real interval Not Null � ] − ∞, 0[ ∪ ]0, +∞[ Null � [0, 0] Strictly Positive � ]0, +∞[ Strictly Negative � ] − ∞, 0[ Arbitrary � ] − ∞, +∞[ Strictly Negative: indicates that the underling FI propagates internal force/torque, in the negative direction only, along the corresponding axis. Arbitrary: indicates that the underling FI may or may not propagate internal force/torque, in either direction, along the corresponding axis. Each FI is associated to a specific geometric configuration. For instance: • spline and threaded links, and snug and loose fits, are associated geometrically with a couple of cylinders; • planar and circular supports can be associated with a couple of planes and a plane and a torus, respectively; • a linear support can be associated with a cylinder lying on a plane. This enables an FI to acquire a local coordinate system, the same way a CI does (see Figure 5.4). A wrench screw, defined as a dual qualitative vector of values of Table 6.1, is then expressed in this local coordinate system and attached to the FI. As a subclass of Screw, the class RelativeScrew represents qualitative dual vectors expressed in a local coordinate system in our application. When a FI is processed, its local coordinate system is aligned with the local coordinate system of its underlying CI, which is in turn defined under the global coordinate system of the assembly. This allows the behavior model to locate the qualitative wrench screw globally with respect to the DMU. Wrench and twist screws assigned to a planar support When a planar support, an FI, is associated with a planar contact, a CI, through a functional interpretation, the corresponding interface refers to two components C1 and C2. Let us consider that C1 is chosen as reference component and CI is characterized by its imprint on its surface. Then, aQualitative representation of physical properties 117 local coordinate system is assumed to have its z-axis coinciding with the contact plane normal, and its origin O� at the barycenter of CI, as shown in Figure 5.4a. C1 being chosen as reference, we then observe that for an ideal, frictionless, planar support, as suggested by Hypothesis 6.2, all infinitesimal external forces that may be exerted by C2 on C1 through CI are normal to the plane, thus parallel to the z-axis of the interface local coordinate system. A force can then be expressed in the local coordinate system as d �f = (0, 0, dfz) where dfz < 0 is the force per infinitesimal area of CI. Hence, the vector representing the sum of these infinitesimal forces is of the form: �f = (0, 0, fz) where fz < 0. (6.1) To compute the moment vector of �f about the origin O� = (0, 0, 0), we note that d �f produces a moment of the form: d�t = (P� − O� ) × d �f, where P� = (x, y, 0) is the position vector where d �f applies in CI, and × is the vector cross product operator. d�t = (P� − O� ) × d �f, = (x, y, 0) × (0, 0, dfz), = (y dfz, −x dfz, 0) , = (dtx, dty, 0) We observe then that the sum of these infinitesimal torques about O is of the form: �t(x0,y0,z0) = (tx, ty, 0). (6.2) In fact, Equations 6.1 and 6.2 can be expressed by means of a wrench screw W1 using nominal values of Table 6.1. W1 =    � � � � � �    (6.3) This physical understanding of a functional interface leads to the same result if the phenomenon is studied from a pure kinematic perspective. In the case of planar support, we define FI by its twist screw T1 that represents the relative velocity (vx, vy, vz) and relative rotational speed (wx, wy, wz) vectors between C1 and C2 as: T1 = {w�|�v} =    0 vx 0 vy wz 0    . (6.4) This kinematic standpoint can be also regarded from a functional perspective since T1 expresses the relative movements between C1 and C2 when their contact is preserved.118 Chapter 6. Qualitative Behavioral Analysis Definition C.2 states that a pair of wrench screw and twist screw is reciprocal when the virtual work of the wrench on the twist equals zero. This can be stated as follows: dW = 0 (W � T)dt = 0 W � T = 0 { �f|m� } � {�ω|�v} = 0 �f · �v + m� · �ω = 0. (6.5) In the context of this thesis, the component interfaces conform to Hypothesis 6.2 by default. Hence, contacts are frictionless and are neither power generators nor consumers, meaning that the wrench and twist screws are reciprocal [133]3. We thus obtain the following wrench screw of a planar support, that, along with twist screw T1, satisfies Equation 6.5: W1 =    0 tx 0 ty fz 0    (6.6) Now considering the unilateral geometric configurations of FI, it is necessary to add the condition fz < 0 to Equation 6.6. We then can express W1 using qualitative values as shown in Equation 6.3. Screws applied to cylindric contacts Another example is a loose fit between C1 and C2, which is associated to a cylindric contact through a functional interpretation. In this case, we define the local coordinate system to lay its z-axis on the cylinder axis, while the origin of coordinates O� coincides with the same axis at barycentric position of the CI. Then, we observe that all infinitesimal external forces are radial, i.e., normal to the contact surface on C1, in an ideal, frictionless support, as suggested by Hypothesis 6.2. The vector representing the force applied by C2 on C1 over a cylindric support is then of the form: d �f = (dfx, dfy, 0) (6.7) where the z-axis coincides with the cylinder axis. The moment, at point O, of an infinitesimal force d �f = (dfx, dfy, 0) is given by the equation d�t = (P� − O� ) × d �f, where O� = (0, 0, 0) is the 3We actually consider a screw space here, i.e., a space of all screws generated by linear combinations of one screw of the given form, instead of a single screw, and its reciprocal screw space. We, however, stick to the term screw in the rest of the document for the sake of simplicity.Qualitative representation of physical properties 119 z y x Figure 6.1: Vectors of position P� (axial, Q� , and radial, R� , components), force, F� , and torque �t of a cylindric support, represented in the local coordinate system of a cylindric contact. origin of the local coordinate system in use, and P� is the position where the infinitesimal force applies. P� can be decomposed into two components; the axial component Q� = (0, 0, z), and the radial component R� = (x, y, 0), we note that x . dfy = y . dfx since the infinitesimal force applies at P� (see Figure 6.1). d�t = (P� − O� ) × d �f, , = (Q� + R� ) × d �f, = Q� × d �f + R� × d �f, = (0, 0, z) × (dfx, dfy, 0) + (x, y, 0) × (dfx, dfy, 0), = (0, 0, z) × (dfx, dfy, 0) +�0, = (dtx, dty, 0). The sum of such infinitesimal torques about the origin O, is then of the form: �t(x0,y0,z0) = (tx, ty, 0). (6.8) Again, Equations 6.7 and 6.8 can be qualitatively expressed by means of a wrench screw W2: W2 =    � � � � � �    . (6.9)120 Chapter 6. Qualitative Behavioral Analysis From a kinematic standpoint, a loose fit can be defined by its twist screw as follows: T2 =    0 0 0 0 wz vz    . (6.10) T2 can be also interpreted from a functional perspective where vz and wz are the output parameters that express the relative movements of C2 with respect to C1. Taking the reciprocal screw of T2, we obtain the wrench screw of this FI: W2 =    fx tx fy ty 0 0    . (6.11) Using qualitative values of Table 6.1, we obtain the same wrench screw as in Equation 6.9, showing that no other condition needs to be added to describe a loose fit. Qualitative wrench screws applied to contacts In an analogous manner, a qualitative wrench screw is assigned to each FI. Table 6.2 shows examples of FIs, and their associated qualitative wrench screws deduced using the same reasoning as mentioned above. Screws shown in the table are to be interpreted in the local coordinate systems of the corresponding CIs, as shown in Figure 5.4. Here, it is important to note that not all the FIs conform to Hypothesis 6.2. From a functional point of view, it is necessary to consider configurations where adherence between C1 and C2 plays a central role. This can be observed when comparing the loose fit a the snug fit. Independently, of the materials of C1 and C2 and of the diameter differences between C1 and C2, the design principle of this fitting is to resist to components fz and tz under working conditions of a product. This justifies the content of W and T compared to the loose fit. This observation is critical since, the qualitative screws of the snug fit differ from that of the loose fit whereas their CI is identical, i.e., in the assembly model the conventional representations of these FIs are identical (see Chapters 4 and 5). Though this is not detailed for sake of conciseness, a similar analysis applies to the conical support and self-locking fit where adherence is also of functional effect though it is combined, in this case, with the apex angle of the cone. This angle is a geometric parameter that influences the adherence effect of the conical fit. This could hinder the qualitative approach but the purpose is not to evaluate a design configuration, it is the analysis a valid ones. Consequently, a first approach can be the categorization of apex angles from a functional point of view. In this case, apex angles can be categorizedQualitative representation of physical properties 121 efficiently into conical support and self-locking fit using an angle threshold because this adherence phenomenon varies slowly with respect to the apex angle and is rather insensitive with respect to the categories of constitutive materials of C1 and C2. This approach, however, is not the most generic one. A second one consists in dropping the reference to the apex angle, i.e., to geometry and refer to a specific physical behavior. This is the solution described here at Section 6.5.1. 6.3.2 Algebraic structure of qualitative values To enable the use of qualitative screws against static equilibrium equations, certain arithmetic has to be defined on qualitative values represented in Table 6.1. Notably, the addition (+) and multiplication (.) operators. The semantics of these operators is defined through interval arithmetic [59], where each qualitative values represent real intervals as Table 6.1 shows. Given K and L ∈ [R], a set of real intervals, an interval operator � : [R] 2 → [R] is defined as the interval extension of the real operator � : R2 → R as follows [59]: K � L = {z|∃(x, y) ∈ K × L, z = x � y}. (6.12) To this end, we define addition and multiplication operators on the set of qualitative values Q = {�, �, �, �, �} as an extension of real addition and multiplication, by replacing K and L in Equation 6.12 by the interval each value represents. We obtain the Cayley tables shown in Table 6.3. Studying addition (+) in Table 6.3, we observe that: • addition is closed on Q, i.e., all table cells are included in the entries; • addition is associative, i.e., this can be established using Light’s algorithm [97]); • addition has an identity element �, i.e., its raw and column match the entries; • addition is commutative, i.e., the table is symmetric. We establish then, that (Q, +) is a commutative monoid. Now, studying product (.) in Table 6.3, we observe that: • product is closed on Q, i.e., all table cells are included in the entries; • product is associative, i.e., this can be established using Light’s algorithm; • production is commutative, i.e., the table is symmetric.122 Chapter 6. Qualitative Behavioral Analysis Table 6.2: Different FIs and the CIs they originate from. Each FI is given a physical dimension using a qualitative wrench screw W and a qualitative twist screw T, defining its static and kinematic behaviors, respectively. Screws are expressed in the local coordinate system of the corresponding CI (see Figure 5.4). FI W T CI(s) Threaded Link    � � � � � �       � � � � � �    Cylindric Interference Planar Support    � � � � � �       � � � � � �    Planar Contact Spline Link    � � � � � �       � � � � � �    Cylindric Interference Snug Fit    � � � � � �       � � � � � �    Cylindric Contact Loose Fit    � � � � � �       � � � � � �    Cylindric Contact Linear Support    � � � � � �       � � � � � �    Rectilinear Contact Circular Lateral Support    � � � � � �       � � � � � �    Circular Contact Circular Axial Support    � � � � � �       � � � � � �    Circular Contact Conical Support    � � � � � �       � � � � � �    Conical Contact Self-locking Fit    � � � � � �       � � � � � �    Conical ContactQualitative representation of physical properties 123 Table 6.3: Addition (+) and production (.) Cayley tables over qualitative vector values. + � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � . � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � We establish then that (Q, .) is a commutative semi-group [98]. It can be shown, on a case-by-case basis, that product is distributive over addition, we thus infer that (Q, +, .) is a semi-ring [98], which is commutative with � as identity. We also observe that: ∀p, q ∈ Q, p+q = � =⇒ p = � ∧ q = �; ∀p, q ∈ Q, p . q = � =⇒ p = � ∨ q = �. It follows that (Q, +, .) is a semi-field [98]. Qualitative values and their arithmetic are defined through the class ScrewValue in our software application. The class also implements multiplication between real scalars and qualitative values using interval arithmetic again. A scalar x is replaced by its singleton interval equivalent [x, x] in this case. 6.3.3 Coordinate systems alignment Wrench and twist screws are expressed in the local coordinate systems of their corresponding FI by means of dual vectors which are referred to as local dual vectors. Each local dual vector (an object of class RelativeScrew in our implementation) has its own Cartesian coordinate system in 3D. When dual vectors are added, subtracted or multiplied, they must be expressed in the same coordinate system, i.e., same reference frame and same origin. Unless all dual vectors share the same coordinate system, a coordinate-system alignment is thus necessary whenever dual vectors are summed. Given a dual vector S = {�v|m� } represented in a Cartesian coordinate system (o, e�x, e�y, e�z), we represent S as {�v� |m� � } in a new Cartesian coordinate system (o, e�x � , e�y � , e�z � ). We note that: �v� = Ω × �v, m� � = Ω × m, � (6.13)124 Chapter 6. Qualitative Behavioral Analysis where Ω is the rotation matrix of �v and m� in the new coordinate system: Ω =   e�x � .e�x e�x � .e�y e�x � .e�z e�y � .e�x e�y � .e�y e�y � .e�z e�z � .e�x e�z � .e�y e�z � .e�z   . If the two local coordinate systems share the same axes, but not the same origin, it means that the underling wrench or twist screws do not share the same point of application. Given a dual vector S = {�v|m� } represented in a Cartesian coordinate system (o, e�x, e�y, e�z), we represent S as {�v� |m� � } in a new Cartesian coordinate system (o� , e�x, e�y, e�z). We note that: �v� = �v m� � = m� + � λ × �v, (6.14) where � λ is the translation vector starting at o� and ending at o, � λ = −→ o� o. Now when neither axes are aligned nor the origin is shared between the new and the current Cartesian coordinate systems, we first apply Equation 6.13, then Equation 6.14 to obtain a dual vector expressed in the new coordinate system. These operators are implemented by the method changeBasis(gp Ax2) of the class RelativeScrew in our software. 6.4 Reference state I: Static equilibrium Static mechanical equilibrium RS builds on the fundamental law of dynamics (Newton’s second law), assuming that all components are at rest. Hypothesis 6.4 (Static equilibrium). Components of an assembly are at static equilibrium. This means that mechanical equilibrium equations hold on each component. More precisely, components in a DMU should not fall apart either when the assembly is at rest state or in working conditions. This is equivalent to consider that every component should not be free to move along any translational movement, which can allow it to fall apart. A component however, can rotate freely because a rotational movement cannot separate a component from its assembly. Because of these observations, this RS can be applied to a very wide range of DMUs. Those equations extend our knowledge about the DMU that is built on its pure geometry model so far. They thus allow the qualitative analysis to proceed with farther reasoning, particularly, the reduction of the number of FIs. The mechanical system studied is reduced to a standalone component and its equilibrium is studied under the actions of its neighboring components onto it.Reference state I: Static equilibrium 125 6.4.1 Static equilibrium equations A rigid body, i.e., an assembly component, is at mechanical equilibrium if and only if it satisfies the following conditions: 1. The vector sum of all external forces applied to this rigid body is zero; 2. The vector sum of all external torques applied to this rigid body is zero around any given axis. Since CIs encapsulate all geometric interactions of a component, all mechanical forces are applied through these interfaces. In the light of Hypothesis 6.3, we can thus state that all forces external to a component are applied through its CIs. Let IC be the set of all CIs of a component C. Given �fi the force vector and t �i the torque vector that represent the resultants of external forces applied to C [132] through its i th interface by its i th neighboring component, i ∈ IC. �fi and t �i are the components of a wrench screw Wi = {�fi|t �i} applied to C at its i th CI, i ∈ IC, then the static mechanical equilibrium of C is obtained when all such wrench screws sum up to zero {�0| �0}: � i ∈ IC {�fi|t �i} = {�0| �0}. (6.15) Hence, the goal of the static equilibrium RS, is to check functional interpretations, FIs, associated to each CI against equation 6.15. This means that more than one wrench screw Wi, i.e., more than one FI, may exists per CI and it is the purpose of the behavior expressed by the static equilibrium RS to provide the qualitative analysis with output parameters that express the behavior of C with respect to this state. Checking a FI ends up verifying if C can reach a static equilibrium state. Summation (addition or subtraction) can only take places on wrench screws sharing the same coordinate system. In our implementation, summation of two dual vectors generate a third one expressed under the local coordinate system of the first operands, where a copy of the second operand undergo a coordinate system alignment, as explained in Section 6.3.3, before being summed up. This functionality is implemented by methods add(Screw) and subtract(Screw) of the class RelativeScrew. Scaling (multiplication by a scalar) is also defined on qualitative dual vectors by the method scale(), which accepts either a real scale(float) or a qualitative value scale(ScrewValue) as a parameter. 6.4.2 Graph search to eliminate irrelevant FIs An exhaustive search algorithm that returns all valid solutions of a system, eliminating invalid functional interpretations for each CI, is presented in126 Chapter 6. Qualitative Behavioral Analysis this section. A valid solution is a set of interpretations, that is a set of FIs, that satisfy static mechanical equilibrium RS for a given CI. Algorithm 1 sketches the outlines of such an approach. Algorithm 1 Mechanical analysis Procedure: analyze for each component c do mark c as OPEN end for while there is still a component marked as OPEN do c ← nextOpenComponent() initScrew ← {(�, �, �)|(�, �, �)} mark all FIs of all CIs of c as invalid calculateSum(c, 0, 0, initScrew) for all invalid FIs: f i do ci ← CI of f i other ← opposite component of ci mark other as OPEN drop f i from possible interpretations of ci end for if Q(c) didn’t change then mark c as CLOSED end if end while Procedure: calculateSum(c, level, i, base) if base = {(�, �, �)|(�, �, �)} then mark all visited FIs as valid mark all FIs yet to be visited from here as valid else if level = |I∗ c | then if isNullable(base) = true then mark all visited interpretations as valid end if else ci ← level-th element of I∗ c for i = 0 to number of interpretation of ci do f i ← i-th interpretation of ci screw ← base + f i.screw calculateSum(c, level + 1, i, screw) end for end if end if This algorithm traverses the CIG through procedure analyze(), visitingReference state I: Static equilibrium 127 each node at least once, to study the component equilibrium against Equation 6.15. All nodes of the CIG are initially marked as open, i.e., they are still to be visited. Though the RS described at Section 6.4.1 applies to a unique component, Algorithm 1 traverses the entire assembly model because the RS is applied individually to each component of a DMU. The function nextOpenComponent() returns the next component to visit. This is the open component with maximum certainty. The certainty of a component c ∈ C is defined as the reciprocal (multiplicative inverse) of the product of the number of interpretations over functionally-valid FIs of the component: Q(c) =  � i∈I∗ c |i|   −1 , (6.16) where |i| is the number of functional interpretations of the interface i, i.e., the number of associated FIs, and I∗ c is the set of CIs involving c for which there exists at least one functional interpretation (see Section 6.4.3). If two components happen to have the same certainty, the one with the smallest |I∗ c | is chosen. This heuristic picks components with higher entropy, thus higher potential to introduce new information, therefore enhancing algorithm convergence time. For the sake of efficiency, certainty is initially calculated and stored in terms of its reciprocal for each component. Certainty is only updated component-wise when a functional interpretation reduction occurs to one of its CI. Comparing certainties reduces to comparing their stored reciprocal, that are integers. Component equilibrium is studied through procedure calculateSum(). Before the call to this procedure, all possible functional interpretations are marked as invalid. Procedure calculateSum() marks an interpretation as valid if it participates to a solution that satisfies Equation 6.15, as will be explained shortly. After the call, all interpretations that are still invalid clearly contradict the mechanical equilibrium RS, thus they are eliminated. If the call to calculateSum() leads to the elimination of at least one interpretation, not only the state of the current component is preserved as open, also the opposite component of the eliminated interpretation interface is marked as open as well, even if it was closed before. This is because the removal of one functional interpretation of a CI introduces new knowledge that may in turn allow for new conclusions if equilibrium equations are checked again against the involved component. If no functional interpretation is removed, this means that further reasoning on the component is meaningless, since it will lead to the same result (unless this fact is changed, by reducing the number of interpretations again through the reasoning on a neighboring component, see the previous paragraph), and the component then is marked as closed.128 Chapter 6. Qualitative Behavioral Analysis The procedure calculateSum() traverses each FI of component CIs recursively, through a depth first graph search, where each CI represents a level in the search tree. The search combines solutions at each node and checks their validity against Equation 6.15 at leaf level. This is done through the accumulation of wrench screws, where the wrench screw of the currently visited FI is added to a sum. The sum is eventually checked whether it is nullable or not; that is, whether or not Equation 6.15 may hold true. A nullable qualitative dual vector has all its values in Q0 = {�, �}. As mentioned at the beginning of Section 6.4 when stating more precisely the concept of static equilibrium of components used to filter out some FIs, a component able to rotate only cannot fall apart. Consequently, its strict static equilibrium equations that end up with: Q0 = {�, �} (see Equation 6.15) can be relaxed into a weaker form: Q0 = {�, �, �, �, �}, that authorizes the component to rotate but not to translate. If the resulting wrench screw is indeed nullable, all visited functional interpretations are marked as valid. To enable this backtracking, a record of visited interpretations is kept. This bookkeeping is not mentioned in the outlines of Algorithm 1 for the sake of simplicity. An enhancement is introduced to the algorithm by the early determination of valid solutions when the sum of wrench screws related to component c represents a rigid link, that is, it equals the qualitative dual vector {(�, �, �)|(�, �, �)} stating that c cannot move with respect to its neighboring components. In this case, summation will always lead to the same wrench screw, which is indeed nullable. Therefore, the recursion is interrupted, and interpretations still to be unfolded from this point, besides those already visited, are marked as valid, as the algorithm shows. This enhancement is justified by the fact that a fair amount of components in an assembly are generating such rigid links, e.g., screws, nuts. Consequently, their specific processing speeds up the overall treatment of an assembly. At each iteration in procedure analyze(), calculateSum() is called, after which either a component is closed or at least one functional interpretation is dropped. A component can only be reopened at the expense of one dropped functional interpretation. Since the number of components is bound in a DMU, and so is the number of functional interpretations, the algorithm is guaranteed to terminate in finite time, given that calculateSum() does. Note that the number of functional interpretations is only a theoretical upper bound to the number of iterations, since only a limited number of functional interpretations are actually dropped from a given CIG. Procedure calculateSum() is a breadth-first traversal algorithm, that runs in O( � I |i|) time in the worst case. This complexity however, is significantly reduced by early determination of rigid links. Algorithm 1 is implemented by the method analyseInterpretations() of the class ExhaustiveMechanicalAnalyser.Reference state I: Static equilibrium 129 6.4.3 Local failure of functional interpretation A component fails to be functionally interpreted when no valid functional solution is found by Algorithm 1 for that component under assumed hypotheses. This occurs either when friction is involved (Hypothesis 6.2 does not hold) or when the model is not consistent (Hypothesis 6.4 does not hold, and components are likely to fall apart). In either case, the corresponding component is signaled to the user as a potential inconsistency. A failure in case of inconsistency related to the friction hypothesis can effectively occur when components are touching each other along planar faces in the assembly model and no other information is available. Back to the concept of conventional representation, this can refer to configurations where the corresponding CI is not a FI of type planar support but should be interpreted as a glued link or a weld. Though this type of FI has not been mentioned in Chapter 4 and Chapter 5, DMUs often represent welds and glued links as contact configurations. Processing efficiently these configurations is left for future work. Similarly, if the failure reflects a assembly model inconsistency, this is not in the scope of the present approach and is part of future work. As a result, all functional interpretations of all CIs of the component are dropped. The set I∗ c reduces to the empty set in this case, and the uncertainty of the component is assumed zero. To avoid a cascading collapse in which a failure to interpret component CIs propagates to neighboring components, resulting in a failure to interpret them as well, an so on across the assembly model, graceful failure measures are inserted into the algorithm. This is obtained by virtually dropping defective CIs, introducing I∗ ⊆ I, the set of functionally-yet-valid CIs; that is the set of CIs for which at least one functional interpretation exists. This fault tolerant approach prevents a local inconsistency from hindering reasoning elsewhere across the DMU. 6.4.4 Graph search example In this section we show a simple example that demonstrates the abovementioned algorithm. The same principles also apply on more complex and complete assembly models. We build on the example of the capscrew-nut assembly shown in Figure 5.5. Only the CIG of the model is passed as input to Algorithm 1, enriched with functional interpretations as shown in Figure 5.6. Since the model is partial, and for the sake of conciseness, we only demonstrate here the execution of the algorithm on one component; that is C. Initially, components C and D are open. We know that the algorithm picks component C first, as its certainty, Q(C) = (|CI1| × |CI2|) −1 = 1/(2 × 1) = 1/2130 Chapter 6. Qualitative Behavioral Analysis is the highest one in the assembly. For example, the certainty of component D, G(D) = (|CI1| × |CI4|) −1 = 1/(2 × 2) = 1/4 is lower than that of C. Figure 6.2 shows the complete search tree that procedure analyze() of Algorithm 1 traverses to find valid solutions. The figure shows that at each level of the tree; that is a functionally-yet-valid CI of the component, two things happen: • Firstly, the search tree forks in as many branches as remaining functional interpretations of CI; • Secondly, and for each branch, the wrench screw of the FI of the corresponding functional interpretation is added qualitatively to the wrench screw sum. At the leaf level, and when no more CIs are to be visited, the wrench screw sum is checked for ‘nullifiability’. The example shows two paths, the first one led to the wrench screw {(�, �, �)|(�, �, �)} produced by the FI spline link. This solution path is rejected because of the existence of the strictly negative qualitative value �, that cannot be nullified, contradicting Hypothesis 6.4. From a technological point of view, this is consistent because replacing the screw thread by a spline link would let the component D fall apart, as well as C. The second solution path led to the wrench screw {(�, �, �)|(�, �, �)}. This solution is acceptable, as all values of the wrench screw are nullable, satisfying the mechanical equilibrium RS. Consequently, all functional interpretations along the way to this valid solution are marked as valid. Namely, CI1 as a threaded link and CI2 as a planar support. As the functional interpretation of CI1 as a spline link did not appear in any valid solution, it remains marked as invalid, and thus is eliminated. Certainty of component C is then updated to its new value Q(C) = 1, which ends the algorithm in the present case. 6.5 Reference state II: Static determinacy The first RS leads to the reduction of the number of functional interfaces, eliminating geometrically suggested solutions that are mechanically invalid. This is a first illustration of a qualitative behavior analysis that is coupled to geometry, i.e., the shape of CIs, and functions, i.e., the FIs associated with CIs, to exploit the dependencies between form – function – behavior and robustly enrich a DMU with functional information at the level of component interfaces.Reference state II: Static determinacy 131 or and Start and Spline Link and Threaded Link or or and Planar Support and Planar Support Cylindric Interference Planar Contact Planar Contact CI1 CI2 ΣW= ΣW= ΣW= ΣW= ΣW= + + + + Figure 6.2: The search tree visited by Algorithm 1 in order to check the static equilibrium validity of FI of CI of component C shown in Figure 5.5. The tree shows two paths, one leading to a nullable qualitative dual vector, i.e., a valid solution, and the other one leads to a non-nullable qualitative dual vector, i.e., an invalid solution. This leads to the elimination of the function interpretation binding interface CI1 with the FI spline link. However, this elimination does not always lead to a one-to-one mapping between CIs and FIs, as for some configurations, more than one solution actually satisfies mechanical equilibrium, thus RS I. To demonstrate such a configuration, we consider the example of a bolted assembly shown in Figure 5.5 with a conical head capscrew as component D on which we now focus. We recall that this functional knowledge about components, i.e., the ‘component names’, and component groups, i.e., the concept of bolted assembly, is not yet available at this stage of reasoning. Section 6.4.4 showed how Algorithm 1 runs on component C of this bolted assembly where C features a ‘planar support’ rather than a conical one, successfully reducing the number of valid solutions to one, thus setting the number of FI per CI to exactly one for C. Interfaces CI1 and CI2 are said to be definitively interpreted.132 Chapter 6. Qualitative Behavioral Analysis or and Start and Self-lock and Conical Supprot or or and Threaded Link and Threaded Link Conical Contact Interference Interference CI4 CI1 ΣW= ΣW= ΣW= ΣW= ΣW= + + + + Figure 6.3: The search tree visited by Algorithm 1 in order to check the static validity of FIs of CIs of component D shown in Figure 5.5. The tree shows that all leaves, two in this case, leads to a nullable qualitative dual vector, thus a statically valid solution. No functional interpretation is eliminated in this case. Now, considering the equilibrium of component D in accordance with Algorithm 1, we first note that only two solutions are left after the elimination of the interpretation of CI1 as a spline link. The remaining solutions are: • Interpreting CI1 as a threaded link, and CI4 as a conical support; • Interpreting CI1 as a threaded link, and CI4 as a self-locking link. As shown in Figure 6.3, both remaining solutions are indeed statically valid. The execution of procedure analyze() leads to no reduction in number of functional interpretations, thus no change in components uncertainty H(D). Consequently, component D is closed, and will remain this way until the algorithm converges and returns.Reference state II: Static determinacy 133 This uncertainty prevents us form attributing functional properties to geometric elements in a decisive manner. The problem stems from the existence of more than one valid solution, even though solution are not equally relevant. A mechanism should thus be established to evaluable the relevance of a valid solution. If such a mechanism existed, discouraged, e.g., unnecessarily costly, solutions can be further rejected in favor of more convenient ones. 6.5.1 Statically indeterminate configurations A close study of the example illustrated above shows that the two remaining solutions differ from each other in a discriminant way. Although both of them are statically valid, as the Algorithm 1 proves, the first solution is isostatic, or statically determinate, while the second one is hyperstatic, or statically indeterminate [123]. A statically indeterminate system can be characterized as follows (see Figure 6.4). This example shows a horizontal cantilevered beam at point A and its opposite extremity B leans on a rigid contact. Now, considering the static equilibrium equations of the beam that reduces to a simple planar problem, it comes, in the reference frame (A, �x, �y): fAx = 0, (6.17) fAy + fBy − F = 0, (6.18) tA + LfBy − L 2 F = 0, (6.19) where the wrench screw at point A is defined by {fAx, fAy|tA} and with {0, fBy|0} at point B, L is the length of the beam, and F is an external force. It appears that this equation system is under determined, i.e., there are three unknowns and two equations. From a mechanical point of view, this system is said statically indeterminate of order 1. Such a configuration is classical in strength of materials and the approach commonly used to find a solution is to refer to the deformation behavior of the beam. Indeed, the bending behavior of the beam brings one more independent equation that can be used to solve the system. From a mechanical point of view, it means that the internal energy of the beam, i.e., its strain energy, contributes to the wrench screws at the interfaces A and B of the beam. Now, coming back to the example of Figure 5.5 and the two alternatives of FIs that can be assigned to the conical contact of D, they differ from each other by the adherence effect that takes place with the self-locking fit when the cone apex angle is small (see Section 6.3.1). In this case, the adherence and compression of the conical component is able to develop an axial force, opposite to an external one, hence the designation self-locking fit.134 Chapter 6. Qualitative Behavioral Analysis Figure 6.4: An example of statically indeterminate mechanical system with one parameter. In the first solution of component D, i.e., conical support, and in the only solution of component C, each and every interface participates to the equilibrium of D. Dropping one interface would render the component invalid statically since the conical support does not incorporate any friction effect. This makes these solutions statically minimal, or determinate. In contrast, the second solution of component D, i.e., self-locking fit, is redundant in the sense that not every interface is strictly necessary to the equilibrium. In fact, a self-locking link is enough on its own to maintain the component D along the z-axis. Subsequently, a threaded link acting along the same axis with the same orientation as the self-locking fit increases the internal energy of this simple mechanical system while not being strictly necessary to the static equilibrium of D. This makes this second solution statically redundant, or indeterminate. Geometrically, this second solution is only valid for small cone apex angles. Because of this redundancy, statically indeterminate configurations are avoidably expensive. They are thus uncommon in industrial products if not strictly necessary, e.g., in Figure 6.4, the rigid contact added at point B reduces the displacement of the beam at the point where F is applied compared to the displacement at the same point if the beam was cantilevered only. Here, adding the rigid contact increases the stiffness of the beam but adding this contact requires more components than the solution with a simple cantilevered beam, hence this solution is more complex to set up. However, a designer may resort to deliberately introduce statically indeterminate mechanism to convey certain functionality, such as reinforced fastening. This leads to the following hypothesis. Hypothesis 6.5 (Static determinacy). Unless functionally justified, statically indeterminate structures are disfavored in a product assembly.Reference state II: Static determinacy 135 Consequently, the self-locking fit of Figure 5.5 is filtered out. It has to be pointed out that this filtering criterion is generic, hence it is independent of any threshold value, e.g., the cone apex angle threshold mentioned at Section 6.3.1. More generally, Figure 6.5 shows examples of two plates assembled together by means of fasteners. Their assembly can be achieved through statically determinate structures, using one or two threaded links (see Figure 6.5a, b). Fastening can be secured through a statically indeterminate configuration with an additional locking nut, where static indeterminacy plays a functional role (see Figure 6.5c). Finally, Figure 6.5d shows a nonfunctional statically indeterminate configuration, if the cylindric contact is to be interpreted as a snug fit. The latter interpretation exhibits functional inconsistency and should be avoided in industrial products. Hypothesis 6.5 provides the necessary criterion against which statically valid solutions that survived RS I can be filtered out. In fact, statically indeterminate configurations could have been recognized during the evaluation of mechanical equilibrium in Algorithm 1. For example, a statically indeterminate solution could have been identified while wrench screws are summed, when a nullable qualitative value, i.e., � or �, is added to another qualitative value rather than zero �. Accordingly, undesired statically indeterminate solution could have been eliminated since the first round. However, some of statically indeterminate configurations constitute the only possible static solution of a component. In this case, the static indeterminate configuration is functional. Such a solution should not be eliminated when it is unique, however, whenever there is a functional interpretation conflict, a statically determinate solution prevails. Consequently, statically indeterminate solution necessity cannot be judged component-wise. Since if a statically indeterminate solution is found unnecessary, as it has a statically determinate alternative for a given component, all functional interpretations participating to the solution would not be validated, thus are likely to be dropped (unless they participate to one of the statically determinate solutions). This elimination, however, may affect the propagation of equilibrium on neighboring components. The static validity of model should thus be checked independently from its static determinacy. For this reason, the ‘pruning’ of the solution tree must occur after reasoning on the RS I is done, where all components playing a role in a statically indeterminate structure are studied at once. If a solution is to be eliminated, another statically determinate solution should be ensured for the whole structure. This analysis shows that RS II can be regarded as a reference state independent of RS I and must be applied after RS I. This requires the study of internal forces propagation paths. In fact, statically indeterminate structures are characterized by a cyclic force propagation along one or more axis, e.g. in case of the example in Figure 6.4,136 Chapter 6. Qualitative Behavioral Analysis (a) (b) (c) (d) Figure 6.5: An assembly of two plates by means of a fastener: (a) A statically determinate solution, using a capscrew and a nut, with one threaded link, thus one internal load generator, (b) Another statically determinate solution, using a bolt with two nuts, and two threaded links, thus two internal load generators, (c) A statically indeterminate solution, with one capscrew and two nuts, the lowest one acting as locking nut. Static indeterminacy plays a functional role here, which is to reinforce fastening, (d) A statically indeterminate configuration if the cylindric interface between the capscrew and the upper plate (light brown) is to be interpreted as a snug fit. Static indeterminacy is non-functional here, and is considered as an unnecessary burden.Reference state II: Static determinacy 137 the statically indeterminate configuration is characterized by the load cycle along the �y axis. In order to outline indeterminate configurations, internal force propagation cycles should first be reported. 6.5.2 Force propagation and force propagation graphs Internal force propagation paths can be formalized through force propagation graphs (FPGs), which are defined as follows. Definition 6.2 (Force Propagation Graph). A force propagation graph (FPG) is a graph Γ(D, J) that represents the propagation of internal forces in a model, along a given direction. We know that each FPG is a subgraph of the CIuG, augmented with an orientation at each edge according to the conventional positive orientation of the force propagation direction taken as reference. This is a result of Hypothesis 6.3 that implies that internal forces only propagate through CIs, which are CIuG edges. Edge orientation is a matter of convention in both CIG and FPG. Orientation convention in the CIG (see Section 5.2.5) becomes meaningless when applied to force propagation, therefore we refer to the CIuG, the undirected version of CIG, as the super undirected graph of all FPGs. In a given assembly model, there are as many FPGs as there are force propagation directions defined by FIs. Theoretically, a force can propagate in an assembly in all directions, that is, an infinite number of propagation directions in 3D space. This is justified when considering that components are behaving like deformable media, producing stress and strain fields when subjected to external forces. This leads to an infinite number of potential force propagation graphs. Here, we refer to Hypothesis 6.1 where components are rigid bodies. Consequently, forces follow the directions given by FIs and because the number of edges in CIuG is bound, there exists an upper limit on the number of its subgraphs, thus an upper limit on the number of FPGs. Figure 6.6a gives an example of such a load cycle. This load cycle is initiated by an FI of type threaded link connecting C1 and C4. The direction assigned to the force cycle is prescribed by the force of this threaded link. This force is then propagated with static equilibrium equations in that direction. Considering C1 as reference component, its equilibrium equation determines the force applied by C2 (light brown downward on Figure 6.6a). Then, moving to component C2, its equilibrium equation determines the force applied by C3 (green upward on Figure 6.6a). Then, moving to component C3, its equilibrium equation determines the force applied by C4 (red upward on Figure 6.6a). Finally, moving to component C4, its equilibrium equation determines the force applied by C1 (gray upward on Figure 6.6a)138 Chapter 6. Qualitative Behavioral Analysis C1 C2 C3 C4 C5 (a) (b) Figure 6.6: (a) An example of load cycle. Ci designates the components involved in the load cycle. C1 contains a threaded link that originates the load cycle. The dotted rectangles represent the external forces applied to the corresponding component Ci. (b) An example of load cycle incorporating a statically indeterminate configuration. Here, the component C1 is subjected to multiple forces with the same orientation that characterizes its static indeterminacy. that is consistent, i.e., opposite, with the force applied by C4 on C1 that has been used initially. This ends the determination of the load cycle. 6.6 Reference state III: Assembly joint with threaded link as functional cluster As Chapter 7 will reveal, later stages of our approach build on the organization of sets of components that participate to the fulfillment of one functionality in one functional group, and on the labeling of such groups by their corresponding FCs (see Section 4.2.4). An example is the clustering of components that are held up together using a tightening mechanism. The corresponding cluster defines effectively a functional group where the function can be stated as fastening a set of components, i.e., the tightened components are a subset of the cluster and the complementary subset describes the fasteners contributing to this function. If such a fastening process is accomplished through a threaded link, the functional group can be labeled as assembly joint with threaded link where assembly joint with threaded link is a FC designating a set of components held –or joint– together by means of a threaded component. In fact, the detection of cyclic internal force propagation, required forReference state III: Assembly joint with threaded link 139 static determinacy analysis, regroups components that participate to common functions such as fastening. This enables their clustering into functional groups of assembly joint with threaded link. Effectively, the set of components refers to a function. One component, the fastener, generates a given input parameter, i.e., here it is a force, and the interaction forces between components propagate through the assembly. The output parameters are characterized by the corresponding force propagation cycles and the force parameters at each CI of the cycle. This analysis enables the definition of a reference state expressing a fastening process. This is designated as RS III since the behavior observed is based on the action of a fastener and this action is effectively independent of the criteria governing RS I and II. Hypothesis 6.6 (Force propagation). An FI capable of a fastening action generates a force through its neighboring components that propagates through the assembly and ends up producing a cyclic graph. In case the force propagation mechanism does not produce a cycle it means that a fastening process may exist but: • it takes place with objects outside the product, e.g., a vice has a fastening function but this function is performed on an object external to the product; • or it indicates an inconsistent design. In both cases, a user input is mandatory to characterize these configurations and they fall out of the scope of the proposed approach which concentrates, in a first place, on the assembly as a standalone set of components. To achieve the above-mentioned benefits, an algorithm has to be established to detect cyclic internal force propagation paths. 6.6.1 Detection of force propagation cycles In this section we define an algorithm that integrate Hypothesis 6.5 into our qualitative reasoning to further reduce the number of function interpretations per CI by the elimination of statically indeterminate solutions, whenever another statically determinate solution exists for the studied structure. As mentioned in the previous section, force propagation cycles are also useful to identify functional clusters of type assembly joint with threaded link. This algorithm will be used also in these configurations, whenever a threaded link is involved in such a cycle. We are interested in the type of statically indeterminate structures that involve a FI generating forces internal to an assembly. We refer to those interfaces as internal load generators. Examples of such FIs are threaded links and self-locking links. Figure 6.6b gives a example configuration where140 Chapter 6. Qualitative Behavioral Analysis the load cycle produces a statically indeterminate loading of component C1. As observed, components C4 and C5 each apply a force on C1 in the same direction and with the same orientation. This results in a statically indeterminate configuration of C1. Now, the criterion to identify a statically indeterminate configuration can be stated as follows. A component is subjected to statically indeterminate loading in the direction set for the load propagation process if there exists at least two forces applied to this component that share the same orientation. FPGs are not readily separable from their supergraph; the CIuG. This is because the CIG, thus the CIuG, has no notion of force propagation direction expressed in a global coordinate system. Although this can be calculated based on CIs’ associated local coordinate systems and their transformation matrices in the assembly coordinate system, this exhaustive subgraph generation is unnecessarily costly. Alternatively, relevant force propagation subgraphs are generated incrementally, following edges of the CIuG, and starting with an edge that is indeed an internal load generator. Procedure f indLoadCycles() iterate over all interfaces that qualify as load generators, and identify the force cycle to which they participate by a call to function followLoad(). If the original load generator is actually a threaded link, as decided by function threadedLink(), the identified cycle is marked as functional group, and labeled as an assembly joint with threaded link. Function followLoad() uses a classical breadth-first cycle detection algorithm. The initial call of the function takes an interface i which is guaranteed to be a load generator by the calling procedure. It also takes the force propagation direction and orientation, represented by its unit vector �χ, which is an intrinsic property of each load generator. The algorithm applies to the FPG characterized by the direction �χ, we refer to this graph as Γ�χ. Since FPGs are not generated ahead of time, function f indReciprocal() is used to ‘sense’ the CIG edges, and follow those who actually belong to Γ�χ. Function f indReciprocal() is also responsible of the elimination of statically indeterminate functional interpretations. Static determinacy is evaluated each time the function is called, according to the direction �χ. If at least one functional interpretation maintain a statically determinate solution, other static indeterminate functional interpretations are dropped. Once a cyclic path is detected, the generation of the subgraph; i.e., Γ�χ, is stopped, and a candidate functional group is reported to procedure f indLoadCycles(). The breadth first algorithm guarantees that the smallest cycle is detected for a given internal load generator. Cases of statically indeterminate configurations are essentially characterized when the number of cumulative forces with the same orientation exceeds one. More general configurations are left for future work and reveal some design inconsistencies that are not in the scope of the present approach.Reference state III: Assembly joint with threaded link 141 Algorithm 2 Load Cycles Detection Procedure: f indLoadCycles boltedJoints ← ∅ for all load generating interfaces i do mark all components of the assembly as WHITE. cycle ← followLoad(i, �χ) if threadedLink(i) then boltedJoints ← boltedJoints + cycle end if end for Function: followLoad(i, �χ) u ← right(i) while true do mark u as GRAY for all j in f indReciprocal(i, u, �χ) do v ← opposite(u, j) if v is GRAY then lc ← new empty load cycle while v �= u do add v to lc backEdge ← pred[v] v ← opposite(v, backEdge) end while return lc else if v is WHITE then pred[v] ← j followLoad(j, �χ) end if end for mark u as BLACK end while142 Chapter 6. Qualitative Behavioral Analysis 6.7 Conclusions In this chapter, concrete methods and data structures are presented to capture mechanical behaviors at the interface, the component, and the component group levels. Each mechanical behavior is then employed to attribute functional knowledge to geometric elements at each of these levels, in relation to what was established in the literature, and studied in Section 2.3. To enable this employment, referential behavioral standards are formalized in terms of RSs, defined in Definition 6.1. RSs add up to the knowledge base through the formalization of domain knowledge into hypotheses that are assumed to hold true in the context of a given state of the product (see Section 6.2). A qualitative behavioral framework based on nominal physical values is defined in Section 6.3, to empower the purely qualitative approach promoted in Section 4.1. This framework casts a physical dimension onto different FIs in relation with the geometric configurations they interpret, as represented by their associated CIs. This physical reading of the model allows qualitative simulation processes to assess the model mechanical and functional validity. Before any RS is applied to the model, the functional knowledge consists in what could be induced on pure geometrical basis; that is a number of functional associations, in terms of FIs, to each CI, as shown in Section 5.4.1. However, this number is not always one per interface. The multiple nature of functional interpretations in the general case introduces uncertainty to the knowledge base. This half-knowledge needs to be cleared if any reliable functional conclusion is to be withdrawn to the benefit of applications such as FE simulation and analysis. To this end, Section 6.4 presented RS I, that is used to check knowledge consistency against static equilibrium equations. This leads to the reduction of uncertainty as statically invalid functional associations of CIs are dropped. However, examples show that although all statically invalid solutions are selected out, the number of those remaining; i.e., statically valid, still does not allow for a single positive functional solution. RS II presented in Section 6.5 provides the qualitative approach with a supplementary criterion that takes into account not only solution validity, but also its quality with respect to its complexity, therefore its cost. Solution complexity is determined in view of its static determinacy. Unless static indeterminacy is functional in a solution, it is considered to be unrealistic in an industrial context, consequently such a solution is eliminated, leading to a further decrease in the number of FIs per CI. RS III presented in Section 6.6 adds also another criterion that relates to the fastening function of a group of components. This function interacts with RS II through the definition of load cycles. Most importantly, the qualitative approach set up has shown how it combines with the geometry of CIs to enforce functional information at theConclusions 143 level of FIs and extend to the components and to groups of components. Finally, if the number of remaining statically determinate interpretations per CI still exceeds one, the most ‘probable’ solution would become a criterion. Probability here is defined by means of solution popularity in industrial DMUs when more than one survive RS I and RS II. Note that this measure is only taken as a last resort, in order to force a single FI per CI. In the studied industrial examples, however, this last filtering was not needed, hence not used and left for future work like other configurations where user’s interactions would be needed to process design inconsistencies or functions involving objects outside the DMUs. The qualitative approach visited in this chapter allowed for the cleansing of the function knowledge associated to a DMU, reducing it to only positive facts about component interfaces and component groups. These facts actually provide the seeds of more elaborate knowledge, if combined with inference rules, as the following chapter will develop.Chapter 7 Rule-based Reasoning to Derive Functional Denominations As for now, only functional interactions were addressed in our qualitative analysis to filter out FIs and produce a precise spatial distribution of FIs. These FIs are consistent with the DMU both from some behavior point of view as well as geometrically. Now, the DMU is functionally interpreted in a definitive manner at the levels of functional interfaces and functional groups to take advantage of its form - behavior consistency and derive a consistent function at the level of each of its components. However, in order to provide a complete functional description of a model, functionality at the functional unit level should be addressed. This chapter deals with annotating components with their functional denominations, i.e., their FDs. Section 7.1 first illustrates the importance of such functional information, before Section 7.2 shows that this knowledge is the extension of the knowledge acquired so far after the application of domain specific rules, i.e., it takes advantage of the function dependency with respect to behavior and form concepts. Section 7.3 discusses alternative solutions to integrate such domain rules into our knowledge base. As a strongly related topic, knowledge representation is addressed in Section 7.4, before that Section 7.5 gives an in-depth demonstration of the formal reasoning process. Section 7.6 concludes, showing how functional knowledge is saturated generating the required functionally interpreted DMU model.146 Chapter 7. Rule-based Reasoning 7.1 Knowledge at the functional unit level The previous chapter showed a qualitative method that used algorithms, such as graph searches, to extend knowledge or reduce uncertainty about functional properties of an assembly. This method came out with functional facts, particularly at the levels of component interactions, that is, at the functional interface and the functional group levels, in a reference to what was outlined in Section 3.4. The corresponding algorithms mapped a consistent and qualitative behavior to functional interfaces, uniquely associating each CI to one FI. As an example of such behavior, this mapping also permitted the clustering of components tightened up together by means of a threaded link into functional groups referred to as bolted joints. In addition to the CIG, each behavior extends the DMU structure with a spatial mapping of the behavior functional meaning. This algorithmic inference enriched our knowledge about the DMU in two ways: • First, reducing ambiguity in statements such as interface i is either a threaded link or a spline link. This is done through the elimination of invalid, and unsuitable alternatives (see Section 6.4). For example, interface CI1 in Figure 5.5 is definitively identified as threaded link. • Introducing new facts such as stating that interface i participates to an assembly joint with threaded link. This is done through the detection of internal load cycles that tighten up components together (see Section 6.5). For example, interfaces CI1, CI2, CI3 and CI4 in Figure 5.5 are found to take part to the same assembly joint with threaded link. In this sense, our knowledge base only contains positive facts after the application of RSs validation. The functional interpretations of geometric configurations are now unique, and uncertainty is reduced to zero. However, the functional knowledge about the DMU is still not complete. In fact, we still know little about functional attributes at the component level; that is, the functional unit level (see Section 3.4). Section 4.2.3 showed that the functional role, or roles, that a component plays in an assembly identify its FD. This information is necessary to meet the functional requirement of geometric model transformation for simulation purposes because an engineer is used to refer to a function or a group of functions in a synthetic manner using a ‘component name’ or a simple expression ‘qualifying a component’. 7.2 Inference rules as domain knowledge This functional knowledge, however, is not beyond our reach. In fact, positive facts that emerge from the qualitative study explained in Chapter 6 open new opportunities for reasoning and provide seeds to express new knowledge.Inference rules as domain knowledge 147 To demonstrate this, we take the example of a component X that has only two FIs. One of them is a planar support, while the other is a threaded link, and they participate to a functional group LC which has assembly joint with threaded link as its FC (see Figure 5.5). We can then rationalize that such a component is indeed a nut, identifying its FD. It is worth noticing that the newly obtained fact is the result of the application of an inference rule inspired by the domain knowledge that states that ‘a statically valid component having only two functional interfaces: a planar support and a threaded link by means of an internal thread, and involved in a assembly joint with threaded link, is a nut’. This rule is not formalized in any RSs. This type of reasoning can then propagate throughout the assembly model, building on newly acquired knowledge to generate new facts, until the knowledge base converges toward saturation. For instance, the application of another rule stating that ‘a statically valid component that links to a nut through a threaded link, and that has another functional interface which is a planar support, is a capscrew’, allows us to deduce that the component D in Figure 5.5 is indeed a capscrew. The previously mentioned rules can be formally stated by means of First Order Logic (FOL) as follows: nut(X) ⇐= component(X) ∧ threadedLink(I1) ∧ planarSupport(I2) ∧ boltedJoint(LC) ∧ innerF orms(X, I1) ∧ forms(X, I2) ∧ ∀I(forms(X, I) =⇒ I = I1 ∨ I = I2) ∧ regroups(B, X) (7.1) capscrew(X) ⇐= component(X) ∧ nut(Y ) ∧ threadedLink(I1) ∧ planaSupport(I2) ∧ outerF orms(X, I1) ∧ forms(Y, I1) ∧ forms(X, I2) (7.2) In this formalization, each of component, threadedLink, planarSupport, boltedJoint, nut, and capscrew is a unary predicate, while forms, innerF orms, outerF orms, and regroups are binary ones. We note that the variable I in Formula 7.1 is bound. Unlike the other free variables of the formula that appear in more that one condition of the148 Chapter 7. Rule-based Reasoning implication, linking them together, I appears only in one condition. It is thus universally qualified. Even though the second rule expressed by Formula 7.2 does not mention components participation to a assembly joint with threaded link in an explicit manner, this information is implied from the fact that X links to a nut through a threaded link. Those rules reflect expertise about the domain of discourse, thus they are not part of any RS, as they are not hypotheses made in view of a given state of the product. However, the incorporation of such rules in the knowledge base is compulsory if functional information of the model is to be explored sufficiently to meet the objectives of this work (see Section 3.4). 7.3 Reasoning alternatives A mechanism should thus be established to account for such domain knowledge. One may suggest the formalization of such rules into algorithms in a similar manner to RSs. This would mean the expression of each rule through a code path that assesses the satisfaction of its conditions, before applying its action. However, such an integration at the implementation level leads to static rules. Each time a new rule is to be introduced, the code must be amended, and resources must be recompiled. While hypotheses made through RS are independent of the particular domain of application, as static validity and determinacy apply to all disciplines of mechanical engineering, inference rules are closely related to specific types of industries and industrial practices. In fact, a list of functional interactions, i.e., FIs and FCs, can be deemed exhaustive and complete with respect to a given set of conventional representations of components. A list of their possible combinations to produce FDs becomes more difficult to set up because new categories of components may appear. Anyhow, such lists cannot be ensured to include all FIs, FDs used in all mechanical industries at present time since conventional representations are not standardized at present (see Sections 1.6 and 3.2). To cope with this heterogeneous con- figuration, considering also that the proposed approach builds up on conventional representations whose consistency has not been analyzed, it is important to dynamically adjust inference rules, add new ones, or remove existing ones. 7.3.1 Dynamic formalization of domain specific rules It is thus advantageous to enable the dynamic addition and modification of such rules, in order to tune our reasoning in accordance with specific needs of the particular domain of application, e.g., aeronautic or automotive industries. The implementation of inference rules as static, hard-coded execution paths is thus inadequate for such a requirement.Reasoning alternatives 149 The ability to formalize rules in terms of FOL formulas such as Formulas 7.1 and 7.2 incites us to make use of this uniformity. If the sought system can take such formalization as an input, and then use it to produce new knowledge, rules can be adapted and augmented according to the particular domain where they apply. 7.3.2 Problem decidability In fact, algorithms —referred to as deductive systems— exist to treat rules and facts expressed in FOL, and deduce new knowledge from them [61, 33, 91]. However, FOL is proven to be undecidable [51, 170]. This means that although FOL deduction can always find the answer in infinite time if the answer is positive (FOL deduction is complete), and that answers are valid when they exist (FOL deduction is sound), no algorithm is guaranteed to find the answer to any given question in an infinite time of execution. This is in fact the price of high expressiveness of FOL. If a decidable deductive system is to be found, some logic constructs, thus some logic expressiveness, is to be sacrificed. Efforts have indeed been paid in this direction, to come up with fragments of FOL that are decidable. In this work we are particularly interested in a family of formal logic languages that is referred to as Description Logic (DL) [28]. In fact, DL is a family of decidable FOL fragments1 that allow the fine tuning of reasoning algorithms complexity as a compromise on the logic expressive power. Moreover, DL provided the theoretical basis upon which OWL —the ontology language recommended by W3C— is built. Section 7.4 promotes the use of OWL ontologies as the knowledge base containers in this work. Algorithms with controllable complexities are developed to allow effi- cient reasoning using DL. This led to a variety of reasoners that implement those algorithms, either for commercial use such as RACER [78], or with open source licencing agreements such as HermiT [155], Pellet [156] and FaCT++ [169]. Different reasoners treat different variants of DL. Because of its simple, yet well-defined formalism, interfacing protocols to communicate facts and queries to reasoners are also established, such as DIG [15]. From the previous analysis and the above-mentioned reasons, the use of DL to formulate inference rules suggests itself as a natural choice so that algorithm complexity can be mastered. This is indeed an important point to stay consistent with the geometric issues addressed in Chapter 5 and the qualitative reasoning process set up in Chapter 6 so that the overall DMU enrichment process can be mastered from an algorithmic complexity standpoint. Section 7.5 will develop in depth on issues related to the formal 1Some DL variants go beyond FOL capabilities, providing operators that require higher order logic, such as transitive closure of roles or fixpoints [28].150 Chapter 7. Rule-based Reasoning reasoning employed in our work. Before that, Section 7.4 addresses a closely related topic, that is knowledge representation. 7.4 DMU knowledge representation In order to enable the reuse of the acquired functional knowledge about a DMU at different stages of a PDP, it must be formalized and stored in a persistent manner. This brings forth the question of how knowledge should be represented. Unlike most of other information systems, in an expert system the choice of method to achieve knowledge persistence is highly related to other choices about problem solving. This is because the issue of reasoning cannot be addressed in disregard of that of knowledge representation. In fact, the way knowledge is represented decides how this knowledge is made available, in which way it is structured, and what elements it is made of. Those choices highly influence what kind of reasoning can be made on that knowledge, and what other information can be driven from. Therefore, both problems are coupled, and often addressed together in what is referred to as Knowledge Representation and Reasoning (KRR). Section 2.6.2 showed that the literature intensively used ontologies to represent additional non-geometric knowledge about the DMU. Even though little has been done beyond the representation of facts in the analyzed works, ontologies, particularly with the powerful semantics of OWL, were shown to provide solid grounds not only for the representation of functional knowledge, but also for reasoning on it. Earlier works in the domain of CAD [127, 157] that concentrated on inference mechanisms was based on inference engine technologies that was not formalized as DL currently is. Consequently, there was no reference to the algorithmic complexity of these processes. Additionally, these approaches were connecting design parameters to geometric models of components in rather loose manner which was preventing them from referencing the precise and appropriate geometric areas of components and the integrity of the geometric model was not necessarily preserved, i.e., a solid may be transformed into an object that is no longer a solid. KBE approaches (see Section 2.6.3) appeared as evolutions of these early approaches linking geometry and artificial intelligence techniques. KBE concentrates on quantitative approaches to dimension components or sub-systems, i.e., it refers to the form – behavior dependency. Here, the knowledge representation is qualitative and can be expressed symbolically, which is well suited with the use of ontology-based approaches. In a tight connection to the choice of reasoning formalism, that is DL, explained in Section 7.3, we opt in this work for representing acquired knowledge in terms of ontologies, and using OWL-DL language. This has the following advantages:DMU knowledge representation 151 • The use of OWL ontologies, as a recommended standardized language [5], enables communication channels with other services through the well-established paradigms of the Semantic Web. Services may either be providers to which some tasks can be outsourced, e.g., reasoners, or consumers that make use of our expert system, e.g., FE pre-processors; • OWL has a semantic advantage over its counterparts Resource Description Framework (RDF) and RDF-S which it actually extends with agreed-upon high-level semantics. This enables the formalization of fact and rules in a rather intuitive manner; • OWL-DL offers a good trade-off between expressive OWL-Full with poor computational properties, and rather efficient, but quite restrictive OWL-Lite; • The use of OWL-DL enables a seamless integration with DL reasoners, as DL is the formal logic on top of which the language is constructed. As shown in Section 2.6.2, an ontology has two components. The terminological part, or TBox noted T , and the assertional part, or ABox noted A. Both the TBox and the ABox constitute the knowledge base K = �T , A�. The TBox T contains concept names and role names, and restrictions on them. While the ABox A contains axioms, which are individual names and their instantiations. 7.4.1 Ontology definition through its concepts and roles The proposed ontology is identified by its Uniform Resource Identifier (URI)2, and defined by its TBox, as it contains the domain knowledge (see Section 2.6.2). ABoxes, containing the model knowledge, are then generated and stored apart, for each analyzed model. We recall that model knowledge is only interpretable in the context of domain knowledge, as Section 2.6.1 has shown. Therefore, before the model is treated, the ontology, in terms of its TBox, is loaded. All introduced concept and role names have the namespace romma. In this text, and for the sake of readability, we refer to the concept name romma:Component as simply :Component, assuming that romma is the default namespace. For the sake of clarity, we use the CamelCase notation in our naming conventions. Names starting with capital letters refer to concept names, while those starting with small letters indicate role names. Individual names are written in all caps. 2http://pagesperso.g-scop.grenoble-inp.fr/~shahwana/romma152 Chapter 7. Rule-based Reasoning The TBox defines functional taxonomies (see Section 4.2.6) through concept hierarchies. The FD taxonomy, which is partially shown in Figure 7.1, is defined by a concept hierarchy rooted at :Component. FDs are defined at the leaf level of the hierarchy, such as :Capscrew, :Nut and :LockingNut. While the root of FI taxonomy is the concept3 :Interface, FIs are again de- fined at the leaf level by concepts such as :PlanarSupport, :ThreadedLink, and :SpineLink. FCs are defined as subclasses of the concept :FunctionalCluster. Examples are :BoltedJoint and :RivetedJoint. The relationship between components (instances of :Component) and interfaces (instances of :Interface) is defined through the role :forms, that relates a component to an interface it forms. This role represents the binary relation �f defined in Section 4.2.5. The role :links is defined to be the inverse role of :forms (an interface links a component). This role represents the binary relation �l defined in Section 4.2.5. A restriction is added to the TBox to ensure that one interface links exactly two components. The role :forms is specialized into two sub-roles, namely :innerForms and :outerForms. This is to faithfully represent geometric configurations where the interface is not symmetric. Examples of asymmetric interfaces are threaded links, spline links, snug fits, etc. In this case, we distinguish the outer component that outer-forms the interface, from the inner component that inner-forms it. The relationship between components and their functional groups (instances of :FunctionalCluster) is defined through the role :regroups where a functional group regroups a component. The role :participatesTo is defined as the the inverse role of :regroups, i.e., a component participates to a functional group. The ontology editor Prot´eg´e [3] is used in the context of this work to design the ontology. This framework allows the intuitive authoring of concepts, roles, and their hierarchies. Moreover, the seamless integration that Prot´eg´e provides with reasoners (embedded support for HermiT and FaCT++ version 4) enables an easy check of concepts satisfiability. This permitted the reporting of inconsistencies as soon as they appeared. 7.4.2 Ontology population with model knowledge Once the qualitative reasoning demonstrated in Chapter 6 is done, the resulting functionally enriched CIG is translated into an ABox of the abovementioned ontology. To this end, the ontology is first loaded. Then the following steps take place: • All nodes of the CIG are defined as individuals. For each node, an 3For the sake of conciseness, the terms concept and role are used instead of concept name and role name, whenever this use is not ambiguous.DMU knowledge representation 153 :CapScrew :Screw ... :Locking Nut :Nut :BoltReceiver :Fastener :Component ... ... :SnugFit :ThreadedLink :ClampLink ... :Linear Support :PlanarSupport :Support :Interface owl:Thing ... ... :PowerTransmitter :FunctionalCluster :IrreversibleThreadAssembly :Gear ... ... :links :regroupes romma Figure 7.1: Partial graphical representation of romma ontology, showing concept and role names. Solid stroke arrows represent the concept hierarchy relationship, while dashed stroke arrows represent named object roles. The rounded rectangle delimits the name space.154 Chapter 7. Rule-based Reasoning axiom is added stating that the corresponding individual is an instance of :Component; • All edges of the CIG are defined as individuals. For each edge, an axiom is added stating that the corresponding individual is an instance of the concept representing the FI associated to the underlying edge, i.e., a sub-concept of :Interface. Please note that as a result of the qualitative reasoning, each CI, thus each node of the CIG, is associated to one and only one FI. Indeed, all edges of CIG become instances of FIs defined as leaves in the taxonomy of interfaces; • All recognized functional groups are defined as individuals. For each functional group, an axiom is added stating that the corresponding individual is an instance of the concept representing the group FC, i.e., a sub-concept of :FunctionalCluster. An assembly joint with threaded link (see Section 6.6) defined over a subset of the CIG nodes is an example of sub-concept of :FunctionalCluster; • For each edge of the CIG, two axioms are added stating that the individual representing the interface links two other individuals representing the nodes at each extremity of the edge through the role :links or one of its sub-roles; • For each recognized functional group, as many axioms as its participating components are created. Each stating that the individual representing the recognized functional group relates to the individual representing the corresponding component through the role :regroups. An example is the set of components belonging to an assembly joint with threaded link. Now that the acquired knowledge is modeled using an ontology, the knowledge base is ready to be reasoned upon, generating new facts until saturation, i.e., until no new facts can be derived. The following section details this issue. 7.5 Formal reasoning to complete functional knowledge Section 7.3 showed the merit of using a formal language to represent domainspecific expert rules. The choice of DL proves ideal for the needs of DMU functional knowledge. However, DL is a family of languages that vary with respect to their expressiveness, thus, with respect to their computational properties [17]. Variants of DL and the linguistic constructs they provide are visited in Appendix D. In this work, we employ the DL language SHOIQFormal reasoning to complete functional knowledge 155 which is supported by OWL-DL, starting version 1.1, in agreement with our knowledge representation choice (see Section 7.4). Even though, starting version 1.1, OWL-DL actually supports SROIQ- (D) [88], that is SHOIQ augmented with complex restrictions on roles and data types constructs. In our work, we do not use these additional features. Disallowing data types in logical constructs aligns with the purely qualitative method advocated in Section 4.1 and described in Chapter 6. Moreover, avoiding the use of such costly constructs and restrictions spares the reasoning process a remarkable computational overhead [116]. DL family is backed by strong semantics that defines how different constructs of a given variant should be interpreted. Appendix D gives more details about the semantics of DL. 7.5.1 Inference rules in DL Statements such as those expressed through Formulas 7.1 and 7.2 can be expressed in DL using General Concept Inclusion (GCI). A GCI in this sense defines an inference rule that applies across the underlying domain. Those rules are actually used to identify components FDs. For example, the aforementioned formulas describing a nut and a capscrew are translated into DL as follows in their respective order: Nut � Component � ∃innerForms.ThreadedLink � ∃forms.PlanarSupport � ∃participatesTo.BoltedJoint � =2forms (7.3) Capscrew � Component � ∃outerForms.(ThreadedLink � ∃links.Nut) � ∃forms.PlanarSupport (7.4) In connection to what has been argued in Section 4.2.6, the hierarchical structure of the FD taxonomy allows inferences to gradually identify a component functional class. A rule can either describe an FD in one statement, or express an intermediate concept only, that leads to the definition of an FD when another rule is applied. Those intermediate concepts can be either inner node (nodes at upper level than leaves) in the FD taxonomy, or auxiliary concepts introduced to the ontology to allow the reuse of inference rules, independently of the FD taxonomy. In the latter case, the intermediate concepts holds no intrinsic functional meaning. For example, the concept name :BoltReceiver can be used to refer to female threaded fasteners. It can then be described as follows:156 Chapter 7. Rule-based Reasoning BoltReceiver � Component � ∃innerForms.ThreadedLink � ∃forms.PlanarSupport � ∃participatesTo.BoltedJoint (7.5) The previous description includes any component with a threaded hole that receives another threaded shaft. The description of a nut can then be narrowed down as follows: Nut � BoltReceiver � =2forms (7.6) The above-mentioned approach allows us to reuse the concept described in Formula 7.5 to describe other concepts, without the need of re-writing the whole statement each time the concept is reused. For example, a :InnerNut can be described as a :BoltReceiver with further restrictions: InnerNut � BoltReceiver � =2forms.PlanarSupport � =3forms (7.7) This states that a statically valid component (as defined in Chapter 6) that has only three interfaces: a threaded link, two planar supports, and that takes part to an assembly joint with threaded link, is an inner nut (see Figure 7.2). A locking nut can then be defined as a nut, whose neighboring component is an inner nut. LockingNut � Nut � ∃forms(PlanarSupport � ∃links.InnerNut) (7.8) We note that individual rules are not definitions. This means that each rule is actually an implication rather than an equivalence. This allows us to describe a given FD by means of two or more rules. If an individual satisfies any of those rules, it is identified as belonging to the corresponding FD. An example is to add another GCI stating that a statically valid component that forms a threaded link by means of an external thread, and that has at least one planar or conic support, and that participates to a bolted joint, is a capscrew, as follows: Capscrew � Component � ∃outerForms.ThreadedLink � ∃forms.(PlanarSupport � ConicSupport) � ∃participatesTo.BoltedJoint (7.9)Formal reasoning to complete functional knowledge 157 Locking Nut Inner Nut Capscrew Threaded Links Planar Supports Conic Supports (a) (b) Figure 7.2: (a) A bolted joint (which is an assembly joint with threaded link), involving a capscrew, a nut, and a locking nut. According to inference rules, the nut would be identified as an inner nut. (b) Some of the FIs involved in the assembly. By adding such a rule, a capscrew can still be identified, even when it is not connected with a nut. While the rule stated by Formula 7.9 is still valid. It is worth noticing that all of the above-mentioned rules are expressed using only SHOIQ constructs. They are therefore expressible in OWL-DL. Again, we use Prot´eg´e to define expert rules, checking ontologies consistency and the satisfiability of concepts at each stage. During a testing phase, Prot´eg´e is also used as a workbench, creating example ABoxes and using its reasoning capability to assess results completeness. The real feeding of the ABox axioms of a given model, however, is done from within our application, and not through Prot´eg´e. This will be developed in more details in Section 7.5.4. In spite of the soundness of inference rules, expected results cannot be obtained by the mere instantiation of individuals and their relations as shown in Section 7.4.2. This is because of two inherent reasoning characteristics of OWL and DL that are the Unique Name Assumption (UNA) and the Open World Assumption (OWA). The upcoming two sections develop on these issues. 7.5.2 The unique name assumption The Unique Name Assumption (UNA) assumes that distinct terms denote distinct individuals [135]. OWL, however, does not make this assumption. In fact, a URI is not required to be unique for a given entity in the Semantic Web philosophy. OWL even has the owl:sameAs property to denote158 Chapter 7. Rule-based Reasoning individuals identity, even though having two different URI, i.e., names. Most of DL reasoners thus do not account for this assumption by default. This prevents making simple judgments, such as those on lower bound cardinality restrictions. For example, even if an individual x is declared to relate to individuals y and z through the role r in the knowledge base ABox, the conclusion that x is an instance of ≥2r cannot be made, in the absence of further knowledge. This is because names x and y may actually refer to the same individual. To work around this issue, the UNA should be made explicitly. This can be done by means of SHOIQ constructs by defining a singleton for each individual, i.e., a concept having only one individual, then declaring those concepts to be mutually disjoint. This is made possible through the nominal construct of SHOIQ that allows rules to describe a concept by listing its individuals. OWL defines the property owl:differentFrom that declares two names as referring to two distinct individuals. It also offers the owl:AllDifferent construct that declares a mutually distinct individuals. These OWL constructs are no more than syntactic shorthands to creating mutually disjoint singletons. In this work, however, the UNA is made using SHOIQ primitive constructs to guarantee compatibility with the communication protocol used (see Section 7.5.4). 7.5.3 The open world assumption The Open World Assumption (OWA) assumes that facts which cannot be proven to be true remain unknown. This is in contrast to the Closed World Assumption (CWA), where facts that cannot be proven to be true are assumed false. Under the OWA, partial knowledge is permitted, and conclusions made at some point cannot be falsified by the introduction of new facts to the knowledge base. While under the CWA, knowledge is assumed complete at each point of the reasoning. This leads to invalidate some conclusions that are made in absence of certain facts, once those facts are introduced to the knowledge base [75]. The OWA thus has the advantage of allowing partial knowledge, while keeping temporal consistency of the knowledge base. The CWA requires complete knowledge, that might not be available in the context of the Semantic Web services and applications. For this reason, OWL and DL make the OWA. This assumption of an open world, however, may hinder reasoning. In fact, in the absence of some closure measures, inferences such as concept negation are not possible. The fact that an individual x, cannot be proven to belong to the concept C, does not mean that it belongs to its complement ¬C. In fact, x belongs to neither concepts. The same applies to upperFormal reasoning to complete functional knowledge 159 bound cardinality restrictions, the fact that an individual x is stated to be involved only once in a role r does not prove its membership of the concept ≤1r, unless another involvement in the same role shows to be impossible. This problem, however, can be solved by means of some sort of local closure of the world of discourse. For example, if the individual x is proven to be an instance of the concept D, while D and C are stated to be disjoint in the TBox of the knowledge base C � ¬D, then ¬C(x) becomes provable (and we write K |= C(x)). This is because x cannot belong to D and C at the same time. To work around this issue in the proposed approach, we allow for local closure of the knowledge base at the TBox level by defining concepts of different taxonomies (FI, FD and FC) to be mutually disjoint at each level of the taxonomy. Moreover, the closure is ensured at the ABox level, and for each treated model individually, by explicitly stating how many interfaces a component forms, and how many components a function cluster regroups. For instance, a component :C (see Figure 5.5) can be stated to have exactly two interfaces as follows {C} � =2forms�. Again, nominal definition of a singleton (namely {C}) is used here, as enabled by the nominal construct of SHOIQ (see Section 7.5.2). 7.5.4 Integration of DL reasoners into application framework As mentioned earlier in Section 7.3.2, efficient and robust algorithms are established in order to reason upon DL knowledge bases. The choice of OWL-DL as ontology language allows us to use these algorithms to saturate the knowledge base with valid new facts. DL reasoning algorithms are implemented in terms of reasoners, which are expert systems that receive the knowledge base as an input, before inference algorithms are run against this knowledge in order to answer user’s queries. To allow the communication of facts and rules, as well as queries, a reasoner provides the software developer with interfaces to client systems. We distinguish two types of communication channels: Application level communication. This is done through a well-defined API, and by means of a software library offered by the reasoner; Network level communication. This is done through a well-defined network protocol, and by means of server applications offered by the reasoner. The first solution, on the one hand, is suited for standalone software applications that are characterized by transparent communications with a minimal overhead. However, and in spite of efforts for standardization [87], different reasoners still define different APIs. This is partially because of the160 Chapter 7. Rule-based Reasoning difference of implementation techniques, e.g., programming languages, used by each reasoner. This disadvantages makes it impractical to switch between reasoners once the binding is done, hence it becomes tedious to switch from one reasoner to another to be able to evaluate their performances. The second solution, on the other hand, goes through standardized communications. A reasoner that provides a network interface implements a well-defined protocol to this end. This allows the software developer to use an arbitrary reasoner, with complete abstraction of the implementation technique at the server and the client sides, as long as both sides implement and use the same protocol. Moreover, a different reasoner can be used, even after the interface is built, given that it provides the developer with a network interface. Following the client-server paradigm, this solution enables the assignment of dedicated reasoning servers for industrial as well as research applications. A protocol for DL reasoners network communication actually exists, DL Implementation Group (DIG) is the de facto DL reasoner network communication standard [15]. It is used by many of them such as RACER, Pellet, and FaCT++ to name only a few. To be able to evaluate the above-mentioned reasoners, we choose to use the architecture solution of network communication channel, implementing the DIG interface from a client perspective, to insert formal reasoning processes in the proposed approach as shown in Figure 7.3. To this end, and for a given execution of our application, a connection to the reasoning server is then made, and a new knowledge base is initialized. The ontology TBox, translated into DIG tell-commands, is read. A tell-command informs the reasoner about rules (in terms of GCI) and facts (in terms of axioms). The ontology tell-commands is then submitted to the reasoner. After the geometric and qualitative analysis demonstrated in Chapters 5 and 6, the ABox of the knowledge base is also submitted to the reasoner, again in terms of tell-commands. Once all relevant facts are declared to the reasoner, i.e., the functionally enriched CIG as interpreted in Section 7.4.2, the individual names are declared unique (see Section 7.5.2) and the world of discourse is locally closed (see Section 7.5.3) using the relevant rules communicated as tell-commands. The reasoner is then queried by means of ask-commands about instances belonging to different FD classes. An ask-command requests the reasoner about a specific piece of information. The reasoner returns, for each ask-command, a list of individual names that belong to the requested concept, that is an FD in our case. These lists are used to annotate corresponding components with their respective FDs. Figure 7.4 illustrates different stages of this process, showing communication messages between the proposed application and a dig server in terms of a sequence diagram. The above-mentioned scheme is totally independent of the underlying reasoner implementation. To carry out our experiments, we used bothFormal reasoning to complete functional knowledge 161 Ontology / DIG HTTP Ontology / OWL Geometric Analysis Behavioral Analysis DIG Client Developed Used DIG Server DL Reasoner Figure 7.3: A diagram showing the architecture of the developed application, and its interface with the reasoning server. The diagram shows communication channels between different modules and applications. FaCT++, a C++ implementation of a SHOIQ(D) reasoner [169], and Pellet, a Java implementation of a SROIQ(D) reasoner [156]. To allow the submission of the TBox to the reasoner, the ontology, expressed in OWL-DL, needs to be translated to DIG tell-commands first. Even though version 3 of Prot´eg´e provided an option to generate the DIG code corresponding to a given ontology, experiment showed that this code is broken. Prot´eg´e 3 actually communicates a different code when it binds to a DIG server, a property that was dropped in Prot´eg´e 4. For the purpose of this work, the TBox of the OWL ontology is translated manually to DIG tell-commands, while the rest of ABox tell-commands are formulated inside our application, in accordance with the facts acquired at the qualitative behavioral analysis stage. In order to complete the functional knowledge about the model on hand, the application queries the reasoner about instances belonging to concepts that represent FDs. A query is thus created per FD. Queries are formulated in terms of ask-commands. This functionality is implemented by the class DigOntologyHandler in our code. For each query the application sends, the reasoning server sends back a set of individual names that belong to the FD in question. Individual names are then mapped to their corresponding components and components are annotated with the FD.162 Chapter 7. Rule-based Reasoning Figure 7.4: A sequence diagram showing communication between the proposed application and the DIG server.Conclusions 163 7.6 Conclusions After their identification at the functional interaction level, functional properties still need to be identified at the functional unit level. This can be materialized by assigning relevant FDs to their corresponding components. Section 7.1 emphasized this need to complete the functional enrichment process of the DMU. Even though this information is still not available when the qualitative behavioral study, described in Chapter 6, concludes, Section 7.2 showed how this knowledge can be obtained. The assignment of FDs to their respective components showed to be the logical entailment of acquired knowledge at the interaction levels, i.e., the FI and FC levels, coupled with inference rules that are inspired from a particular domain of application. Indeed, while the qualitative analysis process refers to a behavior to filter out some FIs, it brings in a consistent set of dependencies between shapes, behavior and function at the level of interfaces between components. Section 7.2 showed how these dependencies at the component interface level could be extended to the component level through inferences. Section 7.3 showed that a pre-defined set of such rules cannot be deemed complete for all mechanical engineering disciplines, thus the need for a dynamic adaptation of inference rules to the context in which a given DMU is defined. This requirement narrowed down the choice of the method to be used to define inference rules to formal logics that brings such agility. Although FOL suggested itself as a theoretically grounded solution, its unpredictable computational behavior made it an inconvenient choice. The advantage of expressing rules using DL, as a family of formal languages, is its well-understood computational properties. This is an important point to produce an application framework that can be mastered from an algorithmic complexity standpoint, both at the geometry and knowledge processing levels. The choice of rules expression languages was made in close connection to the choice of knowledge representation shown in Section 7.4, and the choice of reasoning formalisms developed in Section 7.5. Our OWL-DL ontology was introduced in Section 7.4.1, before Section 7.4.2 showed how a given model is instantiated in view of its concepts and roles. Section 7.5 demonstrated how inference rules can be formalized by means of DL SHOIQ constructs. Reasoning obstacles and their workarounds were then explained in Sections 7.5.2 and 7.5.3. After establishing the reasoning process theoretically, Section 7.5.4 provided an insight into some implementation issues, such as the use of third party DL reasoners, and how knowledge, queries, and answers were communicated back and forth to such reasoners. This chapter concludes the presentation of our purely qualitative approach. As a result of such a process, the DMU model is now restructured164 Chapter 7. Rule-based Reasoning geometrically to allow algorithms to recognize functional interaction zones (see Chapter 5) and identify some components using their FD. After interactions were recognized geometrically, their behavior was analyzed to recognize their functional attributes. Interaction zones, identified by CIs, and interaction groups, identified by components sets, were annotated with their functional semantics, i.e., their respective FIs and FCs (see Chapter 6). As a final stage to a complete functional interpretation of the DMU, components as functional units were annotated with their applicable FD, as part of a formal reasoning process. Indeed, this overall process describes the adequate data structure of a functional component as mentioned at Section 7.5.1Chapter 8 Results and Comparative Study In this chapter we evaluate the proposed application of DMU enrichment with functional information through different use cases, ranging from simple illustrative examples up to industrial scale models. The general application architecture is first visited in Section 8.1. Section 8.2 walks through and comments the result of a range of examples. A successful case study of the integration with a templatebased simulation pre-processor is demonstrated in Section 8.3. 8.1 Application architecture Figure 8.1 shows the major modules of the proposed application. It also shows modules that the application uses to deliver its output. The system comprises three main modules that are the geometric processor seen in Chapter 5, the qualitative analyzer seen in Chapter 6 and the semantic annotator seen in Chapter 7. The three modules communicate by means of the CIG that is enriched with different levels of information according to the processing stage. Open Cascade Technology [149] is used in the geometric processor to read a STEP file and perform primitive geometric and topological operations where the CIs between components are identified and the CIG is then generated. The geometric processor is used again in the semantic annotator to write down the STEP file, now enriched with the CIs between components and the functional knowledge about components. At this stage, the geometric model of each component is structured with all its CIs attached. As shown in Section 7.5.4, a DIG reasoner is used, such as FaCT++ [169] or Pellet [156] to apply rules of the ontology defined in Section 7.4.1 onto the functional knowledge obtained through the qualitative analyzer, generating166 Chapter 8. Results and Comparative Study Figure 8.1: Component diagram showing the developed solution as encapsulated in package romma, along with external libraries that take part in the proposed approach. new facts that relate components with their FDs. Other software libraries have also been used in the developed application, such as Xerces-C++ [6] to parse and generate Extensible Markup Language (XML) strings, and cURL [2] to handle network communications. The system takes as an input a DMU as represented by its geometry in a STEP format. In fact, most commercial CAD applications provide an interface to export CAD models to this format, as it is an ISO standard. Even tough other information rather than geometry can be encapsulated in a STEP file, we only consider the geometry and topology of each component of the DMU. They represent closed B-Rep surfaces forming a volume each that represents a component. The final output of the proposed system is again a STEP file. However, the generated STEP file differs from the read one in two aspects: • The new geometry of the DMU is restructured according to functional interaction zones between components, and with respect to the functional breakdown seen in Section 4.2.3. That is, contacts and interferences are imprinted onto the original surfaces of each component participating to the interaction, generating new curves, thus new faces in the geometric model of each component; • The new STEP file is semantically annotated. This is done in a tightApplication to industrial examples 167 relation to the ontology defined in Section 7.4.1. Functional interaction zones are now named after their FIs designators as represented in the ontology. At this stage, one FI is associated with one CI; Moreover, functionally recognized components are also named according to their unambiguous FD, as borrowed from the same ontology. The connection to an agreed-upon ontology guarantees the meaningfulness of this supplementary information in the outcome DMU. The proposed software can either be used as a command line application, or as a software library. In both cases, it will need a running DL reasoner server, supporting the DIG interface, in order to run properly. Documentation of the software API is available online1. 8.2 Application to industrial examples The proposed application has been run against different examples to evaluate its robustness. Tests included primitive DMUs that did not necessarily convey an industrial meaning, as well as full-scale industrial examples. In the first case, the system validity to generate coherent results with respect to the objectives set in Section 3.4 has been evaluated. In the second case, application scalability has been put to test using industrial use cases. At first, we consider an illustrative example of a simple DMU. It is described purely geometrically and can be interpreted as a bolted joint assembly. The assembly consists of three plates fastened together by means of a capscrew, a nut, and a locking nut. We recall that those denominations are not available at the outset of the DMU analysis. A cross-section in the assembly model is shown in Figure 8.2. This figure also shows the CIG corresponding to the studied DMU, and generated by the geometric analyzer. RS I analysis is reflected in the elimination of statically invalid interpretations, namely both spline links FIs in this case. RS II comes then to filter out FIs leading to unnecessary static indeterminacy. This leads to the elimination of snug fits and the self-locking fit. Finally, RS III identifies an internal load cycle. This leads to the labeling of the group of components that participate to this cycle as an assembly joint with threaded link. Once functionality is determined at the interaction level, the CIG is passed to the semantic annotator, which loads the ontology and connects to the reasoning server. The CIG is then translated into facts, in light of the ontology concepts and roles as shown in Section 7.4.2. After the reasoner is fed with available knowledge, it is inquired about FDs of components. Figure 8.3 shows recognized FDs as a result of the reasoning process. In addition to the capscrew in green and the nut in blue, the application also recognized the locking nut, colored in red. In fact, even though both the nut 1http://pagesperso.g-scop.grenoble-inp.fr/˜shahwana/StepByStep/168 Chapter 8. Results and Comparative Study Conic Contact Conical Support Cylindric Interference Thread Link Spline Link #0 Planar Contact Planar Support Planar Contact Planar Support Cylindric Contact LooseFit SnugFit #1 Cylindric Contact LooseFit SnugFit #2 Cylindric Contact LooseFit SnugFit Planar Contact Planar Support #3 Cylindric Interference Thread Link Spline Link #4 Planar Contact Planar Support #5 Internal Load Generator Internal Load Cycle A Statically Invalid Interpretation #3 #1 #0 #2 #4 #5 Slef-locking Fit A Statically Indeterminate Interpretation Figure 8.2: A cross-section in a simple bolted joint example tying up three plates, along with its corresponding CIG as generated by the geometric analyzer. Functional interpretations are also reduced to one FI per CI, and an internal load cycle is recognized as a result of RS qualitative analysis. and the locking nut have the same shape, they are distinguished based on their CIs and FIs. The locking nut has two CIs whereas the nut has three. It has to be noticed that in a standard setting of a bolted joint with a single nut, this nut has only two CIs. It is because this nut is in contact with another nut that it functionally becomes a locking nut whereas the nut it is in contact with is functionally designated as a nut even though it has three CIs. To enable this distinction, the auxiliary concept of a general nut needs to be introduced to the ontology. A locking nut is then defined as a general nut that forms exactly one planar support with another general nut. This simple example shows how FDs are influenced by FIs as well as other neighboring components: a complexity that can be handled with the reasoning mechanisms of the qualitative analysis and the inference mecha-Application to industrial examples 169 Figure 8.3: A bolted joint assembly showing a recognized capscrew in green, a recognized nut in blue, and a recognized locking nut in red. nisms associated with the proposed ontology. The model of the centrifugal pump, first introduced in Figure 1.5, provides a more elaborate example. The DMU contains 43 components. The geometric analysis of this DMU thus generates a CIG with 43 nodes. Model components, as represented by CIG nodes, are connected through 100 edges, that is 100 CIs. The CIs identified are of types surface contacts (planar and cylindrical), cylindrical interferences, linear contact. Figure 8.4 shows the result of the running of the proposed application against the centrifugal pump model. This figure shows how the following FD could be recognized: a capscrew in green, nuts in blue, studs in yellow, plug screws in cyan and a set screw in magenta. We note that since the capscrew, the studs, and the set screw all have an outer thread that participates to a threaded link, they are classified as threaded shafts. However, the distinction between one FD and another is made in light of components participation to other FIs. A stud for instance is guaranteed to form only threaded links as FIs. The diversity of FDs processed in this example demonstrate the interest of ontology structure and its associated inferences that can be enriched easily to adapt to new categories of components. This is an efficient complement to the qualitative analysis module that is generic and builds upon basic mechanical concepts. The example illustrated in Figure 8.3 showed that even if two components share exactly the same shape, they still can be interpreted differently. It is also worth mentioning that the form of the stand-alone component does not affect the judgment of its FD. In fact, what does matter is components interactions, reflected first at the geometric level by their CIs, and then interpreted functionally by means of FIs. For example, a nut is recognized170 Chapter 8. Results and Comparative Study (a) (b) Figure 8.4: The example of the centrifugal pump after it has been treated by the proposed qualitative approach to detect its FD. (a) A semi-transparent rendering of the DMU, detected CIs of type interference are shown in dark black. (b) A cross-section cut has been applied to the generated DMU to show internal parts. Recognized components are a capscrew in green, nuts in blue, studs in yellow, plug screws in cyan and a set screw in magenta.Application to industrial examples 171 (a) (b) Figure 8.5: Two different conventional representations of an inner thread corresponding to a screw thread. (a) The inner thread is represented with detailed helical shape on the screw, while the outer thread is simplified as a simple cylinder on the housing. This leads to a complex interference zone, which highly depends on components relative position. (b) The inner thread, as well as the outer thread, are represented as cylinders, leading to a cylindric interference between these two components. regardless whether it is a cap nut or a simple nut with hole, as long as it satisfies the nut functionality, as Figure 8.4 shows. Figure 8.5a shows a different representation of the capscrew of the pump model, as compared to the one used in the first example, and illustrated closely in Figure 8.5b. In fact, different representations are due to different conventions, as discussed in Section 3.2. Our algorithm shows to be general enough to recognize both conventions, and interpret them correctly, as the figure shows. In fact, even though the convention illustrated in Figure 8.5a represents the thread in more details with a helical shape at the capscrew side, generating a fairly complex geometric interface, the geometric analyzer of the proposed application reduces it to a simple cylindrical interference to allow the subsequent qualitative reasoning to take place. The real shape of its geometric interface is highly dependent on positioning parameters that are usually relaxed during the designing phase, it has thus to be simpli- fied before it is mapped to an interpretable CI. Here, the analysis based on the relative position of cylindrical surfaces is the key property of this simplification process. Table 8.1 shows execution time for the example of the centrifugal pump, run on a machine with an Intel� CoreTM 2 Duo processor at 2.40GHz and 4GB of memory. It also shows how execution time varies with respect to the number of detected FDs that decides the size of the underling ontology;172 Chapter 8. Results and Comparative Study Table 8.1: Execution time of the proposed method (in seconds), run against the example of the centrifugal pump, as a function the number of detected FDs. Number of detected FDs 3 4 5 6 Execution time (seconds) 15.69 16.26 16.34 16.54 i.e., the number of its rules. Another example that is used to evaluate the proposed method scalability is the root joint example. This structure is a small subset of an aircraft structure connecting a wing to the aircraft fuselage. It is a use-case set during the ROMMA project [1] submitted by Airbus as project partner. Figure 8.6 shows the model of the root joint as an output of the suggested application. The DMU of the root joint contains 148 components. The geometric analysis of such a model shows that components connect to each other through 512 geometric interfaces. It is worth noticing that the execution time of the geometric processing and qualitative analysis is negligible when compared to that of the semantic reasoning, done externally to our application by means of a DL reasoner. In fact, even though DL reasoning complexities have well-known and understood bounds, those bounds are shown to be ExpTime-complete in the general case [27]. Many factors influence the DL reasoning time, among which the amount of provided facts, that is in our case a function of the number of components and CIs. Another important factor is the size of the ontology, which dictates the number of rules taken into account when the reasoning takes place (see Table 8.1). To alleviate the time complexity problem while dealing with large-scale industrial models, an ontology can be simplified to only include rules that define FD that are relevant to the studied model and phenomenon. Such an adaptive ontology has been applied to the root joint example to allow reasoning in a timely manner (less than one minute on a personal computer) while still giving relevant and accurate results. In the above-mentioned example, the ontology rules were reduced to only recognize capscrews, nuts, and locking nuts. It has to be noticed however that the general ontology used efficiently against the centrifugal example, is also used against a sub-assembly of the root joint as shown in Figure 8.3, while keeping execution time reasonable (few seconds). In this case, and instead of reducing the number of rules in an ontology, the number of facts is decreased by examining only a sub-assembly of the whole DMU. Similarity and symmetry properties can then be used to generalize obtained conclusions to the rest of the DMU while keeping timely execution. Figure 8.7 shows execution time of the proposed methodIntegration with FEA pre-processors 173 Figure 8.6: An industrial example of a root joint after it has been processed by the proposed application. Recognized FD in this model are capscrews, nuts, and locking nuts. run against the example of root joint, as well as other sub-assemblies of the same structure. Execution time is plotted as a function of the number of components in each substructure. Experiments are run on a machine with an Intel� CoreTM 2 Duo processor at 2.40GHz and 4GB of memory. 8.3 Integration with FEA pre-processors The proposed approach has proved to integrate seamlessly with automatic FEA pre-processing task [42] as to meet its target. In fact, the output of the proposed application can be fed to a FEA pre-processor as its input. A preprocessor that is aware of the ontology we put forward in Section 7.4.1 can then read the produced functionally enriched DMU, in its STEP format, as well as the FD of each component, in order to prepare a simulation model, while taking into account the simulation objectives (see Figure 1.19). Functional information available in the produced model allows the pre-processor to robustly relate geometry at different levels, i.e., geometric interface, component, and component group, to functionality as defined in the ontology. The pre-processor can then choose the adequate simplifications and/or idealizations to apply on that particular geometric zone in lights of simulation174 Chapter 8. Results and Comparative Study Figure 8.7: Execution time of the proposed approach against the example of root joint and its sub-assemblies, as a function of number of components. objectives and hypotheses. Figure 8.8 shows how the template-based approach proposed in [42] builds on functional annotations provided by the hereby proposed application to simplify a bolted joint connection in accordance with simulation purposes. To allow geometric pre-processing, a set of templates are defined, to which a set of transformations can be associated, according to simulation objectives. For example, the functional group of bolted joint is first recognized as it is labeled as a assembly joint with threaded link by the hereby proposed approach. It is thus matched to a template T. Links are also established between elements of T and functional group components and interfaces, based on their FDs and FIs. This is made possible because the DMU, restructured and functionally enriched through the proposed approach, is no longer a mere annotation of components but this annotation relates to the geometric structure of components using their FIs and load cycles that completely define each bolted joint. Once components and interfaces are matched to template elements, geometric transformations can be applied and adapted to the screw diameter, the number of plates tightened together, the type of screw head, the existence or not of locking nuts, i.e., the template is largely parameterized and becomes generic. Rather than selecting individually each component and performing low level geometric tasks on each component, the engineer can now select components based on their functional meaning, here the assembly joint with threaded link, which is very useful in the present case to transform the screws and nuts into connectors as needed for FEA simulation purposes. In the illustrated case, and for the sake of structural simulation, the locking nut was first removed as its functionality was detected as secondary by the template T. The capscrew and the nut were then merged together, removing the binding threaded link. Loads are created as normal to theConclusions 175 Locking Nut Nut Screw Threaded Link Pre-load Pressure Friction Domain Decomposition (a) (b) (c) (d) (e) Figure 8.8: A template-based simplification of a bolted joint assembly for FEA simulation purposes [42]. (a) The original sub-assembly model annotated with FD and FI as an outcome of the hereby proposed application. Since it is recognized as an assembly joint with threaded link, the subassembly is matched with a template T. (b) The locking nut is removed, as recognized as a secondary FD in the context of assembly joint with threaded link by T. (c) The removal of the threaded link to merge the screw and the nut. (d) Domain decomposition takes place around the cylindric support interaction zone. (e) Screw head transformation extends the range of screws to flat-headed ones. planar support, while friction areas are added under the screw head and the planar support of the nut. Then, the object resulting from the fusion of the capscrew and the nut is further simplified as a flat-headed fastener. Finally, the load cycle of each bolted junction gives access to the plates it tightens and a sub-domain can be created in these plates around the screw as needed to set frictions areas between the plates and adapt the FE mesh generation technique in that area. This generates a simulation model that complies with hypotheses and objectives, and readily allows the generation of the FEM. Overall the proposed approach enabled the time reduction in processing this model from five days to interactively process this DMU as required by an engineer with the current software tools to one hour with the newly proposed approach using the template-based operator exploiting the enriched DMU with the functional information generated by the proposed approach. 8.4 Conclusions In this chapter the proposed approach has been studied from a pragmatic standpoint. Developed algorithms and advocated methods have been put to test with concrete examples to evaluate their validity and scalability. Results show the merit of a qualitative approach, which generates functional knowledge from a purely geometric model, based on an adaptive set of domain expert rules, while taking into account mainstream industrial practices and conventions. They also show potentials of enhancement and176 Chapter 8. Results and Comparative Study optimization. The following chapter concludes this work, and presents some perspectives to extend this work.Chapter 9 Conclusions and Perspectives 9.1 Conclusions The proposed approach to structure and enrich DMUs with functional information has analyzed, in a first place the effective content of DMUs in terms of functionally related information available as well as other technological information that could be processed to meet our objective. Chapter 1 showed that B-Rep models of components where the generic basis available in any CAD or FEA software and other technological or functionally-related information was sparse and, generally inexistent. The DMU structure, i.e., its hierarchical description, as well as position constraints or kinematic connections between components are not intrinsic to a DMU. The DMU structure may not reflect its kinematic behavior and position constraints or kinematic connections between components, when available, are not intrinsically related to the interfaces between these components. Similarly, component names are not reliable information that can be related somehow to component functions. Consequently, the proposed approach has been based on the B-Rep models of components, positioned in 3D space independently of each other, as DMU representation that can be reliably used as input for our enrichment process. The analysis of prior work (see Chapter 2) has shown that functional information has been processed mostly through top-down approaches, with function definitions loosely related to the geometric entities, i.e., faces, edges, vertices, of components. Strong dependencies, however, between shape – function – behavior is commonly recognized though not formalized in details from a geometric point of view. Feature-based approaches on standalone components have led to numerous applications, however, functional information has not been fruitfully addressed. Processing assembly models brought more information about their geometric interfaces but few contributions addressed this level and none of them focused on the enrichment with functional information. Design knowledge modeling and KBE178 Chapter 9. Conclusions and Perspectives approaches added design and functional knowledge to components, essentially through interactive means, KBE approaches being more automatized but reduced to a narrow application range. Anyhow, the technological or functional information is loosely connected to the component shape and does not strongly influence the geometric structure of components. Where ontology-based approaches have been proposed, reasoning capabilities have rarely been proposed, KBE ones however extensively use dedicated behaviors for very specific applications. The proposed approach is bottom-up to take advantage of intrinsic and robust data as input, i.e., component shape and their relative positions. Also, it is tightly related to shape – function – behavior dependencies, which have not been precisely investigated to the best of our knowledge. Ontology-based reasoning processes bring a well formalized framework with algorithmic complexity characterization that brings more efficiency compared to the use of ruled-based systems used in the CAD area in prior work. From these settings, Chapter 3 pointed out that frequently, a real component shape does not match its digital representation. This difference has to be taken into account since it influences the geometric interfaces between components, hence the reasoning processes that can be set up from digital models of components must take into account these differences. Because the concept of function tightly relates to the concept of interactions between components, the focus has been placed on the geometric interfaces between components. The differences between real and digital shapes has been formalized through the concepts of CIs and FIs and knowledge related to these interfaces has been structured through appropriate taxonomies (see Chapter 3 and Chapter 4). Indeed, the differences between real and digital interfaces between components end up as multiple interpretations that require a reasoning process to filter them out and generate a DMU enrichment process that can be automated. The determination of the geometric interfaces between components is not a straightforward process, as pointed out in Chapter 5. This chapter has shown how the accurate definition of imprints of interfaces between components can be sped up and obtained. Though digital shapes of components lead to three categories of interfaces, i.e., contact, clearance and interference, their analysis has concluded that contacts and interferences are the only intrinsic categories that can be used initially to enrich an assembly model with functional information. This choice is consistent with respect to the definition of an approach that relies on intrinsic information. The taxonomy of FIs connected to the precise geometric description of interfaces over components is a first setting of the dependency between shape and function. At this stage, components geometric models are structured as well as the assembly model through its CIG. All this information and the structured models can now be used to take advantage of dependencies between shape, function, and behavior to filter out the multiple interpretations existing atConclusions 179 some component interfaces. To this end, the concept of reference state has been introduced that can be associated with a wide range of DMU configuration throughout a PDP. Then, several qualitative behaviors have been described that rely on generic mechanical properties, i.e., static equilibrium of a component, load propagation cycles, and statically indeterminate configurations, and enable to filter out FIs (see Chapter 6). These reference states are automatically applied and stand for a first reasoning process performed algorithmically. Therefore, its efficiency can be analyzed and its termination can be established. These reference states, as well as the FIs cover only a subset of the possible interfaces between components. Consequently, the straightforward application of these qualitative behavioral models to an arbitrary DMU can lead to incomplete results if CIs are not falling into the proposed taxonomy. In a correct setting, however, the qualitative analysis produces a unique FI per CI, which strengthens the relationship between each CI and its corresponding FI. The DMU thus obtained is consistent at the interface-level and knowledge has been gained at the cluster-level, which structures further the assembly model. Finally, the previous results are input in the second step of reasoning, which is based on a ontological approach. The previous taxonomies of FIs are associated with a pre-defined, generic taxonomy of FDs to lead to the assignment of an FD per component. This parameter becomes an identifier of a component that combines with its FIs and its geometry structured with the imprints of its CIs and other FIs of neighboring components as required by its FD to form the generic information characterizing functionally the component inside its DMU (see Chapter 7). The FD assignment process is obtained through a rule-based process. Inferences are expressed using descriptive logic whose algorithmic complexity is established. Consequently, the overall process of DMU enrichment is guaranteed to terminate and its algorithmic complexity can be mastered. The enrichment is now obtained at component-level as well as component cluster-level. This process is therefore well suited for industrial DMUs and particularly complex ones as they can appear in the aircraft industry. The enrichment thus obtained is robust, i.e., it is consistent and independent of user’s interactions, since the enrichment process is automatic. Chapter 8 has illustrated the results of the proposed approach with various examples. The DMU functional enrichment thus obtained has been successfully used in the context of FEA preparation processes. There, it can be demonstrated how the functional enrichment can contribute to the component selection process for fasteners and save a fair amount of time. Also, Chapter 7 and Chapter 6 have shown how they can be extended to analyze the consistency of a DMU.180 Chapter 9. Conclusions and Perspectives 9.2 Perspectives Applications in Virtual Reality and Motion Planning Although FEA model preparation is the first major objective behind this work, applications are not restricted to this and other applications in a PDP can benefit from the proposed approach. We show how our approach fits other applications such as virtual and augmented reality and robotic and motion planning. VR Applications in PDP DMU geometric model can be employed in VR applications, where the users are immersed in a virtual environment and they can manipulate the product and simulate its use and ergonomics. In return, virtual and augmented reality techniques, varying from simple visualization to fully-immersive environments, can be applied to PDP at different stages such as design and assembly/disassembly planning and simulations [38, 141, 150]. VR approaches use simplified and approximate physical models to model interactions between user avatars and other objects, and between objects themselves, to allow real-time simulation of such an interaction. These models are good enough to simulate a huge portion of expected interactions. However, and for certain cases, a particular physical model fails to provide realistic results. An example is contact simulation between rigid bodies where collision detection algorithms are used to recognize contacts, and generate appropriate forces. Such methods are usually based on objects tessellated model (see Section 1.5.2). However, for special cases such as shaft/bushing connections, simulation based on simple collision detection algorithms generates an unstable behavior of haptic devices, as simplified physical hypotheses and object dimensions are not compatible with the conventional representation of components in a PDP. In such a case, when the shaft approaches the housing, reciprocal forces are generated from the bushing edges that push the shaft away because the shaft and bushing diameters are either equal or closer to each other than the geometric deviation used in collision detection algorithms, thus preventing the desired sliding effect between these components. Efforts have been paid to account for this inconvenience, where early work shows how to use objects and agent specific attributes in order to realize motion planning. Levison & Badler use behavioral object knowledge to build an object-specific reasoner to enable a high-level action planning [110]. Kallmann & Thalmann propose a virtual interactive environment in which smart objects define how they can be used and interacted with, by means of a set of possible states, conditions, and instructions [96]. This allow the adaption of the underlying physical model to the particular action to be performed, avoiding unrealistic effect such as the shaft/bushing phenomenon.Perspectives 181 Jorissen & Lamotte generalize this approach to enable interaction between all objects and human avatars in a virtual environment [93]. All previously presented approaches require functional annotations of objects in order to assign them an appropriate behavior and interaction scheme at the correct location around each object. In the presented works this knowledge is provided during the design time of objects and virtual environments, which suffer problems as mentioned in Chapter 2 and Chapter 4. To allow the application of VR and motion planning to large scale models, such as a product DMU, the manual functional annotation becomes cumbersome (as seen in Section 3.4). Our works proposes an automated method to boost functional annotations of objects and enable the location of interfaces between components as a complement of prior work [89]. Incorporating usage patterns based on objects functionality enables the application of the above-mentioned approaches to industrial scale models and environments because of the tight relationship between geometry, i.e., some local areas of components, function as assigned through the proposed approach, and behavior as needed for these simulations. Consequently, dedicated VR simulation models could be trigged whenever needed for an interaction during a VR simulation process. The use of appropriate VR component behavior become transparent for the user, it is interaction-driven. Contributions to CAD-to-FEA transformations In their recent work, Boussuge et al. [42] introduced a set of automated geometric transformations of CAD models in preparation for FEA. The transformations are based not only on the mere geometry of the model, but also on supplementary simulation-relevant annotations that go through functional groups of components down to the geometric zones that delimit functional interactions between pairs of components. This approach uses the work presented in this manuscript to structure the geometric model of components and connect this new structure to such functional annotations. The categories of components under focus were fasteners. This need to be extended with a larger range of categories of components to take advantage of the proposed principle. To this end, the qualitative approach needs to be extended with new reference states, particularly those that can refer to kinematics, i.e., relative movements between components. This would enable the identification of kinematic equivalence classes and their corresponding components in a DMU. Reasoning with these additional reference states would open the possibility to set up new inferences to categorize components of type bearing, gears, couplings, etc. Even though the scheme described in the manuscript joins KBE in some aspects, it is however a more robust approach. This is because functional182 Chapter 9. Conclusions and Perspectives designations and functions are generic concepts in our approach. KBE aims at structuring engineering knowledge and processing it with symbolic representations [47, 143] using language based approaches. In this work, the focus is placed on a robust connection between geometric models and symbolic representations featuring functions, which has not been addressed in KBE and, therefore, could be used in KBE approaches to extend their range and improve their robustness when DMUs are modified during a PDP. Additionally, KBE approaches as well as CAD-to-FEA transformations show that the proposed approach can be regarded as a means to analyze and structure a DMU at various stages of a PDP. Among these stages, the design process, and even the early stages, can benefit from the proposed approach to automate the enrichment of a DMU with functional information in a top-down manner. As pointed out in Chapter 2, many design approaches based on hierarchical decompositions face difficulties when refining the design downward to detailed geometric configurations. These hierarchical decompositions needs evolutions to meet the graph-based approach that is intrinsic to many mechanisms, as shown by the CIG, the load cycles, and the complexity of inference processes. The proposed DMU enrichment process is robust with respect to a range of conventional representations of components, the influence of these representations has not been addressed with respect to the enrichment process to evaluate how it can be further improved or how it is robust to variants of representations. Studying these issues would help setting up principles and/or standards for a more efficient processing of DMUs at many stages of a PDP. Similarly, studying the robustness of the enrichment process with respect to variants of representations of components open the possibility to design more tolerant software environments that would refer to a sketch-based paradigm though they would stay robust while being more user-friendly.Appendix A Fit Tolerancing and Dimensioning In mechanical engineering, a fit refers to a mating of two mechanical components; on is a containing housing, referred to as the female part, and the other is a contained shaft, referred to as the male part. In technical drawing, both shaft and housing have the same nominal diameter. Tolerancing, however, decides whether it is a snug fit, loose fit, or nondeterminate fit. ISO defines how to annotate drawing with such information in a standardized manner. The tolerance is denoted by a tolerance code that constitutes of a letter followed by a number. The letter defines the deviation from the nominal dimension as a function of it. Small letters are used to dimension shafts by defining the maximal deviation es = dmax −dnom, while when used for housings the letter is capitalized defining minimal deviation EI = Dnom − Dmin. For example, the letter H means zero distance from the nominal diameter for the housing (referential housing), while the letter h means zero distance from the nominal diameter of the shaft (referential shaft). Table A.1 shows tolerance letters for defining maximal and minimal deviation of shaft and housing dimension (respectively) as a function of nominal dimension. Tolerance letters are followed by a number, defining tolerance quality. The number is proportional to the tolerance, thus disproportional to the manufacturing quality. Table A.2 shows 18 tolerance qualities defined by ISO as a function of the nominal dimension. Since the machining the shaft is more precise, shaft tolerance is usually of higher quality rather than that of the housing. The combination of the tolerance codes of each of the shaft and the housing decides whether the fit is sung, loose, or nondeterminate. Nominal dimensions are expressed in millimeters, after a symbol that184 Chapter A. Fit Tolerancing and Dimensioning Table A.1: ISO deviation codes showing deviation of the nominal dimension in µm as a function of nominal dimension (in mm). Lettre c cd d e ef f fg g h ≤3 -60 -34 -20 -14 -10 -6 -4 -2 0 >3 & ≤ 6 -70 -46 -30 -20 -14 -10 -6 -4 0 >6 & ≤ 10 -80 -56 -40 -25 -18 -13 -8 -5 0 >10 & ≤ 14 -95 – -50 -32 – -16 – -6 0 >14 & ≤ 18 -95 – -50 -32 – -16 – -6 0 >18 & ≤ 24 -110 – -65 -40 – -20 – -7 0 >24 & ≤ 30 -110 – -65 -40 – -20 – -7 0 >30 & ≤ 40 -120 – -80 -50 – -25 – -9 0 >40 & ≤ 50 -130 – -80 -50 – -25 – -9 0 >50 & ≤ 65 -140 – -100 -60 – -30 – -10 0 >65 & ≤ 80 -150 – -100 -60 – -30 – -10 0 >80 & ≤ 100 -170 – -120 -72 – -36 – -12 0 >100 & ≤ 120 -180 – -120 -72 – -36 – -12 0 >120 & ≤ 140 -200 – -145 -85 – -43 – -14 0 >140 & ≤ 160 -210 – -145 -85 – -43 – -14 0 >160 & ≤ 180 -230 – -145 -85 – -43 – -14 0 >180 & ≤ 200 -240 – -170 -100 – -50 – -15 0 >200 & ≤ 225 -260 – -170 -100 – -50 – -15 0 >225 & ≤ 250 -280 – -170 -100 – -50 – -15 0 >250 & ≤ 280 -300 – -190 -110 – -56 – -17 0 >280 & ≤ 315 -330 – -190 -110 – -56 – -17 0 >315 & ≤ 355 -360 – -210 -125 – -62 – -18 0 >355 & ≤ 400 -400 – -210 -125 – -62 – -18 0 >400 & ≤ 450 -440 – -230 -135 – -68 – -20 0 >450 & ≤ 500 -480 – -230 -135 – -68 – -20 0 Lettre C CD D E EF F FG G H ≤3 +60 +34 +20 +14 +10 +6 +4 +2 0 >3 & ≤ 6 +70 +46 +30 +20 +14 +10 +6 +4 0 >6 & ≤ 10 +80 +56 +40 +25 +18 +13 +8 +5 0 >10 & ≤ 14 +95 – +50 +32 – +16 – +6 0 >14 & ≤ 18 +95 – +50 +32 – +16 – +6 0 >18 & ≤ 24 +110 – +65 +40 – +20 – +7 0 >24 & ≤ 30 +110 – +65 +40 – +20 – +7 0 >30 & ≤ 40 +120 – +80 +50 – +25 – +9 0 >40 & ≤ 50 +130 – +80 +50 – +25 – +9 0 >50 & ≤ 65 +140 – +100 +60 – +30 – +10 0 >65 & ≤ 80 +150 – +100 +60 – +30 – +10 0 >80 & ≤ 100 +170 – +120 +72 – +36 – +12 0 >100 & ≤ 120 +180 – +120 +72 – +36 – +12 0 >120 & ≤ 140 +200 – +145 +85 – +43 – +14 0 >140 & ≤ 160 +210 – +145 +85 – +43 – +14 0 >160 & ≤ 180 +230 – +145 +85 – +43 – +14 0 >180 & ≤ 200 +240 – +170 +100 – +50 – +15 0 >200 & ≤ 225 +260 – +170 +100 – +50 – +15 0 >225 & ≤ 250 +280 – +170 +100 – +50 – +15 0 >250 & ≤ 280 +300 – +190 +110 – +56 – +17 0 >280 & ≤ 315 +330 – +190 +110 – +56 – +17 0 >315 & ≤ 355 +360 – +210 +125 – +62 – +18 0 >355 & ≤ 400 +400 – +210 +125 – +62 – +18 0 >400 & ≤ 450 +440 – +230 +135 – +68 – +20 0 >450 & ≤ 500 +480 – +230 +135 – +68 – +20 0185 Table A.2: ISO tolerance codes showing tolerance margin in µm as a function of nominal dimension (in mm). Quality 01 0 1 2 3 4 5 6 7 ≤ 3 0,3 0,5 0,8 1,2 2 3 4 6 10 > 3 & ≤ 6 0,4 0,6 1 1,5 2,5 4 5 8 12 > 6 & ≤ 10 0,4 0,6 1 1,5 2,5 4 6 9 15 > 10 & ≤ 18 0,5 0,8 1,2 2 3 5 8 11 18 > 18 & ≤ 30 0,6 1 1,5 2,5 4 6 9 13 21 > 30 & ≤ 50 0,6 1 1,5 2,5 4 7 11 16 25 > 50 & ≤ 80 0,8 1,2 2 3 5 8 13 19 30 > 80 & ≤ 120 1 1,5 2,5 4 6 10 15 22 35 > 120 & ≤ 180 1,2 2 3,5 5 8 12 18 25 40 > 180 & ≤ 250 2 3 4,5 7 10 14 20 29 46 > 250 & ≤ 315 2,5 4 6 8 12 16 23 32 52 > 315 & ≤ 400 3 5 7 9 13 18 25 36 57 > 400 & ≤ 500 4 6 8 10 15 20 27 40 63 Quality 8 9 10 11 12 13 14 15 16 ≤ 3 14 25 40 60 100 140 250 400 600 > 3 & ≤ 6 18 30 48 75 120 180 300 480 750 > 6 & ≤ 10 22 36 58 90 150 220 360 580 900 > 10 & ≤ 18 27 43 70 110 180 270 430 700 1 100 > 18 & ≤ 30 33 52 84 130 210 330 520 840 1 300 > 30 & ≤ 50 39 62 100 160 250 390 620 1 000 1 600 > 50 & ≤ 80 46 74 120 190 300 460 740 1 200 1 900 > 80 & ≤ 120 54 87 140 220 350 540 870 1 400 2 200 > 120 & ≤ 180 63 100 160 250 400 630 1 000 1 600 2 500 > 180 & ≤ 250 72 115 185 290 460 720 1 150 1 850 2 900 > 250 & ≤ 315 81 130 210 320 520 810 1 300 2 100 3 200 > 315 & ≤ 400 89 140 230 360 570 890 1 400 2 300 3 600 > 400 & ≤ 500 97 155 250 400 630 970 1 550 2 500 4 000 defines the shape of the fit, �for instance is used for cylindric fits. In the case of cylindric fit, the nominal dimension is the nominal diameter. For single parts, the dimension and tolerance is expressed by a sequence of shape symbol, nominal dimension, tolerance code. For example �50H7 defines a referential housing with 50mm nominal dimension while �13g6 defines a shaft with 13mm nominal dimension. For assemblies, the symbol and nominal dimension are followed by housing tolerance, then shaft tolerance codes. For example, in Figure 1.2 �69H8f7 refers to a cylindric loose fit of 69mm nominal diameter. Considering Table A.1, it is worth noticing that switching tolerance letter of assemblies do not change the fit nature. For instance H7f7 defines the same loose fit as F7h7, and H7p6 defines the same snug fit as P7h6.Appendix B Dual Vectors Dual numbers Dual numbers [53] are defined in a similar way that complex numbers are. In analogy to the imaginary number ı that is used to define the imaginary part of a complex number, the dual number ε is used to define the dual part of a dual number. The dual number, however, is defined as non-zero element whose powers are zeros, leading to different arithmetics than imaginary numbers. The dual number is therefor called nilpotent. General dual number ring Provided G = {0, 1, ε} with multiplication operator ., where ε �= 0 ε2 = 0. we notice that (G, .) is a semigroup with 1 as identity. Definition B.1 (General dual number ring). A general dual number ring is the semigroup ring [98] of the semigroup G over a ring R [99]. A general dual number is then expressed as ˆx = a + εb where a, b ∈ R. Addition and multiplication are extended on dual numbers. Given ˆx = xa + εxb and ˆy = ya + εyb where xa, xb, ya, yb ∈ R, we write: xˆ + ˆy = (xa + ya) +ε(xb + yb) xˆ − yˆ = (xa − ya) +ε(xb − yb) xˆ × yˆ = (xaya) +ε(xayb + xbya) division ˆx = aˆ ˆb is defined as the solution of the equation ˆa = ˆb × xˆ. We note that dual scalars are general dual numbers defined over the real numbers ring (R, +, .).188 Chapter B. Dual Vectors Dual vectors When ring R in Definition B.1 is a vector field, the semigroup ring of G over R defines a dual vector ring. A dual vector is denoted as ˆ w� = �v + ε�u where �v, �u ∈ R. Dual semifields Dual numbers can apply not only to rings (and fields) but also to semi- fields [98]. Definition B.2 (General dual number semi-ring). A general dual number semiring is the semigroup semiring [98] of the semigroup G over a semifield (thus a semiring) R [99]. This extends the use of dual numbers to structures where not every element has a multiplication inverse.Appendix C Screw Theory Mechanical crews Screw theory [31] studies solid-bodies dynamics and kinematics. In a search of a mathematical tool that can abstract both concepts while still accounting for objects geometry, the theory proposes the use of screws, which it defines as follows. Definition C.1 (Screw). A screw is an ordered 6-tuple. The first triple represents a line Euclidean vector associated, and the second triple represents a free Euclidean vector applied to a point [19]. Each triple represents vector coordinate with respect to a coordinate system B = {o, e�x, e�y, e�z}, where o is the origin of coordinates, e�x, e�y and e�z are orthogonal right-handed unit vectors. The origin o then defines the point to which the second vector is bound. The screw can then be expressed as follows. {v�1|v�2} =    vx 1 vx 2 vy 1 vy 2 vz 1 vz 2    The carrier line of the first vector is defined by v�1 itself, and a Euclidean vector �r = v�1 × v�2 which defines a point on that line. As mentioned above, screws are abstract mathematical tools. In order to interpret screws, a context, either dynamic or kinematic, should be given. Twist about a screw Chasle theory showed that motion of a rigid body between two position can be represented by a translation along an axis, and a rotation about the same axis. The motion of a rigid body can thus be presented by a screw. In this case, the first triple in the screw represents the angular velocity �ω;190 Chapter C. Screw Theory its direction represents the rotation axis, while its magnitude represents the rotation angle per time unit. The second triple represents the linear velocity at the origin �v. Such a vector is then referred to as twist, and written as follows. T = {�ω|�v} =    ωx vx ωy vy ωz vz    Wrench on a screw Poinsot theory showed that the system of external forces acting on a rigid body can be reduced to a force and a torque on plane perpendicular to this force. The system of external forces acting on a rigid body can thus be represented by a screw. In this case, the first triple in the screw represents the force �f. The second triple represents the torque at the origin m� . Such a vector is then referred to as wrench, and written as follows. W = { �f|m� } =    fx mx fy my fz mz    Co-moment of two screws The co-moment of two screws A = {a�1|a�2} and B = {�b1|�b2} is defined as follows: A � B = a�1 · �b2 + �b1 · a�2. When one of the screws is a wrench screw W, while the other is a twist screw T, the co-moment of the two screws define their power. P = W � T = �f · �v + m� · �ω. We can then state that the work done by a wrench screw W to displace a rigid body body by a twist screw T during a time interval dt equals to dW = (W � T)dt. Reciprocal screws Two screws are said to be mutually reciprocal if their virtual coefficient is zero [31]. This means that the work done by a wrench on the first screw to displace a rigid body by a twist about the second one is null over time [134].191 Definition C.2 (Reciprocal screws). A pair of wrench screw W = { �f|�t} and twist screw T = {�ω|�v} is reciprocal when the virtual work of the wrench on the twist equals zero. Screws as dual vectors Literature suggest the representation of screws, either twists or wrenches, as dual vectors [36, 100]. Thus, a screw S = {v�1|v�2} can be written as S = v�1 + v�2ε. In the current work we adopt this convention. This allows the direct application of algebraic properties of dual fields or dual semifields, depending on the underling structure use: rings or semirings respectively.Appendix D Description Logic Decidability Description Logic (DL) is a family of formal languages that deals with decidable fragments of FOL [17]. It incorporate different languages that vary according to their level of expressiveness. In fact, some DL variant go beyond FOL capacities and define constructs that requires higher order logics, they remain however decidable [28]. DL languages exhibit well-understood computational behaviors. Logic’s primitives DL models the world by means of three logical entities. Individuals that represent objects in the modeled world. Individuals are comparable to constants in FOL. Concepts that represent objects sets in the modeled world. Concepts are comparable to unary predicates in FOL. Roles that represent objects relations in the modeled world. Roles are comparable to binary predicates in FOL. Sets of primitive concepts and roles that identify a given domain are first defined in a knowledge base. Primitive concepts are referred to as concept names and primitive roles as role names. Language constructs are used to extends the number of concepts that can be expressed by the language. Newly introduced concepts are described using other role names, concept names and concept descriptions, by means of language constructs. New roles can also be described the same way, and used in concept descriptions. The set of constructs allowed in a DL language dictates its expressiveness. A kernel set of constructs that is embedded in all DL languages is194 Chapter D. Description Logic Table D.1: A subset of DL constructs, their OWL equivalents, and their semantics in terms of interpretations under the domain of discourse Δ. GCI and axioms’ equivalents and interpretations are also shown [17, 28, 179]. DL construct OWL equivalent Construct semantic ALC constructs � owl:Thing Δ ⊥ owl:Nothing ∅ C � D owl:intersectionOf C ∩ D C � D owl:unionOf C ∪ D ∀r.C owl:allValuesFrom {x, ∀y ((x, y) ∈ r ⇒ y ∈ C)} ∃r.C owl:someValuesFrom {x, ∃y ((x, y) ∈ r ∧ y ∈ C} ¬C owl:complementOf Δ/C Other constructs r ∈ p rdfs:subPropertyOf ∀x, y ((x, y) ∈ r ⇒ (x, y) ∈ p) r − owl:inverseOf {(x, y),(y, x) ∈ r} GCI C � D rdfs:subClassOf C ⊆ D C ≡ D owl:equivalentClass C = D Axioms C(x) rdf:type x ∈ C r(x, y) :r (x, y) ∈ r referred to as ALC. In fact, ALC is a DL language on its own, that is the simplest among its counterparts. Table D.1 lists ALC constructs, and their respective equivalents in OWLDL. Language semantics DL is credited for its well-defined semantics. Semantics of the logic are defined at the level of linguistic constructs in terms of interpretations. An interpretation is possible under a domain of discourse Δ, whenever Δ �= ∅. It maps each concept C to a set C ∈ Δ, and each role r to a relation r ∈ Δ×Δ. Table D.1 shows the interpretation of each of ALC constructs with respect to a domain of discourse Δ. The TBox T of a knowledge base is defined in terms of a finite set of General Concept Inclusion (GCI). A GCI is a restriction of the type C � D, where C and D are DL-concepts. A GCI of the type C � D is interpreted as C ⊆ D. A TBox T is interpreted as the conjunction of the interpretations of all its GCIs. Note that a concept equivalence, written C ≡ D is a syntactic sugar of195 the conjunction of two GCI; C � D and D � C. If one of the concepts in C ≡ D is a concept name, the statement is then called a definition. The ABox A of a knowledge base is defined in terms of a finite set of axioms. An axiom can be of the type C(x) where C is a concept and x is an individual. Such an axiom is interpreted as x ∈ C. Alternatively, an axiom can be of the form r(x, y) where r is a role, and x and y are individuals. Such an axiom is interpreted as (x, y) ∈ r. An ABox A is interpreted as the conjunction of the interpretations of all its axioms. A knowledge base K = �T , A� is interpreted as the conjunction of the interpretations of its TBox and its ABox. Expressive power GCIs allow for the expression of domain knowledge in term of rules. They can be used to represent concepts hierarchy in the modeled world, e.g. Student � Person that states that all studets are people. They can also be used to restrict the domain of a role, e.g. ∃teachs.� � Teacher that states that only teachers can teach. They can even express more complex rules such as ∃teachs.Math � Teacher � ∃hasDegree.SientificDiploma that states that in order to teach math, one has to be a teacher with at least one scientific degree. We note that expressiveness of the language is highly dependant on the allowed structures. For instance, with ALC only we cannot put restrictions on roles range. To this end new constructs were added to ALC, producing new DL languages, at the expense of some computational advantages. For example, the introduction of the inverse role allows the expression of range restrictions, and much more. Given a role r, an inverse role r − is defined and interpreted as r− = {(x, y),(y, x) ∈ r}. More constructs are also defined such as transitive roles, subroles, concrete domains and nominals. A convention exists to name DL languages by adding a letter to the name for each introduced construct. To avoid lengthy names, the core language ALC augmented by transitive roles is abbreviated as S. In this work we are particularly interested in the language SHOIQ, which supports nominals O, inverse roles I, and qualified cardinality restriction Q, besides core constructs S. A more expressive language variant, SROIQ [88], is supported by OWL-DL since version 1.1.Bibliography [1] ANR ROMMA project. http://romma.lmt.ens-cachan.fr. [2] cURL. http://curl.haxx.se/. [3] Prot´eg´e ontology editor. http://protege.stanford.edu/. [4] TraceParts. http://www.traceparts.com. [5] World Wide Web Consortium. http://www.w3.org. [6] Xerces-C++ XML parser. http://xerces.apache.org/xerces-c/. [7] ISO 10303-1:1994. Industrial automation systems and integration – Product data representation and exchange – Part 1: Overview and fundamental principles. Standard, International Organization for Standardization, Geneva, Switzerland, 1994. [8] ISO 10303-203:1994. Industrial automation systems and integration – Product data representation and exchange – Part 203: Application protocol: Configuration controlled 3D design of mechanical parts and assemblies. Standard, International Organization for Standardization, Geneva, Switzerland, 1994. [9] ISO 10303-28:1998. Industrial automation systems and integration – Product data representation and exchange – Part 28 - Implementation methods: XML representations of EXPRESS schema and data. Standard, International Organization for Standardization, Geneva, Switzerland, 1998. [10] ISO 10303-21:2002. Industrial automation systems and integration – Product data representation and exchange – Part 21: Implementation methods: Clear text encoding of the exchange structure. Standard, International Organization for Standardization, Geneva, Switzerland, 2002. [11] ISO 10303-22:2002. Industrial automation systems and integration – Product data representation and exchange – Part 22 - Implementation198 Bibliography methods: Standard data access interface. Standard, International Organization for Standardization, Geneva, Switzerland, 2002. [12] ISO 10303-214:2003. Industrial automation systems and integration – Product data representation and exchange – Part 214: Application protocol: Core data for automotive mechanical design processes. Standard, International Organization for Standardization, Geneva, Switzerland, 2003. [13] ISO 10303-11:2004. Industrial automation systems and integration – Product data representation and exchange – Part 11: Description methods: The EXPRESS language reference manual. Standard, International Organization for Standardization, Geneva, Switzerland, 2004. [14] OWL Web Ontology Language Overview. http://www.w3.org/TR/owlfeatures/, 2004. [15] DL Implementation Group. http://dl.kr.org/dig/, 2006. [16] Technical drawings – Indication of dimensions and tolerances – Part 1: General principles. Standard, International Organization for Standardization, Geneva, Switzerland, 2014. [17] Abiteboul, S., Manolescu, I., Rigaux, P., Rousset, M.-C., Senellart, P., et al. Web data management. Cambridge University Press, 2012. [18] Acheson, D. Elementary Fluid Dynamics. Oxford Applied Mathematics and Computing Science Series. Oxford University Press, 1990. [19] Adams, J. D. Feature based analysis of selective limited motion in assemblies. PhD thesis, Massachusetts Institute of Technology, 1998. [20] Agrawala, M., Phan, D., Heiser, J., Haymaker, J., Klingner, J., Hanrahan, P., and Tversky, B. Designing effective step-bystep assembly instructions. In ACM Transactions on Graphics (TOG) (2003), vol. 22, ACM, pp. 828–837. [21] Aidi, M., Tollenaere, M., and Pourroy, F. Towards a numerical simulation scheduling in an engineering system approach. In Systems, Man and Cybernetics, 2002 IEEE International Conference on (2002), vol. 4, IEEE. [22] Albers, A., Braun, T., Clarkson, P. J., Enkler, H.-G., and Wynn, D. C. Contact and channel modelling to support early design of technical systems. In Proc. International Conference on Engineering Design, ICED’09 (Stanford, CA, USA, 2009).Bibliography 199 [23] Albers, A., Burkardt, N., and Ohmer, M. Contact and channel model for pairs of working surfaces. In Advances in Design, H. A. ElMaraghy and W. H. ElMaraghy, Eds., Springer Series in Advanced Manufacturing. Springer London, 2006, pp. 511–520. [24] Albers, A., Matthiesen, S., and Lechner, G. Konstruktionsmethodisches grundmodell zum zusammenhang von gestalt und funktion technischer systeme. Konstruktion, 7-8 (2002), 55–60. [25] Allada, V., and Anand, S. Feature-based modelling approaches for integrated manufacturing: state-of-the-art survey and future research directions. International Journal of Computer Integrated Manufacturing 8, 6 (1995), 411–440. [26] Ames, A. L. Production ready feature recognition based automatic group technology part coding. In Proceedings of the First ACM Symposium on Solid Modeling Foundations and CAD/CAM Applications (New York, NY, USA, 1991), SMA ’91, ACM, pp. 161–169. [27] Baader, F., Brandt, S., and Lutz, C. Pushing the EL envelope. In Proceedings of the 19th International Joint Conference on Artifi- cial Intelligence (San Francisco, CA, USA, 2005), IJCAI’05, Morgan Kaufmann Publishers Inc., pp. 364–369. [28] Baader, F., Horrocks, I., and Sattler, U. Chapter 3 description logics. In Handbook of Knowledge Representation, V. L. Frank van Harmelen and B. Porter, Eds., vol. 3 of Foundations of Artificial Intelligence. Elsevier, 2008, pp. 135 – 179. [29] Bacon, S. Reasoning about Mechanical Devices: A Top-down Approach to Deriving Behavior from Structure. 1988. [30] Baldwin, C., and Clark, K. Design Rules: The power of modularity. Design Rules. MIT Press, 2000. [31] Ball, R. A treatise on the theory of screws. Cambridge University University Press, 1900. [32] Barbau, R., Krima, S., Rachuri, S., Narayanan, A., Fiorentini, X., Foufou, S., and Sriram, R. D. Ontostep: Enriching product model data using ontologies. Computer-Aided Design 44, 6 (2012), 575–590. [33] Barrett, C. W., Dill, D. L., and Stump, A. Checking satis- fiability of first-order formulas by incremental translation to sat. In Computer Aided Verification (2002), Springer, pp. 236–249.200 Bibliography [34] Baysal, M. M., Roy, U., Sudarsan, R., Sriram, R. D., and Lyons, K. The open assembly model for the exchange of assembly and tolerance information: overview and example. In ASME 2004 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (2004), American Society of Mechanical Engineers, pp. 759–770. [35] Berners-Lee, T., Hendler, J., Lassila, O., et al. The semantic web. Scientific american 284, 5 (2001), 28–37. [36] Bidard, C. Dual basis of screw-vectors for inverse kinestatic problems in robotics. In Advances in Robot Kinematics and Computational Geometry, J. Lenarcic and B. Ravani, Eds. Springer Netherlands, 1994, pp. 339–348. [37] Blount, G. N., Kneebone, S., and Kingston, M. R. Selection of knowledge-based engineering design applications. Journal of Engineering Design 6, 1 (1995), 31–38. [38] Blumel, E., Straßburger, S., Sturek, R., and Kimura, I. ¨ Pragmatic approach to apply virtual reality technology in accelerating a product life cycle. In Proc. of International Conference INNOVATIONS (Slany, Czech Republic, June 2004), pp. 199–207. [39] Bobrow, J. E. Optimal robot plant planning using the minimumtime criterion. Robotics and Automation, IEEE Journal of 4, 4 (1988), 443–450. [40] Bogart, K., Drysdale, S., and Stein, C. Discrete math for computer science students, 2004. [41] Boussuge, F., Leon, J.-C., Hahmann, S., and Fine, L. An analysis of DMU transformation requirements for structural assembly simulations. In The Eighth International Conference on Engineering Computational Technology (Dubronik, Croatie, Sep 2012), B.H.V. Topping, Civil Comp Press. [42] Boussuge, F., Shahwan, A., Leon, J.-C., Hahmann, S., Fou- ´ cault, G., and Fine, L. Template-based Geometric Transformations of a Functionally Enriched DMU into FE Assembly Models. Computer-Aided Design and Applications 11, 04 (2014), 436–449. [43] Briggs, C., Brown, G., Siebenaler, D., Faoro, J., and Rowe, S. Model based definition, April 2010. [44] Canny, J. F., and Lin, M. C. An opportunistic global path planner. Algorithmica 10, 2-4 (1993), 102–120.Bibliography 201 [45] Carslaw, H., and Jaeger, J. Conduction of Heat in Solids. 2nde edition. Oxford Science Publications. Clarendo Press, 1986. [46] Chakrabarti, A., and Bligh, T. An approach to functional synthesis of solutions in mechanical conceptual design. part i: Introduction and knowledge representation. Research in Engineering Design 6, 3 (1994), 127–141. [47] Chapman, C. B., and Pinfold, M. Design engineering - a need to rethink the solution using knowledge based engineering. KnowledgeBased Systems 12, 5-6 (October 1999), 257–267. [48] Chapman, C. B., and Pinfold, M. The application of a knowledge based engineering approach to the rapid design and analysis of an automotive structure. Adv. Eng. Softw. 32, 12 (Nov. 2001), 903–912. [49] Chardonnet, J.-R., and Leon, J.-C. Designing interaction in virtual worlds through a passive haptic peripheral. In 2012 IEEE RO-MAN (France, 2012), pp. 284–289. [50] Chouadria, R., and Veron, P. ´ Identifying and re-meshing contact interfaces in a polyhedral assembly for digital mock-up. Eng. with Computers 22, 1 (2006), 47–58. [51] Church, A. An unsolvable problem of elementary number theory. American journal of mathematics 58, 2 (1936), 345–363. [52] Clark, B., Hanks, B., and Ernst, C. Conformal assembly meshing with tolerant imprinting. In Proceedings of the 17th international meshing roundtable (Pittsburg, USA, 2008), Springer, pp. 267–280. [53] Clifford, W. Preliminary Sketch of Biquaternions. Proceedings of The London Mathematical Society s1-4 (1871), 381–395. [54] Condoor, S. Integrating design in engineering graphics courses using feature-based, parametric solid modeling. In Frontiers in Education Conference, 1999. FIE ’99. 29th Annual (1999), vol. 2, pp. 12D2/13– 12D2/17. [55] Corallo, A., Laubacher, R., Margherita, A., and Turrisi, G. Enhancing product development through knowledge-based engineering (kbe): A case study in the aerospace industry. Journal of Manufacturing Technology Management 20, 8 (2009), 1070–1083. [56] Curran, R., Verhagen, W. J., van Tooren, M. J., and van der Laan, T. H. A multidisciplinary implementation methodology for knowledge based engineering: KNOMAD. Expert Systems with Applications 37, 11 (2010), 7336–7350.202 Bibliography [57] Dai, F., and Reindl, P. Enabling digital mock-up with virtual reality techniques – vision, concept, demonstrator. In Design Engineering Technical Conferences and Computers in Engineering Conference (1996). [58] Date, H., Kanai, S., Kishinami, T., and Nishigaki, I. Flexible feature and resolution control of triangular meshes. In Proceedings of the sixth IASTED international conference on visualization, imaging and image processing (2006). [59] Dawood, H. Theories of Interval Arithmetic: Mathematical Foundations and Applications. Hend Dawood and LAP LAMBERT Academic Publishing, 2011. [60] De Kleer, J. How circuits work. Artificial Intelligence 24, 1 (1984), 205–280. [61] De Moura, L., and Bjørner, N. Z3: An efficient smt solver. In Tools and Algorithms for the Construction and Analysis of Systems. Springer, 2008, pp. 337–340. [62] Deng, Y.-M., Britton, G., and Tor, S. A design perspective of mechanical function and its object-oriented representation scheme. Engineering with Computers 14, 4 (1998), 309–320. [63] Dixon, A., and Shah, J. J. Assembly feature tutor and recognition algorithms based on mating face pairs. Computer-Aided Design and Applications 7, 3 (2010), 319–333. [64] Drieux, G., Leon, J.-C., Guillaume, F., and Chevassus, N. Processes to integrate design with downstream applications through product shapes adaptation. Systems Journal, IEEE 3, 2 (2009), 199– 209. [65] Emberey, C., Milton, N., Berends, J. P. T. J., Tooren, M. J. L. V., der Elst, S. V., and Vermeulen, B. Application of knowledge engineering methodologies to support engineering design application development in aerospace. In 7th AIAA Aviation Technology (Belfast, Northern Ireland, 2007), Integration and Operations Conference (ATIO). [66] Falcidieno, B., and Giannini, F. Automatic recognition and representation of shape-based features in a geometric modeling system. Comput. Vision Graph. Image Process. 48 (October 1989), 93–123. [67] Fiorentini, X., Gambino, I., Liang, V.-C., Rachuri, S., Mani, M., and Bock, C. An ontology for assembly representation. Tech.Bibliography 203 rep., National Institute of Standards and Technology NISTIR 7436, Gaithersburg, MD 20899, USA, July,, 2007. [68] Foucault, G., Cuilliere, J.-C., Franc¸ois, V., Maranzana, R., ` and Leon, J.-C. ´ Adaptation of CAD model topology for finite element analysis. Computer-Aided Design 40, 2 (2008), 176–196. [69] Foucault, G., Shahwan, A., Leon, J.-C., and Fine, L. ´ What is the content of a DMU? Analysis and proposal of improvements. In Actes du 12`eme Colloque National AIP PRIMECA, Le Mont Dore, 29 Mars – 1er avril 2011 : Produits, Proc´ed´es et Syst`emes Industriels : int´egration R´eel-Virtuel (Le Mont Dore, France, 2011). [70] French, T., Helsel, J., Urbanick, B., and Svensen, C. Mechanical Drawing CAD Communications. Glencoe/McGraw-Hill School Publishing Company, 1990. [71] Garbade, R., and Dolezal, W. DMU@Airbus – Evolution of the Digital Mock-up (DMU) at Airbus to the Centre of Aircraft Development. In The Future of Product Development, F.-L. Krause, Ed. Springer Berlin Heidelberg, 2007, pp. 3–12. [72] Gero, J. S. Design prototypes: a knowledge representation schema for design. AI Mag. 11, 4 (Oct. 1990), 26–36. [73] Gero, J. S., and Kannengiesser, U. The situated functionbehaviour. Design Studies 25 (2004), 373–391. [74] Gopalakrishnan, P. Handbook Of Materials Management. Eastern economy edition. Prentice-Hall Of India Pvt. Limited, 2004. [75] Grimm, S., and Motik, B. Closed world reasoning in the semantic web through epistemic operators. In OWL: Experiences and Directions (2005). [76] Gruber, T. R. A translation approach to portable ontology specifi- cations. Knowledge acquisition 5, 2 (1993), 199–220. [77] Gui, J.-K., and Mantyl ¨ a, M. ¨ New concepts for complete product assembly modeling. In Proceedings on the second ACM symposium on Solid modeling and applications (New York, NY, USA, 1993), SMA ’93, ACM, pp. 397–406. [78] Haarslev, V., and Moller, R. ¨ Racer: A Core Inference Engine for the Semantic Web. In Workshop on Evaluation of Ontology-based Tools (2003).204 Bibliography [79] Haghighi, K., and Kang, E. A knowledge-based approach to the adaptive finite element analysis. In Modeling, Mesh Generation, and Adaptive Numerical Methods for Partial Differential Equations. Springer, 1995, pp. 267–276. [80] Hamri, O., Leon, J.-C., Giannini, F., Falcidieno, B., Poulat, ´ A., and Fine, L. Interfacing product views through a mixed shape representation. part 1: Data structures and operators. International Journal on Interactive Design and Manufacturing (IJIDeM) 2, 2 (2008), 69–85. [81] Han, J., Pratt, M., and Regli, W. C. Manufacturing feature recognition from solid models: A status report. IEEE Transactions on Robotics and Automation 16 (2000), 782–796. [82] Han, S. M., Benaroya, H., and Wei, T. Dynamics of transversely vibrating beams using four engineering theories. Journal of Sound and Vibration 225, 5 (1999), 935 – 988. [83] Hartenberg, R., and Denavit, J. Kinematic synthesis of linkages. McGraw-Hill series in mechanical engineering. McGraw-Hill, 1964, ch. Concepts and Notations Related to Mechanisms, pp. 28–67. [84] Hashim, F. M., Juster, N., and Pennington, A. A functional approach to redesign. Engineering with Computers 10, 3 (1994), 125– 139. [85] Henderson, M. R., and Taylor, L. E. A meta-model for mechanical products based upon the mechanical design process. Research in Engineering Design 5, 3-4 (1993), 140–160. [86] Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S., and Wood, K. L. A functional basis for engineering design: reconciling and evolving previous efforts. Research in Engineering Design 13, 2 (2002), 65–82. [87] Horridge, M., and Bechhofer, S. The OWL API: A java API for OWL ontologies. Semantic Web 2, 1 (2011), 11–21. [88] Horrocks, I., Kutz, O., and Sattler, U. The even more irresistible SROIQ. KR 6 (2006), 57–67. [89] Iacob, R., Mitrouchev, P., and Leon, J.-C. ´ Contact identification for assembly–disassembly simulation with a haptic device. The Visual Computer 24, 11 (2008), 973–979. [90] Iyer, N., Jayanti, S., Lou, K., Kalyanaraman, Y., and Ramani, K. Three-dimensional shape searching: state-of-the-art review and future trends. Computer-Aided Design 37, 5 (2005), 509–530.Bibliography 205 [91] Jackson, D. Automating first-order relational logic. In ACM SIGSOFT Software Engineering Notes (2000), vol. 25, ACM, pp. 130–139. [92] Jones, M., Price, M., and Butlin, G. Geometry management support for auto-meshing. In Proceedings of 4th International Meshing Roundtable (1995), pp. 153–164. [93] Jorissen, P., and Lamotte, W. A framework supporting general object interactions for dynamic virtual worlds. In Smart Graphics, A. Butz, A. Kr¨uger, and P. Olivier, Eds., vol. 3031 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2004, pp. 154–158. [94] Joshi, S., and Chang, T. C. Graph-based heuristics for recognition of machined features from a 3d solid model. Comput. Aided Des. 20 (March 1988), 58–66. [95] Jourdes, F., Bonneau, G.-P., Hahmann, S., Leon, J.-C., and ´ Faure, F. Computation of components’ interfaces in highly complex assemblies. Computer-Aided Design 46 (2014), 170–178. [96] Kallmann, M., and Thalmann, D. Direct 3d interaction with smart objects. In Proceedings of the ACM symposium on Virtual reality software and technology (New York, NY, USA, 1999), VRST ’99, ACM, pp. 124–130. [97] Kalman, J. Bednarek’s extension of light’s associativity test. Semigroup Forum 3, 1 (1971), 275–276. [98] Kandasamy, W. Smarandache Semirings, Semifields, and Semivector Spaces. American Research Press, 2002. [99] Kandasamy, W., and Smarandache, F. Dual Numbers. Zip Publishing, 2012. [100] Keler, M. L. On the theory of screws and the dual method. In Proceedings of A Symposium Commemorating the Legacy, Works, and Life of Sir Robert Stawell Ball Upon the 100th Anniversary of A Treatise on the Theory of Screws (2000), University of Cambridge. [101] Khatib, O. Real-time obstacle avoidance for manipulators and mobile robots. The international journal of robotics research 5, 1 (1986), 90– 98. [102] Kim, K.-Y., Manley, D. G., and Yang, H. Ontology-based assembly design and information sharing for collaborative product development. Computer-Aided Design 38, 12 (2006), 1233–1250.206 Bibliography [103] Kim, K.-Y., Wang, Y., Muogboh, O. S., and Nnaji, B. O. Design formalism for collaborative assembly design. Computer-Aided Design 36, 9 (2004), 849 – 871. [104] Kitamura, Y., and Mizoguchi, R. An ontological schema for sharing conceptual engineering knowledge. In International workshop on semantic web foundations and application technologies (2003), pp. 25– 28. [105] Kuttig, D. Potential and limits of functional modelling in the cad process. Research in Engineering Design 5, 1 (1993), 40–48. [106] Kyprianou, L. K. Shape classification in computer-aided design. PhD thesis, University of Cambridge, 1980. [107] Lee, J., and Lai, K.-Y. What’s in design rationale? Human– Computer Interaction 6, 3-4 (1991), 251–280. [108] Leizerowicz, W., Bilgic, T., Lin, J., and Fox, M. S. Collaborative design using www. In Proc. of WET-ICE’96 (1996), University of West Virginia. [109] Leon, J. C., and Fine, L. A new approach to the preparation of models for fe analyses. Int. J. of Computer Applications in Technology 23 (2005), 166–184. [110] Levison, L., and Badler, N. I. How animated agents perform tasks: connecting planning and manipulation through object-specific reasoning. In AAAI 1994 Spring Symposium Series. Proceedings (1994), ScholarlyCommons, Penn Engineering. [111] Li, K. Shape Analysis of B-Rep CAD Models to Extract Partial and Global Symmetries. PhD thesis, Grenoble University, Grenoble, November 2011. [112] Liang, V.-C., and Paredis, C. J. A port ontology for conceptual design of systems. Journal of Computing and Information Science in Engineering 4, 3 (2004), 206–217. [113] Lin, M. C., and Canny, J. F. A fast algorithm for incremental distance calculation. In Robotics and Automation, 1991. Proceedings., 1991 IEEE International Conference on (1991), IEEE, pp. 1008–1014. [114] Lou, R., Pernot, J.-P., Mikchevitch, A., and Veron, P. ´ Merging enriched finite element triangle meshes for fast prototyping of alternate solutions in the context of industrial maintenance. ComputerAided Design 42, 8 (2010), 670–681.Bibliography 207 [115] Lovett, P., Ingram, A., and Bancroft, C. Knowledge-based engineering for SMEs – a methodology. Journal of Materials Processing Technology 107, 1–3 (2000), 384 – 389. [116] Lutz, C. The Complexity of Reasoning with Concrete Domains. PhD thesis, RWTH Aachen, 2001. [117] Makem, J. E., Armstrong, C. G., and Robinson, T. T. Automatic decomposition and efficient semi-structured meshing of complex solids. In Proc. of the 20th international meshing roundtable. Springer, 2012, pp. 199–215. [118] Mandil, G. Mod´ele de repr´esentation g´eom´etrique int´egrant les ´etats physiques du produit. PhD thesis, Universit´e de Sherbrooke, Quebec, 2012. [119] Mantyla, M. Topological analysis of polygon meshes. ComputerAided Design 15, 4 (1983), 228–234. [120] Mantyl ¨ a, M. ¨ An Introduction to Solid Modeling. Principles of computer science series. Computer Science Press, 1988. [121] Mantyl ¨ a, M., Nau, D., and Shah, J. ¨ Challenges in feature-based manufacturing research. Commun. ACM 39, 2 (Feb. 1996), 77–85. [122] Marr, D., and Nishihara, H. K. Representation and recognition of the spatial organization of three-dimensional shapes. Proceedings of the Royal Society of London. Series B. Biological Sciences 200, 1140 (1978), 269–294. [123] Matheson, J. A. L. Hyperstatic Structures: An Introduction to the Theory of Statically Indeterminate Structures, vol. 1 of Hyperstatic Structures: An Introduction to the Theory of Statically Indeterminate Structures. Butterworths, 1971. [124] McMahon, C., and Browne, J. CADCAM: Principles, Practice and Manufacturing Management. ADDISON WESLEY Publishing Company Incorporated, 1998. [125] Mitra, N. J., Yang, Y.-L., Yan, D.-M., Li, W., and Agrawala, M. Illustrating how mechanical assemblies work. vol. 29, ACM, p. 58. [126] Mokhtarian, F., and Mackworth, A. K. A theory of multiscale, curvature-based shape representation for planar curves. IEEE Transactions on Pattern Analysis and Machine Intelligence 14, 8 (1992), 789–805. [127] Ohsuga, S. Toward intelligent CAD systems. Computer-aided design 21, 5 (1989), 315–337.208 Bibliography [128] Orton, J. D., and Weick, K. E. Loosely coupled systems: A reconceptualization. Academy of Management Review 15, 2 (1990), 203–223. [129] Pahl, G., Beitz, W., and Wallace, K. Engineering Design: Systematic Approach. Springer-Verlag GmbH, 1996. [130] Piegl, L. A., and Tiller, W. The NURBS book. Springer, 1997. [131] Poincare, H. ´ Analysis situs. Journal de l’Ecole polytechnique 11 ´ (1895). [132] Poinsot, L. El´ements de statique. Mallet-Bachelier, 1861. [133] Pommier, S., and Berthaud, Y. M´ecanique G´en´erale. In [134], 2010, ch. Actions, Liaisons, pp. 83–112. [134] Pommier, S., and Berthaud, Y. M´ecanique G´en´erale. Dunod, Paris, 2010. [135] Poole, D. L., and Mackworth, A. K. Artificial Intelligence: foundations of computational agents. Cambridge University Press, 2010. [136] Qian, L., and Gero, J. S. Function-behavior-structure paths and their role in analogy-based design. AI EDAM 10, 4 (1996), 289–312. [137] Quadros, W. R., and Owen, S. J. Defeaturing cad models using a geometry-based size field and facet-based reduction operators. Engineering with Computers 28, 3 (2012), 211–224. [138] Quinlan, S. Efficient distance computation between non-convex objects. In Robotics and Automation, 1994. Proceedings., 1994 IEEE International Conference on (1994), IEEE, pp. 3324–3329. [139] Quinlan, S., and Khatib, O. Elastic bands: Connecting path planning and control. In Robotics and Automation, 1993. Proceedings., 1993 IEEE International Conference on (1993), IEEE, pp. 802–807. [140] Quintana, V., Rivest, L., Pellerin, R., Venne, F., and Kheddouci, F. Will model-based definition replace engineering drawings throughout the product lifecycle? a global perspective from aerospace industry. Computers in Industry 61, 5 (2010), 497 – 508. [141] Raghavan, V., Molineros, J., and Sharma, R. Interactive evaluation of assembly sequences using augmented reality. IEEE Trans. Robot. Autom. 15, 3 (1999), 435–449. [142] Rahmani, K., and Thomson, V. Ontology based interface design and control methodology for collaborative product development. Comput. Aided Des. 44, 5 (May 2012), 432–444.Bibliography 209 [143] Rocca, G. L. Knowledge based engineering: Between AI and CAD. Review of a language based technology to support engineering design. Advanced Engineering Informatics 26, 2 (2012), 159 – 179. [144] Rocca, G. L., and Tooren, M. J. L. V. Enabling distributed multi-disciplinary design of complex products: a knowledge based engineering approach. Journal of Design Research 5, 3 (2007), 333–352. [145] Rocca, G. L., and van Tooren, M. A knowledge based engineering approach to support automatic generation of fe models in aircraft design. In 45th AIAA Aerospace Sciences Meeting and Exhibit (2007). [146] Roy, U., and Bharadwaj, B. Design with part behaviors: behavior model, representation and applications. Computer-Aided Design 34, 9 (2002), 613 – 636. [147] Roy, U., Pramanik, N., Sudarsan, R., Sriram, R., and Lyons, K. Function-to-form mapping: model, representation and applications in design synthesis. Computer-Aided Design 33, 10 (2001), 699 – 719. [148] Russ, B., Dabbeeru, M. M., Chorney, A. S., and Gupta, S. K. Automated assembly model simplification for finite element analysis. In ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (2012), American Society of Mechanical Engineers, pp. 197–206. [149] SAS, O. C. Open CASCADE Technology, 3D modeling & numerical simulation. http:/www.opencascade.org. [150] Schenk, M., Straßburger, S., and Kissner, H. Combining virtual reality and assembly simulation for production planning and worker qualification. In Proc. of International Conference on Changeable, Agile, Reconfigurable and Virtual Production (Munich, Germany, 2005). [151] Sederberg, T. W. Computer Aided Geometric Design. Brigham Young University, 2011, ch. Tensor-product Surfaces. [152] Shah, J., and Mantyl ¨ a, M. ¨ Parametric and Feature-Based CAD/CAM: Concepts, Techniques, and Applications. A WileyInterscience publication. Wiley, 1995. [153] Shah, J., Sreevalsan, P., and Mathew, A. Survey of CAD/feature-based process planning and NC programming techniques. Computer-Aided Engineering Journal 8, 1 (Feb 1991), 25–33. [154] Shah, J. J., Anderson, D., Kim, Y. S., and Joshi, S. A discourse on geometric feature recognition from cad models. Journal of Computing and Information Science in Engineering 1, 1 (2001), 41–51.210 Bibliography [155] Shearer, R., Motik, B., and Horrocks, I. Hermit: A highlyefficient OWL reasoner. In OWLED (2008), vol. 432. [156] Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., and Katz, Y. Pellet: A practical OWL-DL reasoner. Web Semantics 5, 2 (June 2007), 51–53. [157] Smithers, T. AI-based versus geometry-based design or why design cannot be supported by geometry alone. Comput. Aided Des. 21, 3 (Apr. 1989), 141–150. [158] Sonthi, R., Kunjur, G., and Gadh, R. Shape feature determination usiang the curvature region representation. In Proceedings of the fourth ACM symposium on Solid modeling and applications (1997), ACM, pp. 285–296. [159] Sridharan, N. Classification, Parameterization, and Recognition of NC Machining Features with Sculptured Surfaces. Arizona State University, 2000. [160] Srinivasan, V., Lovejoy, W. S., and Beach, D. Integrated product design for marketability and manufacturing. Journal of Marketing Research (1997), 154–163. [161] Stokes, M., and Consortium, M. Managing Engineering Knowledge: MOKA: Methodology for Knowledge Based Engineering Applications. Professional Engineering Publishing Limited, 2001. [162] Sturges, R. H., O’Shaughnessy, K., and Kilani, M. I. Computational model for conceptual design based on extended function logic. Artificial Intelligence for Engineering, Design, Analysis and Manufacturing 10, 04 (1996), 255–274. [163] Suh, N. The Principles of Design. Oxford series on advanced manufacturing. Oxford University Press on Demand, 1990. [164] Sunil, V., Agarwal, R., and Pande, S. An approach to recognize interacting features from b-rep cad models of prismatic machined parts using a hybrid (graph and rule based) technique. Computers in Industry 61, 7 (2010), 686–701. [165] Swamidass, P. Encyclopedia of Production and Manufacturing Management. Springer, 2000. [166] Thakur, A., Banerjee, A. G., and Gupta, S. K. A survey of CAD model simplification techniques for physics-based simulation applications. Computer-Aided Design 41, 2 (2009), 65–80.Bibliography 211 [167] Tomiyama, T., Umeda, Y., and Yoshikawa, H. A CAD for functional design. CIRP Annals - Manufacturing Technology 42, 1 (1993), 143 – 146. [168] Troussier, N., Pourroy, F., and Tollenaere, M. Mechanical models management in engineering design. In IDMME (France, 1998), vol. 4, pp. 1087–1094. [169] Tsarkov, D., and Horrocks, I. Fact++ description logic reasoner: System description. In In Proc. of the Int. Joint Conf. on Automated Reasoning (IJCAR 2006 (2006), Springer, pp. 292–297. [170] Turing, A. M. On computable numbers, with an application to the entscheidungsproblem. J. of Math 58 (1936), 345–363. [171] Ullman, D. The Mechanical Design Process. McGraw-Hill series in mechanical engineering. McGraw-Hill, 2003. [172] Ullman, D. G. A taxonomy for mechanical design. Research in Engineering Design 3, 3 (1992), 179–189. [173] Ullman, D. G. The mechanical design process. 2nd ed. New York: McGraw-Hill, 1997. [174] Umeda, Y., Takeda, H., Tomiyama, T., and Yoshikawa, H. Function, behaviour, and structure. Applications of artificial intelligence in engineering V 1 (1990), 177–194. [175] Venkataraman, S., and Sohoni, M. Reconstruction of feature volumes and feature suppression. In Proceedings of the seventh ACM symposium on Solid modeling and applications (2002), ACM, pp. 60– 71. [176] Verhagen, W. J., Bermell-Garcia, P., van Dijk, R. E., and Curran, R. A critical review of knowledge-based engineering: An identification of research challenges. Advanced Engineering Informatics 26, 1 (2012), 5 – 15. Network and Supply Chain System Integration for Mass Customization and Sustainable Behavior. [177] Wang, G. G. Definition and review of virtual prototyping. Journal of Computing and Information Science in Engineering (Transactions of the ASME) 2, 3 (2002), 232–236. [178] Welch, R., and Dixon, J. Guiding conceptual design through behavioral reasoning. Research in Engineering Design 6, 3 (1994), 169– 188.212 Bibliography [179] Welty, C., McGuinness, D. L., and Smith, M. K. Owl web ontology language guide. W3C recommendation, W3C (February 2004) http://www. w3. org/TR/2004/REC-owl-guide-20040210 (2004). [180] Whitney, D. Designing the design process. Research in Engineering Design 2, 1 (1990), 3–13. [181] Whitney, D. Mechanical Assemblies: Their Design, Manufacture, and Role in Product Development. No. v. 1 in Mechanical Assemblies: Their Design, Manufacture, and Role in Product Development. Oxford University Press, 2004. [182] Xu, X., and Hinduja, S. Recognition of rough machining features in 2.5D components. Computer-Aided Design 30, 7 (1998), 503–516. [183] Y14.5, A. Geometric Dimensioning & Tolerancing. ASME, 1982. [184] Zhang, Q., Vonderembse, M. A., and Cao, M. Product concept and prototype flexibility in manufacturing: Implications for customer satisfaction. European Journal of Operational Research 194, 1 (2009), 143 – 154. [185] Zhu, H., and Menq, C. B-Rep model simplification by automatic fillet/round suppressing for efficient automatic feature recognition. Computer-Aided Design 34, 2 (2002), 109–123. Etude de l’anesthesie generale `a l’echelle atomique par modelisation d’un homologue bacterien du recepteur nicotinique humain Benoist Laurent To cite this version: Benoist Laurent. Etude de l’anesthesie generale `a l’echelle atomique par modelisation d’un homologue bacterien du recepteur nicotinique humain. Biomolecules. Universit´e Paris-Diderot - Paris VII, 2014. French. HAL Id: tel-01053431 https://tel.archives-ouvertes.fr/tel-01053431 Submitted on 30 Jul 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de d o ctorat de l’un ivers ité Par is D iderot (Par is 7 ) École Doctorale Interdisciplinaire Européenne Frontières du Vivant Étude de l’anesthésie générale à l’échelle atomique par modélisation d’un homologue bactérien du récepteur nicotinique humain Présentée par Benoist Laurent Pour obtenir le grade de Docteur de l’université Paris Diderot (Paris 7) Spécialité : Biochimie informatique et statistique èse soutenue le 16 juin 2014 devant le jury composé de : Dr. Annick Dejaegere Université de Strasbourg Rapporteur Dr. omas Grutter CNRS Rapporteur Pr. Anne-Claude Camproux Université Paris Diderot (Paris 7) Examinateur Dr. Nicolas Férey Université Paris Sud (Paris 11) Examinateur Dr. Damien Laage CNRS Examinateur Dr. Pierre-François Lavallée CNRS Examinateur Dr. Marc Baaden CNRS Directeur de thèseÀ mon épouse, Lydie, mon modèle et ma source d’inspiration dans la science comme dans la vie. À ma lle, Flore, qui a plongé ma vie dans une incertitude insoluble qu’elle balaye chaque fois qu’elle plonge son regard dans le mien.Remerciements Mes remerciements s’adressent tout d’abord à mon directeur de thèse, Marc Baaden, qui s’est battu avec moi pour obtenir un nancement et qui m’a accompagné pendant ces trois années. Tu m’as laissé la liberté dont j’avais besoin (parfois plus!) et toujours respecté mes choix. Merci d’avoir choisi de ne jamais rien m’imposer, mais de me convaincre au terme de débats souvent interminables. Je remercie chaleureusement les laboratoires Servier pour avoir accepté de nancer ce travail pendant plus de trois ans en me laissant la plus grande liberté, et plus particulièrement Olivier Nosjean qui m’a soutenu dès le départ. Merci également à mon école doctorale, Frontières du Vivant et à la Fondation Bettencourt Schueller. Je tiens à remercier le Professeur Philippe Derreumaux pour m’avoir accueilli au sein du Laboratoire de Biochimie éorique. Mes sincères remerciements aux membres du jury qui ont accepté d’évaluer mes travaux. Un merci particulier pour Nicolas Férey et Damien Laage qui ont été mes tuteurs tout au long de ma thèse et qui ont partagé avec moi leur vision et leurs idées sur ce travail. Je remercie très chaleureusement les membres du LBT, passés et présents, qui, chacun à sa manière, contribuent à faire de ce laboratoire un lieu de travail stimulant que je quitte à regret. Merci à Samuel qui m’a apporté son expertise dans de nombreux domaines et répondu à mes questions incessantes avec patience et sarcasmes ! J’aimerais également adresser quelques mots à trois membres du LBT qui m’ont particulièrement soutenus pendant cette thèse : Fabio Sterpone, Antoine Taly et Jérôme Hénin. Merci Jérôme de m’avoir montré que même les choses les plus simples sont d’une complexité abyssale et d’avoir su me les expliquer avec sérénité et courage. Je n’oublie pas mes collègues de pasteuriens, Frédéric Poitevin, Ludovic Sauguet, Marie Prevost, Pierre-Jean Corringer et Marc Delarue, pour m’avoir fait proter de leur expertise insondable des pLGICs. Merci à mes amis, avec qui je partage depuis de nombreuses années mes joies, passions, doutes et espoirs et sur qui j’ai toujours pu compter. Un mot particulier pour Paul qui, il y a maintenant huit ans, m’a poussé à reprendre mes études et sans qui aujourd’hui, j’aurais sans doute un emploi stable ! Un dernier mot pour ma famille et plus particulièrement mes parents, sans qui, pour citer un de mes illustres aînés, je ne serais pas là. Merci pour l’énergie que vous avez investi dès le plus jeune âge à m’éveiller aux curiosités de la vie, probablement malgré vous. Je ne pourrais jamais vous rendre ce que vous m’avez donné en me permettant de reprendre mes études et d’aller au bout de mes rêves.Abbreviations 5-HTR 5-HydroxyTryptamine Receptor ATP Adenosin Triphosphate BAR Bennett’s Acceptance Ratio cAMP cyclic Adenosine Monophosphate CeCILL Ce(A) C(NRS) I(NRIA) L(ogiciel) L(ibre) CHARMM Chemistry at HARvard Molecular Mechanics CNS Central Nervous System CPU Central Processing Unit CSS Cascading Style Sheets DSF Desžurane ECD Extracellular Domain ELIC Erwinia chrysanthemi Ligand-gated Ion Channel FEB Free Energy of Binding FFT Fast Fourier Transforms GA General Anesthetic GABA γ-Aminobutiric Acid GABAAR GABA Receptor of type A GLIC Gloeobacter violaceus Ligand-gated Ion Channel GluCl Glutamate-gated Chloride ion channel GlyR Glycine Receptor GNU GNU’s Not Unix!viii GPL General Public License GROMACS Groningen Machine for Chemical Simulations HTML Hypertext Markup Language IDRIS Institut du Développement et des Ressources en Informatique Scientique IMD Interactive Molecular Dynamics LC Locally Closed MBR Bromoform MD Molecular Dynamics nAChR Nicotinic Acetylcholine Receptor NAMD Not (just) Another Molecular Dynamics program NetCDF Network Common Data Form NMR Nuclear Magnetic Resonance NPT Number of particles Pressure Temperature NVT Number of particles Volume Temperature OPEP Optimized Potential for E›cient rotein structure Prediction PBC Periodic Boundary Conditions PBE Poisson-Boltzmann Equation PDB Protein Data Bank PFL Propofol pLGIC pentameric Ligand-Gated Ion Channel PME Particle Mesh Ewald PNS Peripheral Nervous System reST reStructured Text RMSD Root Mean Square Deviation SAXS Small-Angle X-ray Scattering TMD Transmembrane Domain VMD Visual Molecular Dynamics WT Wild-TypeContents 0 A short primer about this thesis 1 1 Biological Background 3 1.1 The human nervous system, a central player in general anesthesia . . . . . . . . . . 3 1.1.1 Overall structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 The synapse - creating the right interconnections . . . . . . . . . . . . . . . . 6 1.1.3 The action potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4 Medical implications: general anesthesia . . . . . . . . . . . . . . . . . . . . . . 7 1.1.5 Neuroreceptors, a likely target for general anesthetics . . . . . . . . . . . . . 9 1.2 Bacterial and invertebrate homologues to the human nicotinic receptor . . . . . . . 12 1.2.1 Why study channels from bacteria? . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2 A conserved general receptor organization . . . . . . . . . . . . . . . . . . . . . 13 1.2.3 Key features of an ion channel: opening and closing . . . . . . . . . . . . . . . 14 1.3 pLGICs are modulated by a variety of molecules . . . . . . . . . . . . . . . . . . . . . . 15 1.3.1 Modulation through the sites in the ECD . . . . . . . . . . . . . . . . . . . . . . 17 1.3.2 Modulation through the sites in the TMD . . . . . . . . . . . . . . . . . . . . . 17 1.4 Context in October 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2 Molecular Modeling: Theory And Practice 23 2.1 Force Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2 Molecular Dynamics Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.1 Equation of motion integration algorithms . . . . . . . . . . . . . . . . . . . . . 25 2.2.2 Integration time step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.3 Non-bonded interactions under periodic boundary conditions . . . . . . . . 27 2.2.4 Statistical ensembles: thermostats and barostats . . . . . . . . . . . . . . . . . 29 2.3 Free energy calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 Application: bromoform force field parameterization . . . . . . . . . . . . . . . . . . . 32 2.4.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34x Contents 2.5.1 System composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.2 Concentrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.5.3 Protonation state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.4 Solvation in special/unusual environments . . . . . . . . . . . . . . . . . . . . 41 2.5.5 Sampling, statistics, timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.6 Setups and methods used in this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.6.1 Short 8 ns long MD simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.6.2 Long MD simulations beyond the hundred nanoseconds timescale . . . . . . 45 2.6.3 Free energy calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.6.4 Confidence interval on means calculation . . . . . . . . . . . . . . . . . . . . . 47 2.6.5 Binding site occupancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.6.6 Pocket volume calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.6.7 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3 High-Performance Computing And Large Scale Data Analysis 49 3.1 Computing the simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1.1 The need for high-performance computers . . . . . . . . . . . . . . . . . . . . . 49 3.1.2 Optimizing the available resources . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.1.3 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.2 Scaling and parallelization of the analysis processes . . . . . . . . . . . . . . . . . . . 52 3.3 Efficient Analysis Software Need: The Epock Software . . . . . . . . . . . . . . . . . . 53 3.3.1 Program features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3.2 Application: the GLIC ion channel . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3.3 Making Epock public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4 BioSpring: an Augmented Spring Network Simulation Engine . . . . . . . . . . . . . 57 3.4.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4.2 My contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4 Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites 63 4.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.1 Bromoform-bound crystal structure of the GLIC channel in its locallyclosed conformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.2 Molecular Dynamics simulations to explore and quantify anesthetics binding 65 4.1.3 Crystallographic sites are spontaneously reachable . . . . . . . . . . . . . . . 65 4.1.4 All sites are interconnected, with gates between them . . . . . . . . . . . . . 67 4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.2.1 Multi-site allosteric modulation, a delicate balance toward potentiation or inhibition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.2.2 A residue gating the access to anesthetic allosteric binding sites . . . . . . . 73 4.2.3 H11’ protonation state impacts the potentiating site . . . . . . . . . . . . . . . 74Contents xi 4.2.4 The “pore binding site” hypothesis is supported by crystallographic and simulation data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5 Propofol & desflurane simulations provide new insights into anesthetic action at the atomic scale 77 5.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.1.1 An extensive sampling close to the crystal structure . . . . . . . . . . . . . . . 78 5.1.2 Anesthetics are mobile within the W1 binding site . . . . . . . . . . . . . . . . 78 5.1.3 Different mobilities impact the number of contacts with the receptor . . . . 79 5.1.4 Ligand binding stretches the intrasubunit pocket . . . . . . . . . . . . . . . . . 81 5.1.5 Ligand binding does not impact neighboring cavities . . . . . . . . . . . . . . 82 5.1.6 Tyrosine 197 conformations are stabilized by hydrogen bonds . . . . . . . . 83 5.1.7 Y197’s stability is modulated by the T255A mutation . . . . . . . . . . . . . . 84 5.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.1 Binding to the intersubunit site B2 confirmed . . . . . . . . . . . . . . . . . . . 85 5.2.2 A more detailed contact map: the role of Y197 confirmed . . . . . . . . . . . 86 5.2.3 Influence of the ligand binding symmetry . . . . . . . . . . . . . . . . . . . . . 86 5.2.4 Understanding anesthetic’s action . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6 Concluding Remarks, Perspectives & Thoughts 91 6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Appendix Appendices 97 Bibliography 123List of Figures 1.1 e structure of a neuron. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Dišerent types of glia interact with neurons and the surrounding blood vessels. . . . . . . 5 1.3 e chemical synaptic transmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 e action potential. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Structure of common general anesthetics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6 Examples of compounds that do not obey Meyer Overton’s rule. . . . . . . . . . . . . . . . 10 1.7 e structure of the nicotinic receptor from Torpedo marmorata. . . . . . . . . . . . . . . . 12 1.8 GLIC: a bacterial homologue to the human nicotinic receptor. . . . . . . . . . . . . . . . . 13 1.9 Comparing GLIC and ELIC closed state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.10 Location of the anesthetic binding sites highlighted in pLGICs transmembrane domain. . 18 1.11 Hypothesis of anesthetic action on the function of ionotropic channels. . . . . . . . . . . . 20 2.1 Equation of potential energy and schematic representation of the various contributions. . 24 2.2 e algorithm underpinning molecular dynamics simulations. . . . . . . . . . . . . . . . . 25 2.3 Sympletic vs non-symplectic integrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Periodic boundary conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5 Spherical cutoš schemes for non-bonded interactions. . . . . . . . . . . . . . . . . . . . . . 29 2.6 A thermodynamic cycle for the computation of the free energy of binding of a ligand to a receptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7 Biological solutions are crowded mixtures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8 System set-up used to study ion permeation through GLIC according to the double bilayer method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.9 Isožurane and ethanol partitioning along žooding simulations. . . . . . . . . . . . . . . . . 38 2.10 Localization of ionizable residues shown in a cross-section of the GLIC ion channel (grey). 39 2.11 pKa shiŸ predictions with respect to standard values for all ionizable residues in GLIC obtained using dišerent soŸware packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.12 Hydration traces of GLIC’s pore during two representative simulations. . . . . . . . . . . . 41 2.13 Sodium ion occupancy and related relative Boltzmann energy accumulated during a one microsecond MD simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.14 Extensive screening of bromform’s a›nity for GLIC. . . . . . . . . . . . . . . . . . . . . . . 47xiv List of Figures 3.1 Benchmarking the speed of a simulation on a machine. . . . . . . . . . . . . . . . . . . . . 51 3.2 Calculation of a pore prole with Epock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3 From Epock setup to result analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4 Writing Epock’s website. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5 e NetCDF array-oriented format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.6 GNU autoconf and automake process for generating makeles. . . . . . . . . . . . . . . . . 62 4.1 A bromoform-bound structure of GLIC in its locally closed conformation. . . . . . . . . . 64 4.2 Two distinct conformations of residue Y197. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.3 Key residues of the intrasubunit pocket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4 Bromoform exploration in žooding simulations. . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5 Y197 side chain orientation along žooding simulations. . . . . . . . . . . . . . . . . . . . . 69 4.6 Transition of a bromoform molecule from the membrane to the B1 site. . . . . . . . . . . . 69 4.7 Free energies of binding of bromoform to the ve binding sites. . . . . . . . . . . . . . . . 71 4.8 Bromoform exploration of the intra- and intersubunit binding pockets in short MD simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.1 A sampling close to the crystal structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2 Exploration of anesthetic molecules bound to W1. . . . . . . . . . . . . . . . . . . . . . . . 80 5.3 Anesthetics contacts with open GLIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.4 Volume of the intrasubunit pocket W1 occupied by 3 dišerent anesthetics. . . . . . . . . . 82 5.5 Volume of the intersubunit pocket B1 occupied by bromoform. . . . . . . . . . . . . . . . . 82 5.6 Inžuence of propofol binding on neighboring pockets. . . . . . . . . . . . . . . . . . . . . . 83 5.7 Inžuence of bromoform binding to B1 on W1. . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.8 Y197 hydrogen bonds to surrounding residues. . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.9 Tyrosine 197 side chain orientation in open and LC GLIC. . . . . . . . . . . . . . . . . . . . 85 A.1 Compared packing of the nAChR and GLIC structures. . . . . . . . . . . . . . . . . . . . . 97 B.1 Bromoform parameters for GROMACS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 D.1 Contact maps of anesthetics bound to locally closed GLIC variants. . . . . . . . . . . . . . 119 D.2 Pocket exploration by bromoform in short MD simulations. . . . . . . . . . . . . . . . . . 120List of Tables 1.1 Example neurotransmitters and associated signal type. . . . . . . . . . . . . . . . . . . . . . 11 1.2 Sequence similarities of non-human pLGICs. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3 Crystal structure of general anesthetics, alcohols and channel blockers bound to a member of the pLGIC family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1 Bromoform parametrization result summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2 A human synaptic membrane composition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.3 Systems simulated by means of short MD simulations. . . . . . . . . . . . . . . . . . . . . . 45 3.1 Comparing common supercomputers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.2 Composition of a minimal GLIC system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1 Sampling time and studied systems for bromoform characterization. . . . . . . . . . . . . 66 4.2 Bromoform binding site occupancy along MD simulations. . . . . . . . . . . . . . . . . . . 66 4.3 Free energy of binding of bromoform as a function of H235 protonation state . . . . . . . 71 4.4 Bromoform occupancy of intrasubunit sites along žooding MD simulations according to the Y197 residue side chain orientation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.1 Inhibition of GLIC by two general anesthetics. . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2 Propofol occupancy of crystallographic binding sites in short MDs. . . . . . . . . . . . . . 78 5.3 Desžurane occupancy of crystallographic binding sites in short MDs. . . . . . . . . . . . . 79 5.4 Comparison of anesthetic occupancies of the intrasubunit pocket binding sites. . . . . . . 81 5.5 Volume of the intrasubunit pocket W1 in open GLIC in presence of anesthetic molecules. 82 5.6 Predictive ešect of mutant D32A and Y119A on GLIC’s inhibition by propofol and desžurane. 89 D.1 Volume of the intrasubunit pocket W1 in GLIC crystal structures. . . . . . . . . . . . . . . 121 D.2 Volume of the intersubunit pocket W1 in GLIC crystal structures. . . . . . . . . . . . . . . 121A short primer about this thesis 0 Neuroreceptors are membrane proteins responsible for nervous signal transduction between neurons and every part of the body. At synaptic ends, they receive the signal from the presynaptic cell in the form of a neurotransmitter and respond with the opening of an ion channel located on the postsynaptic cell, leading to transmission of the signal across the nervous ending. Dysfunction of neuroreceptors is associated to several disorders of the central nervous system including myasthenia gravis, epilepsy, addiction to nicotine and alcohol and several cognitive and mental disorders such as schizophrenia, Alzheimer’s and Parkinson’s diseases. ey are also involved in general anesthesia mechanisms. In this work, I focused on the latter, trying to understand the open question of general anesthesia mechanisms at the atomistic scale. General anesthetics have been shown to target neuroreceptors, in particular the pentameric Ligand-Gated Ion Channel (pLGIC) family. As a threedimensional structure of an eukaryotic member of this family is particularly di›cult to solve, numerous groups worldwide focus now on prokaryotic members on this family, including Gloeobacter violaceus Ligand-gated Ion Channel (GLIC). GLIC is a homopentameric ion channel the opening of which is controlled by pH variations. Since its rst crystallization in 2009, several high resolution structures of this bacterial channel have been resolved, including mutants, open, locally closed and closed conformations, and co-crystals with modulating ions, alcohols, benzodiazepines, local and general anesthetics. My work is primarily based on crystals of general anesthetics propofol, desžurane and bromoform bound to GLIC in open and locally closed conformations. I attempt to characterize anesthetics behavior while bound to allosteric sites in conformations close to the crystal structures thanks to in silico methods such as Molecular Dynamics (MD) simulations and Free Energy of Binding (FEB) calculations. is manuscript is structured as follows. Chapter 1, “Biological Background”, briežy introduces basic notions on the nervous signal transduction in the human body, followed by a short history on the development of anesthesia. I then focus on the structure and function of human neuroreceptors before concluding with the state-of-the-art of the study of bacterial and unicellular members of the pLGIC superfamily. In Chapter 2, entitled “Molecular Modeling: eory And Practice”, I shortly introduce the main methods I applied in the context of this project: MD simulations and free energy calculations. I then develop some of the principal recurring di›culties that have to be faced calculating MD simulations of biomolecules.2 Chapter 0. A short primer about this thesis Chapter 3, “High-Performance Computing And Large Scale Data Analysis”, deals with the answer I found to methodological issues I faced on a daily basis, mainly related to high-performance computing and large scale data analysis. In particular, I present the Epock soŸware, which I implemented during my PhD project and that aims to e›ciently calculate protein pocket volumes. e next two chapters are devoted to the characterization of general anesthetics behavior bound to the GLIC channel. Chapter 4, “Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites”, aims to describe the bromoform interactions with GLIC while bound to several binding sites. For this purpose, I combine three complementary simulation strategies, trying to answer three principal questions: i) are bromoform crystallographic binding sites spontaneously accessible? ii) how does bromoform dynamics evolve while bound to these sites? iii) what is bromoform’s a›nity for each binding site? In the next chapter, ‘Propofol & desžurane simulations provide new insights into anesthetic action at the atomic scale”, I extend the problems addressed in studying bromoform to general anesthetics propofol and desžurane. I aim to check whether hypotheses I established for bromoform are veried on other general anesthetics that exhibit quite dišerent properties compared to bromoform. I also address several additional issues such as the symmetry of anesthetic binding and the extensive characterization of pocket volume. e work is then concluded with nal remarks and a general perspective. Supplementary information is provided in the appendix.Biological Background 1 1.1 The human nervous system, a central player in general anesthesia Here I will briežy describe in a top-down manner the structure of relevant parts of the human nervous system in relation to general anesthesia. e nervous system is an ensemble of structures that coordinates an animal’s voluntary and involuntary actions and transmits signals to dišerent body areas. In vertebrates, it consists of two main parts, called the Central Nervous System (CNS) and the Peripheral Nervous System (PNS). e CNS consists of the brain and the spinal cord. e PNS consists mainly of nerves, which are long bers that connect the CNS to every part of the body. e PNS also includes peripheral ganglia and the enteric nervous system, a semi-independent part of the nervous system that controls the gastrointestinal system. 1.1.1 Overall structure e nervous system is made of two main categories of cells: neurons and glial cells. Neurons, or nerve cells, are distinguishable from other cells in a number of ways but their most fundamental property is that they communicate with other cells through specialized intercellular adhesion sites called synapses. A typical neuron has four morphologically dened regions: the cell body, dendrites, axon and presynaptic terminals as shown in gure 1.1. Dendrites provide a highly branched, elongated surface for receiving signals. e axon conducts electrical impulses rapidly over long distances to their synaptic terminal, which releases neurotransmitter onto target cells (Kandel et al., 2000). An axon can extend to dišerent parts of the body and make thousands of synaptic contacts. A nerve is a bundle of axons. All neural cells that lack the capacity of transmitting rapid signals in the form of an action potential (see section 1.1.3) are categorized into a broad class termed glia. In mammals, glial cells include microglia, astrocytes, Schwann cells and oligodendrocytes (gure 1.2). ey ensure a wide range of functions, some of them probably unknown yet, including homeostasis maintenance, neuron support, nutrition and insulation to speed up electrical communication (Allen and Barres, 2009). Glial cell are an essential component of the nervous system and can constitute the major part of a brain: human brain has about 90 % glial cells, an elephant’s brain 97 %.4 Chapter 1. Biological Background Nuclear envelope Cell body Axon Synaptic vesicle Myelin sheath Transport vesicle Endoplasmic reticulum Golgi apparatus Dendrites Synaptic terminal Muscle Figure 1.1 –e structure of a neuron. e cell body and nucleus of a spinal motor neuron are surrounded by a double-layered membrane, the nuclear envelope, which is continuous with the endoplasmic reticulum. e space between the two membrane layers that constitutes the nuclear envelope is continuous with the lumen of the endoplasmic reticulum. Dendrites emerge from the basal aspect of the neuron, the axon from the apical aspect. From Kandel et al. (2000).1.1. e human nervous system, a central player in general anesthesia 5 Figure 1.2 – Dišerent types of glia interact with neurons and the surrounding blood vessels. Oligodendrocytes wrap myelin around axons to speed up neuronal transmission. Astrocytes extend processes that en-sheath blood vessels and synapses. Microglia keep the brain under surveillance for damage or infection. From Allen and Barres (2009).6 Chapter 1. Biological Background Ca2+ Presynaptic nerve terminal Receptorchannel Transmitter Postsynaptic cell Na+ Na+ Na+ A B C Figure 1.3 – e chemical synaptic transmission. A) An action potential arriving at the presynaptic terminus causes voltage-gated Ca2+ channels on the presynaptic membrane to open. B) e opening of the Ca2+ channels causes high concentration of intracellular Ca2+ which causes synaptic vesicles containing neurotransmitter molecules to fuse with the presynaptic membrane and transmitters to be liberated in the synaptic cleŸ. C) e released neurotransmitter molecules dišuse across the synaptic cleŸ and bind the neuroreceptor on the postsynaptic membrane. As ion channels open, the membrane potential of the postsynaptic cell changes. Adapted from Kandel et al. (2000). 1.1.2 The synapse - creating the right interconnections e synapse is a specialized structure that mediates a functional interaction between two neurons or between a neuron and another cell type. Synapses may be of chemical as well as electrical nature. Chemical and electrical synapses dišer not only by the mechanism of information transfer, but also in their morphological organization. At electrical synapses, the pre- and postsynaptic cells communicate through gap junctions, cell-to-cell pores that serve as a conduit between the cytoplasm of two cells. Consequently, the space between the two cells, called the synaptic cleŸ, is on the order of 2 to 4 nm wide. In contrast, in the much more common chemical synapses, the synaptic cleŸ is wider, on the order of 20 to 40 nm (Hormuzdi et al., 2004). Chemical synaptic transmission depends on the dišusion of a neurotransmitter across the synaptic cleŸ. Neurotransmitter molecules are contained in synaptic vesicles. At arrival of an electrical signal, voltage-gated Ca2+ channels at the presynaptic terminus open, allowing Ca2+ ions to enter the cell. e rise of intracellular calcium initiates synaptic vesicle fusion with the presynaptic membrane, therefore the neurotransmitter liberation in the synaptic cleŸ (gure 1.3). e neurotransmitter dišuses and binds to its receptor on the postsynaptic membrane, which responds by opening and letting ions pass from the extracellular environment to the cytosol. If the ion žow is adequate, it will provoke a depolarization of the postsynaptic membrane which will be transmitted through the axon of the receptor cell. Importantly, chemical synapses can amplify the signal they receive since one synaptic vesicle releases thousands of neurotransmitter molecules that can open thousands of ion channels on the target cell. A small presynaptic nerve which generates a weak electrical current can therefore depolarize a large postsynaptic cell.1.1. e human nervous system, a central player in general anesthesia 7 –50 0 50 Membrane potential (mV) Open channels per µm2 of membrane 40 20 0 Action potential ENa EK Na+ conductance (Na+ channels) K + conductance (K+ channels) Figure 1.4 –e action potential. e sequential opening of voltage-gated Na+ and K+ channels generates the action potential. From Kandel et al. (2000). 1.1.3 The action potential An enormous amount of work has been realized by Hodgkin and Huxley (1952) leading to the detailed comprehension of the sequence of events that constitute the action potential. As described in section 1.1.2, the neurotransmitters binding to their receptor lead to the opening of ion channels, therefore the entering of ions in the intracellular space. Consequently, the membrane potential changes, rising if cations enter (depolarization), declining if anions enter (hyperpolarization). If the depolarization is su›cient, i.e. exceeds a threshold value1 , voltage-gated Na+ channels rapidly open resulting in an inward Na+ current. is current causes further depolarization, thereby opening more Na+ channels, resulting in a further increase of the inward current. e opening of Na+ channels causes the rising phase of the action potential (gure 1.4). e depolarization gradually inactivates the voltage-gated Na+ channels and opens, with some delay, voltage-gated K+ channels, resulting in an outward K+ žow that tends to repolarize the membrane. As these channels remain open for some time aŸer the resting potential has been reached, this current leads to a transient shiŸ of the membrane potential to values more negative than the resting potential (Kandel et al., 2000). e combined ešect of this increase in K+ conductance combined with the inactivation of Na+ channels underlies the absolute refractory period, the brief period aŸer which an action potential cannot be triggered. As some K+ channels begin to close and some Na+ channels recover from inactivation, the membrane enters the relative refractory period, during which an action potential can be triggered by applying stronger stimuli that those normally required to reach threshold. e membrane potential returns to its resting value as all the K+ channels nally close and the initial concentration of intracellular ions is restored by nongated and gated ion channels responsible for maintaining ion balance at rest. 1.1.4 Medical implications: general anesthesia e development of general anesthesia General anesthesia has several purposes: 1e action potential obeys the all-or-none principle: stimuli below the threshold do not produce an action potential while stimuli above the threshold all produce an action potential with the same amplitude. e intensity of the stimulus ašects the action potential frequency.8 Chapter 1. Biological Background • analgesia i.e. loss of response to pain, • amnesia i.e. loss of memory, • unconsciousness, • immobility i.e. loss of motor režexes, • relaxation of skeletal muscles. In contrast, local anesthesia does not provoke amnesia or unconsciousness. Furthermore, the ešect of a local anesthesia is restricted to a small part of the body. In a strict sense, local anesthesia refer for example to a tooth or an area of the skin. Any larger region such as leg or arm is covered under the term regional anesthesia. Usually, a local anesthetic cannot be used as general anesthetic and conversely. e rst attempts of anesthesia presumably occurred during prehistory through the administration of herbal remedies. Opium and alcohol were used in the Antiquity as narcotic and sedative, respectively, although the question of which people are at the origin of this usage is still debated (Krikorian, 1975). Interestingly, a Chinese legend wants that a Chinese physician successfully used herbal decoctions to render patients unconscious for several days and practice surgery upon them. e exact formula he used likely disappeared at his death. For centuries, physicians used oral as well as inhaled anesthetics in therapeutics in the form of herbal mixtures, oŸen composed in part of Papaver somniferum, a plant from which opium is prepared. Several notable advances in anesthesia, local and general, were made during the 19th century. e rst documented successful use of general anesthesia is generally considered as Hanoka Seishu mastectomy on 13 October 1804 (Izuo, 2004). is Japanese surgeon, aŸer years of ešorts, nally developed a formula which he named tsusensan composed of several plants from which, by the way, opium is not present. e same year, Friedrich Sertürner isolated morphine from opium, a molecule still commonly used as an analgesic. Along the 19th century, several uses of diethyl ether, the analgesic properties of which have been described in the 16th century, are reported for local as well as general anesthesia. In the middle 1800s, chloroform was discovered in Europe and rapidly replaced ether in Europe and Western countries, but was discarded because of its tendency to cause fatal cardiac arrhythmia. Most modern anesthetics have been developed by pharmaceutical labs, including propofol and desžurane; their action mechanism will be discussed in chapter 5. e development of most anesthetics has been primarily empirical, even sometimes fortuitous. Hypotheses on general anesthetics action Several theories have been formulated on general anesthetics action, always relative to the modulation of membrane proteins in the neuronal membrane. Paul Ehrlich (1854–1915) rst proposed the concept of highly specic interactions between drugs and receptors, stating that a drug acts only when bound to its target (Weir, 2006). As this theory was judged hardly applicable to general anesthetics because of their chemical and structural diversity (gure 1.5), theories implying nonspecic perturbations of neurons have been formulated. In the early 20th century, HH Meyer and CE Overton independently reported a correlation between the solubility of narcotics in olive oil and their anesthetic power: the greater the1.1. e human nervous system, a central player in general anesthesia 9 lipid solubility of the compound, the greater its anesthetic potency. is relation became known as the Meyer-Overton correlation, rened by Meyer’s son in Meyer, 1937. eories have then been developed mentioning that anesthetic solubilization in neuronal membranes alters the function of ion channels. However, these theories sušer several weaknesses: • several compounds with structures similar to anesthetics and high lipid solubility do not act as anesthetics (gure 1.6A,B), • general anesthetic ability to perturb membranes in vitro can be reproduced by a temperature drop to less than 1 ○C, a change well within the physiological range and clearly not su›cient to induce loss of consciousness, • some enantiomers of general anesthetics do not produce identical clinical ešects, although they have the same properties in lipid bilayers, (gure 1.6C) • there appears to be a cutoš ešect above a certain molecular volume which is indicative of anesthetic agents interacting with binding site(s) of nite dimensions (Bradley et al., 1984). Finally, it has been demonstrated that a range of general anesthetics act as competitive antagonists on the režy luciferase, a soluble protein (Franks and Lieb, 1984). Remarkably, inhibition of luciferase was directly correlated with anesthetic potency, providing persuasive evidence that general anesthetic drugs could selectively interact with proteins. However, some groups still argue that anesthetics may alter membrane properties which would play a role in anesthesia (Bahri et al., 2007; Baenziger et al., 2008; Hansen et al., 2013). In vitro experiments demonstrated that general anesthetics alter the function of several neurotransmitter receptors at clinically relevant concentrations (Weir, 2006) including the GABA Receptor of type A (GABAAR), the Nicotinic Acetylcholine Receptor (nAChR), the Glycine Receptor (GlyR) and the 5-HydroxyTryptamine Receptor (5-HTR) of subtype 3 (5-HT3R). 1.1.5 Neuroreceptors, a likely target for general anesthetics Neuroreceptors are membrane proteins localized on the postsynaptic membrane that share a few common properties, including the binding of neurotransmitters. A major second property is that, in contrast to molecular pumps, the žux of ions through the channel is passive. It is therefore determined not by the channel itself, but rather by the electrostatic and dišusional driving forces across the membrane. Finally, those channels are selective, which means that they allow particular types of ions to cross the membrane. Most channels are selective to only one type of ion that is usually present is the extracellular environment. Anion channels conduct only one physiological ion, chloride (Cl- ). Cation channels are selective to Na+ , K+ , or Ca2+ . e ešect of a synaptic potential, i.e. excitatory or inhibitory, depends on the type of ion that permeates into the postsynaptic cell: cations, that increase the membrane potential, trigger action potentials while anions cause an inhibition of the signal. Neurons can receive signals from both excitatory and inhibitory synapses. Although some transmitters can produce excitatory as well as inhibitory potentials, most transmitters produce a single type of response because they bind the same type of channel wherever they are met in the body. Excitatory synaptic action10 Chapter 1. Biological Background A C D B E F Figure 1.5 – Structure of common general anesthetics. A) Propofol. B) Ketamine. C) Des- žurane. D) Isožurane. E) Chloroform (not used clinically anymore). F) Sodium thiopental (also known as sodium pentothal). A C B Figure 1.6 – Examples of compounds that do not obey Meyer Overton’s rule. A) 2,3- dichlorooctažuorobutane has very high lipid solubility and properties similar to anesthetic but do not provoke anesthetia. B) Enžurane (isomere of isožurane – gure 1.5C – that is 45 to 90 percent less potent than isožurane). C) Etomidate (R etomidate is 10 times more potent that S etomidate).1.1. e human nervous system, a central player in general anesthesia 11 Neurotransmitter Receptor Receptor type Signal Type Acetylcholine nAChR ionotropic excitatory Glutamate iGluR ionotropic excitatory ATP P2XR ionotropic excitatory Glycine GlyR ionotropic inhibitory GABA GABAAR ionotropic inhibitory GABA GABABR metabotropic excitatory Serotonin* 5-HTR metabotropic excitatory Table 1.1 – Example neurotransmitters and associated signal type. Examples of common neurotransmitters associated with their most common receptor type and action on the signal. * Serotonin receptors are metabotropic receptors with the notable exception of the 5-HT3 receptor which is a ligand-gated Na+ and K+ channel. 5-HT receptors are excitatory receptors with the exception of subtypes 5-HT1 and 5-HT5 . is usually mediated by ionotropic glutamate and nicotine receptor channels that are permeable to sodium and potassium. Inhibitory synaptic action is usually mediated by GABA and glycine receptors that are permeable to chloride, as summarized in table 1.1. Neurotransmitters control the opening of ion channels on the postsynaptic cell either directly or indirectly, by acting on dišerent types of receptors. Receptors that gate ion žow indirectly, known as metabotropic receptors, include for example the serotonin receptor (5-HTR) and the GABA receptor of type B. ey are usually made of a single subunit, at most two, that are distinct from the ion channel they regulate. Activation of these receptors stimulates the production of a second messenger, cAMP for instance, which activates a protein kinase, an enzyme that phosphorylates dišerent substrate proteins. In many cases, the protein kinases directly phosphorylate ion channels, leading to their opening or closing (Kandel et al., 2000). ese several steps account for the delay in the synaptic transmission compared to direct gating. Ligand-gated channels, or ionotropic receptors, gate ion žow directly by opening upon neurotransmitter binding. ey are composed of three to ve identical or homologous subunits symmetrically arranged around a central ionic pore. e channel displays an Extracellular Domain (ECD) where the neurotransmitter binds and a Transmembrane Domain (TMD) that forms an ion-conducting pore (see gure 1.7A-B). Besides the pentameric channels, this family includes the trimetric P2X receptors and the tetrameric glutamate receptor2 . e pentameric superfamily comprises the nAChR, the GABAAR and the GlyR. e pLGICs are also named Cys-loop receptors due to the presence in the extracellular domain of a dening loop of approximately 13 residues žanked by two canonical cysteines linked by a disulde bridge. Most signaling between neurons in the CNS involves ionotropic receptors, as well as synapses at the neuromuscular junction which involve exclusively nAChRs. To date, the only complete structure of an animal3 Cys-loop receptor available is that of the nAChR from Torpedo marmorata (gure 1.7; Unwin, 2005). It was solved at a 4 Å resolution by cryoelectron microscopy, a resolution at which a high uncertainty exists on side chain localization. Besides, this structure 2e glutamate channel from Caenorhabditis elegans (GluCl) is pentameric and chloride selective (see section 1.2.2). 3Apart from that of the nematode C. elegans (see section 1.2).12 Chapter 1. Biological Background A B membrane C M2 helices and central pore Figure 1.7 –e structure of the nicotinic receptor from Torpedo marmorata. A) Side view of the whole structure represented in cartoon. e extracellular, transmembrane and intracellular domains are colored in brown, purple and pink, respectively. B) Top view of the transmembrane domain colored by subunit type (α, γ, α, β, δ). Each subunit contributes four helices, the M2 helix lining the channel pore. C) View of the extracellular half of the TMD in space lling representation showing the numerous gaps induced by the low packing between helices (see also appendix A.1). is, to date, highly controversial since important gaps exist between the TMD helices (gure 1.7C), gaps that are hardly compatible with the hypothesis according to which they are lled with water as originally assumed (Miyazawa et al., 2003) because of the strong density visible at these locations in the density map used to obtain the structure of the nAChR TMD (PDB-id 1OED) and the hydrophobic nature of the residues surrounding these gaps. Brannigan et al. proposed that these gaps are actually lled with cholesterol, since they successfully docked cholesterol into it (Brannigan et al., 2008) and since cholesterol is required for nAChR’s proper function (Dalziel et al., 1980). Furthermore, the lack of resolution of electron microscopy data led to the introduction of residue assignment errors in helices in the rst atomic model of the TMD alone (Miyazawa et al., 2003), in which residues are shiŸed by one helical turn from their correct position. e error became evident inspecting homologous structures (see section 1.2) and has been formally proven from direct experimental testing (Mnatsakanyan and Jansen, 2013). As the raw data from Unwin’s work have not been released, further renement is made impossible and the uncertainties concerning this model have not been dissipated. 1.2 Bacterial and invertebrate homologues to the human nicotinic receptor 1.2.1 Why study channels from bacteria? In 2004, Tasneem et al. searched for distant representatives of the Cys-loop family in organisms outside the animal lineage, faced with the fact that ancestors of voltage-gated potassium and sodium channels have been identied in non-animal eukaryotes, as well as numerous prokaryotes. Interestingly, this indicates that these channels were used in other signaling contexts by a variety of organisms way before the origin of the animal nervous system (Ito et al., 2004). As Tasneem et al. argue that the TMD is compositionally biased and tends to recover false positives in iterative sequence searches, they used only the ECD for their1.2. Bacterial and invertebrate homologues to the human nicotinic receptor 13 A membrane B C M1 M2 M4 M3 N-ter C-ter β9 β9' β10 β5 β6 β2 β8 β7 β1 membrane Figure 1.8 – GLIC: a bacterial homologue to the human nicotinic receptor. A) Side view of the GLIC channel. Compared to the nAChR (see gure 1.7), GLIC’s structure lacks the intracellular domain, the helices at the top of the ECD and the two cysteines that border the signature loop (not visible here). B) Topology of one of GLIC’s ve identical subunits, which is the same as for ELICand GluCl. C) Organination of the transmembrane domain. Each subunit (represented with dišerent colors) contributes to four helices named M1 to M4. M2 helices line the channel pore. queries. ey used PSI-BLAST to search in all organisms with genomic sequence data available at that time, with initial queries such as the human acetylcholine receptor α7 chain or the human GABA receptor α4 chain. In addition to animal sequences, these searches recovered sequences from bacteria such as the cyanobacteria Gloeobacter violaceus and the γ-proteobacteria Erwinia chrysanthemi4 , among others. 1.2.2 A conserved general receptor organization e work by Tasneem et al. turned out to be a breakthrough in the study of pLGICs. Several groups started focusing on bacterial members of the superfamily, despite the debate on the applicability of discoveries from prokaryotes to eukaryotes. Intensive ešorts lead to the crystallization of two bacterial pLGICs, namely ELIC from Erwinia chrysanthemi (Hilf and Dutzler, 2008) and GLIC from Gloeobacter violaceus (Bocquet et al., 2009; Hilf and Dutzler, 2009). e structure of the eukaryotic glutamate-gated chloride channel GluCl, from Caenorhabditis elegans, has been solved few years later in complex with the positive allosteric modulator ivermectin (Hibbs and Gouaux, 2011). ese structures show an important similarity with the nAChR although being simpler (gure 1.8). e ECD is structured in a β-sandwich fold stabilized through conserved hydrophobic residues (Corringer et al., 2012) but lack the N-terminal helix and the two cysteines that border the signature loop. e TMD of each protomer is made of four helices named M1 to M4 (gure 1.8B). e M2 helices form the pore of the channel and are thus critical segments of the ion conduction pathway (gure 1.8C). In contrast to the nAChR, they do not display a cytoplasmic domain. Despite this conserved general organization, the structure and length of loops connecting β-sheets in the ECD vary along pLGICs although they are critical for the quaternary assembly of the receptor (the sequence similarity between those pLGICs is notably low, as shown in table 1.2). e evolutionary 4Recent taxonomic revisions have caused the bacteria Erwinia chrysanthemi to be renamed Dickeya dadantii (Samson et al., 2005).14 Chapter 1. Biological Background GLIC ELIC GluCl nAChR GLIC – 45 (22) 36 (23) 41 (19) ELIC – – 39 (21) 41 (23) GluCl – – – 42 (26) Table 1.2 – Sequence similarities of non-human pLGICs. Sequence similarities calculated with proteinprotein BLAST. Percentages of identity are given between parentheses. Sequence accession ids are Q7NDN8, P0C7B7, Q17328, and Q9UGM1 for GLIC, ELIC, GluCl, and nAChR respectively. explanation for these dišerences is that these loops are believed to play a crucial role in the binding of the agonist and the transduction of the signal to the TMD. Similarly, connecting loops in the TMD play a determinant role for the channel function, such as the M2-M3 loop that actively participates to the signal transduction (Corringer et al., 2012). 1.2.3 Key features of an ion channel: opening and closing e comprehension of an ion channel’s transition from open to closed state, named gating, is essential for the understanding of the mechanics of signal transduction. Based on normal modes analysis, Taly et al. suggested that nAChR gating involved a quaternary twist-motion rearrangement of the ECD and the TMD (Taly et al., 2005). is analysis, later performed on the crystal structures of GLIC and ELIC, suggested that this gating mechanism was applicable to both prokaryotic channels (Bocquet et al., 2009; Cheng et al., 2009). However, the detailed function of a channel’s gating mechanism can hardly be understood without knowing how to activate and inactivate it. GluCl, by denition, is gated by glutamate. GLIC’s natural ligand was known even before the resolution of its crystal structure: the proton, meaning that GLIC opens at acidic pH and closes at neutral pH (Bocquet et al., 2007). On the other hand, ELIC’s detailed investigation was slowed down by the fact that activating ligands were unknown until a list of several primary amines that include GABA were found to activate the receptor (Zimmermann and Dutzler, 2011). Notably, GLIC is a cation channel with similar permeabilities for Na+ and K+ (Bocquet et al., 2007). Its conductance is 8 pS. At −60 mV, GLIC permeates only 3 to 4 ions per microsecond, making this process very expensive in terms of computational cost to study thanks to MD simulations (see sections 2.2 and 3.1.2). A second prerequisite to understand atomic details of a channel’s gating mechanism is to obtain the structures of both its open and resting state, the endpoints of the gating transition. Based on the calculation of the channel pore radius, one can determine whether a channel is in a conducting conformation or not, i.e. if ions can pass through the pore. GLIC and GluCl display very similar open conformations, while ELIC displays a closed pore. Several attempts have been made to model the gating transition from GLIC’s open state to ELIC’s closed state, assuming that ELIC is a good model for GLIC’s resting form (Zhu and Hummer, 2009, 2010; Nury et al., 2010; Calimet et al., 2013), an assumption that is still debated today considering the low sequence identity between the two proteins (see table 1.2). Furthermore, it is not clear whether ELIC’s crystal structure represents the resting state as channels may adopt dišerent closed conformations, in their1.3. pLGICs are modulated by a variety of molecules 15 desensitized state for example (Gonzalez-Gutierrez and Grosman, 2010). However, the work by Nury et al. is interesting from several points of view. First, as GLIC is sensitive to pH, they induced the channel closure by modifying the protonation state of selected residues. Second, they simulated a fully atomistic model of the GLIC system for one microsecond, leading to the closure on only two over ve subunits, which suggests that at least another microsecond would be required to simulate GLIC’s full closure. Finally, they proposed that GLIC’s closure starts by the formation of a hydrophobic gate between residues 9’ and 16’ in prime notation5 , with a twist motion of the top of M2 helices. ese ndings revealed particularly consistent with crystal structures of open and nonconductive GLIC as discussed below. Concerning GluCl’s gating, it turns out that, upon ivermectin removal, the channel closes at the hundred nanosecond timescale (Calimet et al., 2013; Yoluk et al., 2013). is transition is probably too swiŸ to be biologically relevant, as a full gating event is assumed to take place on the millisecond timescale. is swiŸness probably indicates a bias in the crystal structure and/or the simulation setup. However, several observations made during the transition of GluCl from open to closed state are consistent with the quaternary model proposed in the light of recent high resolution structures of GLIC. Among all pLGICs, GLIC is currently probably the best structural model to study transitions from open to closed state since it has been crystallized in three distinct conformations, rstly at acidic pH in an open conformation (Bocquet et al., 2009; Hilf and Dutzler, 2009), later mutants have been crystallized in a Locally Closed (LC) conformation (Prevost et al., 2012; Gonzalez-Gutierrez et al., 2013), and very recently an X-ray structure of Wild-Type (WT) GLIC in its resting state has nally been released (Sauguet et al., 2014). e LC form shares most structural features with the open state but displays a closed pore as a result of the concerted bending of the extracellular part of its M2 helices. It was recently demonstrated that WT GLIC can adopt the LC form and that the open and LC forms coexist at acidic pH (Sauguet et al., 2014), consistently with the assumption that the LC form can represent a late intermediate in the course of activation. ese structures allowed to conrm that GLIC’s gating involves a marked twist motion of the ECD, coupled with an inward tilt motion. e structure of the resting state shows that the conformation of M2 helices is remarkably dišerent from that observed in ELIC: GLIC’s pore appears closed due to a concerted bending of the upper part of its M2 helices (gure 1.9). is motion is independent of M3 helix orientation, unchanged compared to the open form. In ELIC, the M2 helix axis appears straight and M2 and M3 helices seem strongly attached to each other. 1.3 pLGICs are modulated by a variety of molecules Over decades of research, pLGICs turned out to be modulated by numerous compounds with very dišerent physico-chemical properties. I chose to present some of the most important related studies, sorting the compounds by the localization of the binding site. 5e prime notation has been introduced decades ago and aims to number residues that line the channel pore. Hence, residues with the same prime number have the same location on the M2 helix, residue 1’ being located on the intracellular end of M2.16 Chapter 1. Biological Background M2 M3 M2 M3 GLIC Open pore GLIC Closed pore ELIC Closed pore M2 M3 Figure 1.9 – Comparing GLIC and ELIC closed state. Top: enlarged views of the pore. e solventaccessible region is shown by a green mesh, the side chain of the pore lining residues are shown as sticks with polar and hydrophobic residues colored in green and yellow, respectively. Bottom: schematic representation of the M2 and M3 helix relative positions. Adapted from Sauguet et al. (submitted).1.3. pLGICs are modulated by a variety of molecules 17 1.3.1 Modulation through the sites in the ECD pLGICs are modulated by benzodiazepines, a class of widely prescribed drugs that display anxiolitic, anti-convulsive and sedative properties, targeting mainly GABA receptors. ey have been shown to bind ELIC’s ECD in two distinct sites with associated opposite modulation ešects (Spurny et al., 2012): • activation through an intrasubunit site at low concentration, • inhibition through an intersubunit site at high concentration. Notably, the intersubunit site matches a site previously described on GABAAR (Ramerstorfer et al., 2011). Divalent cations such as Ca2+ or Zn2+ have been suggested to play an important role in a biological context. Ca2+ can potentiate nAChRs (Vernino et al., 1992; Mulle et al., 1992) and inhibit 5-HTRs (Peters et al., 1988), while Zn2+ can have potentiating or inhibiting ešects, depending on its concentration and the type of pLGIC (Laube et al., 1995; Palma et al., 1998). Divalent ions have been shown to inhibit ELIC (Zimmermann et al., 2012), with a binding site at the interface between two subunits. A 2.4 Å structure of GLIC allowed to detect Br- , Cs+ and Rb+ at several binding sites in the vestibule edge region of the ECD (Sauguet et al., 2013b). In the same study, the authors suggest two binding sites for acetate, one overlapping the benzodiazepine binding site identied in ELIC, the second at the interface between two subunits. A nal study should be mentioned here. Pan et al. (2012) proposed a binding site for the General Anesthetic (GA) ketamine located at the interface between subunits in GLIC’s ECD. Interestingly, this structure is, to my knowledge, the only crystal structure of a GA bound to a pLGIC extracellular domain. However, further investigation in Marc Delarue’s group highlighted several structures with unattributed densities at the same location, even in absence of ketamine. e same group used these data to try to propose an inhibition mechanism of GLIC by ketamine, using the Perturbation-based Markovian Transmission model (Mowrey et al., 2013a). is work has, in my opinion, two weaknesses: i) the doubts that still exist on the structure of ketamine bound to GLIC and ii) the lack of dynamic analyses to conrm the validity of the paths from ECD to TMD that would explain ketamine’s action. Importantly, most of these binding sites, especially ion ones, are still largely unexplored, as most groups focused on the modulating sites in the TMD. A summary of anesthetics and alcohol binding sites found by X-ray crystallography in pLGICs is given in table 1.3. 1.3.2 Modulation through the sites in the TMD e TMD is the target of general and local anesthetics, alcohols and several cations. Modulation sites for alcohols and GAs have been characterized experimentally by combining photolabelling (Hamouda et al., 2013), site-directed mutagenesis and electrophysiology (Olsen et al., 2013; Howard et al., 2011b). ree principal binding sites for GAs and alcohols have been identied within the TMD: i) an intrasubunit pocket located within the M1-4 helix bundle, ii) an intersubunit pocket located roughly at the same height than the intrasubunit pocket and iii) a channel site located at the extracellular end of the pore, between the M2 helices. pLGICs crystal structures have been solved in complex with GAs and18 Chapter 1. Biological Background Protein Ligand Resolution (Å) Reference GAs GLIC propofol 3.3 Nury et al. (2011) GLIC desžurane 3.1 Nury et al. (2011) GLIC (F238A) bromoform 3.1 Sauguet et al. (2013a) GLIC bromoform 2.7 Sauguet et al. (2013a) ELIC bromoform 3.7 Spurny et al. (2013) Alcohols GLIC (F238A) ethanol 2.8 Sauguet et al. (2013a) GLIC (F238A) 2-bromo-ethanol 3.1 Sauguet et al. (2013a) Channel blockers GLIC bromo-lidocaine 3.5 Hilf et al. (2010) GLIC tetra-ethyl-arsonium 3.5 Hilf et al. (2010) GLIC tetra-methyl-arsonium 3.6 Hilf et al. (2010) GLIC tetra-butyl-antimony 3.7 Hilf et al. (2010) GLIC picrotoxine 3.4 Hibbs and Gouaux (2011) Table 1.3 – Crystal structure of general anesthetics, alcohols and channel blockers bound to a member of the pLGIC family. Adapted from Sauguet et al. (submitted). A B P1 B1 B2 W3 W1 W2 B1 W3 W1 W2 P1 B2 Figure 1.10 – Location of the anesthetic binding sites highlighted in pLGICs transmembrane domain. Top (A) and side (B) views of one and a half subunit transmembrane domain showing the three intrasubunit binding sites (W1 to W3), the intersubunit site (B1) present in the GlyR and in GLIC F238A mutant, Nury et al.’s linking tunnel (B2) and the pore site (P1).1.3. pLGICs are modulated by a variety of molecules 19 alcohols, covering these three sites. For convenience, we introduce here a nomenclature for these binding sites that will be consistently numbered as summarized in gure 1.10 and referred to by their number. A brominated variant of the local anesthetic lidocaine, which is known for its pore blockage properties, as well as several cations were co-crystallized with GLIC few years ago (Hilf et al., 2010). Docking based data suggested GLIC’s pore blockage by propofol and isožurane with a micromolar a›nity (Brannigan et al., 2010; LeBard et al., 2012). More recently, the co-crystal structure of ELIC with bromoform provided another experimental evidence that anesthetics can bind pLGIC’s pore (Spurny et al., 2013). Inhibition through the pore can be understood intuitively and two distinct mechanisms probably coexist. Open-channel blockers, such as lidocaine, are most oŸen charged molecules that carry the same charge as the permeating ion and block the pore by mimicking ion permeation up to the point where they sterically prevent ion conduction and jam the channel in an open conformation. On the other hand, general anesthetics such as propofol, desžurane or isožurane are mostly believed to block the pore in an allosteric fashion, either selecting or favoring, then stabilizing a closed conformation. However, from a mechanistic point of view, the hypothesis that pore blockage/closing alone is at the origin of the anesthetic-induced ešects is di›cult to reconcile with mutagenesis data indicating that mutations in the intrasubunit pocket region ašect anesthetic action (Nury et al., 2011). Binding sites in this region should therefore closely be examined, too. Propofol, desžurane and bromoform bind the intrasubunit pocket in GLIC (Nury et al., 2011; Sauguet et al., 2013a; Chiara et al., 2014). While propofol and desžurane binding poses are virtually the same, bromoform adopted three distinct poses in the cavity: site W1 (the W standing for within the subunit) overlaps the propofol and desžurane binding site; site W2 lies closer to the M1 helix and partially overlaps site W1; site W3 is deeper inserted in the cavity, between the M1 and M2 helices, at the interface between the intra- and intersubunit regions. Ethanol, 2-bromo-ethanol and bromoform were found to bind an intersubunit cavity in the structure of a GLIC ethanol sensitive variant, namely the mutant F238A. Ethanol, 2-bromo-ethanol and bromoform were shown to bind an ethanol-sensitive variant of GLIC, namely the mutant F238A, by docking in an intersubunit cavity (Sauguet et al., 2013a) that will be referred to as site B1 (the B standing for between the subunits). is site had been previously suggested for ethanol binding to the glycine receptor by MD simulations (Murail et al., 2011). GAs and alcohols binding to these sites produce opposite ešects on channel function. In GLIC, the intersubunit site B1 is thought to be potentiating (Sauguet et al., 2013a; Brömstrup et al., 2013; Murail et al., 2012; Howard et al., 2011a) while the intrasubunit W1 site is inhibitory (Nury et al., 2011). Another intersubunit site has been suggested for propofol binding to GABAAR by photolabelling at the ECD and the TMD interface (Yip et al., 2013), that had been suggested for desžurane based on MD data (Nury et al., 2011). is site will be referred to as site B2. A founding hypothesis of my work is that anesthetics modify the equilibrium between the channel open and closed states, complying with the denition of an allosteric modulator (gure 1.11). However, it should be mentioned that some experts believe that anesthetics block ion žow by sterically obstructing the channel. A consensus exists for some anesthetics such as lidocaine which is believed to be an open channel blocker. On the other hand, some anesthetics such as propofol for example have been proven to bind to GLIC’s intrasubunit pocket (Nury et al., 2011) and suggested to bind the pore as well (LeBard et al., 2012). Propofol is therefore believed by some to be a steric channel blocker and not an allosteric inhibitor. e emerging picture is that modulation is the ešect of competitive binding between the intersubunit20 Chapter 1. Biological Background Resting state Activation by agonist Inbibition by anesthetic (cationic channels) Potentiation by anesthetic (anionic channels) Open channel Closed channel Neurotransmitter Anesthetic Figure 1.11 – Hypothesis of anesthetic action on the function of ionotropic channels. Neurotransmitters as well as anesthetics are believed to change the equilibrium between the channel conformations i.e. open and closed. e neurotransmitter modies the equilibrium in favor of the open state. At excitatory channels, anesthetics favor the closed state, preventing cations to enter the cell therefore the increase of the membrane potential. At inhibitory channels, they favor the open state, allowing anions to enter the cell which have the ešect of decreasing the membrane potential. At excitatory as well as at inhibitory channels, anesthetic action is therefore to inhibit the transmission of the action potential. potentiating site and the intrasubunit inhibitory site, which is consistent when applied to mammalian pLGICs since GAs and alcohols potentiate inhibitory channels GABAARs and GlyRs, while they inhibit the excitatory nAChRs. Although, despite the accumulation of crystal structures of general anesthetics bound to a member of the pLGIC family, the molecular mechanism of allosteric inhibition by anesthetics binding to intra- and intersubunit pockets is still poorly understood. Regarding the probable existence of general anesthetic binding sites in pLGICs pore, channel modulation is to be regarded as the combined ešect of binding to the intra, inter, and pore regions. 1.4 Context in October 2010 In the next few lines, I attempt to provide some context for the choices I made when I started to work on the project, in October 2010. A close collaboration was initiated in 2009 between Marc Delarue’s group at Institut Pasteur and my PhD supervisor, Marc Baaden. In January 2011, Marc Delarue’s group released the rst structure of general anesthetics bound to GLIC (Nury et al., 2011). His group co-crystallized propofol and desžurane bound to1.4. Context in October 2010 21 GLIC’s intrasubunit pocket. As electrophysiology measurement showed marked dišerences in the modulation of several GLIC mutants by these GAs, Marc Baaden was in charge of running MD simulations aiming to understand this phenomena. ese simulations yielded interesting but incomplete data on anesthetic dynamics while bound to the receptor, mainly suggesting that channel closure could be caused by the repetitive contacts between GAs and the M2 helices. We decided to center the start of my thesis on three principal aspects: i) the extensive characterization of desžurane and propofol dynamics bound to the crystallographic site; ii) understanding why propofol inhibits more the T255A mutant than the WT GLIC; iii) understanding why desžurane has an opposite ešect than propofol on this mutant, i.e. it is less ešective on the mutant than on the WT. In early 2013, our collaborators at Institut Pasteur came back to us with several structures of bromoform bound to GLIC, displaying among other previously unseen sites, a bromoform molecule bound to the pore of GLIC in LC conformation. As I had developed a suite of tools that allowed me to rapidly launch MD simulations on a system of interest and e›ciently analyze the results, our collaborators asked us to characterize GLIC’s inhibition by bromoform. In the next two chapters, I will introduce the methods I used and developed during this project. e characterization of GLIC’s inhibition by bromoform will be detailed in chapter 4. e following chapter will be devoted to the study of propofol and desžurane dynamics while bound to GLIC. Finally, I will end the present manuscript with some concluding remarks.Molecular Modeling: Theory And Practice 2 In this chapter, I introduce the principal method I have been using in this work: molecular modeling. Molecular modeling includes a wide range of methods, from mixed experimental-theoretical to purely theoretical ones. As an example of a so-called mixed method, Nuclear Magnetic Resonance (NMR) and X-ray crystallography are widely used to determine the three-dimensional structures of molecules. Both methods have a strong in vitro component including protein expression, purication and raw data acquisition. Since none of these techniques routinely allow to precisely determine the position of atoms from raw data, in silico models are used to t atoms in the signal acquired from the machines (Trabuco et al., 2008; Brünger et al., 1998). Pure in silico methods developed during the last decades faced with the lack of in vitro methods able to describe molecule dynamics at the atomistic scale. MD simulations are a member of the large family of pure in silico methods, further including Brownian Dynamics, Normal Modes Analysis, or docking for example. ese methods belong to the family of molecular mechanics methods that require the use of a force eld (see section 2.1) to describe the interactions between a system of particles. Despite their empirical nature, these methods have proven their ability to reproduce data obtained from “wet lab” experiments and are used to answer questions that in vitro and in vivo procedures cannot. In 2013, the Nobel Prize in Chemistry was awarded jointly to Martin Karplus, Michael Levitt and Arieh Warshel for the development of multiscale models for complex chemical systems, an acknowledgment that in silico methods are to be considered as an essential tool that can, together with in vitro and in vivo methods, address some of the most challenging questions of our time. is chapter is divided into four sections. e rst three sections briežy introduce respectively the concepts of force eld, MD simulation and free energy calculations. Finally, the fourth section will be devoted to challenges mostly related to the simulation of biological systems. 2.1 Force Fields As opposed to quantum mechanical representations that aim to describe the dual particle-like and wavelike behavior of energy and matter, molecular mechanics representations use classical mechanics to model a molecular system. Molecular mechanics methods require the use of a force eld that describes the interactions between a system of particles with contributions of processes such as the stretching of bonds,24 Chapter 2. Molecular Modeling: eory And Practice Vpotential = ∑ bonds ki 2 (li − li,0) 2+ ∑ angles ki 2 (θi − θi,0) 2+ ∑ torsions Vn 2 [1 + cos(nω − γ)]+ N−1 ∑ i=1 N ∑ j=i 4εi j ⎡ ⎢ ⎢ ⎢ ⎢ ⎣ ( σi j ri j ) 12 − ( σi j ri j ) 6⎤ ⎥ ⎥ ⎥ ⎥ ⎦ + N−1 ∑ i=1 N ∑ j=i qiqj 4πε0ri j + - Figure 2.1 – Equation of potential energy and schematic representation of the various contributions. e total potential energy is the sum of bonded (bonds, angles, torsions) and non-bonded (steric, electrostatic) interactions. the opening and closing of angles, the rotations about single bonds and non-bonded interactions between particles. It should be noted that some methods do not account for all these components. As an example, in rigid docking bonded interactions are oŸen ignored while classical spring network models do not explicitly account for electrostatic interactions (Tirion, 1996; Bahar et al., 1997; Hinsen, 1998). e classical form of a molecule’s potential energy is shown in the illustrated equation of gure 2.1. For each component, energy penalties are associated with the deviation from equilibrium values. e resolution of these equilibrium values, even when based on experimental data, is oŸen adjusted to t a molecule’s macroscopic properties that can be measured thanks to in vitro experiments. is process is called parametrization. For example, during the parametrization of small molecules such as anesthetics, it is common to use the density of a pure solution of this molecule and the solvation energy of this molecule in water as target properties. As another example, lipids are oŸen parametrized in such a way that the order parameter of each carbon atom ts in vitro data. As a consequence and since force elds are parametrized to t a nite set of properties that can be dišerent from one force eld to another, it is not surprising that a given force eld may perform better reproducing certain properties compared to another one (and conversely). It is then crucial to choose with precaution which force eld is the most appropriate to reproduce the properties one wants to study. For example, several studies highlight the fact that the Amber03 force eld overstabilizes helical structures (Cino et al., 2012; Lindorš-Larsen et al., 2012) while it has been suggested that the OPLS-AA force eld may be biased in favor of bends over helices (Cao et al., 2011; Cino et al., 2012; Vamparys, 2013).2.2. Molecular Dynamics Simulations 25 Initialize ri and vi Fi = − ∂V ∂ri ai = Fi mi Update ri and vi repeat as long as needed Figure 2.2 – e algorithm underpinning molecular dynamics simulations. With ri the cartesian coordinates of the atom i, vi its velocity, Fi the net force acting on it, V the potential energy applied to it, ai the acceleration applied to it and mi its mass. 2.2 Molecular Dynamics Simulations Molecular Dynamics (MD) is a computer simulation method that integrates Newton’s laws of motion to calculate successive congurations of a system, resulting in a trajectory of atom coordinates and velocities over time. e second law of motion states that the acceleration of a body depends directly upon the net force acting upon the body, and inversely upon the mass of the object. us F = ma, where F is the net force acting on the object, m its mass and a its acceleration. anks to a force eld, F can be calculated for each particle of a system. Since the particle mass is known, its acceleration can be calculated, therefore its position at the next iteration can be deduced. is process, called integration of equations of motions can be performed several times to obtain a trajectory for each particle in the system (gure 2.2). e integration of motion equations can be done thanks to several integrators, each one having specic properties. Next I will develop a few examples of such integrators. Because MD is an in silico method, the soŸware used to run the calculations plays a central role in the data acquisition. During my thesis these issues proved important. In this part I will introduce some dišerences that exist in the main two soŸware suites that I used for MD simulations, namely NAMD and GROMACS. 2.2.1 Equation of motion integration algorithms is part could lead us into the deepest pits of classical physics and mathematics. I chose to present only a few key concepts in order to highlight some of the most important properties that should be considered before running an MD simulation. ere are a variety of algorithms that can be used to solve ordinary dišerential equations. e most basic methods are probably the Euler method, named aŸer Leonard Euler who proposed it in the late 17th century, and its generalization by C. Runge and M. W. Kutta, called the Runge-Kutta method.26 Chapter 2. Molecular Modeling: eory And Practice 0 2 4 6 8 10 12 14 16 18 20 27.5 27 26.5 26 25.5 − − − − − − 25 Velocity Verlet, ∆t =1 fs Runge−Kutta 4, ∆t =1 fs 0 2 4 6 8 10 12 14 16 18 20 25.464 25.4635 25.463 25.4625 − − − − − 25.462 Velocity Verlet, ∆t =0.1 fs Runge−Kutta 4, ∆t =0.1 fs Time (ps) Total Energy (Kcal/mol) Figure 2.3 – Sympletic vs non-symplectic integrators. Energy evolution of a water tetramer simulated by the symplectic Verlet scheme (solid line) versus the non-symplectic Runge-Kutta integrator (dashed line) at two time steps (0.1 and 1 fs). From Schlick (2010). ese methods are quite intuitive and easy to implement, but do not feature one of the most important properties an integrator should have in MD: they are not symplectic integrators. Sympletic integrators are integrators that preserve specic properties associated with the Hamiltonian system of dišerential equations, including its value i.e. its energy (Schlick 2010, section 14.2). In practice, the total energy is not preserved exactly but the energy error remains contained over time, which is dišerent from non-symplectic integrators which display a systematic energy driŸ over time. Runge-Kutta or Euler integrators are therefore not to be used in MD. e most popular methods for integrating Newton’s laws of motions derives from the Verlet method (Verlet, 1967) in which the positions are given by r(t + ∆t) ≈ 2r(t) − r(t − ∆t) + F m ∆t 2 (2.1) with ∆t the time between two snapshots. e velocities are given by v(t) = r(t + ∆t) − r(t − ∆t) 2∆t + O(∆t 2 ) (2.2) with O(∆t 2 ) being the interpolation error. NAMD implements the velocity-Verlet algorithm (Phillips et al., 2005) while GROMACS’ default MD integrator is leap-frog (Pronk et al., 2013). GROMACS also implements a variety of integrators which are mostly variants of either leap-frog or velocity-Verlet, each one aiming to either increase accuracy or e›ciency under certain circumstances.2.2. Molecular Dynamics Simulations 27 2.2.2 Integration time step e upper limit for the integration time step ∆t in the integration scheme depends on the fastest motions in the system. For biological systems under biological temperature and pressure conditions, these motions are light-atom bond vibrations, which are on the order of 10 fs (Schlick 2010, section 14.2.3). It is usually accepted that ∆t has to be one order of magnitude lower than the fastest motions in the system, i.e. 1 fs in this case. As the amount of CPU-time1 a user can spend calculating an MD simulation is xed and since the computation time of one time step is constant, it is therefore useful to be able to increase the value of ∆t to speed up the simulation: computing 1,000,000 simulation steps with ∆t = 1fs will output a 1 ns long simulation trajectory, while, with ∆t = 2 fs, 2 ns can be calculated in the same amount of time. e integration time step can be increased by treating bond stretching degrees of freedom as rigid. e traditionnal algorithm to constrain bonds, implemented in NAMD, is SHAKE (Ryckaert et al., 1977). e LINCS algorithm (Hess et al. 1997, a default in GROMACS), has proven of higher e›ciency and presents better convergence properties. Both algorithms solve the same problem i.e. resetting coupled constraints aŸer an unconstrained update. Interestingly, a third algorithm optimized for rigid water molecules, named SETTLE (Miyamoto and Kollman, 1992), has been implemented in both soŸware packages and is commonly used in the simulations of biological solutions. An alternative scheme to treat high-frequency vibrational modes is to separate the calculation of the force on a particle into two components: short-range and long-range forces, the underlying idea being that long-range forces vary more slowly than short-range forces. is technique, known as multiple-timestepping, allows to use dišerent time steps for bonded and non-bonded interactions. NAMD implements this idea separating bonded forces, Lennard-Jones and short-range electrostatic forces and nally longrange electrostatic forces in three dišerent loops. Typical multiple time step example values would be 2 fs, 2 fs and 6 fs. Multiple-time-stepping is not yet implemented in GROMACS. 2.2.3 Non-bonded interactions under periodic boundary conditions Periodic boundary conditions Without specic boundary conditions, the simulation of a molecular system would take place in vacuum: particles at the system’s border are surrounded by nothing. At a moderately short time scale, this would lead to serious artefacts because the whole system would dišuse in the innite space of cartesian coordinates. e solution to this issue is to circumscribe the system in a box just large enough to encompass every particles of the system. But this would lead to other artefacts: border particles would repeatedly collide with the box, which would strongly impact their behavior. Because the size of the systems that can be currently simulated with MD is still so small, the abnormal behavior of border particles would nally impact little by little every components of the system. A solution to this problem is to periodically repeat the simulation cell, a technique known as Periodic Boundary Conditions (PBC). A particle exiting on one side of the cell enters from the opposite face with the same velocity (gure 2.4). Besides, border particles on one side of the cell interact with particles at the opposite side. is technique therefore simulates an 1Cost of a simulation, expressed as the amount of time for which a Central Processing Unit (CPU) was used processing instructions of a computer program (denition from wikipedia.org). For example, a calculation that was run on 128 CPUs and lasted 2 hours consumed t = 2 × 128 = 256 CPU-hours.28 Chapter 2. Molecular Modeling: eory And Practice Figure 2.4 – Periodic boundary conditions. e initial cell (central) is replicated in each direction so that border particles interact with particles from the neighboring cell. Particles that exit a cell on one side enter the cell on the opposite side. innite system, but interactions with contributions from an innite number of neighboring images have to be calculated, with consequences on computational e›ciency. Non-bonded interactions e complexity of computing non-bonded interactions is O(N 2 ) where N is the number of atoms. is is because non-bonded interactions have to be computed between all pairs of atoms. Such a complexity implies a huge computational cost: Schlick (2010) estimates to roughly 2 years the CPU-time required to calculate a single nanosecond of a 10,000-atom system. Fortunately, techniques have been developed to reduce the dramatic cost of computing non-bonded interactions without decreasing the accuracy of simulations of biomolecules in solvent. e rst technique is to use a spherical cutoš scheme, which is easy to implement and cheaper than brute calculation (O(N)). ere are three categories of cutoš techniques, all of them setting the contribution of atoms remote from each other of a distance r > b to 0. e dišerence between the techniques are their behavior when r <= b (gure 2.5): • the truncation approach does not change the value of the energy when r <= b, therefore abruptly sets the interaction energy to 0 when r > b, • switching schemes smoothly change the energy value for a <= r <= b, • shiŸ functions alter the function for all r < b. In simulations of biomolecules, spherical cutoš schemes are mostly used for representing van der Waals interactions, which are quite short-range interactions. Electrostatic interactions are long-range interactions that play a critical role in biomolecules. e Particle Mesh Ewald (PME) approach has revolutionized biomolecular simulations, reducing the computational cost of calculating long-range interactions from O(N 2 ) to O(N log N) (Darden et al., 1993). is technique, which has been developed specically to be used under PBC, employs direct calculation for short-range interactions while long-range interactions are calculated in reciprocal space thanks to Fast Fourier Transforms (FFT).2.2. Molecular Dynamics Simulations 29 orig. trunc. switch shift 7 8 9 10 11 x 10-3 0 -2 -4 -6 VdW potential (kcal/mol) r (Å) a b 0.00 -0.06 -0.04 -0.02 4 6 8 10 Figure 2.5 – Spherical cutoš schemes for non-bonded interactions. Van der Waals potential for various cutoš schemes with bušer region 6-10 Å. Example of a Cβ − Cβ interaction with parameters taken from the CHARMM program. Adapted from Schlick (2010). 2.2.4 Statistical ensembles: thermostats and barostats Biological organisms live under strict conditions of temperature and pressure. To mimic a biological environment, it is fundamental to be able to reproduce the atomic vibrational movement associated with a given temperature and pressure. It is therefore very common for simulations of biological interest to run in the NPT ensemble, i.e. an ensemble where the Number of particles, the Pressure and the Temperature are retained constant. Temperature coupling e temperature T of a system is related to its kinetic energy, which is given by: Ekinetic = 1 2 N ∑ i=1 miv 2 i = 1 2 νkT (2.3) where ν is the number of degrees of freedom, i.e. 3 per atom (velocities along x, y and z axes)2minus the number of constraints applied to the system. For example, for a system of N atoms with xed bond length and center of mass momentum removal, ν = 3N − Nbonds − 3. Controlling the temperature can therefore be done by a simple scaling of the velocities at each time step. However, algorithms coupling to an external bath are oŸen preferred because they allow the temperature to žuctuate about the desired temperature. e Berendsen weak-coupling scheme (Berendsen et al., 1984) is a widely used algorithm. It has been implemented in several MD soŸware packages such as NAMD and GROMACS. However, while it performs fast temperature equilibration, it does not generate rigorous canonical averages (Leach, 2001). Dišerent canonical algorithms are therefore oŸen used for the production phase, such as the Andersen thermostat (Andersen, 1980) or the Nosé-Hoover scheme (Nosé, 1984; Hoover, 1985). GROMACS also implements a velocity rescaling method which is very similar to a Berendsen thermostat with an additional stochastic term that ensures a correct canonical ensemble (Bussi et al., 2007). 2ere are 6 degrees of freedom per atom in the system, 3 for its velocity components plus 3 for the positions. As the kinetic energy does not depend on atomic positions, here each atom accounts for 3 degrees of freedom.30 Chapter 2. Molecular Modeling: eory And Practice Pressure coupling e instantaneous pressure p(t) is computed as the trace p = 1 3 Trace P (2.4) of the pressure tensor P = 2 V ( 1 2 N ∑ i=1 mivi ⊗ vi − Ξ) (2.5) from the virial tensor Ξ = − 1 2 ∑ i 100 mM). is process is depicted on gure 2.9 along with data for alcohol partitioning (Murail et al., 2011). Brannigan’s study implies that a long equilibration of the system may be necessary before concentrations can be measured reliably in order to allow solute molecules to partition between aqueous and membrane phases. It may be debated whether concentrations should be calculated with respect to the water phase only, with respect to water and membrane or with respect to the entire simulation box. 2.5.3 Protonation state Knowing the protonation state of ionizable residues is a key issue to reliably model a protein. e protonation state depends on a residue’s local environment. Standard pKa values measured in bulk cannot be applied to buried protein residues, in particular for membrane proteins with an environment that largely dišers from aqueous solution. GLIC is constituted of ve symmetric protomers and the location of its 81 × 5 ionizable residues is shown in gure 2.10. We may consider that equivalent residues in each subunit bear identical protonation states. is assumption leads to approximately 281 = 1019 possible combinations of protonation states. Tang and coworkers suggest that the protonation state of some titratable groups may be dišerent from one protomer to another leading to up to 1098 dišerent combinations (Cheng et al., 2010; Willenbring et al., 2011), a gure exceeding the number of particles in the universe! e development of methods for calculating pKa values of titratable groups in proteins was pioneered by Tanford and Kirkwood (1957) who proposed to represent the protein as an impenetrable sphere, which allows to analytically solve the Poisson-Boltzmann Equation (PBE). e increase in computing performances has facilitated the development of many PBE solvers, including the widely used APBS soŸware (Fogolari et al., 2002; Baker et al., 2001). Nielsen and coworkers showed that a Finite Dišerence PoissonBoltzmann method yields better results when adding an explicit step to optimize the hydrogen bond38 Chapter 2. Molecular Modeling: eory And Practice 1 10 100 1000 0 0.3 0.6 0.9 0 100 200 300 400 100 1000 ISO - nAChR ISO - GLIC Eth - GlyR Fraction ISO/Eth in membrane [ISO]aq (mM) [Eth]aq (mM) Time (ns) Figure 2.9 – Isožurane and ethanol partitioning along žooding simulations. Isožurane (black and red) and ethanol (green) partition into the membrane during the equilibration of a GLIC, a nAChR and a GlyR system, respectively. e aqueous concentration of isožurane (top) decreases for the benet of the fraction in the membrane (bottom). e same behavior is observed for the partitioning of ethanol during the equilibration of a GlyR system (green) but to a lesser extent. Due to its more hydrophilic properties, ethanol concentration decreased to half the initial one (≈ 300 mM) at the end of the simulation. is is in contrast to isožurane: its concentration drops to less than 10% of the starting one (≈ 10 mM). network (Nielsen et al., 1999). Ideally, protein conformational žexibility should be taken into consideration for calculating pKa values. Specic terms have been included in some algorithms (Alexov and Gunner, 1997) and, more recently, methods based on the λ-dynamics approach using constant pH MD and Replica Exchange Molecular Dynamics emerged (Donnini et al., 2011; Williams et al., 2011; Meng and Roitberg, 2010). ese latter methods are currently still under development and have so far only been tested on small non-membrane peptides or proteins. PROPKA (Li et al., 2005; Bas et al., 2008) may be one of the most commonly used empirical approaches because it is very fast. In order to setup simulations of the GLIC system, we assessed the results of several widely used programs and web services. ese pKa predictions yielded widely varying pKa shiŸs as illustrated in gure 2.11. We settled on the use of the Yasara soŸware (Krieger et al., 2002) mixing Ewald summation and hydrogen bonding network optimization to determine if a titratable group should be protonated or not (Krieger et al., 2006). e Yasara results remain in a reasonable pKa shiŸ range, whereas some of the other methods suggest huge shiŸs (gure 2.11). We applied a consensus approach, only protonating residues that were simultaneously found to change ionization state in all ve subunits. Subsequent Brownian Dynamics simulations suggested that a neutral H11’ residue is most compatible with ion permeation (data courtesy of Prof. Toby Allen; not shown) and the inžuence of this protonation state has been tested in more recent simulations. Many ešorts in improving the crystallization protocol for GLIC recently lead to a higher resolution structure in which ion binding can be predicted between residue D86 and D88. is is a strong indication that these residues should not be protonated (Sauguet et al., 2013b). ese ndings allowed us to iteratively improve our protonation state estimate for GLIC.2.5. Di›culties 39 Figure 2.10 – Localization of ionizable residues shown in a cross-section of the GLIC ion channel (grey). M2 helices, in cartoon representation, line the pore through which cations (pink) cross the membrane (ochre).40 Chapter 2. Molecular Modeling: eory And Practice Figure 2.11 – pKa shiŸ predictions with respect to standard values for all ionizable residues in GLIC obtained using dišerent soŸware packages. Residues are ordered according to ∆pKa = (pKa solution − pKa calc) with respect to the Yasara soŸware (A) or the PROPKA soŸware (B), respectively. e bottom part of each panel indicates the amino acid type of each residue.2.5. Di›culties 41 -20 -10 0 10 20 0 50 100 150 200 -20 -10 0 10 20 z (Å) Time (ns) A B Figure 2.12 – Hydration traces of GLIC’s pore during two representative simulations. Minor changes in the simulation parameters can make a noticeable dišerence between a fully hydrated channel (A) and a channel that dehydrates spontaneously in the upper part of the M2 helix-lined pore (B). For both simulations, the protonation states were identical (Bocquet et al., 2009), the only dišerences were the forceeld and the MD soŸware used (amber99 and Gromacs for simulation A, vs. Charmm22 and NAMD2 for simulation B). 2.5.4 Solvation in special/unusual environments e complex shapes of proteins may feature channels and cavities providing special, potentially solvated nano-environments. Water in such hydrophobic nanoconnement may be particularly unstable, a phenomenon known as capillary evaporation. Several groups have observed and characterized dewetting transitions in MD simulations, for example in the context of nanopores (Beckstein and Sansom, 2003; Beckstein et al., 2001) or in the bacterial mechanosensitive channels MscL and MscS (Anishkin et al., 2010; Anishkin and Sukharev, 2004). Roth and coworkers suggest that capillary evaporation could constitute an intrinsic property of some channels (Roth et al., 2008) and may be a widespread biological mechanism. In the case of GLIC, extensive sampling lead us to observe an unexpected pore dewetting behavior (see gure 2.12A), as did several other groups (LeBard et al., 2012; Willenbring et al., 2011). Yet we cannot currently conclude whether GLIC belongs to a family of bubble gated ion channels, since ongoing studies in our lab suggest that subtle changes in the simulation parameters may prevent dewetting to occur (see gure 2.12B). Another very recent study is more a›rmative (Zhu and Hummer, 2012b). It should be noted that forceeld parameters generally have not been tuned to reproduce the behavior of water in such special environments, which is in part due to the lack of experimental data. 2.5.5 Sampling, statistics, timescale A fundamental question before starting any computational study is how to best spend the limited amount of available computing time. Strategies may vary in between two extremes: a) running many short simulations from several starting points or b) running an extended one-shot simulation. Shaw et al. recently showed that the result of the second approach matches experimental data very well, when the MD simulations are long enough (Shaw et al., 2010). In 2010, my PhD host lab studied GLIC gating in a 1 microsecond MD simulation suggesting a domino gating mechanism in which subunits sequentially switch from an open to a closed conformation (Nury et al., 2010). Despite the large amount of computational resources (approx. 10 months of calculations on42 Chapter 2. Molecular Modeling: eory And Practice Figure 2.13 – Sodium ion occupancy and related relative Boltzmann energy accumulated during a one microsecond MD simulation. Ions are blocked in the upper part of the transmembrane domain. a supercomputer in 2009, i.e. tens of years on a recent desktop machine), only two protomers had fully undergone this transition to a closed state at the end of the simulation, suggesting that a much longer simulation was required to achieve a complete gating transition in all ve protomers. Longer simulations are also needed to characterize processes such as ion permeation. Since GLIC has a low conductivity of 8 ps, one should observe an estimated passage of only 3 ions per microsecond at −65 mV. A cheaper alternative is to map the a›nity of ions for a certain position along the channel pore. Such a graph was determined previously from the 1 microsecond gating simulation for a non-conductive state with a central barrier (gure 2.13). It is usually admitted that a simulation should be run at least 10 times longer than the slowest timescale of interest (Zuckerman, 2011). is is oŸen impossible since many relevant biomolecular timescales exceed 1 microsecond. Typically, the neuromuscular acetylcholine receptor’s gating is expected to be in the range of 1 to 10 µs (Chakrapani and Auerbach, 2005) which implies MD simulations from 10 to 100 µs. Running several short comparative simulations may be more appropriate for ligand binding studies, for example involving drugs and anesthetics as illustrated in the results of this PhD thesis. An advantage of such short simulations is to remain close to a well dened state, e.g. a crystal structure, rather than moving away from the experimentally backed conformation to some transient intermediate state. Furthermore one may reduce the number of unproductive runs where the drug may dišuse out of the binding pocket into the solvent. Many short simulations with slightly dišerent ligand starting conformations improve statistics and sampling. We employ such an approach to study two general anesthetics, propofol and desžurane, that2.5. Di›culties 43 have recently been co-crystallized with GLIC (Nury et al., 2011). is study revealed a binding site in the upper part of the transmembrane domain of the protein. Other binding sites for general anesthetics and alcohols, including transmembrane, extracellular and pore sites have been suggested (Cheng et al., 2010; Chen et al., 2010; Brannigan et al., 2010; Howard et al., 2011a). Channel blocking by charged quaternary ammonium compounds, divalent ions and lidocaine has been shown using electrophysiology and X-ray crystallography (Hilf et al., 2010), also suggesting binding sites located in the pore of the channel. ese observations pose the problem of sampling from a combinatorial point of view: multiplying the number of sites by the number of ligands, then by the number of mutants one wishes to test quickly leads to an intractable required total simulation time. Lipids are crucial for the structure and function of membrane proteins. Bilayers with complex compositions pose a particular sampling challenge (Soares and Straatsma, 2008). A misplaced lipid in a simulation setup might have consequences on the whole trajectory, in particular if it were to play a specic biological role. With a dišusion coe›cient of the order of 10−8 cm2 /s, a lipid embedded in a membrane is expected to have a mean-square displacement of 4 nm2 for a one microsecond long simulation. In our GLIC simulations, convergence for this value sets on beyond 100 ns and fully stabilizes at about 500 ns. Hence, the timescale of most current studies does not allow for an extensive reorganization of lipids around membrane proteins. Parton et al. recently addressed this problem while simulating a whole vesicle, demonstrating the importance of lipid dišusion for protein aggregation (Parton et al., 2011). e authors however highlight that the coarse grained models are highly simplied and inevitably approximate the nature of the protein-lipid and protein-protein interactions. de Meyer et al. (2010) previously suggested the role of cholesterol in protein clustering using dissipative particle dynamics Monte Carlo and a more simplied model. At last, the problem of simulation convergence should be raised briežy. Methods for the quantication of sampling have been proposed for several decades, yet none has been widely adopted. In 2000, Berk Hess proposed a method based on principal component analysis (Hess, 2000) that has been used by other groups to evaluate the convergence of a set of MD simulations (Faraldo-Gómez et al., 2004; Grosseld et al., 2007). Faraldo-Gómez and coworkers focus on convergence of membrane protein simulations, and although the timescale is relatively short by today’s standards, their main ndings are likely still valid. eir work concludes that structured transmembrane domains converge relatively fast, even on a 10 ns timescale, but more mobile parts are under-sampled. Grosseld et al. calculated 26 independent 100 ns molecular dynamics runs of rhodopsin and found similar results (Grosseld et al., 2007). To date, despite new method proposals (Grosseld and Zuckerman, 2009; Zhang et al., 2010; Zhu and Hummer, 2012a), sampling quality is oŸen tentatively assessed based on several simple criteria. A single descriptor may be monitored along a simulation until it reaches a stable value. e Root Mean Square Deviation (RMSD), which is a descriptor for molecular deformation, is a common but controversial criterion. A variation consists in stopping a simulation aŸer a descriptor reaches an experimental reference value and remains close to it for a certain time. Another approach is to use several independent MD simulations with dišerent starting points. When these simulations converge to a similar state, sampling is considered su›cient.44 Chapter 2. Molecular Modeling: eory And Practice 2.6 Setups and methods used in this work In this subsection I rst describe the simulation setups that form the basis for this thesis, representing a total of over 1600 nanoseconds sampling accumulated on the anesthetic-bound GLIC system. At the end I highlight a few non-standard methods used to calculate condence intervals on these data sets, characterize the location of the anesthetic in a given binding site and determine binding pocket volume. is work reports MD simulations of three dišerent anesthetics bound to GLIC. Molecular models of propofol (PFL) and desžurane (DSF) bound to GLIC were built using a pre-equilibrated system of GLIC embedded in a fully hydrated lipid bilayer. GLIC’s initial conguration was based on PDB ID 3EAM, in which protein conformation is virtually identical to the later released high resolution structure 4HFI (RMSD on heavy atoms is 0.4 Å), and then equilibrated without restraints for several tens of nanoseconds. GLIC’s conformation at the end of the equilibration phase displayed an RMSD relative to 3EAM of 2.5 Å (calculated and tted on the protein Cα atoms). For bromoform, molecular models of open GLIC were built from PDB ID 4HFI (wild-type) and 4HFD (F238A). e system was equilibrated with harmonic constraints on the protein backbone for 200 ns. Residue protonation state was assigned in the same fashion as in previous simulations (Nury et al., 2011) on the basis of pKa calculations with the Yasara soŸware (Krieger et al., 2012) to represent the most probable pattern at pH 4.6, with residues E26, E35, E67, E69, E75, E82, D86, D88, E177 and E243 being protonated. All histidines were doubly protonated (unless stated otherwise). e models were inserted in a fully hydrated palmitoyl-2-oleoyl-sn-glycerol-phosphatidylcholine (POPC) lipid bilayer. e net charge of the system was neutralized with Na+ and Clcounter ions. e NAMD (Phillips et al., 2005) and GROMACS (Pronk et al., 2013) soŸware suites were used for short and long MD simulations, respectively. 2.6.1 Short 8 ns long MD simulations Anesthetic initial poses e ligand was inserted into a previously equilibrated system of GLIC embedded in a fully hydrated lipid bilayer. Bromoform (MBR) poses have been generated by randomly moving and rotating bromoform molecules around the crystallographic binding site. Propofol and desžurane poses have been generated by taking the largest clusters from a 30 ns long MD simulation of the GA bound to GLIC. Previous coordinates were calculated using the GROMACS g_cluster program with the gromos algorithm. e cutoš distance for the clustering has been determined empirically to t the number of starting conformations we needed i.e. approximately 125. GA molecules were assigned dišerent conformations in each of the ve GLIC subunits and in each of the 25 systems that were simulated achieving a total of 125 dišerent poses, which maximizes anesthetic sampling in the binding pocket. Each system was then minimized for 1000 steps and ran for 8 ns using the run parameters described below.2.6. Setups and methods used in this work 45 Anesthetic GLIC variant Conformation* Binding site† Sampling (ns) Total sampling (ns) MBR WT Open W1 25 × 8 = 200 1000 MBR WT LC P1 10 × 8 = 80 80 MBR F238A Open B1 25 × 8 = 200 1000 DSF WT Open W1 25 × 8 = 200 1000 DSF WT LC W1 25 × 8 = 200 1000 DSF T255A Open W1 25 × 8 = 200 1000 DSF T255A LC W1 25 × 8 = 200 1000 PFL WT Open W1 25 × 8 = 200 1000 PFL WT LC W1 25 × 8 = 200 1000 PFL T255A Open W1 25 × 8 = 200 1000 PFL T255A LC W1 25 × 8 = 200 1000 Table 2.3 – Systems simulated by means of short MD simulations. Each GLIC protomer hosts a GA. Considering that each GA molecule is independent from the ones in the neighboring subunits, an MD simulation of 5 GAs bound to GLIC therefore provides 5 times the sampling. * LC conformation is dened in section 1.2.3. † Site numbering is dened in section 1.3.2. MD run parameters MD simulations were performed using the CHARMM27 (MacKerell et al., 1998) force eld. Temperature and pressure were maintained using Langevin dynamics (Kubo et al., 1992) and a Langevin Piston (Feller et al., 1995), respectively, at 310 K and 1 bar. Short-range non-bonded interactions were computed using a potential switching from 8.5 to 10 Å. Long-range interactions have been treated using PME (Darden et al., 1993). e same protocol has been used for each system for which short MD simulations were calculated (table 2.3). 2.6.2 Long MD simulations beyond the hundred nanoseconds timescale e žooding simulation setup was carried out by my colleague Samuel Murail. For long MD simulations a previously equilibrated system containing GLIC, 246 POPC lipids, 29141 water molecules, 170 Cland 135 Na+ ions (i.e. a total of 146,000 atoms) in an hexagonal box was used to create the system with 200 bromoform molecules. It was equilibrated for 50 ns with position constraints on GLIC Cα atoms with the 4HFI structure as a reference. en four iterations were used to add slowly the bromoform and avoid aggregates due to its low solubility. In each iteration, 50 molecules of bromoform were added by replacing random water molecules 10 Å away of protein and 4 Å away of the membrane. e system was then minimized for 10,000 steps and equilibrated with position constraints on GLIC Cα atoms with the 4HFI structure as a reference. In the two rst iterations, equilibrations were 50 ns long, and 100 ns long in the two following. In a last step bromoform molecules which were bound in the intrasubunit cavity were replaced in the water phase and the system was minimized for 10,000 steps. is equilibrated system was then used as starting point for the three žooding simulations. For simulation of F238A, the phenyl46 Chapter 2. Molecular Modeling: eory And Practice side chain was removed manually from the system and a minimization of 10,000 steps was run. In each of the three simulations, a supplementary equilibration step was used consisting in a 10 ns equilibration with position constraints on heavy atoms, and 20 ns with position constraints on Cα atoms. Reference structures used were, for WT open, WT LC, and F238A open simulations, respectively, PDB:4HFI, the structure presented in chapter 4 and PDB:4HFD. Production runs were nally carried out for 1 µs without any constraints. Simulations were performed using GROMACS 4.6.3 using virtual interaction sites, 5 fs time steps, and all bond lengths constrained with the LINCS algorithm (Hess et al., 1997). Electrostatics interactions were computed using particle mesh ewald summation at every step. A 10 Å cutoš was used for non-bonded interactions and the neighbor list was updated every 5 steps. ree baths (protein, water and ion, membrane) were coupled to a temperature of 310 K using the Bussi velocity rescaling thermostat with a time constant of τ = 0.1 ps. e x/y dimensions were scaled isotropically with a Berendsen weak barostat and the z dimension independently to reference pressures of 1 bar, τ = 5 ps and compressibility of 4.5 × 10−5 bar−1 . During equilibration position restraints of 1000 kJ/(mol nm) were used. 2.6.3 Free energy calculations irdly, we calculated the bromoform a›nity for each of the 6 binding sites in WT, F238A, open and LC variants of GLIC using alchemical free energy calculations (gure 2.14). e bromoform poses displayed in the crystal structure were used when available. e bromoform pose in intersubunit site B2 was extracted from a short MD simulation. Bromoform was inserted into a previously equilibrated system of GLIC embedded in a fully hydrated lipid bilayer. MD simulations were performed using the CHARMM36 (Huang and MacKerell, 2013) force eld. e system was minimized for 10,000 steps. Two successive equilibrations with constraints on a reference structure, typically a crystal structure, were performed: 5 ns constraining protein heavy atoms and bromoform, then 20 ns constraining protein Cα atoms and bromoform. During these two equilibration steps, constraints were also applied on the dihedral angle between Y197 C-Cα-Cβ -Cγ atoms ensuring an angle of 173.5° in GLIC open form and 91.8° in the locally closed conformation. ese values correspond to the two principal modes of the angle distribution observed along short MD simulations. A thermodynamic cycle was then applied to calculate free energies of binding of bromoform to GLIC using a similar protocol as that described in (Brömstrup et al., 2013), however as a large number of such calculations was carried out, we optimized the protocol in terms of number of windows and sampling times. Coulombic and van der Waals interactions were decoupled using a decoupling parameter λ linearly increasing from 0 to 1. Coulombic interactions were decoupled along 11 independent steps while 21 steps were necessary to decouple van der Waals interactions. At each λ-point, the system was minimized for 5000 steps, equilibrated for 10 ps in the NVT ensemble, then equilibrated for 100 ps in the NPT ensemble. Bromoform positions were harmonically constrained during these two equilibration steps with a force constant of 1000 kJ/(mol nm2 ). Production simulations were run using the sd3 integrator with a time step of 2 fs. During the production phase, bromoform positions were restrained using an umbrella potential with a force constant of 100 kJ/(mol nm2 ). For coulombic interaction decoupling, 2 ns were carried out. For van der Waals interactions, 3 ns were carried out for the rst 14 λ-points (initial λ < 0.7) and 10 ns for the remaining 7 points (initial λ >= 0.7). e same protocol was applied for decoupling bromoform in water. e calculation of the binding free energy was carried out2.6. Setups and methods used in this work 47 GLIC Variant Pore state Binding site Locally-Closed Open WT B1 B2 P1 W1-2 W3 B1 B2 P1 W1-2 W3 Locally-Closed Open F238A B1 B2 P1 W1-2 W3 B2 P1 W1-2 W3 B1 Figure 2.14 – Extensive screening of bromform’s a›nity for GLIC. Bromoform’s free energy of binding was calculated for 5 binding sites in GLIC wild-type, mutant F238A, in both open and locally closed conformation. using the BAR method (Bennett, 1976) as implemented in the g_bar program from the GROMACS suite. 2.6.4 Confidence interval on means calculation Comparing two means extracted from MD simulations requires a robust methodology that is not well established in the eld. A classical method such as the Shapiro-Wilk test is oŸen not applicable in MD because this test, as well as most parametric tests, require the data to be normally distributed and have equal variances, which is oŸen not the case in MD. Non parametric tests, such as the Kolmogorov-Smirnov test, are therefore a better choice but, as well as the parametric tests by the way, are biased by the number of observations: they will return signicant p-values if the number of observations is important, even if the dišerence between the distributions is minimal. In MD, it is very common to calculate a mean on hundreds or thousands of steps of a simulation. Another approach has therefore to be used to calculate robust means with condence intervals. I chose to use the bootstrapping method. is method consists in calculating an estimator, typically the mean, of a distribution using a random resampling of the distribution with replacement. Numerous resamplings have to be done, to nally obtain as many estimators extracted from the slightly dišerent subsamples extracted from the original data set. is method has several advantages, especially to calculate means with condence intervals. First, it can be used on non normally distributed data since the ensemble of means that is calculated will most likely be normally distributed itself. Second, this method is sensitive to variance in the initial distribution which means that two sets of data centered on the same value but with dišerent variances will yield dišerent condence intervals. In my case, I chose to use 1000 resamplings. 2.6.5 Binding site occupancies Binding sites occupancies have been computed by calculating the distance between the anesthetic and a reference position taken from relevant crystal structures. e occupancy of site B2, which is not a crystallographic site, has been calculated with respect to a position extracted from a short MD reference simulation. A site is dened as occupied at a time t if the distance between the center of mass of the anesthetic molecule and the reference position are within a cutoš. e cutoš value I chose is 4 Å, which is quite restrictive considering the volume of the intrasubunit pocket. It is therefore important to note that the analysis may indicate that the anesthetic does not occupy any binding site strictly speaking while 3e sd integrator implemented in GROMACS is an accurate leap-frog stochastic integrator which also acts as a thermostat.48 Chapter 2. Molecular Modeling: eory And Practice being inside the pocket. Occupancy maps have been calculated with Visual Molecular Dynamics (VMD)’s volmap tool, using a classical van der Waals radius, combining all frames and averaging the data. 2.6.6 Pocket volume calculation Binding pocket volume calculations have been carried out using the Epock soŸware (see section 3.3). To calculate the volume of the intrasubunit pocket, only frames with anesthetic molecules closer than 4 Å from sites W1, W2 or W3 have been taken into account. e nal volume average value and corresponding condence interval have been calculated by bootstrapping (see section 2.6.4.) considering the last 3 nanoseconds of simulation. 2.6.7 Contacts Contacts between the anesthetic and the protein residues have been calculated with the VMD measure contacts procedure. A contact with a residue is counted if any atom from the anesthetic is closer than 4 Å of any atom of the residue. e number of contacts with a residue at a time t is summed over the ve subunits of the protein. e nal percentage of contacts between the anesthetic and a residue is dened as the sum of the number of contacts at each frame divided by the number of frames in the simulation. is percentage is therefore the probability that any of the ve anesthetic molecules present in a simulation contacts the correspondind residue on any of the ve GLIC chains.3 High-Performance Computing And Large Scale Data Analysis e founding principle of statistical physics concerns ergodicity stating that the time average of one sequence of events is the same as the ensemble average. Hence, as any statistical analysis, data obtained from MD simulations can only be trusted if numerous uncorrelated events have been observed. As discussed in section 2.5.5, there are basically two ways one can apply this principle to MD simulations: a) running an extended one-shot simulation; b) running many short simulations from several starting points. Depending on the study focus, the rst, second or both methodologies may apply. For example, a study that aims to describe the process of binding of a ligand to a protein would most probably require long simulations in which the ligand is not bound to the protein at the start as opposed to the description of the interactions between a protein and a bound ligand, which would require many short simulations to avoid the ligand unbinding. Nowadays, it is very common to run one to two long simulations since, as will be justied in this chapter, it oŸen implies less work. A major aspect of this work has been the description of the dynamics of GAs bound to GLIC. I chose the second approach, i.e. the calculation of several short simulations to achieve extensive sampling of the ligand dynamics while bound to the protein. In this part, my goal is to introduce the main technical di›culties I have been facing. e rst section will be devoted to the specic hurdles related to the approach I used, while the following is related to the system’s size. 3.1 Computing the simulations 3.1.1 The need for high-performance computers As GLIC is a membrane protein, a minimum system for studying this channel at an all-atom resolution is made of several molecule types, leading to a total number of approximately 200,000 atoms (see table 3.2). e simulation of such a number of particles remains challenging and requires computational power that is oŸen not accessible locally. Supercomputers are therefore required to produce data in a reasonable time. As an example, using 184 cores on jade@cines.fr1 allows to run an MD simulation at a speed of 10 ns/24h. While computing 10 ns of simulation takes one day on jade, it would virtually take 46 days to50 Chapter 3. High-Performance Computing And Large Scale Data Analysis get the same amount of data on a recent desktop computer. I focused on 12 subsystems including dišerent GLIC mutants in dišerent conformations with dišerent GAs bound to it. Since 25 simulations of 8 ns each have been run for each system, I calculated the equivalent of 9600 ns, which would have been done in a total of 960 days if they had been run one aŸer the other on a super computer, and more than 120 years on a recent desktop computer, pointing out the essential need for supercomputers in theoretical biophysics. e total amount of CPU-time2 spent on this aspect of the project is estimated to 4,377,528 jade equivalent CPU-hours3 . 3.1.2 Optimizing the available resources e number of CPU-hours available for a project is nite, obviously. To best spend the limited amount of available computing time, it is necessary to run several benchmarks to avoid loosing time by running a suboptimized simulation. e procedure to nd the set of parameters that gives the best computation speed is well dened and should be carried out every time one starts to work on new machines or a new system since this set of parameters depends both on the topology of the system and the architecture of the machines. e very rst step to optimize a simulation is to reduce to the minimum the number of particles that compose a system. e size of the simulation box (see section 2.2.3) has therefore to be well chosen not being too large, which will increase the number of lipids (in the case of a membrane protein) and solvent molecules, but also not being too small to avoid contacts between protein periodic images or articial structuring of the membrane. e second step is to run several very short simulations (on the order of 100 ps) varying the number of cores used that will allow to estimate the speed a simulation is computed at (i.e. number of nanoseconds calculated per day), and the computing time consumed. e optimal number of processors and cores (recent processors have up to 16 cores, and, sometimes, leaving one core available yields better results) can then be dened according to the project needs. A number of processors which is a power of two usually yields better performance. However, NAMD developers advise for a maximum speed to use a number of cores proportional to the system’s size. For instance, it can be deduced from gure 3.1 that the maximum speed (number of nanoseconds computed per day) is reached at 544 CPUs. It is then a waste of resources, again for this particular system on this particular machine, to run a simulation using 1024 CPUs, as no speed-up is achieved. e second element that will inžuence the choice of the number of cores to use is the number of nanoseconds that can be computed with a certain amount of CPU-hours, 300,000 for instance. is amount is inversely proportional to the number of cores used. It is clear on gure 3.1, that, at maximum speed (i.e. 512 CPUs), only 500 ns can be computed while more than 700 ns can be computed with 128 CPUs. On the other hand, the 500 ns would be obtained in X days only with 512 CPUs, whereas Y days are required with the more economical 128 CPUs for 700 ns. Last but not least, the program options should be in their turn optimized. In NAMD, for instance, 1 jade is a supercomputer located at Centre Informatique National de l’Enseignement Supérieur (CINES, Montpellier). 2 See denition on page 27. 3e simulations were dispatched on jade@cines.fr, turing@idris.fr, babel@idris.fr, ada@idris.fr, vargas@idris.fr and curie@tgcc.fr. is value is the number of CPU-hours that would have been consumed if all the simulations had been carried out on jade@cines.fr.3.1. Computing the simulations 51 Total number of cores Figure 3.1 – Benchmarking the speed of a simulation on a machine. e total number of cores is the product of the number of CPUs and the number of cores on each CPU. Benchmark realized with NAMD in 2011 on jade@cines.fr. dividing patches4 in halves oŸen leads to better results. e PME calculation (electrostatic interactions) can be optimized by dening the dimension of the grid for PME decomposition and dening the number of processors on which PME should be computed and reserve them for PME only. Several other options can be adjusted and will not be developed here. Table 3.1 compares some French supercomputer performances. Although it may seem illogical, the fastest machine is not necessarily the one to use for all purposes. For instance, curie@tgcc.fr’s cores are slightly less e›cient to run an MD than ada@idris.fr’s but, on the other hand, curie’s overall speed is higher than ada’s since it has more cores: 80,640 cores vs 10,624 on ada. is reduces the waiting time between jobs and may allow to run more jobs in parallel, depending on a given supercomputer’s policy. Furthermore, more cores could be used on curie than on ada speeding-up the simulation (but increasing the cost of a simulation in CPU-hours/ns). As as second example, turing@idris.fr is one order of magnitude slower than every other supercomputer listed in table 3.1. However, this machine turned out to be suitable to run short MD simulations (8 ns). e specic rules of the computer centers have to be taken into account. At IDRIS, the number of jobs a user can run at the same time is limited to 3, and the number of jobs the same user can have in queue is also restricted. is rule can strongly slow down a project’s proceedings when numerous jobs have to be run. To compute 20 dišerent free energies of binding of bromoform to GLIC (see section 2.6.3), I had to run a total of 640 jobs. For the reason stated above, most of these jobs (in the limit of the available CPU time) were run on curie to benet of the unrestricted number of jobs a single user can run at the same time on this machine. e remaining jobs were run with a special priority on the ada machine, thanks to the assistance of the IDRIS support team. 3.1.3 Data storage e storage of these data has to be considered as a major concern, since more than 6 TB have been produced carrying out this part of the project. Besides, safety demands storing at least two copies of the data in 4e patch is used by NAMD as the fundamental unit of spatial decomposition.52 Chapter 3. High-Performance Computing And Large Scale Data Analysis Machine Number of cores Speed (ns/day) ns/100,000 CPU hours days/µs turing@idris.fr 256 3.54 58 283 ada@idris.fr 256 57.66 938 17 curie@tgcc.fr 256 53.03 863 19 jade@cines.fr 256 43.61 710 23 hades@lbt.ibpc.fr 180 35.88 865 28 Table 3.1 – Comparing common supercomputers. Benchmark realized with GROMACS 4.6.3 on a system made of 146,182 particles. dišerent places, allowing to recover data if one copy is damaged or deleted. e original data have been stored on gaya@idris.fr, that ošers a capacity of 6.6 PB of taped storage. Copies had to be stored locally. However, the lab’s current storage setup imposes limits on the recurrent backup of such large quantities of data. e solution I found is to switch from the original NAMD dcd format to the GROMACS xtc format, which has been optimized for žoating point numbers compression. Hence, an xtc le is more than 3 times smaller than a dcd le and displays a negligible precision driŸ. It therefore turns out a very good choice for original data backup and everyday analyses. Finally, xtc les generated for this part of the project constitute a total of 1.9 TB of data. From a more general point of view, I think that GROMACS’s xtc format should always be used to store system trajectories for numerous reasons. e rst reason is the impressive gain of space detailed above. e second reason is that GROMACS can perform a variety of operations on xtc les such as ltering, tting, translating, etc. e third reason is that dealing with smaller les will signicantly impact the time a program will require to run an analysis, even its capacity to run an analysis. As an example, the VMD soŸware loads into memory the whole trajectory at start. Obviously, the larger the le, the longer the loading, which can become critical if the le size exceeds 1 GB. Finally, backup soŸware run time considerably depends on the number of les to save. Some MD soŸware, such as OPEP (Chebaro et al., 2012), store the system trajectory as Protein Data Bank (PDB) formatted les at a rate of one le per frame. One trajectory could therefore be stored as several thousands (millions) of les which will take a considerable amount of time to backup. is may even be more critical at supercomputer centers, as the number of available inodes on the le system may be limited. Dealing with such a volume of data divided into 400 independent simulations is not trivial. Improving the e›ciency and the scaling of the analysis processes turned out to be unavoidable. 3.2 Scaling and parallelization of the analysis processes Handling several similar simulations at the same time can reveal itself time consuming and many mistakes can slip into the process if some slight changes have to be made from one simulation to the other. Since most recent studies favor the calculation of one to a handful (< 5) of long simulations upon the calculation of many short ones, no soŸware has been developed to perform this kind of specic task. A good knowledge of Unix tools combined with programming skills allowed me to handle 4003.3. E›cient Analysis SoŸware Need: e Epock SoŸware 53 Molecule type Number of molecules Number of atoms Protein 1555 residues (5 chains of 311 residues) 25,385 Lipids 301 41,138 Water 43,882 131,646 Ions 143 143 Total – 198,312 Table 3.2 – Composition of a minimal GLIC system. minimal is to be understood as that contains the minimum number of species to calculate an all-atom simulation. We estimate that the total number of atoms can be further reduced by ≈ 25% by agressively optimizing the simulation box shape. independent simulations very e›ciently considering both time concerns and risk minimization. As an example, a script aiming to get each simulation ready to run on a supercomputer is shown in appendix C.1. e script creates one directory per simulation with all the materials required to run the MD simulation on a cluster. It implements the possibility of choosing on which cluster the simulations have to be ran and adapts the submission scripts in consequence. Such kind of scripts are not major progresses in the eld but have to be implemented when running tens (hundreds in my case) of similar simulations that may vary by a handful parameters. e same kind of approach had to be applied to the simulation analysis. I chose to write one specic Makefile for each analysis which allowed me to take advantage of the multi-threaded nature of the make program and to run up to 12 analyses at the same time, which became critical when analyses have to be run on hundreds of simulations. Furthermore, by writing scripts as žexible as possible, running a new analysis turned out a matter of minutes, even on hundreds of simulations. 3.3 Efficient Analysis Software Need: The Epock Software is part is adapted from Laurent et al. (submitted) and specically adresses the development of a pocket volume analysis tool in the context of handling more and more massive amounts of MD data. Owing to recent advances in hardware and soŸware, MD simulations enable the study of the evolution of biomolecular systems of increasing size and complexity over time. Repeatedly D.E. Shaw showed the possibility of breaking the millisecond barrier using the Anton supercomputer and the Desmond computer program (Lindorš-Larsen et al., 2011). e drawback of this progress is the generation of increasingly large MD datasets (see section 3.1), with consequences for subsequent analysis. It is therefore crucial to develop improved soŸware tools able to analyze these datasets in a reasonable time. e volume of an internal protein pocket is of fundamental importance to ligand accessibility and mobility inside the pocket. Along years, several programs and algorithms that aim to quantify the volume of a protein cavity have been developed and, among them, only few are designed to e›ciently manage dynamic data from MD. Limited performance oŸen prohibits their use on large datasets. To tackle this issue, I developed Epock, a program that allows e›cient measurement of the evolution of protein pocket volume during MD trajectories.54 Chapter 3. High-Performance Computing And Large Scale Data Analysis 3.3.1 Program features Epock is a command-line program that requires input in the form of a system topology and an MD trajectory in GROMACS xtc format (Pronk et al., 2013), which can be either atomistic or coarse-grained. An Epock conguration le species a set of parameters for each cavity to be characterized, including a maximum encompassing region for the cavity (MER). e MER provides explicitly dened bounds for each cavity by combining simple 3D objects (spheres, cylinders and cuboids) to create complex shapes (a concept known as “solid constructive geometry”). is allows to unequivocally follow a priori determined cavities over time, whereas Epock is not intended for cavity searches. My implementation extends the method proposed by Durrant and coworkers in the POVME program (Durrant et al., 2011). e Epock Tcl/Tk plugin for VMD (Humphrey et al., 1996) provides an intuitive way to choose and position shapes to dene the MER (see gure 3.3A-B) 5 . For each pocket, Epock calculates the space accessible to a probe, called “free space”, which is the set of all grid points with a distance to protein exceeding the user-dened probe radius (typically, 1.4 Å). e number of grid points that overlap each residue is stored and can be outputted as “residue contribution”. e volume of the so-called free space is then calculated at higher precision using a ner grid. Epock outputs pore proles by calculating the radius of the largest disc that can t the previously detected free space along the Z axis. e results are similar to those obtained with the Hole soŸware (Smart et al. 1993. see gure 3.2) 6 . Epock produces several output les, including the computed trajectory of free space over time, a feature inspired by the trj_cavity soŸware (Paramo et al., 2014). is trajectory is directly readable in VMD, which makes the relationship between pocket volume and protein conformation highly intuitive. Epock results for pocket volume, residue contribution and pore prole can be plotted directly in VMD using the plugin, or by running the Python scripts that are freely distributed with Epock. 3.3.2 Application: the GLIC ion channel e Gloeobacter violaceus Ion Channel (GLIC) previously introduced in this PhD manuscript features numerous pockets, including a binding site for general anesthetics (Nury et al., 2011). It is a challenging test case because of its size, 1555 residues, and the presence of multiple pockets that oŸen connect to each other and/or to the central pore. e volume of a single pocket was computed over an 800-frame trajectory of the protein (25385 atoms, 75 MB) on Mac OS 10.6.8 with 2 × 2.93 GHz Quad-Core Intel Xeon processors and 8 GB 1066 MHz DDR3 memory. Examples of Epock output are shown in gure 3.3. e chosen analysis example shows that the cavity volume dramatically decreases aŸerc.a. 1500 ps, (see red curve in gure 3.3C). Epock’s residue contribution analysis shows a particularly high variability for residue Y197 (see cyan curve in gure 3.3C, and gure 3.3D). Simultaneous visualization of the protein trajectory alongside the pocket free space in VMD (gure 3.3E-F) conrms that movement of the Y197 side chain is largely responsible for the volume decrease. 5e VMD plugin has been developed by Matthieu Chavent and Caroline Dahl from the Structural Bioinformatics and Computational Biochemistry Unit, Department of Biochemistry, University of Oxford, UK 6e pore prole feature has been developped by Tristan Cragnolini, Laboratoire de Biochimie éorique, CNRS UPR 9080, Univ. Paris Diderot, France3.3. E›cient Analysis SoŸware Need: e Epock SoŸware 55 60 50 40 30 20 1 0 2 4 6 8 10 12 14 Z pore radius (Å) A B Figure 3.2 – Calculation of a pore prole with Epock. A) GLIC transmembrane domain (protein backbone is represented as white cartoon, Epock’s pore surface as red wireframe). e pore prole has been calculated given a 14 Å-radius cylinder as include region and a superimposed 7 Å-radius cylinder as contiguous seed (see Epock’s manual for more information). e surface has been calculated from Epock’s output using the VMD Volmap tool. B) Comparison of the average prole of the GLIC pore of a 800-frame trajectory. Epock (red) and Hole (blue) results are very similar.56 Chapter 3. High-Performance Computing And Large Scale Data Analysis A B C E D F Volume (Å 3) 0 1000 2000 3000 4000 5000 6000 7000 8000 200 300 400 500 600 700 0 200 400 600 800 1000 1200 1400 1600 Time (ps) Y197 contribution Contribution Standard deviation TYR197 ILE201 TYR119 MET205 TYR254 THR255 VAL242 ILE202 ILE258 PHE121 PRO120 LEU206 ILE259 PHE238 ASN239 LEU241 LEU246 ILE262 ILE198 THR253 ASN245 HSP235 GLU243 GLY256 TYR194 ASN307 ALA257 ASN200 GLU243 PHE303 MET261 0 50 100 150 200 250 300 350 1500 ps 3500 ps Figure 3.3 – From Epock setup to result analysis. A) Graphical interface for dening the MER using the VMD Epock plugin. e MER consists of a combination of volumes to include (spheres in red) and exclude (spheres in purple), giving rise to a custom complex geometric shape for analysis. B) Grid points that compose the MER. C) Pocket volume (red) and residue contribution of Y197 (cyan) during an MD simulation. D) Standard deviation of residue contribution ordered from highest to lowest. E-F) Protein conformation and pocket (protein surface in grey mesh, backbone as white tube, Y197 as spheres colored by atom type, pocket accessible space as red spheres) at t = 1500 ps (E) and t = 3500 ps (F). We compared Epock execution speed to two existing programs: i) mdpocket (Schmidtke et al., 2011) that uses Voronoi diagrams and has been specically designed to calculate pocket volume for MD simulations and ii) POVME (Durrant et al., 2011) which implements an algorithm similar to Epock for free space detection but with dišerences in the free space volume calculation. e same input grid can be given for all three programs, allowing for meaningful performance comparisons. Epock ran in 5 seconds. is is a dramatically higher speed than both mdpocket and POVME, which feature computing times on the hour timescale (5 and 3 hours, respectively). We hypothesize that POVME’s execution time is largely related to its implementation in Python which is known for being slower than the corresponding C++ executable. e reason why Epock is faster than mdpocket may be due to the numerous additional analyses that mdpocket performs during a run, and that can not be disabled. 3.3.3 Making Epock public e source code distribution A distributed soŸware requires protection against abusive use such as copy and distribution for commercial use. I strongly believe in open-source projects, especially for science, as well as Epock co-developers. We decided to make Epock’s source code accessible to anyone so that developers could enhance the program over years or build a new program inspired by it. As it is crucial for us to assure the accessibility of the source code of any program inspired by Epock, Epock source code is distributed under the CeCILL license, a modied version (and still compatible with it) of the GNU General Public License (GPL). To encourage developers to contribute to Epock, its source code is versioned with mercurial, a distributed source control management system. is technology allows a developer to access all past code3.4. BioSpring: an Augmented Spring Network Simulation Engine 57 modications and keep track of new code modications while developing a new feature. If a developer wants to contribute to Epock, his changes can be pulled into Epock’s mother repository so that the whole history of the new feature development is then accessible from it. Epock’ source code is hosted by bitbucket.org and is available at http://bitbucket.org/epock/epock. e soŸware distribution Nowadays, besides the publication of an article or application note in a scientic journal, it is crucial for a soŸware to be visible on the Internet, so that, in the case of Epock for example, anyone looking for a program for pocket volume measurement in molecular dynamics can reach Epock. Part of the time I spent on the Epock project was therefore naturally devoted to the creation of a website explaining the method underlying Epock, its usage and a series of application examples. As writing HTML code can be time consuming, I have been looking for a solution allowing me to write text les with a simplied markup language and translate them to HTML. e best solution I found is the Sphinx tool that was originally created for the new Python documentation, and, from a general point of view, is particularly adapted to the code documentation. In the case of Epock, I did not want to document the code itself but only to build a showcase allowing to download the package, access the online manual and read more about Epock. Sphinx inputs are, besides a conguration script, text les in reST format, a markup language that allows high e›ciency during the writing process since reST les are much simpler to write than HTML code. It can be guessed from gure 3.4 (that shows the reST input le and the corresponding webpage) that reST is a very powerful language that can produce very rich content: this thesis manuscript could perfectly have been written in reST and rendered into a PDF document thanks to Sphinx! A few more hours were also required to customize the page layout and, more importantly, write the CSS les for a stylized and original website. Epock’s website is hosted by bitbucket.org and is available at http://epock.bitbucket.org. e methodological aspect of this project has now been covered. In the next two chapters, I will focus on the results I obtained on the study of general anesthetic action at the atomic scale. e accurate characterization of binding pocket volumes did play an important role in these investigations. 3.4 BioSpring: an Augmented Spring Network Simulation Engine As has already been discussed, MD simulations of GLIC require consequent computational power and a simulation may run for weeks, if not months. Here I will describe BioSpring, a computational tool for much faster - but also more approximate - simulations of macromolecular systems. BioSpring is not an alternative to MD simulations, but a useful complementary tool to characterize a molecular system.58 Chapter 3. High-Performance Computing And Large Scale Data Analysis Figure 3.4 – Writing Epock’s website. e reST source code (leŸ) that, aŸer processing by Sphinx, will produce the HTML that can be rendered in any web browser (right). 3.4.1 Principle BioSpring is a calculation engine allowing to run molecular simulations of spring network models. Spring networks are a simplied representation in which the system structure is maintained by interactions mimicking springs: harmonic potentials are created between neighbor particles so that the more the distance di j between two particles i and j is distant from their equilibrium distance d 0 i j, the greater is the associated energy. e equilibrium distance d 0 i j is dened as the distance between particles i and j at t0. By denition, this force tends to drive the system back to its equilibrium state: the initial conguration of the system. Biospring has two major originalities. First, it takes into account non-bonded interactions between particles which can allow the system to reach metastable states dišerent from its initial conguration. Second, Biospring implements an interface to Interactive Molecular Dynamics (IMD), a technique in which a user can input forces to the system manually as the simulation is going on thanks to a dedicated input device. is input device can be a simple mouse or a haptic device that allows to send back forces to the user. IMD therefore allows to very intuitively dock a ligand on a receptor or fold a protein. Another application has been demonstrated recently by Molza et al. (2014) in a study where the authors use a map extracted from Small-Angle X-ray Scattering (SAXS) experiments to run a targeted folding thanks to BioSpring. 3.4.2 My contribution BioSpring development was initiated by Nicolas Férey in 2008. He implemented BioSpring’s core plus several associated tools. My initial thesis project included several BioSpring-IMD experiments on GLIC including docking of anesthetics and studies of the channel gating. e current BioSpring force-elds turned out unsuitable to reproduce hydrophobic interactions with su›cient accuracy, so anesthetic docking tries were unfruitful3.4. BioSpring: an Augmented Spring Network Simulation Engine 59 as were tests on GLIC’s gating. In the latter case because the spring network revealed itself too rigid to properly reproduce the motions of the M2 helices. To make these tests, I nevertheless regularly improved BioSpring in dišerent ways I will develop in this part. Input/Output BioSpring input les are • the simulation conguration le (containing time step, number of steps...), • the system topology. e system topology le contains the parameters for all the particles of a system including coordinates, radius, charge,etc. Reading and writing tabulated les can raise problems, especially forformat specication. BioSpring lead developers chose to use the NetCDF format for topology les in which data are stored as arrays (gure 3.5). I improved NetCDF reader and writer classes already existing in BioSpring by performing numerous sanity checks to make sure the le format behaves as expected, a crucial step to avoid unauthorized memory access, which can turn out very di›cult to debug. I also implemented methods to automatically write NetCDF binary les and implemented BioSpring support for the newest versions of the NetCDF library. Associated tools Initially, BioSpring conversion tools from PDB format to NetCDF format ošered limited žexibility. In the context of scientic experiments using BioSpring, it is very common that the spring stišness between two particles or two groups of particles has to be adjusted, some springs have to be removed, others have to be added, etc. Despite the di›culty of the task, these operations had to be done manually, which was time consuming and a potential source of errors. As an example, to add a single spring between two particles, the user had to 1. nd the id number of the two particles (this part was usually done using VMD, making sure the serial parameter of VMD corresponds to the actual particle id in BioSpring), 2. add 1 to the dimension spring_number, 3. add the two particle ids to the springs array 4. add the appropriate stišness for this spring to the springsstiffness array, 5. add the appropriate spring equilibrium distance to the springsequilibrium array (note that the spring stišness and equilibrium parameters have to be inserted at the exact same position as the spring is inserted in the springs array). I developed three tools named pdb2spn, editspn and mergespn to deal with most use cases and signicantly reduce both the time spent on the topology tuning and the probability of making mistakes during the process.60 Chapter 3. High-Performance Computing And Large Scale Data Analysis netcdf model { dimensions: spatialdim = 3 ; particle_number = 2 ; particlename_length = 4 ; chainname_length = 4 ; resname_length = 4 ; springdim = 2 ; spring_number = 1 ; variables: float coordinates(particle_number, spatialdim) ; coordinates:units = "angstrom" ; coordinates:long_name = "Particle coordinates" ; float charges(particle_number) ; charges:long_name = "Particle charge id" ; charges:units = "electron" ; float radii(particle_number) ; radii:units = "A" ; radii:long_name = "Particle radius" ; float epsilon(particle_number) ; epsilon:units = "kJ.mol 1" ; epsilon:long_name = "Particle epsilon for Lennard Jones" ; float mass(particle_number) ; mass:units = "Da" ; mass:long_name = "Particle mass" ; ... int springs(spring_number, springdim) ; springs:long_name = "Spring between particle referenced by 2 particle id s" ; float springsstiffness(spring_number) ; springsstiffness:long_name = "Spring stiffness" ; float springsequilibrium(spring_number) ; springsequilibrium:long_name = "Spring distance equilibrium" ; data: coordinates = 0, 0, 0, 2, 0, 0 ; particleids = 0, 1 ; particlenames = "N", "N" ; charges = 0.4157, 0.4157 ; radii = 1.824, 1.824 ; epsilon = 0.17, 0.17 ; mass = 14.01, 14.01 ; surfaceaccessibility = 0, 0 ; hydrophobicityscale = 0.112, 0.112 ; resnames = "VAL", "VAL" ; resids = 1, 2 ; chainnames = "A", "A" ; dynamicstate = 0, 1 ; springs = 0, 1 ; springsstiffness = 1 ; springsequilibrium = 2 ; } Figure 3.5 – e NetCDF array-oriented format. Example of a NetCDF text le for a system containing two particles. BioSpring input is the binary version of this le that can be created thanks to the ncgen program distributed along with the NetCDF library.3.4. BioSpring: an Augmented Spring Network Simulation Engine 61 pdb2spn is a utility that converts a PDB formatted le to a binary NetCDF formatted le. Prior to the development of this tool, text les were generated. ey had to be converted to a binary in a second time, thanks to a tool distributed with the NetCDF library. e creation of a binary le is the only new feature of pdb2spn but it is incorporated within a framework in which BioSpring topology les should not be edited by hand. editspn allows to edit BioSpring binary topology les. It implements features such as spring creation from a cutoš, add or remove springs thanks to a selection language, modify particle positions... mergespn aims to merge two BioSpring binary topology les. is is particularly useful for creating a system in which several parts have dišerent žexibility levels. Two spring network models can be created for two distinct molecules of a system, with dišerent spring cutošs and/or spring stišness thanks to two calls to pdb2spn. ey are gathered together in a second time thanks to mergespn which can additionally create springs between the two structures. e compilation process BioSpring soŸware is made of 98 source les representing a total exceeding 20,000 lines of C++ code. It has several dependencies such as the NetCDF library and a few more libraries. e build process can therefore not be managed by hand. For decades, developers used the GNU build system known as Autotools, a suite of programs designed to generate a configure script for the project. is script, to be executed by the user prior to compilation, generates the Makefile that will produce the soŸware targets (programs, libraries, etc.) by invoking the command make (gure 3.6). is system has proven both its robustness and di›culty of use since Autotools input les have a very particular syntax that makes writing them tough and improvement even tougher since the whole le has to be read again and understood before being modied. e CMake soŸware was developed in this context in the early 2000s, with a main objective to simplify the writing of conguration les. e developer has to write basically a single input le and CMake generates the appropriate Makefile. Notably, CMake conguration variables are very easy to modify, so the build settings can be tuned very quickly. CMake is now used by thousands of developers to compile hundreds of projects including very large projects such as KDE, a Unix desktop environment, MySQL, a database management system and BioSpring! BioSpring lead developers chose CMake as build process management system, facing the fact that the less time is spent on the compilation, the more is spent on the actual code development. My contribution to the build process has been to improve the CMake input le by adding several options to customize the build process and make the input le clearer from a general point a view. A very interesting CMake feature is the package search: CMake can search for libraries, programs or any kind of dependency a project has. I wrote several CMake search scripts that were not already included in the CMake package, such as for the NetCDF and the MDDriver libraries for example.62 Chapter 3. High-Performance Computing And Large Scale Data Analysis configure.ac aclocal autoconf autoheader automake autoscan aclocal.m4 Makefile.am configure config.h.in Makefile.in config.status config.h make Makefile input file executable process influences output file creates Figure 3.6 – GNU autoconf and automake process for generating makeles. From http://www.wikipedia.org4 Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites is chapter is devoted to the characterization of general anesthetic bromoform binding sites described in Sauguet et al. (2013a). I characterize the three sites and an additional pore site described in a new crystal structure of GLIC in locally closed conformation. I combine several computational approaches to address three key questions: (i) are the crystal binding sites spontaneously accessible? (ii) can bromoform travel from one site to another? (iii) what is the bromoform a›nity for each binding site? Molecular dynamics simulations of žooding the receptor with bromoform recover most of the experimentally observed sites, with a modulated occupancy between the open and the locally closed conformations. Sixty short MD simulations were carried out to extensively explore the binding pockets, providing data on possible routes connecting them. ese simulations furthermore highlight residues such as Y197 that may play key roles in controlling the interaction between anesthetic and receptor molecules. FEB calculations indicate signicant a›nity for all crystallographic binding sites in open and locally-closed conformations, in some cases modulated by pH. ey support the critical role of Y197 into anesthetic binding. e chapter is largely inspired by a scientic article currently in preparation. I am the rst author of this article. Furthermore this work features contributions from Ludovic Sauguet and Marc Delarue (Institut Pasteur) who covered the X-ray crystallography part of this project, my colleague Samuel Murail who carried out the setup of microsecond timescale MD simulations as well as the main part of their analysis, and Marc Baaden who supervised the project. I was in charge of writing the article, managing the dišerent contributions, running and analyzing all short MD simulations, running and analyzing all FEB calculations as well as partly analyzing long MD simulations. 4.1 Results 4.1.1 Bromoform-bound crystal structure of the GLIC channel in its locally-closed conformation In order to study the properties of bromoform-binding to the GLIC receptor in its locally-closed conformation, we grew crystals of the GLIC K33C L246C variant in the presence of bromoform. GLIC K33C L246C variant is a particularly adapted model for this study as it is known to crystallize in a locally-closed64 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites E-2' T2' S6' I9' A13' I16' intra-subunit sites pore site Y197 N245 T244 T244 N245 Y197 Figure 4.1 – A bromoform-bound structure of GLIC in its locally closed conformation. A) Top view of GLIC TMD. Bromoform densities, shown in ochre wireframe, are present in the intrasubunit site of four over ve subunit, and in the new pore site. B) Location of bromoform (sticks) in the pore site. Two M2 helix backbones of the LC and open conformations are represented in pink and white, respectively. Water molecules detected in GLIC high resolution structure are represented as red spheres. C-D) Side and top view of one intrasubunit site in open (pink) and locally closed (white) conformations. Residues possibly responsible for decrease of site W3 accessibility are showed as sticks. conformation but shares indistinguishable electrophysiological properties with WT GLIC (Prevost et al., 2012). Bromoform is an analogue of chloroform containing three bromine atoms that produce a specic anomalous signal that can be observed by crystallography using X-rays with tunable wavelengths. e bromoform-bound structure was determined at a 2.95 Å resolution (gure 4.1). It was completely superimposable with the apo-form of GLIC K33C L246C with a root mean square deviation of 0.77 Å over the 1555 Cα atoms. In the pore, a bromoform-binding site is indicated by a Fo-Fc electron density peak (7.0 σ) that overlaps with a bromine-specic anomalous peak (10.0 σ). Bromoform binds in the middle part of the pore between the I240 (I9’) and S236 (S6’) rings of residues (gure 4.1B), two critical rings of residues that are repectively involved in gating and ion permeation (Sauguet et al., 2013b). is bromoform-binding site in GLIC is novel and is specically occupied when the channel pore is closed. In contrast, when the channel pore is open, this location is lled of ordered water molecules that were found to be critical for ion permeation. Interestingly, bromoform was found to occupy a similar location in ELIC ’s closed pore (Spurny et al., 2013). A previous study revealed that bromoform occupies alternatively three poses in the intrasubunit cavity of the GLIC open-channel structure (named W1 to W3). In contrast, this intrasubunit cavity is remodelled in the GLIC locally-closed structure thus ašecting the previously described bromoform binding sites (gure 4.1C-D). Indeed, despite the presence of an intrasubunit bromine anomalous signal in four out of ve subunits, the absence of interpretable Fo-Fc dišerence electron density supports the possibility that bromoform may also bind at positions W1 and W2, but with too low occupancy or too high mobility to allow for condent model building. is is caused by the side chain of residue Y197 that alternates between two conformations. e second one induces a steric clash that prevents binding of bromoform at W1 and W2 sites (gure 4.2). In addition, the revolving motion of the M2-M3 loop partly occludes the intrasubunit cavity and prevents bromoform-binding at position W3. In summary, bromoform binding-sites are dišerent in the locally-closed versus the open GLIC structures: while a novel site is observed in the pore, binding to the intrasubunit cavity is discouraged in the locally-closed form.4.1. Results 65 A B C Figure 4.2 – Two distinct conformations of residue Y197. A) In open conformation (top), Y197 side chain (space lling representation colored by atom type) does not overlap any of the 3 intrasubunit bromoform binding sites (pink, purple and magenta spheres), while in down conformation (bottom) it partially overlaps site W2 and W3. B-C) Inžuence of Y197 side chain orientation on the intrasubunit pocket accessible volume (represented with red spheres and calculated with the Epock soŸware, see section 3.3). e protein surface is represented as a white wireframe, its backbone as a grey tube. 4.1.2 Molecular Dynamics simulations to explore and quantify anesthetics binding I combine three complementary simulation strategies to explore bromoform binding to GLIC. Firstly, I used data from several one microsecond long MD simulations of membrane inserted GLIC in an oversaturated bromoform solution to assess the spontaneous exploration of the system by the anesthetic and identify preferential bromoform binding sites. We subsequently refer to this type of simulations as žooding experiments. ree forms of GLIC were used, WT GLIC in open and LC conformation and the GLIC mutant F238A in the open conformation. Secondly, we ran 25 unconstrained 8-ns long MD simulations of GLIC F238A in open conformation starting from anesthetic locations in sites W1-2 and site B1. Considering that, at this timescale, the ve subunits are independent, we accumulated a total of 25 × 5 × 8 ns sampling per system. is one microsecond dataset for each location yielded an extensive exploration of both the intra- and the intersubunit binding pockets and allowed us to observe transitions between sites. Ten 8-ns simulations were run for GLIC WT in the LC form starting with bromoform in the pore site P1. irdly, we determined the bromoform a›nity for each of the 6 binding sites in WT and F238A mutant for both open and LC variants of GLIC using alchemical free energy calculations. Sampling times are given in table 4.1, full technical details of all the simulation approaches are provided in section 2.6. 4.1.3 Crystallographic sites are spontaneously reachable Flooding experiments reveal that all binding sites (i.e. W1, W2 W3, B1, B2, and P1), are spontaneously reachable in at least one of the three simulations. By design, the ion channel in the short MD simulations remains very close to the crystal structure, which makes for straightforward comparison with experiment. e observed occupancies for sites W1 and W2 are equivalent as was observed in the crystal (respectively 0.41 and 0.38, table 4.2). In contrast, the equilibrium is shiŸed in favor of the membrane exposed W1 site in žooding simulations. In both short and long MD simulations, the occupancy of the W1-2 sites is66 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites Sequence Form Bromoform pore Sampling time Long MD simulations F238A Open Flooding 1 µs WT LC Flooding 1 µs WT Open Flooding 1 µs Short MD simulations F238A Open Site W1-2 25 × 8 = 200 ns F238A Open Site B1 25 × 8 = 200 ns WT LC Site P1 10 × 8 = 80 ns FEB calculations F238A Open W1-2, W3, B1, B2, P1 32 windows sampled for 3 to 10 ns each F238A LC WT Open WT LC Table 4.1 – Sampling time and studied systems for bromoform characterization. markedly higher than that of site W3, which is consistent with crystallographic data. During žooding simulation of WT GLIC in LC conformation, site W3 occupancy was lower by one order-of-magnitude compared to the simulation starting from the open form and displayed a particularly low residence time (3.4 ns in average), consistently with crystallographic data. As the intersubunit cavity B1 does not exist in WT GLIC because of the presence of the bulky F238 residue sidechain, this site has only been reached in the simulation of the F238A mutant. Spontaneously, the pore site P1 has been reached in the žooding simulation of WT open GLIC only. Site W1 Site W2 Site W3 Site B1 Site B2 Site P1 F238A – O Site W1 0.41 0.38 0.03 0.01 0.00 0.01 F238A – O Site B1 0.00 0.00 0.00 0.94 0.00 0.00 WT – LC Site P1 0.00 0.00 0.00 0.00 0.00 1.00 WT – O Flooding 0.56 0.43 0.35 0.00 0.12 0.49 WT – LC Flooding 0.45 0.24 0.03 0.00 0.00 0.00 F238A – O Flooding 0.46 0.23 0.25 0.02 0.19 0.00 Table 4.2 – Bromoform binding site occupancy along MD simulations. e 3 rst rows correspond to short MD simulations with bromoform being placed in site W1, B1 or P1, respectively. e 3 last rows refer to žooding simulations4.1. Results 67 M1 M3 M4 Loop β6-β7 M2 Loop M2-M3 Figure 4.3 – Key residues of the intrasubunit pocket. Percentage frames in which a bromoform molecule contacts a residue of the intrasubunit pocket along short MD simulations. 4.1.4 All sites are interconnected, with gates between them Considering the close vicinity of the experimentally observed sites W1,2,3 and B1, we characterized the dynamics of bromoform bound to each site. e simulations furthermore generate data to examine possible paths between these sites. Site W1-2 may act as an entrance to other sites In the žooding simulations, site W1 was the most occupied site mainly because it is exposed to the membrane. During the second half of the production run around 95 % of bromoform molecules were located in the membrane, as a consequence the W1 sites were the easiest to access and the rst to be bound. In short simulations bromoform did not oŸen penetrate much deeper into the intrasubunit pocket as depicted by both the low site W3 occupancy and the relatively low number of contacts with M2 residues (gure 4.3). Concerning site W3, its occupation in the žooding runs was signicantly higher compared to the short simulations but only in the open form of GLIC. In the simulation of LC GLIC, the occupation of sites W1 and W2 were close to GLIC in open form, however site W3 was weakly occupied. In the LC form, the conformation of the M2-M3 loop and of the top part of the M2 helix prevent occupation of site W3, in particular residue T245 is in close contact with this site, preventing any binding (gure 4.4). A key observation is that, once site W3 has been reached, bromoform was able to enter the upper intersubunit B2 pocket, as previously mentioned. e same behavior was observed in žooding simulations of open GLIC (WT and F238A), which is režected by the high occupancy of site B2. Y197: a gate to the inner channel Interestingly, Y197 which is not in the immediate environment of bromoform in the crystal structure, appears to dramatically modulate the volume of the intrasubunit pocket (gure 4.2), as proposed by Mowrey et al. (2013b). erefore Y197 might control access to sites W3 and B2. In the crystal structure, the Y197 side chain is oriented toward the extracellular domain, the dihedral angle θ between Y197 CCα-Cβ -Cγ atoms being equal to (167.6 ± 0.5)°. Notably, in available crystal structures of open GLIC, all68 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites WT LC WT OPEN F14'A OPEN Figure 4.4 – Bromoform exploration in žooding simulations. Top (top pannel) and side (bottom pannel) views of a GLIC subunit in which bromoform occupancies are represented as yellow surfaces. Residues Y197 and T244 are represented with sticks colored by atom type. Y197 residues display this up conformation (θ = 165.6 ± 3.8°), while closed structures of subtypes I and III respectively display four and two Y197 in down conformation, in which the Y197 side chain lies inside the intrasubunit pocket (θ =60.4 ± 8.5°). During the MD simulations, θ oscillated around these values with average orientations at 169.9° and 72.9° (gure 4.5). Notably, in down conformation, the Y197 side chain plunges into the intrasubunit pocket and occupies a large volume there, overlapping sites W2 and 3, hindering bromoform entering the deeper intrasubunit pocket (gure 4.2), and therefore ultimately prevents it from entering the intersubunit pocket. It is to be noted that the transition of the Y197 rotamer is a rare event with an average of 10 ± 6 transitions per microsecond calculated on the žooding simulations dataset. Bromoform is conned within the intersubunit site In the intersubunit cavity, bromoform mostly stays within 6.5 Å of the crystal structure location. roughout the one-microsecond dataset provided by short MDs, a single transition from site B1 to site B2 was observed. Two residues, L241i and E243i-1, restrain the available space in this region and therefore hinder crossing from site B1 to B2 (either way). During the F238A žooding simulation, the same inverse transition (B2 to B1) was observed once (gure 4.6). In that case, the molecule has been traveling from the membrane to the W1-2 site to W3, to B2, to nally reach site B1. Another intersubunit site was occupied by one molecule for more than 800 ns. is site is located 5 Å above B1 and slightly closer to the membrane. e bromoform molecule reaches that site from site W2 and stays there for the rest of the simulation.4.1. Results 69 Figure 4.5 – Y197 side chain orientation along žooding simulations. Distribution of the Y197 side chain orientation along žooding MD simulations for each system namely wild-type (WT) open (O) and locally closed (LC) and the F14’A mutant in open conformation (F14A-O). Densities have been calculated over the a microsecond period with a time step of 0.5 ns, leading to a total of 10,000 points per density (2000 points per Y197 × 5 subunits). 800-810 ns 811-836 ns 836-840 ns 840-860 ns 861-1000 ns W1-W2 W3 B2 B1 B1 B2 W3 W1-W2 membrane membrane Figure 4.6 – Transition of a bromoform molecule from the membrane to the B1 site. Top (leŸ) and side (right) views of a GLIC subunit. Bromoform center of mass is represented as spheres colored according to the time of the simulation. In 200 ns, this bromoform molecule could pass from the membrane to site W1-2, W3, B2 and ultimately B1.70 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites Bromoform is stable in site P1 Short simulations of the locally closed form of GLIC with bromoform bound to the pore site P1 show that the anesthetic molecule remains close to this site, never leaving the region delimited by residues T226 (T2’) and I233 (I9’), even in the absence of additional stabilizing bromoform molecules that were present in the žooding simulations but not in the short runs. Flooding simulations of WT open GLIC showed anesthetic molecules switching from the ECD vestibule to the pore site P1. As a result, the occupancy of site P1 in that simulation reaches 0.49 (table 4.2), with a total of three bromoform molecules present in the pore. One bound at the beginning of the simulation and stayed continuously in site P1 for more than 400 ns before binding an upper pore site (between I9’ and A13’) and coming back to site P1 twice for a few nanoseconds. e two other molecules were observed binding the upper site in the pore, the rst one came early (aŸer ∼ 100 ns) from the vestibule and stayed in the upper cavity for the rest of the simulation with the exception of one 3 ns binding event in site P1 halfway through the simulation (∼ 500 ns). e other molecule came from the intra subunit cavity (W1-2 for 205 ns then site W3 for 365 ns) at the very end of the simulation (∼ 950 ns). In the LC form simulation, no anesthetics were shown to bind to the pore site. During the F238A mutant simulation, no anesthetics were shown to bind in site P1, however one molecule was binding the upper pore site in the second half of the simulation (∼ 550 ns). e molecule came from the intra subunit cavity (W1-2 for 67 ns) and later an intermediate position between B2 and W3 for 63 ns. To be noted, none of the bromoform molecules, which bound in the pore, leŸ the pore. Bromoform binding a›nities are favorable for all binding sites Bromoform a›nity for crystallographic binding sites ranges from −7.1 to −4.8 kcal/mol (gure 4.7). e open form appears signicantly more favorable for sites W3, B1 and B2 with ∣∆∆G∣ ranging from 1.3 to 2.8 kcal/mol, while P1 displays a higher a›nity in the LC form than in the open form with ∣∆∆G∣ of 1.7 and 2.4 kcal/mol respectively for the WT and the F238A channel. It should be noted that the pore site P1 of both WT and F238A channels displays a favorable FEB, comparable to site W1-2 in open form and even more favorable than W1-2 in the channel LC form. Bromoform free energy of binding is sensitive to H235 protonation state. e H235 residue is located on the pore-lining M2 helix (H11’ in prime notation), close to the B1 site entrance. e protonation state of its side chain has been shown to be particularly di›cult to determine with condence (Laurent et al., 2013). To assess whether the protonation state of H235 modulates the ligand binding a›nity, we compared bromoform free energy of binding for neutral and protonated H235 (table 4.3). When neutral, we observe a dišerence of −1.9 kcal/mol between the WT intrasubunit site W1 (−6.3 ± 0.1 kcal/mol) and the F238A intersubunit site B1 (−8.2 ± 0.1 kcal/mol). When H235 is protonated, the FEB to B1 reduces to (−6.1 ± 0.1) kcal/mol. No ešect was observed on the more remote site W1.4.1. Results 71 F238A-LC -8.0 -6.0 -4.0 -2.0 0 W1-2 W3 B1 B2 P1 WT-O WT-LC F238A-O Figure 4.7 – Free energies of binding of bromoform to the ve binding sites. Energies are given in kcal/mol. WT = “Wild-Type”; O = “Open”; LC = “Locally-Closed”. Error estimates are all below or equal to 0.2 kcal/mol. H235 + H235 n Site W1 (intra) −6.6 −6.3 Site B1 (inter) −6.1 −8.2 ∆ = W1 − B1 −0.5 +1.9 Table 4.3 – Free energy of binding of bromoform as a function of H235 protonation state Energies are given in kcal/mol; “+” stands for double charged, “n” stands for neutral.72 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites 4.2 Discussion Globally, a picture of dynamically accessible and interconnected anesthetic binding sites emerges from this computational study, in excellent agreement with the available crystallographic data. e calculations reveal phenomena enriching the picture obtained from the experimental data such as the transitions between sites or the possible modulation of anesthetic binding a›nities by pH. 4.2.1 Multi-site allosteric modulation, a delicate balance toward potentiation or inhibition Evidence that anesthetics bind the intrasubunit site in the W1 region is strong. Crystal structures showed that bromoform (Sauguet et al., 2013a), propofol and desžurane bind to this pocket (Nury et al., 2011; Chiara et al., 2014). e data collected in this work are in very good agreement, clearly showing that intrasubunit sites are spontaneously accessible from the membrane and display favorable FEB, especially for W1. Our data suggest that sites W1 and W2 should be considered as two marginally dišerent poses of the same site. e ligand may switch from one to another with equal probabilities as is the case in short MD simulations. On a longer timescale, this equilibrium shiŸs in favor of site W1, probably because of a bias induced by its direct exposure to the membrane where most bromoform molecules accumulate. In WT GLIC, site B1 does not exist since the presence of the bulky F238 side chain does not leave enough room for an anesthetic molecule, as it leaves barely enough space for a single water molecule. Interestingly the F238 residue is conserved in the human nicotinic acetylcholine receptor subunits α3,4,5 and β1,2 and 5-HTR subunits 3A,B. In the glycine and the GABAA receptors this residue is substituted by less bulky residues, respectively Q and L/I. Howard and coworkers showed that this substitution creates an intersubunit pocket (corresponding to the B1 binding site) in which ethanol can bind, explaining the potentiating ešect on the channel. We observe in this study that the articial intersubunit pocket created in GLIC by the mutation F238A can be reached from intrasubunit site W1. Calculated free energies of binding režect the high a›nity of bromoform for B1 in both open and locally closed forms of GLIC F238A. is observation suggests that the anesthetics’ initial binding site could be site W1 for both inhibitory and excitatory channels. e anesthetic would then migrate to B1 in inhibitory channels, in this way stabilizing the open form, while remaining in the intrasubunit pocket in excitatory channels stabilizing the closed form. Such a scenario would support hypotheses proposing that the dišerence of action of anesthetics (and alcohols) on inhibitory and activating Cys-loop receptors might be found in the accessibility of the lower intersubunit pocket (Murail et al., 2012). Besides transitions from site W1-2 to B1, our data show a high mobility of bromoform inside the binding regions (see gure 4.8). Notably, we observe an important exchange rate between site W1-2 and site W3 over the microsecond period. e average occupancy of site W3 appears signicantly lower than for site W1-2 in both short and long MD simulations, which is in very good agreement with crystallographic data. Importantly, we observe several transitions from site W3 to site B2, an intersubunit site described in GLIC on the basis of MD simulations (Nury et al., 2011) and in GABAA by photolabeling (Yip et al., 2013) with respectively desžurane and ortho-propofol diazirine. As we observe bromoform occupying this site on the microsecond timescale, we argue that site B2 is denitely occupied by antagonists at a timescale4.2. Discussion 73   Figure 4.8 – Bromoform exploration of the intra- and intersubunit binding pockets in short MD simulations. Side view from the pore. e protein TMD backbone atoms are represented as cartoon colored by subunits. e area explored by the bromoform along short MD simulations are represented with meshes colored according to the bromoform starting location (purple and orange for intra- and intersubunit pockets, respectively). Two residues that seem to occlude the route between B1 and B2 intersubunit sites are represented with space lling spheres colored by atom type. relevant for anesthesia. Still, the anesthetic has to be able to access site B2 through a route passing by sites W1-2 and W3, a route that can be occluded by Y197. 4.2.2 A residue gating the access to anesthetic allosteric binding sites Our data strongly suggest that the orientation of the Y197 side chain is critical for anesthetic binding and insertion depth; therefore their transition to intersubunit cavities may be controlled in this way. e up conformation of Y197 as described above appears highly conserved in all GLIC open structures, while the down conformation is found in the majority of the locally closed structures. In addition, the M2 helices bending in the locally closed conformation move residues from the top of M2 and from the M2-M3 loop inside the intrasubunit pocket and in particular residue T245. erefore, site W3 is not accessible anymore from site W1 in the locally closed channel conformation, as shown in the crystal structure of bromoform bound to LC GLIC presented here. Free energy calculations corroborate these data showing that site W1 is clearly more favorable to bromoform than site W3 and B2 in the LC structures, while in GLIC ’s open form, this dišerence is less clear (gure 4.7). Importantly, structural alignments reveal that Y197 is highly conserved in Cys-loop receptors, including, nicotinic acetylcholine, 5HT3 and glycine receptors (Sauguet et al., 2013a). Interestingly, in GABAAR, the tyrosine is substituted by a phenylalanine, two residues with very similar side chains, especially considering their volume. We argue this residue might play a critical role in Cys-loop receptors’ sensitivity to anesthetics. Our simulations show that Y197 orientation ašects the F195 rotamer distribution. In the down conformation the Y197 residue prevents F195 from being in the same conformation, and vice versa. e F195 residue, given its direct interaction with the M2-M3 helix, may be a key residue to modulate GLIC gating. is residue is a glycine in all GABAA Conception et commande d’un robot de comanipulation pour l’assistance `a la biopsie de prostate. Cecile Poquet To cite this version: Cecile Poquet. Conception et commande d’un robot de comanipulation pour l’assistance `a la biopsie de prostate.. Robotics. Universit´e Pierre et Marie Curie - Paris VI, 2014. French. . HAL Id: tel-01081960 https://tel.archives-ouvertes.fr/tel-01081960 Submitted on 12 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es. L’UNIVERSITÉ Sciences Mécanique, Acoustique et Robotique Conception et commande d'un robot de comanipulation pour l'assistance à Directeur de recherche Soutenue le 11 Septembre 2014 Devant la commission d’examen formée de M. Gérard POISSON Professeur de l' Université d'Orléans M. Pierre RENAUD Professeur Mme. Jocelyne TROCCAZ Directrice de recherche à l'Université Joseph Fourier M. Jean-Luc ZARADER Professeur de l'Université Pierre et Marie Curie M. Guillaume MOREL Professeur de l'Université Pierre et Marie Curie Mme. Marie-Aude VITRANI Maître de Conférence à l'Université Pierre et Marie Curie M. Pierre MOZER Maître de Conférence à l'Université Pierre et Marie Curie M. Antoine LEROY Président de la société Koelis THÈSE PRÉSENTÉE A L’UNIVERSITÉ PIERRE ET MARIE CURIE ÉCOLE DOCTORALE SMAER Sciences Mécanique, Acoustique et Robotique Par Cécile POQUET POUR OBTENIR LE GRADE DE DOCTEUR SPÉCIALITÉ : Robotique Conception et commande d'un robot de comanipulation pour l'assistance à la biopsie de prostate Directeur de recherche : Guillaume MOREL ’examen formée de : Professeur de l' Université d'Orléans Professeur d'Université à l'INSA Strasbourg Directrice de recherche à l'Université Joseph Fourier Professeur de l'Université Pierre et Marie Curie Professeur de l'Université Pierre et Marie Curie Maître de Conférence à l'Université Pierre et Marie Curie Maître de Conférence à l'Université Pierre et Marie Curie et urologue à l'hôpital de la Pitié Salpêtrière Président de la société Koelis PIERRE ET MARIE CURIE Conception et commande d'un robot de comanipulation pour l'assistance à Rapporteur Rapporteur Examinatrice Examinateur Directeur Maître de Conférence à l'Université Pierre et Marie Curie Encadrante Maître de Conférence à l'Université Pierre et Marie Curie Invité Invité i Résumé Le cancer de la prostate est à l’heure actuelle le cancer le plus fréquent chez l’homme en France. Sous cette appellation unique sont regroupés des pronostics très différents : cancers asymptomatiques évoluant suffisamment lentement pour n’avoir aucune influence sur l’espérance et la qualité de vie, mais aussi cancers agressifs pouvant causer le décès. Or il est aujourd’hui très difficile d’analyser le cancer, d’en prévoir l’évolution et donc de prendre une décision thérapeutique adaptée. C’est pourquoi il est capital de faire évoluer les outils de diagnostic du cancer de la prostate, non pas pour détecter plus de cas mais pour être capable de mieux les qualifier. L’examen permettant de poser le diagnostic de cancer prostatique est la réalisation de biopsies de prostate, c’est-à-dire le prélèvement d’échantillons qui seront ensuite analysés. Or ce geste, effectué en routine clinique sous échographie bidimensionnelle sur un patient anesthésié localement, s’avère particulièrement complexe à réaliser et fournit très peu d’informations quantitatives sur les carottes de glande prélevées. C’est pourquoi la robotisation des biopsies est aujourd’hui vue comme un medium intéressant pour améliorer la qualité du diagnostic du cancer de la prostate. Dans cette thèse, nous abordons la problématique de l’assistance robotique à la réalisation de biopsies prostatiques. Le geste chirurgical et son impact sur le diagnostic sont d’abord étudiés, il en ressort qu’un tel système robotique présente un réel intérêt. Une analyse des dispositifs existants destinés à la biopsie et à la brachythérapie de prostate permet ensuite, en tenant compte des contraintes économiques liées à l’examen, de poser les grandes lignes de la conception de notre robot : utilisation de l’image échographique comme seule source d’informations extrinsèques, passage par la voie transrectale, cinématique à 6 degrés de liberté et exploitation du paradigme de la comanipulation. Un robot répondant à ces critères est présenté : Apollo est un bras anthropomorphique à actionnement hybride (trois freins et trois moteurs), une solution intéressante en matière de performances, de coût mais aussi de sécurité pour le patient. Différentes fonctions d’assistance peuvent être réalisées avec ce système. Un mode libre permettant à l’urologue de maîtriser les mouvements de la sonde sans influence aucune du robot est d’abord présenté. Une analyse du geste lors de la réalisation d’une tâche de pointage permet de prouver que le mode libre présente une transparence satisfaisante, grâce à des mesures matérielles et logicielles. Un mode verrouillé est ensuite développé : celui-ci assure un maintien en position de la sonde échographique à la fois souple et précis. Les performances de ce mode de commande, validées in vitro et in cadavero, permettent de justifier a posteriori la conception d’Apollo. Des essais cliniquesii portant sur les modes libre et verrouillé ont été autorisés par le Comité de Protection des Personnes ainsi que par l’Agence Nationale de Sécurité du Médicament et devraient débuter en Juillet 2014 à la Pitié-Salpêtrière. L’anus pouvant se déplacer au cours de l’examen et le niveau limite acceptable des efforts n’étant pas connu, la question du respect de cette contrainte anatomique se pose. L’utilisation d’un robot similaire à Apollo mais présentant six degrés de liberté permet de comparer une commande dite « déplacement de torseur » et une commande dite « bras de levier ». Il est ainsi montré que la commande « bras de levier » permet de réaliser en utilisant un robot tel qu’Apollo toute fonction d’assistance par retour d’effort exprimée comme une force virtuelle appliquée sur la partie distale d’un outil comanipulé, tout en respectant la contrainte anatomique. Un exemple d’une telle fonction d’assistance à la biopsie prostatique est ensuite présenté : il s’agit d’une augmentation de la raideur apparente de la prostate utilisant l’image échographique en temps réel dans l’élaboration de sa commande. Cette fonction, mise en œuvre en tout début de thèse, a été testée sur un prototype basique mais permet néanmoins de démontrer la faisabilité d’un tel retour d’effort basé image. Enfin, Apollo étant déjà pourvu de deux modes de base (libre et verrouillé) ainsi que d’une méthodologie de réalisation de commande par retour d’effort respectueuse de la contrainte anatomique exploitant le paradigme de la comanipulation, il est proposé d’utiliser également ses capacités de fonctionnement automatique. Une assistance au positionnement fin par bouclage sur l’image échographique est implémentée et testée in vitro : elle permet d’approcher la ligne de visée de l’aiguille à biopsie d’une cible définie dans la prostate avec une précision satisfaisante. Plusieurs possibles perspectives de recherche sont présentées en conclusion de la présentation de ces travaux. Mots clés : robotique médicale, comanipulation, conception, commande, contrainte anatomiqueiii Abstract Prostate cancer is nowadays the most common cancer among men in France. Very different prognosis are brought together under this only one designation : asymptotical cancers that evolve slowly enough as not to have any influence over the lifetime expectancy and quality of life, but also aggressive cancers that can lead to death. Yet to analyze cancer, to predict its outcome and thus to take an appropriate therapeutic decision is still very difficult. That’s why making progress in the field of diagnostical tools is crucial, not in order to detect more cancer cases but to be able to better qualify them. The examination that can bring to diagnose prostate cancer is prostate biopsy, which consists in taking out tissue samples that will later be analyzed. This gesture, which is performed in clinical routine under 2D ultrasonic imaging on a patient who is under local anesthesia, proves to be particularly complex to realize and provides very little quantitative information about the samples taken out. Thus the robotization of biopsies appears to be an interesting medium to improve the quality of the prostate cancer diagnostic. In this thesis, we take up the problematic of robotic assistance to the realization of prostate biopsies. The surgical gesture and its impact on the diagnostic are first studied. From that it appears that such a robotic system could bring noticeable improvement to the process. Thanks to an analysis of the existing devices destined for prostate biopsy and prostate brachytherapy and taking in account the economic constraints attached to the examination, guidelines are led out for our robot design : it will have to use the ultrasonic image as the only source of extrinsic information, pass through transrectal access, exhibit 6 degrees of freedom and exploit the comanipulation paradigm. A robot satisfying these criteria is presented : Apollo is an anthropomorphic arm exhibiting a hybrid actuation (three brakes and three motors), an interesting solution as regards performances, cost and patient safety. Different assistive functions can be performed with such a system. A free mode allowing the urologist to control the probe movements without any influence from the robot is first presented. An analysis of the gesture during a pointing task proves that the free mode exhibits a satisfying transparency, thanks to material and software design. A locked mode is then developed : it precisely locks the ultrasonic probe in its position while exhibiting a low stiffness. The performances of this control mode are tested both in vitro and in cadavero, which justify a posteriori Apollo’s design. Clinical trials focusing on the free mode and the locked mode have been authorized byiv the Comité de Protection des Personnes (french People Protection Committee) and the Agence Nationale de Sécurité du Médicament (french Drug Security National Agency), it should start in July 2014 in the Pitié-Salpêtrière hospital. Given that the anus can move during the examination and that the acceptable limit for the efforts applied on it is unknown, it is crucial to determine how to respect this anatomical constraint. Thanks to a robot that is similar to Apollo but exhibits six motorized degrees of freedom, two control laws are compared : a « wrench displacement » control law and a « lever effect » control law. It is proved that any force feedback assisting function can be realized with Apollo controled by a « lever effect » command and respect the anatomical constraint, provided that this function can be expressed as a virtual force applied on the distal part of a comanipulated tool. A example of such an assistance function is then presented : an increase in the apparent stiffness of the prostate based on real time ultrasonic imaging. This function as been implemented and tested at the beginning of the thesis here presented on a basic prototype but it still demonstrates the feasibility of such an image based force feedback. Finally, Apollo being already fitted with two basic modes (free and locked) and a methodology to compute a force feedback control law that respects the anatomical constraint thanks to comanipulation, exploiting its automatic functioning capabilities is proposed. An assistance to precise positionning featuring a loop on the ultrasonic image is implemented and tested in vitro : it allows to bring the line of sight of the biopsy needle near a target defined in the prostate with a satisfying precision. As a conclusion, possible future research axis arising from these work are presented. Keywords : medical robotics, comanipulation, design, control, anatomical constraintRemerciements Je souhaite tout d’abord remercier Guillaume Morel, Marie-Aude Vitrani et Pierre Mozer, pour leur accueil et tout ce qu’ils m’ont appris. Guillaume, merci de m’avoir amenée jusqu’au bout malgré nos caractères très différents. Marie-Aude, merci de m’avoir permis de m’investir autant dans l’enseignement. Pierre, merci de m’avoir ouvert les portes de la Pitié, plus jamais je ne pourrai dire « bonjour monsieur » sans arrière-pensée. Merci à Mrs. Renaud et Poisson, qui ont accepté d’être rapporteurs de cette thèse. Vos avis m’ont beaucoup aidée à clarifier mes idées et à réorganiser le contenu de cette thèse en vue de sa soutenance. Je remercie également Mme. Troccaz ainsi que Mrs. Zarader et Leroy, qui ont bien voulu être membres du jury. Je tiens aussi à remercier la société Koélis, et en particulier Michael Baumann que j’ai beaucoup sollicité. Je vous souhaite longue vie et j’espère que vous prendrez bien soin d’Apollo. Plus généralement, merci à tous les partenaires du projet PROSBOT, qui m’ont permis de voir plus loin que le bout de mon end-effecteur. J’adresse de chaleureux mercis aux membres de l’équipe Agathe, passés et actuels, avec qui j’ai pris beaucoup de plaisir à travailler (ou pas ;-)). Je ne me risquerai pas à les nommer un par un, de peur d’en oublier, mais j’ai néanmoins une pensée particulière pour le J08 historique, Juan et les Vincent. Mes remerciements particuliers vont également à David, Sébastien et Florian, ingénieurs dans l’équipe Agathe, qui m’ont énormément aidée. Merci à mes amis. Alsaciens, parisiens, suisses, fournisseurs de chats, couturières et tricoteuses, connus depuis le lycée ou plus récemment rencontrés, vous avez toujours été présents et avez grandement contribué à mon équilibre ces dernières années. Votre amitié m’est précieuse. Un grand merci à ma famille pour son soutien et surtout à mes parents, qui ont su me donner le goût des études puis m’ont encouragée quand j’ai voulu faire à mon tour une « foutue thèse ». Enfin, merci à toi Christophe. Je ne saurais écrire correctement tout ce que je te dois. Alors tout simplement : je t’aime, et je suis heureuse de me lancer dans un nouveau projet à (très) long terme avec toi.Table des matières 1 La robotique dans le diagnostic du cancer de la prostate 5 1.1 Le cancer de la prostate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.1 Du dépistage au diagnostic . . . . . . . . . . . . . . . . . . . . . . 6 1.1.2 Options thérapeutiques . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 La biopsie prostatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.1 Anatomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.2 Routine clinique . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.3 Problématiques inhérentes à l’examen . . . . . . . . . . . . . . . . 13 1.3 L’UroStation, un dispositif informatif . . . . . . . . . . . . . . . . . . . . 15 1.4 Analyse du geste chirurgical . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4.1 Influence sur le geste de biopsie . . . . . . . . . . . . . . . . . . . 17 1.4.2 Étude géométrique du geste . . . . . . . . . . . . . . . . . . . . . 18 1.4.3 Conséquences sur le diagnostic . . . . . . . . . . . . . . . . . . . 21 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2 Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo 25 2.1 Analyse des dispositifs existants . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1 Imagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2 Voie d’abord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.3 Cinématique du robot . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.1.4 Degré d’autonomie du robot . . . . . . . . . . . . . . . . . . . . . 30 2.2 Cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Distribution des actionneurs . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4 Différentes fonctions d’assistance . . . . . . . . . . . . . . . . . . . . . . 40 2.4.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.4.2 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.4.3 Assistance par retour d’effort . . . . . . . . . . . . . . . . . . . . . 41 2.4.4 Déplacement fin par retour échographique . . . . . . . . . . . . . . 42 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42viii Table des matières 3 Modes libre et verrouillé 45 3.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.1 Une caractéristique essentielle : la transparence . . . . . . . . . . . 46 3.1.2 Commande bas niveau . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1.3 Commande du mode libre . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Validation expérimentale du mode libre . . . . . . . . . . . . . . . . . . . 49 3.2.1 Analyse de la transparence d’Apollo in vitro . . . . . . . . . . . . 49 3.2.2 Essais in cadavero . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.3.1 Souplesse et précision, deux contraintes antagonistes . . . . . . . . 58 3.3.2 Commandes développées . . . . . . . . . . . . . . . . . . . . . . . 60 3.4 Validation expérimentale du mode verrouillé . . . . . . . . . . . . . . . . . 69 3.4.1 Validation in vitro . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.2 Validation in cadavero . . . . . . . . . . . . . . . . . . . . . . . . 73 3.5 Essais cliniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4 Assistance au positionnement comanipulé par retour d’efforts 77 4.1 Transmission d’efforts respectueuse d’un point de passage . . . . . . . . . 79 4.1.1 Contrainte anatomique . . . . . . . . . . . . . . . . . . . . . . . . 79 4.1.2 Différentes stratégies de commande possibles . . . . . . . . . . . . 80 4.1.3 Comparaison expérimentale . . . . . . . . . . . . . . . . . . . . . 83 4.2 Augmentation de raideur apparente basée image . . . . . . . . . . . . . . . 94 4.2.1 Mise à l’échelle de force . . . . . . . . . . . . . . . . . . . . . . . 94 4.2.2 Commande basée image . . . . . . . . . . . . . . . . . . . . . . . 96 4.2.3 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . 100 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5 Ajustement automatique lors d’une tâche de pointage 109 5.1 Réalisation d’un ajustement de visée . . . . . . . . . . . . . . . . . . . . . 109 5.2 Déplacements fins automatiques unitaires . . . . . . . . . . . . . . . . . . 111 5.2.1 Définition de la matrice d’interaction . . . . . . . . . . . . . . . . 111 5.2.2 Protocole d’identification de la matrice d’interaction . . . . . . . . 112 5.2.3 Déplacements automatiques, freins serrés . . . . . . . . . . . . . . 113 5.2.4 Déplacements automatiques freins déserrés . . . . . . . . . . . . . 116 5.3 Asservissement sur l’image de déplacements fins . . . . . . . . . . . . . . 118 5.3.1 Processus de bouclage . . . . . . . . . . . . . . . . . . . . . . . . 118 5.3.2 Expérience mise en place . . . . . . . . . . . . . . . . . . . . . . . 119 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6 Conclusions et perspectives 125 A Résumé du protocole expérimental des essais cliniques 131 Bibliographie 135Notations et définitions Rb = (O, −→xb , −→yb , −→zb ) ... repère lié à la base du robot Rs = (E, −→xs , −→ys , −→zs ) ... repère lié à la sonde échographique endorectale Ri = (E, −→xi , −→yi , −→zi ) ... repère lié à l’image échographique 3D Ri2 = (E, −→xi2, −→yi2) ... repère lié à l’image échographique 2D P ... centre du poignet du robot T ... point cible par lequel on souhaite faire passer la biopsie E ... extrémité de la sonde −→xA ... vecteur position du point A a ... coordonnées du vecteur −→a dans le repère RbIntroduction Contexte clinique Le cancer de la prostate est à l’heure actuelle le cancer le plus fréquent chez l’homme en France. Sous cette appellation unique sont regroupés des pronostics très différents : certains patients présentent des cancers asymptomatiques évoluant suffisamment lentement pour n’avoir aucune influence sur leur espérance et leur qualité de vie, tandis que d’autres sont atteints par des cancers agressifs pouvant causer leur décès. Traiter tous les patients de la même manière n’est donc pas envisageable, les différents types de cancer prostatiques appelant différentes solutions thérapeutiques. Or ces dernières années ont vu augmenter le nombre de dépistages systématiques du cancer de la prostate effectués dans la population des hommes de plus de 50 ans. Cette tendance crée la polémique car elle peut mener à un sur-diagnostic et à un sur-traitement des patients atteints : du fait des outils aujourd’hui disponibles pour réaliser le diagnostic il est très difficile d’analyser le cancer, d’en prévoir l’évolution et donc de prendre une décision thérapeutique adaptée. Il est donc capital de faire évoluer les outils de diagnostic du cancer de la prostate, non pas pour détecter plus de cas mais pour être capable de mieux les qualifier. L’examen permettant de poser le diagnostic de cancer prostatique est la réalisation de biopsies de prostate, c’est-à-dire le prélèvement d’échantillons qui seront ensuite analysés par l’anatomopathologiste. Or ce geste, effectué en routine clinique sous échographie bidimensionnelle sur un patient anesthésié localement, s’avère particulièrement complexe à réaliser et fournit très peu d’informations quantitatives sur les carottes de glande prélevés. C’est pourquoi la robotisation des biopsies est aujourd’hui vue comme un medium intéressant pour améliorer la qualité du diagnostic du cancer de la prostate. Problématique et objectifs Les travaux menés au cours de cette thèse portent sur le développement d’un robot d’assistance aux biopsies prostatiques et de sa commande, le système exploitant le paradigme de la comanipulation pour s’affranchir des limites rencontrés par les dispositifs2 Table des matières existants. Il doit assurer la sécurité du patient et assister l’urologue sans le contraindre ou l’éloigner du premier. Dans le chapitre 1 nous analysons le geste chirurgical effectué par l’urologue et son impact sur la détection de tumeurs. Cette étude nous permet de mettre en évidence l’intérêt d’un robot tel que celui que nous allons développer. Dans le chapitre 2 un état de l’art des dispositifs d’assistance à la biopsie et à la brachythérapie de prostate existants est présenté. L’analyse de ces systèmes et du contexte médico-économique nous amène à faire de premiers choix de conception, à partir desquels est développé le robot Apollo. Sa cinématique et son actionnement sont présentés. Plusieurs modes d’assistance à l’urologue qu’il est susceptible d’offrir sont évoqués. Dans le chapitre 3 nous nous concentrons sur deux de ces modes : le mode libre et le mode verrouillé. Le premier doit permettre à l’urologue de maîtriser les mouvements de la sonde sans influence aucune du robot, nous chercherons donc à améliorer la transparence d’Apollo et à la quantifier. Le second doit assurer un maintien en position de la sonde échographique qui soit à la fois souple, pour ne pas blesser le patient, et précis. Plusieurs commandes, exploitant différents composants d’Apollo, sont proposées puis testées, in vitro et in cadavero. Dans le chapitre 4 la question de l’exploitation du paradigme de comanipulation pour l’assistance au geste par retour d’effort est posée. Deux points clés apparaissent dans ce contexte : la prise en compte de la contrainte constituée par le point d’insertion de la sonde dans le patient et la gestion des échelles de temps dans une commande en effort basée image. Pour répondre à chacun de ces problèmes, plusieurs commandes sont présentées et évaluées. Dans le chapitre 5 les capacités de manipulation automatiques de la sonde échographique par Apollo sont exploitées. Une commande permettant le positionnement fin automatique basé image de la ligne de visée de l’aiguille à biopsie vers une cible est détaillée. Une preuve de concept expérimentale est ensuite présentée. Dans le chapitre 6 nous concluons sur ces études et présentons plusieurs pistes de prolongement de ces travaux. Contexte partenarial Cette thèse s’inscrit dans le cadre du projet PROSBOT, qui a été lancé en Novembre 2011. Il est financé par l’ANR TECSAN. Ce projet, qui regroupe à la fois des partenaires académiques, hospitaliers et industriels, a pour but le développement d’un système robotisé d’assistance aux biopsies prostatiques.Table des matières 3 Les partenaires académiques sont l’Institut des Systèmes Intelligents et de Robotique (Université Pierre et Marie Curie, Paris) et le laboratoire Techniques de l’Ingénierie Médicale et de la Complexité (Université Joseph Fourier, Grenoble). TIMC s’intéresse plus particulièrement au suivi d’organe par imagerie, à la prédiction de bougés par modèle bio-mécanique et au couplage image-modèle, tandis que l’ISIR travaille au développement d’un robot comanipulé, à l’analyse des bougés pour la commande et à la mesure de la position de la sonde échographique. Les partenaires hospitaliers, l’APHP-Pitié Salpêtrière (Paris) et le Centre d’Investigation Clinique - Innovation Technologique de Grenoble, sont en charge de l’analyse de risque, des évaluation cliniques et des aspects réglementaires de ces essais. Le partenaire industriel est Koelis, une entreprise basée à Grenoble spécialisée dans le développement de systèmes de GMCAO (Gestes Médico-Chirurgicaux Assistés par Ordinateur) dans le domaine de l’urologie. Cette société produit l’UroStation, un dispositif d’assistance aux biopsies prostatiques qui sera présenté en section 1.3.Chapitre 1 La robotique dans le diagnostic du cancer de la prostate Sommaire 1.1 Le cancer de la prostate . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.1 Du dépistage au diagnostic . . . . . . . . . . . . . . . . . . . . . . 6 1.1.2 Options thérapeutiques . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 La biopsie prostatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.1 Anatomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.2 Routine clinique . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.3 Problématiques inhérentes à l’examen . . . . . . . . . . . . . . . . 13 1.3 L’UroStation, un dispositif informatif . . . . . . . . . . . . . . . . . . . 15 1.4 Analyse du geste chirurgical . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4.1 Influence sur le geste de biopsie . . . . . . . . . . . . . . . . . . . 17 1.4.2 Étude géométrique du geste . . . . . . . . . . . . . . . . . . . . . 18 1.4.3 Conséquences sur le diagnostic . . . . . . . . . . . . . . . . . . . 21 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.1 Le cancer de la prostate Le cancer de la prostate est à l’heure actuelle très répandu : en 2013 240000 nouveaux cas ont été dépistés et presque 24000 décès sont survenus aux États-Unis d’après [Siegel 2013]. Néanmoins, si le cancer prostatique est le plus fréquent chez l’homme en France (taux d’incidence de 99,4 pour 100000) il n’est que le cinquième pour le taux de mortalité (11,3 pour 100000) [Rébillard 2013]. Les taux relatifs de survie sont donc très importants : quasiment 100% à 5 ans, 98% à 10 ans et 91% à 15 ans [ACS ]. L’âge moyen de diagnostic se situe autour de 69 ans, tandis que l’âge médian de décès se situe après 80 ans.6 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate Du fait de l’étendue de cette pathologie, l’examen permettant de la diagnostiquer est un acte médical courant : des centaines de milliers de biopsies sont réalisées chaque année aux États-Unis [ACS ] afin d’identifier les patients atteints d’un cancer de la prostate et d’estimer le pronostic. 1.1.1 Du dépistage au diagnostic À un stade précoce, le cancer de la prostate est généralement asymptomatique. Néanmoins la présence de cellules cancéreuses dans la prostate entraîne l’augmentation du taux sanguin d’antigène prostatique spécifique (PSA), ce qui trahit la présence d’un cancer avant qu’il ne génère le moindre symptôme. Mais le dosage du PSA n’est pas suffisant pour diagnostiquer à lui seul un cancer car il s’agit d’un marqueur de la prostate et non du cancer, ce qui signifie qu’une augmentation du taux de PSA n’est pas nécessairement due à un cancer prostatique. D’autres examens existent (toucher rectal, IRM...) mais ils permettent uniquement d’évoquer le diagnostic. En effet, tout zone dure dans la prostate n’est pas forcément cancéreuse et l’IRM peut uniquement montrer des « zones suspectes » sans pour autant permettre de conclure sur leur nature. La plupart du temps, c’est l’augmentation du taux de PSA qui va conduire le médecin à prescrire au patient une série de biopsies prostatiques, qui est le seul examen permettant d’établir le diagnostic. Les biopsies prostatiques se déroulent en chirurgie ambulatoire, sous anesthésie locale. L’urologue utilise une sonde échographique endorectale afin de visualiser la prostate et de choisir les lieux de biopsie. En règle générale, une aiguille à biopsie est utilisée pour réaliser une douzaine de ponctions aussi équi-réparties que possible dans le volume de la glande, auxquelles des biopsies ciblées dans les zones suspectes peuvent ensuite être ajoutées selon les résultats de l’imagerie. Les carottes de prostate ainsi prélevées sont confiées à l’anatomopathologiste pour analyse. Celui-ci informe l’urologue de la longueur de tissu cancéreux présente dans chaque prélèvement ainsi que de leur stade de développement (score de Gleason). Il revient à ce dernier de poser le diagnostic puis, en accord avec le patient, de prendre des décisions thérapeutiques. 1.1.2 Options thérapeutiques Si la présence de cellules cancéreuses au sein de la prostate est avérée, une décision thérapeutique doit être prise. Celle-ci doit offrir au patient les meilleures perspectives possibles, en terme de d’espérance mais aussi de qualité de vie. Différents choix sont possibles, en fonction notamment du stade d’évolution des cellules cancéreuses et de l’âge du patient. Du fait de la systématisation des examens de dépistage (l’Association Française d’Urologie préconise un dosage annuel du taux de PSA dès 50 ans, 45 ans en cas de risque familial ou ethnique, et jusqu’à 75 ans [Salomon 2010]), les cancers de la prostate sont généralement dépistés à un stade très précoce. Nous nous intéresserons ici aux options thérapeutiques généralement envisagées pour des cancers de stade II (cancers de taille1.1. Le cancer de la prostate 7 importante et ayant un haut score de Gleason mais localisés dans la prostate), c’est-à-dire les cas les plus souvent rencontrés. La première option possible est de ne pas traiter le patient et de le placer sous surveillance. En effet, de nombreux cancers prostatiques évoluent très lentement. Certains évoluent tellement peu qu’ils n’ont aucun effet sur la santé du patient, et ce jusqu’à leur mort (due à une autre cause). Dans ce cas, le patient sera placé sous surveillance : son taux de PSA sera suivi et il passera régulièrement des biopsies prostatiques et des IRMs afin de contrôler l’évolution de la zone cancéreuse. Les résultats des biopsies faites d’une année sur l’autre sont malheureusement parfois difficiles à expliquer. En effet, étant donné que les urologues utilisent uniquement l’image échographique 2D pour cibler les zones de biopsie et sachant que la taille de la prostate peut varier considérablement au cours du temps (et de l’évolution de la maladie), il est impossible de prélever précisément au même endroit d’une année sur l’autre. Ainsi, l’urologue ne peut connaître de façon certaine et quantitative l’évolution de l’étendue de la tumeur. FIGURE 1.1 – Illustrations tirées de [Gross 2011]. A gauche : accélérateur linéaire de particules classiquement utilisé en radiothérapie de la prostate. A droite : segmentation d’une image obtenue par scanner pour établir le planning de dosimétrie ; en orange la vessie, en vert le rectum, en bleu la prostate. Si le cancer est plus agressif et/ou plus étendu ou si le patient est jeune, il peut être décidé de le traiter par irradiation. Cette irradiation peut être faite soit par radiothérapie externe [Gross 2011], soit par brachythérapie. Dans le premier cas, un accélérateur de particules couplé à un logiciel de planning permet d’irradier le volume prostatique défini au préalable grâce à la segmentation d’un scanner, voir figure 1.1. Il s’agit dans le deuxième cas d’insérer des grains radioactifs dans la prostate à l’aide d’une aiguille en suivant un planning établi par un logiciel de dosimétrie, ceci afin d’assurer une irradiation suffisante et uniforme de la prostate. Cette opération se fait en s’aidant d’un « template ». Le template est une plaque percée, chaque trou correspondant à un point d’entrée pouvant être imposé par le logiciel de dosimétrie. Il est placé contre le périnée du patient qui est alors sous anesthésie générale. Un moyen d’imagerie médicale (sonde échographique endorectale, scanner ou IRM) est utilisé pour contrôler visuellement le geste au cours de son exécution et connaître a posteriori la répartition des grains dans la prostate (voir8 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate FIGURE 1.2 – Illustrations tirées de ❤tt♣✿✴✴✇✇✇✳✉r♦♣❛❣❡✳❝♦♠✴. A gauche : schématisation de la brachythérapie. A droite : visualisation échographique des grains insérés dans la prostate. figure 1.2). Quelle que soit la méthode d’irradiation de la prostate choisie, si la glande n’a pas été suffisamment traitée alors des cellules cancéreuses peuvent résister et continuer à se développer. A l’inverse, une irradiation trop importante de la prostate peut conduire à une irradiation des tissus environnants sains, ce qui peut avoir un impact sur les fonctions digestives notamment [Alivizatos 2005]. FIGURE 1.3 – Illustration tirée de [Bastide 2009]. Schématisation de la prostatectomie radicale. Il est également possible de pratiquer une prostatectomie radicale, c’est-à-dire une ablation de la glande dans sa totalité sous anesthésie générale, voir figure 1.3. A l’issue de l’opération, le patient est stérile mais toutes ses autres fonctions corporelles sont normalement intactes. Cependant la prostate est très proche à la fois des nerfs érectiles et du sphincter. Si ces structures anatomiques sont touchées lors de l’opération, le patient peut devenir impuissant et/ou incontinent. A l’heure actuelle, on constate que 2 à 3% des patients ayant subi une prostatectomie radicale souffrent par la suite d’incontinence permanente, 5 à 20% présentent une incontinence d’effort et 14 à 87% une dysfonction érectile selon les études (donc les définitions des complications post-opératoires considérées), les techniques chirurgicales employées, le stade tumoral, etc [Bastide 2009, Richard 1993]. Il est important de noter que les taux de complications sont particulièrement liés à l’âge1.2. La biopsie prostatique 9 du patient et à l’expérience du chirurgien [Alivizatos 2005]. La prostatectomie radicale est donc un geste chirurgical présentant des risques non négligeables et nécessitant un long apprentissage ; il convient de n’y recourir que lorsque c’est nécessaire. On note ainsi que, à l’heure actuelle, seuls des traitements globaux sont disponibles. En effet, qu’il s’agisse de l’irradiation ou de la chirurgie, la glande va être traitée dans sa totalité alors que le cancer peut être localisé dans une partie seulement de la prostate. De ce fait, des tissus sains sont impactés par les traitements proposés aux patients atteints d’un cancer prostatique. La décision thérapeutique est ainsi lourde de conséquences alors qu’elle repose sur des outils diagnostiques imprécis. Améliorer la qualité du diagnostic ne veut donc pas dire uniquement augmenter les capacités de détection des cellules cancéreuses, mais aussi et surtout augmenter sa précision. Un « bon » diagnostic est un diagnostic apportant des informations fiables et précises (si possible chiffrées) sur la répartition des tumeurs dans la prostate. Connaître la localisation précise des biopsies présentant des cellules cancéreuses permettrait à l’urologue de prendre une décision adaptée au cas particulier de son patient, sans sur-traitement ou opération inutile, et de se diriger vers des traitements focalisés sur les zones tumorales, ayant des effets secondaires moins importants. 1.2 La biopsie prostatique Comme nous l’avons vu précédemment, améliorer la qualité de l’examen menant au diagnostic du cancer de la prostate permettrait aux praticiens de prendre des décisions thérapeutiques en ayant une vision claire et juste du stade de développement de la maladie. Nous allons donc nous intéresser à la réalisation proprement dite des biopsies prostatiques, afin de déterminer les éléments de l’examen sur lesquels il est possible d’agir. 1.2.1 Anatomie La prostate est une glande qui fait partie du système reproducteur masculin. Elle se situe en avant du rectum, juste sous la vessie (figure 1.4). Elle a la forme d’une châtaigne et mesure 3 à 5 cm dans toutes les directions. Cependant sa taille peut varier du simple au quadruple selon le patient et son âge. Lorsque le sujet est debout, la zone basse est appelée apex, la zone haute est appelée base. Des cellules cancéreuses peuvent se développer dans la prostate, principalement près de sa périphérie, et l’on cherche à les détecter le plus tôt possible. 1.2.2 Routine clinique Bien que chaque urologue ait sa propre façon de procéder, des recommandations existent [Ouzzane 2011]. Les biopsies prostatiques se font généralement sans10 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate FIGURE 1.4 – Appareil génital masculin. 1. Vessie 2. Pubis (os) 3. Pénis 4. Corps caverneux 5. Gland 6. Prépuce 7. Méat urétral 8. Côlon sigmoïde 9. Rectum 10. Vésicule séminale 11. Canal éjaculateur 12. Prostate 13. Glande de Cowper 14. Anus 15. Canal déférent 16. Épididyme 17. Testicule 18. Scrotum. hospitalisation, en chirurgie ambulatoire. Le patient est placé en décubitus latéral gauche (couché en chien de fusil sur le côté gauche) comme on peut le voir sur la figure 1.5. Une sonde échographique endorectale munie d’un guide-aiguille est introduite dans le rectum. Une injection permet de réaliser une anesthésie locale de la paroi du rectum. FIGURE 1.5 – Installation pour la réalisation d’une série de biopsies prostatiques en routine clinique. En s’aidant de l’image échographique, le chirurgien dirige l’aiguille vers la zone désirée. Les tumeurs prostatiques, souvent des adénocarcinomes, n’étant généralement pas visibles sur l’image échographique, le chirurgien n’utilise celle-ci que pour se repérer au sein de la prostate et cibler les zones qu’il souhaite biopsier. Lorsqu’il est en face d’une1.2. La biopsie prostatique 11 de celles-ci, il perce la paroi du rectum pour placer l’extrémité de l’aiguille au contact de la capsule prostatique puis il actionne le pistolet à biopsie. Celui-ci va pousser très rapidement l’aiguille sur une distance maximale de 22 mm, pour une ponction nette et moins douloureuse (figure 1.6). FIGURE 1.6 – Réalisation d’une biopsie de prostate. A gauche : vue en coupe sagittale (❤tt♣✿✴✴✇✇✇✳✉r♦♣❛❣❡✳❝♦♠). A droite : gros plan sur la zone de ponction (❤tt♣✿✴✴✇✇✇✳ ✈✐❞❛❧❣r❛♥❞♣✉❜❧✐❝✳❝♦♠). Le schéma le plus couramment utilisé pour le placement des biopsies est le schéma en sextant : on réalise 12 biopsies, 6 dans chaque lobe (droite et gauche), également réparties entre la base, le milieu et l’apex (figure 1.8). Ces biopsies se font dans un ordre prédéterminé, afin de faciliter la navigation au sein de la prostate pour l’urologue. Il est éventuellement possible de réaliser des biopsies supplémentaires, par exemple dans des zones suspectes détectées à l’IRM (voir figure 1.7). Dans ce cas, la plupart du temps, le chirurgien réalise une mise en correspondance mentale entre les images IRM et l’image échographique. Il est possible de réaliser les biopsies par voie transpérinéale mais cela rend la procédure plus longue, coûteuse et délicate. En effet, il faut dans ce cas que le patient soit placé sous anesthésie générale, ce qui implique une hospitalisation. Or cela n’est pas compatible avec les contraintes médico-économiques actuelles : les biopsies prostatiques constituent certes un examen diagnostic et non pas un dépistage, néanmoins une part importante de la population masculine doit passer cet examen chaque année. Il faut donc qu’il reste peu onéreux et rapide (une séance typique dure une vingtaine de minutes). De plus, pratiquer une anesthésie générale plutôt qu’une anesthésie locale accroît les risques de complications pour le patient. Ainsi la voie d’abord transpérinéale n’est indiquée que12 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate FIGURE 1.7 – L’IRM permet de détecter des zones suspectées d’être concéreuses. A gauche, une image d’une prostate saine, à droite une prostate contenant un carcinome ( ). FIGURE 1.8 – Schéma de biopsies en sextant.1.2. La biopsie prostatique 13 dans de rares cas et la voie transrectale sera préférée en routine. Une autre raison pour laquelle l’urologue utilise l’échographie plutôt qu’une autre modalité d’imagerie est le contexte médico-économique. En effet, l’utilisation d’une machine telle que l’IRM est trop coûteuse en routine, sans compter la rareté de cette ressource qui la rend difficile d’accès et interdit de l’immobiliser une vingtaine de minutes pour chaque patient. 1.2.3 Problématiques inhérentes à l’examen Si la réalisation d’une biopsie prostatique peut paraître simple au premier abord, il n’en est rien. Tout d’abord, l’urologue ne bénéficie quasiment d’aucune information tactile sur le geste qu’il est en train de réaliser. En effet, les efforts exercés par le rectum sur la sonde peuvent être très importants et sont variables au cours du temps puisqu’ils dépendent notamment de l’activation musculaire (consciente ou non) du patient. Or il est important que le chirurgien maintienne un effort stable entre l’extrémité de la sonde et la paroi rectale. Un effort trop grand causerait une déformation et un déplacement importants de la prostate et pourrait occasionner de la douleur pour le patient. Un effort trop faible pourrait permettre à une bulle d’air de se glisser entre le transducteur et la paroi rectale, ce qui ferait perdre l’image échographique. Ainsi l’urologue doit garder les yeux rivés sur l’écran de l’échographe en permanence, afin d’estimer les efforts qu’il exerce sur la paroi rectale via la sonde en observant les déformations des structures anatomiques visibles à l’image échographique. Tout au long de l’examen, le chirurgien doit également se construire une image mentale de la prostate dans laquelle il se représente et suit la position de la sonde échographique, du plan de coupe affiché sur l’écran de l’échographe, et de l’aiguille. Cette opération demande une grande concentration au chirurgien. De plus il est impossible de connaître la localisation des biopsies effectuées avec précision, ce qui limite actuellement la qualité du diagnostic et du suivi de l’évolution des cellules cancéreuses et empêche le développement de traitements localisés des tumeurs. L’urologue ne pouvant se guider qu’à l’aide de l’image échographique et de sa reconstruction mentale de la prostate, il est difficile pour lui d’obtenir une répartition homogène des ponctions dans le volume prostatique et impossible de vérifier a posteriori la qualité de son échantillonnage. C’est pour cette raison notamment que l’échantillonnage systématique suivant le schéma en sextant a été retenu, puisqu’il permet d’obtenir un taux de détection des cellules cancéreuses satisfaisant malgré les imprécisions de réalisation du geste chirurgical [Villers 2004]. Il a été montré que, si l’on était capable d’obtenir une précision parfaite dans le placement des biopsies, on pourrait n’en réaliser que six ou sept, dont le placement a été défini grâce à une analyse statistique, tout en obtenant un taux de détection du cancer de l’ordre de 95%, tandis que le schéma en sextant offre un taux de détection de l’ordre de 70% [Zhan 2007]. Or il a été montré par [Rodriguez 1998] que, si14 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate les biopsies prostatiques par voie transrectale ne présentent pas de risque de complication majeure, les complications mineures sont courantes : hématurie (présence de sang dans les urines), saignement du rectum, douleur persistante, présence de sang dans le sperme, dysurie (difficulté à uriner)... Il serait donc intéressant de pouvoir guider le geste du chirurgien afin que les biopsies soient correctement réparties et moins nombreuses, ce qui réduirait le risque de complications post-opératoires. Enfin, lors de l’examen la prostate bouge sous les effets combinés de plusieurs mécanismes : – mouvements physiologiques (respiration, mais aussi remplissage de la vessie), – déplacements du patient (volontaires et réflexes), – pression exercée par le chirurgien sur la paroi rectale via la sonde échographique endorectale, – efforts générés par l’aiguille lors de sa pénétration dans la paroi rectale puis dans la prostate. Il a été montré dans [Stone 2002] que l’insertion d’une aiguille dans la glande peut occasionner des déplacements d’amplitude pouvant atteindre le centimètre (moyenne observée : 2,3 mm) et des déformations (définies ici comme la variation de la dimension maximale de la prostate dans la direction considérée) pouvant atteindre 2 cm (moyenne observée : 4,2 mm). L’insertion d’aiguilles peut également faire pivoter la prostate d’un angle pouvant atteindre 13,8 ◦ d’après [Lagerburg 2005]. Un état de l’art de la littérature disponible sur le déplacement de la prostate durant des séances de biopsie et de brachythérapie a été réalisé par [Marchal 2006] et aboutit à une conclusion similaire : des déplacements de la prostate de l’ordre de 5 mm sont couramment observés, ils dépassent même régulièrement le centimètre. L’importante mobilité et la déformabilité de la prostate, qui sont liées aux actions du chirurgien mais aussi à des éléments que le praticien ne peut contrôler, compliquent la tâche de reconstruction mentale de la prostate pour l’urologue et limitent encore sa maîtrise de l’échantillonnage de la glande. A cela il faut ajouter enfin que, lorsque la sonde est orientée de telle façon que le guide-aiguille se retrouve en-dessous, le chirurgien peut se retrouver obligé d’adopter une position inconfortable pour pouvoir à la fois maintenir la sonde en position et insérer le pistolet à biopsie dans le guide-aiguille. Or cette configuration de la sonde correspond généralement à sa position moyenne lors des ponctions dans le lobe gauche, donc à la moitié de l’examen. En résumé, la réalisation de biopsies prostatiques impose à l’urologue une lourde charge cognitive ainsi qu’une charge physique. Les mobilités de la prostate et le fait que le patient ne soit pas sous anesthésie générale compliquent encore le geste. Devant ce constat, différents systèmes d’assistance à la réalisation de biopsies prostatiques ont été proposés.1.3. L’UroStation, un dispositif informatif 15 1.3 L’UroStation, un dispositif informatif Afin d’assister l’urologue lors de la réalisation de biopsies prostatiques, différents systèmes lui apportant des informations supplémentaires sur le champ opératoire et le geste qu’il réalise ont été proposés. Parmi eux figure l’UroStation, un produit de la société Koelis ([Koe ], Grenoble, France), partenaire du projet ANR PROSBOT avec qui nous avons travaillé dans le cadre de cette recherche. L’UroStation est un système d’assistance aux biopsies prostatiques sous imagerie échographique. Elle permet de visualiser les biopsies dans une image tridimensionnelle de la prostate, mais aussi d’effectuer une fusion IRM-échographie. FIGURE 1.9 – L’Urostation, mise en œuvre et capture d’écran. L’UroStation est composée d’un échographe 3D « classique » en liaison avec un ordinateur portable. Sur cet ordinateur tourne un logiciel qui récupère les images échographiques tridimensionnelles au fur et à mesure de l’examen (la dernière image 3D arrivée est appelée peropératoire) et qui, en utilisant des techniques avancées de recalage élastique d’images tridimensionnelles présentées dans [Baumann 2009] et [Baumann 2012], calcule la position de l’aiguille dans une image de référence de la prostate (une image tridimensionnelle qui a été prise en tout début d’examen, appelée panorama). Cette information est présentée au chirurgien sous la forme d’un cylindre positionné dans une image échographique 3D de la prostate. Le praticien peut alors naviguer dans cette image et analyser le geste qu’il vient d’effectuer. Il est important de noter que ce recalage se fait sans segmentation de la prostate, en traitant l’image 3D dans sa globalité. Après chaque déclenchement du pistolet à biopsie, le praticien lance une acquisition 3D durant laquelle il cherche à maintenir la sonde immobile. En effet l’image tridimensionnelle est obtenue en assemblant une série d’images bidimensionnelles correspondant à différentes orientations de la barrette d’éléments piézoélectriques, qu’un moteur permet de faire pivoter à l’intérieur de la sonde (le volume échographique ainsi16 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate visualisé est représenté à gauche de la figure 1.9). Le logiciel permet d’afficher la position et l’orientation de la biopsie sur le panorama puisque, le guide-aiguille étant fixé à la sonde échographique endorectale, la « ligne de visée » de l’aiguille est fixe par rapport à l’image peropératoire. Le chirurgien peut ainsi savoir où est la zone biopsiée, à la fois par rapport aux autres biopsies et par rapport à la prostate. De plus si l’acquisition est lancée en mode simulation, c’est-à-dire avant le déclenchement du pistolet à biopsie, le logiciel indique à l’urologue quelle serait la position de la biopsie s’il avait inséré l’aiguille dans la capsule prostatique dans cette configuration. Malheureusement, l’acquisition d’une image 3D n’est pas instantanée puisqu’elle nécessite un balayage du transducteur. Or les mouvements du patient et du chirurgien intervenant durant la phase d’acquisition nuisent à la qualité de l’image 3D obtenue donc à la précision du placement de la biopsie. Ainsi l’UroStation fournit une information précieuse au chirurgien sur l’échantillonnage de la prostate mais a posteriori et sous réserve d’un maintien en position de la sonde qui soit satisfaisant durant l’acquisition des images échographiques tridimensionnelles. Les biopsies virtuelles ne sont elles qu’indicatives puisque, pour que le chirurgien cible effectivement la zone indiquée par l’UroStation suite à une biopsie virtuelle, il faudrait que l’urologue et le patient soient totalement immobiles à partir du moment où la biopsie virtuelle est demandée et jusqu’au moment où la biopsie réelle est faite. Il a été déjà montré par [Mozer 2009] que l’UroStation permet à l’urologue d’améliorer la précision de son geste (c’est-à-dire de limiter la distance entre la biopsie réalisée et la cible visée), mais nous nous sommes posé deux questions supplémentaires : – l’UroStation induit-elle une modification dans la façon même de procéder à des biopsies prostatiques ? – en vue du développement d’une assistance robotique, les données issues des recalages effectués par l’UroStation permettent-elles de mettre en évidence certaines caractéristiques du geste chirurgical ? 1.4 Analyse du geste chirurgical Nous avons pu utiliser une base de données comportant les examens de 78 patients qui ont passé des biopsies prostatiques entre Janvier et Septembre 2009 à l’APHP Pitié-Salpêtrière, et pour lesquels le docteur Pierre Mozer et deux de ses collègues ont utilisé l’UroStation. Les algorithmes de recalage élastique implémentés dans l’UroStation permettent l’enregistrement de nombreuses données géométriques lors de l’examen. Toutes ces données sont exprimées dans un repère lié à la prostate (panorama initial) et peuvent être extraites à l’aide d’un exécutable écrit par M. Baumann (Koelis). Grâce à un traitement mathématique puis à une étude statistique des données, nous avons pu étudier l’influence de l’UroStation sur le geste médical réel, les caractéristiques géométriques de ce dernier et leur influence sur le diagnostic.1.4. Analyse du geste chirurgical 17 1.4.1 Influence sur le geste de biopsie Les données issues de l’UroStation ont été d’abord exploitées pour calculer la position dans le repère lié à l’image de référence du point d’entrée de l’aiguille dans la capsule prostatique lors de chaque biopsie, pour chaque lobe. Connaissant l’ordre de réalisation des biopsies, on peut alors les relier en les parcourant dans le sens des aiguilles d’une montre pour dessiner la surface ponctionnée dans chaque lobe (biopsies reliées dans l’ordre 1-2-4-6-5-3 pour le lobe droit, 8-7-9-11-12-10 pour le lobe gauche, voir figure 1.8). La figure 1.10 présente deux exemples de graphiques obtenus. FIGURE 1.10 – Position du transducteur pour chaque biopsie du lobe droit dans un repère lié à la prostate pour deux patients différents. A gauche : schéma en sextant respecté. A droite : biopsies n ◦ 5 et 6 du schéma en sextant inversées. Les surfaces ponctionnées lors de certains examens apparaissent « croisées », comme dans l’exemple présenté à droite de la figure 1.10. Cela signifie que l’urologue n’a pas exécuté les biopsies dans l’ordre prévu par le schéma en sextant, pourtant globalement suivi (on retrouve bien une biopsie dans chaque zone du sextant). Il s’agit d’un effet direct de l’utilisation de l’UroStation : l’urologue constate en temps réel ses imprécisions et les corrige. Supposons par exemple que le chirurgien souhaite réaliser la biopsie n ◦3. Il vise sa cible en s’appuyant sur l’image échographique 2D, fait pénétrer l’aiguille dans la capsule prostatique, actionne le pistolet à biopsie, puis lance l’acquisition d’une image 3D. L’UroStation l’informe que la troisième biopsie, qui vient d’être réalisée, est en réalité là où devrait se trouver la biopsie n ◦4 du schéma en sextant. L’urologue va alors déplacer la sonde de manière à réaliser sa quatrième biopsie dans la zone où aurait dû se trouver la troisième. Ainsi, tout en conservant le même nombre de biopsies et les mêmes zones cible, l’urologue effectue un échantillonnage de la prostate de meilleure qualité et plus conforme18 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate au schéma en sextant recommandé (seul l’ordre des biopsies a changé). L’UroStation, qui est un système informatif, permet donc d’améliorer l’examen puisqu’il aide l’urologue à échantillonner équitablement les différentes zones de la prostate en lui permettant de visualiser les éventuelles erreurs de placement de biopsie. 1.4.2 Étude géométrique du geste 1.4.2.1 Apparition de faisceaux Les données issues de l’UroStation permettent également de connaître la position et l’orientation de l’aiguille à biopsie, ainsi que la position du transducteur dans le repère lié à l’image de référence lors de chaque biopsie. Ainsi, pour chaque patient, l’ensemble des positions et orientations de l’aiguille par rapport à la prostate lors d’une séance est connue. Nous avons utilisé les données issues d’examens de routine pour analyser la géométrie du geste. Deux situations, présentées sur la figure 1.11 , peuvent être observées selon les patients : – 1er cas : les positions successives de l’aiguille à biopsie dans le repère lié à la prostate forment un faisceau en forme de sablier, tous les axes ainsi obtenus traversant une unique « zone de passage » correspondant logiquement à l’anus, – 2ieme cas : les positions successives de l’aiguille à biopsie dans le repère lié à la prostate se séparent en deux faisceaux ou plus, chaque faisceau présentant une « zone de passage » distincte. Le deuxième cas correspond à un examen au cours duquel, à un moment donné, la prostate s’est déplacée de façon importante et a glissé d’un côté ou de l’autre de la sonde échographique tout en tournant. Ainsi dans le repère lié à la prostate l’anus a effectivement changé de position, ce qui explique la présence de plusieurs faisceaux d’aiguilles (biopsies faites avant ou après le glissement). 1.4.2.2 Espace de travail de la sonde Pour chaque biopsie, il est également possible de calculer la position de la sonde échographique endorectale dans le repère lié à la prostate connaissant la position du transducteur (qui est situé à l’extrémité distale de la sonde) et l’orientation de l’aiguille (qui est la même que celle de la sonde puisque le guide-aiguille est rigidement lié à cette dernière). Ainsi, une position moyenne de la sonde dans le repère lié à la prostate a pu être déterminée pour chaque patient et les écarts à cette position moyenne ont pu être analysés. Les caractéristiques statistiques de ces écarts sont présentés en table 1.4.2.2. Si l’espace de travail de la sonde échographique endorectale varie beaucoup d’un patient à l’autre, il est néanmoins contenu dans un cône de demi-angle au sommet de 30◦ .1.4. Analyse du geste chirurgical 19 FIGURE 1.11 – Axe de la sonde lors de biopsies successives dans un repère lié à la prostate pour deux patients. En haut : 1er cas, un seul faisceau. En bas : 2ieme cas, deux faisceaux.20 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate Écart de position Écart d’orientation du transducteur (mm) de la sonde (◦) Minimum 5,0 12,2 Premier décile 7,1 16,7 Médiane 9,0 21,7 Neuvième décile 12,2 26,1 Maximum 20,6 30,2 Moyenne 9,2 21,4 TABLEAU 1.1 – Écart de position et d’orientation de la sonde par rapport à sa position moyenne dans le repère lié à la prostate. 1.4.2.3 Surface de la capsule prostatique ponctionnée Nous avons également utilisé les données issues de l’UroStation pour calculer la surface ponctionnée dans chaque lobe prostatique. Cette surface est définie de la façon schématisée en figure 1.12 . Le barycentre Ebar des points d’entrée Ei de l’aiguille dans le lobe prostatique est déterminé, ainsi que la position du plan PE qui minimise la distance au carré des points Ei au plan PE. Le point Ebar est ensuite déplacé perpendiculairement au plan PE vers l’extérieur de la prostate, de la distance entre le plan PE et le point Ei qui en est le plus en avant, de façon à tenir compte au moins en partie du bombé de la prostate. Ensuite, la surface de chaque triangle formé par Ebar et deux points Ei consécutifs est calculée. La somme de ces surfaces est une estimation de la surface ponctionnée dans le lobe considéré. Les valeurs obtenues pour chaque patient et chaque lobe sont présentées sur la figure 1.13 en fonction du volume prostatique du patient. FIGURE 1.12 – Définition de la surface percée dans un lobe. Il apparaît que les surfaces de ponction sont variables d’un patient à l’autre mais semblent être corrélées avec le volume prostatique, ce qui est logique. La surface de ponction moyenne est de l’ordre de 1 cm2 seulement. On observe également que la surface1.4. Analyse du geste chirurgical 21 FIGURE 1.13 – Surface percée dans chacun des lobes prostatiques en fonction du volume de la glande. Gris foncé : lobe droit. Gris clair : lobe gauche. ponctionnée dans le lobe gauche est en moyenne plus importante que celle percée dans le lobe droit. Or il existe effectivement une dissymétrie du geste médical : durant la réalisation des biopsies dans le lobe droit le guide-aiguille se situe sur le dessus de la sonde échographique, tandis qu’il se trouve en-dessous de la sonde échographique lorsque le chirurgien travaille sur le lobe gauche. Il en résulte une position moins confortable pour l’urologue lorsqu’il biopsie le lobe gauche. On pourrait s’attendre à ce que cet inconfort se traduise par une surface de ponction moins importante dans le lobe gauche que dans le lobe droit puisque les mouvements semblent gênés. Mais il semblerait que cette mauvaise position lors des ponctions dans le lobe gauche conduise à une sous-estimation par le chirurgien de ses propres mouvements et donc à une surface de ponction plus grande dans le lobe gauche que dans le lobe droit. 1.4.3 Conséquences sur le diagnostic Une variabilité non négligeable de la surface prostatique ponctionnée selon le patient et le lobe biopsié (gauche ou droit) est apparue. Une étude a alors été menée pour déterminer, en combinant ces données avec les résultats des analyses anatomopathologiques, si ces différences de géométrie ont un impact sur le diagnostic final posé par l’urologue. Elle a porté sur 158 patients, âgés de 64 ans en moyenne, chez qui un cancer de la prostate a été diagnostiqué grâce à un examen sous UroStation durant lequel six biopsies ont été réalisées dans chaque lobe. L’histogramme présenté en figure 1.14 montre pour chaque lobe l’évolution du taux de22 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate FIGURE 1.14 – Taux de détection de cancer et surface biopsiée pour chacun des lobes en fonction du volume prostatique. détection de cancer (pourcentage de patients dont au moins l’un des échantillons biopsiés dans ce lobe présente des cellules cancéreuses) et de la surface biopsiée (comme définie précédemment) en fonction du volume prostatique. On constate tout d’abord que le taux de détection chute lorsque le volume prostatique augmente, ce qui est logique puisque le volume de tissu prélevé est constant donc la proportion de volume prélevé évolue de façon inversement proportionnelle à la taille de la prostate. On note également qu’au moins une des biopsies effectuées dans le lobe droit présentait des cellules cancéreuses pour 29,1% des patients inclus dans l’étude (tous volumes prostatiques confondus), tandis que pour le lobe gauche ce taux est de 40,5%. Or il n’y a aucune raison anatomique connue pouvant expliquer une dissymétrie de la répartition des tumeurs prostatiques à l’échelle d’une telle cohorte de sujets. Cette disparité dans le taux de détection de cancer entre le lobe droit et le lobe gauche est donc bien liée à l’examen. Cela pourrait être dû à la dissymétrie du geste de ponction entre les lobes droit et gauche, ou encore à la fatigue puisque les urologues qui ont réalisé les biopsies prises en compte dans cette étude ponctionnent toujours le lobe droit en premier, puis le lobe gauche. Le diagnostic posé par l’urologue à l’issue d’une séance de biopsies prostatiques classique est donc biaisé. Nous avons ainsi montré que la dissymétrie des surfaces ponctionnées dans chacun des lobes prostatiques conduisait à une erreur, ou tout du moins une imprécision, sur1.5. Conclusion 23 le diagnostic posé : les tumeurs localisées dans le lobe gauche sont statistiquement plus souvent détectées que celles situées dans le lobe droit. Ainsi, une séance « type » de biopsies prostatiques fournit à l’urologue une information biaisée ; les décisions thérapeutiques prises à la suite de cet examen seront basées sur une vision faussée de la présence et de la répartition de cellules cancéreuses dans les deux lobes prostatiques. Outre le fait que cette dissymétrie dans la détection des tumeurs puisse mener à des décisions thérapeutiques n’étant pas les plus appropriées, elle empêche de plus d’avancer vers des traitements locaux du cancer prostatique pourtant plus intéressants en terme de sauvegarde des tissus sains et de réduction des effets secondaires. 1.5 Conclusion La qualité de réalisation des biopsies prostatiques est d’une importance capitale en terme de santé publique puisque cet examen débouche sur un diagnostic et sert de base à la prise de décisions thérapeutiques. Or il s’agit d’un geste complexe et contraignant, du fait des nombreux phénomènes perturbateurs qui interviennent (mouvements de la prostate, mouvements du patient, positions inconfortables pour le praticien) et de la basse qualité des informations fournies à l’urologue (pas d’information tactile, image temps réel ne permettant pas de visualiser les lésions, qualité de l’image 3D dégradée par les mouvements cités précédemment). De plus nous avons montré que, malgré l’utilisation d’un outil d’aide à la visualisation des biopsies, l’examen présente une dissymétrie géométrique. Celle-ci coïncide avec une différence statistique dans les taux de détections de cellules cancéreuses en fonction du lobe dans lequel elles sont situées, ce qui crée un biais dans le diagnostic sur lequel sont ensuite basées les décisions thérapeutiques. Il apparait donc qu’une assistance robotique pourrait améliorer la réalisation de biopsies prostatiques, en ce sens qu’elle pourrait permettre de mieux maîtriser la répartition des biopsies mais aussi de faciliter la navigation dans la prostate et même de soulager physiquement le praticien. En effet si la sonde échographique est liée à l’organe terminal d’un robot alors il est possible d’exploiter les atouts classiques d’un tel système : force, endurance, répétabilité, précision, navigation, enregistrement de données quantitatives. Dans le prochain chapitre, nous allons détailler la conception d’un tel robot qui est forcément impactée par son cadre de travail particulier : au contact direct avec deux humains. Nous déterminerons également les types d’assistance que le système ainsi conçu est susceptible d’offrir au praticien, avec les problématiques robotiques que cela implique d’adresser.Chapitre 2 Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo Sommaire 2.1 Analyse des dispositifs existants . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1 Imagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2 Voie d’abord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.3 Cinématique du robot . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.1.4 Degré d’autonomie du robot . . . . . . . . . . . . . . . . . . . . . 30 2.2 Cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Distribution des actionneurs . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4 Différentes fonctions d’assistance . . . . . . . . . . . . . . . . . . . . . . 40 2.4.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.4.2 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.4.3 Assistance par retour d’effort . . . . . . . . . . . . . . . . . . . . . 41 2.4.4 Déplacement fin par retour échographique . . . . . . . . . . . . . . 42 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1 Analyse des dispositifs existants La robotique pourrait constituer un apport intéressant et à fort impact pour l’assistance à la biopsie prostatique. De plus, la brachythérapie présente des problématiques similaires pour la robotisation puisqu’il s’agit également de maîtriser l’insertion d’une aiguille dans la prostate d’un patient.26 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo En plus d’améliorer la qualité du diagnostic, connaître précisément la géométrie des biopsies permettrait en cas de cancer prostatique avéré de se tourner vers des traitements locaux : seuls les sites où des cellules cancéreuses ont été détectées seraient traités, épargnant ainsi les tissus sains. Ce geste thérapeutique local pourrait prendre différentes formes : irradiation localisée à l’aide de grains radioactifs, destruction des cellules par laser amené via une fibre optique logée dans une aiguille, apport de molécules capables d’attaquer les cellules cancéreuses, cryothérapie... Ces techniques locales ont comme point commun de nécessiter elles aussi le placement précis d’une aiguille dans la prostate, elles pourraient donc être mises en œuvre avec le même système que les biopsies. Ainsi, si dans nos travaux nous nous sommes placés plus spécifiquement dans le cadre du diagnostic du cancer de la prostate, l’extension à la thérapie reste possible. Du fait du grand intérêt et de l’important potentiel d’un système d’assistance à la biopsie et/ou à la brachythérapie et/ou au traitement focal du cancer de la prostate, plusieurs équipes de recherche se sont penchées sur la question. Un état de l’art exhaustif concernant la biopsie et la brachythérapie est présenté dans [Hungr 2012]. Les systèmes robotiques qui ont été proposés à ce jour diffèrent sur quatre critères principaux : – la modalité d’imagerie, – la voie d’abord, – la cinématique du robot, – le degré d’autonomie du robot. 2.1.1 Imagerie Le premier critère permettant de classifier les systèmes robotiques proposés dans la littérature est la modalité d’imagerie utilisée. En effet, la prostate n’étant ni rigide ni fixe dans le corps du patient, il est nécessaire de contrôler sa géométrie et sa position en temps réel. Pour cela, différents moyens d’imagerie peuvent être utilisés : l’échographie [Bassan 2007, Bax 2011, Davies 2004, Fichtinger 2006, Fichtinger 2008, Ho 2009, Hungr 2012, Phee 2005, Salcudean 2008, Schneider 2004, Wei 2005, Yu 2007], le scanner [Fichtinger 2002] et l’imagerie par résonance magnétique [Abdelaziz 2011, Chinzei 2000, Fischer 2008, Krieger 2011, Patriciu 2007, Song 2010, van den Bosch 2010]. Comme on peut le voir sur la figure 2.1, les trois modalités fournissent des images ayant des caractéristiques différentes : précision, structures observables, durée d’acquisition, exposition aux rayonnements pour le patient et le personnel hospitalier à proximité. L’échographie permet d’obtenir soit des images bidimensionnelles en temps réel (plan de coupe), soit des images tridimensionnelles à une fréquence de l’ordre du dixième de Hertz, la scène observée devant être au maximum immobile par rapport à la sonde échographique. Cette image 3D peut être obtenue soit à l’aide d’une sonde 3D [Hungr 2012] (dans ce cas, c’est la barrette d’éléments piézoélectriques située dans l’extrémité de la sonde qui pivote, le mouvement étant géré par l’échographe), soit à l’aide d’une sonde 2D déplacée de façon2.1. Analyse des dispositifs existants 27 FIGURE 2.1 – Prostate vue sous différentes modalités d’imagerie : échographie à gauche, IRM au milieu, scanner à droite (✇✇✇✳♦♥❝♦♣r♦❢✳♥❡t et ✇✇✇✳✉r♦❢r❛♥❝❡✳♦r❣). incrémentale [Bassan 2007, Bax 2011, Davies 2004, Fichtinger 2006, Fichtinger 2008, Ho 2009, Phee 2005, Salcudean 2008, Wei 2005, Yu 2007]. Dans les deux cas, une image 2D est enregistrée à chaque position (de la barrette d’éléments piézoélectriques dans la sonde ou de la sonde dans le rectum du patient) puis un volume 3D est reconstruit à partir de l’ensemble des images ainsi obtenues. L’avantage principal de l’échographie est que les appareils sont déjà présents dans les cabinets d’urologie, puisqu’ils sont utilisés pour les biopsies prostatiques en routine clinique, et relativement peu coûteux. Il est cependant important de noter que les tumeurs ne sont pas visibles à l’échographie, puisque leur échogénécité est généralement la même que celle du reste de la prostate. De plus l’image échographique est de très mauvaise qualité : elle est très bruitée, de ce fait les structures anatomiques peuvent être difficiles à distinguer. L’IRM et le scanner permettent d’avoir des images plus nettes et plus précises, mais à un coût bien plus élevé et une fréquence plus basse. Cela implique que le patient doive rester le plus immobile possible durant l’acquisition, cette condition étant bien plus complexe à remplir lorsque le patient est réveillé que lorsqu’il est placé sous anesthésie générale. De plus, le scanner a un effet irradiant sur le patient comme sur le praticien, ce qui limite son temps d’utilisation, tandis que pour sa part l’IRM impose de prendre en compte la compatibilité magnétique, ce qui donne des contraintes lourdes à prendre en compte lors de la conception de robots destinés à être utilisés dans son enceinte [Fischer 2008, Song 2010]. Une autre faiblesse de l’IRM et du scanner en vue de la robotisation est que, contrairement au cas de l’échographie, la ligne de visée de l’aiguille à biopsie n’est pas connue dans le repère Ri lié à l’image mais uniquement dans le repère Rb lié à la base du robot. Ainsi, une phase de calibration est nécessaire pour déterminer la transformation Tib permettant de passer du repère Ri au repère Rb. Le site à biopsier étant choisi dans l’image, ses coordonnées dans le repère Ri sont connues et ses coordonnées dans le repère Rb peuvent être calculées. Le robot a alors pour tâche de placer l’aiguille à cette position. Or la prostate bouge et se déforme au cours de la procédure, sous l’influence de nombreux paramètres : respiration, remplissage de la vessie, pression d’une éventuelle sonde échographique (parfois utilisée en complément du scanner ou de l’IRM, afin d’avoir28 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo un retour visuel en temps réel), insertion de l’aiguille... Ainsi, la prostate a bougé durant le temps qu’a mis le robot pour atteindre les coordonnées cibles dans le repère Rb et ces dernières ne correspondent plus à la même zone physique de la prostate. Ainsi, il a été montré par [Xu 2010] que le robot initialement présenté dans [Krieger 2005] ne pouvait pas atteindre une précision satisfaisante de positionnement de l’aiguille à biopsie dans la prostate si les mouvements par rapport à la base du robot et les déformations de la glande n’étaient pas pris en compte. Outres les avantages et inconvénients déjà présentés pour chacune des modalités d’imagerie, il est important de prendre en compte le contexte médico-économique dans lequel devra évoluer un robot d’assistance aux biopsies prostatiques. En effet l’échographe est un appareil utilisé dans la pratique clinique actuelle, les cabinets d’urologie en sont donc d’ors et déjà équipés. A l’inverse, le scanner et l’IRM sont des ressources coûteuses et rares, souvent partagées entre plusieurs services hospitaliers et qui ne sont donc pas aisément accessibles. Pour toutes ces raisons, nous avons choisi de baser notre système sur une imagerie par ultrasons. 2.1.2 Voie d’abord La voie d’abord par laquelle on cherchera à atteindre la prostate avec une aiguille constitue un deuxième critère de classification des systèmes robotiques proposés dans la littérature : il est possible d’utiliser la voie transpérinéale [Abdelaziz 2011, Bax 2011, Bassan 2007, Chinzei 2000, Davies 2004, Fichtinger 2002, Fichtinger 2006, Fichtinger 2008, Fischer 2008, Heikkilä 2008, Ho 2009, Hungr 2012, Patriciu 2007, Phee 2005, Podder 2007, Salcudean 2008, Song 2010, van den Bosch 2010, Yu 2007, Wei 2005] ou la voie transrectale [Krieger 2011, Schneider 2004], comme illustré par la figure 2.2. Comme nous l’avons vu au chapitre 1, lors d’une série de biopsies prostatiques classique (c’est-à-dire non robotisée) la voie transrectale est généralement préférée. Seule une anesthésie locale de la paroi du rectum est réalisée en début d’examen. Ainsi, le patient est réveillé et peut bouger. Dans ce cas, l’urologue utilise généralement une sonde échographique endorectale sur laquelle est fixée un guide-aiguille, l’aiguille à biopsie étant glissée dans ce dernier. L’aiguille est non biseautée et de diamètre important (18 gauges, soit environ 1 mm). Sa déformation lors de la biopsie peut ainsi être considérée comme négligeable et sa ligne de visée correspond à l’axe du guide-aiguille. Elle est fixe dans l’image échographique, ce qui permet à l’urologue de cibler le site de ponction de son choix en positionnant la sonde. En revanche, lors d’une séance de brachythérapie, la voie transpérinéale est préférée. Certains auteurs proposent d’utiliser cet abord pour la réalisation des biopsies2.1. Analyse des dispositifs existants 29 FIGURE 2.2 – Voies d’abord possibles pour la biopsie de prostate : voie transrectale et voie transpérinéale. prostatiques [Song 2010], mais cela pose plusieurs problèmes : la procédure est plus longue et le patient doit être placé sous anesthésie générale. Cette dernière condition n’est pas compatible avec les contraintes médico-économiques que nous avons déjà évoquées au chapitre 1 et accroit les risques pour le patient. En revanche, cet abord permet l’insertion simultanée de plusieurs aiguilles. Notre système d’assistance aux biopsies prostatiques devra donc utiliser la voie transrectale, le guide-aiguille étant fixé sur la sonde échographique endorectale, car cela est non seulement compatible avec la pratique clinique actuelle mais permet également de limiter la complexité du système à développer puisque imageur (sonde échographique) et instrument effecteur (ligne de visée de l’aiguille à biopsie, matérialisée par le guideaiguille) sont rigidement liés. 2.1.3 Cinématique du robot Pour placer l’extrémité d’une aiguille à une position et dans une orientation données seuls 5 degrés de liberté (ddl) sont nécessaires, puisque la rotation de l’aiguille autour de son axe n’a pas d’impact sur la tâche de positionnement. Néanmoins, certains auteurs choisissent de motoriser la rotation de l’aiguille autour de son axe afin d’améliorer sa pénétration à travers le périnée [Bassan 2007, Hungr 2012, Podder 2007, Yu 2007] (la pénétration d’une aiguille dans la paroi rectale étant plus aisée). Lorsque la voie transrectale est choisie, l’anus joue le rôle d’une contrainte cinématique à 2 degrés de liberté type linéaire-annulaire : la sonde (à laquelle le guide-aiguille donc la ligne de visée de l’aiguille à biopsie sont rigidement liés) peut pivoter dans toutes les directions et translater selon son axe. La tâche présente alors 4 degrés de liberté. Ceci a poussé plusieurs auteurs à concevoir des systèmes présentant un centre de30 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo rotation déporté, ou « remote center of motion » (RCM) [Wei 2005] : du fait de la géométrie du robot son effecteur, ici la sonde, passe forcément par un point fixe dans le repère Rb lié à sa base. Le principal intérêt d’une telle approche est que le robot ne doit posséder que 4 degrés de liberté, ce qui réduit son coût total. En contrepartie, toute intervention devra commencer par une phase de mise en place pour faire coïncider l’anus du patient et le RCM du robot. Celle-ci peut être longue, fastidieuse et peut poser problème dans le cas où le patient est sous anesthésie locale uniquement : en effet, celui-ci peut alors se déplacer consciemment ou non par rapport à la base du robot, ce qui non seulement impose de recommencer l’étape d’installation mais surtout peut occasionner des blessures pour le patient. De plus il apparait en pratique clinique que les chirurgiens utilisent parfois l’élasticité de l’anus pour atteindre certaines cibles de biopsies avec ce qu’ils jugent être la bonne orientation de la sonde [Torterotot 2010]. Dans ce cas, formellement, la contrainte cinématique n’est plus respectée. Ainsi, utiliser un RCM limite l’espace de travail de la sonde échographique par rapport à une manipulation humaine, ce qui peut empêcher d’atteindre avec le robot certaines configurations de biopsie voulues par le praticien. Ainsi il nous parait intéressant de développer un robot présentant 6 degrés de liberté. Outre le fait qu’un tel système n’impose pas de suivre une procédure lourde de mise en place, cela permettra à l’urologue de bénéficier de sa liberté de mouvement habituelle lorsque cela s’avère nécessaire mais également d’assurer la sécurité du patient en n’imposant aucune contrainte de coïncidence géométrique. 2.1.4 Degré d’autonomie du robot Les systèmes proposés dans la littérature diffèrent également par leur degré d’autonomie. Certains systèmes sont entièrement autonomes : ils positionnent le guideaiguille de façon à ce que la ligne de visée de l’aiguille à biopsie soit celle qui est désirée, puis insèrent eux-même l’aiguille dans la prostate [Davies 2004, Bassan 2007, Fichtinger 2006, Hungr 2012, Patriciu 2007, Yu 2007]. Ce mode de robotisation s’avère intéressant dans le cas où le système est basé sur un scanner, puisque cela permet à l’urologue de se tenir loin de l’appareil et donc de limiter son exposition aux radiations. D’autres robots sont des comanipulateurs, qui partagent la réalisation du geste avec le chirurgien. La répartition des tâches est généralement séquentielle : le robot place le guideaiguille à la position désirée, puis le chirurgien réalise l’acte médical proprement dit en manipulant l’aiguille à la main [Abdelaziz 2011, Bax 2011, Chinzei 2000, Fichtinger 2002, Fichtinger 2008, Fischer 2008, Schneider 2004, Salcudean 2008, Song 2010, Wei 2005]. Sur certains systèmes, le robot limite néanmoins la manipulation manuelle de l’aiguille en bloquant cette dernière lorsque la profondeur d’insertion prévue par le logiciel de commande est atteinte [Ho 2009, Phee 2005].2.1. Analyse des dispositifs existants 31 La première limitation de ces systèmes vient de leur commande. Elle peut être calculée soit en temps réel, soit une fois pour toute sous forme de trajectoire donnée dans le repère Rb lié à la base du robot. La première solution impose d’être capable de traiter des images à très haute vitesse, en supposant que celles-ci sont fournies à une cadence suffisante. A l’heure actuelle, aucun système ne présente ces capacités. Dans le deuxième cas, le calcul des déplacements du robot doit se faire à partir d’une unique image puis d’un modèle qui devrait idéalement prendre en compte de très nombreux paramètres pouvant varier dans le temps même si le patient est sous anesthésie générale : anatomie (géométrie) du patient, raideur des différents organes entrant en jeu, déplacements et déformations cycliques dûs à la respiration, contraintes géométriques liées au point d’insertion de l’aiguille et/ou de l’imageur dans le corps du patient, etc. Or de telles données sont difficiles voire impossibles à obtenir à l’heure actuelle et, sans au moins une partie d’entre elles, la précision requise pour que le positionnement de l’aiguille soit acceptable peut ne pas être atteinte [Xu 2010]. De plus ces deux types de systèmes ne sont pas utilisables sur un patient qui n’est pas endormi, pour des raisons évidentes de sécurité mais aussi d’acceptabilité pour le patient (voir figure 2.3). Or, comme nous l’avons vu au chapitre précédent, l’anesthésie générale est pour la majorité des patients à la fois inutilement risquée et incompatible avec les contraintes médico-économiques liées aux biopsies prostatiques. FIGURE 2.3 – Dessin issu de « Quino-thérapie » par Quino (ISBN : 2.7234.0520.6, éditions Glénat). Nous avons donc choisi de développer un robot comanipulé ou « cobot » qui ne fonctionnera en mode « automatique » que dans certaines conditions dans lesquelles le système est capable d’assurer la sécurité du patient, à savoir maintien en position de la sonde vers une cible et petits déplacements. Il est à noter que le fait de limiter32 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo les mouvements automatiques à ces deux seuls cas nous permettra de choisir des actionneurs moins nombreux et/ou moins compliqués que si le robot avait dû être totalement automatique et capable de générer seul de grands déplacements. Le reste du temps, l’urologue et le robot tiendront tous les deux la sonde échographique endorectale et travailleront ensemble. Une combinaison particulière de choix de conception et de réglages de commande permettront d’assurer à tout moment la sécurité du patient. 2.2 Cinématique Comme nous l’avons vu dans la section 2.1, nous cherchons à concevoir un robot présentant 6 degrés de liberté capable de comanipuler une sonde échographique endorectale fixée à son effecteur. De nombreuses cinématiques sont alors envisageables [Smith-Guerin 2008], le choix devant être fait en fonction de l’espace de travail voulu, de l’encombrement acceptable, des efforts en jeu ainsi que de la précision attendue. Nous avons montré dans la section 1.4.2.2 que l’espace de travail de la sonde est un cône de demi-angle au sommet de 30◦ , représenté sur la figure 2.4. La rotation de la sonde autour de son axe doit être possible sur un angle de l’ordre de 300◦ environ, la position moyenne du guide-aiguille durant les biopsies du lobe gauche étant diamétralement opposée à sa position moyenne durant les biopsies du lobe droit (au-dessus ou en-dessous de la sonde). FIGURE 2.4 – Espace de travail de la sonde montée sur Apollo. Un robot, appelé Apollo, a été conçu de façon à autoriser cet espace de travail lorsque sa base est placée sur le lit d’examen, à une quarantaine de centimètres environ du point d’insertion de la sonde dans le patient (par exemple dans le creux des genoux du patient2.2. Cinématique 33 FIGURE 2.5 – Exemple de positionnement du robot Apollo pour la réalisation de biopsies prostatiques FIGURE 2.6 – Apollo34 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo placé en décubitus latéral, comme on peut le voir sur la figure 2.5). Comme on peut le voir sur la figure 2.6, il est composé de six pivots assemblés selon une géométrie anthropomorphique : – les deux premiers pivots, l’axe du premier étant vertical et celui du suivant étant horizontal, constituent une épaule ; – le troisième pivot, dont l’axe est parallèle à celui du deuxième, correspond au coude du robot ; – les trois derniers pivots, dont les axes sont concourants en un unique point P, forment le poignet du robot. La géométrie d’Apollo est décrite en suivant la convention de Denavit et Hartenberg [Denavit 1955], les paramètres sont résumés dans la table 2.2 et les liaisons correspondantes sont représentées sur la figure 2.7. i αi−1 ai−1 di θi 1 0 0 0 θ1 2 −π/2 0 0 θ2 3 0 0,25 m 0 θ3 4 π/2 0 0,30 m θ4 5 −π/4 0 0 θ5 6 π/2 0 0 θ6 TABLEAU 2.1 – Paramètres de Denavit et Hartenberg du cobot Apollo. FIGURE 2.7 – Schéma cinématique d’Apollo. Il est à noter que les variables θ2 et θ3 ne sont pas directement accessibles par les capteurs du robot. Les axes 2 et 3 sont en réalité deux sommets opposés d’un parallélogramme déformable que l’on peut voir sortir du capot sur la figure 2.6, les moteurs étant montés sur deux articulations successives du parallélogramme (celles qui sont situées au plus proche de la base, cachées par le capot). Les codeurs montés sur les axes moteurs donnent donc les angles moteurs θm2 et θm3, qui permettent de calculer les2.2. Cinématique 35 angles articulaires θ2 et θ3 comme suit : θ2 = θm2 (2.1) θ3 = π −θm3 (2.2) Le dernier segment est conçu de manière à présenter un trou cylindrique de 8 cm de diamètre dont l’axe coïncide avec celui de la dernière liaison. Ainsi, n’importe quelle sonde échographique peut être connectée à l’extrémité d’Apollo à l’aide d’une pièce d’interface propre à la sonde. La fixation de la pièce d’interface au robot se fait à l’aide de couples trous/picots métalliques (pour la mise en position) et d’aimants (pour le maintien en contact) visibles sur la figure 2.8. Grâce à ce système, Apollo peut être utilisé avec différentes sondes échographiques sans devoir être entièrement reconçu. FIGURE 2.8 – Système de fixation de la sonde échographique endorectale sur le robot Apollo, avec la première version des pièces d’interface. Nous disposons d’une sonde échographique endorectale 4DEC9-5/10STI de la société Ultrasonix, pour laquelle nous avons conçu une pièce d’interface qui a été fabriquée en prototypage rapide. Comme on peut le voir sur la figure 2.8, cette interface est constituée de deux pièces comprenant chacune une demi-empreinte de la sonde. Ces deux pièces sont fixées autour de la sonde grâce à deux vis de serrage. Dans une première version, un trou a été ménagé face à l’entrée du guide-aiguille, afin de permettre l’insertion de l’aiguille. Une deuxième version de cette pièce, que l’on peut voir sur la figure 2.9, a été dessinée par la36 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo FIGURE 2.9 – Deuxième version des pièces d’interface montée sur la sonde échographique endorectale. suite pour permettre une protection efficace lors d’un futur essai clinique : cette nouvelle pièce d’interface permet en effet de placer une protection type préservatif entre la sonde échographique endorectale et le guide-aiguille. 2.3 Distribution des actionneurs Nous appellerons mode libre le mode dans lequel le robot est « suiveur », c’est-à- dire qu’il laisse entièrement le contrôle des mouvements de la sonde à l’utilisateur. Ce mode pourrait être réalisable sans actionneur, mais Apollo doit également être capable d’appliquer sur la sonde échographique endorectale des efforts afin de la maintenir à une position décidée par l’urologue (la position de la sonde au moment où l’urologue déclenche ce mode, que nous appellerons mode verrouillé). En robotique, il existe classiquement deux façons d’atteindre un tel but : – utiliser un moteur électrique asservi en position avec un fort gain (ce qui génère une raideur importante), – utiliser des freins électromagnétiques (dont la raideur est infinie tant qu’il n’y a pas de glissement). Les freins électromagnétiques présentent un rapport couple résistant/masse plus important que les moteurs électriques. Ils sont également moins chers et leur commande est plus facile à mettre en œuvre. Ils présentent néanmoins un inconvénient majeur : ils n’offrent que très peu de possibilités de commande. En effet ils fonctionnent sur un mode « tout ou rien » : les freins sont soit bloqués (ils présentent alors une raideur infinie tant que le couple résisitif maximal n’est pas atteint) soit libres (ce qui correspond à une raideur nulle), aucun intermédiaire n’est possible. Ainsi, si tous les axes d’Apollo étaient équipés de freins, il ne serait pas possible d’exercer des efforts contrôlés sur la sonde échographique endorectale.2.3. Distribution des actionneurs 37 De plus, une fois que l’urologue a positionné la sonde comme il le souhaitait et actionné le mode verrouillé, il relâche la sonde. Toutes les forces externes que l’urologue compensait jusque là en mode libre, à savoir le poids de la sonde et les efforts de contact exercés par le patient sur la sonde, agissent alors comme des perturbations pour le robot. Si la raideur du robot pourvu de freins n’est pas infinie, cela va conduire à un déplacement de la ligne de visée de l’aiguille à biopsie. Or augmenter la raideur de la structure du robot et des freins signifie limiter la déformation des pièces mécaniques et augmenter la puissance des freins, ce qui implique d’augmenter la masse du système. Ceci va à l’encontre du besoin de transparence, qui est crucial en mode libre (nous reviendrons en détail sur ce point dans le chapitre suivant, section 3.1). À cela il faut ajouter qu’un robot qui présenterait une raideur importante serait dangereux pour le patient : si ce dernier bouge tandis que le robot présente une raideur élevée, alors il peut être blessé. Pour choisir les actionneurs équipant les six axes d’Apollo, plusieurs éléments ont donc dû être pris en considération : – la masse du robot doit être minimisée afin de faciliter sa manipulation en mode libre, – le prix du robot doit rester le plus bas possible afin de permettre son transfert vers un usage clinique, – la raideur du robot doit pouvoir être modulée durant les phases de verrouillage afin de ne pas blesser le patient, qui est sous anesthésie locale uniquement et peut donc bouger pendant que le robot maintient la sonde en position. Si les deux premières contraintes vont dans le sens des freins, la troisième impose l’utilisation de moteurs. Afin d’obtenir le meilleur compromis possible, un mode d’actionnement hybride a finalement été choisi. Les trois premiers pivots sont équipés de moteurs électriques Maxon RE35, afin de pouvoir générer un comportement élastique de raideur contrôlable au centre P du poignet. Pour assurer une bonne maniabilité en mode libre, les forces d’inerties et les forces résistives doivent être minimisées. Les moteurs sont donc placés au plus près de la base du robot. Ainsi, non seulement ils génèrent moins d’effets inertiels, mais ils n’auront pas à être portés par les segments du robot (le « bras » situé entre les axes 2 et 3 et l’« avant-bras » qui lie les axes 3 et 4). De ce fait, le bras et l’avant-bras pourront être plus légers, ce qui participera aussi à la réduction de l’inertie du robot. C’est pour cette raison que le bras est en réalité un parallélogramme, comme nous l’avons vu précédemment. Les moteurs étant déportés près de la base du robot, il est nécessaire d’utiliser une transmission pour exercer les couples voulus au niveau des axes ; le choix d’un système à câble limite les frottements. Chaque moteur est équipé d’un codeur optique, ce qui permet de mesurer la position articulaire de chacun des trois premiers axes. Les trois axes du poignet sont en revanche équipés de freins Kebco 01.P1.300, ce qui restreint la masse et le coût du robot. Un potentiomètre est monté sur l’axe de chacun des freins, donnant ainsi accès aux positions articulaires des axes correspondants. Si la conception des axes 4 et 5 ne pose pas de problème particulier (les freins, qui sont38 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo traversants, peuvent être montés directement sur les axes), il n’en va pas de même pour l’axe 6. En effet, celui-ci devant comporter un trou cylindrique de 8 cm centré sur l’axe de la liaison pour permettre le montage de la sonde sur le robot, le frein ne peut être placé directement sur cet axe. Il a été choisi d’utiliser une transmission par engrenage : une couronne dentée a été fixée sur l’anneau dans lequel viendra se monter la pièce d’interface sonde/robot tandis que le corps du frein est monté sur le segment liant les axes 5 et 6 et une deuxième roue dentée est fixée sur l’axe traversant le frein. Le ratio des nombres de dents étant de 4,5, un potentiomètre multitours a été choisi pour équiper l’axe 6, permettant de couvrir la plage de rotation autorisée par les butées (environ 350◦ ). Les freins sont commandés de façon binaire : ils sont soit alimentés, auquel cas il sont libres et n’empêchent pas la rotation de l’axe sur lequel ils sont montés ; soit non alimentés, auquel cas il sont bloqués. Tous ces éléments sont visibles sur la figure 2.10. FIGURE 2.10 – Gros plan sur le poignet d’Apollo. La présence de ces freins constitue une sécurité supplémentaire pour le patient. En effet, lorsque les freins sont relâchés, Apollo peut uniquement exercer sur la sonde une force au centre P du poignet, point autour duquel la sonde pivote librement. Ainsi le robot, ne pouvant exercer de couple sur la sonde au point P, ne peut générer d’effort sur l’anus du patient via la sonde. Les risques d’occasionner des blessures en cas de dysfonctionnement sont donc réduits. Le robot a été fabriqué par la société Haption [Hap ], spécialisée dans la conception d’interfaces haptiques puissantes (utilisant notamment des transmissions à câbles). Les trois premiers axes d’Apollo sont identiques à ceux du Virtuose3D, tandis que les 3 derniers axes ont été fabriqués à partir de notre conception. Les caractéristiques d’actionnement axe par axe sont résumées dans la table 2.3. Les moteurs des trois premiers axes permettent de générer au centre P du poignet un effort continu de 5 N et un effort pic de 15 N.2.3. Distribution des actionneurs 39 Axe Actionneur Transmission Rapport Couple maximal 1 moteur câble 21,6 3,4 Nm 2 moteur câble 14,9 2,4 Nm 3 moteur câble 14,8 2,3 Nm 4 frein directe 1 0,4 Nm 5 frein directe 1 0,4 Nm 6 frein engrenage 4,5 1,8 Nm TABLEAU 2.2 – Caractéristiques d’actionnement d’Apollo axe par axe. FIGURE 2.11 – Éléments mécaniques améliorant la transparence du robot Apollo.40 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo Les masses des différentes pièces ont été réparties de façon à ce que la gravité ne génère pas de moment sur les axes. Pour cela, deux stratégies ont été utilisées : – un contrepoids a été monté sur l’axe 4 d’Apollo, voir figure 2.11, cette solution présentant néanmoins l’inconvénient d’ajouter à la masse embarquée du système ; – des ressorts ont été montés sur les axes 2 et 3 d’Apollo, voir figure 2.11. Notons que les ressorts montés sur les axes 2 et 3 compensent une part constante des effets de la gravité correspondant à peu près au poids des pièces non-démontables (ni la sonde ni sa pièce d’interface ne sont concernées). Cela permet d’éviter les soucis au démontage de la sonde : si le poids de la sonde et de son interface était compensé par les ressorts, lors de leur décrochage le poignet du robot monterait brusquement et risquerait de venir frapper l’utilisateur au visage. Notons que les couples articulaires que peut générer Apollo sont relativement faibles, ce qui constitue une sécurité intéressante pour un robot travaillant au contact de deux humains : en cas de problème, il sera aisé pour l’urologue de forcer (à la main) les mouvements du robot. Les moteurs électriques sont contrôlés au bas niveau par une boucle de courant. Grâce à cette dernière, il est possible de commander les moteurs directement en effort. 2.4 Différentes fonctions d’assistance Nous disposons donc d’un robot capable de bloquer l’orientation de la sonde échographique endorectale par rapport à son avant-bras ou, au contraire, de la laisser libre de pivoter selon les trois directions autour du centre P de son poignet. Apollo est également capable d’exercer une force contrôlée en ce point P. Ces capacités vont nous permettre de nous intéresser à trois tâches ou types de tâches : – laisser l’urologue libre de manipuler la sonde comme il le souhaite, sans qu’il ne ressente la présence du robot ; – verrouiller la positon de la sonde, c’est-à-dire maintenir la sonde en position tout en garantissant la sécurité du patient, sans l’aide de l’urologue ; – assister l’urologue dans le positionnement de la sonde par rapport à la prostate en mode libre en y ajoutant un retour d’effort. 2.4.1 Mode libre Comme nous l’avons vu précédemment à la section 2.1.4, planifier une trajectoire de la sonde échographique endorectale que devra générer le robot est très complexe si l’on doit prendre en compte les déformations et déplacements de la prostate, les mouvements éventuels du patient, les contraintes anatomiques liées au rectum et à l’anus, la possibilité de s’appuyer sur ces contraintes anatomiques sans atteindre le seuil de douleur du patient, etc. En revanche, un urologue est lui capable d’intégrer toutes ces informations lorsqu’il manipule la sonde. De plus, il possède un sens du toucher fin ainsi que des connaissances et2.4. Différentes fonctions d’assistance 41 compétences cognitives qui ne peuvent être mises en équation : connaissances médicales, réactivité, adaptabilité, etc. C’est pourquoi Apollo doit offrir un « mode libre », dans lequel il laisse la sonde « aussi libre que possible », l’urologue contrôlant les mouvements de cette dernière. Nous présenterons ce mode plus en détails dans le chapitre 3, section 3.1. 2.4.2 Mode verrouillé Lorsque le système est en mode libre, l’urologue peut positionner manuellement la sonde à l’endroit qui lui parait être adapté pour faire une biopsie. Comme nous l’avons vu plus tôt, le chirurgien cherche alors à rester le plus immobile possible au moins le temps d’effectuer la biopsie proprement dite. Il peut également, s’il dispose d’une UroStation (voir section 1.3), faire une biopsie test puis soit effectuer la biopsie réelle si la localisation simulée lui convient, soit corriger sa position si nécessaire. Dans les deux cas, il est important que la sonde soit immobile dès le lancement de l’acquisition 3D (qui permettra de calculer l’emplacement de la biopsie virtuelle dans un repère lié à la prostate) et jusqu’à la biopsie ou la réalisation d’un petit déplacement de la sonde. Or un maintien en position parfait est très difficile à obtenir à la main. C’est pourquoi Apollo doit pouvoir présenter un « mode verrouillé », durant lequel le robot maintient précisément la sonde en position tandis que l’urologue a les mains libres pour effectuer d’autres tâches (manipulation de l’échographe, de l’UroStation et du pistolet à biopsie notamment). Cette tâche est double : le robot doit à la fois assurer un positionnement précis de la sonde échographique endorectale et garantir la sécurité du patient, qui n’est pas endormi. Il doit donc être à la fois précis et souple, deux contraintes classiquement antagonistes en robotique. Nous avons vu dans la section 2.3 comment le choix des actionneurs d’Apollo permet de prendre en compte en partie ce problème, nous verrons dans le chapitre 3, section 3.3 la commande qui a été développée pour le résoudre complètement. 2.4.3 Assistance par retour d’effort Si les modes précédents constituent déjà une amélioration potentiellement significative de l’examen, aussi bien en terme de gestion de la répartition des biopsies qu’en terme de confort pour le praticien, un système tel qu’Apollo pourrait être utilisé pour développer de nombreuses autres fonctions d’assistance. Il est notamment envisageable d’utiliser Apollo pour fournir à l’urologue un retour d’effort via l’application de forces sur la sonde en mode libre, comme nous le verrons au chapitre 4. Nous verrons dans un premier temps en section 4.1 que la génération d’un retour d’effort à travers une contrainte anatomique peut avantageusement exploiter les capacités de l’humain manipulant la sonde pour arriver à une commande nécessitant peu42 Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de prostate : Apollo de ressources et présentant un haut niveau de sécurité pour le patient. Cette capacité de génération d’un retour d’effort peut permettre de réaliser plusieurs fonctions, par exemple un guidage virtuel ou une augmentation de la raideur apparente de la prostate. Le développement de cette dernière fonction sera détaillé dans la section 4.2. 2.4.4 Déplacement fin par retour échographique La fonction de verrouillage présentée précédemment souffre d’une faiblesse : ce mode n’utilise que les capteurs du robot pour élaborer sa commande, ce qui signifie qu’Apollo maintient la sonde fixe dans un repère Rb lié à sa propre base. Or la prostate n’est pas fixe dans ce repère et la cible de biopsie est quant à elle fixe par rapport à la prostate. Ainsi, il est possible que la précision du maintien de la ligne de visée de l’aiguille en direction de la cible à biopsier en mode verrouillé ne soit pas satisfaisante dans le repère de la tâche. Ainsi, si la réalisation de grands mouvements par le robot en autonomie est à proscrire pour les raisons détaillées dans la section 2.1, il est possible d’utiliser Apollo pour générer à partir du mode verrouillé de petits déplacements correctifs de la sonde calculés à partir d’informations tirées de l’échographie. Ainsi, l’urologue pourrait effectuer un positionnement aussi précis qu’il est humainement possible de le faire, puis le robot pourrait effectuer une correction fine en se basant sur les données géométriques issues de l’image. Ce mode de fonctionnement sera détaillé dans le chapitre 5. 2.5 Conclusion Dans ce chapitre, nous avons analysé les différents robots dédiés au diagnostic et au traitement du cancer de la prostate qui existent dans la littérature. Nous avons ensuite présenté le robot Apollo, un comanipulateur de sonde échographique endorectale à 6 degrés de liberté présentant un actionnement hybride, et les raisons qui ont motivé les différents choix de conception. Différentes fonctions que notre système pourrait offrir ont été présentées dans la section 2.4, elles seront détaillées dans la suite de ce document. Dans le chapitre 3, nous détaillerons les deux fonctions de base que sont le mode libre (section 3.1) et le mode verrouillé (section 3.3) : le premier doit permettre une manipulation de la sonde par l’urologue sans que le mouvement ne soit impacté par le robot, tandis que le deuxième doit permettre un maintien en position de la sonde à la fois précis et souple par le robot seul. Le fait que notre système soit équipé de trois moteurs et capable d’exercer une force maîtrisée au centre de son poignet nous permet de nous intéresser à différents types d’assistance par comanipulation, que nous détaillerons dans le chapitre 4. Nous nous intéresserons particulièrement à la méthodologie de génération de guides haptiques à2.5. Conclusion 43 travers une contrainte anatomique et à un exemple de retour haptique basé image. Nous nous pencherons ensuite, dans le chapitre 5, sur la génération de déplacements fins basés sur des informations issues de l’image échographique. Cette possibilité d’ajuster la position de maintien de la sonde viendra renforcer le mode verrouillé pour aider l’urologue à atteindre les cibles de son choix.Chapitre 3 Modes libre et verrouillé Sommaire 3.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.1 Une caractéristique essentielle : la transparence . . . . . . . . . . . 46 3.1.2 Commande bas niveau . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1.3 Commande du mode libre . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Validation expérimentale du mode libre . . . . . . . . . . . . . . . . . . 49 3.2.1 Analyse de la transparence d’Apollo in vitro . . . . . . . . . . . . 49 3.2.2 Essais in cadavero . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.3.1 Souplesse et précision, deux contraintes antagonistes . . . . . . . . 58 3.3.2 Commandes développées . . . . . . . . . . . . . . . . . . . . . . . 60 3.4 Validation expérimentale du mode verrouillé . . . . . . . . . . . . . . . 69 3.4.1 Validation in vitro . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.2 Validation in cadavero . . . . . . . . . . . . . . . . . . . . . . . . 73 3.5 Essais cliniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Nous avons présenté dans le chapitre précédent les raisons qui ont présidé à la conception d’Apollo, un cobot d’assistance aux biospies prostatiques, dont nous avons également défini les principaux modes de fonctionnement. Nous allons dans ce chapitre détailler l’élaboration et la validation expérimentale des modes libre (ou « mode L ») et verrouillé (ou « mode V »). 3.1 Mode libre La première capacité que doit présenter notre système est de permettre une manipulation de la sonde par le chirurgien qui soit naturelle. C’est cette aptitude que l’on46 Chapitre 3. Modes libre et verrouillé appelle « transparence ». 3.1.1 Une caractéristique essentielle : la transparence La transparence d’un robot est sa faculté à ne pas perturber le mouvement d’un utilisateur qui manipule son effecteur [Troccaz 2012]. Ainsi une tâche à réaliser à l’aide d’un outil sera effectuée de la même manière que l’utilisateur seul tienne l’outil ou que ce dernier soit également fixé à l’extrémité distale d’un robot présentant une transparence parfaite. Cela signifie que tous les paramètres de la tâche seront les mêmes, qu’ils soient objectifs ou subjectifs : temps de réalisation de la tâche, qualité de réalisation de la tâche, trajectoire de l’outil, efforts exercés par l’utilisateur sur l’outil, efforts exercés par l’outil sur son environnement, etc, voir [Jarrasse 2008]. Pour offrir une transparence satisfaisante, un robot doit donc présenter plusieurs caractéristiques qu’il convient de prendre en compte dès sa conception. Tout d’abord la masse en mouvement doit être la plus faible possible, afin de limiter les effets d’inertie. C’est pour cette raison que les bras d’Apollo ont été réalisés en carbone et que les moteurs ont été déportés au niveau de sa base. Ajoutons au passage que réduire les masses embarquées permet de limiter les efforts à générer en mode verrouillé et donc de diminuer les efforts demandés aux moteurs. Comme on l’a vu à la section 2.3, Apollo a de plus été conçu de façon à ce que la gravité ne génère pas de moment sur ses axes. Un robot transparent doit également présenter une grande réversibilité, c’est-à-dire qu’il doit être aisé de déplacer l’extrémité distale du robot à la main lorsqu’une commande nulle est envoyée aux actionneurs. Les systèmes type vis-écrou ou engrenages multi-étages ne présentent généralement pas cette caractéristique, c’est pourquoi la transmission entre les moteurs et les axes d’Apollo est assurée par un système de câbles visibles sur la figure 2.11. 3.1.2 Commande bas niveau 3.1.2.1 Transmission des vitesses et des efforts Déterminer la commande d’Apollo revient à définir la force que le robot doit exercer au centre P de son poignet. Afin de pouvoir effectivement contrôler le robot, il faut faire le lien entre cet effort et les couples articulaires. Le lien entre couples articulaires et effort généré au point P découle du modèle cinématique du robot :  VP,s/b ωs/b  =  Jv1,P 0 Jω1 Jω2  | {z } JP q˙ , (3.1)3.1. Mode libre 47 avec ˙q = θ˙ 1 ··· θ˙ 6 T le vecteur des vitesses articulaires, JP la matrice jacobienne 6×6 du robot au point P et Jv1,P, Jω1 et Jω2 des sous-matrices jacobiennes 3×3 exprimées dans le repère Rb, VP,s/b les composantes de la vitesse du point P par rapport à la base du robot dans le repère Rb, ωs/b les composantes du vecteur rotation de la sonde par rapport à la base du robot dans le repère Rb. La sous-matrice supérieure droite nulle indique que les vitesses articulaires des axes 4 à 6 n’ont aucun effet sur la vitesse du point P lié à la sonde par rapport à la base du robot. Ceci découle du fait que ce point soit situé à l’intersection des trois pivots constituant le poignet. Le robot étant équipé de butées, les singularités cinématiques se situent en-dehors de son espace de travail. De ce fait, on peut considérer que la matrice jacobienne JP est de rang plein. Grâce à la dualité cinémato-statique, la matrice jacobienne définie dans l’équation 3.1 permet également de relier le torseur d’effort exercé par le robot sur la sonde au point P aux couples articulaires τ = τ1 ··· τ6 T : τ = [τ1 τ2 τ3] T [τ4 τ5 τ6] T ! =  J T v1,P J T ω1 0 J T ω2  | {z } J T P  Fr→s MP,r→s  , (3.2) avec Fr→s les composantes dans Rb de la force et MP,r→s les composantes dans Rb du moment appliqués par le robot sur la sonde au point P. Les axes 4 à 6 étant équipés de freins, les couples articulaires τ4 à τ6 ne peuvent être modulés. Seuls pourront être commandés les couples moteurs τmoteurs = [τ1 τ2 τ3] T . On cherchera généralement à exprimer la commande sous la forme d’une somme : τmoteurs = [τ1 τ2 τ3] T = τcomp +τf onc , (3.3) avec τcomp les couples articulaires des trois premiers axes compensant les effets de la gravité et τf onc les couples articulaires des trois premiers axes permettant de réaliser la fonction voulue (par exemple le maintien en position de la sonde). 3.1.2.2 Compensation du poids de la sonde Réaliser la compensation des effets de la gravité n’est a priori pas absolument nécessaire : l’urologue est habitué à manipuler la sonde à la main, donc à ressentir son poids et son inertie. Néanmoins, il pourrait être intéressant de soulager le praticien des effets de la pesanteur sur la sonde. Cela pourrait contribuer à son confort, et nous chercherons à évaluer l’impact de cette compensation sur le geste proprement dit. Nous allons donc dans un premier temps exprimer τcomp les couples articulaires des trois premiers axes compensant les effets de la gravité sur la sonde échographique endorectale. Freins libres Une approche math´ematique pour la forme architecturale Ahmed Elshafei To cite this version: Ahmed Elshafei. Une approche math´ematique pour la forme architecturale. Hardware Architecture. Universit´e Paris-Est; Laboratoire G´eom´etrie, structure, architecture (Paris), 2014. French. . HAL Id: tel-01061095 https://tel.archives-ouvertes.fr/tel-01061095 Submitted on 5 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Paris-Est L’école doctorale VTT: ville, transport et territoires L’école nationale supérieure d’architecture Paris-Malaquais Laboratoire GSA: géométrie, structure et architecture Thèse de doctorat UNE APPROCHE MATHÉMATIQUE POUR LA FORME ARCHITECTURALE Doctorant: Ahmed ELSHAFEI Directeur de thèse de doctorat: Maurizio BROCATO | 12 | Pour ceux qui ne connaissent pas les mathématiques, il est difficile d’avoir un réel sentiment pour la beauté, la plus profonde beauté, de la nature ... Si vous voulez en apprendre davantage sur la nature, pour apprécier la nature, il est nécessaire de comprendre la langue qu’elle parle. R. Feynman | 3Résumé Au cours des deux dernières décennies avec la montée des ordinateurs et des logiciels de CAO dans l’architecture, il a été une fois de plus un intérêt croissant pour les mathématiques. Toutefois, cet intérêt a de nombreuses conséquences paradoxales. C’est parce qu’au cours des deux derniers siècles ces deux disciplines ont augmenté dans des directions presque opposées sur la compréhension de l’espace et des objets en elle. Cette recherche examine ces conséquences paradoxales, il part de l’hypothèse que les mathématiques modernes peuvent une fois de plus être la base de la compréhension de l’espace dans l’architecture. Cela signifie que toutes les constructions abstraites de la géométrie moderne serait l’outil pour comprendre, concevoir et manipuler l’espace architectural et les objets qu’elle contient. En prenant cette position de nombreuses questions se posent. Questions de technicité en termes de connaissances mathématiques à acquérir et questions de nature philosophique en termes de ce que cela signifie pour l’architecture de comprendre l’espace mathématiquement. Cette recherche examine ces deux dimensions de cette position, à savoir que d’une part il y a une construction mathématique complète des espaces et des objets en elle, couplés avec des réflexions philosophiques sur le sens de ces constructions dans l’architecture. À côté du formalisme mathématique, ces constructions sont également traduits en une série de programmes courts qui alors peuvent effectivement être utilisés comme outils de calcul et de visualisation. La recherche tente d’assembler divers fragments de différentes branches mathématiques en un seul corps du savoir mathématique qui est pertinente d’un point de vue de la conception architecturale, comprise dans huit chapitres. Le premier chapitre traite principalement les conséquences philosophiques de cette prise de position entre l’architecture et les mathématiques; expliquant le contexte de leur relation et éclairer la nature esthétique de la recherche. Dans le chapitre deux, nous essayons de préparer la fondation pour les constructions mathématiques, à savoir examiner la relation entre la géométrie et de la perception. Nous expliquons aussi la différence entre les espaces formels et physiques, et nous définissons formellement les notions de base de la spatialité en utilisant la topologie et enfin nous construisons le principal objet géométrique de la recherche, qui est la variété différentiable (en particulier à deux dimensions à savoir la surface). La logique de structuration des constructions mathématiques dans la recherche provient essentiellement de l’approche intuitive de la conception architecturale de définir d’abord une forme de base, puis appliquer des modifications. Par conséquent, nous avons deux parties générales des constructions mathé- matiques la première est la définition des formes et la deuxième partie est les opérations sur les formes. Dans le chapitre trois, nous donnons une explication de la différence entre nos deux types principaux de définitions de formes à savoir la définition paramétrique et la définition algébrique. Dans le chapitre quatre, nous donnons une explication sur les deux principales techniques de définitions de forme utilisés par les logiciels de CAO à savoir les meshes et les splines (en particulier les NURBS). Ceci est couplé avec une réflexion philosophique sur l’utilisation de logiciels de CAO et de sa relation à la connaissance géométrique, et sur une perspective plus large, la relation entre cette recherche et l’architecture numérique. Dans les trois chapitres suivants, nous définissons trois types d’opérations différentes qui peuvent être appliquées à des formes que nous avons définies, à savoir les opérations algébriques, analytiques et algorithmiques. Comme il ressort de leurs noms, ces opérations correspondent aux différentes branches de la géométrie: la géométrie affine (en particulier euclidienne) et la géométrie projective, puis la géométrie différentielle et enfin la géométrie combinatoire et computationnelle. Dans le chapitre cinq, l’accent est sur les opérations algébriques, nous commençons par expliquer les différents espaces en question et de passer ensuite la notion de la symétrie par lesquels ces différents types de géométrie sont constitués une dans l’autre (cf. programme d’Erlangen). Dans le chapitre six, nous nous concentrons sur la géométrie différentielle (en particulier des courbes et surfaces), avec une variété de résultats analytiques qui permet un large éventail d’outils et techniques de conception. Tous ces résultats sont couplés avec des exemples des conceptions architecturales élaborées à l’aide de ces calculs. Dans le chapitre sept nous déplaçons vers des opérations algorithmiques, qui sont divisés en deux parties: la première partie traite de géométrie combinatoire et computationnelle et la seconde porte sur les méthodes d’optimisation tels que les algorithmes génétiques. Nous concluons finalement la recherche au chapitre huit, dans lequel nous revenons une fois de plus à nos réflexions philosophiques. Nous prenons trois grandes idéologies en architecture à savoir, le fonctionnalisme, la sémiotique et la phénoménologie et essayer de voir comment cette recherche se rapporte aux leurs points de vue. 4 | Table des matières 1.Introduction 1.1. Objectif 1.2. Objectif et sa double nature 1.3. Changement de paradigme dans l’esthétique 1.4. Changement de paradigme en mathématiques 1.5. Disciplinarité, indisciplinarité et interdisciplinarité 1.6. Références 2. Géométrie et espace 2.1. Géométrie, la perception et l’expérience 2.2. Les espaces formels et variétés 2.2.1 Notions topologiques de base 2.2.2. Construction d’une variété 2.3. Références 3. Définition de la forme 3.1. Définition paramétrique de courbes et de surfaces 3.2. Familles de surfaces 3.3. Définition algébrique (non paramétriques) des courbes et des surfaces 3.3.1. Paramétrage de la surface algébrique 3.5. Références 4. L’ordinateur et la conception 4.1. Bref historique de la conception assistée par ordinateur 4.2. Modélisation de maillage polygonal 4.2.1. «Box modeling» et «winged edge data structure» 4.2.2. Conception en utilisant «box modeling» 4.2.3. La conception et la manipulation de la structure de données 4.3. Modélisation par interpolation 4.3.1. Interpolation polynomiale 4.3.2. Splines cubique et bicubique 4.3.3. Bézier et NURBS 4.3.4. Concevoir utilisant NURBS 4.4. Critique de la conception assistée par ordinateur 4.5. Concernant l’architecture numérique 4.6. Références | 55. Opérations algébriques 5.1. Construction des espaces vectoriel et affine 5.2. Symétrie et géométrie 5.3. La géométrie euclidienne vs l'arithmétique pythagoricienne en architecture 5.4. Géométrie affine et euclidienne 5.4.1. Définition du groupe 5.4.2. Transformations affines isométriques (i.e. transformation euclidienne) 5.4.3. Transformation affine non-isométrique 5.4.4. Projections orthogonales 5.4.5 Conception en utilisant la géométrie affine 5.5. Géométrie projective 5.5.1. Espace projectif et groupe projectif 5.5.2. Bref historique de la perspective 5.5.3. Points à l'infini 5.5.4. Construction de la perspective 5.6. Conception utilisant la géométrie affine et la géométrie projective 5.7. Références 6. Opérations analytiques 6.1. Bases de calcul différentiel 6.2. Géométrie différentielle des courbes 6.2.1. Définition d'une courbe régulière 6.2.2. Analyse d'une courbe régulière 6.2.3. Conception en utilisant l'analyse d'une courbe régulière 6.2.4. Tubes le long des courbes 6.2.5. Conception utilisant des tubes 6.3. Géométrie différentielle des surfaces 6.3.1. Calcul vectoriel 6.3.2. Définition d'une surface régulière 6.3.3. Analyse d'une surface régulière 6.3.3.1. Champs de vecteurs 6.3.3.2. Conception en utilisant des champs de vecteurs 6.3.3.3. Courbes intégrales et systèmes dynamiques 6.3.3.4. Conception en utilisant des courbes intégrales 6.3.3.5. Métrique riemannienne sur une surface régulière 6.3.3.6. Conception en utilisant la métrique riemannienne 6.3.3.7. Volume contenu par une surface régulière 6.3.3.8. Courbure d'une surface régulière 6.3.3.9. Conception en utilisant la courbure 6.3.3.10. Asymptotes dans une surface régulière 6.3.3.12. Courbes géodésiques dans une surface régulière 6.3.3.13. Courbes d'intersection entre les surfaces régulières 6.3.3.14. Conception en utilisant l'intersection entre les surfaces régulières 6.3.4. Surfaces spéciales 6.3.4.1. Surfaces non orientables 6.3.4.2. Conception en utilisant des surfaces non orientables 6.3.4.3. Surfaces réglées et développables 6.3.4.4. Conception en utilisant les surfaces réglées 6.3.4.5. Surfaces de révolution 6.3.4.6. Surfaces à courbure constante 6.3.4.7. Surfaces minimales 6.4. Références 6 | 7. Opérations algorithmiques 7.1. Dessin automatisé 7.1.1. Organisation interne 7.1.1.1. Circulation verticale 7.1.1.2. Séparation et la division de l'espace 7.1.1.3. Renflement et transition douce 7.1.2. Tâches répétitives 7.1.2.1. Opération géométrique répétée 7.1.2.2. Elément architectural répété 7.1.2.3. Génération des variants 7.1.3. Géométrie computationnelle 7.1.3.1. Problèmes de géométrie computationnelle (le paire la plus proche) 7.1.3.2. Motif computationnelle 7.1.4. Problèmes de géométrie combinatoire (pavage) 7.1.4.1. Pavage et l'architecture 7.1.4.2. Groupes ponctuels discrets et groupes de «wallpaper» 7.1.4.3. Conception en utilisant le groupe de «wallpaper» 7.2. Optimisation (méthode de recherche) 7.2.1. Problème d'optimisation 7.2.2. Conception et la science 7.2.3. Notions de base de la biologie évolutive 7.2.4. Optimisation en utilisant un algorithme génétique 7.2.5. Optimisation en utilisant la méthode de Monte-Carlo 7.3. Références 8. Qu'est-ce que l'architecture 8.1. Architecture 8.2. Idéologies architecturales dominantes 8.2.1. L'architecture comme fonction 8.2.2. L'architecture comme communication 8.2.3. L'architecture comme une expérience vécue 8.3. Références | 71.Introduction ü 1.1. Objectif Tout au long de l'histoire, l'architecture et les mathématiques ont été profondément liées, et même dans certaines périodes les deux disciplines étaient indiscernables, à savoir les architectes étaient aussi des mathé- maticiens et vice-versa. Cela était dû au fait que l'architecture offerts les mathématiques (qui, dans le monde antique était plein de symbolisme et de mysticisme) un moyen d'exprimer, visualiser et de manifester ces relations divines dans la pierre. Ceci peut être vu dans le monde antique de l'Egypte, la Grèce et Rome, les cathédrales médiévales de l'Europe et les grandes mosquées du monde islamique et tout le chemin à la Renaissance italienne. Tout au long de toutes ces périodes une relation intime entre la spiritualité et les mathématiques a été exprimé dans la relation entre la beauté et de l'architecture. Nous trouvons dans la Grèce antique, la philosophie pythagoricienne dont les adeptes (les pythagoriciens) comprenaient les mathématiques comme la base de toutes les choses physiques et métaphysiques, avec les nombres en son coeur. Au moyen âge, nous pouvons voir dans l'architecture de la cathédrale comment les mathématiques a été écrit dans la pierre; symbolisme provenant de relations géométriques divins sont dans presque tous les aspects de sa conception. Le nombre de piliers, la proportion de l'aménagement de la façade, jusqu'aux détails de la division de la rosace, tous expriment les relations géométriques divines avec d'importantes signification métaphysique que la personne médiévale comprise et appréciée. Dans la renaissance de la relation de l'architecture aux mathématiques a atteint son apogée avec la montée de l'humanisme et de la figure de l'homme de la Renaissance, hommes comme Léonard de Vinci et Albrecht Durer, qui a donné des représentations détaillées du corps humain et de sa relation à des proportions géométriques, en particulier le nombre d'or. D'autres, comme le maître de la Renaissance Andrea Palladio qui a proposé l'utilisation de séquences dans les dimensions des pièces dans ses célèbres Les Quatre Livres de l'architecture, et le polymathe Leon Battista Alberti qui consid- érait les mathématiques comme un fondement commun de l'art et de la science. Cependant, avec la montée du modernisme dans la culture occidentale à la fin du XVIIIe siècle, un changement de paradigme commençait un changement fondamental dans la pensée occidentale dans la philosophie, l'art et la science; à tel point que, pour comprendre toute discipline contemporaine nous devons extrapoler revenir à ce changement de paradigme [1]. En ce qui concerne la relation entre l'architecture et les mathématiques qui est au cœur de cette recherche, nous trouvons deux aspects importants de ce changement de paradigme est nécessaire de comprendre. Le premier est le changement de paradigme dans l'esthétique qui a conduit à une esthétique plus kantienne qui a porté sur l'œuvre d'art elle-même à la place de l'esthétique classique qui a été porté sur la nature. Le deuxième est le changement de paradigme en mathématiques qui a conduit à l'interprétation moderne de la géométrie avec l'accent uniquement sur le formel-logique à la place de l'ancienne interprétation de la géométrie qui nécessitait une connaissance a priori de ses objets (tels que des points, des lignes et des surfaces). Avec ce bref aperçu du contexte dans lequel nous nous trouvons aujourd'hui concernant l'architecture et les mathématiques, nous allons formuler l'objectif de la recherche montrant sa double nature et ses limites. L'objectif de cette recherche: Application de la géométrie moderne en architecture dans le sens de fournir une approche mathématique formelle pour la conception de formes architecturales et à la compréhension de l'espace. Avec ce dit, nous allons maintenant montrer quelques points importants concernant la nature de cet objectif, ses limites et les difficultés qu'elle implique, après que nous nous concentrerons sur le contexte dans lequel nous nous trouvons lorsque vous faites une telle recherche. Cette idée contextuelle serait donné par faire la lumière sur la relation entre l'architecture contemporaine et les mathématiques, une relation qui a été défini principalement par le changement de paradigmes dans l'esthétique et les mathématiques. 8 | ü 1.2. Objectif et sa double nature Cet objectif a par définition une nature double et presque paradoxal: d'un côté, il est tout à fait pratique d'apporter une base mathématique à la génération de forme dans l'architecture, ce qui permettra un meilleur contrôle et une compréhension des formes, pour ne pas mentionner un terrain commun mieux adapté pour la correspondance avec les ingénieurs et les conseillers techniques. D'autre part la géométrie moderne est assez loin dans son abstraction et son formalisme de la géométrie descriptive traditionnelle que les architectes connaissent, avec des notions comme des variétés, et la topologie qu'il serait presque absurde du point de vue de l'architecture d'avoir un tel niveau d'abstraction qui n'est pas nécessaire; ici nous rencontrons l'autre côté fondamental de la recherche qui est le côté esthétique. En un mot, l'objectif de la recherche du début à la fin contient deux motivations adverses: une motivation pratique et une esthétique. Avec ce dit, nous nous trouvons dans une position particulière en soulevant de nouveau la question de l'architecture et les mathématiques dans nos temps modernes. Cette particularité vient du fait que, même si l'intérêt de l'architecture en mathématiques reste encore tout à fait clair, il n'y a pas de cadre contextuel approprié pour héberger une telle question de manière scientifique; ceci est l'une des premières limites de la recherche. Il n'est pas un corps important des recherches en combinant les deux disciplines à partir de laquelle nous pouvons avoir assez de ressources ou de points de départ, les deux disciplines ont été assez séparés depuis au moins deux siècles. Il existe bien sûr de la recherche en architecture orientée vers la géométrie mais l'objectif principal est la génération de forme et beaucoup moins concentrer sur la construction formelle abstraite, et il y a la recherche en mathématiques qui ne se rapporte pas beaucoup aux disciplines artistiques comme l'architecture. Ainsi, afin de surmonter cette limitation, nous devions aller et extraire les constructions formelles issus des mathématiques et puis essayer de les assembler de la manière la plus cohérente possible du point de vue de l'architecture. Ceci peut être vu dans la structure de la recherche qui est divisé en définitions des formes, puis les opérations (algébriques, analytiques et algorithmique) sur ces formes, cette logique ne vient pas de mathématiques, mais plus de l'architecture; car, dans l'architecture, nous commençons naturellement par une forme de base, puis nous modifions et développons avec le processus de conception. Une autre limitation qui nous avons rencontré dans cette recherche est que les notions géométriques qui sont d'intérêt contemporain dans la conception architecturale, à savoir les sujets concernant courbure, géodésiques entre autres, sont assez intuitive du point de vue de l'architecture architectural; mais ils sont des sujets assez avancés dans la géométrie moderne. Cela signifie que leur construction formelle nécessiterait un niveau avancé de connaissances mathématiques et un nombre important de constructions mathématiques qui y mènent. Encore une fois cette limitation a été surmontée par l'extraction de ces concepts et toutes leurs constructions issus des mathématiques et de les assembler de manière cohérente qui peut être pédagogique du point de vue architectural; mais cela est venu au coût que le niveau mathématique de la recherche a également été soulevée. Ces deux limitations et en particulier la première nous offre un aperçu du contexte problématique de la recherche et nous montre que cette recherche combinant géométrie et l'architecture ne peut jamais être simplement une recherche scientifique dans le sens de l'ingénierie ou les sciences naturelles, car une grande partie de sa motivation est l'appréciation esthétique. Cela conduit à la conclusion que faire une telle recherche est un acte esthétique, le mot esthétique est ici essentiel et nous expliquer son importance plus tard. Le produit final est donc un objet esthétique sur trois niveaux différents d'appréciation esthétique. Nous avons d'abord l'esthétique austère des constructions mathématiques formelles; deuxièmement les conceptions architecturales avec leur esthétique plus accessible et enfin l'acte de utiliser ces constructions mathématiques dans la conception architecturale avec sa dimension poétique. En plus des constructions mathématiques formelles, il y a le codage numérique de ces constructions qui nous permettent de calculer et d'analyser des informations sur les formes; ce qui donne la recherche sa dimension intrinsèquement pratique. Cette dualité entre la motivation esthétique et une pratique est une caractéristique fondamentale non seulement de cette recherche, mais de la discipline architecturale en général. Maintenant que nous avons mentionné l'importance de cette dualité entre l'esthétique et la pratique dans cette recherche, nous avons besoin de comprendre précisément ce que nous entendons par un objet esthétique; et ce qui fait que l'utilisation des construction mathématiques dans la conception architecturale avoir une dimension poétique. Donc, nous allons donner deux brefs récits sur ces changements de paradigme, ce qui nous permettra d'expliquer la dimension poétique de travailler entre disciplines. | 9ü 1.3. Changement de paradigme dans l'esthétique Bien sûr, nous n’allons pas donner un exposé complet sur l’esthétique moderne qui pourraient faire l’objet d’une recherche complète par elle-même, à la place, nous allons nous concentrer ici sur quelques idées clés de l’esthétique moderne qui pourraient être utiles pour nous plus tard, quand nous parlons de la poétique de la connaissance. En résumé, l’esthétique moderne commence autour du XVIIIe siècle avec les travaux de penseurs allemands et britanniques qui ont souligné la beauté comme l’élément clé de l’art et celui de l’expérience esthétique et vu l’art comme nécessairement visant à la beauté absolue. Le premier à utiliser le terme «esthétique» dans son sens moderne était le philosophe allemand A.G.Baumgarten pour qui, l’esthétique est la science de l’expérience des sens, plus proche de la logique et de la beauté est donc la forme la plus parfaite de la connaissance que l’expérience de sens peut avoir. Un des récits les plus cruciales et les plus influents sur l’esthétique est celle de Kant dans son livre Critique du jugement, à savoir sa formulation du jugement esthé- tique et sa conception du sublime; qui, selon Jean-François Lyotard est essentiel pour l’art moderne. Kant se trouve en plein milieu d’un changement historique complet dans le point central de l’esthétique; avant Kant, l’esthétique a pris ses principaux exemples de la beauté et de la sublimité de la nature, après Kant l’accent est porté sur l’œuvre d’art elle-même. Ceci est crucial pour nous, car c’est précisément à partir de ce point que les mathématiques et l’art démarrer leurs trajectoires divergentes modernes; qui donne toute tentative de les réunir une position presque paria. Avec le déplacement de la valeur esthétique d’une œuvre d’art de la nature (comme la manifestation de l’harmonie divine) à l’œuvre elle-même, les artistes ont perdu leur intérêt pour les mathématiques qui a toujours été considéré comme la langue dans laquelle le divin a créé la nature. Et ils se sont concentrés davantage sur leur propre vision du monde, leur psychologie et perceptions; menant vers l’art contemporain, où il n’y a absolument pas de cadre de référence objectif pour juger la valeur du travail. Malgré cette position apparemment non universel en ce qui concerne la valeur esthétique d’une œuvre, Kant considère l’expérience esthétique de la beauté comme un jugement de la vérité subjective, mais encore universel; puisque tous les gens devraient conviennent qu’un certain rose est belle mais la beauté ne peut pas être réduit à un ensemble de base des caractéristiques de cette rose. Cette notion de «subjective pourtant universel” est également essentielle, car elle nous sauve de l’attitude réductrice de dire «tout est permis» et nous donne une compréhension de la notion kantienne du jugement esthétique. Dans le cadre de cette recherche, nous avons deux motivations pour comprendre le compte de Kant du jugement esthétique, Tout d’abord, le jugement esthétique est au cœur du processus de conception architecturale, même lorsque les architectes utilisent un raisonnement pratique derrière leur préférence d’une certaine forme sur une autre, il reste dans le domaine du jugement esthétique. La deuxième motivation vient de la nature de indisciplinaire de cette recherche (indisciplinaire ici est dans le sens du concept de Jacques Rancière de la poétique de la connaissance), qui repose principalement sur le compte kantienne du jugement esthétique. Maintenant, nous allons donner une brève explication du jugement esthétique de Kant. Dans la Critique du jugement, Kant définit jugement comme la subsomption d’un particulier sous un universel. Si l’universel est la faculté de comprendre, qui fournissent des concepts. et la raison est celle qui tire des conclusions, alors le jugement sert d’intermédiaire entre l’entendement et la raison en permettant des actes individuels de subsomption. Cela conduit à une distinction entre les jugements déterminés et réflexifs. Cependant, dans les jugements réflexifs, le jugement doit procéder sans concept, parfois dans le but de former un nouveau concept; Kant met le jugement esthé- tique dans la catégorie de jugement réflexifs [2]. Ici, nous pouvons voir clairement que l’opposition entre les arts et les mathématiques ne sont pas simplement une distinction entre les jugements universels et particuliers. Mais plutôt, que dans l’art les concepts universels ne peuvent pas déterminer un jugement sur le cas particulier d’une manière directe comme ils le font dans les mathématiques et les sciences en général. Bien sûr, cela est dû au déplacement de la valeur de l’art de la nature à l’œuvre elle-même. L’architecture a une place particulière dans cette distinction des jugements déterminés et réflexifs, car dans certains domaines, l’architecture peut fonctionner en utilisant un jugement déterminant, par exemple sur les aspects techniques. Néanmoins, le jugement global en architecture est réflexive, car il ne peut pas être obtenue directement à partir de concepts universels. Que notre contexte est artistique ou scientifique, presque immédiatement une question se pose sujet de la convenance de la nature au notre jugement, Kant soutient ce principe de convenance et il l’appelle la finalité ou la détermination de la nature au notre jugement. Il ajoute que sans ce principe, la science ne serait pas possible, comme toutes les sciences doivent assumer la disponibilité de ses objets pour notre jugement. De même, sans un tel principe nos jugements sur la beauté ne serait pas exposer la communicabilité, ou 10 | serait pas possible, comme toutes les sciences doivent assumer la disponibilité de ses objets pour notre jugement. De même, sans un tel principe nos jugements sur la beauté ne serait pas exposer la communicabilité, ou la tendance à l’universalité même en l’absence d’un concept, ce qu’ils font. Le problème de le jugement est d’une grande importance, puisque, pour Kant, le jugement sert d’intermédiaire entre deux branches de la philosophie, la philosophie théorique mettant l’accent sur la connaissance de la nature sensible et la philosophie pratique mettant l’accent sur la possibilité d’une action morale et sur la nature sensible. Kant constate un problème dans notre faculté de raisonner contre elle-même, puisque dans son emploi théorique, la raison exige absolument la soumission de tous les objets à la loi, mais dans son utilisation pratique, raison exige également la possibilité de la liberté. Kant résout ce problème en utilisant l’idéalisme, à savoir chaque objet doit être conçu de manière double: d’abord comme une apparition, sous réserve de la compétence nécessaire de certains concepts de base et les formes de l’espace et le temps, d’autre part, comme une chose en lui-même, dont plus rien ne peut être dit. Nous allons utiliser cet idéalisme kantien dans cette recherche quand nous allons décrire les objets géométriques. À savoir qu’il y a effectivement deux façons de concevoir une forme géométrique, son apparence physique que ce soit représentée graphiquement ou construit comme un objet du monde physique et sa description mathématique qui nous allons considérer que l’objet en lui-même. Nous allons traiter cette question dans le chapitre suivant sur l’espace et la géométrie, pour l’instant nous revenons à la définition de Kant du jugement esthétique, et montrer comment la position de cette recherche se rapporte à elle. Kant affirme que les jugements esthétiques (ou jugements de goût) doivent avoir quatre principales caractéristiques distinctives. D’abord, ils sont désintéressés, ce qui signifie que nous prenons plaisir à quelque chose parce que nous jugeons que c’est beau, plutôt que de juger que c’est beau, parce que nous trouvons agréable. Deuxièmement, ils sont universels, ce qui signifie en gros que c’est une partie intrinsèque de l’activité d’un tel jugement d’attendre que les autres sont d’accord avec nous. Troisièmement, elles sont nécessaires, la beauté se comporte comme si elle était une propriété réelle d’un objet, comme son poids ou sa composition chimique. Enfin, de beaux objets semblent être utile sans but (parfois traduit comme définitive sans fin) [3]. Nous expliquons maintenant que ces quatre caractéristiques du jugement esthétique de Kant pourrait être trouvée dans la position de cette recherche; tout d’abord il est désintéressé, car il prend plaisir à l’emploi des constructions mathématiques dans la conception simplement parce qu’il juge que c’est beau, et pas dans l’autre sens. Deuxièmement, il prend une position universelle de la beauté de cet emploi, et ne dit pas qu’il est seulement belle personnellement. Troisièmement, il a un caractère nécessaire, et enfin le résultat final de cette recherche ne semble utile sans but. Après avoir défini les quatre critères de du jugement esthétique, Kant porte à décrire l’expérience esthétique. Il affirme que, comme l’expérience naturelle, l’expérience esthétique qui conduit à un jugement déterminant est explicable que à l’aide d’une dimension intuitive et conceptuelle qui signifie que la beauté est cognitive. Le deuxième type de base de l’expérience esthétique de Kant est le sublime, le sublime décrit des expériences qui nous accablent et nous donnent le sentiment que nous ne pouvons pas les saisir pleinement. Le deuxième type de base de l’expérience esthétique pour Kant est le sublime, le sublime décrit des expériences qui nous accablent et nous donnent le sentiment que nous ne pouvons pas nous saisir pleinement. Le sublime est un concept essentiel dans la compréhension de l’art moderne où il y a eu un changement clair de la beauté au sens classique de la beauté qui a vient de l’effet écrasant. La plupart de l’art contemporain, vise à assurer sous une forme ou une autre un sentiment être bouleversé par le travail au lieu de pleasured par sa beauté harmonieuse. Ce sentiment d’être bouleversé par le travail est la caractéristique récurrent dans presque tout l’art contemporain, son but est de choquer l’observateur. La question de savoir si c’est légitime ou pas est un autre débat. Nous nous intéressons ici au compte de Kant sur le sublime, puisque l’architecture contemporaine tombe ainsi dans cette tendance pour le choquant et l’écrasante. Ceci peut être vu en particulier dans le nouveau mouvement de l’architecture numérique et son appétit croissant pour les conceptions de plus en plus choquantes. Kant divise le sublime en deux types: la mathématique et de la dynamique. Si notre capacité de l’intuition est accablé par taille, comme un immense bâtiment, ce serait une expérience sublime mathématique et si notre capacité de vouloir ou de résister est accablé par la force, comme une énorme tempête, ce serait une expérience sublime dynamique. Kant soutient que ce qui est sublime n’est pas du tout l’objet, mais nos idées de la raison: à savoir les idées de la totalité absolue dans le sublime mathématique et la liberté absolue dans le sublime dynamique. Toutefois énorme est le bâtiment, ou puissante est la tempête, ils ne sont rien par rapport à la totalité absolue et la liberté absolue, le sentiment sublime est donc une alternance rapide entre la crainte de l’écrasante et le plaisir particulier de voir ce écrasante accablé [4]. Maintenant, nous allons diriger notre attention vers une autre notion kantienne important que l’idée esthétique; ce qui est crucial pour nous dans cette recherche en raison de sa position entre | 11ce écrasante accablé [4]. Maintenant, nous allons diriger notre attention vers une autre notion kantienne important que l’idée esthétique; ce qui est crucial pour nous dans cette recherche en raison de sa position entre l’art et la science et la dualité de l’esthétique et le pratique. Après avoir défini l’esthétique et la sublime Kant se tourne vers la définition de l’art et sa relation avec ses concepts de l’idée esthétique et le génie. Kant croit que le cognition part à l’évaluation des beaux-arts est similaire à la cognition part à l’évaluation beauté naturelle et que ce qui donne âme aux beaux-arts est l’idée esthétique et que le talent du génie est de produire des idées esthétiques. Une idée esthétique est une contrepartie à l’idée rationnelle: si celui-ci est un concept qui ne pourrait jamais être exposé de manière adéquate sensiblement, le premier est un ensemble de présentations sensibles à laquelle aucun concept est suffisante [5]. Ainsi l’art pour Kant se réfère à l’activité de fabrication selon une notion qui précède, si je fais une chaise, je dois savoir à l’avance ce une chaise est, qui le rend différent de la nature; étant donné qu’une ouverture de la fleur se passe sans notion préalable de l’ouverture par la fleur. Il différencie aussi l’art de la science, l’art est une compétence distingué d’une connaissance de type, une capacité pratique irréductible à des concepts déterminés, qui se distingue d’une simple compréhension de quelque chose. La science peut être enseignée, tandis que l’art bien que soumis à la formation, il s’appuie sur le talent natif. Ainsi, pour Kant, il n’y a aucune telle chose comme un génie scientifique, parce qu’un esprit scientifique ne peut jamais être radicalement originale, c’est-à-dire que les icônes scientifiques comme Isaac Newton et Albert Einstein sont des génies artistiques dans le domaine de la physique. Nous pouvons accord ou en désaccord avec l’affirmation de Kant, mais ce qui est important de comprendre ici, c’est le sentiment qu’il vise, à savoir qu’il essaie de montrer que l’esthétique n’est pas seulement limitée aux disciplines de l’art comme dans le sens classique du terme. Mais il s’agit plutôt d’un concept plus large et générale plus liée à l’originalité et la créativité dans notre pensée quelle que soit notre domaine de travail. Ceci est encore pertinente dans le contexte de cette recherche puisque, par définition, nous essayons de faire des objets esthétiques en utilisant le langage de la science à savoir les mathématiques; et nous n’avons pas à notre disposition la dimension mystique harmonieux global unifiant art et la science comme à l’époque classique. Kant ici est en quelque sorte rassurant pour nous une valeur esthétique à l’œuvre sur la base de son concept de l’idée esthétique à la place de l’esthétique classique. Cette esthétique kantienne et le rapport de l’art à la science marque le début du changement de paradigme moderniste de l’esthétique (de la nature à l’œuvre d’art elle-même). Qui d’une part signale la disparition des figures des polymathes de la Renaissance et le divorce entre l’art et la science, mais d’autre part ouvre une nouvelle façon de penser entre les disciplines, notamment scientifiques et des disciplines artistiques. Le passage de l’esthétique antique et médiévale où l’harmonie des proportions et la symétrie sont fondamentales et où les mathématiques avec ses pouvoirs mystiques ont trouvé une maison naturelle en architecture à l’esthétique moderne kantienne, signifiait que le rapprochement de l’art et de la science aurait besoin d’un nouveau cadre de travail conceptuel : indisciplinarité. Ce concept n’est pas un concept kantien par défaut, mais un concept développé par le philosophe français Jacques Rancière, qui sera essentiel pour nous de comprendre davantage l’esthétique de la position de la recherche entre l’art et la science. Nous allons faire face à cette situation lorsque nous allons expliquer la poétique du travail entre disciplines, à savoir, dans ce contexte les mathématiques et l’architecture. Pour le moment, après avoir décrit le changement de paradigme dans l’esthétique de la perspective kantienne, nous allons décrire un également important changement de paradigme, c’est le changement de paradigme en mathématiques. 12 | ü 1.4. Changement de paradigme en mathématiques Il semble maintenant que ce sont les artistes qui ont perdu l’intérêt pour les mathématiques avec le changement de la valeur esthétique de la nature à l’œuvre d’art elle-même, mais ce n’est qu’un côté de l’histoire. Il y a eu une perte égale mutuelle d’intérêt de la part des scientifiques et surtout les mathématiciens en métaphysique ou plus précisément l’ontologie de la science. On peut dire que la science moderne et les mathématiques modernes comme nous les connaissons ont commencé aussi à ce moment-là, où le sens et le symbolisme ont été purgés de leurs domaines, ne laissant que la logique formelle et les expériences positivistes que leurs seuls sujets. Cela permettra également de jouer un rôle également crucial que le changement de l’esthé- tique dans l’histoire de l’art et de la science, et par conséquent toute tentative moderne de les réunir. Après avoir discuté le changement de paradigme dans l’esthétique, nous allons maintenant discuter du changement de paradigme en mathématiques à savoir l’interprétation ancienne et moderne de la géométrie. Avant d’entrer dans les détails de cette ancienne et moderne distinction, nous allons montrer intuitivement quel est le problème et comment il se rapporte à l’architecture. Quand on pense à des mathématiques en architecture immédiatement on pense à des applications pratiques, par exemple, des calculs de structure, qui est tout à fait justifié mais ce n’est pas la principale contribution des mathématiques à l’architecture ou de l’intellect humain en général pour cette question. Ce que se passe avec les mathématiques est quelque chose de vraiment remarquable d’un point de vue philosophique, à savoir, que c’est seulement par l’utilisation d’un système de symboles et de relations logiques que nous sommes en mesure de créer des représentations de phénomènes physiques. Cela semble tout à fait naturel pour nous, car nous sommes habitués au fait que les mathématiques peuvent décrire le monde physique, mais si nous prenons un peu de recul et de penser, ce n’est pas du tout évident que ces deux mondes des phénomènes et l’esprit humain peuvent être liés si étroitement. Dans les temps pré-modernes, il a été tout simplement compris que les mathématiques avaient une signification mystique et par le savoir nous se rapprochent de la divine. Cela a fonctionné parfaitement pour l’art et l’architecture depuis les mathématiques et la géométrie en particulier leur a donné la langue par laquelle l’artiste pourrait manifester l’esthétique classiques basés sur la nature. Mais avec la modernité, cette harmonie globale est détruite et comme nous avons décrit dans le changement de paradigme dans l’esthétique, l’art et les mathématiques n’étaient plus compatibles. Cela a laissé la question de savoir comment les mathématiques décrits si parfaitement le monde physique grande ouverte. En fait, ce problème est tout à fait un vieux problème et il ne se limite pas à l’architecture, mais à la physique et les sciences exactes et naturelles en général; cette question sur la géométrie et l’expérience a été soulevée par Albert Einstein dans sa conférence devant l’Académie des sciences de Prusse en 1921. Ce problème est bien sûr un problème métaphysique car du point de vue scientifique moderne, la question de savoir pourquoi les mathématiques décrit la réalité est moins important que comment nous pouvons utiliser les mathématiques pour décrire la réalité. Ayant fait ce constat, nous n’allons pas tenter de répondre à cette question, qui peut faire l’objet d’une thèse par lui-même. Mais nous allons diriger notre attention sur comment en soulevant cette question Albert Einstein montre l’évolution des mathématiques de l’ancienne à la nouvelle interprétation de la géométrie. C’est en quelque sorte encore plus important dans notre contexte que la question elle-même, puisque dans plusieurs façons l’un des principaux obstacles entre l’architecture et les mathématiques aujourd’hui est due à la différence entre l’ancienne et la nouvelle interprétation de la géométrie. Einstein a demandé comment se pourrait-il que les mathématiques, étant après tout un produit de la pensée humaine qui est indépendante de l’expérience, est admirablement adapté aux objets de la réalité? Est la raison humaine, alors, sans expérience, simplement en prenant la pensée, capable de sonder les propriétés des choses réelles? Sa réponse a été très bref: En ce qui concerne les propositions des mathématiques se réfèrent à la réalité, ils ne sont pas certains, et dans la mesure où elles sont certaines, elles ne se réfèrent pas à la réalité [6]. Einstein a ensuite continué à clarifier sa réponse en faisant référence à la montée de l’axiomatique comme une branche des mathématiques, ses progrès dans la séparation de la logique formelle de mathématiques de son contenu intuitif ou objectif. Cela a été en parallèle avec l’essor de la science positiviste qui est venu à être compris comme la seule interprétation légitime de la réalité, éliminant tout besoin pour la métaphysique et de provoquer le divorce entre la foi et la raison et par conséquent l’art et la science. Les mathématiques qui a été considéré par les anciens philosophes jusqu’à ce que les polymathes de la Renaissance comme Alberti la base pour les arts et les sciences ont dû subir une transformation fondamentale. Une transformation à faire être capable d’être le langage de la science positiviste moderne, elle devait être purgé de tout symbolisme métaphysique, devenant ainsi une discipline purement | 13mation fondamentale. Une transformation à faire être capable d’être le langage de la science positiviste moderne, elle devait être purgé de tout symbolisme métaphysique, devenant ainsi une discipline purement formelle dépourvue de sens mystique. Comme précisé Einstein, selon axiomatique, que la logique formelle constitue l’objet des mathématiques, qui n’est pas concerné par l’intuitif ou tout autre contenu non associé. Cette nouvelle interprétation des mathématiques et de l’émergence de la géométrie moderne ont eu un impact fondamental sur l’architecture et sa relation avec le reste des beaux-arts. Alberto Perez Gomez explique dans son livre Architecture et la crise de la science moderne que la purge des mathématiques de tous les sens externe ou valeur a forcé l’architecture à une situation difficile, une existence de scission entre le couple science et l’art moderne, récemment divorcé. C’était parce que la géométrie, qui est l’outil fondamental pour la conception architecturale, a dû abandonner son “caractère sacré” et tout le bagage symbolique, il portait avec lui, afin d’évoluer dans une discipline scientifique moderne appropriée. Cette géométrie moderne purgé de toute signification est précisément la géométrie que nous allons utiliser dans cette recherche; construit à partir de la logique purement formelle sans nécessairement de rapport avec les mondes physiques ou symboliques. Nous allons montrer en détail plus loin comment cette constructions formelles de l’objet géométrique et de les utiliser dans des conceptions architecturales a une dimension poétique, ce qui n’est pas basée sur le symbolisme mystique comme ce fut le cas dans les périodes pré-modernes. Mais nous devons d’abord revenir à l’explication d’Albert Einstein de l’ancienne et la nouvelle interprétation de la géométrie. Albert Einstein a expliqué la différence entre l’interprétation ancienne et moderne de la géométrie en donnant un exemple de l’axiome: par deux points dans l’espace, il passe toujours un et un seul ligne droite. Dans l’ancienne interprétation cela sera considéré comme vrai en raison de son évidence, ce qui signifie qu’il fait partie d’une connaissance a priori ce qui est une ligne et ce qui est un point. Dans l’interprétation moderne, que la validité de l’axiome est supposé sans avoir besoin d’une connaissance a priori sur les objets: la ligne et les points (i.e. axiomes sont considérés comme des définitions implicites, Schlick: épistémologie). Cependant la géométrie est née de la nécessité d’étudier le comportement d’objets réels et cela ne peut être fait en utilisant uniquement le système de la géométrie axiomatique, comme il ne peut pas faire des affirmations sur le comportement des corps réels. Pour être capable de faire cela, nous devons ajouter la proposition: les corps solides sont liés par rapport leurs dispositions possibles, de même que les organismes dans la géométrie euclidienne à trois dimensions. Einstein appelle cela: la géométrie pratique complété par opposition à la géométrie purement axiomatique et il ajoute que toutes les mesures de longueur en physique, y compris les mesures de longueur géodésiques et astronomiques constituent la géométrie pratique en ce sens, si l’on utilise la loi empirique que la lumière se propage en ligne droite , et même en ligne droite dans le sens de la géométrie pratique [6]. Il est clair que tandis que les physiciens et les ingénieurs ont adopté l’interprétation moderne de la géométrie purement axiomatique, qui est ensuite complété dans la géométrie pratique. Les architectes s’approprient l’ancienne interprétation de la géométrie, ce qui a donc conduit à une compréhension des formes basées sur nos sens et de la perception. Dans un sens, cela est tout à fait compréhensible puisque, après tout pourquoi un architecte va passer du temps sur la compréhension des espaces abstraits qui sont dans la plupart des cas pas possible de visualiser, tandis que le seul espace qui est en fait un intérêt architectural est l’espace euclidien à trois dimensions. Et cet espace euclidien et sa géométrie euclidienne peuvent être totalement compris en utilisant l’ancienne interprétation de la géométrie, à savoir que tous les objets sont comprises aussi comme des objets physiques qui peuvent être soit dessinés ou construits. Cependant il y avait un prix, l’architecture a dû payer pour s’en tenir à la simplicité de l’ancienne interprétation, à savoir que l’écart entre l’architecture et les mathématiques a augmenté au point les architectes d’aujourd’hui ont près de zéro idées de ce que la géométrie moderne est. Encore une fois ce ne serait pas du tout un problème si les architectes ont juste rester avec leur ambition de conception dans la tradition euclidienne, ce qui n’est pas le cas. Si quoi que ce soit il y a un appétit toujours croissante dans l’architecture contemporaine pour les constructions géométriques complexes, et pour des concepts abstraits qui ont développé au cours des trois cents ans en mathématiques. Et dont l’architecture n’a pas de n’importe quelle manière exhaustive intégrée dans son discours, qui est resté fondamentalement fidèle à l’ancienne interprétation de la géométrie.Dans cette recherche, nous allons tenter une nouvelle fois de mettre à jour l’architecture avec la géométrie moderne, à savoir d’accueillir ces constructions provenant des mathématiques modernes dans la conception architecturale. Et d’une façon essayer de voir quelles pourraient être les possibilités pour l’interprétation moderne de la géométrie dans l’architecture. 14 | ü 1.5. Disciplinarité, indisciplinarité et interdisciplinarité Nous verrons par la suite que, pour comprendre cette dimension poétique nous nous appuierons sur le compte de Kant sur l’esthétique que nous avons mentionné ci-dessus. Pour cela, nous allons maintenant remettre en question la distinction entre la disciplinaire, indisciplinaire et interdisciplinaire, à travers le travail de Rancière sur la poétique de la connaissance. Cette recherche envisage les possibilités et les conséquences de l’adoption de l’interprétation moderne de la géométrie dans la conception architecturale comme un acte esthétique; il demande quel est-il de concevoir l’aide de la connaissance de l’espace tel qu’il est compris par les mathématiques modernes? Quel type d’un objet esthétique peut sortir de cet acte? Le mot esthétique est ici crucial, car le produit n’est pas une conception architecturale, ni un article mathématique ou philosophique, il n’est pas non plus simplement une boîte à outils d’ingénierie ni un aperçu historique sur l’architecture et la géométrie, et pourtant il touche l’ensemble de ces territoires, d’où son caractère esthétique. Cette attouchements entre ces différents territoires, n’est pas simplement de les mélanger dans une sorte de mélange interdisciplinaire, mais cette recherche pourrait être considérée comme une famille de ponts (pour utiliser la métaphore de Rancière) qui relient ces territoires distincts ensemble. Il est important de comprendre que ce travail ne vise pas en tout cas de créer une discipline hybride entre l’architecture et les mathématiques, ou à déterritorialiser des concepts géométriques dans l’architecture et de leur donner une nouvelle signification. En fait cet acte de déterritorialisation des concepts est l’une des principales critiques que nous avons contre l’architecture numérique, sur lequel nous aurons une analyse plus approfondie plus loin dans la recherche. Au contraire, nous insistons sur la présentation des concepts mathématiques en utilisant leur langage propre à aucune tentative pour abus de langage; avec certains schémas et textes pour les expliquer au lecteur non mathématiquement qualifié. En d’autres termes cette recherche peut être considérée comme ce que le philosophe français Jacques Rancière appelle un travail indisciplinaire, une esthétique de connaissances résultant de la pensée entre les disciplines. Selon Rancière de parler d’une dimension esthétique de la connaissance est de parler d’une dimension de l’ignorance qui divise l’idée et la pratique de la connaissance eux-mêmes [7]. Rancière affirme que la multiplicité est essentielle pour la construction de ces ponts entre les disciplines. Cette notion d’ignorance est aussi d’une grande importance dans ce contexte, car au contraire de ce que nous pensons intuitivement que la maîtrise de deux disciplines mène à la maîtrise de leur somme, la réalité est plus subtile; à savoir en allant plus profondément dans deux territoires déconnectés le résultat est la maîtrise d’aucun d’eux. C’est parce que d’une certaine manière en creusant dans le nouveau territoire une certaine ignorance de l’autre territoire grandit avec elle, en d’autres termes, si l’on peut être bien formés dans deux disciplines, on a aussi deux ignorances sur ces deux disciplines qui viennent avec cette formation. Dans la partie qui suit, nous allons montrer comment Rancière explique cette notion d’ignorance et les ponts entre les disciplines. Selon Rancière les disciplines forment une orthodoxie d’un côté de l’eau sans avoir à ouvrir la possibilité pour d’autres connaissances de l’autre côté, néanmoins, quand on est le pont, on touche les deux côtés sans appartenir à l’un d’eux. Il ajoute que, avec ce pont, les deux parties deviennent égaux et peuvent être atteints et que indisciplinarité est l’espace signifiant textuel dans lequel le pont d’un mythe à l’autre est visible et pensable, contrairement à l’interdisciplinarité, qui est tout simplement intensifie d’une discipline pour un autre. La valeur esthétique d’une œuvre indisciplinarité n’est pas simplement la somme des valeurs de chacune des disciplines comme c’est le cas de l’interdisciplinarité, mais plutôt l’esthétique de la création d’un pont entre les disciplines. Cette valeur esthétique est créé par la double négation que le travail n’est pas limitée dans le territoire de l’une des disciplines, d’où il évite les orthodoxes dogmatiques, les frontières que les disciplines tentent de défendre. Dans la Critique du jugement, Kant explique que la double négation constitue l’expérience esthétique l’aide d’un certain déconnexion des conditions habituelles de l’expérience sensible [7]. Ainsi, dans un sens kantien, cette recherche est présentée comme un objet d’appréhension esthétique qui est caractérisée comme ce qui n’est ni un objet de connaissance, ni un objet de désir et apprécié comme une forme sans concept. Tout cela semble un peu abstrait, mais au fond il est une idée simple, à savoir que l’architecture et les mathématiques comme toute autre discipline forment une certaine défense contre les autres à l’aide de l’orthodoxie pour protéger son mythe. Ce mythe n’est pas visible de l’intérieur de la discipline, il n’est visible que lorsque l’on s’engager entièrement dans une autre discipline, en gagnant un point de vue depuis le pont entre les disciplines qui est essentiellement poétique, car il expose ces mythes. En mythe ici on n’entend pas faux, mais ce que les gens dans une certaine discipline, se soucient profondément. Ce serait la même si cette sphère a été construit à partir d’acier ou de béton, serait d’une grande importance pour l’architecte et presque pas d’importance pour | 15gens dans une certaine discipline, se soucient profondément. Ce serait la même si cette sphère a été construit à partir d’acier ou de béton, serait d’une grande importance pour l’architecte et presque pas d’importance pour le mathématicien, même si dans les deux exemples les deux ont travaillé sur la même forme géométrique: la sphère. Cela peut nous donner une meilleure compréhension de ce que nous entendons par le mythe créé par une discipline, et que lorsque nous sortons de la discipline sommes nous capable d’apprécier la dimension poétique de soins mathématicien de la construction abstraite et l’architecte se soucier de la construction matériel. Ce cours entre les disciplines a une double négation qui est liée à l’expérience esthétique kantienne que nous l’avons mentionné plus tôt, parce qu’il regarde la forme seule, sans les frontières sociales. Cette double négation n’est pas seulement définie par les nouvelles conditions d’appréciation des œuvres d’art, elle définit également un certain suspension des conditions normales d’expériences sociales. Voilà ce que Kant illustre avec l’exemple du palais, dont le jugement esthétique isole la forme seulement pour être esthétiquement apprécié, désintéressé à savoir si le palais sert la vanité des riches oisifs et pour qui la sueur des travailleurs a été passé afin de construire. Il est important de clarifier cette nature esthétique de la recherche afin d’éviter toute confusion, une confusion qui est caractéristique de toute recherche effectuée dans la discipline de l’architecture; c’est parce que contrairement à ce qu’il semble être, l’architecture est l’une des disciplines moins clairement défini. C’est pourquoi, lorsque l’on fait la recherche en architecture on se retrouve immédiatement dans le territoire d’une autre discipline que ce soit les mathématiques, l’ingénierie, de la philosophie, de la sociologie ou de l’histoire, d’où l’importance de indisciplinarité et l’esthétique de la connaissance. Cela soulève naturellement des questions sur le sens de la connaissance et de sa relation à l’ignorance, la manifestation la plus simple de cette sensibilité, est comment certains mots comme «espace» ont une existence et une structure complète dans des disciplines différentes. Maintenant, chaque discipline voit «l’espace», selon sa propre structure qui ne s’oppose pas à celle des autres disciplines, mais plutôt ignorer. C’est-à-dire que chaque connaissance vient avec une forme d’ignorance qui lui est intrinsèque. Cela va contre l’idée générale commun de connaissances (détenus par des sociologues comme Pierre Bourdieu) qui est tout simplement: il existe la vraie connaissance qui est conscient et libère et fausse connaissance qui ignore et opprime. Maintenant, la neutralisation esthétique de la connaissance suggère qu’il n’y a pas une seule connaissance, mais que la connaissance est toujours double: il est l’ensemble des connaissances (le savoir-faire) et une distribution organisée de positions et que chacun de ces connaissances a ignorance comme son inverse. Par conséquent, il est aussi des connaissances qui réprime et l’ignorance qui libère [7]. Nous pouvons voir que dans l’exemple des pratiquants des disciplines utilisant le concept «espace»; chacun d’eux a une double connaissance, le savoir faire en fonction de chaque discipline et la connaissance de leur état disciplinaire sociale. Par exemple, comme un architecte ou un mathématicien, vous êtes censé regarder l’espace de la manière dictée par votre discipline et pas en d’autres façons provenant d’autres disciplines, ce qui est une forme d’ignorance. Nous pouvons voir que encore dans l’exemple de Kant du palais: les constructeurs de possession du palais connaissances techniques et de leur condition de travailleurs qui ne possèdent le palais. Chacune de ces deux savoirs a une ignorance comme son inverse: ceux qui savent comment travailler avec leurs mains sont censés être ignorants en ce qui concerne l’appréciation de l’adéquation de leur travail à une fin supérieure. Platon dit que c’est suffisant pour eux d’agir sur une base quotidienne, comme si c’était le cas: il suffit que leur jugement font leur savoir-faire accord avec leur connaissance de leur état. Il dit que c’est une question de croyance qui déterminent le rapport des deux savoirs et les deux ignorances. Un autre exemple parallèle à celle des travailleurs du palais est que la présence des ingénieurs et mathématiciens dans des cabinets d’architectes pour la résolution des problèmes structurels et géométriques; à cause de leur capacité technique, ils sont censés être ignorant de la motivation artistique de l’œuvre. Qui vient précisément de leur connaissance de leur état disciplinaire sociale, à savoir en tant que professionnel technique, vous êtes présumé ignorants des significations artistiques. Le même pour les architectes, avoir la connaissance de comment concevoir et de créer est livré avec une connaissance de leur condition sociale d’être artistique, qui suppose qu’ils soient ignorants des connaissances techniques géométrique impliqué. Cette recherche prend la position de Rancière et Kant, à savoir une position indisciplineaire esthétiquement neutre, où les conditions sociales disciplinaires sont simplement suspendus ou ignorées toutes ensemble permettant une appréciation désintéressée. Rancière suit Kant dans faisant valoir que les travailleurs sont en mesure de prendre une position désintéressée et apprécier la beauté du palais sans tenir compte de leur position sociale comme les travailleurs, tandis que les sociologues font valoir que cela est réservé uniquement pour ceux qui ne sont ni les propriétaires ou les travailleurs de la palais. L’expérience esthétique dérègle cette disposition, il est donc bien plus qu’une façon d’apprécier des œuvres d’art, il neutralise la relation circulaire entre la connaissance que le savoir faire et les connais- 16 | de la palais. L’expérience esthétique dérègle cette disposition, il est donc bien plus qu’une façon d’apprécier des œuvres d’art, il neutralise la relation circulaire entre la connaissance que le savoir faire et les connaissances que la distribution des rôles. Ceci explique l’importance de l’expérience esthétique dans cette recherche car elle nous permet d’échapper à la répartition sensée des rôles: architecte, mathématicien, ingénieur et philosophe et leurs compétences et d’apprécier le résultat d’une position neutre désintéressé. Maintenant que nous avons montré l’importance de l’esthétique de Kant dans la compréhension des concepts de Rancière sur la poétique de la connaissance et de travail entre les deux disciplines, ce qui est essentiel pour la compréhension de la dimension esthétique de cette recherche, nous allons maintenant analyser plus en détail la notion de “discipline “. Selon Rancière une discipline n’est pas simplement la définition d’un ensemble de méthodes appropriées pour un certain domaine ou un certain type d’objet, mais c’est la constitution même de cet objet comme un objet de pensée, une certaine idée de la relation entre la connaissance et une distribution de positions. En d’autres termes, une discipline est une manifestation d’une idée de la connaissance, où une idée de la connaissance doit être comprise comme le rapport entre les deux savoirs et deux ignorances. C’est toujours plus qu’un ensemble de procédures qui permettent la pensée d’un territoire donné d’objets, c’est la constitution de ce territoire lui-même et donc la création d’une certaine répartition du pensable. En tant que tel, il suppose une coupure dans le tissu commun de manifestations de la pensée et de la langue. Pensée disciplinaire dit: nous avons notre territoire, nos objets et nos méthodes qui leur correspondent. Disciplines sont donc en guerre avec la allodoxie de jugement, mais ce qu’ils appellent allodoxie est en fait dissensus esthétique, la déhiscence entre le corps et ce qu’il sait dans le double sens de la connaissance, la pensée indisciplinaire est donc une pensée qui rappelle le contexte de la guerre. Pour ce faire, il doit pratiquer une certaine ignorance, il faut ignorer les frontières disciplinaires pour restaurer ainsi leur statut comme des armes dans un conflit [7]. C’est exactement ce que nous essayons de faire dans cette recherche, de l’idée de base de l’application de la géométrie moderne dans la conception architecturale tout au long dans les moindres détails; notions fondamentales de mathématiques, les sciences et la philosophie mettre dans le contexte, comme s’ils pouvaient être utilisés comme outils de conception architecturale. Cette mise de concepts d’une discipline dans leur forme brute et les mettre dans un nouveau contexte d’une autre discipline avec toutes leurs structures rigoureuses intactes, c’est ce que révèle cette confrontation violente des orthodoxies de disciplines. Par exemple, les notions mathématiques sont effectuées sur le territoire de la conception architecturale avec tout leur bagage mathématique structurale sans les privant de leur contenu ou les vulgariser afin d’être adapté dans le nouveau contexte. Cela montre les deux savoirs et les deux ignorances en jeu; la connaissance du savoir-faire permet l’écriture de ces notions, alors que la connaissance du rôle d’un mathématicien ignore les valeurs de ces notions pour la conception architecturale. Dans le même temps la connaissance de la conception architecturale permet l’utilisation créative de ces notions mathématiques tandis que la connaissance du rôle de l’architecte ne tient pas compte de la valeur d’acquisition de ces connaissances techniques. Cela, réinvente efficacement la relation entre une situation donnée et les formes de visibilité et les capacités de la pensée qui y sont attachés; la pensée indisciplinaire créer le texte et l’espace signifiant dans lequel cette relation du mythe au mythe est visible et pensable. Ceci est un rôle important de indisciplinarité en général et dans cette recherche en particulier, il est un rappel constant que la fondation de la fondation est une histoire, un mythe, un beau mensonge qui est la réalité de la vie pour la majorité des gens. Cela ne veut pas dire de toute façon que ces histoires sont nulle ou sans effet, cela signifie simplement que ce sont des armes dans une guerre, ils ne sont pas les armes qui facilitent simplement l’examen d’un territoire, mais des armes qui servent à établir les limites incertaines. Il n’ya pas de limite assurée entre les disciplines, et de retracer ce limites est de tracer la frontière entre ceux qui ont pensé à cette question et ceux qui n’ont pas. La poétique de la connaissance ainsi, ne prétendent pas que les disciplines sont fausses connaissances, mais plutôt les moyens d’intervenir dans la guerre entre les raisons de l’égalité et ceux de l’inégalité. Avec cela, nous terminons notre explication de la dimension esthé- tique de cette recherche et dans la partie qui suit, nous allons commencer la prepration pour la construction de l’espace formel. | 17ü 1.6. Références [1] Sacred, profane and geometrical symbolism in architecture, Antonio Caperna, 2007 [2] Internet encyclopedia of philosophy / Kant’s aesthetics / The central problems of the critique of judgment [3] Internet encyclopedia of philosophy / Kant’s aesthetics / The judgment of the beautiful [4] Internet encyclopedia of philosophy / Kant’s aesthetics / The sublime [5] Internet encyclopedia of philosophy / Kant’s aesthetics / Fine art and genius [6] Geometry and experience, Albert Einstein, Springler, Berlin 1921 [7] Thinking between disciplines: an aesthetics of knowledge, Jacques Ranciére, Parrhesia, Paris 2006 18 | 2. Géométrie et espace ü 2.1. Géométrie, la perception et l’expérience Dans le chapitre dernier nous nous sommes concentrés sur le contexte général de cette recherche, portant principalement sur sa position entre les deux disciplines de l’architecture et les mathématiques. Nous avons également mis l’accent sur affichant la double nature de la recherche motivée par des raisons esthétiques et pratiqueset, et puis nous avons donné un bref compte rendu de l’esthétique de Kant qui a servi dans la compréhension de la dimension esthétique de l’œuvre. Enfin, nous avons utilisé le concept de Jacques Rancière pour montrer la dimension poétique de travail entre disciplines. Dans ce chapitre, nous allons laisser la situation générale et commencer à se concentrer sur l’objet de la recherche à savoir l’utilisation de la géométrie moderne en architecture. Bien sûr, cela nécessite une certaine préparation avant de plonger dans les formules et les constructions abstraites, cette préparation est essentiellement de comprendre quelques différences fondamentales importantes entre la vision de l’espace et de la géométrie des architectes et des mathématiciens. We have already hinted at this distinction when we explained the paradigm shift in mathematics resulting in the old and new interpretation of geometry. Cependant, maintenant nous allons lier cette distinction à deux points dominants de vue de l’espace dans l’architecture: les cartésiennes et phénoménologiques, avec plus d’emphase sur le point de vue phénoménologique dans les dernières décennies. Nous allons de nouveau utiliser certaines notions de l’ontologie Kant quand nous expliquons cette distinction. Le thème de l’espace et de la géométrie est un vaste sujet dans la philosophie et en particulier l’ontologie de l’espace et du temps; dans cette recherche, nous allons mettre l’accent sur certaines notions spécifiques qui sont pertinentes à notre contexte. Des notions telles que la distinction entre l’espace formel et l’espace physique, qui sont liés à l’ancienne et la nouvelle interprétation de la géométrie. Autres notions importantes sont liées à la perception et la compréhension espace à travers nos sens et d’autres notions phénoménologiques tels que l’expérience corporelle. Cela nous aidera à obtenir une meilleure compréhension de la relation entre l’espace, la géométrie et de notre perception. Il y a eu un grand nombre d’ouvrages philosophiques consacrés à l’étude de l’espace et de la perception, surtout depuis le début de la phénoménologie comme un mouvement philosophique et jusqu’à mouvements ultérieurs comme l’existentialisme, le structuralisme et le post-structuralisme qui ont été très influencés par cette ligne de pensé. Ces travaux ont eu une influence considérable pour l’ compréhension de l’espace dans l’architecture, ce qui contribue d’une certaine manière à la problématique de l’application de la géométrie moderne à la conception architecturale en particulier et au divorce entre la science et l’art moderne en général. L’idée de base de la problématique est dans l’opposition entre deux points de vue fondamentaux: l’ontologie cartésienne sur la base du cogito et l’ontologie phénoménologique par exemple, que des corps-sujet de Merleau-Ponty. Il y a beaucoup de comptes ontologiques phénoménologiques anti-cartésiens, mais nous tenons à mentionner en particulier celle de Merleau-Ponty en raison de son attitude douteuse explicite en ce qui concerne les connaissances scientifiques comme le vrai compte de la réalité. Merleau-Ponty utilise référence à la technique anti-perspective de Cézanne à la peinture, la considérant comme une manière plus profonde pour capturer l’expérience humaine de l’espace [1]. Ce point de vue ne pouvait pas être plus loin du point de vue de la renaissance où la perspective était censé être un moyen de capturer l’espace réaliste humaniste. Nous pouvons déjà voir l’hostilité entre l’ontologie cartésienne adoptée largement par la science et les mathématiques modernes avec leur compréhension abstraite de l’espace et l’ontologie phénoménologique qui met l’accent sur l’expérience. Cela donne plus d’explications pourquoi les mathématiques jouent un rôle important dans les arts de la Renaissance, alors qu’elle est totalement absente si pas en position opposée aux arts dans les temps modernes. Merleau-Ponty poursuit en expliquant cette opposition entre les mathématiques modernes et la science en général et l’art moderne. Selon Merleau-Ponty, la science est à l’opposé de l’art, où l’art de capturer la perception individuelle, la science est fondamentalement anti-individualiste, à savoir positiviste. Dans son livre (la phénoménologie de la perception) Merleau-Ponty décrit la science comme une abstraction ex post facto, et qu’il néglige la profondeur des phénomènes qu’il cherche à expliquer [2]. En d’autres termes, cette géométrie moderne (également de la géométrie pratique complété de la physique) avec toute sa rigueur, en quelque sorte ne peut pas saisir pleinement la profondeur du phénomène de l’expérience des objets réels. La position de Merleau-Ponty en ce qui concerne la compréhension de l’espace et des objets dedans, est la position générale d’architectes que ce soit par conviction ou | 19du phénomène de l’expérience des objets réels. La position de Merleau-Ponty en ce qui concerne la compréhension de l’espace et des objets dedans, est la position générale d’architectes que ce soit par conviction ou simplement en suivant la convention de la discipline. Nous n’allons pas ici plaider en faveur ou contre cette position, nous mentionnons simplement comme partie de notre préparation du terrain pour la construction de l’espace formel. Principalement pour donner une idée du contexte actuel de la compréhension de l’espace en architecture avant de commencer à importer la compréhension de l’espace des mathématiques dans ce territoire. Nous pouvons être d’accord ou en désaccord avec la position de Merleau-Ponty, le fait est qu’il est vrai que les formules ne peuvent pas saisir pleinement l’expérience humaine, mais ce n’est pas ce qu’ils sont faits pour. Cependant, ils capturent certain type de connaissances sur l’objet réel qui n’est pas accessible aux sens. Pour rendre cette idée plus claire, nous prenons un exemple concret de représentant une forme connue, par exemple le cercle. Il s’agit d’une forme que nous connaissons tous, parce que nous avons vécu dans la réalité, par exemple en regardant la pleine lune. Alors, où un cercle tracé à la main plutôt déformé par un artiste représente mieux la perception individuelle du cercle, il ne parvient pas à nous dire ses propriétés intrinsèques, quelque chose que l’équation du cercle peut dire avec beaucoup de détails. Cela peut sembler une observation triviale mais c’est précisément la position problématique de l’architecture depuis un côté, nous devons être capables de dire des informations précises sur les formes que nous concevons, tout en exprimant une vision individuelle artistique d’eux. Ce problème n’existerait pas dans l’ingénierie puisque ce qui est important est l’information intrinsèque, et il n’apparaît pas dans la peinture ou la sculpture parce que c’est la vision individuelle est ce qui compte. Au 18ème siècle, le mathématicien français Gaspard Monge a développé une méthode de représentation intermédiaire: la géométrie descriptive, portant le processus rigoureux de construction mathématique en utilisant le dessin au lieu de formules. Géométrie descriptive a été très adapté à l’architecture et le dessin technique, qu’il est resté jusqu’au l’essor de dessin à l’ordinateur et des logiciels de CAO, la dominante et parfois la seule géométrie enseignée dans les écoles d’architecture. Cependant, malgré les fondements mathématiques de la géométrie descriptive, son processus est entièrement phénoménologique à savoir que les constructions sont basées sur notre vision. Pour cette raison, nous ne pouvons pas considérer son application en architecture d’une application de la géométrie moderne et son espace n’est pas un espace formel. Contrairement aux dessin à la main ou à l’aide de la géométrie descriptive, l’écriture d’une équation pour le cercle crée un saut que le dessin ne peut pas faire, c’est parce que, après tout, le dessin est une tentative de recréer l’expérience de voir le contour (par exemple de la pleine lune ) en utilisant une autre expérience qui, est de voir le cercle graphique dessinée. Maintenant ce que nous obtenons avec une équation en termes de perception n’a rien à voir avec le cercle puisque visuellement tout ce que nous voyons sont des symboles mathématiques, donc le lien à la forme du cercle n’est pas un visuel, mais un lien mental. C’est comme donner le cercle une double existence, l’un comme une forme phénoménologique et l’autre comme une relation logique entre les symboles, c’est remarquable, car il est équivalent à avoir un autre moyen de comprendre et d’apprécier les formes uniquement à travers nos esprits. Toutes les informations sur la forme peut être comprise de cette manière, par exemple, où elle se courbe ou où il n’est pas lisse, et puis peuvent être observés phénoménologiquement et ont trouvé être parfaitement assorti. Cela nous amène au problème d’Einstein du chapitre précédent lorsque nous avons soulevé la question de savoir comment les mathématiques décrivent le monde physique avec une précision étonnante. Cette distinction entre les propriétés d’un objet qui peut être compris que par l’esprit et ceux observés par les sens, peut être retracée aux idées et formes de Platon, mais mises de l’avant dans les temps modernes par Emmanuel Kant dans son livre Critique de la pure raison comme noumène et phénomènes. Cette distinction pourrait être compris comme des choses en soi et les choses comme elles apparaissent. Ces notions sont des notions importantes de la philosophie transcendantale de Kant qui ont besoin profonde étude de la philosophie de Kant à comprendre pleinement. Dans le cadre de cette recherche, nous allons tenter d’interpréter ces concepts afin de les intégrer dans notre discours sur l’ancienne et la nouvelle interprétation de la géométrie, ce qui est important pour nous, en montrant la différence entre l’espace du point de vue de l’architecture et du point de vue des mathématiques modernes. Nous allons mener cette tentative en utilisant à nouveau l’exemple de la représentation du cercle par le dessin et par l’équation mathématique. Simplement, en considérant la représentation mathématique comme noumène et la représentation graphique dessiné comme phénomène, tant représenté sur la figure ci-dessous. 20 | Noumena (la chose en soi) Un objet posé ou de l’événement, qui est connu sans l’utilisation des sens G = 9x œ !2 f HxL = x1 2 + x2 2 = 1= , ici f représente une propriété intrinsèque du cercle comme noumène à savoir que chaque point sur le cercle vérifie cette relation. Phénomènes (la chose telle qu’elle apparaît) Un objet posé ou de l’événement, qui apparaît aux sens Représentation du cercle ici comme un phénomène visible (un cercle de rayon = 1). Le point de vue de Kant est la suivante: lorsque nous utilisons un concept de décrire ou de classer noumènes nous sommes en fait en employant des méthodes pour décrire ses manifestations ou des phénomènes observables [3]. Il continue de classer les méthodes par lesquelles les humains tentent de comprendre le monde tel qu’il est, qu’il a appelé, catégories de l’entendement: l’esthétique transcendantale, analytique transcendantale, la logique transcendantale, et déduction transcendantale. Selon Kant, afin de transcender une observation directe ou une expérience, les humains utilisent la raison et classifications, pour corréler entre les interrelations entre les phénomènes que l’on observe, cependant, ils ne peuvent jamais connaître les choses en elles-mêmes directement. Plutôt, nous devons déduire la mesure dans laquelle les pensées correspondent avec les choses en elles-mêmes par nos observations des manifestations de ces choses qui peuvent être détectés, c’est des phénomènes [3]. Aussi abstrait que cela puisse paraître, nous pouvons voir des éléments de cette théorie en mathématiques et en géométrie, en particulier, à savoir que par l’usage de formules, nous sommes en mesure de puiser dans certaines informations sur la forme (par exemple le cercle), mais ces informations comme la courbure en un point, peuvent être observés seulement si la forme est dessinée ou trouvé dans un objet physique, mais ce qui est le cercle en soi est inconnaissable. Ces idées de la distinction kantienne entre noumène et phénomènes sont très importants dans notre contexte, car ils peuvent nous montrer les origines de la suite à venir: ontologie phénoménologique de l’espace. Cela commence par le travail d’Edmund Husserl père de la phénoménologie transcendantale et mathématicien qui a pris les idées de Kant et les a développé davantage. Dans ce qui suit nous allons continuer plus loin, en mettant l’accent sur les notions d’espaces physiques et formelles et la perception, à travers de brefs comptes rendus des travaux de Husserl, Rudolf Carnap et Martin Heidegger. Husserl était préoccupé par les phénomènes de notre perception de l’espace. Il se demandait en quoi consistent la spatialité de notre perception, en d’autres termes comment pouvons-nous appréhender l’espace et comment pouvons-nous décrire. Dans son livre (Idées I), il définit le concept de épochè comme processus impliqués dans le blocage des préjugés et des hypothèses pour expliquer un phénomène en termes de son propre système inhérent de signification. Et bracketing comme un processus de mise systématiquement sur le côté, nos diverses hypothèses et nos croyances sur un phénomène, afin d’examiner comment le phénomène se présente dans le monde du participant. Bracketing implique donc mettre de côté la question de l’existence réelle d’un objet envisagé, ainsi que toutes les autres questions sur la nature physique ou objectif de l’objet; ces questions sont laissées aux sciences naturelles [4]. Par exemple, le fait de voir un cheval est considéré comme une expérience mentale, que l’on voit le cheval en personne, dans un rêve, ou dans une hallucination. Bracketing le cheval suspend tout jugement sur le cheval comme noumène et à la place, analyse le phénomène du cheval dans le mental humain. Cela signifie que pour Husserl perception est notre principale forme de savoir et n’existe pas en dehors de l’a priori de la structure de l’organisme et de son engagement dans le monde. Dans ces exemples, nous pouvons voir déjà la distinction entre les notions d’es- | 21notre principale forme de savoir et n’existe pas en dehors de l’a priori de la structure de l’organisme et de son engagement dans le monde. Dans ces exemples, nous pouvons voir déjà la distinction entre les notions d’espace formel et physique, et la première formulation de Husserl de la compréhension phénoménologique de l’espace qui cherche à devenir sans présupposés au moyen de la réduction phénoménologique. Husserl, étant un mathématicien naturellement favorisé une version transcendantale de la phénoménologie où l’accent de notre compréhension de l’espace et des objets dedans, se fonde sur notre perception ignorant leur existence physique, laissant cette question aux sciences naturelles. Nous verrons tout à fait un point de vue phénoménologique différente plus tard avec Heidegger, où l’accent est mis beaucoup plus sur la présupposition que nous avons sur le monde, conditionné par le fait que la personne est jeté dans le monde. Nous verrons plus loin, un point de vue phénoménologique tout à fait différente avec Heidegger, où l’accent est mis beaucoup plus sur la présupposition que nous avons sur le monde, conditionné par le fait que la personne est jeté dans le monde. En Logique formelle et transcendantale Husserl tente de géométriser la perception. À savoir, qu’il corrèle les concepts géométriques avec le sens phénoménologique pure et il donne une utilisation intradescriptive aux outils de la géométrie; traitant ainsi les concepts et les outils opérationnellement et non objectivement. Il décrit le corps comme le lieu de toutes les formulations sur le monde; non seulement il occupe l’espace et le temps mais comporte également de la spatialité et la temporalité, et il a une dimension [5]. Ce que Husserl appelle la géométrie de l’expérience pourrait être comprise comme les significations que nous recevons quand nos corps se déplacent dans l’espace polarisant la réalité extérieure. Pour lui la conception architecturale est une extension de cette géométrie de l’expérience au-delà du corps [6]. Husserl conçoit la constitution de ce qu’on appelle l’espace objectif à la fois des aspects statiques / dynamiques et mono / intersubjectives. D’un côté, il constitue un espace objectif comme le corrélat de la transformation intentionnelle mono-subjective de la variété de champs dits sensuels que nous faisons lors de notre activité mobile corporels. De l’autre côté comme le corrélat de la transformation intentionnelle inter-subjective de structures d’espaces ressentis subjectivement, (c’est à dire empathie transcendantale) au sein de notre communauté de sujets transcendantaux qui communiquent entre eux. Le travail de Husserl a influencé de nombreux philosophes, logiciens et mathématiciens, l’un d’eux était le philosophe allemand Rudolf Carnap, qui était membre du cercle de Vienne et un protagoniste du positivisme logique. Le travail de Rudolf Carnap couvre de nombreux domaines, en se concentrant principalement sur les fondements de disciplines, telles que la logique, les mathématiques et la physique, comme un élève de Husserl, il utilise certaines de ses idées, mais il les pousse d’une manière tout à fait différente. Carnap comme nous l’avons mentionné est un positiviste logique, et ainsi sa position est beaucoup plus anti métaphysique, mais nous devons donner un bref compte rendu des idées de Rudolf sur les espaces formels et physiques dans le cadre de notre préparation générale pour les constructions formelles qui suit. Rudolf Carnap a développé sa théorie philosophique de l’espace dans son ouvrage sur les fondements de la géométrie, il distingue trois types d’espace: formels, physiques et perceptives. Selon Carnap, les espaces formels sont les espaces mathématiques, limitée seulement par ne pas être contradictoire en soi d’un point de vue logico-déductive, tandis que l’étude des inter-relations entre les objets déterminés de manière empirique constitue espaces physiques. Enfin, les espaces perceptuels sont le domaine d’expériences sensorielles immédiates aussi connu comme Anschauungen (ou espace visuel). La distinction de Carnap des trois espaces est assez directe et claire par rapport à la phénoménologie transcendantale de Husserl, où le formel et le perceptif sont plus liés; dans le cadre de cette recherche lorsque nous utilisons le terme: espace formel, nous serions alors parlons de des espaces mathématiques de Carnap. Qui sont évidemment basée ce que Einstein distingue comme la nouvelle interprétation de la géométrie, sous la seule réserve formelle et indépendante de toute présupposition a priori sur ses objets ou de toute existence physique logique. Cette position a une saveur beaucoup plus scientifique qui est sûr, naturel pour le cercle de Vienne avec leur rejet de la métaphysique; cette position dans la compréhension d’espace, est la position classique de l’ingénierie et des sciences naturelles, mais l’architecture ne partage pas cette position. Compréhension architecturale de l’espace est plus liée à l’autre école de pensée engendré par la phénoménologie transcendantale de Husserl, mais a pris une direction philosophique plus continental avec l’influence de Heidegger, par opposition à la direction philosophique analytique de Carnap et la logique positiviste. Martin Heidegger qui a également été influencé par Husserl, néanmoins développé une position philosophique très différentes de celles de Husserl et Carnap. Heidegger est aussi un philosophe très influent avec un grand corps de travail, mais nous allons nous concentrer ici uniquement sur son travail concernant l’espace. Nous allons remarquer immédiatement la différence de la langue et de la pensée de Heidegger par rapport à ce que nous avons vu jusqu’à présent chez Husserl et Carnap dans le sens où Heidegger en revanche à Husserl et Carnap n’est pas orienté vers les mathématiques et 22 | la langue et de la pensée de Heidegger par rapport à ce que nous avons vu jusqu’à présent chez Husserl et Carnap dans le sens où Heidegger en revanche à Husserl et Carnap n’est pas orienté vers les mathématiques et sa version de la phénoménologie est fondée dans les présupposés que les humains ont de l’espace. Ces présupposés que Husserl essayait de bracket, Heidegger creuse profond en eux et développe son concept d’être jeté dans le monde, aussi sa langue est beaucoup plus orienté vers les conditions de vie de tous les jours avec l’humeur et l’anxiété. Sa position concernant la science est naturellement opposé aux philosophes analytiques et positivistes logiques, qui considèrent les connaissances scientifiques pour être le plus proche de la réalité, en revanche Heidegger trouve autant de vérité dans la poésie et les arts sur la réalité comme dans les enquêtes scientifiques. Cela nous donnerait une idée de pourquoi la phénoménologie de Heidegger était beaucoup plus répandue en architecture, qui, vers le 20ème siècle est devenu de moins en moins liée aux mathématiques. Dans ce qui suit, nous allons présenter le concept de Heidegger de ce que nous appelions jusqu’ici espace formel ou de l’espace mathématique, et comment il contraste avec la notion de lieu, on remarque immédiatement la différence de la langue et de l’intérêt par rapport à la langue sèche de Carnap, qui se concentre uniquement sur les constructions formelles et logiques. Pour la première fois, nous rencontrons une compréhension différente de l’espace qui est fondamentalement liée à la perception, mais pas de la manière anti-présuppositionnelle comme chez Husserl, mais bien au contraire en se concentrant sur le sens de la place de l’homme. Heidegger, il est très clair que l’espace dans la tradition mathématique cartésienne où le calcul peut être fait à propos de ses fonctions, n’a rien à voir avec la place qui est l’environnement dans lequel nous vivons. Heidegger est très clair que l’espace dans la tradition mathématique cartésienne où le calcul peut être fait à propos de ses fonctions, n’a rien à voir avec la place qui est l’environnement dans lequel nous vivons. Dans son essai (bâtiment, le logement, la pensée), Heidegger explique espace phénoménologique, par les notions de distance ou de spatium en latin et l’extension ou extensio. Il continue alors de définir d’abord, la distance de la manière suivante: une distance est un espace intermédiaire ou un intervalle, donc la proximité ou l’éloignement entre les hommes et les choses peuvent devenir de simples intervalles d’espaces intermédiaires. Il ajoute ensuite que dans un espace qui est représenté à titre purement spatium, toute entité apparaît comme une simple chose à une position qui peut être occupé à tout moment par quelque chose d’autre, ou remplacé par un simple marqueur. Ce qui est plus, les simples dimensions de la hauteur, la largeur et la profondeur peuvent être extraites de l’espace sous forme d’intervalles. Ce qui est si abstraite, nous représentons comme une variété pure de trois dimensions [7]. Cette définition de la distance est essentiellement la définition de la distance dans la tradition cartésienne où les entités sont représentées par des coordonnées en trois dimensions d’espace homogène, mais Heidegger explique que cette distance peut être prélevée encore plus loin pour devenir une extension. Il raconte ce à la construction de variétés qui sont en quelque sorte, une nouvelle abstraction de l’espace cartésien euclidienne. Il explique ensuite qu’une pièce fait par cette variété est également plus déterminée par la distance, il n’est plus un spatium, mais maintenant pas plus que extensio, encore plus, il y a même encore un autre niveau d’abstraction de l’espace comme extensio qui sont: variétés purement mathématiques. Il leur explique comme des constructions purement mathématiques de dimensions arbitraires prises que par des relations algébriques abstraites analytiques. L’espace prévu pour cette manière mathématique peut être appelé l’espace, une espace en tant que tel, mais dans ce sens l’espace contient pas de lieux [7]. Ici, il fait clairement la distinction entre l’espace et le lieu qui d’une manière subtile est différente de la distinction formelle et physique de l’espace de Carnap et de la vieille et la nouvelle interprétation de la géométrie d’Einstein. Cette distinction heideggerienne est le plus proche pour expliquer la différence entre l’espace compris en architecture et l’espace compris par les mathématiques et la science, ce n’est pas seulement que les architectes comprennent l’espace à travers la vieille interprétation de la géométrie et de l’espace physique, ils comprennent l’espace surtout que le lieu. Par contraste aux scientifiques en particulier des physiciens et ingénieurs qui sont, par définition, concernés par l’espace physique avec la géométrie pratique complété d’Einstein; leur espace physique contient également pas de lieux. En bref, ce qui fait l’espace en architecture n’est pas seulement sa construction formelle comme en mathématiques, ni ses propriétés matérielles comme en physique, ni la façon dont il est perçu psychologiquement par nos sens, mais qu’il est toujours fondamentalement constituée d’endroits. Heidegger manifeste alors de sa position poétique concernant la réalité de l’espace, en disant que l’espace formel avec sa géométrie formelle ne peut jamais saisir la profondeur de ce que un lieu est. Il dit que spatium et extensio permettre à tout moment la possibilité de mesurer les choses en termes de distances, portées et les directions, et de calculer ces grandeur. Mais le fait qu’ils sont universellement applicables à tout ce qui a une extension, ne peut en aucun cas faire les grandeurs numériques la base de la nature des lieux et des espaces qui sont mesurables à l’aide des mathématiques [7]. La phénoménologie de Heidegger était très | 23ce qui a une extension, ne peut en aucun cas faire les grandeurs numériques la base de la nature des lieux et des espaces qui sont mesurables à l’aide des mathématiques [7]. La phénoménologie de Heidegger était très influent à l’intérieur et à l’extérieur de la philosophie, en particulier dans la théorie architecturale, fournissant un moyen de comprendre l’espace non pas comme un espace neutre abstraite (espace mathématique formelle), mais plutôt comme l’espace d’expériences vécues. Les phénoménologues essaient de récupérer une dimension ontologique à l’environnement bâti, une dimension qu’ils croient a été érodée progressivement depuis l’invention de la perspective linéaire, il y a eu une tendance à percevoir l’espace comme de plus en plus abstraite et éloignée du corps et ses sensations. Ils prétendent que les sens doivent être traitées, et l’espace doit être perçu avec toutes les associations phénoménologiques autant que ce soit par des moyens visuels de représentation, par exemple la visualisation de formules mathématiques. Puisque cette recherche est centrée autour de l’application de la géométrie moderne dans la conception architecturale, à savoir le traitement de l’espace dans sa forme la plus abstraite, nous sommes enclins à penser qu’il s’agit d’une approche anti-phénoménologique, cependant, ce ne serait pas un jugement tout à fait correcte. C’est parce que, malgré le fait que tous les espaces et les formes qui vont être définis ici sont purement formelles, sans aucun lien avec des expériences monde physique, ils ne sont pas considérés comme une architecture au sens plein, nous pourrions les considérer comme des candidats virtuels ou proto-architecture qui pourraient être développées davantage en objets architecturaux. Avec ces brefs comptes rendus, nous avons une idée du contexte dans lequel nous nous trouvons en tenter d’apporter l’espace formel et la géométrie moderne dans la conception architecturale; avec cela, nous procédons maintenant à nos constructions mathématiques. 24 | ü 2.2. Les espaces formels et variétés ü 2.2.1 Notions topologiques de base Puisque la majorité des travaux dans cette recherche utilisent la géométrie moderne et l’espace formel, nous devons comprendre quelques concepts fondamentaux qui sont essentiels à sa construction, le premier d’entre eux sera la topologie. La topologie est l’étude mathématique concerné avec les propriétés qualitatives les plus élémentaires de formes et d’espaces, tels que la connectivité, de la continuité et de la limite, les propriétés qui sont conservées sous déformations continues, y compris étirement et de flexion, mais pas déchirer ou collage. Topologie a de nombreux sous-champs: la topologie générale, qui établit les aspects fondamentaux de la topologie et examine les concepts inhérents aux espaces topologiques (exemples incluent la compacité et la connectivité). Topologie algébrique, qui tente de mesurer le degré de connectivité en utilisant des constructions algébriques tels que les groupes d’homotopie et homologie, et la topologie différentielle principalement des études de variétés différentiables et leurs plongements dans d’autres variétés. Espace topologique [11] Soit X un ensemble, !HXL l' ensemble de parties de X, " Õ !HXL alors " est une topologie si « œ " et X œ " " eststable par intersections finies : Ai œ " , " i œ 81, .., n< ï›i=1 n Ai œ " " eststable par réunions quelconques : Ai œ " , " i œ I ï‹iœI Ai œ " ï le couple HX, "Ls' appelle espace topologique U est un sous ensemble de X inclus dans ", U est un ouvert de X " est une topologie séparée ó " x, y œ X distincts, $ U, V œ " x œ U, y œ V and U › V = f Le diagramme suivant explique la topologie d ' un ensemble X = 8a, b, c< Le bas à gauche n' est pas une topologie parce que la réunion 8b< ‹ 8c< = 8b, c< à " = 8f, X, 8b<, 8c<< En bas à droite n' est pas une topologie car l' ntersection 8a, b< › 8b, c< = 8b< à " = 8f, X, 8a, b<, 8b, c<< La relation de la topologie à la conception architecturale n’semble pas tout à fait clair, compte tenu de la nature abstraite de la topologie, par contraste à la relation de la géométrie à l’architecture qui est un peu évident. D’un point de vue quantitatif c’est vrai; la géométrie a beaucoup plus à offrir, mais il y a un parallèle fondamental sous-jacent entre la topologie et l’architecture, à savoir l’analyse qualitative des formes et des espaces. L’architecture n’est pas seulement concerné par la nature quantitative des formes mais aussi leurs propriétés qualitatives par exemple compacité et la connectivité. Des termes comme voisinage, ouvert, fermé, intérieur, extérieur, frontière, densité entre autres apparaissent simultanément entre l’architecture et la topologie, mais il n’a jamais été une recherche importante sur la corrélation entre ces analogies. Cette recherche porte sur l’application de la géométrie moderne à l’architecture, ce qui signifie que les questions de la topologie seraient naturellement adressées puisque la géométrie moderne est intrinsèquement liée à la topologie, mais ces questions topologiques ne constituent pas l’objet principal du travail. | 25Espace métrique [8] d : X ä Xö!+ , d s' appelle une métrique sur l' espace topologique X, if " x, y, z œ X séparabilité : dHx, yL = 0 óx = y positivité : dHx, yL r 0 inégalité triangulaire : dHx, zL b dHx, yL + dHy, zL ï le couple HX, dL s' appelle un espace métrique " x, y œ !n , dpHx, yL = H⁄i=1 n †xi - yi § p L 1 p d2 est la distance euclidienne et H!n , d2L est l' espace euclidien de dimension n Le premier de ces concept sera le voisinage. Le voisinage est l’un des concepts fondamentaux de la la topologie et donc fondamentale pour la géométrie en particulier la géométrie différentielle, intuitivement un voisinage d’un point dans un espace topologique est un ensemble contenant ce point, où l’on peut déplacer ce point une certaine quantité sans quitter l’ensemble. Le voisinage est étroitement liée à la notion d’ un ouvert et de l’intérieur. Voisinage et ouvert [8] HX, "L est un espace topologique, p œ X et V œ !HXL V est un voisinage de p ó $ U œ " p œ U Õ V , nous notons #p l' ensemble des voisinages de p HX, dL est un espace métrique, p œ X et V œ !HXL et BHp, rL = 8y œ X dHp, yL < r< est une boule ouverte V est un voisinage de p ó BHp, rL Õ V HX, "L est un espace topologique, U Õ X est un ouvert ó " x œ U, U œ #x HX, dL est un espace métrique, U Õ X est un ouvertsi " p œ U $ e > 0 " x œ X , dHx, pL < e ï x œ U Représentation de V comme un voisinage de p , V ! U un ouvert Après avoir défini le voisinage, nous allons maintenant définir l’intérieur d’un espace, son extérieur et sa limite. Intuitivement, l’intérieur d’un sous ensemble A d’un espace topologique X est l’ensemble des points de A qui n’appartiennent pas à sa limite, et, naturellement, à l’extérieur de A est à l’intérieur de son complémentaire ou en d’autres termes le complément de son adhérence. La frontière de A est naturellement l’ensemble des points de l’adhérence de A qui ne sont pas à l’intérieur de A, et l’adhérence de A est sa frontière plus son intérieur. Intérieur [8] HX, "L est un espace topologique, S œ !HXL, x œ X est un point intérieur de S ó S œ #x S Î = 8x œ X x point intérieur de S< s' appelle l' intérieur de S Hle plus grand ouvert contenant SL HX, dL est un espace métrique, x œ S Îó $ r > 0 BHx, rL Õ S 26 | Adhérence [8] HX, "L est un espace topologique, S œ !HXL, x œ X est un point adhérent à S ó " V œ #x , V › S " f S = 8x œ X x point adhérent à S< s' appelle l' adhérence de S Hle plus petit fermé contenant SL S c est le complémentaire de S ï HSL c = HS c L Î et #S est la frontière de S ï #S = S îS Î S est un fermé ó S c est ouvert et S est dense dans X ó S = X S est un fermé si S = S Hi.e. " x œ S ïx est un point de accumilation ou un point isoléL x œ X un point de accumilation de S is " V œ #x , V › S î 8x< " f x œ X un point isolé de S ó $ V œ #x , V › S î 8x< = f HX, dL est un espace métrique, x œ Só " r > 0 BHx, rL › S " f Représentation de x comme un point intérieur de S et y comme un point d ' adhérence Hde la frontière L de S En outre, nous allons définir la compacité et la connexité d’un espace, mais avant, nous devons définir une propriété fondamentale de la topologie, à savoir la continuité d’une application entre deux espaces topologiques (ie les transformations continues). Intuitivement une application continue est une application pour laquelle petits changements dans l’entrée provoque de petits changements dans la sortie. Continuité (topologique) [8] HX, "X L, HY, "Y Lsont des espaces topologiques f : X Ø Y, est continue en xó " V œ #y $ U œ #x f HUL Õ V f est une application continue ó f est continue en tout x œ X Continuité (métrique) [8] HX, dX L, HY, dY Lsont des espaces métriques, x, x' œ X f : X Ø Y, est continue en xó " e > 0 $ d > 0 dX Hx, x'L < e ï dY H f HxL, f Hx'LL < d et f est k - Lipschitz continueódY H f HxL, f Hx'LL b k dX Hx, x'L continuité (topologique) continuité (métrique) | 27Avec la définition de la continuité, nous allons définir la notion de homéomorphisme, ce qui est essentiel dans l’étude de la topologie; essentiellement un homéomorphisme est une application continue entre deux espaces topologiques qui a une application inverse continue. Deux espaces avec un homéomorphisme entre eux sont appelés homéomorphe, et si ces espaces sont des espaces métriques alors ce homéomorphisme s’appelle un isomorphisme. Ces notions sont importantes pour comprendre la catégorisation des familles de formes qui vont être mis en place plus tard dans la recherche. Dans les figures ci-dessous, nous pouvons voir comment cette compréhension topologique des homéomorphismes d’objets et d’espaces peut être d’une grande utilité dans le processus de conception, par exemple ici, nous allons concevoir une maison flottante qui est homéomorphe à tore T 2 . Toutes les transformations utilisées dans l’élaboration de la conception sont continue et réversible, à savoir qu’ils sont des transformations topologiques; ne conservant que les informations topologiques sur la forme. Dans ce qui suit nous allons donner des explications précises sur ce que sont ces informations topologiques, par exemple compacité et la connectivité. Homéomorphisme @8D HX, "X L, HY, "Y Lsont des espaces topologiques f : X Ø Y, est un homéomorphisme ó f est continue, bijective etson inverse f -1 est continue Isomorphisme @8D HX, dX L, HY, dY Lsont des espaces métriques, x, x' œ X f : X Ø Y, est un isomorphismeódY H f HxL, f Hx'LL = dX Hx, x'L Homotopie @9D HX, "X L, HY, "Y Lsont des espaces topologiques, f , g : Xö Y continue H : X ä@0, 1Dö Y " x œ X, HHx, 0L = f HxL et HHx, 1L = gHxLï H est une homotopie entre f , g Représentation des transformations homéomorphiques dans un processus de conception architecturale Maintenant nous arrivons à la caractérisation des espaces topologiques et métriques, en d’autres termes les propriétés qualitatives de ces espaces, les propriétés comme la compacité et la connectivité. Chacune de ces propriétés est intuitivement connu pour les architectes car ils pourraient être comprises phénoménologiquement sur les objets de l’espace physique tridimensionnel, mais depuis notre travail est dans l’espace mathématique formelle, nous allons fournir une description formelle de ces propriétés. Intuitivement un espace complet est un espace métrique sans points manquants, par exemple l’espace euclidien de nombres réels avec la métrique de distance habituelle est un espace complet. La compacité est plus intuitive du point de vue architectural, puisque la plupart des conceptions architecturales impliquent un enclos de quelque sorte; géométriquement ces enclos sont sous-ensembles compacts de l’espace euclidien, ce qui en soi n’est pas compact, car il n’est pas borné. Semblable à la compacité, la connexité est assez intuitive, un espace topologique connexe ne peut être représentée comme étant l’union d’ouverts non vides disjoints; une notion plus forte, qui est plus proche de notre notion de connexité dans le monde physique est celui de connexité par arc. Un espace connexe par arc, est un espace dans lequel deux points quelconques peuvent être reliés par un chemin continu, par exemple l’espace euclidien est connexe et connexe par arc mais pas compact. 28 | Espace complet [8] HX, dL est un espace métrique, HxnLn œ ! est une suite de X xn est une suite de Cauchy ó " e > 0 $ n œ " " p, q œ " avec p, q r n , dIxp, xqM < e HX, dL est complet ó " HxnLn œ ! une suite de Cauchy X , HxnLn œ ! est convergent HX, dL est complet HX, dL n’est pas complet Espace compact [8] HX, "L espace topologique, HAiLi œ I une famille de recouvrements ouverts de X ó X = ‹Ai i œ I si J Õ I et X = ‹Ai i œ J ï HAiLi œ J est une famille finie de recouvrementsHla propriété de Borel - LebègueL HX, "L estséparé et vérifie la propriété de Borel - Lebègue ï HX, "L compact HX, dL espace métrique , HxnLn œ ! est une suite de X x est une valeur de adhérence de HxnLn œ ! ó " r > 0 , " N œ " $ n r N dHx, xnL < r HX, dL est compactsi toute suite de X contient au moins une valeur d ' adhérence HX, dL est compacts' il est fermé et borné X = ‹Ai i œ I famille de recouvrements ouverts X = ‹Ai i œ J famille finie de recouvrements Espace connexe [8] HX, "L espace topologique, O1, O2 ouverts de X et F1, F2 fermés de X HX, "L est connexeó lesseules parties de X qui sont à la fois ouvertes et fermées sont f et X HX, "L est connexe ó si X = F1 ‹ F2 avec F1 › F2 = f ï soit F1 ou F2 = f HX, "L est connexe ó si X = O1 ‹O2 with O1 ›O2 = f ï soit O1 ou O2 = f HX, "L est connexe ó si f : X Ø 80, 1< continue ï f constante Connexité par arc [8] HX, dL espace métrique, x, y œ X f : @a, bD Ø X continue, f est un chemin de x à y, si f HaL = x et f HbL = y HX, dL est connexe par arc ó " x, y œ X $ f œ CH@a, bD, XL chemin de x à y | 29Composante connexe [8] HX, dL espace métrique, x œ X , $x = 8A œ !HXL A est connexe, x œ A< Cx = ‹A A œ !x est la composante connexe de x Hla plus grande partie connexe de X contenant xL Dx = 8y œ X $ f œ CH@a, bD, XL chemin de x à y< est la composante connexe par arc de x si x, y œ X x " y ï Cx = Cy or Cx › Cy = f et Dx Õ Cx C est simplement connexe D est connexe par arc Poursuivant dans nos définitions d’espaces, nous arrivons à la définition de l’espace vectoriel normé, c’est un type fondamental de l’espace, puisque l’espace euclidien du monde physique appartiennent à cette catégorie. Fondamentalement, un espace vectoriel normé est un espace vectoriel accompagnée d’une norme; plus tard, nous allons donner une définition détaillée de l’espace vectoriel lorsque nous aurons affaire à des opérations algébriques. Pour le moment, nous allons donner une définition générale des espaces vectoriels normés du point de vue de la topologie, pour cela, nous aurons besoin de définir la notion de norme et des applications linéaires. Espace vectoriel normé [8] E est un espace vectoriel sur un corps # H = ! ou $L N : Eö!+ , N est une norme sur E qui vérifie, " x, y œ E , " l œ # séparabilité : NHxL = 0 óx = 0E Hvecteur nulL homogénéité positif : NHl xL = †l§ NHxL inégalité triangulaire : NHx + yL b NHxL + NHyL ïHE, NL est un espace vectoriel normé si E = !n et N = °.¥ ï HE, NL = H!n , °.¥L est l' espace euclidien un espace vectoriel normé complet est appelé un espace de Banach ï l' espace euclidien est un espace de Banach Applications linéaires (caractérisation topologique) [8] HE, NEL, HF, NFL espaces vectoriels normés, x œ E, et f : EöF linéaire, alors f est continue ó f est continue en 0E , Lipschitz continue Hi.e. $ k > 0 NFH f HxLL b k NEHxLL ó f est bornée : un ouvert O de E, BEH0, 1L , BEH0, 1L et #BEH0, 1L Représentation de l’espace euclidien de dimension 3 comme I!3 , °.¥M 30 | ü 2.2.2. Construction d’une variété Avec ces constructions précédentes, nous sommes maintenant en mesure de définir la variété. Intuitivement, variétés en particulier de une et deux dimensions peuvent être considérées comme des généralisations des notions de courbes et de surfaces, qui sont les deux objets mathématiques de base pour la conception architecturale. Ainsi, afin d’étudier la conception architecturale du point de vue de la géométrie moderne, il faut comprendre des courbes et des surfaces non comme des objets physiques, mais comme des cas particuliers de leurs généralisations abstraites, nommément des variétés des une et deux dimensions. Les variétés sont des objets essentiels des mathématiques modernes, en plus de leur généralisation des notions de courbes et de surfaces, elles utilisent les idées de l’algèbre linéaire, la topologie et l’analyse, en outre, certaines catégories spéciales de variétés ont également une structure algébrique, ils peuvent se comporter comme des groupes, ils sont appelés groupes de Lie. Historiquement, la notion de variété est liée à la découverte de ce qu’on appelle géométries non euclidiennes, les enquêtes sur ce sujet ont commencé presque immédiatement après Euclide a écrit son livre Les éléments, interrogeant précisément le cinquième postulat également connu sous le postulat des parallèles. Le cinquième postulat dit que si une droite tombant sur deux droites fait les angles intérieurs du même côté plus petits que deux droits, ces droites, prolongées à l’infini, se rencontreront du côté où les angles sont plus petits que deux droits. Beaucoup de mathématiciens ont essayé de trouver une contradiction à ce postulat, à partir des mathématiciens musulmans de the11th, 12e et 13e siècles comme Ibn Al-Haytham, Omar Al-Khayam et Nasr El-Din al-Tusi, jusqu’à les mathématiciens européens du 18e siècle comme Giovanni Saccheri et Johann Lambert. Mais il n’était pas jusqu’au 19ème siècle avec les travaux des mathématiciens: Janos Bolyai, Nikolaï Lobatchevski, Carl Friedrich Gauss et Bernhard Riemann que les premiers traités de géométries hyperboliques et elliptiques ont été écrites, et il était Gauss qui a inventé le terme de géométrie non-euclidienne. Dans la théorie moderne, ces deux notions d’espaces elliptiques et hyperboliques correspondent aux variétés de courbure constante positive et négative; plus loin dans cette recherche, nous allons définir ces notions formellement. Hyperbolique Euclidien Elliptique Une variété est un espace topologique que près de chaque point ressemble à l’espace euclidien. Plus précisé- ment, chaque point d’une variété à n dimensions a un voisinage qui est homéomorphe à l’espace euclidien à n dimensions; dans cette recherche, nous allons nous concentrer uniquement sur variété différentiable. Variétés différentiables sont également variétés topologiques, mais avec une structure différentiable globale supplémentaire et qu’ils sont localement difféomorphe à l’espace euclidien. Nous allons définir la notion de difféomorphismes locaux / mondiaux avec la notion générale de différentiabilité plus tard, lorsque nous commençons la définition des opérations différentielles sur nos formes et espaces; pour le moment, nous allons donner des définitions générales des courbes et des surfaces comme variétés. Afin de définir des courbes et des surfaces les collecteurs, nous aurons besoin de définir la notion de sous-variétés en particulier, les sous-variétés de l’espace euclidien. Cette définition de nos courbes et surfaces en tant que sous variétés peut être effectué par divers façons; dans cette recherche, nous allons nous concentrer principalement sur deux façons: la submersion et l’immersion ou en d’autres termes des équations algébriques et paramétriques. Ensuite, nous allons montrer que ces sous-variétés de l’espace euclidien sont en eux-mêmes variétés, en choisissant des atlas dont les cartes sont des restrictions de la forme normale. Nous verrons aussi que l’immersion ou la définition paramétrique de nos formes est beaucoup plus pratique, du point de vue de la conception architecturale. Afin de définir la submersion et l’immersion nous aurons besoin de deux théorèmes importants de calcul différentiel: la théorème d’inversion locale et théorème des fonctions implicites (ces deux théorèmes seront définies avec la notion de différentiabilité plus loin dans la recherche). | 31Submersion @10D f : U Õ !pö !q C k submersion if " x œ U, f ' HxL estsurjective Immersion @10D f : U Õ !pö !q C k immersion if " x œ U, f ' HxL est injective Sous-variétés de !n [13] M Õ !n , si " x œ M $ U œ #x et V œ #0!n voisinages ouverts et une forme normale f f : U Õ !nö V Õ !n f HU › ML = V › !k ä80"n-k < ïM est une sous - variété de !n de k dimensions Représentation de la construction d’une sous-variété de !n de k dimensions Variété topologique [10] M est une variété topologique de n dimensionssi Mest un espace topologique séparé telle que " x œ M $ U Õ M ouvert , x œ U et V Õ !n h : UöV est un homéomorphisme Maintenant que nous avons défini la sous-variété nous allons maintenant définir formellement la variété différentiable, et pour ce faire, nous devrons définir quelques notions importantes: celle d’une carte, d’un atlas et celle de l’application de changement des cartes. Ce vocabulaire est assez familier à tout le monde, c’est tout simplement parce que les cartes et les atlas du globe sont des bons exemples de ce que nous essayons de faire. Carte d’une variété [10] M est une variété topologique, le couple HU, jL est une carte de M si U Õ M ouvert Hest appelé le domaine de jL et j : U Õ MöV Õ !n est un homéomorphisme HU1, j1L, HU2, j2L deux cartes de M, alorssi U1 › U2 " f etsi l' application de changement des cartes j2 Îj1 -1 : j1HU1 › U2Lö j2HU1 › U2L C k est un difféomorphisme ï HU1, j1L, HU2, j2L sont compatibles Atlas d’une variété [10] M est une variété topologique, HUi , jiLiœI une famille de cartes dont les domainesHUiLiœI recouvrent M ï $ = HUi , jiLiœI est un atlas de M $ est de classe C k si " i, j œ I, les cartesHUi , jiL, IUj , jj Msont compatibles $ est maximale si elle contient toutesles cartes compatibles avec ses propres cartes ï un atlas maximal $ de classe C k est appelé une structure différentielle de classe C k ïune variété différentiable de classe C k est une variété topologique avec une structure différentielle de classe C k ïune variété lisse est une variété différentiable de classe C ¶ Hle seul type que nous allons utiliserL 32 | Les courbes et les surfaces en tant que sous variétés de l’espace euclidien sont en eux-mêmes variétés en choisissant des atlas dont les cartes sont des restrictions de forme normale, à partir de maintenant, les termes courbe et la surface se réfèrent à variétés différentiables des une et deux dimensions. Sous-variété comme une variété [10] S Õ !n est une sous - variété de l' espace euclidien !n j : U Õ !n ö V Õ !n jHU › SL = V › !k ä80"n-k < est une forme normale la restriction de j à S ï HU, j SL est une carte de S ï$ = IUi , ji S M iœI est un atlas maximal de S dont les cartesHformes normales restreintesLsont compatibles ïS est une variété différentiable dont l' atlasHstructure différentielleL est $ Sous-variété S (défini par des équations) [10] S Õ !n , si " x œ S $ U Õ !n , x œ U et une submersion f f : U Õ !nö !n-k U › S = f -1 H80"n-k < L ïS est une sous - variété de !n de k dimensions pour n = 3 ï si k = 1, S est une courbe, etsi k = 2, S est une surface Hhypersurface etsi n - k = 1L Sous-variété S (défini par le paramétrage local) [10] S Õ !n , si " p œ S $ V Õ !n , p œ V et $ U Õ !k , 0"k œ U et une immersion c : U Õ !kö !n cHUL = V › S homéomorphisme ïS est une sous - variété de !n de k dimensions pour n = 3 ï si k = 1, S est une courbe, etsi k = 2, S est une surface Hhypersurface etsi n - k = 1L Représentation de la définition paramétrique de la surface S dans !3 Ces constructions sont les bases fondamentales dont nous avons besoin avant de commencer toute opération de géométrie différentielle sur la variété, même si ces constructions d’espaces formels (ou variétés) semblent tout à fait abstrait, Intuitivement, tous tournent autour d’une idée simple. Qui est: une variété cependant courbée ou de forme complexe, il est traité localement comme espace vectoriel plat, ce “traité” localement signifie qu’il est difféomorphe à un espace vectoriel plat qui est tout à fait familier et où nous pouvons faire toutes nos opérations de l’algèbre et l’analyse. Nous allons étudier cela en détail, lorsque nous allons travailler sur les opérations analytiques, et là nous allons montrer une famille de techniques pour extraire des informations à partir d’une variété en les amenant localement dans les cartes à un espace vectoriel plat. En fait, quand les architectes ont une surface courbe, ils l’appellent un objet en trois dimensions, alors qu’en fait, il est un objet de deux dimensions plongé ou immergé (selon la surface) dans l’espace euclidien habituel de trois dimensions. | 33ü 2.3. Références [1] Cézanne’s doubt, Maurice Merleau-Ponty, 1945 [2] Phenomenology of perception, Maurice Merleau-Ponty, 1945 [3] Critique of pure reason, Immanuel Kant, 1781 [4] Ideas I, Edmund Husserl, 1913 [5] Formal and trancendental logic, Edmund Husserl, 1929 [6] Architecture and the crisis of modern science, Alberto Perez-Gomez, MIT press, Cambridge, Massachussets, 1985 [7] Building, dwelling, thinking, Martin Heidegger, trans. A.Hofstadter, New York, 1971 [8] Cours de Topologie generale, Sylvain Durand, Université Paris Descartes, Paris, 2011 [9] Cours de Topologie algébrique, Julien Marché, Université Pierre et Marie Curie, Paris, 2012 [10] Cours de Géométrie Différentielle, Laurent Charles, Université Pierre et Marie Curie, Paris, 2012 34 | 3. Définition de la forme ü 3.1. Définition paramétrique de courbes et de surfaces Jusqu’à ce point, nous étions occupés à préparer le terrain pour la constructions mathématiques qui formeront l’essentiel de cette recherche; ces constructions mathématiques peuvent être considérés comme de deux familles: les définitions de la forme et des opérations sur la forme, et maintenant nous allons commencer avec la première famille: la définition de la forme. La distinction entre les définitions et des opérations n’est pas une distinction mathématique, mais elle découle de la vision de cette recherche du processus de la conception. À savoir, nous commençons par définir une forme initiale, puis appliquer des opérations à elle afin de la rapprocher de la forme finale souhaitée. Dans ce qui suit, nous allons montrer deux types principaux de la définition de la forme mathématiquement, à savoir paramétriquement et algébriquement venant de la définition des variétés par paramétrisation locale et par une équation algébrique. Toutefois, le but est d’amener toutes les définitions à une définition paramétrique qui est la forme la plus adéquate pour les opérations telles qu’elles sont définies dans cette recherche. Avant de passer à notre premier type de définitions: la définition paramétrique de courbes et de surfaces, il convient de mentionner que même si le mot paramétrique nous rappelle immédiatement à l’expression: l’architecture paramétrique; il faut distinguer la définition paramétrique de formes architecturales (courbes et surfaces) du terme: l’architecture paramétrique. Bien entendu, la définition paramétrique des courbes et des surfaces est comprise dans la notion générale de l’architecture paramétrique, mais ce n’est pas la seule interprétation de celui-ci. Le terme: l’architecture paramétrique est sans doute le mot plus abusé dans l’architecture contemporaine, et, naturellement, il est très difficile de trouver une définition unifiée pour elle. Le terme: l’architecture paramétrique est sans doute l’expression la plus abusé dans l’architecture contemporaine, et, naturellement, il est très difficile de trouver une définition unifiée pour. Le terme est aussi synonyme à d’autres termes tels que: conception numérique, conception computationnelle, de modélisation associative et la fabrication numérique, il existe un grand nombre d’œuvres de la théorie architecturale développées autour de ce terme, chacun essayant de le définir et de le transformer en une forme ou d’une autre. En tout cas, cette recherche ne cherche pas à faire la même chose, au lieu de l’utilisation du mot: paramétrique ici est strictement dans son sens mathématique. Avec ce dit que nous commençons par montrer les bases de définitions paramétriques de formes, à savoir quel est un paramètre et quels sont ses avantages et ses inconvénients. Dans une fonction mathématique, par exemple f HxL = a x2 + b x + c, f est définie par la variable x et les constantes a, b, c où la variable x est dans la liste des arguments, alors que les constantes a, b, c ne soient pas, mais leur présence définit toute une famille de fonctions une pour chaque ensemble de valeurs de ces constantes. Ces constantes sont appelés paramètres mais dans la définition paramétrique de courbes et surface, nous renvoyons également aux variables indépendantes comme paramètres, qui découle de la notion de l’équation paramétrique d’une courbe ou d’une surface. La définition paramétrique des courbes et des surfaces est l’une des plus directe et facile à manipuler; ceci lui fait une des définitions les plus adaptés pour l’utilisation dans la production de la forme architecturale. La définition paramétrique est une méthode de définition d’une relation à l’aide des paramètres, pour l’essentiel, il définit la relation comme un ensemble d’équations; par conséquent, il est défini plus précisément comme une représentation paramétrique. Cette façon d’exprimer des courbes et des surfaces est pratique ainsi que l’efficacité, par exemple, on peut intégrer et dériver les courbes et surfaces terme à terme, en outre, la représentation paramétrique de courbes, a tendance à être inappropriés à l’utilisation dans des applications de CAO. Et il n’est pas de s’adapter facilement aux transformations géométriques, comme des rotations, des translations et mise à l’échelle. En outre, la représentation implicite est gênant pour produire des points sur une courbe ou sur une surface, parce que les valeurs de x peuvent être choisis de telle manière que le point ne se trouve pas sur la courbe ou de la surface. Ces problèmes sont éliminés par la réécriture des équations sous forme paramétrique, pour ces raisons, les opérations définies plus tard sont adaptées aux définitions paramétriques de courbes et de surface, le seul problème est que les définitions paramétriques a ses limites. | 35Exemple de base de la variation de forme basée sur le changement des paramètres Le cercle unité est définie par a : @0, 2 pD Õ !ö!2 , aHtL = HCosHtL, Sin HtLL L' ellipse est définie par b : @0, 2 pD Õ !ö!2 , bHtL = H4 CosHtL, 2 Sin HtLL Il est clair que l’équation du cercle est une forme spécifique de l’équation de l’ellipse où les fonctions coordonnées Hx, yLsont H1 CosHtL, 1 SinHtLL au lieu de H4 CosHtL, 2 SinHtLL. Là, nous définissons une équation générale où 2 et 4 ne sont pas fixes mais les valeurs sont des paramètres a, b et aboutissant à l’équation: f : @0, 2 pD Õ !ö!2 , f HtL Ha, bL = Ha CosHtL, b Sin HtLL Représentation de la génération d’un cercle et d’une ellipse en changeant les paramètres La même analogie peut être faite avec des surfaces qui peuvent être vus comme une généralisation des courbes à savoir une application f : !2ö!3 (une définition plus élaborée de courbes et de surfaces paramétrées sera montré plus tard). Cette idée semble si simple, est très important dans cette recherche, il montre simplement comment les variations de la forme peuvent être produites.Variation qui sont utilisés pour tester le potentiel de la forme en termes d’esthétique, de la structure, etc. Avant de montrer la puissance et l’étendue de cette méthode pour générer des formes architecturales, nous allons d’abord sur les définitions formelles de courbes et surfaces paramétriques, ces définitions nécessite certaines notions importantes que nous allons définir plus tard dans la section des opérations analytiques. Donc, pour le moment, nous allons donner une formalisation générale pour une courbe régulière et pour une surface régulière. Courbe régulière [1] g : Ha, bL ö!2 , gHtL = HxHtL, yHtLL est une courbe régulière H°g' HtL¥ " 0L et différentiables par morceaux a : Ha, bL Õ ! ö!3 est une courbe régulière if " t œ Ha, bL , a est différentiable et °a' HtL¥ " 0"I","3 M si " t œ Ha, bL , °a' HtL¥ = 1 alors a a une vitesse unité Surface régulière [1] % Õ !2 open, q œ % and p = cHqL c : %ö& Õ !3 , cHu, vL = Hx1Hu, vL, x2Hu, vL, x3Hu, vLL is a regular injective patch Ha regular surfaceL Il est vrai que ce n’est pas intuitif concevoir en utilisant des formules. Cela découle de notre notion de dessin à la main qui se sent comme interpolation travers des points invisibles. C’est pour cela que l’interpolation est la méthode la plus populaire pour le dessin parmi les architectes et il n’est pas surprenant que tous les logiciels de CAO est basé sur une forme ou une autre de points l’interpolation, que ce soit splines cubiques ou nurbs. Nous allons montrer prochain, que la conception en utilisant des formules peut être intuitif après un certain temps et très manipulatrice comme les interpolations. Le point de départ naturel pour une telle tâche est d’examiner certaines des courbes et des surfaces classiques en !3 , comprendre comment elles fonctionnent et ensuite commencer à construire de nouvelles formules sur elles. Il existe des exemples fondamentaux, que les comprendre constitue la base de la création de formules pour de nouvelles courbes et des surfaces. Les exemples suivants de courbes sont très utiles dans la conception, en particulier l’épicycloïde qui est la plus élaborée. 36 | Quelques courbes de base [1] Nous allons maintenant donner les formules de base pour les paramétrages de quelques courbes classiques, l’idée est simplement que par la compréhension de la façon dont leurs traces se rapportent à leur paramétrage, nous serons en mesure de construire nos propres courbes d’une certaine forme conçue. L' ellipse g : U Õ @0, 2 pD Õ !ö!2 , gHtL = Ha CosHtL, b Sin HtLL , avec U ouvert La spirale d ' or g : U Õ @0, 2 pD Õ !ö!2 , gHtL = Ia ‰ b t CosHtL, a ‰ b t SinHtLM , avec U ouvert L' épicycloïde g : U Õ @0, 2 pD Õ !ö!2 , avec U ouvert gHtL = Ha Hb + 1L CosHtL - a CosHHb + 1L tL, a Hb + 1L SinHtL - a SinHHb + 1L tLL L' hélice a : U Õ @0, 4 pD Õ !ö!3 , aHtL = Ha CosHtL, a SinHtL, b tL , avec U ouvert Le noeud de tore a : U Õ @0, 2 pD Õ !ö!3 , avec U ouvert aHtL = HH8 + 3 CosH5 tLL CosH2 tL, H8 + 3 CosH5 tLL SinH2 tL, 5 SinH5 tLL | 37Quelques surfaces de base [1] Même que nous n’avons pour les courbes, nous allons faire pour les surfaces, les surfaces montrent ci-dessous seront les traces d’une des surfaces locales injectives réguliers, en d’autres termes chacun d’eux est paramétrée par une seule carte, et & = c(%) une surface régulière. Encore une fois l’idée est simplement que par la compréhension de la façon dont ces traces se rapportent à leur paramétrage, nous serons en mesure de construire nos propres surfaces d’une certaine forme conçue. Le plan !2 Hi.e. Graphe d ' une fonction hL h : % Õ @0, 2 pD 2ö! fonction réelle différentiable de deux variables c : % Õ @0, 2 pD 2ö& Õ !3 est une surface locale régulière, où % ouvert hHu, vL = SinHuL SinHvL cHu, vL = Hu, v, a hHu, vLL Le cylindre IS 1 ä !M c : % Õ @0, 2 pD 2ö& Õ !3 est une surface locale régulière, où % ouvert cHu, vL = Ha CosHuL, b SinHuL, c vL La sphère S 2 c : % Õ @0, 2 pD 2ö& Õ !3 est une surface locale régulière, où % ouvert cHu, vL = Ia CosHuL SinI v 2 M, b SinHuL SinI v 2 M, c CosI v 2 MM Le tore T 2 c : % Õ @0, 2 pD 2ö& Õ !3 est une surface locale régulière, où % ouvert cHu, vL = HCosHuL Ha + b CosHvLL, SinHuL Ha + b CosHvLL, c SinHvLL 38 | Modification d’une courbe standard Ces courbes et surfaces classiques peuvent être utilisés comme base pour les construction de formules décrivant les formes souhaitées. Ceci est fait par des adaptations de ces courbes et des surfaces classiques, ces adaptations peuvent être modification de leurs formules ou par des combinaisons de différents types. Premier exemple de ces adaptation serait que de passer de l’hélice spirale à une courbe horizontale allongée. Ceci peut également être considéré comme une fusion entre la spirale et l’hélice. Un autre exemple plus élaboré est l’adaptation de l’épicycloïde (avec une cuspide i.e. cardioïde) à une courbe en forme de coeur. Ici, la modification de la formule est plus fondamental, mais l’esprit de l’épicycle reste présent dans la courbe en forme de coeur. Spiral hélice à la courbe en spirale allongée L’équation de l’hélice spirale est donnée par b : U Õ @0, 4 pD Õ !ö!2 , aHtL = Kt, 2 ‰ -2 25 t SinHtL, 2 ‰ -2 25 t CosHtLO et est ensuite modifié pour j : U Õ @0, 4 pD Õ !ö!3 , jHtL = It + SinI t 2 M - 1 100 SinHtL, SinI t 2 M, 1 - CosHtL + SinI t 2 MM Représentation de la modification de l’hélice spirale Épicycloïde (avec une cuspide i.e. cardioïde) à une courbe en forme de coeur L’équation de l’épicycloïde est donnée par b : U Õ @0, 2 pD Õ !ö!2 , aHtL = H2 SinHtL - SinH2 tL, 2 CosHtL - CosH2 tLL et est ensuite modifiée pour l’équation de la courbe en forme de coeur a : U Õ @0, 2 pD Õ !ö!2 , aHtL = ISinHtL 3 , I 5 3 + CosHtLM HCosHtL H1 - CostHtLLLM Représentation de la modification de cardioïde | 39Modification d’une surface standard La même maintenant peut être fait pour les surfaces, nous pouvons commencer à partir d’une forme générale classique d’un ellipsoïde et l’adapter à une surface en forme de coeur. Sphère à une surface en forme de coeur L’équation de la sphère est donnée par b : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , bHu, vL = ISinI v 2 M CosHuL, SinI v 2 M SinHuL, I1 - CosI v 2 MMM et est ensuite modifiée pour l’équation de la surface en forme de coeur c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = I 2 3 CosHuL SinI v 2 M 5 , 1 2 SinHuL SinI v 2 M 5 , 2 3 I 5 3 + CosI v 2 MM CosI v 2 M I1 - CosI v 2 MM + 1M Représentation de la modification de la sphère Ces exemples donnent une idée de la façon dont certaines formes en général peuvent être dérivées des formes géométriques classiques (comme l’ellipse et l’ellipsoïde), mais dans le but de prendre ce au niveau de la conception architecturale, nous avons besoin d’une technique beaucoup plus manipulable. Nous allons montrer que les formes que nous allons concevoir, sont des variantes de la sphère S 2 , le tore T 2 , le cylindre IS 1 ä !M et le plan !2 . Si nous sommes en mesure de contrôler la révolution d’une certaine courbe de profil, nous pouvons parvenir à une assez grande variété de formes précisément conçus. Dans la sphère S 2 , la courbe de profil est un demi-cercle et la courbe de révolution est un cercle. Dans le tore T 2 , la courbe de profil et la courbe de révolution sont tous les deux cercles. Dans le cylindre IS 1 ä !M, la courbe de profil est une ligne et la courbe de révolution est un cercle. Dans le plan !2 , les deux courbes de paramétrage sont des lignes. L’ensemble des exemples suivant montrent comment nous pouvons être très élaboré dans le travail sur les deux courbes de paramétrage dans les directions u et v, et arriver à des formes qui peuvent facilement être utiles dans l’architecture. Les quatre familles de surfaces que nous serons concernés par sont: la sphère S 2 , le tore T 2 , le cylindre IS 1 ä !M et le plan !2 , les deux premiers sont compact, le cylindre et le plan !2 sont noncompact. Il est important de savoir que nous pouvons construire des surfaces continues paramétrés par une seule carte seulement jusqu’au degré 1 (du genre topologique). Pour la construction de formes qui ont deux ou plusieurs trous, soit nous utilisons plusieurs surfaces paramétriques locales ou de définir la forme algébriquement à savoir comme un ensemble de zéros d’une fonction de trois variables. 40 | ü 3.2. Familles de surfaces Afin que nous construisons une recherche concluante, nous devons nous limiter à quelques familles de surfaces qui couvrent une grande variété de types de bâtiments architecturaux et alors nous pouvons bien les modifier et de les analyser. Pour cette tâche, nous allons limiter nous-mêmes sur des surfaces qui peuvent être paramétrées par une seule surface locale. Homéomorphe au plan !2 (graphe hHu, vL) Ce type de surfaces est très utile pour la conception de bâtiments de faible hauteur, couvrant d’une parcelle rectangulaire. La surface n’est que le graphique de la fonction h : Hu, vL œ !2ö!, il est relativement facile à comprendre que les autres types et il est adapté pour des conceptions architecturales des grands espaces comme des ateliers, des salles de sport et de petites usines. Ici, les deux courbes de paramétrage sont des courbes ouvertes. nous commençons par construire l' équation h h : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, hHu, vL = I 1 - 1 2 Sin HuL SinHvL - SinI v 2 M 45 + CosHvL 2 M I1 - CosI u 2 M 90M I1 - CosI v 2 M 90M puis nous mettrons h dansl' équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = Hu, v, hHu, vLL cHu, vL = Iu, v, I 1 - 1 2 Sin HuL SinHvL - SinI v 2 M 45 + CosHvL 2 M I1 - CosI u 2 M 90M I1 - CosI v 2 M 90MM Représentation d’une courbe de paramétrage dans la direction u Représentation de la famille de surfaces homéomorphes au plan !2 (graphe hHu, vL) | 41Application architecturale Maintenant que nous avons défini cette famille de surfaces, nous allons montrer un exemple concret de la façon dont cette surface peut être utilisé comme forme architecturale. Dans cet exemple, une fois que nous fixons les famille de surfaces, nous commençons à rechercher des variations en faisant simplement varier les paramètres de l’équation de base ci-dessus jusqu’à ce que nous allons faire un choix de la surface qui va être l’enveloppe du bâtiment en fonction de certains critères. Représentation de l’exploration de différentes surfaces de cette famille Représentation d’une conception architecturale choisie de cette famille de surfaces 42 | Homéomorphe au plan !2 (non graphe) Ce type de surfaces est également très utile pour la conception de bâtiments de faible hauteur, couvrant d’une parcelle non rectangulaire. Bien que cette famille de surfaces est également homéomorphes au plan !2 ce n’est pas un graphe hHu, vL cela signifie que le terrain que nous couvrons peut également prendre diverses formes. on commence par la construction de l’équation de la courbe u f0 : U Õ @0, 2 pD Õ !ö!, f0HuL = u + 4 5 SinHuL f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = 2 + CosI 3 2 u + pM f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = 1 + 1 5 Sin 3 2 u +p 2 20 f3 : U Õ @0, 2 pD Õ !ö!, f3HuL = 1 2 I1 - CosI u 2 M 20M f : U Õ @0, 2 pD Õ !ö!2 , f HuL = H f0HuL, f1HuL f2HuL f3HuLL puis nous construisons la courbe v g0 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g0Hu, vL = H2 + CosHn u + pLL I Hv - pL + 1 10 SinH2 vLM g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = 2 - CosH2 vL g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 1 + 1 10 CosI2 v 2 M 20 g3 : U Õ @0, 2 pD Õ !ö!, g3HvL = 1 2 I1 - CosI v 2 M 20M g : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2 , gHu, vL = Hg0Hu, vL, g1HvL g2HvL g3HvLL et enfin nous composons les deux applications dans l’équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = I f0HuL, 1 4 g0Hu, vL, 1 2 g1HvL g2HvL g3HvL f1HuL f2HuL f3HuLM cHu, vL = Ju + 4 SinHuL 5 , 1 4 I2 - CosI 3 u 2 MM IHv - pL + 1 10 SinH2 vLM, 1 8 I1 - CosI u 2 M 20M I2 - CosI 3 u 2 MM J1 + CosHvL 20 10 N I1 - CosI v 2 M 20M H2 - CosH2 vLL J1 + 1 5 SinI 1 2 Ip + 3 u 2 MM20NN Représentation de la courbe u Représentation de la famille de surfaces homéomorphes au plan !2 (non graph) | 43Application architecturale Comme dans l’exemple précédent, nous allons fixer une famille de surfaces et commence alors à rechercher les variations de la surface de base de cette famille qui seraient appropriés pour la conception de l’enveloppe du bâtiment. Il ressort clairement de ces variantes sélectionnées de la surface que l’espace de recherche de surfaces de la même famille peut être très grande, ce qui permet une grande quantité d’options à choisir et adapté à de nombreuses applications architecturales. Représentation de l’exploration de différentes surfaces de cette famille Représentation d’une conception architecturale en utilisant cette famille de surfaces 44 | Homéomorphe au cylindre IS 1 ä !M Ce type de surfaces construction est très utile pour la conception des tours, intuitivement la peau de tours et immeubles de grande hauteur sont homéomorphes au cylindre IS 1 ä !M. La même méthode de la courbe de révolution u et la courbe de profil v est utilisé ici, mais avec plus de précisions sur la courbe de révolution u. On peut voir cette courbe comme la base du plan de l’étage à un niveau donné, et en changeant le niveau, la forme de la courbe de révolution (i.e. de plan de l’étage) seront également changer. Comme nous le savons le niveau est rien que la valeur de la courbe de profil v à une v fixée En d’autres termes, nous pouvons voir la courbe de la révolution en termes de Hu, vL au lieu de seulement u. L’exemple suivant illustre cette construction. on commence par la construction de l’équation de la courbe de révolution u f1 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, f1Hu, vL = CosHuL 1 - J 9 10 v-pN p SinH2 uL 4 f2 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, f2Hu, vL = SinHuL 1 - J 9 10 v-pN p SinH2 uL 4 f : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2 , f Hu, vL = H f1Hu, vL, f2Hu, vLL puis nous construisons la courbe de profil v g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = 1 + SinHvL 2 g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 2 Hv - SinHvLL g : U Õ @0, 2 pD Õ !ö!2 , gHvL = Hg1HvL, g2HvLL et enfin nous composons les deux applications dans l’équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = H f1Hu, vL g1HvL, f2Hu, vL g1HvL, g2HvLL cHu, vL = CosHuL 1 - J 9 10 v-pN SinH2 uL 4 p I1 + SinHvL 2 M, SinHuL 1 - J 9 10 v-pN SinH2 uL 4 p I1 + SinHvL 2 M, 2 Hv - SinHvLL Représentation de la courbe de profil et les famille de surfaces homéomorphes au cylindre IS 1 ä !M | 45Homéomorphe au disque unité ID1 M Ce type de surfaces appartiennent à la famille surface homéomorphe au disque unité ID1 M, ils peuvent être considérés comme graphes sur des domaines non rectangulaires. Ils sont utiles dans la conception de bâtiments de faible hauteur, on distingue deux cas: homéomorphes au disque unité et homéomorphes à une Couronne. on commence par la construction de l’équation de la courbe de révolution u f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = I1 + I 1 2 SinH2 uL 3 MM I 13 10 + CosHuL 5 M CosHuL f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = I1 + I 1 2 SinH2 uL 3 MM I 13 10 + CosHuL 5 M SinHuL f : U Õ @0, 2 pD Õ !ö!2 , f HuL = H f1HuL, f2HuLL puis nous construisons la courbe de profil v g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = v g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 3 SinI v 2 M g : U Õ @0, 2 pD Õ !ö!2 , gHvL = Hg1HvL, g2HvLL et enfin nous composons les deux applications dans l’équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = H f1HuL g1HvL, f2HuL g1HvL, g2HvLL cHu, vL = Iv CosHuL I 13 10 + CosHuL 5 M I1 + 1 2 SinH2 uL 3 M, v SinHuL I 13 10+ CosHuL 5 M I1 + 1 2 SinH2 uL 3 M, 3 SinI v 2 MM Représentation de la courbe u Représentation de la famille de surfaces homéomorphes au disque unité ID1 M 46 | Application architecturale Encore une fois le même procédé est appliqué, à savoir une famille de surfaces est fixe et ensuite une recherche de variantes est réglée en modifiant les paramètres de l’équation de base de la paramétrisation, et à nouveau comme dans les exemples précédents l’espace des variations est assez grande, ce qui permettra une riche variété de choix. Ces sélections peuvent être simplement basés sur les choix esthétiques ou comme nous allons voir plus tard dans la recherche basée sur des modèles de recherche algorithmiques. Représentation de l’exploration de différentes surfaces de cette famille Représentation d’une conception architecturale en utilisant cette famille de surfaces | 47Homéomorphe à la sphère (S 2 ) Ce type de surface est tout à fait utile pour la conception de l’enveloppe du bâtiment continu (i.e. la façade continuant sur le toit). Cette famille de formes est devenu très populaire dans l’architecture dans les deux dernières décennies en raison de l’intérêt des architectes dans la «continuité» comme caractéristique de la forme. Pour cette raison, la construction des équations qui génère des formes qui sont homéomorphe à la sphère S 2 est très utile du point de vue de la conception architecturale contemporaine. on commence par la construction de l’équation de la courbe de révolution u f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = CosHuL + 5 2 CosI u 2 M 8 f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = 2 SinHuL f : U Õ @0, 2 pD Õ !ö!2 , f HuL = H f1HuL, f2HuLL puis nous construisons la courbe de profil v g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = 3 2 I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = v - SinHvL g : U Õ @0, 2 pD Õ !ö!2 , gHvL = Hg1HvL, g2HvLL et enfin nous composons les deux applications dans l’équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = H f1HuL g1HvL, f2HuL g1HvL, g2HvLL cHu, vL = I 3 2 ICosHuL + 5 2 CosI u 2 M 8 M I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM, 3 SinHuL I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM, v - SinHvLM Représentation de la courbe u Représentation de la famille de surfaces homéomorphes à la sphère S 2 48 | Homéomorphe au tore (T 2 ) Ce type de surfaces est très utile pour la conception de bâtiments de faible hauteur, qui a un atrium ou d’une cour. Dans cette construction, on définit des équations pour les surfaces avec une courbe de révolution u fermé. on commence par la construction de l’équation de la courbe de révolution u f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = I3 CosHuL - 1 5 CosH3 uLM J1 + 7 10 SinI 3 2 uM 3 N I1 + 1 2 SinIu - p 4 M 2 M f2 : U Õ @0, 2 pD Õ !ö!, f1HuL = 3 2 I3 SinHuL - 1 5 SinH3 uLM J1 + 7 10 SinI 3 2 uM 3 N I1 + 1 2 SinIu - p 4 M 2 M f : U Õ @0, 2 pD Õ !ö!2 , f HuL = H f1HuL, f2HuLL puis nous construisons la courbe de profil v g1 : U Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g1Hu, vL = 3 2 + CosHvL g2 : U Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g2Hu, vL = 2 SinHvL J1 + 6 5 SinI 3 2 uM 2 N g : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2 , gHu, vL = Hg1Hu, vL, g2Hu, vLL et enfin nous composons les deux applications dans l’équation finale de la surface c : % Õ @0, 2 pDä@0, 2 pDö!3 , cHu, vL = H f1HuL g1Hu, vL, f2HuL g1Hu, vL, g2Hu, vLL cHu, vL = JI3 CosHuL - 1 5 CosH3 uLM I 3 2 + CosHvLM J1 + 7 10 SinI 3 2 uM 3 N J1 + 1 2 SinIu - p 4 M 2 , 3 2 I 3 2 + CosHvLM I3 SinHuL - 1 5 SinH3 uLM J1 + 7 10 SinI 3 2 uM 3 N I1 + 1 2 SinIu - p 4 M 2 M, 2 SinHvL J1 + 6 5 SinI 3 2 uM 2 NN Représentation de la courbe u Représentation de la famille de surfaces homéomorphe au tore T 2 | 49Application architecturale Dans ce dernier exemple, on voit à nouveau le même processus de génération de variations basées sur la modification des paramètres de l’équation de paramétrisation de base, suivie d’une sélection d’une variante qui va être utilisé comme l’enveloppe du bâtiment. Cependant, nous voyons dans cet exemple, le panneautage de la surface choisie par un composant architectural, ce processus, nous allons expliquer en détail plus tard avec les opérations algorithmiques. Représentation de l’exploration de différentes surfaces de cette famille Représentation d’une conception architecturale en utilisant cette famille de surfaces 50 | ü 3.3. Définition algébrique (non paramétriques) des courbes et des surfaces Maintenant que nous avons défini nos familles de surfaces paramétriquement, nous allons maintenant explorer la définition des courbes et des surfaces par des équations polynomiales, nous avons déjà vu cette définition quand nous avons défini les variétés par des équations. Comme nous l’avons mentionné avant la définition algébrique des courbes et des surfaces n’est pas aussi simple que la définition paramétrique, mais il peut s’avérer plus efficace dans la conception des formes plus complexes. Il s’agit d’une définition beaucoup plus généralisée des courbes et des surfaces et avec elle, nous sommes capables d’atteindre des formes plus complexes et élaboré, le problème est qu’il est théoriquement plus complexe et moins pratique en termes de manipulations par des opérations. Cependant, il est important de donner une idée de définitions algébriques, car dans la conception architecturale bien sûr nous devons explorer les conceptions de l’enveloppe des bâtiments qui vont au-delà d’un seul paramétrage d’une surface locale. Par exemple, les formes qui ont plus d’un trou, comme le tore à n-trous, qui pourrait être utile dans la conception des bâtiments à plusieurs cours, ici il est clair que nous aurons besoin de plus qu’une seule surface locale pour couvrir cette surface. Dans ces cas, la stratégie est de trouver une équation polynomiale, puis de décrire la surface comme l’ensemble des zéros de cette équation, puis de trouver des surfaces locales (traités comme des graphes) sur ces surfaces en utilisant les théorème des fonctions implicites. Avec cette technique, nous pouvons appliquer toutes les opérations algébriques, analytiques et algorithmiques nécessaires afin de manipuler et de transformer la forme selon la conception désirée. Avant de commencer, nous aurons besoin de quelques notion importante de la géométrie algébrique, la première serait l’hyper-plan et ensuite l’hyper-surface, puis nous allons commencer par définir les plus élémentaires de définitions algébriques de courbes et de surfaces à savoir les coniques et les quadriques. Après cela, nous allons explorer certaines des surfaces algébriques plus complexes et belles et essayer de trouver des paramétrages pour eux. Représentation de la surface de genre avec deux trous (paramétrage en deux surfaces locales) | 51Hyper plan de !n [2] L œ H!n L * l' espace dual de !n L : !nö !, L Hx1, ..., xnL = a1 x1 + ... + an xn + a0, $ i œ 81, ..., n< ai " 0 H = 8Hx1, ..., xnL œ !n LHx1, ..., xnL = 0< = ker L est un hyper plan Hyper surface de !n [2] P œ QkH!L est un polynôme de degré k à n variables G = 8Hx1, ..., xnL œ !n PHx1, ..., xnL = 0< = ker P est une hyper surface Les formes non linéaires les plus simples seraient ceux du degré 2, dans le cas des courbes, elle est appelée coniques et dans le cas des surfaces, elle est appelée quadriques Quadriques de !n [2] P œ Q2H!L est un polynôme de degré 2 en n variables G = 9Hx1, ..., xnL œ !n PHx1, ..., xnL = ⁄i=1 n aii xi + ⁄i, j=1 n bij xi x j + c = A t x + x B t x + c = 0= , avec A, B œ MnH!L et c œ ! n = 2 ï G est une conique et n = 3 ï G est une quadrique Les coniques de !3 [2] Les plus basiques des courbes algébriques sont les coniques, leur importance dans l’architecture est très significatif, à savoir ils sont largement utilisés en raison de leurs capacités structurelles. Nous avons déjà paramétrages de ces courbes, maintenant, nous allons donner leurs définitions implicites. L' ellipse f : !2ö !, f Hx, yL = x 2 a 2 + y 2 b 2 - 1 G = 9Hx, yL œ !2 f Hx, yL = 0= = ker f La parabole f : !2ö !, f Hx, yL = y - a x2 G = 9Hx, yL œ !2 f Hx, yL = 0= = ker f L' hyperbole f : !2ö !, f Hx, yL = x 2 a 2 - y 2 b 2 - 1 G = 9Hx, yL œ !2 f Hx, yL = 0= = ker f 52 | Les quadriques de !3 [2] Après avoir défini les coniques nous allons maintenant définir leurs équivalents en deux dimensions à savoir les surfaces quadriques, leur nom, bien sûr vient du fait que leurs polynômes sont tous de second degré (équation quadratique).e all of second degree (quadratic equation). Tout comme les coniques nous avons des paramétrisations de ces quadriques, mais nous allons maintenant les définir comme l’ensemble des zéros de leurs polynômes. Dans la suite, nous allons présenter quelques exemples classiques importants de quadriques non dégénérée / dégénérés de !3 . L' ellipsoid f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 + z 2 c 2 - 1 G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f Le paraboloïde elliptique f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 - z G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f Le paraboloïde hyperbolique f : !3ö !, f Hx, y, zL = x 2 a 2 - y 2 b 2 - z G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f | 53Encore de Quadrics de !3 [2] Le cône elliptique f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 - z 2 c 2 G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f Le cylindre elliptique f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 - 1 G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f L’hyperboloïde f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 - z 2 c 2 - 1 , G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f Hune nappeL f : !3ö !, f Hx, y, zL = x 2 a 2 + y 2 b 2 - z 2 c 2 + 1 , G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f Hdeux nappesL Hyperboloïde une nappe Hyperboloïde deux nappes 54 | ü 3.3.1. Paramétrage de la surface algébrique Maintenant on va prendre quelques exemples de surfaces ne pouvant pas être paramétrées en utilisant une seule surface locale et essayer de les paramétrer en utilisant plusieurs cartes, comme nous l’avons mentionné plus tôt que cela est possible en utilisant le théorème des fonctions implicites. L’idée est de trouver des voisinages ouverts V Õ !3 , W Õ !2 et une fonction h : Wö!2 de classe C 1de telle sorte que chaque point Hx, y, zL œ V avec f Hx, y, zL = 0 (i.e. se trouvant sur la surface) si et seulement si la coordonnée z peut être exprimée comme la fonction réelle hHx, yL = z, où les coordonnées Hx, yL œ W et #z f Hx, y, zL est inversible. Cette méthode peut être vu dans les exemples suivants où la paramétrisation est donnée par les surfaces locales (graphes) sous la forme cHx, yL = f Hx, y, hHx, yLL . Dans cet exemple nous avons une surface définie par un polynôme de degré six, qui sont capables de paramétrer l’aide de deux cartes (surfaces locales). Le Distel [3] f : !3ö !, f Hx, y, zL = x 2 + y 2 + z 2 + 3000 Ix 2 + y 2 M Ix 2 + z 2 M Iy 2 + z 2 M - 3 , G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z la surface peut être paramétré par deux carte Hsurfaces localesL cHu, vL = Ku, v, - +-K- 1 6000 Ix 2+y 2 M - x 4 2 Ix 2+y 2 M - x 2 y 2 x 2+y 2 - y 4 2 Ix 2+y 2 M + 1 6000 Ix 2+y 2 M I ,I1 + 36 000 x 2 - 6000 x 4 + 9 000 000 x 8 + 36 000 y 2 - 12 000 x 2 y 2 - 6000 y 4 - 18 000 000 x 4 y 4 + 9 000 000 y 8 MMO Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par deux surfaces locales | 55Plus d’exemples de paramétrisation des surfaces algébriques [3] Les Chubs f : !3ö !, f Hx, y, zL = x 4 - x 2 + y 4 - y 2 + z 4 - z 2 + 2 5 , G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z ï cHu, vL = Hu, v, hHu, vLL la surface peut être paramétré par quatre cartes cHu, vL = u, v, - + 5 - + 5 -3+20 x 2-20 x 4+20 y 2-20 y 4 10 Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par quatre surfaces locales La Q1 f : !3ö !, f Hx, y, zL = Ix 4 + y 4 + z 4 M - 4 Ix 2 + y 2 z 2 + y 2 + z 2 x 2 + z 2 + x 2 y 2 M + 21 x y z + 3 2 , G = 9Hx, y, zL œ !3 f Hx, y, zL = 0= = ker f ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z ï cHu, vL = Hu, v, hHu, vLL Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par quatre surfaces locales 56 | ü 3.5. Références [1] Modern differential geometry of curves and surfaces, Alfred Gray, CRC Press, 1993 [2] Cours d’ Algébre géométrique, Daniel Bertrand, Université Pierre et Marie Curie, Paris, 2012 [3] Gallery of Algebraic surfaces, http://www-sop.inria.fr/galaad/surface/ | 574. L’ordinateur et la conception ü 4.1. Bref historique de la conception assistée par ordinateur L’introduction des ordinateurs dans les domaines de la conception «action-centrée» comme l’architecture n’était pas simplement une transition en douceur naturelle à partir de la planche à dessin à l’ordinateur, cela est dû au fait que les ordinateurs sont essentiellement des machines rationnelles qui suivent des algorithmes et la conception architecturale est fondamentalement intuitive. Contrairement à cela, nous constatons que dans la conception «raison-centrée» comme l’ingénierie, l’introduction des ordinateurs étaient un plus naturel et ils sont devenus intrinsèque à la conception de l’ingénierie moderne. Le problème pour la conception architecturale est qu’il s’appuie sur le jugement esthétique qui est au sens kantien un jugement réflexif, à savoir qu’il ne vient pas comme une simple détermination partir du concept universelle à une instance particulière par la raison. En d’autres termes, il n’existe pas de formule universelle ou étapes prédéterminées, qui peuvent être suivies pour produire une conception qui peut être jugé comme ayant une cohérence interne. En conséquence, peu d’approches différentes ont été prises dans l’introduction de l’informatique dans la processus de conception architecturale, mais surtout il y a deux tendances fondamentales. Le premier était de simplement consid- érer la conception architecturale comme une conception «raison-centrée» semblable à la conception technique, l’autre était d’utiliser déductivement l’ordinateur comme une planche à dessin électronique, en d’autres termes pas de processus de calcul, que le dessin en utilisant l’ordinateur. Cette seconde approche est également connu comme conception assistée par ordinateur ou CAO (et notamment à la conception architecturale: modélisation 3d). CAO est essentiellement l’utilisation de systèmes informatiques pour aider à la création, la modification, l’analyse ou l’optimisation d’une conception, il décrit essentiellement le processus de création d’un dessin technique en utilisant l’ordinateur. CAO a également été la force motrice majeure pour la recherche en géométrie algorithmique, infographie et la géométrie différentielle discrète; la conception de modèles géométriques des objets, en particulier, est parfois appelé conception géométrique assistée par ordinateur. Le terme CAO, a été inventé par l’informaticien Douglas T. Ross, qui a été inspiré par les opérateurs de radar de début des années 50. Les concepteurs de ces tout premiers ordinateurs ont découvert qu’ils pouvaient créer des symboles électroniques et des figures géométriques à être utilisé pour créer les schémas de circuit et les organigrammes. Ils ont réalisé que l’objet une fois établi, il pourrait être reproduit à volonté, son orientation, ses liens et son ampleur, mais il a fallu dix ans avant le précurseur de logiciels de CAO: Sketchpad a été développé par l’informaticien Ivan Sutherland dans les années 60. Sketchpad a permis au concepteur d’interagir avec son ordinateur graphique, cela signifie que la conception a été alimenté dans l’ordinateur, en s’appuyant sur un écran cathodique avec un crayon optique. D’autres travaux importants qui ont influencé le développement de logiciels de CAO, ont été les travaux sur les courbes et les surfaces polynomiales par les ingénieurs Pierre Bézier et Paul de Casteljau à savoir le développement de courbes splines. Ensemble avec les développement de la 3D dans les années 70, la modélisation solide dans les années 80 et les noyaux de la modélisation solides B-rep dans les années 90; une application plus souple et pratiquement omniprésent de l’ordinateur dans la conception architecturale a été créé. Une caractéristique fondamentale et importante d’un système de CAO est la modélisation 3D, qui est le processus d’élaboration d’une représentation mathématique d’une surface d’un objet en trois dimensions, le produit est appelé un modèle 3D et est divisé en deux caté- gories: les modèles volumiques et surfaciques. Les modèles solides définissent le volume de l’objet qu’ils représentent (comme une pierre), ces modèles sont principalement utilisés pour la simulation non visuels tels que la simulation médicale et de l’ingénierie. Les modèles surfaciques représentent la limite de l’objet, elles sont utilisées dans presque tous les modèles visuels des objets à partir jeux vidéo jusqu’aux domaines du design. Il y a deux façon populaire pour représenter un modèle 3D: modélisation polygonale en utilisant des maillages polygonaux reliant les points dans l’espace 3D, et modélisation Nurbs de courbes et de surfaces en utilisant l’interpolation de points dans l’espace. Modélisation polygonale est une approche pour la modélisation des objets en représentant ou en rapprochant leurs surfaces en utilisant des maillages polygonaux. 58 | ü 4.2. Modélisation de maillage polygonal ü 4.2.1. «Box modeling» et «winged edge data structure» Une des méthodes les plus populaires et les plus simples de constructions de maille, est «box modeling», où on commence par une primitive comme un cube pour faire la forme de base et de là on sculpte la forme finale à l’aide à plusieurs reprises deux outils simples: extrusion et subdivision. L’outil d’extrusion est appliquée à une face, il crée nouvelle face identique et déplacée, et puis relier chacun de ses bords à des bords existants par une face. L’outil de subdivision sépare les faces et les arêtes en petits morceaux en ajoutant de nouveaux sommets, par exemple une face carrée serait subdivisé en ajoutant un sommet au centre et un au chaque côté, créant quatre nouvelles faces carrés plus petites. Un des éléments les plus importants dans construction de maillage est sa structure de données, un maillage polygonal est constitué d’un ensemble de sommets, arêtes et faces avec leurs relations topologiques. En général, il y a deux grandes tendances dans les structures de données de maillage: basés sur les faces et basés sur les arêtes. Les structures de données basées sur les faces, enregistre pour chaque face, des pointeurs vers ses sommets et ses faces voisines, ce qui permet de naviguer autour de chaque sommet et visiter ses faces voisines. Néanmoins, un traitement spécial est nécessaire, lorsque la navigation passe au-dessus des éléments avec valence variable (par exemple mailles qui combine des quadrilatères et des triangles). Les structures de données basés sur les arêtes, enregistre pour chaque bord, des pointeurs vers les sommets et les bords voisins, et puisque les bords ont toujours la même structure topologique, il est possible de manipuler des polygones avec des valences variables dans un seul maillage. Un exemple important de la structure de données basés sur les arêtes est «winged edge data structure», qui enregistre pour chaque bord références à ses sommets, à les deux polygones partageant cette arête, et les quatre les bords voisins (ou ailes). Traversant le voisinage nécessite un distinction de cas par étape, car un bord ne code pas pour son orientation explicitement; la «half edge data structure» résout ce problème en divisant chaque bord en deux moitiés, où chaque demi bord est pointé vers son demi bord opposé, un sommet incident, un polygone incident [1]. Représentation de «winged edge data structure» L’algorithme suivant crée un maillage par une succession d’extrusions «box modeling», puis crée une structure de données «winged edge data structure» du maillage résultant, les extrusions sont atteints par une combinaison de trois simples opérations algébriques: translation, homothétie et de rotation. Cette combinaison se retrouve dans la plupart des systèmes de logiciels de modélisation CAO avec «box modeling», car il est assez intuitive permettant au concepteur de sculpter la forme désirée facilement. La structure de données doit être capable de s’adapter aux différentes topologies à savoir lors de la création de trous dans le maillage en supprimant et souder ensemble des faces, mais dans l’algorithme suivant, nous restons dans le même genre topologique: 0 de la sphère (i.e. sans trous). L’extrusion est que la première partie de la modélisation de la boîte, la deuxième outil essentiel serait le lissage de maillage au moyen la subdivision, de nombreux algorithmes sont peuvent être utilisés dans cette opérations comme la subdivision de Catmull-Clark. | 59Le code pour la création d’une modélisation «box modeling» avec la structure «winged edge data structure» s@i_D := 8884 Hi + 1L + 1, 4 Hi + 1L + 2<, 84 Hi + 1L + 2, 4 Hi + 1L + 1<<, 884 Hi + 1L + 2, 4 Hi + 1L + 3<, 84 Hi + 1L + 3, 4 Hi + 1L + 2<<, 884 Hi + 1L + 3, 4 Hi + 1L + 4<, 84 Hi + 1L + 4, 4 Hi + 1L + 3<<, 884 Hi + 1L + 4, 4 Hi + 1L + 1<, 84 Hi + 1L + 1, 4 Hi + 1L + 4<<<; Es@i_D@AA_D := 8s@iD@@1DD, s@iD@@2DD, s@iD@@3DD, s@iD@@4DD, 88s@iD@@1, 1, 1DD, AA@@1DD<, 8AA@@1DD, s@iD@@1, 1, 1DD<<, 88s@iD@@2, 1, 1DD, AA@@2DD<, 8AA@@2DD, s@iD@@2, 1, 1DD<<, 88s@iD@@3, 1, 1DD, AA@@3DD<, 8AA@@3DD, s@iD@@3, 1, 1DD<<, 88s@iD@@4, 1, 1DD, AA@@4DD<, 8AA@@4DD, s@iD@@4, 1, 1DD<<<; Tri@A_D := 88A@@1DD, A@@2DD, A@@3DD<, 8A@@1DD, A@@3DD, A@@4DD<<; Par@A_D@u_, v_D := A@@1DD + u HA@@2DD - A@@1DDL + v HHA@@4DD + u HA@@3DD - A@@4DDLL - HA@@1DD + u HA@@2DD - A@@1DDLLL; deru@c_D@u_, v_D := !uu c@uu, vvD ê. 8uu Ø u, vv Ø v<; derv@c_D@u_, v_D := !vv c@uu, vvD ê. 8uu Ø u, vv Ø v<; cNor@c_D@u_, v_D := Cross@deru@cD@u, vD, derv@cD@u, vDD ë , HCross@deru@cD@u, vD, derv@cD@u, vDD.Cross@deru@cD@u, vD, derv@cD@u, vDDL; cen@A_D := Par@AD@0.5, 0.5D; fN@A_D := cNor@Par@ADD@0.5, 0.5D; fNln@A_D := 8cen@AD, cen@AD + 0.3 fN@AD<; Ori@A_D := 8A@@1DD - cen@AD, A@@2DD - cen@AD, A@@3DD - cen@AD, A@@4DD - cen@AD<; Ext@A_D@l_D := 8A@@1DD + l fN@AD, A@@2DD + l fN@AD, A@@3DD + l fN@AD, A@@4DD + l fN@AD<; MSR@f_, q_, y_, l1_, l2_, l3_, l_D@A_D := : Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD -Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD . l1 0 0 0 l2 0 0 0 l3 .Ori@Ext@AD@lDD@@1DD + cen@Ext@AD@lDD, Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD -Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD . l1 0 0 0 l2 0 0 0 l3 .Ori@Ext@AD@lDD@@2DD + cen@Ext@AD@lDD, Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD -Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD . l1 0 0 0 l2 0 0 0 l3 .Ori@Ext@AD@lDD@@3DD + cen@Ext@AD@lDD, Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD -Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD . l1 0 0 0 l2 0 0 0 l3 .Ori@Ext@AD@lDD@@4DD + cen@Ext@AD@lDD>; v1 = 80, 0, 0<; v2 = 81, 0, 0<; v3 = 81, 1, 0<; v4 = 80, 1, 0<; v5 = 80, 0, 1<; v6 = 81, 0, 1<; v7 = 81, 1, 1<; v8 = 80, 1, 1<; Vr = 8v1, v2, v3, v4, v5, v6, v7, v8<; ve = 889, 1, 4<, 810, 2, 1<, 811, 3, 2<, 812, 4, 3<, 88, 5, 9<, 85, 6, 10<, 86, 7, 11<, 87, 8, 12<<; ev = 8881, 2<, 82, 1<<, 882, 3<, 83, 2<<, 883, 4<, 84, 3<<, 884, 1<, 81, 4<<, 885, 6<, 86, 5<<, 886, 7<, 87, 6<<, 887, 8<, 88, 7<<, 888, 5<, 85, 8<<, 885, 1<, 81, 5<<, 886, 2<, 82, 6<<, 887, 3<, 83, 7<<, 888, 4<, 84, 8<<<; ef = 881, 6<, 82, 6<, 83, 6<, 84, 6<, 85, 1<, 85, 2<, 85, 3<, 85, 4<, 81, 4<, 82, 1<, 83, 2<, 84, 3<<; ee = 8 889, 85, 1<<, 810, 82, 6<<, 82, 83, 2<<, 84, 81, 4<<<, 8810, 86, 2<<, 811, 83, 7<<, 83, 84, 3<<, 81, 82, 1<<<, 8811, 87, 3<<, 812, 84, 8<<, 84, 81, 4<<, 82, 83, 2<<<, 8812, 88, 4<<, 89, 81, 5<<, 81, 82, 1<<, 83, 84, 3<<<, 888, 88, 5<<, 86, 86, 7<<, 810, 82, 6<<, 89, 85, 1<<<, 885, 85, 6<<, 87, 87, 8<<, 811, 83, 7<<, 810, 86, 2<<<, 886, 86, 7<<, 88, 88, 5<<, 812, 84, 8<<, 811, 87, 3<<<, 887, 87, 8<<, 85, 85, 6<<, 89, 81, 5<<, 812, 88, 4<<<, 885, 86, 5<<, 81, 81, 2<<, 84, 84, 1<<, 88, 85, 8<<<, 886, 87, 6<<, 82, 82, 3<<, 81, 81, 2<<, 85, 86, 5<<<, 887, 88, 7<<, 83, 83, 4<<, 82, 82, 3<<, 86, 87, 6<<<, 888, 85, 8<<, 84, 84, 1<<, 83, 83, 4<<, 87, 88, 7<<<<; Fv = 88Vr@@1DD, Vr@@2DD, Vr@@6DD, Vr@@5DD<, 8Vr@@2DD, Vr@@3DD, Vr@@7DD, Vr@@6DD<, 8Vr@@3DD, Vr@@4DD, Vr@@8DD, Vr@@7DD<, 8Vr@@4DD, Vr@@1DD, Vr@@5DD, Vr@@8DD<, 8Vr@@5DD, Vr@@6DD, Vr@@7DD, Vr@@8DD<, 8Vr@@1DD, Vr@@4DD, Vr@@3DD, Vr@@2DD<<; fv = 881, 2, 6, 5<, 82, 3, 7, 6<, 83, 4, 8, 7<, 84, 1, 5, 8<, 85, 6, 7, 8<, 81, 4, 3, 2<<; Fe = 88ev@@1, 1DD, ev@@10, 2DD, ev@@5, 2DD, ev@@9, 1DD<, 8ev@@2, 1DD, ev@@11, 2DD, ev@@6, 2DD, ev@@10, 1DD<, 8ev@@3, 1DD, ev@@12, 2DD, ev@@7, 2DD, ev@@11, 1DD<, 8ev@@4, 1DD, ev@@9, 2DD, ev@@8, 2DD, ev@@12, 1DD<, 8ev@@5, 1DD, ev@@6, 1DD, ev@@7, 1DD, ev@@8, 1DD<, 8ev@@4, 2DD, ev@@3, 2DD, ev@@2, 2DD, ev@@1, 2DD<<; fe = 881, 10, 5, 9<, 82, 11, 6, 10<, 83, 12, 7, 11<, 84, 9, 8, 12<, 85, 6, 7, 8<, 84, 3, 2, 1<<; 60 | ndV = 8; ndF = 6; ndE = 12; DoB i = RandomInteger@81, ndF0){ $v3=1; } //description: $e3 is counter increases with k | The two conditions $k=0 & $k>0 activate the unit Vector $v3 for($j=0;$j<$Ax;$j+=1) {$e2=$j*($Cx); if($j==0){ $v2=0; } if($j>0){ $v2=1; } //description: $e2 is counter increases with j | The two conditions $j=0 & $j>0 activate the unit Vector $v2 for($i=0;$i<$Cx;$i+=1) {$e1=$i; $e=$e1+$e2+$e3; if($i==0){ $v1=0; } if($i>0){ $v1=1; } //description: $e1 is counter increases with i & $e is the cell number | The two conditions $i=0 & $i>0 activate the unit Vector $v1 $Sc[$e]=$base[$e]*$Sx*20; $B[$e]=$Sc[$e]*12; $cell_c=”COP”+($e); $cell[$e]=”COP”+($e); polyCube -n $cell_c -w $Sc[$e] -d $Sc[$e] -h $Sc[$e]; //description:$Sc[$e] is the size assigned to each cell and it is equal to the (base number).(General scale).(Zoom constant) //$B is the size of the bubble around each base cell //$cell[$e] is filling the array $cell[] with {Cop0, Cop1,......CopN} //polyCube is the creation of the base Cell, naming it $cell_c & assigning it the size of Sc[$e] to its width, depth & height //print(“cell(“+$e+“)B: “+$B[$e]+“\n”); if($i==0){ $vyc=$B[$e]; $vyp=0; } if($i>0){ $vyc=$B[$e-1]+$B[$e]; } if($j==0){ $vxc=$B[$e]; $vxp=0; } if($j>0){ $vxc=$B[$e-$Cx]+$B[$e]; } if($k==0){ $vzc=$B[$e]; $vzp=0; } if($k>0){ $vzc=$B[$e-($Cx*$Ax)]+$B[$e]; } $vy[$e]=$v1*($vyc+$vyp); $vx[$e]=$v2*($vxc+$vxp); $vz[$e]=$v3*($vzc+$vzp); //description:The condition assign the value of V_current either as ($B[$e]) or as ($B[$e] + $B[of the proper previous cell]) //Each vector is a product of its unit vector and the sum of V_current and V_previous //$Cellvector[$e]=”[“+int($vx[$e])+“,”+int($vy[$e])+“,”+int($vz[$e])+“]”; //print (“Cell(“+$e+“)=”+$Cellvector[$e]+“\n”); //print (“vxp: “+$vxp+“ vxc: “+$vxc+“ vx: “+$vx[$e]+“\n”); //print (“vyp: “+$vyp+“ vyc: “+$vyc+“ vy: “+$vy[$e]+“\n”); //print (“vzp: “+$vzp+“ vzc: “+$vzc+“ vz: “+$vz[$e]+“\n”); if($i>0){ $vyp=$vy[$e]; } if($j>0){ $vxp=$vx[$e-$Cx+1]; } if($k>0){ $vzp=$vz[$e-($Cx*$Ax)+1]; } //description:Here we cast the value V_previous to be ready for the next round of the loop move -r $vx[$e] $vy[$e] $vz[$e]; //description:This moves each cell to its 3 dimensional vector namely its ($vx[$e],$vy[$e],$vz[$e]) } } } 70 | //________________________________________________________________________________ //Cell Development //description: Extrusion Sequence | Fractal Growth //________________________________________________________________________________ int $zd[],$ad[]; int $h[],$d[],$u[],$ff[],$bf[],$rf[],$lf[],$df[],$uf[]; int $dad[],$dl[],$sdl[],$edl[]; int $U1,$U2,$U3,$F1,$F2; float $Hx,$Hy,$Hz,$Hsx,$Hsy,$Hsz; float $Hax,$Hay,$Haz,$Harx,$Hary,$Harz,$Hasx,$Hasy,$Hasz; float $LDx,$LDy,$LDz1,$LDz2,$LDz3,$LDz4,$LDrx,$LDry,$LDrz,$LDsx,$LDsy,$LDsz; float $LUx,$LUy,$LUz1,$LUz2,$LUz3,$LUrx,$LUry,$LUrz,$LUsx,$LUsy,$LUsz; float $LFx,$LFy,$LFz1,$LFz2,$LFz3,$LFrx,$LFry,$LFrz,$LFsx,$LFsy,$LFsz; float $LBx,$LBy,$LBz1,$LBz2,$LBrx,$LBry,$LBrz,$LBsx,$LBsy,$LBsz; float $LDdx,$LDdy,$LDdz,$LDdrx,$LDdry,$LDdrz,$LDdsx,$LDdsy,$LDdsz; float $LDux,$LDuy,$LDuz,$LDurx,$LDury,$LDurz,$LDusx,$LDusy,$LDusz; float $LRx,$LRy,$LRz1,$LRz2,$LRrx,$LRry,$LRrz,$LRsx,$LRsy,$LRsz; float $LLx,$LLy,$LLz1,$LLz2,$LLrx,$LLry,$LLrz,$LLsx,$LLsy,$LLsz; float $ARx,$ARy,$ARz,$ARrx,$ARry,$ARrz,$ARsx,$ARsy,$ARsz; float $ALx,$ALy,$ALrx,$ALry,$ALrz,$ALz,$ALsx,$ALsy,$ALsz; for($k=0;$k<$Gx;$k+=1) {$e3= $k*(($Cx)*($Ax)); for($j=0;$j<$Ax;$j+=1) {$e2=$j*($Cx); for($i=0;$i<$Cx;$i+=1) {$e1=$i; $e=$e1+$e2+$e3; $g=$Gcode[$e]; float $S=$Sc[$e]; //description:Casting the $g number from the $Gcode[$e] and the $S from the $Sc[$e] | the $g numbers is the //face number from which we start the extrusion sequences //The Fractal for($l=0;$l<$Lx;$l+=1) { if($l==0){ $zd[$l]=1; $h[$l]=$g+1; $ff[$l]=118; $bf[$l]=119; $rf[$l]=159; $lf[$l]=160; $df[$l]=140; $uf[$l]=130; if($g==0){ $d[$l]=110; $u[$l]=105; } if($g==1){ $d[$l]=109; $u[$l]=110; } if($g==2){ $d[$l]=111; $u[$l]=107; } if($g==3){ $d[$l]=107; $u[$l]=109; } if($g==4){ $d[$l]=110; $u[$l]=106; } if($g==5){ $d[$l]=104; $u[$l]=108; } } $Hx=1; $Hy=1; $Hz=1; $Hsx=$Hsy=$Hsz=1.3; if(($g==4)||($g==5)){ $Hax=1; $Hay=1; $Haz=1;$Hasx=$Hasy=$Hasz= 0.8; $Harx=-10 ;$Hary=0;$Harz=0; } else{ $Hax=1; $Hay=1; $Haz=1;$Hasx=$Hasy=$Hasz=0.8; $Harx=-10 ;$Hary=10;$Harz=0; } //description:Head Antena controllers if($i==0) { $LDx=0;$LDy=0; $LDz1=10;$LDz2=10;$LDz3=10;$LDz4=60; $LDrx=5; $LDry=10; $LDrz=0; if(($g==2)||($g==3)){$LDsx=0.8; $LDsy=1.2;$LDsz=1.2;}else{$LDsx=$LDsy=$LDsz= 1.2 ;} }else { $LDx=0;$LDy=0; $LDz1=$LDz2=$LDz3=$LDz4=2; $LDrx=5; $LDry=0; $LDrz=0; //$LDrx=5; $LDry=0; $LDrz=0; if(($g==2)||($g==3)){$LDsx=0.8; $LDsy=1.2;$LDsz=1.2;}else{$LDsx= 1.2 ; $LDsy= 1.2 ;$LDsz= 1.2 ;} } //description:Down body controllers if($i==$Cx-1) { $LUx=0;$LUy=-1;$LUz1=10;$LUz2=10;$LUz3=60; $LUrx=-5; $LUry=-10; $LUrz=0; if($g==5){$LUsx=0.8;$LUsy=1;$LUsz=1.5;}else{$LUsx=1.5;$LUsy=1.1;$LUsz=1.5;} }else { $LUx=0;$LUy=-1; $LUz1=$LUz2=$LUz3=3; $LUrx=-5; $LUry=0; $LUrz=0; //$LUrx=-5; $LUry=0; $LUrz=0; if($g==5){$LUsx=0.8;$LUsy=1;$LUsz=1.5;}else{$LUsx=1.5;$LUsy=1.1;$LUsz=1.5;} } //description:Upper body controllers if($k==$Gx-1){ $LFrx=5;$LFry=0;$LFrz=0; $LFz1=10;$LFz2=10;$LFz3=60; if(($g==2)||($g==3)){$LFsx=0.8; $LFsy=1.2;$LFsz=1.2;}else{$LFsx=1.2; $LFsy=1.2;$LFsz=1.2;} }else { $LFx=0;$LFy=0; if($g==5){$LFz1=$LFz2=$LFz3= 5;}else{$LFz1=$LFz2=$LFz3=2;} $LFrx=5;$LFry=0;$LFrz=0; if(($g==2)||($g==3)){$LFsx=0.8; $LFsy=1.2;$LFsz=1.2;}else{$LFsx=1.2; $LFsy=1.2;$LFsz=1.2;} } //description:Front body controllers | 71//description:Front body controllers if($k==0){ $LBx=0;$LBy=0; $LBz1=10;$LBz2=60; $LBrx=-5;$LBry=0;$LBrz=0; if(($g==2)||($g==3)){$LBsx=0.8; $LBsy=1.2;$LBsz=1.2;}else{$LBsx=$LBsy=$LBsz=1.2;} }else { $LBx=0;$LBy=0; $LBz1=$LBz2=2; $LBrx=-5;$LBry=0;$LBrz=0; if(($g==2)||($g==3)){$LBsx=0.8; $LBsy=1.2;$LBsz=1.2;}else{$LBsx=$LBsy=$LBsz=1.2;} } //description:Back body controllers $LDdx=0;$LDdy=0;$LDdz=4; $LDdsx=$LDdsy=$LDdsz=0.9; $LDdrx=-5;$LDdry=0;$LDdrz=0; //description:D-U connection D part controllers $LDux=0;$LDuy=0;$LDuz=4; $LDusx=$LDusy=$LDusz= 0.9 ; $LDurx=20;$LDury=0;$LDurz=0; //description:D-U connection U part controllers if($j==0){ $LRx=0;$LRy=0; $LRz1=20;$LRz2=100; $LRrx=5;$LRry=30;$LRrz=5; //$LRrx=0;$LRry=0;$LRrz=0; $LRsx=0.8; $LRsy=0.5;$LRsz=0.8; }else { $LRx=0;$LRy=0; $LRz1=$LRz2=4; $LRrx=5;$LRry=0;$LRrz=5; //$LRrx=0;$LRry=0;$LRrz=0; $LRsx=0.8; $LRsy=0.6;$LRsz=0.8; } //description:Right body controllers if($j==$Ax-1){ $LLx=0;$LLy=0; $LLz1=20;$LLz2=100; $LLrx=-5;$LLry=-30;$LLrz=-5; //$LLrx=0;$LLry=0;$LLrz=0; $LLsx=0.8; $LLsy=0.5;$LLsz=0.8; }else { $LLx=0;$LLy=0; $LLz1=$LLz2=4; $LLrx=-5;$LLry=0;$LLrz=-5; //$LLrx=0;$LLry=0;$LLrz=0; $LLsx=0.8; $LLsy=0.6;$LLsz=0.8; } //description:Left body controllers $ARx=0;$ARy=0;$ARz=10;$ARsx=$ARsy=$ARsz=1; $ARrx=-20;$ARry=-20;$ARrz=0; //description:Tail Right controllers $ALx=0;$ALy=0;$ALz=10;$ALsx=$ALsy=$ALsz=1; $ALrx=20;$ALry=20;$ALrz=0; //description:Tail Left controllers //description:Setting the prequisites for the extrusion //$zd[] is the magnification factor | $h[] is the face number for the head extrusion //$d[] is the face number for the downward extrusion | $u[] is the face number for the upward extrusion //$df[] is the down face number for the d-u connection | $uf[] is the up face number for the d-u connection //$rf[] is the face number for the right extrusion | $lf[] is the face number for the left extrusion //___________________________________________________________________________________________________ //if($l==1){ //int$zp=$zd[$l-1]; //$zd[$l]=($zp*50); //$ad[$l]=264; $h[$l]=$h[$l-1]+123; //if($g==0){$d[$l]=375; $u[$l]=369;$sdl[$l]=368;} //if($g==1){$d[$l]=375; $u[$l]=371;$sdl[$l]=368;} //if($g==2){$d[$l]=370; $u[$l]=371;$sdl[$l]=368;} //$dad[$l]=1;$dl[$l]=(($dad[$l]*8)-1); //$edl[$l]=$sdl[$l]+$dl[$l]; //} //if($l>1){ //int$zp=$zd[$l-1]; int$ap=$ad[$l-1]; //$zd[$l]=($zp*50); $ad[$l]=($ap*2); //$h[$l]=$h[$l-1]+$ad[$l-1]; $d[$l]=$d[$l-1]+$ad[$l]; $u[$l]=$u[$l-1]+$ad[$l]; //int$dap=$dad[$l-1]; //$dad[$l]=(($dap*2)+1); $dl[$l]=(($dad[$l]*8)-1); //$sdl[$l]=($d[$l]-7); $edl[$l]=$sdl[$l]+$dl[$l]; //} //print “\n”;//not in Animal+ //print (“zd=”+$zd[$l]+“ h=”+$h[$l]+“ d=”+$d[$l]+“ u=”+$u[$l]+“\n”);//not in Animal+ //print (“dad=”+$dad[$l]+“ dl=”+$dl[$l]+“ sdl=”+$sdl[$l]+“ edl=”+$edl[$l]+“\n”);//not in Animal+ //___________________________________________________________________________________________________ polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); 72 | polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$h[$l]+“]”); Delete ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$h[$l]+“]”); Delete ($cell[$e]+“.f[“+$h[$l]+“]”); //description:PolyExtrudeFacet is the growth command, for each facet we need to specify the LT (translation), LS(scaling), LR(rotation) select -cl; select -r $cell[$e]; polyMirrorFace -ws 1 -direction 1 -mergeMode 2 -ch 1 $cell[$e]; select -cl; //description:Selecting the Cell so far and mirroring it to produce the head //___________________________________________________________________________________________________ //if($l>0){//select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+$edl[$l]+“]”);// Delete; //if($g==0){ select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+($edl[$l]-1)+“]”);Delete; select -r ($cell[$e]+“.f[“+($edl[$l]-3)+“]”); Delete; } //if($g>0){ select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+$edl[$l]+“]”); Delete; }} //___________________________________________________________________________________________________ polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz1) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz2) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz3) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz4) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$d[$l]+“]”); Delete ($cell[$e]+“.f[“+$d[$l]+“]”); //description:The part of the sequence generate the lower body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz1) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz2) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz3) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$u[$l]+“]”); Delete ($cell[$e]+“.f[“+$u[$l]+“]”); //description:The part of the sequence generate the upper body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz1) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz2) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz3) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$ff[$l]+“]”); Delete ($cell[$e]+“.f[“+$ff[$l]+“]”); //description:The part of the sequence generate the front body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LBx) ($S*$zd[$l]*$LBy) ($S*$zd[$l]*$LBz1) -ls $LBsx $LBsy $LBsz -lr $LBrx $LBry $LBrz ($cell[$e]+“.f[“+$bf[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LBx) ($S*$zd[$l]*$LBy) ($S*$zd[$l]*$LBz2) -ls $LBsx $LBsy $LBsz -lr $LBrx $LBry $LBrz ($cell[$e]+“.f[“+$bf[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$bf[$l]+“]”); Delete ($cell[$e]+“.f[“+$bf[$l]+“]”); //description:The part of the sequence generate the back body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDdx) ($S*$zd[$l]*$LDdy) ($S*$zd[$l]*$LDdz) -ls $LDdsx $LDdsy $LDdsz -lr $LDdrx $LDdry $LDdrz ($cell[$e]+“.f[“+$df[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDdx) ($S*$zd[$l]*$LDdy) ($S*$zd[$l]*$LDdz) -ls $LDdsx $LDdsy $LDdsz -lr $LDdrx $LDdry $LDdrz ($cell[$e]+“.f[“+$df[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$df[$l]+“]”); Delete ($cell[$e]+“.f[“+$df[$l]+“]”); //description:The part of the sequence generate the down part of the d-u connection polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDux) ($S*$zd[$l]*$LDuy) ($S*$zd[$l]*$LDuz) -ls $LDusx $LDusy $LDusz -lr $LDurx $LDury $LDurz ($cell[$e]+“.f[“+$uf[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$uf[$l]+“]”); Delete ($cell[$e]+“.f[“+$uf[$l]+“]”); //description:The part of the sequence generate the up part of the d-u connection polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[164]”) ($cell[$e]+“.vtx[168]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[165]”) ($cell[$e]+“.vtx[168]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[167]”) ($cell[$e]+“.vtx[168]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[166]”) ($cell[$e]+“.vtx[168]”); //description:*first use topological unification | PolyMergeVertex is used to mesh unification polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LRx) ($S*$zd[$l]*$LRy) ($S*$zd[$l]*$LRz1) -ls $LRsx $LRsy $LRsz -lr $LRrx $LRry $LRrz ($cell[$e]+“.f[“+$rf[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LRx) ($S*$zd[$l]*$LRy) ($S*$zd[$l]*$LRz2) -ls $LRsx $LRsy $LRsz -lr $LRrx $LRry $LRrz ($cell[$e]+“.f[“+$rf[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$rf[$l]+“]”); Delete ($cell[$e]+“.f[“+$rf[$l]+“]”); //description:The part of the sequence generate the right body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LLx) ($S*$zd[$l]*$LLy) ($S*$zd[$l]*$LLz1) -ls $LLsx $LLsy $LLsz -lr $LLrx $LLry $LLrz ($cell[$e]+“.f[“+$lf[$l]+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LLx) ($S*$zd[$l]*$LLy) ($S*$zd[$l]*$LLz2) -ls $LLsx $LLsy $LLsz -lr $LLrx $LLry $LLrz ($cell[$e]+“.f[“+$lf[$l]+“]”); select -cl; select -r ($cell[$e]+“.f[“+$lf[$l]+“]”); Delete ($cell[$e]+“.f[“+$lf[$l]+“]”); //description:The part of the sequence generate the left body polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); | 73polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”); polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”); //description:The part of the sequence is additional | namely it doesnt change the topology. Only the $vtotal has to increase if new extrusions are made } //select -r $cell[$i];//not in Animal+ //move -r ($i*(-3000)*$Sx); select -cl;//not in Animal+ } } } select -r $cell; $animal_c=”AOP”+(0); polyUnite -ch 1 -n $animal_c; //description:Selecting the array $cell and putting it in one element $animal_current //_____________________________________________________________________________________________ //Topological unification // description: equations that describe the numbers of the vertices for the merging //_____________________________________________________________________________________________ int $ni,$nj,$nk,$vtotal; int $idu,$iduc,$jdu,$jduc,$kdu,$kduc,$c,$ck,$Nsmall,$Nbig; int $BNstart,$BNstart_p,$Nino,$Ninc,$Ninc_start,$Nino_p,$Nin[]; int $BGstart,$BGstart_p,$Gigo,$Ginc,$Ginc_start,$GincUnit; int $BTstart,$BTstart_p,$Tito,$Tinc,$Tinc_start,$IT,$IT_p,$ITinc,$IA,$ITunit,$ITunit_p,$Tit_p,$Tit[]; $vtotal=224; $ni=127+((1)*$vtotal); $nj=172+($Cx)*$vtotal-($Cx-1)*4; $nk=156+(($Cx*$Ax)*$vtotal)-(($Cx-1)*$Ax*4)-(($Ax-1)*$Cx*4); //print (“ni:”+$ni+“ nj:”+$nj+“ nk:”+$nk+“\n”); // description: This part calculates the ni,nj,nk (the equations) //---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - if($Cx<$Ax){ $Nsmall=$Cx;$Nbig=$Ax;$GincUnit=$Cx*4; } else { $Nsmall=$Ax;$Nbig=$Cx;$GincUnit=($Ax+1)*4; } if($Nsmall>2){for($i=0;$i<$Nsmall-2;$i+=1) { if($i==0){ $Ninc=3;$BNstart_p=0;$Ginc=24;$BGstart_p=24;if($Cx<$Ax){ $Tinc=12;$BTstart_p=32; }else{ $Tinc=12;$BTstart_p=24; }} $BNstart=$BNstart_p+$Ninc; $BNstart_p=$BNstart; $BGstart=$BGstart_p+$Ginc; $BGstart_p=$BGstart; $BTstart=$BTstart_p+$Tinc; $BTstart_p=$BTstart; $Ninc=$Ninc+2; $Ginc=$Ginc+8; $Tinc=$Tinc; }} else { $BNstart=0;$BGstart=24; if($Cx<$Ax){ $BTstart=32; }else{ $BTstart=24; }} $Nino=$BNstart+(($Nsmall-1)*($Nbig-$Nsmall)); $Gigo=$BGstart+(($GincUnit)*($Nbig-$Nsmall)); if($Cx<$Ax){ $Tito=$BTstart+(8*($Nbig-$Nsmall-1)); }else{ $Tito=$BTstart+(4*($Nbig-$Nsmall)); } //print (“Nino:”+$Nino+“\n”);print (“Gigo:”+$Gigo+“\n”); print (“Tito:”+$Tito+“\n”); // description:This part calculates the starting numbers $BNstart->Nino|$BGstart->Gigo|$BTstart->Tito | which special numbers needed for the unification equations // These numbers are complex to predict so a graph was made to mapp these numbers through trial and error if($Nsmall>2){for($i=0;$i<$Nsmall-2;$i+=1){ if($i==0){ if($Cx<$Ax){ $ITinc=3;$IT_p=-2; }else{ $ITinc=2;$IT_p=-2; }} $IT=$IT_p+$ITinc; $IT_p=$IT; if($Cx<$Ax){ $ITinc=$ITinc+2; }else{ $ITinc=$ITinc+2; } }}else{$IT=2;} //print(“IT”+$IT+“\n”); // description:This part calculates the initial incrementing unit for each base of Tito:IT if($Nsmall<3){ if($Cx<$Ax){ $ITunit=-2; }else{for($i=0;$i<=$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0;} $ITunit=$ITunit_p-$IA; $ITunit_p=$ITunit;$IA=$Nsmall-1; } $ITunit=-1*$ITunit; } }else{ if($Cx<$Ax){ for($i=0;$i<$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0; } $ITunit=$ITunit_p+$IA; $ITunit_p=$ITunit;$IA=$Nsmall-2; } }else{ for($i=0;$i<=$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0; } $ITunit=$ITunit_p+$IA; $ITunit_p=$ITunit;$IA=$Nsmall-1; }}} $ITunit=$ITunit*4; //print(“ITunit”+$ITunit+“\n”); // description:This part calculates the incrementing unit for each entry (Cx . Ax) of Tito:ITunit for($k=0;$k<$Gx;$k+=1) { if($k==0){ $Nino_p=-$Nino;$Tit[$k]=0; }$Nin[$k]=$Nino_p+$Nino; $Nino_p=$Nin[$k]; if($k==1){ $Tit[$k]=$Tito;$Tit_p=$Tit[$k]; } if($k>1){ $Tit[$k]=$Tit_p-$ITunit; $Tit_p=$Tit[$k]; } //print (“Nin[“+$k+“]:”+$Nin[$k]+“\n”);//print (“Tit[“+$k+“]:”+$Tit[$k]+“\n”); } // description:This part calculates the propagation(k) the incrementing unit for Tito->Tit[k] Nino->Nin[k] //---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - for($k=0;$k<$Gx;$k+=1) {$e3= $k*(($Cx)*($Ax)); for($j=0;$j<$Ax;$j+=1) {$e2=$j*($Cx); $c=$j+($k*$Ax); for($i=0;$i<$Cx;$i+=1) {$e1=$i; $e=$e1+$e2+$e3; $idu=($e-$c)*4; $iduc=($e-$c)*4; 74 | $idu=($e-$c)*4; $iduc=($e-$c)*4; if($i!=$Cx-1){ polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(136+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni)+($e*$vtotal)-($iduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(137+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-1)+($e*$vtotal)-($iduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(138+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-2)+($e*$vtotal)-($iduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(139+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-3)+($e*$vtotal)-($iduc))+“]”); } } } } // description:This part Unifies in the i-direction (connecting the cells up and down) | The idu & iduc equations describe the number of vertices lost in every connection act for($k=0;$k<$Gx;$k+=1) {$e3= $k*(($Cx)*($Ax)); for($j=0;$j<$Ax;$j+=1) {$e2=$j*($Cx); $c=$j+($k*$Ax); for($i=0;$i<$Cx;$i+=1) {$e1=$i; $e=$e1+$e2+$e3; $jdu=($e*8)-(($c+($Cx-1))*4)-($k*($Cx*4)); $jduc=($e*8)-($c*4)-($k*($Cx*4)); if($j==0){ $jdu=($e*4)+($k*($Nino*4)); } if($j!=$Ax-1){ polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(180+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(181+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(183+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(182+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”); } //print (“e:”+$e+“ c:”+$c); //print (“ jdu:”+$jdu+“ jduc:”+$jduc+“\n”); //print (“Vside_giv:”+(164+($e*168)-($jdu))+“ Vside_rec:”+($nj+($e*168)-($jduc))+“\n”); } } } // description:This part Unifies in the j-direction (connecting the cells right and left) | The jdu & jduc equations describe the number of vertices lost in every connection act and the irregularities described by $Nino for($k=0;$k<$Gx;$k+=1) {$e3= $k*(($Cx)*($Ax)); //print (“Tit[“+$k+“]:”+$Tit[$k]+“\n”); //print (“Nin[“+$k+“]:”+$Nin[$k]+“\n”); for($j=0;$j<$Ax;$j+=1) {$e2=$j*($Cx); $c=$j+($k*$Ax); for($i=0;$i<$Cx;$i+=1) {$e1=$i; $e=$e1+$e2+$e3; $kdu=($e*12)-($c*4)-($k*($Cx*4))-$Gigo; $kduc=($e*12)-($c*4)-($k*($Cx*4))-($Cx*4); if($j==0){$kdu=($e*12)-(($e-$c)*4)-$Tit[$k]; $kduc=($e*12)-(($e-$Nin[$k])*4);} if($k==0){$kdu=($e*12)-($e*4)-($c*4)-($Cx*4);if($j==0){$kdu=($e*12)/3;$kduc=($e*12)-($e*4);}} if($k!=$Gx-1){ polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(148+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(149+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(151+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”); polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(150+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”); } //print (“e:”+$e+“ c:”+$c); //print (“ kdu:”+$kdu+“ kduc:”+$kduc+“\n”); //print (“Vfront_giv:”+(164+($e*168)-($jdu))+“ Vfront_rec:”+($nj+($e*168)-($jduc))+“\n”); } } } // description:This part Unifies in the k-direction (connecting the cells front and back) // The kdu & kduc equations describe the number of vertices lost in every connection act and the irregularities described by $Gigo, $Tit[k], $Nin[k] | 75ü 4.3. Modélisation par interpolation ü 4.3.1. Interpolation polynomiale La seconde technique de modélisation majeur qui est de loin le plus utilisé dans la conception architecturale est l’interpolation à travers des points discrets, l’interpolation est largement répandu dans le contexte de l’ingénierie, en raison de sa capacité à rapprocher solution de problèmes pour lesquels nous n’avons pas une formule explicite. Malgré la propagation de la modélisation par interpolation en architecture, il n’y a pas beaucoup d’architectes qui construisent ou sont conscients de la construction mathématique de la méthode d’interpolation qu’ils utilisent. Dans cette recherche, nous nous concentrons à donner des formules explicites pour les formes que nous concevons, mais dans certains cas où la forme est souhaitable de passer par des points discrets spécifiques, il est beaucoup plus facile de construire une interpolation polynomiale. Nous allons voir un exemple de ce cas plus tard, quand nous construisons une surface passant par des points discrets recueillies à partir d’une mesure externe, nous donnerons également la construction mathématique des courbes et surfaces de Bézier et NURBS, qui sont les interpolations les plus largement utilisés dans les systèmes de CAO aujourd’hui. Un système de modélisation CAO typique peut être considéré comme constitué de l’interaction entre une interface graphique d’utilisateur (GUI) avec une géométrie: NURBS et /ou de représentation de limite de données (B-rep) par l’intermédiaire d’un noyau de modélisation géométrique. «Non uniform rational basis spline» (ou NURBS) est un modèle mathématique pour générer et représenter des courbes et des surfaces avec une grande souplesse et précision. La représentation de limite (B-rep) est une méthode pour représenter des formes à l’aide des limites; un solide est représenté comme un ensemble d’éléments de surface reliés, la limite entre solide et non solide. Nous trouvons que la majorité des logiciels de CAO d’aujourd’hui qui sont couramment utilisés dans la conception architecturale repose sur cette définition de NURBS de courbes et de surfaces. Pour cette raison, et puisque dans cette recherche, nous nous intéressons à la géométrie moderne et l’espace formel, nous allons expliquer la définition mathématique formelle de NURBS. Afin de comprendre les NURBS, nous devons commencer par la notion de base de l’interpolation des courbes ou des surfaces à travers un ensemble de points discrets, qui nous conduira à des méthodes d’interpolation plus complexes tels que splines (bi)cubiques, Bézier et finalement NURBS. L’interpolation est un procédé de construction de nouveaux points de données à l’intérieur de la plage d’un ensemble discret de points de données connus. Une des méthodes d’interpolation les plus simples est l’interpolation linéaire (Lerp), une interpolation linéaire est simplement la ligne droite entre deux points donnés dans l’ensemble discret. Naturellement, dans une interpolation polynomiale, l’interpolant est un polynôme qui passe exactement à travers d’un ensemble donné de points, et, dans une interpolation spline, l’interpolant est un type particulier: polynomiale par morceaux appelée spline. Fonction polynomiale [2] est une fonction qui peut être définie par l' évaluation d ' un polynôme une fonction f à un argument est appelé une fonction polynomiale si elle satisfait f HxL = a0 x 0 + ... + an x n = ⁄i=0 n ai x i Anneau de polynômes #[X] [2] l' ensemble de tousles polynômes avec des coefficients dansle corps # Havec # = ! ou $L #n@XD espace vectoriel des polynômes de degré n et #@XD est un anneau commutatif, le symbole X est couramment appelé la variable P, Q œ #n@XD , R œ #m@XD , pi , qi , ri œ # pour i = 0, ..., n et j = 0, ..., m PHXL = ⁄i=0 n pi X i , QHXL = ⁄i=0 n qi X i et RHXL = ⁄j=0 m rj X j PHXL + QHXL = HP + QL HXL = ⁄i=0 n Hpi + qiL X i et PHXL RHXL = ⁄k=0 m+n I⁄i+ j=k pi ri M X i le corps # peut être remplacé par n' importe quel anneau commutatif comme !, donnant lieu à l' anneau de polynômes sur ! qui est notée !@XD 76 | Avant de commencer à construire les polynômes d’interpolation plus élaborés que nous allons utiliser dans la conception architecturale, nous devons d’abord commencer par les bases de l’interpolation polynomiale, pour cela, nous allons montrer la matrice de Vandermonde. Le problème de cette méthode est que le degré du polynôme va augmenter avec l’augmentation du nombre de points qui donnent lieu à un polynôme moins stable avec un grand nombre d’oscillations. Nous allons résoudre ce problème lorsque nous allons construire les splines cubiques et bi-cubiques, où la courbe est faite à partir de segments, chacun est un polynôme de degré trois. Interpolation polynomiale [2] est l' interpolation d ' un ensemble de points donné par un polynôme qui passe exactement à travers de ces points pi œ !2 , pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, .., n< , xi = x jói = j " i œ 80, .., n< , PHxiL = yi , P est l' unique interpolation polynomiale degHPL § n pour n + 1 pointsHxiL, P : # n+1ö#n@XD est une bijection linéaire, " i œ 80, .., n<, PHxiL = ⁄k=0 n ak xi k = a0 xi 0 + ... + an xi n = yi pour trouver les coefficients ak pour k = 0, ..., n de l' interpolant P nous résolvonsle système M A = B ïA = M-1 B , où M est la matrice de Vandermonde 1 x0 1 .. x0 n 1 x1 1 .. x1 n : : .. : 1 xn 1 .. xn n a0 a1 : an = y0 y1 : yn Interpolant P avec deg(P) = 3 G = 9pi = Hxi , yiL œ !2 , for i = 0, ..., 3= est un ensemble de quatre points distincts p0 = I-1, 1 2 M, p1 = H0, 0L, p2 = I1, - 1 2 M et p3 = H2, 0L P œ #3@XD est un polynôme d ' interpolation de degré = 3 PHxiL = ⁄k=0 3 ak xi k = a0 xi 0 + a1 xi 1 + a2 xi 2 + a3 xi 3 = yi B = t Hy0, ..., y3L = t H2, 0, -2, 0L est le vecteur connu A = t Ha0, ..., a3L est le vecteur des coefficients de P et M est la matrice de Vandermonde M A = B ï 1 x0 1 x0 2 x0 3 1 x1 1 x1 2 x1 n 1 x2 1 x2 2 x2 n 1 x3 1 x3 2 x3 n a0 a1 a2 a3 = y0 y1 y2 y3 ïA = M-1 B ï a0 a1 a2 a3 = 1 -1 1 -1 1 0 0 0 1 1 1 1 1 2 4 8 -1 1 2 0 - 1 2 0 = 0 - 2 3 0 - 1 6 ïP : !ö!, PHxL = H0L x 0 + I- 2 3 M x 1 +H0L x 2 + I- 1 6 M x 3 = - 2 x 3 + x 3 6 Représentation d’un polynôme d’interpolation de degré 3 à travers 4 points | 77ü 4.3.2. Splines cubique et bicubique Avec la définition du polynôme d’interpolation clarifié nous allons définir maintenant le spline cubique et bicubique. Une spline est une fonction polynomiale suffisamment lisse par morceaux polynôm; les types les plus courants sont: B-spline cubique et cubique splines de Bézier. Une courbe cubique peut avoir qu’un seul point d’inflexion, de faire une courbe avec trois points d’inflexion, nous devons ajouter des points de contrôle supplémentaires et utilisant un polynôme de degré supérieur (degré ¥ 3). Néanmoins, ces polynômes de degré supérieur sont sensibles à la position des points et ne font pas toujours des formes lisses. De construire un polynôme par morceaux est de laisser chaque paire de points de contrôle représenter un segment (polynôme cubique) de la courbe. Construction générale de splines cubiques (forme non paramétrique) [2] pi œ !2 , pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, .., n< , xi = x jói = j PiHxiL = ⁄k=0 3 ak,i xi k = a0,i xi 0 + a1,i xi 1 + a2,i xi 2 + a3,i xi 3 = yi Hle segment entre pi & pi+1L les dérivés des segments Pi ' Hxi+1L = a1,i + 2 a2,i Hxi+1L + 3 a3,i Hxi+1L 2 et Pi+1 ' Hxi+1L = a1,i+1 + 2 a2,i+1 Hxi+1L + 3 a3,i+1 Hxi+1L 2 Pi '' Hxi+1L = 2 a2,i +6 a3,i Hxi+1L et Pi+1 '' Hxi+1L = 2 a2,i+1 +6 a3,i+1 Hxi+1L les conditions qui construisent le système PiHxiL = yi et Pi Hxi+1L = yi+1 IC 0 continuitéM et Pi ' Hxi+1L = Pi+1 ' Hxi+1L IC 1 continuitéM Pi '' Hxi+1L = Pi+1 '' Hxi+1L IC 2 continuitéM , P0 ' Hx0L = s0 et Pn-1 ' HxnL = sn HPentes aux points des extrémitésL les équations du système a1,0 + 2 a2,0 Hx0L + 3 a3,0 Hx0L 2 = s0 a0,i xi 0 + a1,i xi 1 + a2,i xi 2 + a3,i xi 3 = yi a0,i xi+1 0 + a1,i xi+1 1 + a2,i xi+1 2 + a3,i xi+1 3 = yi+1 a1,i + 2 a2,i Hxi+1L + 3 a3,i Hxi+1L 2 - a1,i+1 - 2 a2,i+1 Hxi+1L - 3 a3,i+1 Hxi+1L 2 = 0 2 a2,i +6 a3,i Hxi+1L - 2 a2,i+1 -6 a3,i+1 Hxi+1L = 0 a1,n-1 + 2 a2,n-1 HxnL + 3 a3,n-1 HxnL 2 = sn pour n + 1 points que nous avons besoin de n segmentsï 4 n équations ï le système pour n = 4 Hi.e. 5 points de donnéesL 0 1 2 x0 1 3 x0 2 0 0 0 0 0 0 0 0 0 0 0 0 1 x0 1 x0 2 x0 3 0 0 0 0 0 0 0 0 0 0 0 0 1 x1 1 x1 2 x1 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 x1 1 3 x1 2 0 -1 -2 x1 1 -3 x1 2 0 0 0 0 0 0 0 0 0 0 2 6 x1 1 0 0 -2 -6 x1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 x1 1 x1 2 x1 3 0 0 0 0 0 0 0 0 0 0 0 0 1 x2 1 x2 2 x2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 x2 1 3 x2 2 0 -1 -2 x2 1 -3 x2 2 0 0 0 0 0 0 0 0 0 0 2 6 x2 1 0 0 -2 -6 x2 1 0 0 0 0 0 0 0 0 0 0 0 0 1 x2 1 x2 2 x2 3 0 0 0 0 0 0 0 0 0 0 0 0 1 x3 1 x3 2 x3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 x3 1 3 x3 2 0 -1 -2 x3 1 -3 x3 2 0 0 0 0 0 0 0 0 0 0 2 6 x3 1 0 0 -2 -6 x3 1 0 0 0 0 0 0 0 0 0 0 0 0 1 x3 1 x3 2 x3 3 0 0 0 0 0 0 0 0 0 0 0 0 1 x4 1 x4 2 x4 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 x4 1 3 x4 2 a0,0 a1,0 a2,0 a3,0 a0,1 a1,1 a2,1 a3,1 a0,2 a1,2 a2,2 a3,2 a0,3 a1,3 a2,3 a3,3 = s0 y0 y1 0 0 y1 y2 0 0 y2 y3 0 0 y3 y4 s4 78 | Splines cubique à travers 5 points de données (forme non paramétrique) G = 9pi = Hxi , yiL œ !2 , pour i = 0, ..., 4= est un ensemble de 5 points de données distincts p0 = H0, 1L, p1 = H2, 3L, p2 = H4, -1L , p3 = H6, 1L et p4 = H8, 0L et la pente de débuts0 = -1 et la pente du bouts4 = 2 Pi œ #3@XD est un polynôme d ' interpolation de degré = 3 PiHxiL = ⁄k=0 3 ak,i xi k = a0,i xi 0 + a1,i xi 1 + a2,i xi 2 + a3,i xi 3 = yi B = t Hs0, y0, y1, 0, 0, y1, y2, 0, 0, y2, y3, 0, 0, y3, y4, s4L est le vecteur connu A = t Ha0,0, a1,0, a2,0, a3,0, a0,1, a1,1, a2,1, a3,1, a0,2, a1,2, a2,2, a3,2, a0,3, a1,3, a2,3, a3,3, a0,4, a1,4, a2,4, a3,4L A est le vecteur des coefficients de l' interpolant P et M est le système de matrice d’équations M A = B ï A = M-1 B ï A = a0,0 a1,0 a2,0 a3,0 a0,1 a1,1 a2,1 a3,1 a0,2 a1,2 a2,2 a3,2 a0,3 a1,3 a2,3 a3,3 = 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 4 8 0 0 0 0 0 0 0 0 0 0 0 0 0 1 4 12 0 -1 -4 -12 0 0 0 0 0 0 0 0 0 0 2 12 0 0 -2 -12 0 0 0 0 0 0 0 0 0 0 0 0 1 2 4 8 0 0 0 0 0 0 0 0 0 0 0 0 1 4 16 64 0 0 0 0 0 0 0 0 0 0 0 0 0 1 8 48 0 -1 -8 -48 0 0 0 0 0 0 0 0 0 0 2 24 0 0 -2 -24 0 0 0 0 0 0 0 0 0 0 0 0 1 4 16 64 0 0 0 0 0 0 0 0 0 0 0 0 1 6 36 216 0 0 0 0 0 0 0 0 0 0 0 0 0 1 12 108 0 -1 -12 -108 0 0 0 0 0 0 0 0 0 0 2 36 0 0 -2 -36 0 0 0 0 0 0 0 0 0 0 0 0 1 6 36 216 0 0 0 0 0 0 0 0 0 0 0 0 1 8 64 512 0 0 0 0 0 0 0 0 0 0 0 0 0 1 16 192 -1 -1 1 3 0 0 3 -1 0 0 -1 1 0 0 1 0 2 l' interpolant PHxL est égal à si x0 § x < x1 = P0HxL = 1 - x + 597 x 2 224 - 373 x 3 448 si x1 § x < x2 = P1HxL = - 163 14 + 503 x 28 - 1527 x 2 224 + 335 x 3 448 si x2 § x < x3 = P2HxL = 1097 14 - 1387 x 28 + 2253 x 2 224 - 295 x 3 448 si x3 § x < x4 = P2HxL = - 1598 7 + 1453 x 14 - 3471 x 2 224 + 341 x 3 448 Représentation d’une spline cubique à travers 5 points de données (forme non paramétrique) | 79Construction générale de splines cubiques (forme paramétrique) Il s’agissait de la forme générale de la spline cubique mais ce qui est plus intéressant du point de vue de la conception architecturale est la paramétrisation de cette forme, comme cela, nous sommes en mesure de libérer la variable x à aller en avant et en arrière si nous sommes dans !2 et que nous pouvons commencer à dessiner des courbes dans !3 . Ces courbes dans !3 sont largement utilisés dans le logiciel de CAO et ils sont également la base pour la construction des surfaces qui les relient; cependant l’utilisateur du système de CAO n’a pas accès à aux fonctions d’interpolation polynomiales de ces courbes, elles sont la plupart du temps caché dans la bibliothèque du logiciel. Cependant, dans cette recherche, puisque nous construisons ces fonctions nous-mêmes, nous avons accès à leur structure, et nous pouvons choisir entre les différentes techniques d’interpolation, en fonction de nos besoins, ce qui sera montré plus tard, quand nous allons utiliser ces fonctions d’interpolation dans notre processus de conception. Nous allons maintenant définir une forme paramétrique de la spline cubique Construction générale de splines cubiques (forme paramétrique) [2] pi œ !3 , pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, ..., n< , xi = x jói = j maintenant le paramètre ne sera pasla variable x, mais u sur n intervalles Ii = @ci , diD pour i = 0, ..., n et pour l œ 8x, y, z< ti = fiHuL fiHciL = 0 et fiHdiL = 1 et d ti d u = d fi d u = 1 l' équation de la courbe cubique paramétrique Pli HtiL = Pli H fi HuLL = ⁄k=0 3 alk,i fiHuL k = al0,i fi HuL 0 + al1,i fi HuL 1 + al2,i fi HuL 2 + al3,i fiHuL 3 = li Pli HtiL = al0,i t i 0 + al1,i t i 1 + al2,i t i 2 + al3,i t i 3 = li Hle composant l pour le segment entre pi & pi+1L dérivés par rapport à t Hi.e. f L et par rapport à u Dfi @Pli H fi HuLLD = d Pli d fi = al1,i + 2 al2,i H fiHuLL + 3 al3,i H fiHuLL2 Dfi 2 @Pli H fi HuLLD = d 2 Pli d fi 2 = 2 al2,i +6 al3,i H fiHuLL Du @Pli H fi HuLLD = d Pli d fi d fi d u = Dfi @Pli H fi HuLLD = Pli ' H fiHuLL Du 2 @Pli H fi HuLLD = J d Pli ' d fi d fi d u N d fi d x = Dfi 2 @Pli H fi HuLLD = Pli '' H fiHuLL les conditions qui construisent le système Pli H fi HciLL = li et Pli H fiHdiLL = li+1 IC 0 continuitéM et Pli ' H fiHdiLL = Pli+1 ' H fi+1Hci+1LL IC 1 continuitéM Pli '' H fiHdiLL = Pli+1 '' H fi+1Hci+1LL IC 2 continuitéM, Pl0 ' H f0Hc0LL = s0 et Pln-1 ' H fn-1Hdn-1LL = sn HPentes aux points des extrémitésL les équations du système Pl0 ' H f0Hc0LL = al1,0 + 2 al2,0 H f0Hc0LL + 3 al3,0 H f0Hc0LL2 = s0 ï al1,0 = s0 ... H1L Pli H fi HciLL = al0,i fi HciL 0 + al1,i fi HciL 1 + al2,i fi HciL 2 + al3,i fiHciL 3 = li ï al0,i = li ... H2L Pli H fi HdiLL = al0,i fi HdiL 0 + al1,i fi HdiL 1 + al2,i fi HdiL 2 + al3,i fiHdiL 3 = li+1 ï al0,i + al1,i + al2,i + al3,i = li+1 ... H3L Pli ' H fiHdiLL = Pli+1 ' H fi+1Hci+1LL ï al1,i + 2 al2,i H fiHdiLL + 3 al3,i H fiHdiLL2 = al1,i+1 + 2 al2,i+1 H fi+1Hci+1LL + 3 al3,i+1 H fi+1Hci+1LL2 ï al1,i + 2 al2,i +3 al3,i - al1,i+1 = 0 ... H4L Pli '' H fiHdiLL = Pli+1 '' H fi+1Hci+1LL ï 2 al2,i +6 al3,i H fiHdiLL = 2 al2,i+1 +6 al3,i+1 H fi+1Hci+1LL ï2 al2,i +6 al3,i - 2 al2,i+1 = 0 ... H5L Pln-1 ' H fn-1Hdn-1LL = al1,n-1 + 2 al2,n-1 H fn-1Hdn-1LL + 3 al3,n-1 H fn-1Hdn-1LL2 = sn ï al1,n-1 + 2 al2,n-1 +3 al3,n-1 = sn ... H6L 80 | pour n + 1 points que nous avons besoin de n segmentsï 4 n équations ï le système pour n = 4 Hi.e. 5 points de donnéesL 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 ax0,0 ay0,0 az0,0 ax1,0 ay1,0 az1,0 ax2,0 ay2,0 az2,0 ax3,0 ay3,0 az3,0 ax0,1 ay0,1 az0,1 ax1,1 ay1,1 az1,1 ax2,1 ay2,1 az2,1 ax3,1 ay3,1 az3,1 ax0,2 ay0,2 az0,2 ax1,2 ay1,2 az1,2 ax2,2 ay2,2 az2,2 ax3,2 ay3,2 az3,2 ax0,3 ay0,3 az0,3 ax1,3 ay1,3 az1,3 ax2,3 ay2,3 az2,3 ax3,3 ay3,3 az3,3 = sx0 sy0 sz0 x0 y0 z0 x1 y1 z1 0 0 0 0 0 0 x1 y1 z1 x2 y2 z2 0 0 0 0 0 0 x2 y2 z2 x3 y3 z3 0 0 0 0 0 0 x3 y3 z3 x4 y4 z4 sx4 sy4 sz4 Splines cubique à travers 5 points de données (forme paramétrique) G = 9pi = Hxi , yi , ziL œ !3 , pour i = 0, ..., 4= est un ensemble de 5 points de données distincts p0 = H2, 0, 0L, p1 = H1, 0, 2L, p2 = H1, 1, 1L , p3 = H-1, 2, 1L et p4 = H3, 3, 5L les pentes au débuts0 = Is0x , s0y , s0z M = H-1, -1, -1L et les pentes au bouts4 = Is4x , s4y , s4z M = H2, -2, -2L ti = fiHuL = u - i fiHciL = 0 et fiHdiL = 1 et d ti d u = d fi d u = 1 pour u œ Ii = @ci , diD pour i = 0, ..., n et pour l œ 8x, y, z< Pli œ #3@XD est un polynôme d ' interpolation de degré = 3 tel que Pli HtiL = ⁄k=0 3 ak,i t i k = al0,i t i 0 + al1,i t i 1 + al2,i t i 2 + al3,i t i 3 = li Bl = t Hs0l, l0, l1, 0, 0, l1, l2, 0, 0, l2, l3, 0, 0, l3, l4, s4lL est le vecteur connu Al = t Ha0,0, a1,0, a2,0, a3,0, a0,1, a1,1, a2,1, a3,1, a0,2, a1,2, a2,2, a3,2, a0,3, a1,3, a2,3, a3,3, a0,4, a1,4, a2,4, a3,4L est le vecteur des coefficients de l' interpolant Pl et M est le système de matrice d ' équations matrix M Al = Bl où A = H Ax Ay Az L et B = H Bx By Bz L A = M-1 B = 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 -1 -1 -1 -1 2 0 0 1 0 2 0 0 0 0 0 0 1 0 2 1 1 1 0 0 0 0 0 0 1 1 1 -1 2 1 0 0 0 0 0 0 -1 2 1 3 3 5 2 -2 -2 | 81l' interpolant PH f HuLL = IPxH f HuLL, PyH f HuLL, PzH f HuLLM est égal à si 0 § u < 1 , PH f HuLL = Px0 H f0HuLL Py0 H f0 HuLL Pz0 H f0 HuLL = 2 - u - 27 u 2 28 + 27 u 3 28 -u + 17 u 2 14 - 3 u 3 14 -u + 181 u 2 28 - 97 u 3 28 si 1 § u < 2 , PH f HuLL = Px1 H f1HuLL Py1 H f1 HuLL Pz1 H f1 HuLL = 1 + 1-u 28 + 27 14 H-1 + uL 2 - 53 28 H-1 + uL 3 11 14 H-1 + uL + 4 7 H-1 + uL 2 - 5 14 H-1 + uL 3 2 + 43 28 H-1 + uL - 55 14 H-1 + uL 2 + 39 28 H-1 + uL 3 si 2 § u < 3 , PH f HuLL = Px2 H f2HuLL Py2 H f2 HuLL Pz2 H f2 HuLL = 1 - 13 7 H-2 + uL - 15 4 H-2 + uL 2 + 101 28 H-2 + uL 3 1 + 6 7 H-2 + uL - 1 2 H-2 + uL 2 + 9 14 H-2 + uL 3 1 - 15 7 H-2 + uL + 1 4 H-2 + uL 2 + 53 28 H-2 + uL 3 si 3 § u < 4 , PH f HuLL = Px3 H f3HuLL Py3 H f3 HuLL Pz3 H f3 HuLL = -1 + 41 28 H-3 + uL + 99 14 H-3 + uL 2 - 127 28 H-3 + uL 3 2 + 25 14 H-3 + uL + 10 7 H-3 + uL 2 - 31 14 H-3 + uL 3 1 + 113 28 H-3 + uL + 83 14 H-3 + uL 2 - 167 28 H-3 + uL 3 Représentation d’une spline cubique (forme paramétrique) 82 | Méthode itérative La méthode précédente est très simple pour dessiner la spline cubique, le seul problème est que le nombre de points détermine le nombre d’équations à résoudre donc la matrice M devra être réglée si nous ajoutons ou supprimer des points dans le processus de conception, qui n’est pas très efficace. Alors maintenant, nous allons limiter la taille de la matrice à 4ä4 et utiliser une boucle itérative pour calculer les coefficients des polynômes à travers les segments. Nous allons définir trois types importants de splines cubiques: l’Hermite cubique, Catmull Rom et la spline Cardinal, qui peuvent être utilisés dans l’itération. Méthode itérative pour dessiner la spline cubique [2] pi œ !3 , ti œ !3 , pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL Pli HtiL = ⁄k=0 3 ak,i t i k = al0,i t i 0 + al1,i t i 1 + al2,i t i 2 + al3,i t i 3 = li Hle composant l pour le segment entre pi & pi+1L ti = fiHuL = u - i fiHciL = 0 et fiHdiL = 1 et d ti d u = d fi d u = 1 pour u œ Ii = @ci , diD pour i = 0, ..., n et pour l œ 8x, y, z< PiHtiL = PiH fiHuLL = Px i HtiL Py i HtiL Pz i HtiL = ax0,i t i 0 + ax1,i t i 1 + ax2,i t i 2 + ax3,i t i 3 ay0,i t i 0 + ay1,i t i 1 + ay2,i t i 2 + ay3,i t i 3 az0,i t i 0 + az1,i t i 1 + az2,i t i 2 + az3,i t i 3 et Pi ' HtiL = ax1,i + 2 ax2,i ti + 3 ax3,i t i 2 ay1,i + 2 ay2,i ti + 3 ay3,i t i 2 az1,i + 2 az2,i ti + 3 az3,i t i 2 ti = ti,x ti,y ti,z est la tangente donnée en pi et mi = mi,x = ti,x xi+1-xi mi,y = ti,y yi+1-yi mi,z = ti,z zi+1-zi est la tangente mise à l' échelle enpi les conditions qui construisent le système PiH0L = pi , PiH1L = pi+1 , Pi ' H0L = mi et Pi ' H1L = mi+1 le système pour le segment entre Hxi , yi , ziL et Hxi+1, yi+1, zi+1L est donnée par 1 0 0 0 1 1 1 1 0 1 0 0 0 1 2 3 ax0,i ay0,i az0,i ax1,i ay1,i az1,i ax2,i ay2,i az2,i ax3,i ay3,i az3,i = xi yi zi xi+1 yi+1 zi+1 mi,x mi,x mi,x mi+1,x mi+1,y mi+1,z dansle cas d ' Hermite cubique spline ti = ti,x ti,y ti,z est donnée à chaque pi dansle cas de Catmull Rom spline ti = pi+1-pi-1 2 = ti,x = xi+1-xi-1 2 ti,y = yi+1-yi-1 2 ti,z = zi+1-zi-1 2 dansle cas de la spline Cardinal ti = H1-cL Hpi+1-pi-1 L 2 = ti,x = H1-cL Hxi+1-xi-1 L 2 ti,y = H1-cL Hyi+1-yi-1 L 2 ti,z = H1-cL Hzi+1-zi-1 L 2 Hi.e. un paramètre de forme c est ajouté pour contrôler la courbure autour de piL | 83Maintenant, nous allons montrer une spline cubique construit en utilisant une itération, en passant par les points à interpoler, comme nous l’avons mentionné il y a quelques méthodes pour créer cette interpolantion. Iteration through n points using the Catmul Rom spline G = 9pi = Hxi , yi , ziL œ !3 , pour i = 1, ..., n= est un ensemble de n points de données distincts la spline ne passe pas par p1 et pn ils ne sont utilisés que pour donner la tangence aux extrémités de la spline pour n = 8 la spline interpole 6 points ï nous aurons un système de 24 équations, lieu de cela nous allons créer une itération p1 = H0, 0, 0L, p2 = I 1 2 , 1 2 , 1 2 M , p3 = H2, 0, 1L , p4 = H4, 0, 4L, p5 = H4, 3, 2L, p6 = H3, 4, 4L, p7 = H5, 5, 5L et p8 = H6, 6, 6L n = CardHGL = 8 et c = 1 Hune valeur de comptage initialeL nous itérons pour i = 2, ..., n - 2 m1 = I pi+1-pi-1 2 M, m2 = I pi+2-pi-2 2 M , a0 a1 a2 a3 = 1 0 0 0 1 1 1 1 0 1 0 0 0 1 2 3 -1 pi pi+1 m1 m2 PcHuL = a0 + a1 Hu - Hc - 1LL + a2 Hu - Hc - 1LL2 + a3Hu - Hc - 1LL3 c = c + 1 l' interpolant PHuL est égal à si 0 § u < 1 , PHuL = P1HuL, si 1 § u < 2 , PHuL = P2HuL, si 2 § u § 3 , PHuL = P3HuL si 3 § u < 4 , PHuL = P4HuL, si 4 § u < 5 , PHuL = P5HuL, si 5 § u § 6 , PHuL = P6HuL Représentation d’une itération à travers 8 points en utilisant la spline de Catmull Rom 84 | Spline bicubique Maintenant que nous avons construit la spline cubique, il est naturel de construire son analogue sur une grille bidimensionnelle de points, à savoir une spline bicubique qui est une surface paramétrique qui passe par ces points de grille. La spline bicubique est la première des trois types d’interpolation à deux dimensions que nous allons construire dans le cadre de cette recherche, la deuxième serait la surface de Bézier et la troisième sera la surface NURBS. Maintenant, nous allons définir l’interpolation bicubique qui est une extension de l’interpolation cubique destiné à interpoler des points de données sur une grille régulière à deux dimensions, il est souvent choisie de préférence à l’interpolation bilinéaire et la méthode du plus proche voisin dans le rééchantillonnage d’image. Spline bicubique [3] G = 9pi, j œ !3 , i = 0, .., m et j = 0, .., n= est un ensemble de Hm + 1LäHn + 1L points de données et ti œ !3 Pli, j Iti , sj M = ⁄k=0 3 ⁄l=0 3 alk,l,i, j ti k sj l = li, j Ile composant l pour le carré entre pi, j , pi+1, j , pi+1, j+1, pi, j+1M Pli, j Iti , sj M = al0,0,i, j ti 0 sj 0 + al0,1,i, j ti 0 v 1 + al0,2,i, j ti 0 v 2 + al0,3 ti 0 v 3 +al1,0,i, j ti 1 sj 0 + al1,1,i, j ti 1 sj 1 + al1,2,i, j ti 1 sj 2 + al1,3,i, j ti 1 sj 3 +al2,0,i, j ti 2 sj 0 + al2,1,i, j ti 2 sj 1 + al2,2,i, j ti 2 sj 2 + al2,3,i, j ti 2 sj 3 +al3,0,i, j ti 3 sj 0 + al3,1,i, j ti 3 sj 1 + al3,2,i, j ti 3 sj 2 + al3,3,i, j ti 3 sj 3 = li, j la surface interpolée sur un carré Ipi, j , pi+1, j , pi+1, j+1, pi, j+1M est donnée par Pi, j Hu, vL = Pxi, j Iti , sj M = Pxi, j I fiHuL, gjHvLM Pyi, j Iti , sj M = Pyi, j I fiHuL, gjHvLM Pzi, j Iti , sj M = Pzi, j I fiHuL, gjHvLM ti = fiHuL = u -i etsj = gj HvL = v - j fiHciL = 0 , fiHdiL = 1, gj Ie j M = 0, gj Ihj M = 1 d ti d u = d fi d u = d sj d v = d gj d v = 1 pour u, v œ Ii, j = @ci , diDäAe j , hjE pour i = 0, ..., m et j = 0, .., n et pour l œ 8x, y, z< les dérivés dansles directions u, v et u v Pu li, j Iti , sj M = ⁄k=0 3 ⁄l=0 3 k alk,l,i, j ti k-1 sj l Pu li, j Iti , sj M = al1,0,i, j ti 0 sj 0 + al1,1,i, j ti 0 sj 1 + al1,2,i, j ti 0 sj 2 + al1,3,i, j ti 0 sj 3 + 2 al2,0,i, j ti 1 sj 0 +2 al2,1,i, j ti 1 sj 1 + 2 al2,2,i, j ti 1 sj 2 + 2 al2,3,i, j ti 1 sj 3 +3 al3,0,i, j ti 2 sj 0 + 3 al3,1,i, j ti 2 sj 1 + 3 al3,2,i, j ti 2 sj 2 + 3 al3,3,i, j ti 2 sj 3 Pv li, j Iti , sj M = ⁄k=0 3 ⁄l=0 3 l alk,l,i, j ti k sj l-1 Pv li, j Iti , sj M = al0,1,i, j ti 0 sj 0 + 2 al0,2,i, j ti 0 sj 1 + 3 al0,3,i, j ti 0 sj 2 +al1,1,i, j ti 1 sj 0 + 2 al1,2,i, j ti 1 sj 1 + 3 al1,3,i, j ti 1 sj 2 +al2,1,i, j ti 2 sj 0 + 2 al2,2,i, j ti 2 sj 1 + 3 al2,3,i, j ti 2 sj 2 +al3,1,i, j ti 3 sj 0 + 2 al3,2,i, j ti 3 sj 1 + 3 al3,3,i, j ti 3 sj 2 Pu v li, j Iti , sj M = ⁄k=1 3 ⁄l=1 3 k l alk,l,i, j ti k-1 sj l-1 Pu v li, j Iti , sj M = al1,1,i, j ti 0 sj 0 + 2 al1,2,i, j ti 0 sj 1 + 3 al1,3,i, j ti 0 sj 2 +2 al2,1,i, j ti 1 sj 0 + 4 al2,2,i, j ti 1 sj 1 + 6 al2,3,i, j ti 1 sj 2 +3 al3,1,i, j ti 2 sj 0 + 6 al3,2,i, j ti 2 sj 1 + 9 al3,3,i, j ti 2 sj 2 | 85les conditions qui construisent le système Pli, j H0, 0L = li, j = al0,0,i, j Pli, j H1, 0L = li+1, j = al0,0,i, j + al1,0,i, j + al2,0,i, j + al3,0,i, j Pli, j H0, 1L = li, j + 1 = al0,0,i, j + al0,1,i, j + al0,2,i, j + al0,3,i, j Pli, j H1, 1L = ⁄k=0 3 ⁄l=0 3 alk,l,i, j Pu li, j H0, 0L = al1,0,i, j Pu li, j H1, 0L = al1,0,i, j + 2 al2,0,i, j + 3 al3,0,i, j Pu li, j H0, 1L = al1,0,i, j + al1,1,i, j + al1,2,i, j + al1,3,i, j Pu li, j H1, 1L = ⁄k=1 3 ⁄l=0 3 k alk,l,i, j Pv li, j H0, 0L = al0,1,i, j Pv li, j H1, 0L = al0,1,i, j + al1,1,i, j + al2,1,i, j + al3,1,i, j Pv li, j H0, 1L = al0,1,i, j + 2 al0,2,i, j + 3 al0,3,i, j Pv li, j H1, 1L = ⁄k=0 3 ⁄l=1 3 l alk,l,i, j Pu v li, j H0, 0L = al1,1,i, j Pu v li, j H1, 0L = al1,1,i, j + 2 al2,1,i, j + 3 al3,1,i, j Pu v li, j H0, 1L = al1,1,i, j + 2 al1,2,i, j + 3 al1,3,i, j Pu v li, j H1, 1L = ⁄k=1 3 ⁄l=1 3 k l alk,l,i, j le système est donnée par 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 2 4 6 0 3 6 9 ax0,0,i, j ay0,0,i, j az0,0,i, j ax0,1,i, j ay0,1,i, j az0,1,i, j ax0,2,i, j ay0,2,i, j az0,2,i, j ax0,3,i, j ay0,3,i, j az0,3,i, j ax1,0,i, j ay1,0,i, j az1,0,i, j ax1,1,i, j ay1,1,i, j az1,1,i, j ax1,2,i, j ay1,2,i, j az1,2,i, j ax1,3,i, j ay1,3,i, j az1,3,i, j ax2,0,i, j ay2,0,i, j az2,0,i, j ax2,1,i, j ay2,1,i, j az2,1,i, j ax2,2,i, j ay2,2,i, j az2,2,i, j ax2,3,i, j ay2,3,i, j az2,3,i, j ax3,0,i, j ay3,0,i, j az3,0,i, j ax3,1,i, j ay3,1,i, j az3,1,i, j ax3,2,i, j ay3,2,i, j az3,2,i, j ax3,3,i, j ay3,3,i, j az3,3,i, j = Pxi, j H0, 0L Pyi, j H0, 0L Pzi, j H0, 0L Pxi, j H1, 0L Pyi, j H1, 0L Pzi, j H1, 0L Pxi, j H0, 1L Pyi, j H0, 1L Pzi, j H0, 1L Pxi, j H1, 1L Pyi, j H1, 1L Pzi, j H1, 1L Pu xi, j H0, 0L Pu yi, j H0, 0L Pu zi, j H0, 0L Pu xi, j H1, 0L Pu yi, j H1, 0L Pu zi, j H1, 0L Pu xi, j H0, 1L Pu yi, j H0, 1L Pu zi, j H0, 1L Pu xi, j H1, 1L Pu yi, j H1, 1L Pu zi, j H1, 1L Pv xi, j H0, 0L Pv yi, j H0, 0L Pv zi, j H0, 0L Pv xi, j H1, 0L Pv yi, j H1, 0L Pv zi, j H1, 0L Pv xi, j H0, 1L Pv yi, j H0, 1L Pv zi, j H0, 1L Pv xi, j H1, 1L Pv yi, j H1, 1L Pv zi, j H1, 1L Pu v xi, j H0, 0L Pu v yi, j H0, 0L Pu v zi, j H0, 0L Pu v xi, j H1, 0L Pu v yi, j H1, 0L Pu v zi, j H1, 0L Pu v xi, j H0, 1L Pu v yi, j H0, 1L Pu v zi, j H0, 1L Pu v xi, j H1, 1L Pu v yi, j H1, 1L Pu v zi, j H1, 1L C’est le système de base à résoudre pour le carré Hi, jL, ceci devra être mis en une boucle itérative pour calculer les surfaces d’interpolation pour toutes les carrés Hi, jL; c’est ce que l’on va montrer dans l’exemple suivant où nous interpolons à travers une grille de 4ä4 points. 86 | Maintenant, nous allons montrer le premier exemple concret de la construction d’une surface interpolée travers des points discrets, comme nous l’avons mentionné ci-dessus, il y aura deux autres types de surfaces d’interpolation: les surfaces de Bézier et les surfaces NURBS. La spline bicubique ne se propage pas dans les pratiques architecturales autant que les Bézier et les NURBS, mais dans cette recherche, nous allons l’utiliser en raison de sa bonne précision. Itération à travers 4ä4 points en utilisant la spline bicubique G = 9pi, j = Ixi, j , yi, j , zi, j M œ !3 , pour i = 1, ..., m et j = 1, .., n = est un ensemble de mä n points de données distincts p1,1 = H0, 0, 0L, p1,2 = I- 1 4 , 1 2 , 1 2 M , p1,3 = I 1 2 , 2, - 1 4 M , p1,4 = I0, 3, 1 4 M, p2,1 = I1, - 1 4 , - 1 4 M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, - 1 4 M , p2,4 = I1, 5 2 , 0M p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1 2 M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1 4 M, p4,1 = I3, 0, 1 4 M, p4,2 = I 5 2 , 1, - 1 4 M, p4,3 = I3, 2, 1 2 M et p4,4 = I3, 5 2 , 1 2 M les tangentes aux extrémités Su = (1, 0, 0), Sv = (0, 1, 0), Su v = (1, 1, 0), Eu = (1, 0, 0), Ev = (0, 1, 0) et Eu v = (1, 1, 0) facteur d’échelle tr = 1 2 ak,l,i, j = Iaxk,l,i, j , ayk,l,i, j , azk,l,i, j M, Pi, j Iti , sj M = IPxi, j Iti , sj M, P yi, j Iti , sj M, Pzi, j Iti , sj MM Pu i, j Iti , sj M = IPu xi, j Iti , sj M, Pu yi, j Iti , sj M, Pu zi, j Iti , sj MM Pv i, j Iti , sj M = IPv xi, j Iti , sj M, Pv yi, j Iti , sj M, Pv zi, j Iti , sj MM Pu v i, j Iti , sj M = IPu v xi, j Iti , sj M, Pu v yi, j Iti , sj M, Pu v zi, j Iti , sj MM m = 4 et n = 4 nous itérons pour i = 1, ..., m - 1 et j = 1, ..., n - 1 Conditions pour les tangentes si i = 1, Pu i, j H0, 0L = tr Su sinon Pu i, j H0, 0L = trIpi+1, j - pi-1, j M et Pu i, j H0, 1L = tr Su sinon Pu i, j H0, 1L = trIpi+1, j+1 - pi-1, j+1M si i = m - 1, Pu i, j H1, 0L = tr Eu sinon Pu i, j H1, 0L = trIpi+2, j - pi, j M et Pu i, j H1, 1L = tr Eu sinon Pu i, j H0, 1L = trIpi+2, j+1 - pi, j+1M si j = 1, Pv i, j H0, 0L = tr Sv sinon Pv i, j H0, 0L = trIpi, j+1 - pi, j-1M et Pv i, j H1, 0L = tr Sv sinon Pv i, j H1, 0L = trIpi+1, j+1 - pi+1, j-1M si j = n - 1, Pv i, j H0, 1L = tr Ev sinon Pv i, j H0, 1L = trIpi, j+2 - pi, j M et Pv i, j H1, 1L = tr Ev sinon Pv i, j H1, 1L = trIpi+1, j+2 - pi+1, j M si i = 1 Í j = 1, Pu v i, j H0, 0L = tr Su v sinon Pu v i, j H0, 0L = trIpi+1, j+1 - pi+1, j-1 - pi-1, j+1 - pi-1, j-1M si i = m - 1 Í j = 1, Pu v i, j H1, 0L = tr Su v sinon Pu v i, j H1, 0L = trIpi+2, j+1 - pi+2, j-1 - pi, j+1 - pi, j-1M si i = 1 Í j = n - 1, Pu v i, j H0, 1L = tr Su v sinon Pu v i, j H0, 1L = trIpi+1, j+2 - pi+1, j - pi-1, j+2 - pi-1, j M si i = m - 1 Í j = n - 1, Pu v i, j H1, 1L = tr Eu v sinon Pu v i, j H1, 1L = trIpi+2, j+2 - pi+2, j - pi, j+2 - pi, j M | 87Le système est donnée par ax0,0,i, j ay0,0,i, j az0,0,i, j ax0,1,i, j ay0,1,i, j az0,1,i, j ax0,2,i, j ay0,2,i, j az0,2,i, j ax0,3,i, j ay0,3,i, j az0,3,i, j ax1,0,i, j ay1,0,i, j az1,0,i, j ax1,1,i, j ay1,1,i, j az1,1,i, j ax1,2,i, j ay1,2,i, j az1,2,i, j ax1,3,i, j ay1,3,i, j az1,3,i, j ax2,0,i, j ay2,0,i, j az2,0,i, j ax2,1,i, j ay2,1,i, j az2,1,i, j ax2,2,i, j ay2,2,i, j az2,2,i, j ax2,3,i, j ay2,3,i, j az2,3,i, j ax3,0,i, j ay3,0,i, j az3,0,i, j ax3,1,i, j ay3,1,i, j az3,1,i, j ax3,2,i, j ay3,2,i, j az3,2,i, j ax3,3,i, j ay3,3,i, j az3,3,i, j = 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 0 2 4 6 0 3 6 9 -1 . Pxi, j H0, 0L Pyi, j H0, 0L Pzi, j H0, 0L Pxi, j H1, 0L Pyi, j H1, 0L Pzi, j H1, 0L Pxi, j H0, 1L Pyi, j H0, 1L Pzi, j H0, 1L Pxi, j H1, 1L Pyi, j H1, 1L Pzi, j H1, 1L Pu xi, j H0, 0L Pu yi, j H0, 0L Pu zi, j H0, 0L Pu xi, j H1, 0L Pu yi, j H1, 0L Pu zi, j H1, 0L Pu xi, j H0, 1L Pu yi, j H0, 1L Pu zi, j H0, 1L Pu xi, j H1, 1L Pu yi, j H1, 1L Pu zi, j H1, 1L Pv xi, j H0, 0L Pv yi, j H0, 0L Pv zi, j H0, 0L Pv xi, j H1, 0L Pv yi, j H1, 0L Pv zi, j H1, 0L Pv xi, j H0, 1L Pv yi, j H0, 1L Pv zi, j H0, 1L Pv xi, j H1, 1L Pv yi, j H1, 1L Pv zi, j H1, 1L Pu v xi, j H0, 0L Pu v yi, j H0, 0L Pu v zi, j H0, 0L Pu v xi, j H1, 0L Pu v yi, j H1, 0L Pu v zi, j H1, 0L Pu v xi, j H0, 1L Pu v yi, j H0, 1L Pu v zi, j H0, 1L Pu v xi, j H1, 1L Pu v yi, j H1, 1L Pu v zi, j H1, 1L ti = fiHuL = u -Hi - 1L etsj = gj HvL = v - H j - 1L, Pi, j Hu, vL = IPxi, j Hu, vL, P yi, j Hu, vL, Pzi, j Hu, vLM où Pl i, j Hu, vL = al0,0,i, j + al0,1,i, j Hv - H j - 1LL + al0,2,i, j Hv - H j - 1LL2 + al0,3,i, j Hv - H j - 1LL3 + al1,0,i, j Hu - Hi - 1LL + al1,1,i, j Hu - Hi - 1LL Hv - H j - 1LL + al1,2,i, j Hu - Hi - 1LL Hv - H j - 1LL2 + al1,3,i, j Hu - Hi - 1LL Hv - H j - 1LL3 + al2,0,i, j Hu - Hi - 1LL2 + al2,1,i, j Hu - Hi - 1LL2 Hv - H j - 1LL + al2,2,i, j Hu - Hi - 1LL2 Hv - H j - 1LL2 + al2,3,i, j Hu - Hi - 1LL2 Hv - H j - 1LL3 + al3,0,i, j Hu - Hi - 1LL3 + al3,1,i, j Hu - Hi - 1LL3 Hv - H j - 1LL + al3,2,i, j Hu - Hi - 1LL3 Hv - H j - 1LL2 + al3,3,i, j Hu - Hi - 1LL3 Hv - H j - 1LL3 l' interpolant PHu, vL est égal à si 0 § u < 1 Ï 0 § v < 1 , PHu, vL = P1,1Hu, vL, si 0 § u < 1 Ï 1 § v < 2 , PHu, vL = P1,2Hu, vL , si 0 § u < 1 Ï 2 § v § 3 , PHu, vL = P1,3Hu, vL si 1 § u < 2 Ï 0 § v < 1 , PHu, vL = P2,1Hu, vL, si 1 § u < 2 Ï 1 § v < 2 , PHu, vL = P2,2Hu, vL, si 1 § u < 2 Ï 2 § v § 3 , PHu, vL = P2,3Hu, vL si 2 § u § 3 Ï 0 § v < 1 , PHu, vL = P3,1Hu, vL, si 2 § u § 3 Ï 1 § v < 2 , PHu, vL = P3,2Hu, vL, si 2 § u § 3 Ï 2 § v § 3 , PHu, vL = P3,3Hu, vL Représentation d’une itération à travers 4ä4 points en utilisant la spline bicubique 88 | Construire une surface à partir de données collectées Maintenant que nous avons expliqué comment construire une surface bicubique à partir d’un ensemble de points donnés, nous allons montrer comment il pourrait être très utile pour le processus de conception architecturale, à savoir la création d’un modèle mathématique d’un certain contexte. Collecte des points de données de la surface de la statue L’ensemble des 17ä11 points de données pts = 8887.4, 0., 0.<, 85.9, 0., 3.45575<, 88.65, 0., 6.9115<, 89.25, 0., 10.3673<, 811.65, 0., 13.823<, 811.95, 0., 17.2788<, 812.65, 0., 20.7345<, 812.65, 0., 24.1903<, 87.95, 0., 27.646<, 87.6, 0., 31.1018<, 87.1, 0., 34.5575<<, 886.59937, 2.73355, 0.<, 86.6376, 2.74938, 3.45575<, 87.99156, 3.31021, 6.9115<, 88.03165, 3.32682, 10.3673<, 812.2664, 5.08089, 13.823<, 811.7128, 4.85161, 17.2788<, 810.5399, 4.36578, 20.7345<, 811.0146, 4.5624, 24.1903<, 87.42396, 3.0751, 27.646<, 87.21927, 2.99032, 31.1018<, 86.91556, 2.86452, 34.5575<<, 884.98519, 4.98519, 0.<, 84.87878, 4.87878, 3.45575<, 84.52606, 4.52606, 6.9115<, 85.05635, 5.05635, 10.3673<, 85.76382, 5.76382, 13.823<, 86.25869, 6.25869, 17.2788<, 85.41066, 5.41066, 20.7345<, 85.87011, 5.87011, 24.1903<, 85.26807, 5.26807, 27.646<, 85.4447, 5.4447, 31.1018<, 85.02046, 5.02046, 34.5575<<, 882.41091, 5.82044, 0.<, 82.31523, 5.58947, 3.45575<, 81.68381, 4.06507, 6.9115<, 81.16718, 2.81783, 10.3673<, 81.07151, 2.58686, 13.823<, 82.31523, 5.58947, 17.2788<, 82.71705, 6.55954, 20.7345<, 82.87013, 6.9291, 24.1903<, 82.9658, 7.16007, 27.646<, 83.138, 7.57581, 31.1018<, 83.46329, 8.36111, 34.5575<<, 880., 6.05, 0.<, 80., 5.2, 3.45575<, 80., 3.4, 6.9115<, 80., 2.05, 10.3673<, 80., 1.8, 13.823<, 80., 3.25, 17.2788<, 80., 6.05, 20.7345<, 80., 5.85, 24.1903<, 80., 7.75, 27.646<, 80., 8.35, 31.1018<, 80., 10.75, 34.5575<<, 88-1.16718, 2.81783, 0.<, 8-1.39679, 3.37216, 3.45575<, 8-1.10978, 2.67925, 6.9115<, 8-0.650562, 1.5706, 10.3673<, 8-0.593159, 1.43201, 13.823<, 8-1.24372, 3.00261, 17.2788<, 8-2.41091, 5.82044, 20.7345<, 8-2.1813, 5.26611, 24.1903<, 8-2.58311, 6.23619, 27.646<, 8-3.17627, 7.6682, 31.1018<, 8-4.13298, 9.9779, 34.5575<<, 88-2.80312, 2.20312, 0.<, 8-2.22028, 1.02028, 3.45575<, 8-2.94454, 2.34454, 6.9115<, 8-2.09602, 1.09602, 10.3673<, 8-3.27279, 2.27279, 13.823<, 8-3.50018, 3.50018, 17.2788<, 8-7.17713, 7.17713, 20.7345<, 8-5.26795, 5.26795, 24.1903<, 8-5.51543, 5.51543, 27.646<, 8-7.03571, 7.03571, 31.1018<, 8-8.3085, 8.3085, 34.5575<<, 88-7.52962, 3.11887, 0.<, 8-4.98634, 1.32277, 3.45575<, 8-8.82305, 3.65463, 6.9115<, 8-3.70918, 1.30796, 10.3673<, 8-6.28238, 2.60225, 13.823<, 8-6.8829, 2.85099, 17.2788<, 8-11.2251, 4.6496, 20.7345<, 8-9.28499, 3.84597, 24.1903<, 8-9.05402, 3.7503, 27.646<, 8-10.3013, 4.26692, 31.1018<, 8-9.00783, 3.73116, 34.5575<<, 88-9.05, 0., 0.<, 8-9.55, 0., 3.45575<, 8-11.3, 0., 6.9115<, 8-11.55, 0., 10.3673<, 8-11.05, 0., 13.823<, 8-13.45, 0., 17.2788<, 8-14.35, 0., 20.7345<, 8-13.55, 0., 24.1903<, 8-10.2, 0., 27.646<, 8-12.05, 0., 31.1018<, 8-9.85, 0., 34.5575<<, 88-9.05402, -3.7503, 0.<, 8-8.82305, -3.65463, 3.45575<, 8-7.76059, -3.21454, 6.9115<, 8-6.28238, -2.60225, 10.3673<, 8-7.06768, -2.92753, 13.823<, 8-10.3013, -4.26692, 17.2788<, 8-8.82305, -3.65463, 20.7345<, 8-7.6682, -3.17627, 24.1903<, 8-8.82305, -3.65463, 27.646<, 8-9.65454, -3.99904, 31.1018<, 8-8.73066, -3.61636, 34.5575<<, 88-6.47003, -6.47003, 0.<, 8-6.39932, -6.39932, 3.45575<, 8-5.58614, -5.58614, 6.9115<, 8-4.10122, -4.10122, 10.3673<, 8-4.20729, -4.20729, 13.823<, 8-3.6416, -3.6416, 17.2788<, 8-4.09602, -2.79602, 20.7345<, 8-4.06569, -2.56569, 24.1903<, 8-3.51127, -3.51127, 27.646<, 8-5.69221, -5.69221, 31.1018<, 8-2.01525, -2.01525, 34.5575<<, 88-3.40588, -8.22253, 0.<, 8-3.17627, -7.6682, 3.45575<, 8-2.50658, -6.05141, 6.9115<, 8-1.79861, -4.34223, 10.3673<, 8-1.97082, -4.75798, 13.823<, 8-1.35853, -3.27977, 17.2788<, 8-1.49749, -1.50104, 20.7345<, 8-1.24874, -1.00052, 24.1903<, 8-1.24623, -2.20157, 27.646<, 8-2.64052, -6.37477, 31.1018<, 8-0.593159, -1.43201, 34.5575<<, 880., -3.15, 0.<, 80., -1.8, 3.45575<, 80., -2.4, 6.9115<, 80., -0.95, 10.3673<, 80., -4.05, 13.823<, 80., -3.45, 17.2788<, 80., -1.35, 20.7345<, 80., -0.65, 24.1903<, 80., -1.75, 27.646<, 80., -5.45, 31.1018<, 80., -1.35, 34.5575<<, 881.35853, -3.27977, 0.<, 81.5271, -1.75537, 3.45575<, 81.51844, -2.41731, 6.9115<, 81.58268, -2.02388, 10.3673<, 81.93255, -4.66559, 13.823<, 81.74121, -4.20365, 17.2788<, 81.63143, -2.0244, 20.7345<, 81.58701, -1.39291, 24.1903<, 81.5271, -2.25537, 27.646<, 82.08562, -5.03514, 31.1018<, 80.593159, -1.43201, 34.5575<<, 885.33862, -5.33862, 0.<, 83.80399, -2.50399, 3.45575<, 83.55894, -3.0894, 6.9115<, 83.68841, -3.08841, 10.3673<, 85.58711, -5.58711, 13.823<, 84.98637, -4.98637, 17.2788<, 83.5712, -3.2712, 20.7345<, 83.51011, -2.31011, 24.1903<, 83.55876, -3.05876, 27.646<, 84.7025, -4.7025, 31.1018<, 81.62758, -1.62758, 34.5575<<, 887.35095, -3.04486, 0.<, 85.49045, -2.27422, 3.45575<, 87.04219, -2.91697, 6.9115<, 87.04272, -2.91719, 10.3673<, 89.49738, -3.93394, 13.823<, 89.14163, -3.78659, 17.2788<, 810.1048, -4.18555, 20.7345<, 86.9007, -2.85836, 24.1903<, 85.84168, -2.4197, 27.646<, 86.98193, -2.89201, 31.1018<, 86.5991, -2.73344, 34.5575<<, 887.4, 0., 0.<, 85.9, 0., 3.45575<, 88.65, 0., 6.9115<, 89.25, 0., 10.3673<, 811.65, 0., 13.823<, 811.95, 0., 17.2788<, 812.65, 0., 20.7345<, 812.65, 0., 24.1903<, 87.95, 0., 27.646<, 87.6, 0., 31.1018<, 87.1, 0., 34.5575<<<; | 89Or, ces points peuvent être utilisés par la spline bicubique pour générer la surface d’interpolation suivante. Par exemple, pour créer une structure de robe autour d’une statue (ou un corps humain) qui est précisément adapté à ce corps, nous aurons besoin de définir une représentation de la surface de ce corps, mais nous pouvons recueillir que des points discrets de nombre fini de la surface (normalement effectué à l’aide d’un scanner 3D). Ici, la spline bicubique nous offre un moyen pour interpoler ces points discrets et en nous fournissant une surface paramétrique continue, qui peut s’approcher de plus en plus la surface de la statue en recueillant plus de points de données. Dans l’exemple suivant, nous allons utiliser un nombre relativement faible de points collectées de la surface de la statue, afin de créer une surface d’interpolation spline bicubique, qui en ellemême va être utile plus tard pour l’adaptation de la conception. Représentation d’une l’interpolation de points de données en utilisant la spline bicubique Cet exemple est cruciale, car elle nous permet de créer une surface paramétrique à partir des points discrets par interpolation, ce qui signifie que nous pouvons commencer à relier nos constructions géométriques qui sont continu aux données du monde physique qui sont toujours discrètes. Et avec cette surface d’approximation à notre disposition, nous montrerons comment l’adapter à une autre surface, en utilisant par exemple des transformations homotopes, tout cela est possible parce que nous avons transformé les points discrets à une surface continue. Après cela, nous allons créer des éléments architecturaux reliant ces deux surfaces, des éléments qui pourraient être utilisés pour les attacher ensemble d’une manière structurelle. 90 | ü 4.3.3. Bézier et NURBS Après avoir défini les splines cubiques et bicubiques nous allons maintenant définir la courbe de Bézier et la surface de Bézier qui sont un type important de méthodes d’approximation. Les courbes et surfaces de Bézier sont fréquemment utilisés dans l’infographie et dans autres domaines similaires beaucoup plus que les splines cubiques et bicubiques en particulier dans les systèmes de logiciels de CAO. Courbes et surfaces de Bézier, sont entièrement contenues dans l’enveloppe convexe de ses points de contrôle. Pour définir la fonction de Bézier, nous devons définir le polynôme de Bernstein qui est une combinaison linéaire de polynômes de Bernstein de base, puis nous définissons la courbe et surface de Bézier et leurs versions rationnelles. Les versions rationnelles, ajoute simplement des poids réglables pour fournir des approximations plus proches de formes arbitraires. Polynôme de Bernstein [4] un binôme est un polynôme à deux termesHla somme de deux monômesL avec le cas particulier donné par x n+1 - y n+1 = Hx - yL ⁄k=0 n x n-k y k binôme élevé à la n - ième puissance est donnée par Hx + yL n = n 0 x n y 0 + ... + n n x 0 y n = ⁄k=0 n n k x n-k y k , où le coefficient n k = n! k! Hn-kL! BHxL = ⁄k=0 n bk,nHxL bk , où bk sont les coefficients de Bernstein et bk,n sont les n + 1 polynômes de Bernstein de base de degré n où bk,nHxL = n k H1 - xL n-k x k , pour k = 0, ..., n Courbe de Bézier (rationnelle) [4] G = 8pi œ !p , i = 0, ..., n < est un ensemble de n + 1 points de données BHtL = ⁄i=0 n bi,nHtL pi = ⁄i=0 n n i H1 - tL n-i t i pi est la courbe de Bézier pour G BHtL = ⁄i=0 n n i H1-tL n-i t i pi wi ⁄i=0 n n i H1-tL n-i t i wi est la courbe de Bézier rationnelle pour G et wi sont les poids Surface de Bézier (rationnelle) [4] G = 9pi, j œ !p , i = 0, .., m et j = 0, .., n = est un ensemble de Hm + 1LµHn + 1L points de données BHu, vL = ⁄i=0 m ⁄j=0 n bi,mHuL bj,nHvL pi, j = ⁄i=0 m ⁄j=0 n m i H1 - uL m-i u i n j H1 - vL n- j v j pi, j est la surface de Bézier pour G B Hu, vL = ⁄i=0 m ⁄ j=0 n m i H1-uL m-i u i n j H1-vL n- j v j pi, j wi, j ⁄i=0 m ⁄ j=0 n m i H1-uL m-i u i n j H1-vL n- j v j pi, j est la surface de Bézier rationnelle pour G et wi, j sont les poids en fixant le paramètre u ou v Hi.e. u = u0 ou v = v0L la surface de Bézierse réduit à une courbe de Bézier Hcourbes isoparamétriquesL BHu, v0L = ⁄i=0 m ci bi,mHuL , ci = ⁄j=0 n bj,nHv0L pi, j et BHu0, vL = ⁄j=0 n c j bj,nHvL , c j = ⁄i=0 m bi,mHu0L pi, j | 91Approximation à travers 4 points en utilisant la courbe de Bézier (rationnelle) G = 9pi, j = Ixi, j , yi, j , zi, j M œ !3 , pour i = 1, ..., n = est un ensemble de n points de données distincts p1 = H0, 0, 0L, p2 = I- 1 4 , 1 2 , 1 2 M , p3 = I 1 2 , 2, - 1 4 M et p4 = I0, 3, 1 4 M et les poids sont w1 = 1, w2 = 3, w3 = 3 et w4 = 1 la courbe de Bézier pour G BHtL = 3 H1 - tL 2 t + 6 H1 - tL t 2 + 3 t 3 , 6 H1 - tL 2 t + 3 H1 - tL t 2 + 2 t 3 , t 3 la courbe de Bézier rationnelle pour G BHtL = 9 H1-tL 2 t+6 H1-tL t 2+3 t 3 H1-tL 3+9 H1-tL 2 t+3 H1-tL t 2+t 3 , 18 H1-tL 2 t+3 H1-tL t 2+2 t 3 H1-tL 3+9 H1-tL 2 t+3 H1-tL t 2+t 3 , t 3 H1-tL 3+9 H1-tL 2 t+3 H1-tL t 2+t 3 Représentation d’une approximation à travers 4 points en utilisant une courbe de Bézier (rationnelle) Approximation à travers 4ä4 points utilisant les surface de Bézier (rationnelle) G = 9pi, j = Ixi, j , yi, j , zi, j M œ !3 , pour i = 1, ..., m et j = 1, .., n = est un ensemble de män points de données distincts p1,1 = H0, 0, 0L, p1,2 = I- 1 4 , 1 2 , 1 2 M , p1,3 = I 1 2 , 2, - 1 4 M , p1,4 = I0, 3, 1 4 M, p2,1 = I1, - 1 4 , - 1 4 M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, - 1 4 M , p2,4 = I1, 5 2 , 0M p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1 2 M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1 4 M, p4,1 = I3, 0, 1 4 M, p4,2 = I 5 2 , 1, - 1 4 M, p4,3 = I3, 2, 1 2 M et p4,4 = I3, 5 2 , 1 2 M les poids sont w1,1 = 1, w1,2 = 1 , w1,3 = 1 , w1,4 = 1, w2,1 = 1, w2,2 = 1, w2,3 = 1 , w2,4 = 1 w3,1 = 1, w3,2 = 10 , w3,3 = 1 , w3,4 = 1, w4,1 = 1, w4,2 = 1, w4,3 = 1 et w4,4 = 1 la surface de Bézier approximant G BHu, vL = 3 H1 - uL 2 u H1 - vL 3 + 6 H1 - uL u 2 H1 - vL 3 + 3 u 3 H1 - vL 3 - 3 4 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 18 H1 - uL u 2 H1 - vL 2 v + 15 2 u 3 H1 - vL 2 v + 3 2 H1 - uL 3 H1 - vL v 2 + 9 H1 - uL 2 u H1 - vL v 2 + 18 H1 - uL u 2 H1 - vL v 2 + 9 u 3 H1 - vL v 2 + 3 H1 - uL 2 u v3 + 6 H1 - uL u 2 v 3 + 3 u 3 v 3 , - 3 4 H1 - uL 2 u H1 - vL 3 + 3 2 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 9 H1 - uL u 2 H1 - vL 2 v + 3 u 3 H1 - vL 2 v + 6 H1 - uL 3 H1 - vL v 2 + 18 H1 - uL 2 u H1 - vL v 2 + 18 H1 - uL u 2 H1 - vL v 2 + 6 u 3 H1 - vL v 2 + 3 H1 - uL 3 v 3 + 15 2 H1 - uL 2 u v3 + 9 H1 - uL u 2 v 3 + 5 u 3 v 3 2 , - 3 4 H1 - uL 2 u H1 - vL 3 + 1 4 u 3 H1 - vL 3 + 3 2 H1 - uL 3 H1 - vL 2 v + 9 2 H1 - uL u 2 H1 - vL 2 v - 3 4 u 3 H1 - vL 2 v - 3 4 H1 - uL 3 H1 - vL v 2 - 9 4 H1 - uL 2 u H1 - vL v 2 + 3 2 u 3 H1 - vL v 2 + 1 4 H1 - uL 3 v 3 + 3 4 H1 - uL u 2 v 3 + u 3 v 3 2 92 | la surface de Bézier rationnelle approximant G BHu, vL = JI3 H1 - uL 2 u H1 - vL 3 + 6 H1 - uL u 2 H1 - vL 3 + 3 u 3 H1 - vL 3 - 3 4 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 180 H1 - uL u 2 H1 - vL 2 v + 15 2 u 3 H1 - vL 2 v + 3 2 H1 - uL 3 H1 - vL v 2 + 9 H1 - uL 2 u H1 - vL v 2 + 18 H1 - uL u 2 H1 - vL v 2 + 9 u 3 H1 - vL v 2 + 3 H1 - uL 2 u v3 + 6 H1 - uL u 2 v 3 + 3 u 3 v 3 Më IH1 - uL 3 H1 - vL 3 + 3 H1 - uL 2 u H1 - vL 3 + 3 H1 - uL u 2 H1 - vL 3 + u 3 H1 - vL 3 + 3 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 90 H1 - uL u 2 H1 - vL 2 v + 3 u 3 H1 - vL 2 v + 3 H1 - uL 3 H1 - vL v 2 + 9 H1 - uL 2 u H1 - vL v 2 + 9 H1 - uL u 2 H1 - vL v 2 + 3 u 3 H1 - vL v 2 + H1 - uL 3 v 3 + 3 H1 - uL 2 u v3 + 3 H1 - uL u 2 v 3 + u 3 v 3 M, J- 3 4 H1 - uL 2 u H1 - vL 3 + 3 2 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 90 H1 - uL u 2 H1 - vL 2 v + 3 u 3 H1 - vL 2 v + 6 H1 - uL 3 H1 - vL v 2 + 18 H1 - uL 2 u H1 - vL v 2 + 18 H1 - uL u 2 H1 - vL v 2 + 6 u 3 H1 - vL v 2 + 3 H1 - uL 3 v 3 + 15 2 H1 - uL 2 u v3 + 9 H1 - uL u 2 v 3 + 5 u 3 v 3 2 Ní IH1 - uL 3 H1 - vL 3 + 3 H1 - uL 2 u H1 - vL 3 + 3 H1 - uL u 2 H1 - vL 3 + u 3 H1 - vL 3 + 3 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 90 H1 - uL u 2 H1 - vL 2 v + 3 u 3 H1 - vL 2 v + 3 H1 - uL 3 H1 - vL v 2 + 9 H1 - uL 2 u H1 - vL v 2 + 9 H1 - uL u 2 H1 - vL v 2 + 3 u 3 H1 - vL v 2 + H1 - uL 3 v 3 + 3 H1 - uL 2 u v3 + 3 H1 - uL u 2 v 3 + u 3 v 3 M, J- 3 4 H1 - uL 2 u H1 - vL 3 + 1 4 u 3 H1 - vL 3 + 3 2 H1 - uL 3 H1 - vL 2 v + 45 H1 - uL u 2 H1 - vL 2 v - 3 4 u 3 H1 - vL 2 v - 3 4 H1 - uL 3 H1 - vL v 2 - 9 4 H1 - uL 2 u H1 - vL v 2 + 3 2 u 3 H1 - vL v 2 + 1 4 H1 - uL 3 v 3 + 3 4 H1 - uL u 2 v 3 + u 3 v 3 2 Ní IH1 - uL 3 H1 - vL 3 + 3 H1 - uL 2 u H1 - vL 3 + 3 H1 - uL u 2 H1 - vL 3 + u 3 H1 - vL 3 + 3 H1 - uL 3 H1 - vL 2 v + 9 H1 - uL 2 u H1 - vL 2 v + 90 H1 - uL u 2 H1 - vL 2 v + 3 u 3 H1 - vL 2 v + 3 H1 - uL 3 H1 - vL v 2 + 9 H1 - uL 2 u H1 - vL v 2 + 9 H1 - uL u 2 H1 - vL v 2 + 3 u 3 H1 - vL v 2 + H1 - uL 3 v 3 + 3 H1 - uL 2 u v3 + 3 H1 - uL u 2 v 3 + u 3 v 3 MN Représentation d’une approximation à travers 4ä4 points en utilisant une surface de Bézier (rationnelle) | 93NURBS Après avoir défini les courbes et surfaces de Bézier nous allons maintenant définir le plus populaire des méthodes d’approximation utilisées dans les logiciels de CAO aujourd’hui, à savoir les NURBS (non uniform rational B-spline) courbes et surfaces. NURBS sont une généralisation des courbes et surfaces de Bézier (i.e. la représentation de Bézier est un simple cas de B-splines lorsque le nombre de points de contrôle = l’ordre de k). Pour définir la NURBS, nous devons définir la fonction B-spline et le vecteur de nœud. Courbes et surfaces NURBS [5] G = 8pi œ !p , i = 0, ..., n < est un ensemble de n + 1 points de données T = 8t0, ..., tm< t0 § ... § tm est le vecteur de nœud la même valeur ti ne doit pas apparaître plus d ' une fois où k k = l' ordre de la B - spline Hi.e. le degré = l' ordre - 1L la courbe NURBS de base est donnée par NHtL = ⁄i=0 n hi,k HtL pi où hi,k HtL est la fonction B - spline de degré Hk - 1L associé au vecteur de nœud T pour k = 1, hi,1HtL = 1 si t œ @ti , ti+1D et 0 sinon et pour k > 1, hi,k HtL = t-ti ti+k-1-ti hi,k-1HtL + ti+k-t ti+k-ti+1 hi+1,k-1HtL ti § t § ti+k ï hi,k HtL > 0 , t0 § t § ti et ti+k § t § tn+k ï hi,k HtL = 0 et tk-1 § t § tn+1 ï ⁄i=0 n hi,k HtL = 1 Hpropriété de normalisationL # nœuds = # points de contrôle + l' ordre de la courbe Hdegré + 1L ï Hm + 1L = Hn + 1L + k ï m = n + k Hpour 5 points de contrôle i.e. n = 4L vecteur de nœud uniforme HpériodiqueLï ti - ti-1 = constant ï T = 80, 1, 2, 3, 4, 5, 6, 7< avec une plage de paramètres : Hk - 1L § t § Hn + 1L vecteur de nœud non périodique ï k valeurs répétées à la fin ï T = 80, 0, 0, 1, 2, 3, 3, 3< vecteur de nœud non - uniforme ï k valeurs répétées à la finï T = 80, 0, 0, 1.5, 2.3, 3, 3, 3< avec une plage de paramètres 0 § t § Hn - k + 2L NHtL = ⁄i=0 n hi,k HtL wi pi ⁄i=0 n hi,k HtL wi est la courbe NURBS avec wi sont les poids G = 9pi, j œ !3 , i = 0, .., m et j = 0, .., n= est un ensemble de Hm + 1LäHn + 1L points de données U = 9u0, ..., up= u0 § ... § up vecteur de noeud dansla direction uet V = 9v0, ..., vq= v0 § ... § vq vecteur de nœud dansla direction v la même valeur ui Hresp. viL ne doit pas apparaître plus que k Hresp.lL fois où k = l' ordre de la B - spline dansla direction u Hresp.l dansla direction vL la surface de NURBS de base est donnée par NHu, vL = ⁄i=0 m ⁄j=0 n hi,k HuL h j,l HvL pi, j où hi,k HuL et h j,l HvLsont des fonctions B - splines de degré Hk - 1L et Hl - 1L associé aux vecteurs de nœud U et V # nœuds = # points de contrôle + l' ordre de la courbe Hdegré + 1L ï Hp + 1L = Hm + 1L + k ï p = m + k et Hq + 1L = Hn + 1L + l ï q = n + l NHu, vL = ⁄i=0 m ⁄ j=0 n hi,k HuL hj,l HvL wi, j pi, j ⁄i=0 m ⁄ j=0 n hi,k HuL hj,l HvL wi, j est la surface NURBS rationnelle avec wi, j sont les poids 94 | Approximation à travers 9 points utilisant la courbe NURBS d’ordre 3 avec un vecteur de nœud non périodique G = 9pi, j = Ixi, j , yi, j , zi, j M œ !3 , pour i = 1, ..., n = est un ensemble de n points de données distincts p1 = H1, 2, 0L, p2 = H2, 4, 1L , p3 = H3, 2, 0L , p4 = H4, 1, 2L , p5 = H4, 7, 9L, p6 = H5, -2, 6L , p7 = H6, 3, 3L , p8 = H7, 0, 2L et p9 = H8, -1, 4L les poids sont w1 = 1, w2 = 3, w3 = 3 , w4 = 2, w5 = 4, w6 = 1, w7 = 3 , w8 = 1 et w9 = 1 le vecteur de nœud non périodique est donnée par 80, 0, 0, 1, 2, 3, 4, 5, 6, 7, 7, 7< Représentation d’une approximation à travers 9 points utilisant la courbe NURBS d’ordre 3 Comme nous l’avons mentionné plus tôt, l’interpolation (approximation) NURBS serait la troisième méthode d’interpolation, nous allons définir dans cette recherche. Modélisation NURBS a gagné grande popularité ces derniers temps dans les logiciels de CAO destinés à conception architecturale et ils sont à la base de ces systèmes. Il était important pour nous dans le cadre de cette recherche de donner une construction mathématique des courbes et des surfaces NURBS, car il y a certaines parties des conceptions architecturales créés ici faites en utilisant des logiciels de CAO basé sur NURBS. De cette façon, nous pouvons procéder dans la conception de ces formes à l’aide ces systèmes logiciels mais avec la compréhension mathématique de la façon dont ces outils de conception sont construits. Cela signifie restant en conformité avec le discours initial de la recherche, à savoir fonder le processus de conception sur une compréhension mathématique complète des méthodes géométriques impliqués. Les courbes et les surfaces de NURBS sont largement utilisés dans la conception de des formes qui nécessitent des lignes de courant et de continuité qui est le cas dans la conception automobile et la conception aéronautique. Dans notre contexte architectural nous allons montrer des conceptions de formes qui partagent certaines de ces caractéristiques, de cette manière, nous sommes en mesure de montrer la capacité et l’intérêt pour l’utilisation et la construction de ces outils de modélisation. | 95Approximation à travers 5ä5 points en utilisant la surface NURBS d’ordre 3 G = 9pi, j = Ixi, j , yi, j , zi, j M œ !3 , pour i = 1, ..., m et j = 1, .., n = est un ensemble de män points de données distincts p1,1 = H0, 0, 0L, p1,2 = I- 1 4 , 1 2 , 1 2 M , p1,3 = I 1 2 , 2, - 1 4 M , p1,4 = I0, 3, 1 4 M, p1,5 = I0, 4, 1 4 M , p2,1 = I1, - 1 4 , - 1 4 M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, - 1 4 M , p2,4 = I1, 5 2 , 0M, p2,5 = I1, 4, 1 4 M, p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1 2 M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1 4 M, p3,5 = I2, 4, 1 4 M, p4,1 = I3, 0, 1 4 M, p4,2 = I 5 2 , 1, - 1 4 M, p4,3 = I3, 2, 1 2 M , p4,4 = I3, 5 2 , 1 2 M, p4,5 = I3, 4, 1 4 M, p5,1 = I4, 0, 1 4 M, p5,2 = I4, 1, - 1 4 M, p5,3 = I4, 2, 1 2 M , p5,4 = I4, 5 2 , 1 2 M et p5,5 = I4, 4, 1 4 M les poids sont w1,1 = 1, w1,2 = 1 , w1,3 = 1 , w1,4 = 1, w2,1 = 1, w2,2 = 1, w2,3 = 1 , w2,4 = 1 w3,1 = 1, w3,2 = 1 , w3,3 = 1 , w3,4 = 1, w4,1 = 1, w4,2 = 1, w4,3 = 1 et w4,4 = 1 le vecteur de nœud non périodique dansla direction u est donnée par 80, 0, 0, 1, 2, 3, 3, 3< le vecteur de nœud non périodique dansla direction v est donnée par 80, 0, 0, 3, 4, 5, 5, 5< Representation of an approximation à travers 5ä5 points en utilisant la surface NURBS d’ordre 3 Avec cet exemple, nous terminons la construction mathématique des courbes et des surfaces NURBS, qui à son tour termine les constructions de l’interpolation polynomiale, que nous avions l’intention de faire dans cette recherche. Dans la partie suivante, nous allons montrer quelques exemples de conceptions architecturales, faites en utilisant la modélisation NURBS avec l’aide d’un système de logiciels de CAO. Après ces exemples, nous aimerions réfléchir sur la vague actuelle de l’intérêt de l’architecture dans ces outils de modélisation, de leur application de base comme outil de dessin utilisant une interface utilisateur graphique, aux applications plus sophistiquées utilisant des scripts et des simulations. Cette vague a développé au cours des deux dernières décennies, possédant des noms différents et des convictions différentes, dans cette recherche, nous allons choisir le terme: architecture numérique, de se référer à cette vague dans le sens le plus large. 96 | ü 4.3.4. Concevoir utilisant NURBS Maintenant que nous avons à notre disposition la construction mathématique des courbes et surfaces NURBS nous allons montrer une certaine génération de forme en utilisant la modélisation NURBS avec l’aide d’un système de CAO. Nous allons définir une surface NURBS définie par une série de courbes NURBS planes, dont chacune est située dans un plan perpendiculaire à une courbe de base. Représentation du processus de génération de la forme architecturale utilisant Nurbs Représentation des courbes et des surfaces NURBS faites en utilisant un système de logiciel de CAO | 97Plus d’exemples de conception utilisant NURBS Maintenant, nous allons montrer un exemple de génération de forme à l’aide d’une modélisation Nurbs pour la conception d’une maison-bateau, ces exemples montrent la capacité des NURBS pour gérer conception de surfaces courbes telles que celles dans les coques de bateaux et des conceptions d’automobiles. Représentation du processus de génération de forme en utilisant des courbes et des surfaces NURBS Représentation d’un dessin fait en utilisant les NURBS dans un système de logiciel de CAO 98 | Exemple de conception en utilisant NURBS en combinaison avec la «box modeling» Jusqu’à présent, nous avons montré des conceptions en utilisant soit la modélisation «box modeling» ou l’interpolation utilisant des surfaces NURBS, dans cette partie, nous allons montrer que nous pouvons combiner les deux méthodes à savoir que la peau externe pourrait être conçu utilisant la modélisation «box modeling» et l’intérieur pourrait être élaboré en utilisant la surfaces NURBS. Représentation de l’intérieur d’une maison-bateau conçu en utilisant des surfaces NURBS Représentation de la conception extérieure de la peau en utilisant la «box modeling» | 99Plus d’exemples de conception utilisant NURBS en combinaison avec «box modeling» C’est un exemple de plus d’avoir la peau extérieure conçu en utilisant la «box modeling» tandis que l’intérieur est travaillé à l’aide de surfaces de NURBS.Il est important de présenter ces exemples qui sont établis utilisant de logiciels de CAO, car ils montrent l’étendue de la liberté et aussi la limitation de l’utilisation des interpolations méthodes (NURBS) dans la conception architecturale. Représentation de l’intérieur d’une forme que nous avons développé en utilisant la «box modeling» Représentation d’une autre partie intérieure de la même forme architecturale 100 | ü 4.4. Critique de la conception assistée par ordinateur Dans les deux premiers chapitres, nous étions occupés des questions relatives à la position de cette recherche entre les deux disciplines de l’architecture et les mathématiques (chapitre 1) et la préparation pour la construction de l’espace formel: variétés (chapitre 2). Dans le troisième chapitre, nous avons construit l’espace comme une variété et nous avons donné les définitions formelles de des formes comme des sous-variétés de l’espace euclidien utilisant submersion (définition algébrique) et l’immersion (dans la plupart des cas un plongement - définition paramétrique). Dans ce chapitre, nous avons donné des approximations de formes continue en les définissant utilisant des maillages polygonaux et des interpolations polynomiales, qui, comme nous l’avons mentionné sont le type le plus utilisé de la définition de la forme dans la conception architecturale en raison de leur utilisation dans les systèmes de logiciels de CAO. Malgré leur large diffusion, peu de architectes ont connaissance de leurs constructions mathématiques, cela dit, nous aimerions à ce point avant de commencer les définitions des opérations sur les des formes, de prendre un certain recul et de réfléchir sur ces méthodes de conception utilisant CAO. Nous aimerions comprendre la raison de leur succès et de quelle manière ils diffèrent des méthodes traditionnelles de dessin architectural en utilisant la géométrie descriptive. En cela, nous ferions une fois de plus l’utilisation des noumènes et les phénomènes de Kant pour comprendre sur le plan ontologique l’expérience de simulation de dessin. En plus de Kant, nous apporter quelques concepts de la théorie critique, en particulier de philosophes: Jean Baudrillard et Gilles Deleuze pour nous aider à comprendre le contexte global de la réussite de ces technologies numériques. Nous allions enfin réfléchir davantage ponctuellement sur les mouvements architecturaux réunis sous le parapluie de l’architecture dite numérique. Le succès de la conception utilisant de logiciels de CAO, c’est parce qu’elle est fondée sur l’idée intuitive de l’interpolation de points qui sont donnés par l’entrée du créateur à travers l’interface graphique (la souris) sans la nécessité d’avoir des connaissances mathématiques sur la fonction d’interpolation. C’est en substance rend l’ensemble du processus de dessiner en utilisant l’ordinateur rappelle le processus de dessiner utilisant le crayon et de la planche à dessin, car il n’y avait pas de transcendance de l’expérience au sens kantien a été impliqué. Ceci, certainement augmenté la vitesse de production et la précision des dessins, mais il n’y avait pas de changement de perspective. Les architectes ont pensé et ont dessiné de la même manière que précédemment, seulement maintenant en utilisant l’ordinateur, dans d’autres terme, ils ont simulé l’expérience du dessin, mais ce qui est plus problématique est la simulation de la connaissance qui se pose avec le logiciel de CAO, qui dans le cas de la conception architecturale est la simulation de la connaissance en géométrie. Nous sommes capables de voir le problème dans un exemple simple: si l’on prend la tâche de dessiner deux lignes perpendiculaires, d’abord à la main et ensuite par l’ordinateur: dans le premier cas, nous sommes confrontés à un problème classique des mathématiques qui est celui de la construction et afin de réaliser la tâche, nous appliquons les méthodes de la géométrie descriptive. Néanmoins, dans le deuxième cas à savoir, en utilisant un interface graphique du logiciel de CAO, nous allons chercher les icônes dans le menu du programme qui correspondent au dessin d’une ligne et qui correspond à trouver la perpendiculaire à cette ligne. Maintenant, la connaissance mathématique nécessaire pour effectuer cette tâche est entièrement caché de l’utilisateur dans la bibliothèque du programme; ce qui est perceptible au concepteur est la connaissance de la façon de gérer l’interface. Cette situation est problématique, non pas parce que d’une idée romantique que l’expérience de dessin est plus authentique, mais il est problématique parce que la simulation créée par le logiciel de CAO donne au concepteur l’illusion d’avoir la connaissance géométrique nécessaire pour effectuer la tâche. C’est-à- dire que le logiciel de CAO modifie la nature du problème d’un problème de géométrie à un problème d’interface, et dans ce saut il existe une perte importante de connaissances qui n’est pas nécessairement remarqué et qui va devenir de moins en moins remarqué que les interfaces de logiciels de CAO deviendront de plus en plus intuitive. Ce problème de la simulation n’est en aucun cas limité à la conception architecturale, En fait, il s’agit de la version architecturale d’un problème plus large de la société, un problème qui a été prévu par le théoricien critique Guy Debord dans son livre La société du spectacle et a été au centre du travail de philosophe Jean Baudrillard dans de son traité philosophique Simulacres et simulation. Justement, en appliquant la géométrie moderne dans la conception architecturale, nous soulignons le problème en créant une turbulence dans la simulation de la connaissance que les systèmes logiciels de CAO établissent, pour comprendre cette turbulence nous devons d’abord comprendre comment l’architecture contemporaine se rapporte à la société du spectacle de Debord. L’idée de Debord tourne autour de la dégradation de la société moderne dans laquelle la vie sociale authentique a été remplacé par sa représentation à savoir que les expériences humaines | 101société du spectacle de Debord. L’idée de Debord tourne autour de la dégradation de la société moderne dans laquelle la vie sociale authentique a été remplacé par sa représentation à savoir que les expériences humaines qui étaient autrefois vécu sont devenu simples représentations, la dégradation selon Debord se passe par le déclin d’être à avoir à apparaître [6]. Le compte de Baudrillard sur la société est tout à fait similaire de nombreux égards, comme il le prétend que notre société actuelle a remplacé toute la réalité et la signification par des symboles et des signes et que l’expérience humaine est une simulation de la réalité. Donc, à partir Alberti et Desargues (deux architectes et mathématiciens) ayant une connaissance approfondie de la géométrie comme la langue de la conception architecturale, aux architectes dits paramétriques maîtrisant leur dernier logiciel de CAO, on peut voir clairement cette dégradation de la connaissance aux apparences. Quand les architectes paramétriques utilisent des termes comme géométrie complexe ce qu’ils signifient réellement: sont des formes qui apparaissent complexe à savoir par leur nature courbée, alors que le processus de leur création contient peu de connaissance de la géométrie. Il s’agit d’un abus de langage assez fréquent, qui est toujours négligé en raison de la confusion entre la connaissance et la simulation de la connaissance, l’utilisation du terme: simulation ici ne signifie pas simplement faire semblant. Baudrillard dans Simulacres et simulation, définit la dissimulation, comme le semblant de ne pas avoir ce que l’on a, et la simulation est feindre d’avoir ce que l’on n’a pas. Il explique que la simulation est plus complexe que feindre ou faire semblant, en donnant l’exemple de simuler la maladie; il explique que, pour prétendre qu’on est malade, on reste tout simplement dans le lit et faire croire aux autres on est malade. Alors que si l’on simuler la maladie, on produit en soi certains des symptômes. La différence fondamentale ici est clair, faire semblant conserve la réalité intacte, tandis que la simulation menace la différence entre le vrai et le faux. Quelque chose de cette nature peut être vu quand les architectes utilisent des logiciels de CAO pour représenter et résoudre certains des problèmes géométriques de leur conception; la vraie connaissance n’est pas simplement remplacée par semblant (à savoir l’architecte est conscient de l’ignorance) mais cette connaissance est simulé à l’aide symptômes (i.e. gestion de l’interface), laissant l’architecte ignorent de la différence entre le vrai et le faux. Le deuxième concept important dans le livre de Baudrillard est: simulacres, il définit simulacre, non comme cacher la vérité, mais comme la vérité qui cache qu’il n’y en a pas. Simulacres sont des copies qui représente des choses qui soit n’avaient pas une réalité pour commencer, ou N’ayant plus un original, tandis que la simulation est l’imitation des opérations d’un processus du monde réel par la production de certains de ses symptômes [7]. La progression actuelle, et la vitesse de développement de logiciels de CAO de plus en plus complexe, capable de faire la stimulation visuelle de plus en plus avancé: l’architecture paramétrique, est un exemple de simulacre, où le mot paramétrique a perdu son sens mathématique original et est devenu une référence sans un référent. Baudrillard décompose la relation entre l’image et la réalité en quatre étapes qu’il relie plus tard à des périodes historiques. La première étape est une relation fidèle, entre l’image et la copie, où le signe est le reflet d’une réalité profonde, il associe ce stade avec la période pré-moderne où la représentation est clairement un portelieu artificiel pour la vraie chose. La deuxième étape est la perversion de la réalité, nous croyons que le signe est copie infidèle, qui masque et dénature la réalité comme une apparence, Baudrillard associe ce stade avec la modernité et la révolution industrielle où la distinction entre la représentation et la réalité a été rompu en raison de la prolifération des copies produites en masse d’articles, qui les transforme en produits de base. La troisième étape, masque l’absence d’une réalité profonde, où simulacre prétend être une copie fidèle, mais c’est une copie sans originale; Baudrillard associé ce stade avec la postmodernité et le capitalisme tardif où simulacre précède l’original. La quatrième étape est la simulation pure, dans laquelle le simulacre n’a pas de relation, à aucune réalité que ce soit. Ici, les produits culturels ne seraient même pas besoin de faire semblant d’être vrai au sens naïf car les expérience des vie des consommateurs sont essentiellement artificielles, il a utilisé le terme: l’hyper-réalité pour décrire cette réalité qui est de plus en plus notre vie quotidienne [7]. On peut voir une corrélation entre les étapes de Baudrillard de la relation entre l’image et la réalité et le développement de la relation entre l’architecture et les mathématiques. Les périodes médiévales et la Renaissance représentent la première étape de la relation image-réalité, où la connaissance de la géométrie visant à l’utiliser pour représenter une réalité profonde d’un univers harmonieux de divines proportions et géométrie sacrée. L’expression parfaite de cette étape, était dans l’invention de la perspective linéaire par les polymathes: Alberti, Brunelleschi et Desargues, ici on peut voir presque une tentative littérale d’utiliser l’image comme un reflet fidèle de la réalité, à savoir la peinture basée sur la perspective. Avec l’arrivée de la modernité et de la domination du cogito cartésien de la science positiviste et la révolution industrielle, la deuxième étape est claire, il y a une méfiance dans les apparences et la perception comme l’accès à la réalité. Ici, l’image est une copie infidèle qui dénature la réalité, l’architecture et l’art ne sont plus des représentations de pro- 102 | étape est claire, il y a une méfiance dans les apparences et la perception comme l’accès à la réalité. Ici, l’image est une copie infidèle qui dénature la réalité, l’architecture et l’art ne sont plus des représentations de profondes réalités harmonieuses, l’esthétique kantienne avec l’accent mis sur l’objet d’art lui-même remplacé l’esthétique classique ouvrant la voie à l’art moderne. L’intérêt en mathématiques pour représenter fidèlement la réalité a diminué hors de la faveur, cela peut être vu dans les mouvements de la peinture moderne de l’impressionnisme au cubisme et leurs équivalents architecturaux, de l’art nouveau au Bauhaus et le style international où la géométrie est enfin détaché de l’architecture. Au même temps, la science est devenue excessivement positiviste, rejetant la métaphysique et les apparences comme trompeuses et ne comptant que sur la raison humaine comme le seul accès à la réalité objective des choses qui est obscurcie par nos sens, cela peut être vu dans l’interprétation moderne de la géométrie et en physique des particules. La période postmoderne capitaliste tardive est caractérisée par la troisième phase de la relation image-réalité, c’est l’ère de la communication de masse, la mondialisation et la consommation où l’image ne représente plus un original et même masques l’absence de réalité profonde. Mouvements postmodernes dans l’art et l’architecture expriment clairement cette propriété, ce qui peut être vu, de l’essor du pop art à l’ajout de motifs classiques de l’architecture postmoderne; clairement la position de la géométrie dans l’architecture a atteint son point le plus bas. Ce qui est plus intéressant, c’est ce qui se passe aujourd’hui, qui commence à la fin du postmodernisme, et que nous pouvons identifier comme la quatrième étape de la relation image réalité, à savoir la simulation pure ou le stade hyper-réalité. Dans l’art et en particulier dans l’architecture il y a une augmentation de ce qu’on appelle l’art numérique, et au sein de la communauté architecturale: l’architecture paramétrique; on peut déjà voir dans le nom, les premiers symptômes d’une juxtaposition problématique. Numérique, étant synonyme de données informatisée numériques, qui est le monde des mathématiques discrètes de calcul, couplés avec l’art, le monde que depuis plus de deux siècles a rejeté les mathématiques. Ce couplage semble à première vue être un renouveau de l’utopie prémoderne de la renaissance mais cela ne pouvait pas être plus loin de la vérité. En fait, il est un symptôme parfait de la quatrième étape de Baudrillard de la relation image-réalité où le simulacre n’a plus aucun rapport avec la réalité et les signes se réfèrent seulement à d’autres signes [7]. Un bon exemple de cette propriété peut être vu dans l’intérêt retourné en géométrie dans l’architecture paramétrique, ce retour est fondamentalement et purement simulée sans lien véritable avec l’étude moderne de la géométrie. Cette simulation est réalisée par la création d’un mythe, à savoir inventer de nouveaux termes, expressions, un système de signes référant seulement à d’autres signes sans réalités originale ou, dans certains cas avait une réalité originale qui n’est plus là. Par exemple, des mots comme: paramétrique, continue, morphogenèse et topologie, sont coupés de leurs origines mathématiques et donné une nouvelle vie dans le système simulé. Même termes fondamentaux, comme la «géométrie» lui-même ne se réfèrent plus à son sens mathématique universelle, mais cela signifie tout simplement la forme. Le problème ici, n’est pas simplement un problème de vulgarisation des termes scientifiques comme c’est le cas dans de nombreuses œuvres philosophiques et littéraires, il est beaucoup plus problématique. Il est compréhensible de faire des actes individuels de vulgarisation pour exprimer certains concepts philosophiques, il a toujours été fait par les philosophes et des artistes, mais ici ce qui se passe n’est rien de moins que d’une tentative pour une fausse universalité. À savoir, que, par exemple, quand un mot comme “géométrie” (ou “paramétrique”) est utilisé dans son sens hyper-réel simulé, il est entendu par tout le monde, et créant ainsi un mythe à propager. Le long de la même ligne de Simulacres et simulation, nous rencontrons un autre phénomène important du capitalisme tardif, à savoir le passage de discipline au contrôle, ce concept a été élaboré par le philosophe français Gilles Deleuze, dans un de ses derniers essais intitulé Post-scriptum sur les sociétés de contrôle. Dans ce post-scriptum, nous trouvons un ton beaucoup plus politique par rapport aux écrits précédents de Deleuze, en substance Deleuze exprimer une préoccupation envers la technologie et en particulier ce qu’il appelle les machines de troisième génération: ordinateurs; une position qui rappelle la position de Heidegger envers la technologie. Il élabore des thèmes soulevés par le philosophe français Michel Foucault sur les sociétés disciplinaires; Deleuze explique que ces sociétés disciplinaires ont évolué vers des sociétés de contrôle. Foucault situé les sociétés disciplinaires dans le 18ème et 19ème siècles, elles ont atteint leur hauteur au début de la 20ème. Elles initient l’organisation de vastes espaces d’enclos; l’individu ne cesse passer d’un milieu fermé à un autre, chacun ayant ses propres lois: d’abord, la famille, puis l’école, puis la caserne, puis l’usine, parfois l’hôpital ou même la prison, l’instance prééminent d’enclos. Le projet idéal de ces milieux de enclos, est de distribuer dans l’espace, et d’ordonner dans le temps; de composer une force productive dans la dimension de l’espace-temps dont l’effet sera plus grand que la somme de ses forces composantes [8]. Deleuze affirme que nous ne sommes plus dans ces sociétés disciplinaires, nous sommes dans une crise généralisée par rapport à tout l’environnement d’enclos: | 103grand que la somme de ses forces composantes [8]. Deleuze affirme que nous ne sommes plus dans ces sociétés disciplinaires, nous sommes dans une crise généralisée par rapport à tout l’environnement d’enclos: famille, école, usine, hôpital, prison. Les administrations en charge ne cesse d’annoncer des réformes nécessaires; de réformer les écoles, de réformer les hôpitaux, de réformer les prisons, alors que tout le monde sait que ces institutions sont finis, quelle que soit la longueur de leurs périodes d’expiration. Les sociétés de contrôle, sont maintenant dans le processus de remplacement de ces sociétés disciplinaires, le contrôle est le nom du nouveau monstre, qui Deleuze et Foucault reconnaissent comme notre avenir immédiat. Deleuze exprime sa préoccupation en ce qu’il considère comme un passage de l’analogique au numérique (ou digital). Il dit que dans les sociétés disciplinaires, les différents espaces de enclos à travers laquelle l’individu passe, sont des variables indépendantes avec un langage commun analogique, en les reliant. Alors que, dans les sociétés de contrôle, on obtient à la place de différents espaces de enclos, des mécanismes de contrôle différents qui sont des variations inséparables avec un langage commun numérique. Les enclos sont des moules, des moulages distincts, mais les contrôles sont une modulation, comme un moulage auto-déformant qui continue changer d’un moment à l’autre, ce qui peut être vu dans la différence entre l’usine et la corporation; l’usine était un corps qui a tenu ses forces internes à un niveau d’équilibre, mais la corporation, qui l’a remplacé, est un esprit ou un gaz. Comme la corporation a remplacé l’usine, la formation perpétuelle tend à remplacer l’école, et le contrôle continu l’examen, ce qui est le plus sûr moyen de livrer de l’école à la corporation. Dans les sociétés disciplinaires, on a commencé toujours à nouveau; de l’école à la caserne à l’usine, tandis que dans les sociétés de contrôle, on n’est jamais fini avec quoi que ce soit, la corporation, le système éducatif, les services armés, sont tous des états métastables coexistent dans un et la même modulation, comme un système universel de déformation [8]. C’est tout à fait clair, dans la façon dont les écoles d’architecture d’aujourd’hui sont liés à des agences des architectes qui sont à la fois les enseignants et les patrons. Et comment la dynamique des studios de design et des cabinets d’architectes se ressemblent de plus en plus, devenant variations de la même chose, donc un étudiant en architecture qui a suivi une certaine doctrine d’un certain architecte peut commencer sa vie professionnelle dans le bureau de cet architecte sans jamais se sentir la transition. Alors que, dans le passé, la transition de la vie étudiante à la vie professionnelle a été très clair, ou comme le dit Deleuze: l’étudiant repartir de zéro en passant d’un enclos à l’autre i.e. de l’école au bureau. Dans les sociétés disciplinaires, l’individu a été désigné par une signature et a été indiqué dans les masses par un numéro; dans les sociétés de contrôle ce qui est important n’est pas la signature ou le nombre, mais un code: le code est un mot de passe, qui marque l’accès à informations ou la rejette. Nous nous trouvons plus, face à la paire: masse / individu, les individus sont devenus dividus, et les masses des échantillons, des données, des marchés ou des banques. L’homme disciplinaire était un produit d’énergie discontinu, mais l’homme de la société de contrôle est ondulatoire, en orbite, dans un réseau continu, partout, le surf a déjà remplacé les les sports anciens. Sociétés disciplinaires se équipés de machines portant sur l’énergie, avec le un danger passif de l’entropie et le danger actif du sabotage, les sociétés de contrôle fonctionnent avec les machines du troisième type, les ordinateurs, dont passive un danger est le brouillage et dont un danger actif est le piratage et l’introduction des virus. C’est le capitalisme de production d’ordre supérieur. Il n’achète plus des matières premières et ne vend plus les produits finis: il achète des produits finis et assebles parties, ce qu’il veut vendre est un service et ce qu’il veut acheter est des stocks [8]. La conception d’un mécanisme de contrôle, donnant la position d’un élément dans un environnement à un instant donné, est devenu une réalité avec le «smart phone». La ville imaginée par psychanalyste français Félix Guatari, où on serait en mesure de quitter son appartement, sa rue, son quartier, grâce à de une carte électronique individu qui soulève un barier donné ou être rejetée sur un jour donné ou à certaines heures, est en grande partie réaliser. Ce qui compte n’est pas la barrière, mais l’ordinateur qui permet de suivre la position de chaque personne licites ou illicites et effectue une modulation universelle [8]. On peut facilement le voir, dans le nombre écrasant des réseaux sociaux, les blogs et les plates-formes numériques pour l’échange d’informations, sur nos activités et nos emplacements, qui prolifère en permanence chaque partie de nos vies. Dans l’architecture c’est tout à fait tangible dans l’explosion des blogs et des communautés numériques favorisant l’architecture paramétrique, ce qui est l’architecture de contrôle par excellence, l’idéologie favorise l’efficacité et le contrôle sur la conception et la production de la forme architecturale. Cependant, nous devons être très vigilants ici, parce que même si il semble une motivation raisonnable pour un architecte d’être en contrôle de la conception de la forme, il est bien loin d’un type de contrôle technique qui vient de la formation disciplinaire. Dans les sociétés disciplinaires contrôle est livré avec des connaissances disciplinaires, à savoir l’architecte devrait recevoir la formation adéquate, par exemple, dans l’analyse structurelle et à partir de là un contrôle en termes de connais- 104 | plinaires contrôle est livré avec des connaissances disciplinaires, à savoir l’architecte devrait recevoir la formation adéquate, par exemple, dans l’analyse structurelle et à partir de là un contrôle en termes de connaissances disciplinaires est atteint. Alors que la plupart des logiciels de CAO aujourd’hui essaient indéfiniment à fournir aux architectes avec de plus en plus d’informations sur l’objet conçu; informations qui dépassent la connaissance de l’architecte et même son intérêt; informations qui sont en quelque sorte inutile, c’est comme si l’objectif de contrôle est le contrôle lui-même. C’est tout à fait comparable à ces heures interminables de vidéos de caméras de sécurité, pour fournir des quantités infinies d’informations, dans l’espoir que certaines d’entre elles pourrait se révéler utile si certains attaque se produirait pour traquer les attaquants. La question de savoir si nous avons besoin de ce montant de la surveillance est un autre débat, mais ce qui est clair, c’est le lien entre leur informations superflues et les informations superflues du logiciel de CAO, à savoir que soustend les deux, n’est pas une question de l’utilité comme au sens disciplinaire mais plutôt l’idéologie de contrôle. Il est devenu aujourd’hui un avantage pour un architecte d’avoir un logiciel qui permet de calculer la pression du vent sur l’objet, sans que l’architecte ait la moindre idée de ce que cela signifie du point de vue de la science de l’ingénierie structurelle. Autant il est devenu important pour un téléphone portable, d’indiquer le taux de battre cardiaque de son utilisateur sans que l’utilisateur ait la moindre idée de ce que cela signifie du point de vue médical. Nous pouvons voir dans ces exemples ce que Deleuze tentait de souligner avec sa préoccupation au sujet de la prolifération des ordinateurs dans notre vie humaine, ils alignent simplement tout dans un seul plan à l’aide d’un code numérique. | 105ü 4.5. Concernant l'architecture numérique L'influence de la montée des ordinateurs sur l'architecture est vraiment remarquable, en dehors de l'influence évidente, en termes de productivité efficace rendue possible par les logiciels de CAO (et modélisation 3D), l'influence est idéologique et assez problématique. Cette problématique vient du fait que, même si les ordinateurs rendent les choses plus faciles, plus rapides et plus efficaces, il y a un coût indirect; que ce soit hyper réalité de Baudrillard, la société de spectale de Debord ou la société de Deleuze de contrôle. Malgré le fait que l'architecture numérique dans n'importe quelle saveur il arrive, est informé, efficace et visuellement complexe; dans de nombreux aspect pourrait être considérée comme supérieure aux mouvements architecturaux antérieures, c'est l'architecture de l'hyper réalité par excellence. C'est précisément dans ce passage de l'analogue aux outils numériques, nous pouvons voir la prédiction de Deleuze de l'aplatissement de tout dans un seul plan du code numérique, et où les disciplines sont toutes des variations dans ce plan, ce qui explique l'inondation des concepts scientifiques à l'architecture numérique avec une facilité absolue. La relation de l'architecture aux disciplines scientifiques a toujours existé, mais elle a exigé un grand effort de transgression disciplinaire des architectes; résultant dans le fait que l'utilisation de concepts scientifiques dans l'architecture est restée dans une large mesure métaphorique. Et si l'utilisation d'un concept scientifique n'allait pas être métaphorique alors ce concept n'était pas d'une complexité scientifique de haut niveau; cette modestie disparaît avec l'architecture numérique en raison de l'ordinateur. L'architecture numérique utilise des concepts scientifiques de la plus haute complexité et actualités: de la topologie à la théorie du chaos, les architectes pour la première fois ont la possibilité d'utiliser ces concepts non métaphoriquement sans avoir à passer à travers les difficultés de transgression disciplinaire. Tout cela rendu possible parce que l'ordinateur était capable de simuler les connaissances nécessaires pour utiliser et manipuler ces concepts scientifiques sous la forme d'une interface conviviale du logiciel de CAO. De ce point de vue, on peut voir que, même si il est vrai qu'il y a un changement dans la pensée scientifique vers des concepts de complexité, il est tout à fait exagéré de penser que l'architecture numérique a son fondement dans cette nouvelle tendance scientifique. Ceci est simplement dû au fait que la science moderne et en particulier la physique et les mathématiques se concentre uniquement sur la logique formelle et l'expérimentation positiviste sans aucune attention à l'ontologie, tandis que l'architecture (numérique ou non) restera toujours ontologiquement compris. En d'autres termes la science moderne a atteint un niveau auquel il est fortement déconnectée de l'existence quotidienne intuitive, que la façon dont les individus moyens comprennent les faits scientifiques est similaire à la façon dont les individus antérieures ont compris leurs mythes de la création. Par exemple, tout individu aujourd'hui connaît les concepts scientifiques de l'ADN ou de la physique quantique, et serait en mesure de dire à peu près certains de leurs mécanismes. Ce qui manque toutefois, c'est une compréhension ontologique, en d'autres termes, comment la compréhension de l'individu de son existence quotidienne est différente avec la connaissance de ces concepts scientifiques; qui sont dans bien des cas tout à fait contre-intuitive. Un architecte numérique a la même position que l'individu moyen, car même si les logiciels CAO peuvent simuler certains concepts scientifiques comme l'évolution ou les systèmes dynamiques non linéaires, l'architecte qui l'utilise, n'a aucune compréhension formelle ou expérimentale de ces concepts. Ce qui signifie que l'architecte ne peut pas être pleinement conscient de l'évolution de la pensée scientifique, plus que l'individu moyen, en d'autres termes, pour que l'architecture numérique faire partie de ce changement scientifique, les architectes ont besoin de transgresser l'architecture vers les disciplines scientifiques et non seulement les simuler. Mais même si cela arrive et que les architectes reçu la connaissance scientifique disciplinaire appropriée, ils sont maintenant confrontés au problème de l'ontologie: comment rendre ces concepts scientifiques formelles significatives pour l'existence humaine quotidienne. Aujourd'hui, nous assistons de plus en plus dans les écoles d'architecture des programmes éducatifs orientés vers une approche scientifique, ce qui signifie que les les architectes qui sortent de ces programmes auraient en quelque sorte une compréhension plus profonde des sciences en question de l'individu moyen. Cependant, nous voyons que l'ensemble de ces connaissances scientifiques est médiée par l'ordinateur, puisque tous ces programmes éducatifs sont fondées sur la compréhension numérique des concepts scientifiques, et non sur les cours disciplinaires réguliers qui bien sûr serait prendre beaucoup plus de temps et d'efforts à saisir. Le fait est que, malgré la forte progression de l'architecture numérique, elle a encore un long chemin avant de donner une véritable nouvelle architecture; c'est parce qu'elle doit surmonter deux difficultés. Tout d'abord, elle a besoin de travailler durement pour correspondre à ses ambitions scientifiques et, deuxièmement, elle doit travailler encore plus dur pour fournir l'ontologie appropriée pour elle- 106 | deux difficultés. Tout d'abord, elle a besoin de travailler durement pour correspondre à ses ambitions scientifiques et, deuxièmement, elle doit travailler encore plus dur pour fournir l'ontologie appropriée pour ellemême, et que, tout en étant informée par la science moderne, elle n'a pas perdu son sens artistique et poétique et se réduite à un problème d'optimisation. Une autre question fondamentale qui semble être souvent négligé est pourquoi ce grand intérêt pour la science qui caractérise l'architecture numérique. Il est vrai que la relation entre l'architecture et la science a une longue histoire, d'un côté des raisons pratiques de l'ingénierie du bâtiment, et de l'autre côté, les analogies entre les méthodes de conception et des phénomènes naturels, mais l'architecture numérique se rapporte à la science dans une manière totalement nouvelle dépassant à la fois la pratique et le raisonnement analogique. Malgré l'apparence extérieure de fonctionnalité que l'architecture numérique donne à son intérêt pour la science, la vérité est que la science entre dans l'architecture numérique comme un obscur objet du désir, un objet de fascination pure. Ceci peut être vu dans le très grand nombre de publications, des cours théoriques et pratiques, tous dédiés sous une forme ou une autre d'utiliser des phénomènes scientifiques en tant que donateur de la forme architecturale, au point que l'on s'interroge sur le sens de ces conceptions. En dépit de leur force visuelle, ces conceptions clairement n'abordent pas les questions architecturales, comme l'espace, la circulation, etc. Et s'ils le font, il est fait d'une manière assez réductrice, comme si ces questions étaient des problèmes quantitatifs simplement positivistes (paramètres), ils n'abordent pas non plus des questions scientifiques ou techniques, après tout une enquête scientifique exige des connaissances disciplinaires et pas seulement du logiciel de CAO. Ainsi, la question de l'intérêt de l'architecture numérique dans la science n'a rien à voir avec la relation historique entre l'architecture et la science, mais une fois de plus, il fait partie d'un plus grand problème social contemporain qui se manifeste dans l'architecture à travers le couvert de l'architecture numérique. Le problème a à voir avec la position de la science moderne dans la société contemporaine en général, et comment elle a changé dans l'ère numérique. Il ne fait aucun doute, que la science a toujours été motivée par la fascination, à savoir la fascination du scientifique avec un certain phénomène et son envie de le démystifier, cela signifiait que la science (au moins depuis le siècle des Lumières) traite de fascinations sans être un objet de fascination en soi. Maintenant, avec l'ordinateur, la science devient l'objet de fascination en soi, ce qui peut être vu dans la montée de ce qu'on appelle les "geeks" (à ne pas confondre avec les informaticiens). La différence est la suivante: compte tenu n'importe quel phénomène physique, un scientifique serait fasciné par ce phénomène lui-même, tandis que les geeks plupart du temps dépourvus des connaissances disciplinaires, seraient intéressés par la simulation offerte par l'ordinateur pour étudier ce phénomène. Par exemple, les geeks qui peuvent montrer tout l'aspect d'un logiciel pour enregistrer, analyser et manipuler le son, sans aucune connaissance ou un intérêt dans la physique des ondes sonores. Cela signifie que dans notre société d'ordinateurs, des réseaux sociaux et des smartphones, la science acquiert un important nouvelles caractéristiques: le «scientific look», ce qui est au cœur de la façon dont il est entendu par l'individu moyen. Dans notre société de l'hyperréalité de Baudrillard, il ne suffit pas de simplement faire de la science telle qu'elle se fait traditionnellement en utilisant les connaissances disciplinaires, la science plus que tout doit avoir le «scientific look», pour qu'elle soit acceptée par la société dans la science. Ce «scientific look» est ce qui fait de la science un objet de désir dans les yeux de la personne moyenne contemporain, il est ce qui est fait des ordinateurs et smartphones se vendent très bien, parce que lors de l'utilisation d'un logiciel ou d'une application, il semble que si l'on fait la science. Maintenant, l'architecture numérique traite la science le long de ces mêmes lignes, un logiciel de CAO contemporain serait capable de modéliser des formes géométriques complexes de certains phénomènes physiques et un geeks serait capable de la maîtriser sans intérêt ou des connaissances dans le science elle-même. Le logiciel de CAO donne l'ingrédient magique pour le travail, notamment son «scientific look». L'ironie est que si un travail d'architecture aurait eu une étude scientifique sérieuse derrière lui, mais il n'est pas fait à l'aide d'un logiciel de CAO, il serait perçu comme moins scientifique qu'un travail fait en utilisant le logiciel de CAO, mais sans science derrière. Cela nous amène à la conclusion que l'architecture numérique n'est pas intéressé à faire entrer la science dans le travail, mais simplement le «scientific look»; qui est ensuite complété par l'utilisation abusive des termes scientifiques d'une grande complexité. On ne peut pas commencer à compter le nombre de publications de l'architecture numérique qui utilisent constamment des termes tels que la topologie, fractale, paramétrique, code génétique pour n'en nommer que quelques-uns. | 107ü 4.6. Références [1] Winged edge data structure, Hanan Samet, University of Maryland, 1998 [2] Lecture notes on Cubic spline, Donald H.House, Clemeson University, 2011 [3] http://en.wikipedia.org/wiki/Bicubic_interpolation [4] Bezier curves and surfaces, Andres Iglesias, University of Cantabria, 2001 [5] B-splines and NURBS curves and surfaces, Andres Iglesias, University of Cantabria, 2001 [6] The Society of the spectacle, Guy Debord , Buchet-Chastel, 1967 [7] Simulacra and simulation, Jean Baudrillard , Éditions Galilée, 1981 [8] Postscript on the society of control, Gilles Deleuze, Jstor, 1992 108 | 5. Opérations algébriques ü 5.1. Construction des espaces vectoriel et affine A ce stade, nous arrivons à la fin de la première partie des constructions mathématiques à savoir les définitions de formes; dans cette partie, nous avons vu le définitions paramétriques et algébriques de courbes et de surfaces, en plus nous avons vu les techniques de approximations de formes en utilisant des mailles et interpolations qui sont à la base des systèmes de logiciels de CAO. Ici, la qualité de la définition des formes mathématiquement va commencer à montrer son potentiel, à savoir lorsque nous sommes en mesure d'utiliser les formules pour extraire des informations sur la forme et les utiliser pour générer d'autres formes. En d'autres termes, dans la partie qui suit, nous allons nous concentrer sur la façon de modifier ces formes que nous avons définies en utilisant des opérations mathématiques. Ces modifications sont une partie essentielle de la conception depuis tant qu'architectes nous commençons toujours par une forme de base qui se fait adaptée au long du processus de conception pour des raisons différentes esthétiques et pratiques. Ces opérations mathématiques que nous allons utiliser pour modifier les formes sont classés en trois types: les opérations algébriques, analytiques et algorithmiques. Cette catégorisation est très clair, à savoir que dans les opérations algébriques nous allons utiliser des applications linéaire, affine et projectives, ce qui signifie que les géométries concernées ici sont des géométries affine, euclidienne et projectives. La façon dont nous allons construire les opérations algébriques: linéaire, affines et projectives, serait entre des espaces vectoriels en utilisant des matrices de transformation, ce sont des opérations familiers comme les traductions, les rotations, mise à l'échelle et la projection. Dans la partie analytique, nous allons utiliser les opérations de calcul différentiel et intégral, ce qui signifie que la géométrie de cette partie est la géométrie différentielle, nous devrions utiliser ces opérations pour calculer des informations cruciales sur la forme à savoir les dérivés, courbures, des longueurs d'arc, les zones et volumes, etc. Ensuite, utilisez ces informations pour générer des variantes de la forme de champs de vecteurs, par exemple les surfaces minimales, trouver géodésiques sur la surface, sont tous des outils de conception utiles et intéressants. Enfin dans la partie algorithmique, nous utiliserons des algorithmes et traitions des éléments géométriques discrets qui signifie que les géométries concernées ici sont des géométries computationnelle et combinatoires. Dans cette dernière famille d'opérations; différentes méthodes numériques computationnelle vont être utilisés, par exemple des algorithmes d'optimisation et des algorithmes de recherche (comme la méthode de Monte Carlo) et des formes générées de manière itérative, modèle computationnelle. Maintenant que nous avons une idée générale des trois types d'opérations différentes, nous allons commencer par le premier type: les opérations algébriques. Les opérations algébriques sont les bases sur lesquelles tout repose, il y a beaucoup de notions que nous connaissons intuitivement dans l'architecture comme un espace tridimensionnel euclidien, la distance, la projection et beaucoup d'autres, mais nous ne connaissons pas leur formulation mathématique. Dans cette recherche comme mentionné plus tôt, nous essayons de combler l'écart entre l'abstrait et l'intuitive, de sorte qu'une approche mathématique approprié pour la conception peut fonctionner. Nous commençons par expliquer le monde où nous faisons toutes ces formes à savoir l'espace euclidien à trois dimensions, il est aussi l'espace dans lequel nos variétés sont soit immergées ou submergées et où nous allons appliquer nos opérations. Il est tout d'abord un !-espace vecteuriel normé avec une norme appelée la norme euclidienne. Afin de bien définir un espace euclidien nous avons besoin de quelques autres notions qui nous aideront à comprendre sa construction mathématique, le premier de ces serait la notion fondamentale d'un groupe et comment nous pouvons aller de groupe à l'autre en utilisant des applications linéaires (morphismes). | 109Groupe et morphisme de groupe [1] est une structure algébrique constituée d ' un ensemble non vide G, muni d ' une loi interne associative ù , admettant un élément neutre, et tel que tout x œ G , x possède un inverse si x ù y = yù x ï G est appelé un groupe abélien ou commutatif Nous disons que G est un groupe si etseulementsi ù associative : " a, x, y œ G, H aù xLù y = aùHxù yL $ e est l' élément neutre : " a œ G, eùa = aùe = a $ a' est l' inverse de a : " a œ G , aùa' = a'ùa = e H Õ G est un sous - groupe de G si " x, y œ H , x'ù y œ H ZHGL = 8z œ G " g œ H, zùg = gù z< est le centre du groupe G H1, H2 Õ G sous groupes conjugués de G si " h1 œ H1, $ g œ G et h2 œ H2 h1 = g -1 h2 g HG, ùL et HG', *L , deux groupes et f : GöG' , f est un homomorphisme ó " x, y œ G f Hxù yL = f HxL* f HyL f est un isomorphisme si bijective et f est un endomorphisme si HG, ùL = HG', *L Action de groupe [1] G un groupe, X un ensemble alorsl' action de G sur X est donnée par Gä Xö X, Hg, xL Ø g.x vérifiant que " g1, g2 œ G , " x œ X , g1. Hg2.xL = Hg1 g2L.x et 1G.x = x Hoù 1G = élément neutre de GL si " x, y œ X, $ g œ G y = g.x l' action est transitive si " x œ X, g.x = x ó g = 1G l' action est libre x, y œ X, ~ est une relation d ' équivalence si etseulementsi il est réflexive : x ~ x , symétrique : x ~ y ïy ~ x et transitive : x ~ y et y ~ z ï x ~ z X êG est l' ensemble quotient de la relation d ' équivalence y ~ x si y = g.x p : Xö X êG , x # x est la projection canonique x = G.x = 8y œ X y = g.x , " g œ G < = 8y œ X y ~ x< L'espace vectoriel Après avoir défini le groupe, nous pouvons passer à la définition de l'espace vectoriel sur un corps de scalaires, le corps de scalaires est tout simplement l'ensemble où les coordonnées d'un vecteur viennent. Tout vecteur est un tuple de cette forme Hv1, ..., vnL où les vi pour i=1,..,n sont des nombres réels (mais ils peuvent aussi être des nombres complexes ou des éléments de n'importe quel corps). Nous verrons ci-dessous que un espace vectoriel est un ensemble E d'éléments appelés vecteurs (c. coordonnées des points) avec une loi interne de l' addition de vecteurs et une loi externe de la multiplication par les scalaires (éléments du corps #) où l'ensemble E muni de la loi d'addition est un groupe abélien. Cela semble un peu abstrait, mais il est assez intuitive, par exemple, lorsque nous additionnons deux vecteurs (points) dans l'espace euclidien nous obtenons encore un vecteur dans le même espace euclidien et si l'on divise ce résultat par deux on obtient le point milieu entre ces deux points initiales. Représentation d'un espace vectoriel de dimension trois 110 | Espace vectoriel [2] # un corps de scalairesH# = ! ou $L E un ensemble dont les éléments sont appelés vecteurs, E a deux lois une loi interne « + » : E 2 Ø E, appelée loi d ' addition ou somme vectorielle, HE, +L est un groupe abélien une loi extérieure à la gauche « • » : #µE Ø E, appelé multiplication par un scalaire " u, v œ E, et " l, m œ # u + v = v + u et u + Hv + wL = Hu + vL + w, Hi.e. commutative et associative L $ 0E élément neutre 0E + v = v " u œ E a opposé un, noté - u u + H-uL = 0E l •Hu + vL = Hl • uL + Hl •vL, Hi.e. distributive sur la gauche par rapport à la loi « + » de EL Hl + µL • u = Hl • uL + Hµ • uL, Hi.e. distributive sur la droite par rapport à l' addition du corps #L HlmL • u = l • Hµ • uL , Hi.e. associatives sur la droite par rapport à la multiplication dans #L 1 • u = u , Hi.e. l' élément neutre multiplicatif du corps #, noté 1 est neutre sur la gauche pour la loi externe « • »L l • 0E = 0E, Hi.e. 0E est absorbant à droite pour la loi « • » L 0# • u = 0E, Hi.e. le produit de tout vecteur de E par un scalaireL -1 • u = -u, Hi.e. -v Hl' opposé de vL est le produit de v par le scalaire - 1L Base de l'espace vectoriel [2] e = He1, ..., enL une famille de vecteurs linéairement indépendants " Hl1, ..., lnL œ !n , ⁄i=1 n li ei = 0 ï " i œ 81, ..., n<, li = 0 " x œ E , $ Hl1, ..., lnL x = ⁄i=1 n li ei ï e = He1, ..., enL une base de E Il est tout à fait naturel après avoir défini l'espace vectoriel; de définir le sous-espace vectoriel, par exemple un sous-espace vectoriel de l'espace euclidien à trois dimensions, est le plan euclidien qui contient les vecteurs qui ont coordonnée z nulle. Sous-espace vectoriel [2] F Õ E , F " « stable pour l' addition vectorielle et la multiplication par un scalaire Hcombinaison linéaireL " u, v œ F et " l, m œ # l u + m v œ F ce sous ensemble F contient l' opposé de chacun de ses vecteurs " u œ F $ v œ F u + v = 0E Hi.e. v = -uL F est le sous - groupe de HE, +L F1 et F2 sont des sous - espaces de E sont en somme directe F1$F2 ó F1 › F2 = 80E< F1 et F2 sont des sous - espaces de E sont complémentaires ó F1$F2 = E F1, ... Fn sont des sous - espaces de E, alors ⁄i=1 n Fi = 8x œ E $ Hx1, ..., xnL œ F1 ä ...äFn , x = x1 + .. + xn< | 111La norme Venons-en maintenant à la définition de la norme euclidienne qui conduit à la définition de l'espace euclidien. Pour ce faire, nous définissons de quelques notions importantes à savoir la forme bilinéaire symétrique et sa forme quadratique et la signature de cette forme quadratique. Norme euclidienne [3] °.¥ : Eö!+ , °.¥ norme euclidienne sur E qui vérifie, " x œ E séparabilité : °x¥ = 0 óx = 0E vecteur nul positivité : " l œ #, °l x¥ = †x§ ° x¥ inégalité triangulaire : ° x + y¥ b °x¥ + °y¥ °x¥p = H⁄i=1 n †xi § p L 1 p , x œ E = H!n , °.¥ L Forme bilinéaire symétrique [3] E est un ! - espace vectoriel, j : E 2ö! est une forme bilinéaire symétrique si " l, m œ ! and " x, y, u, v œ E jHl x + m u, yL = l jHx, yL + m jHu, yL and jHx, l y + m vL = l jHx, yL + m jHx, vL Forme quadratique [3] E est un ! - espace vectoriel, dim E = n , j est une forme bilinéaire symétrique et q : E ö! quadratic form qHxL = jHx, xL and qHxL = ⁄i=1 n aii xi 2 + ⁄1bi< jbn aij xi x j jHx, yL = 1 2 @qHx + yL - qHxL - qHyLD, jHx, yL = ⁄i=1 n aii xi yi + 1 2 ‚ 1bi< jbn aij Ixi y j + x j yi M aprèsla réduction de Gauss et de la signature $ n formes linéairement indépendantes : v1, ..., vn q = ai @viD 2 , ai œ 81, 0, -1< , SignHqL = 8# 8i : ai = 1<, # 8i : ai = -1<< q est définie positive si sa signature est Hn, 0L = Hdim E, 0L , à savoir " x œ E , qHxL = jHx, xL > 0 Enfin, nous définissons le produit scalaire qui est l'ingrédient principal pour fabriquer l'espace euclidien. Il s'agit essentiellement de la règle selon laquelle on mesure la distance entre deux points x, y dans l'espace. En d'autres termes la longueur de leur vecteur x y Ø = v = y - x which is Xv, v\ Produit scalaire [3] est une forme bilinéaire symétrique définie positive, °.¥ la norme associée " x œ E , °x¥ = Xx, x\ , " x, y œ E , °x + y¥ 2 = °x¥ 2 + 2 Xx, y\ + °y¥ 2 inégalité triangulaire : °x + y¥ § °x¥ + °y¥ inégalité de Cauchy Schwarz : †Xx, y\§ § °x¥ °y¥ " x, y œ E , q angle entre x, y où q œ P0, pT, cosq = Xx,y\ °x¥ °y¥ ó -1 § Xx,y\ °x¥ °y¥ § 1 Maintenant, avec les définitions précédentes, nous sommes en mesure de définir l'espace euclidien comme suit Espace euclidien [3] est un ! - espace vectoriel muni d ' un produit scalaire, dim E = n 112 | L'espace euclidien L'espace euclidien de dimension trois est un !-espace vectoriel muni d'un produit scalaire, dim E = 3 avec la base canonique (e1, e2, e3) comme sa base où e1 est le vecteur colonne (1,0,0), e2 est le vecteur colonne (0,1,0) et e3 est le vecteur colonne (0,1,0). Maintenant que nous avons défini l'espace euclidien !3 nous pouvons commencer par définir la transformation qui nous permettra de générer de nouvelles formes à partir des initiales, nous allons nous concentrer principalement sur les transformations linéaires, affines et projectives, nous devons aussi voir les définitions de formes dans la base canonique. On a vu à cette définition du cylindre cHu, vL = Ha CosHuL, b SinHuL, c vL, cette définition peut aussi s'écrire plus explicitement comme une combinaison linéaire des vecteurs de base canoniques (e1, e2, e3), à savoir dans cette forme cHu, vL= Ha CosHuLL e1 + Hb SinHuLL e2+ Hc vL e3. Dans cette forme, nous pouvons voir clairement que l'application cHu, vL est rien d'autre qu'une application à valeurs dans !3 , ce qui signifie que l'évaluation de cHu, vL Hu,vL va donner un vecteur qui est une combinaison linéaire de (e1, e2, e3). Cela signifie que pour le même équation écrite dans une autre base va donner une version déformée du cylindre. Définition de la forme dans une base de l'espace euclidien !3 (e1, e2, e3) est la base canonique, e1 = 1 0 0 , e2 = 0 1 0 , e3 = 0 0 1 cHu, vL = H1, 1, 0L + 1 2 CosHuL e1 + 1 2 SinHuL e2 + v 4 e3 Maintenant, si nous prenons la même équation et l'écrire est une autre base de l'espace euclidien !3 (b1, b2, b3) où il n'est pas une base orthonormée, nous pouvons voir dans la figure ci-dessous la déformation de la forme (cylindre). Cependant, dans cette recherche, nous considérerons toujours la base canonique la base de notre espace euclidien !3 (b1, b2, b3) est la base canonique, b1 = 1 1 2 0 , b2 = 0 1 0 , b3 = 1 5 1 5 1 cHu, vL = cHu, vL = H1, 1, 0L + 1 2 CosHuL b1 + 1 2 SinHuL b2 + v 4 b3 Représentation d'un cylindre dans la base canonique et d'une base non orthonormé de l'espace euclidien !3 | 113Applications entre espaces vectoriels Premièrement, nous allons considérer la transformation linéaire à savoir de transformation qui sont produites en multipliant le vecteur par une matrice nommée matrice de transformation. La translation n'est pas une transformation linéaire mais une transformation affine dont la partie linéaire est la matrice d'identité. Nous allons montrer plus en détail comment les transformations affines fonctionnent et comment elles sont utiles dans la conception architecturale, en fait, toute transformation affine est un produit semi-direct de traduction et une transformation linéaire. Alors d'abord, nous définissons une application linéaire, à savoir une application qui prend des vecteurs comme ses variables et c'est la façon dont nous nous déplaçons entre différents espaces vectoriels ou dans le même espace vectoriel. Dans cette recherche, nous allons nous concentrer principalement sur les applications linéaires qui envoie un espace vectoriel dans lui-même à savoir endomorphismes c'est parce que la plupart de nos objets sont définis dans !3 et les images de leurs transformations sont également dans !3 . Application linéaire (homomorphisme de !-espaces vectoriels) [3] E, F sont des # - espaces vectoriels, f est une application f : E öF telle que " l, m œ # et " x, y œ E f Hl x + m yL = l f H xL + m f HyL, f est additif et homogène si f est bijective ï f est un isomorphisme, si E = F ï f est un endomorphisme, si f is bijective et E = F ï f est un automorphisme LHE, FL est l' espace vectoriel des applications linéaires de E à F, IsomHE, FL est l' ensemble des isomorphismes de E à F LHEL est l' espace vectoriel des endomorphismes de E, G LHEL est le groupe des automorphismes de E les applications linéaires peuvent être représentés dans une base donnée par une matrice Théorème du rang [3] KerH f L = 8x œ E f HxL = 0< = f -1 H80 0 et A renverse l' orientation si detHAL < 0 Orthogonal endomorphism [3] u est un endomorphisme orthogonal HA est une transformation orthogonaleLsi " x, y œ !n , °uHxL¥2 = °A x¥ 2 = °x¥ 2 = t x x = Xx, x\ XuHxL, uHyL\ = XA x, A y\ = t x tA A y = t x y = Xx, y\ une rotation de !n est une transformation orthogonale qui préserve l' orientation 114 | L'espace affine Une autre notion importante est l'espace affine. Par exemple, si nous voulons faire pivoter un objet en réalité, nous le faisons en choisissant une origine et un axe autour duquel il sera tourné. Ce choix de l'origine peut être considérée comme une translation ou d'un déplacement de l'espace vectoriel à partir de l'origine canonique à la nouvelle origine, cette copie déplacé est un espace affine. Espace affine [5] E est ensemble non vide, muni d ' un action de groupe libre et transitif de l' espace vectorielKE Ø , +Osur E KE Ø , +OäEö E , Jv Ø , pN Ø v Ø .p = p + v Ø vérifiant que " p, q œ E , $ v Ø œ E Ø q = p + v Ø Ji.e. v Ø = p qN and if p + v Ø = p ï v Ø = 0 E Ø , or dim E = dim E Ø Sous-espace affine [5] Soit O œ E , " F Õ E, F = O + F Ø est le sous - espace affine avec un sous - espace vectoriel directeur F Ø Õ E Ø Coordonnées barycentriques et cartésiennes [5] S = 8p0, p1, .., pk< Õ Eï F = XS\ est le plus petit sous - espace affine contenant S les pi sont affinement inpedendantsi " i , les vecteurs :pi pj , j = 0, ..., k and i " j> sont linéairement indépendants ï dim XS\ = k et " p œ XS\, $ ! Hl0, ..., lkL œ # k+1 , ⁄i=0 k li = 1 et " o œ E, o p = ⁄i=0 k li o pi Hl0, ..., lkLsont les coordonnées barycentriques par rapport à S, et nous pouvons écrire : p = l0 p0 + ... + lk pk soit p0 = o ï o p = l1 o p1 + ... + lk o pk Hl1, ..., lkLsont les coordonnées cartésiennes de p par rapport à l' origine o et la base et :o p1 , ..., o pk > de F Ø Vectorialization de l'espace affine E à l'espace vectoriel !n Hnon - canoniqueL [5] E espace affine, E Ø son espace vectoriel directeur avec Je1 Ø , .., en Ø N comme sa base canonique soit o œ E sera appelé l' origine, qo : EöE Ø , qoHpL = o p est une bijection avec qo -1 H u öL = o + u ö ï nous pouvons ajouter à E une structure d ' un espace vectoriel Eo appelé le vectorialization de E en o par lesformules p + q = r o p + o q = o r , l.p = l o p etson élément neutre 0Eo = o f : !nö E, f Hl1, ..., lnL = P = o + l1 e1 Ø + ... +ln en Ø est un isomorphisme de !n à Eo ï Hl1, ..., lnLsont les coordonnées cartésiennes of p relative to the origin o and the canonical base L'extension vectorielle de l'espace affine (canonique) [5] E espace affine, E Ø son espace vectoriel directeur E ` est l' extension vectorielle de E E hyperplan affine, E Ø hyperplan vectoriel E ` = E Ø ‹ 8l x x œ E, l œ # * < avec 1 x = x h : E ` ö # est une forme linéaire hHv ` L = 0 si v ` œ E Ø et hHv ` L = l si v ` = l x E Ø = ker h et E = h -1 H1L | 115ü 5.2. Symétrie et géométrie L'intérêt dans les opérations algébriques a été intrinsèque dans la conception architecturale à travers toute son histoire, cela est dû à l'importance de la notion de symétrie dans l'architecture. Depuis la conception architecturale est largement basée sur la composition, elle repose sur la symétrie dans de nombreuses façons pour générer des formes et des motifs, de la conception des plans d'étage aux façades et toitures. En effet, les opérations algébriques comme la translation, l'homothétie et la rotation ont formé la palette générale de transformation dans la conception architecturale pour la plupart de son histoire. Que très tard, que les architectes ont commencé à avoir un intérêt dans d'autres types de transformation, à savoir infinitésimal au lieu de algébrique. Jusqu'au milieu du XXe siècle, les transformations d'éléments architecturaux en rapport à une surface de base (par exemple des ouvertures sur la façade) ont été confinés à des surfaces planes. Mais, avec l'intérêt croissant pour les surfaces courbes un autre type de transformation sera définie, à savoir celle qui utilise un champ de vecteurs comme une direction variable au lieu d'un seul vecteur. Ce type de transformation est considéré dans la section des opérations d'analyse de cette recherche où les notions de champs de vecteurs et courbes intégrales sont considérés. Représentation d'un plan d'étage de basilique romaine Nous allons maintenant définir la symétrie du point de vue de la théorie des groupes, à savoir la définition du groupe de symétrie d'un objet. Le groupe de symétrie d'un objet est le groupe de toutes les isométries sous lequel l'objet est invariant, avec la composition comme la loi du groupe, c'est un sous groupe du groupe d'isométrie de l'espace concerné. Le principal groupe de symétrie sur lequel nous allons nous concentrer dans cette recherche est le groupe de symétrie de l'espace euclidien connu comme le groupe euclidien qui est un sous groupe du groupe affine. Le groupe de symétrie est parfois appelé le groupe de symétrie complète afin de souligner ce qu'il comprend les isométries qui renversent l'orientation (comme la réflexion), sous lequel la forme est invariante. Le sous groupe des isométries qui préservent l'orientation (comme translations et rotations) qui laisse l''objet invariant est appelé le groupe de symétrie propre. Tout groupe de symétrie dont les éléments ont un point fixe commun, ce qui est vrai pour tous les groupes de symétrie finis et les groupes de symétrie des figures bornées sont représentés comme un sous groupe du groupe orthogonal en choisissant l'origine pour être le point fixe. Le groupe de symétrie propre est un sous groupe du groupe spécial orthogonal aussi connu comme le groupe de rotation. Les groupes de symétrie peuvent être soit des groupes de symétrie discrètes ou continues. Le groupe de symétrie discrète vient dans trois types: les groupes de ponctuels finis, y compris seulement des réflexions, des rotations, des inversions et roto-inversions, les groupes de réseau infini, y compris que des translations et le groupe d'espace infini qui combine des éléments des deux types. Le groupe de symétrie continue, qui contient de rotation d'angles arbitrairement petits et de translations de distances arbitrairement petites, ces groupes de symétrie sont étudiés comme des groupes de Lie. Deux figures géométriques sont considérées comme étant du même type de symétrie si leurs groupes de symétrie sont des sous groupes conjugués du groupe euclidien. Groupe de symétrie [6] X est un ensemble, G est un groupe et Gä XöX , Hg, xLög.x est une action de groupe de G sur X g.x = y ïy estsymétrique à x S = 8g œ G g.x = x < Õ G est le groupe de symétrie des objets dans X 116 | Les groupes de symétrie d'une forme Afin de clarifier cette notion de symétrie, nous allons donner un tableau des différents types de groupes de symétrie principalement celles de l'espace affine, l'espace euclidien et l'espace projectif (i.e. les groupes de transformations affines, euclidien et projectives) et leurs géométries respectives. En plus des transformations topologiques continus qui ne conserve que des notions topologiques (comme l'ouverture, la fermeture, la compacité, la connexité, etc) qui est liée plus à la géométrie différentielle. L'idée générale est illustrée dans l'image ci-dessous, qui montre toutes les façons dont un carré peut être transformée. La transformation dans la rangée 1 est la dispersion, la seule propriété qui est préservée dans ce cas est que chaque point correspond à un point. La transformation de la ligne 1 est: dispersion, la seule propriété qui est préservée dans ce cas est que chaque point correspond à un point. La transformation dans la rangée 2 est continue et de préserver également la séquence de points résultant en une figure topologiquement fermé. Sous la transformation de perspective dans la rangée 3, la propriété: ligne droite, est également conservé. La transformation affine, dans la rangée 4 conserve tout ce qui a précédé et aussi le parallélisme, d'ailleurs quand le vrai angle est conservé, la forme peut encore être transformé par mettre à l'échelle, les formes restent les mêmes comme dans la rangée 5. Enfin à la ligne 6, la taille réelle est également conservée, ce qui signifie que la forme conserve toutes ses propriétés, mais peut encore être transformé par la translation et deux opérations de symétrie: réflexion et de rotation. Les deux niveaux inférieurs sont liés à la géométrie métrique descendu de l'antiquité grecque, le troisième niveau concerne la géométrie affine, le quatrième niveau de la géométrie projective, et le cinquième niveau de la topologie. En géométrie métrique (euclidienne), le carré est toujours représenté par un carré dans le sens habituel, alors que dans la géométrie affine tout parallélogramme y compris le carré métrique représente un carré; qui illustre le fait que la géométrie (euclidienne) métrique est comprise par la géométrie affine: la dernière est plus grand, plus riche et plus abstrait, et dans ce sens plus complexe que la précédente. La géométrie Affine est à son tour comprise par la géométrie projective, où tout quadrilatère peut représenter un carré donc un nouveau niveau de complexité est atteint, et par cette logique, un niveau encore plus élevé de complexité est atteint avec la topologie, depuis le carré peut maintenant être représentée par toute forme fermée. Cela nous donne une idée intuitive du programme d'Erlangen de Félix Klein où chaque géométrie est considérée comme un cas particulier de son prédécesseur plus abstrait; du début intuitive nous allons maintenant formaliser ces notions en donnant leur description mathématique en utilisant le langage de la théorie des groupes. Représentation des groupes de symétrie d'une forme carrée | 117ü 5.3. La géométrie euclidienne vs l'arithmétique pythagoricienne en architecture Avec les définitions formelles des différentes géométries comme les différents groupes de symétrie, nous voudrions donner une certaine attention à la plus pertinente de ces groupes à l'architecture à savoir le groupe euclidien et sa géométrie: la géométrie euclidienne. Sa présence en architecture a été et est toujours le plus important de tous les autres géométries, mais il est moins connu que la géométrie euclidienne n'était pas la seule présence des mathématiques en architecture, il a eu le système arithmétique pythagoricienne de proportions comme son principal rival. En montrant ce bref historique, nous allons compter sur un article publié dans Nexus Journal en 2001 par le professeur Michele Sbacchi de l'université de Palerme intitulé: Euclidism et la théorie de l'architecture [7]. La géométrie euclidienne est l'une des branches fondamentales de géométrie, elle est restée presque inchangée, nous l'utilisons encore aujourd'hui comme elle a été codifié par Euclide d'Alexandrie en treize livres appelé les éléments. Ce livre très influent traité géométrie planaire et contient les définitions de base des éléments géométriques tels que les célèbres point, ligne et surface, un point, c'est ce qui n'a pas de part, une ligne a une longueur sans largeur et une surface est celle qui a longueur et la largeur. En plus de toute une série de propositions où les caractéristiques des figures géométriques plus complexes sont définis. Euclide fournit également des procédures pour générer des formes et des solides planes et à résoudre des problèmes géométriques. Il est assez impressionnant que jusqu'au 17ème siècle, la géométrie euclidienne a été tout simplement la géométrie tout court, car ce n'est qu'à partir de la seconde moitié de ce siècle que d'autres branches de géométrie ont été développés, notamment la géométrie analytique et projective et beaucoup tard la topologie. Ces disciplines plutôt que de contester la validité de la géométrie euclidienne, elles ont ouvert des compréhensions complémentaires; confirmant ainsi l'efficacité de la géométrie euclidienne, mais certains sujets euclidiennes subi des attaques violentes et encouragés d'immenses débats, par exemple le 5ème postulat (le postulat des parallèles). Euclide n'était guère un génie isolé; historiens ont précisé qu'il a attiré d'autres sources essentiellement Theatetus et Eudoxs, donc plutôt que d'inventer il a surtout systématisé un corpus de connaissances qui ont circulé autour de savants dans des formes un peu rugueuses. Les éléments, représentait un grand pas en avant en particulier par rapport à la façon fragmentaire dans lequel la géométrie a été connu et transmis, il est vite devenu un livre extrêmement utile pour tous les domaines où la géométrie a été appliquée. Optique, mensuration, l'arpentage, la navigation, l'astronomie et l'architecture, tous bénéficié en diverses manières de ce nouvel ensemble complet de règles capables de surmonter les problèmes géométriques. Suite au destin de la plupart des textes scientifiques grecs, il fut bientôt traduit en arabe et a été connu à travers cette langue pendant près de quinze siècles, une traduction latine bien connue a été faite par Adelard de Bath dans le 12ème siècle mais c'était traduction en latin de Campano de 1482, le premier à être publié. La première traduction anglaise est due à Henry Billingsley en 1570. Non moins important sont les commentaires sur les éléments, si ce n'est que parce qu'ils ont été témoins des débats continus que les érudits ont eu sur le texte. L'architecture, la discipline concernée avec la fabrication de formes, peut-être le plus profité de cette connaissance, il est tout à fait évident, la relation entre l'architecture et la géométrie euclidienne; de Vitruve et jusqu'à l'architecture moderne. Il est vrai que d'autres branches de géométrie qui ont résulté de la 17ème siècle, ont affecté l'architecture comme la géométrie projective et la topologie mais cela reste loin d'être comparable à l'utilisation écrasante de la géométrie euclidienne dans la conception architecturale à travers l'histoire. La pertinence des méthodes euclidiennes pour la réalisation de l'architecture a été soulignée par de nombreux spécialistes, et parmi les maçons et les charpentiers les procédures euclidiennes étaient répandues beaucoup plus qu'on ne le pensait jusqu'ici. Nous pouvons croire que pendant le moyen âge, pour faire de l'architecture, la lignes euclidiennes, facilement établis et visualisées, étaient le plus souvent une bonne alternative à des calculs numérologiques plus complexes. Par conséquent, nous pouvons supposer qu'une culture euclidienne associée à l'architecture existait depuis longtemps et qu'il a été prééminente parmi les masses et les travailleurs, mais parmi les cercles raffinés de clients et des architectes la tradition assez différente de Vitruve était également en vigueur. Cette tradition a été fondée sur l'idée platonique de Pythagore que les proportions et les rapports numériques réglementés l'harmonie du monde, toute la théorie, dont le domaine est bien sûr beaucoup plus large que la simple application d'architecture a été construit autour de la notion de proportion, comme Platon compris dans le Timée. Il a été fondé sur l'analogie entre les rapports musicaux et visuels établis par Pythagore: il a soutenu que des rapports numériques existaient entre les hauteurs de sons, obtenus avec une certaine musique et l'architecture. En architecture, les numéros utilisés à des fins différentes: la détermination des proportions globales dans les bâtiments et la construction modulaire des ordres architec- 118 | avec une certaine musique et l'architecture. En architecture, les numéros utilisés à des fins différentes: la détermination des proportions globales dans les bâtiments et la construction modulaire des ordres architecturaux, le premier considéré les dimensions réciproques de l'hauteur, la largeur et la longueur dans les chambres ainsi que dans le bâtiment dans son ensemble. Le second était un module mis en place généralement à partir de la moitié du diamètre de la colonne à partir de laquelle toutes les dimensions des ordres pourraient être dérivés. L'ordre déterminé le système numérique à adopter, et donc chaque élément de l'ordre architectural a été déterminée par un rapport au module. En effet, il était possible d'exprimer l'architecture par un algorithme, simplement en mentionnant le style une formule numérique a été impliqué et les dimensions de l'ordre pourrait être construit. Si l'on compare maintenant à nouveau ces procédures avec celles euclidiennes, il semble que la différence entre les deux systèmes est significative. Selon Vitruve, multiplications et divisions de nombres réglementées les formes et dimensions architecturales, mais en adoptant des constructions euclidiennes, l'architecture et ses éléments ont été faite de lignes à l'aide d'un compas et une règle. La théorie pythagoricienne des nombres et la géométrie euclidienne des lignes établies ainsi une polarité au sein de la théorie de l'architecture, la dichotomie était une plus générale, étant donné que chaque forme peut être déterminée soit par le traçage d'une ligne ou par calcul numérique. Pendant le moyen âge, la procédure euclidienne et la procédure de Vitruve empiriquement coexistaient dans la pratique de la construction, pendant la Renaissance l'avènement d'une théorie de l'architecture établi basé sur le texte de Vitruve, promus l'aspect de la numérologie néo-pythagoricienne de l'architecture. Leon Battista Alberti, le plus important théoricien de l'architecture de la Renaissance, était bien conscient de la géométrie euclidienne mais il était dans la tradition orthodoxe de Pythagore-Vitruve de rapports numériques. Pour Alberti, le nombre était encore la source la plus fondamentale. Il n'était pas jusqu'à ce que Francesco di Giorgio Martini que les définitions euclidiennes de point, ligne et surface ont fait leur première apparition dans un traité d'architecture, mais plutôt d'une manière non systématique. Serlio va ensuite plus loin, y compris dans son livre des définitions et des constructions euclidiennes, principalement comme motif pour la perspective que pour l'architecture. Dans le 17ème siècle, la situation subirait un changement important; avec le travail de Guarino Guarini, la géométrie euclidienne fait son apparition ouvert dans un traité. Cela est dû à plusieurs raisons, d'abord il était un mathématicien qui lui a fait obligés de considérer la géométrie euclidienne, et il a enseigné les mathématiques à Messine, où des érudits Cela est dû à plusieurs raisons, d'abord il était un mathématicien qui lui a fait obligés de considérer la géométrie euclidienne, et il a enseigné les mathématiques à Messine, où des érudits euclidiennes distingués enseignaient. Pourtant, il est probable que son intérêt pour la géométrie euclidienne élargi, car il y rencontra un milieu scientifique animé et en particulier le mathématicien François Millet de Chales, qui l'a influencé profondément. Guarini dans son traité Architecttura Civile déclare ses intérêts géométriques en disant que, depuis l'architecture en tant que discipline utilise des mesures dans chacune de ses activités, elle dépend de la géométrie, et au moins veut savoir ses éléments primaires, et donc il s'est mis ces principes géométriques qui sont les plus nécessaires. Le traité contient neuf définitions de point, ligne, surface, angle, angle droit, angle aigu et des lignes parallèles; avec des chapitres consacrés à des surfaces, formes rectilignes et des formes circulaires. Le tout premier traité continue essentiellement de cette manière avec les postulats, d'autres principes et plusieurs transformations euclidiennes typiques, par exemple instructions géométriques comme la façon de tracer une ligne d'un point afin de toucher le cercle. Le cinquième traité porte sur la discipline euclidienne de géodésie: la manière de diviser et de transformer des formes planes en équivalents, certains d'entre eux sont peu développées dans la lumière de leur application architecturale. La position de Guarini est clairement géométrique, par opposition à la tradition arithmétique de Vitruve; dans Architecttura Civile le cœur de la numérologie de Vitruve est éclipsé par l'approche géométrique alternative. Remarquablement la procédure modulaire, enracinée en nombres, est remplacé par un système mixte où la dimension des éléments architecturaux sont déterminés par des constructions géométriques et seulement dans certains cas, par des opérations numériques. Guarini n'était pas le seul à faire revivre cette culture euclidienne dans la théorie architecturale, le traité de l'architecte milanais Carlo Osio également intitulé Architecttura Civile, présente un système pour les ordres qui est, encore plus géométrique que celui de Guarini. Avec Guarini et Osio la tradition euclidienne est consciemment reconnu dans le domaine de la théorie savant et non plus appartenu à une culture orale et empirique; avec la particularité des leurs traités où les géomètres Euclide et Chales sont préconisés comme autorités architectural, même dans les pièces les plus typiquement architecturales. En Architecttura Civile les éléments de géométrie assez souvent deviennent simplement les éléments de l'architecture, par exemple un mur est une surface et un dôme est une demi-sphère, par conséquent, la conception architecturale semble le plus souvent être identifiées avec le dessin architectural. Comme un véritable | 119ture, par exemple un mur est une surface et un dôme est une demi-sphère, par conséquent, la conception architecturale semble le plus souvent être identifiées avec le dessin architectural. Comme un véritable géomètre Guarini décrit la production du projet plutôt que la production du bâtiment, sans tenir compte de l'aspect constructif de l'architecture en faveur des descriptions détaillées techniques de dessin, à cet égard, il est assez curieux que des outils de dessin sont en fait regroupés sous le titre : instruments architectural. Le problème pour lui n'était pas la façon de construire mais comment dessiner, donc la géométrie euclidienne est devenu une partie de la théorie architecturale, mais elle a aussi entraîné avec lui son essence linéaire. Nous tenons également à mentionner que la raison pour laquelle la géométrie euclidienne était capable de passer de la reconnaissance timide de Martini et Serlio à la grande inclusion de Guarini dans l'architecture est due aux travaux de savants tels que Francesco Barozzi. 120 | ü 5.4. Géométrie affine et euclidienne ü 5.4.1. Définition du groupe Nous allons maintenant donner une catégorisation générale de ces opérations de transformations affines à savoir les éléments du groupe affine qui est une extension du groupe linéaire. Un important sous-groupe du groupe affine est le groupe euclidien aussi connu comme le groupe de symétrie de l'espace euclidien (ie le groupe des isométries de l'espace euclidien); ce groupe de symétrie est cruciale pour la conception architecturale et l'utilisation historique en architecture est tout à fait évidente. De ce point de vue (Programme d'Erlangen de Félix Klein), nous lisons la géométrie euclidienne, la géométrie du groupe de symétries euclidien comme une spécialisation de la géométrie affine. Tous les théorèmes affines s'appliquent avec le facteur supplémentaire de la distance euclidienne, dont l'angle peut être déduite. Nous commençons par définir les groupes linéaires et affines, puis nous allons définir la notion de symétrie qui nous permettra de définir le groupe de symétrie de l'espace euclidien. Représentation d'une transformation affine dans !2 d'un triangle à l'autre Groupes linéaire et affine [5] GLKE Ø O = : f Ø : E Øö E Ø bijection> est le groupe linéaire Ksi E Ø = # nï GLKE Ø O = GLnH#L O GLnH#L = 8A œ Mn H#L A est inversible Hi.e. det A " 0L< SLnH#L = 8A œ GLn H#L det A = 1< est le groupe spécial linéaire GA HEL = 8 f : Eö E bijection< est le groupe affine p : GA HELöGL KE Ø O, pH f L = f Ø est la projection canonique T HEL = Ker p = : f œ GA HEL f Ø = id E Ø> est le groupe de translation, THELsous groupe de GA HEL le groupe quotient GA HEL êTHEL est isomorphe à GLKE Ø O le groupe de translation THEL est isomorphe à KE Ø , +O Hi.e. l' espace vectorielL GA HEL = KE Ø , +O äGLKE Ø O produitsemi directe Hi.e. f œ GA HEL , f peut être considéré comme un produitsemi direct d ' un vecteur de translation et une application linéaireL | 121Le groupe euclidien Comme nous avons défini le groupe affine comme le produit semi direct du groupe de translation et le groupe linéaire général, nous allons maintenant définir le groupe euclidien comme le produit direct de semi du groupe de translation et le groupe orthogonal. Le groupe orthogonal de la forme bilinéaire symétrique ou une forme quadratique sur un espace vectoriel est le groupement d'opérateurs linéaires inversibles sur l'espace qui permettent de préserver la forme. Dans cette recherche, nous allons seulement se concentrer sur le produit scalaire sur l'espace euclidien comme notre forme bilinéaire alors le groupe orthogonal correspondant est un ensemble de n matrices carrés orthogonales. Représentation de transformation euclidienne !2 Groupe orthogonal [4] j : !n ä!nö! est une forme bilinéaire symétrique et q : !n ö! forme quadratique où j = X , \ est un produit scalaire He1, ..., enL est une base orthonormée de !n Hpar choix ou par le processus de Graham - SchmidtL A = Aai, jE 1§i, j§n ï " i, j œ 81, ..., n< , ai, j = jIei , e j M = 1 si i = j et jIei , e j M = 0 if i " j pour que A = Aai, jE 1§i, j§n préserve j ï jIei , e j M = jIAHeiL, AIe j MM = jI⁄k=1 n ai,k ek , ⁄l=1 n aj,l el M = ⁄k,l=1 n ai,k aj,l jHek , elL = ⁄k=1 n ai,k aj,k où H tA ALi, j = ⁄k=1 n ai,k aj,k = 1 si i = j et 0 si i " j ï t A A = In ï On H!L = 8A œ GLnH!L tA A = A tA = In< est le groupe orthogonal SOn H!L = 8A œ OnH!L det A = 1< est le groupe spécial orthogonal On H!L Õ En Hle groupe euclidienL , On H!L = En › GLnH!L Groupe euclidien [8] En Õ GA HEL où E Ø = !n ï GLKE Ø O = GLnH!L , On KE Ø O = On H!L et SOn KE Ø O = SOn H!L p : EnöGLKE Ø O, pH f L = f Ø est la projection canonique THEL = Ker p = : f œ En f Ø = id E Ø> est le groupe de translation, THELsous groupe de En le groupe quotient En êTHEL est isomorphe à OnKE Ø O le groupe quotient En + êTHEL est isomorphe à S On KE Ø O En = KE Ø , +O äOnKE Ø O produitsemi directe En = : f œ GAHEL f Ø œ OnKE Ø O> est le groupe euclidien Hle groupe de symétrieL En + = : f œ GAHEL f Ø œ S On KE Ø O> est le groupe de symétrie propre Maintenant, avec l'espace affine, le groupe affine et le groupe euclidien définis, nous pouvons définir le plan affine (et éventuellement la transformations affine). 122 | Application affine [5] E, E' espaces affines et E Ø , E Ø ' leurs espaces vectoriels directeurs E = Xo, e1, .., en\ et E' = Xo', e1 ', .., em '\ ïB = Jo e1 , ..., o en N et B' = Ko' e1 ' , ..., o' em 'O deux bases de E Ø et E Ø ' f : Eö E' est une application affine si $ o œ E et f Ø : E Øö E' Ø l' application linéaire attachée f HpL = f Jo + o p N = f HoL + f Ø Ho p L f Ø can be represented by the transformation matrix A œ Mn,mH#L ï f HpL = o' + v Ø + A x Ø , où v Ø = o' f HoL nous identifions E avec # n avec l' origine o Hi.e. Eo = # n L et E' avec # m avec l' origine o' Hi.e. Eo' ' = # mL p œ E = Eo = # n ï p = x0 o + x1 e1 + ... + xn en ï o p = x1 o e1 + ... + xn o en ï p = x Ø dans Eo = # n x Ø = Hx1, ..., xnL avec les coordonnées cartésiennes de p par rapport à l' origine o et la base :o e1 , ..., o en> de Eo = # n ï f HpL = f Jx Ø N = v Ø + A x Ø il est commode d ' écrire cette représentation de f comme f ` où p = x Ø œ E = Eo = # n est représenté par p ` = x Ø 1 œ E ` = # n+1 f ` : E ` = # n+1öE ` ' = # m+1 , f ` Hp ` L = f ` x Ø 1 = v Ø + f Ø Jx Ø N = A v Ø 0 1 x Ø 1 = A x Ø + v Ø 1 si E = E' = !3 nous avons E ` = E ` ' = !4 , Jo e1 , ..., o en N = Ko' e1 ' , ..., o' em 'O et o = o' = f HoL " p œ E ïp ` = x1 x2 x3 1 , A = a1,1 a1,2 a1,3 a2,1 a2,2 a1,3 a3,1 a3,2 a3,3 œ M3H!L est la transformation linéaire f ` : !4ö!4 , f HpL = f ` Hp ` L = a1,1 a1,2 a1,3 v1 a2,1 a2,2 a2,3 v2 a3,1 a3,2 a3,3 v3 0 0 0 1 x1 x2 x3 1 = a1,1 x1 + a1,2 x2 + a1,3 x3 + v1 a2,1 x1 + a2,2 x2 + a2,3 x3 + v2 a3,1 x1 + a3,2 x2 + a3,3 x3 + v3 1 = q1 q2 q3 1 si A est une matrice orthogonale ï f est une transformation euclidienne avec cette construction, nous sommes en mesure de transformer des formes dans l'espace euclidien !3 en ajoutant simplement 1 comme quatrième coordonnée à un point (i.e. p = x1 x2 x3 œ !3 Ø p ` = x1 x2 x3 1 œ !4 ) puis en appliquant le plan affine (représenter par une matrice augmentée de M4H!L) puis enlever enfin le 1 à nouveau du vecteur l'image (i.e. f ` Hp ` L = q1 q2 q3 1 œ !4 Ø f HpL = q1 q2 q3 œ !3 ) | 123ü 5.4.2. Transformations affines isométriques (i.e. transformation euclidienne) Symétrie de translation La première transformation affine nous construisons est la translation aussi connu comme symétrie de translation. La traduction est l'un des la transformation la plus connue et utilisée dans la conception architecturale à travers son histoire. De copier éléments dans un, deux ou trois directions (par exemple, colonnes, poutres, arcs, fenêtres, escaliers marches, etc) est la forme la plus basique et la plus simple de la composition des formes et des motifs. La translation est une symétrie isométrique savoir qu'il garde la forme non déformée après son application. La translation dans une direction a été utilisé dans l'organisation des éléments structurels par exemple colonnes, poutres, arcs et des poutres etc alors que la traduction dans deux directions a été le principal outil de conception de façade en créant un tableau à deux dimensions de fenêtres. La translation en trois dimensions peut être utilisé dans l'étude de la composition volumétrique dans la première phase de la conception. Les exemples de symétrie de translation en architecture sont très nombreux puisque l'on peut à peine imaginer l'architecture sans translation. Classique styles architecturaux ont fait usage de la traduction des colonnes et des arcs pour la conception des temples et des églises mais le style qui a poussé à sa limite traduction comme un outil esthétique serait le haut modernisme. Translation (symétrie isométrique propre) [5] E = Xo, e1, e2, e3 \ = !3 , f : Eö E, f HpL = t v ØHpL = p + v Ø est la translation, f est une isométrieó ° f HpL¥ = °p¥ E ` = !4 , f ` Hp ` L est la matrice représentant la translation dans E ` = !4 " p, v œ !4 , p ` = x1 x2 x3 1 et v ` = v1 v2 v3 1 ï f ` Hp ` L = 1 0 0 v1 0 1 0 v2 0 0 1 v3 0 0 0 1 x1 x2 x3 1 = x1 + v1 x2 + v2 x3 + v3 1 Translation d'une forme dans l'espace euclidien !3 Nous allons utiliser le cylindre comme notre forme initiale et appliquer la traduction sur elle. Depuis affine (de cartes linéaire prolongée) prend vecteurs comme des variables, nous définissons notre forme comme un ensemble de vecteurs qui sont l'image de l'application paramétrique. ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit v Ø = t H2, 2, 0L le vecteur de translation t v Ø : Eö E la translation par le vecteur v Ø , t v ØHpL = H2 + CosHuLL e1 + H2 + SinHuLL e2 + I v 2 M e3 Représentation d'une translation d'un cylindre dans l'espace euclidien !3 124 | Symétrie de rotation en architecture la Symétrie de rotation est également fait partie des symétries isométriques, et est une technique de composition très important dans la conception architecturale. Comme toutes les autres opérations algébriques, il a été plus utilisé dans l'architecture classique que dans l'architecture moderne et contemporaine. Il a été poussé à son comble avec le style architectural byzantin et son intérêt dans les structures en forme de dôme. L'architecture islamique montre quelques-uns des exemples les plus élaborées de l'utilisation de la symétrie de rotation non seulement dans les dômes, mais aussi dans les motifs graphiques utilisés pour décorer les façades et les intérieurs. Rotation (symétrie isométrique propre) [5] Fix HrL = 8p œ E rHpL = p< est l' axe de rotation E = Xo, e1, e2, e3 \ = !3 , r : Eö E, rHpL = rJm + m p N = m + rq Ø Hm p L est la rotation de centre m et d ' angle q rq Ø rotation vectorielle sur les axes x, y et z est représenté par la matrices orthogonales r Ø x,q = 1 0 0 0 cosHqL -sin HqL 0 sin HqL cosHqL , r Ø y,q = cosHqL 0 sin HqL 0 1 0 -sin HqL 0 cosHqL , r Ø z,q = mate HuL = cosHqL -sin HqL 0 sin HqL cosHqL 0 0 0 1 r Ø f,q,y = r Ø z,y r Ø y,q r Ø x,f préserve l' orientation correspondant à la rotation dansle sens horaire avec les angles d ' Euler f, q, y avec la convention x, y, z r Ø f,q,y = cosHqL cosHyL -cosHfLsinHyL + sinHfLsinHqL cosHyL sinHfLsinHyL + cosHfLsinHqL cosHyL cosHqLsinHyL cosHfL cosHyL + sinHfLsinHqLsinHyL -sinHfL cosHyL + cosHfLsinHqLsinHyL -sinHqL sinHfL cosHqL cosHfL cosHqL rotation générale autour d ' un axe m a où u Ø = m a °m a ¥ = Hu1, u2, u3L estson vecteur normalisé r Ø m a ,q = cosHqL + u1 2 H1 - cosHqLL u1 u2H1 - cosHqLL - u3 sinHqL u1 u3H1 - cosHqLL + u2 sinHqL u1 u2 H1 - cosHqLL + u3 sin HqL cosHqL + u2 2 H1 - cosHqLL u2 u3 H1 - cosHqLL - u1 sinHqL u1 u3 H1 - cosHqLL - u2 sinHqL u2 u3 H1 - cosHqLL + u1 sinHqL cosHqL + u3 2 H1 - cosHqLL E ` = !4 , r ` Hp ` L est la matrice représentant la rotation dans E ` = !4 " p, v œ !4 , p ` = x1 x2 x3 1 et v ` = v1 v2 v3 1 r ` f,q,yHp ` L = cosHqL cosHyL -cosHfLsinHyL + sinHfLsinHqL cosHyL sinHfLsinHyL + cosHfLsinHqL cosHyL v1 cosHqLsinHyL cosHfL cosHyL + sinHfLsinHqLsinHyL -sinHfL cosHyL + cosHfLsinHqLsinHyL v2 -sinHqL sinHfL cosHqL cosHfL cosHqL v3 0 0 0 1 x1 x2 x3 1 et r ` u Ø ,q Hp ` L = cosHqL + u1 2 H1 - cosHqLL u1 u2H1 - cosHqLL - u3 sinHqL u1 u3H1 - cosHqLL + u2 sinHqL v1 u1 u2 H1 - cosHqLL + u3 sin HqL cosHqL + u2 2 H1 - cosHqLL u2 u3 H1 - cosHqLL - u1 sinHqL v2 u1 u3 H1 - cosHqLL - u2 sinHqL u2 u3 H1 - cosHqLL + u1 sinHqL cosHqL + u3 2 H1 - cosHqLL v3 0 0 0 1 x1 x2 x3 1 | 125Rotation d'une forme dans l'espace euclidien !3 Comme mentionné avant toute transformation affine est composé d'une transformation linéaire et une translation, pour la rotation affine (i.e. la rotation + translation) nous devons choisir son centre et souvent ce centre n'est pas à l'origine de !3 . Nous devons donc composer notre rotation avec une translation d'un vecteur (vecteur entre l'origine et le centre de rotation) et utiliser son inverse comme le vecteur de translation de la rotation affine. Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle on applique la rotation. ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit m = t I0, 0, p 2 M , a = t I0, -3, p 2 M œ !3 tel que m a est l' axe de rotation, q = p 2 l' angle de rotation soit m O = t I0, 0, - p 2 M le vecteur de translation, afin de coïncider l' origine avec le centre de la rotation soit u Ø = m a °m a ¥ est le vecteur normalisé de l' axe de rotation t m O HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v 2 M - p 2 M e3 est la forme translatée soit v Ø = t I0, 0, p 2 M = O m le vecteur de translation de la rotation affine r : Eö E est la rotation d ' axe m a et angle q = p 2 " p œ ImHcL, rJt m O HpLN = I p 2 - v 2 M e1 + SinHuL e2 + I p 2 + CosHuLM e3 Représentation d'une rotation d'un cylindre le long d'un axe dans l'espace euclidien !3 126 | Symétrie de réflexion (bilatéral) La symétrie bilatérale avec la translation est l'opération algébrique la plus utilisée dans la conception architecturale. Historiquement, la majorité des bâtiments étaient symétriques autour d'un axe; spécialement, les bâtiments importants, puisque cette esthétique symétrique donné un sens d'équilibre et de puissance. Cette technique de composition utilisé sur tous échelle dans la conception architecturale de la plus petite des meubles aux grands plans d'urbanisme. La raison de cet intérêt dans la symétrie bilatérale vient de la croyance en la beauté du corps humain qui est bien sûr symétrique, et que, puisque Dieu a créé l'homme à son image donc symétrie a une certaine forme de divinité en elle. Les exemples de la symétrie bilatérale est beaucoup plus évidente dans l'architecture classique que dans l'architecture moderne, mais elle reste bien présente. Seulement à la fin du 20ème siècle, avec l'intérêt pour des formes courbes que cette importance de la symétrie bilatérale diminue considérablement, donnant lieu à des effets plus cinématographique de la dynamique plutôt que l'ancienne intérêt dans l'équilibre statique. Représentation de l'utilisation symétrie de réflexion (bilatéral) dans l'architecture Réflexion (symétrie isométrique) [5] s : Eö E, réflexion affine, s Ø : E Øö E Ø , réflexion vectoriel F Õ E sous - espace affine dont le sous - espace vectoriel directeur est F Ø , G Õ E sous - espace affine dont le sous - espace vectoriel directeur est G Ø E Ø = F Ø $G Ø ï " p œ E , s Ø est la réflexion vectorielle de E Ø par rapport à F Ø parallèle à G Ø , où v Ø = v1 Ø $v2 Ø ï s Ø Jv Ø N = v1 Ø $J-v2 Ø N , s Ø G Ø = -id G Ø ï G Ø = ker Js Ø + id E ØN et F Ø = ker Js Ø - id E ØN ï E Ø = ker Js Ø + id E ØN $ker Js Ø - id E ØN ï s Ø Js Ø N = id E Ø Hi.e. involutionL , FixHsL = F | 127Réflexion (symétrie isométrique) [5] E = Xo, e1, e2, e3 \ = !3 , F = Xo, e1, e2 \ = !2 , G = Xo, e3 \ = ! s : Eö E, sHpL = sJo + o p N = o + s Ø Ho p L est la réflexion de p par rapport à F parallèle à G Ø s Ø est la réflexion vectorielle de o p E ` = !4 , s ` Hp ` L est la matrice représentant la réflexion dans E ` = !4 " p, v œ !4 , p ` = x1 x2 x3 1 et v ` = v1 v2 v3 1 s ` Hp ` L = -1 0 0 v1 0 1 0 v2 0 0 1 v3 0 0 0 1 x1 x2 x3 1 = -x1 + v1 x2 + v2 x3 + v3 1 la réflexion sur le plan y - z s ` Hp ` L = 1 0 0 v1 0 -1 0 v2 0 0 1 v3 0 0 0 1 x1 x2 x3 1 = x1 + v1 -x2 + v2 x3 + v3 1 la réflexion sur le plan x - z s ` Hp ` L = 1 0 0 v1 0 1 0 v2 0 0 -1 v3 0 0 0 1 x1 x2 x3 1 = x1 + v1 x2 + v2 -x3 + v3 1 la réflexion sur le plan x - y Réflexion d'une forme dans l'espace euclidien !3 Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle nous appliquons la réflexion affine. ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit v Ø = t H0, -2, 0L le vecteur de translation de la réflexion affine s : Eö E la réflexion affine par rapport au plan x - z " p œ ImHcL, sHpL = CosHuL e1 + H-2 - SinHuLL e2 + I v 2 M e3 Représentation d'une réflexion d'un cylindre dans l'espace euclidien !3 128 | ü 5.4.3. Transformation affine non-isométrique Homothétie (mise à l'échelle) Le deuxième type de transformation affine nous construisons est l'homothétie et mise à l'échelle non uniforme. Mise à l'échelle comme une symétrie est non isométrique à savoir que la forme est déformée après son application. Historiquement, ce type d'opérations algébriques n'a pas été utilisé autant que les symétries isométriques comme la translation et la rotation mais on peut encore le voir dans la répétition de certains éléments architecturaux de différentes tailles, souvent comme une technique de décoration. Homethety peut être vu clairement dans la pagode chinoise traditionnelle comme chaque calque du toit a la même forme que la précédente, mais de plus petite taille ou dans la tour de Pise où les colonnes sont plus petits à chaque niveau. Homothétie est beaucoup plus utilisé aujourd'hui en raison de l'intérêt dans des formes courbes, ce qui est visible lorsque l'on veut créer un tableau à deux dimensions d'éléments sur une surface courbe, par exemple pavage sur une façade courbe ou d'un toit. En raison de la courbure, chaque tuile ou élément sera similaire aux autres, mais à une échelle différente pour une meilleure approximation de la surface courbe. Homethety est poussé à sa limite esthétiquement avec l'utilisation des opérations algorithmiques qui automatise la mise à l'échelle des éléments donnant le sentiment cinématographique du mouvement des éléments variables. Représentation d'une homothétie dans !2 d'un triangle à l'autre Homothétie (symétrie non isométrique) [5] Fix HhL = 8p œ E hHpL = p< E = Xo, e1, e2, e3 \ = !3 , h : Eö E, hHpL = hJm + m p N = m + h Ø Hm p L = m + l id E ØHm p L est l' homothétie de centre m et un rapport l h Ø = l id E Ø est l' homothétie vectorielle Hmise à l' échelle uniformeL m hHpL = J m hHpL m p N m p ï le rapport l = m hHpL m p E ` = !4 , h ` Hp ` L est la matrice représentant l' homothétie dans E ` = !4 " p, v œ !4 , p ` = x1 x2 x3 1 et v ` = v1 v2 v3 1 ï h ` Hp ` L = l 0 0 v1 0 l 0 v2 0 0 l v3 0 0 0 1 x1 x2 x3 1 = l x1 + v1 l x2 + v2 l x3 + v3 1 h ` Hp ` L = l1 0 0 v1 0 l2 0 v2 0 0 l3 v3 0 0 0 1 x1 x2 x3 1 = l1 x1 + v1 l2 x2 + v2 l3 x3 + v3 1 est la mise à l' échelle non uniforme | 129Homothétie (et mise à l'échelle non uniforme) d'une forme dans l'espace euclidien !3 Comme mentionné ci-dessus toute transformation affine est composé de une transformation linéaire et une translationtion, pour l'homothétie (et mise à l'échelle non uniforme) nous avons besoin de choisir son centre et souvent ce centre n'est pas l'origine de !3 . Nous devons donc composer notre homothetie avec une translation par un vecteur (vecteur entre l'origine et le centre de l'homothétie) et utiliser son inverse comme le vecteur de translation de l'homothétie affine. Homothetie ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit m = t I0, 0, p 2 M le centre de l' homothetie soit m O = t I0, 0, - p 2 M le vecteur de translation, afin de coïncider l' origine avec le centre de l' homothety t m O HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v 2 M - p 2 M e3 est la forme translatée soit v Ø = t I0, 0, p 2 M = O m le vecteur de translation de l' homothety h : Eö E est l' homothétie de centre o et de rapport 1 2 " p œ ImHcL, hJt m O HpLN = 1 2 CosHuL e1 + 1 2 SinHuL e2 + I 1 2 II v 2 M - p 2 M + p 2 M e3 Non uniform scaling ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit o = t I0, 0, p 2 M le centre de la mise à l' échelle non uniforme soit m O = t I0, 0, - p 2 M le vecteur de translation, afin de coïncider l' origine avec le centre de la mise à l' échelle non uniforme t m O HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v 2 M - p 2 M e3 est la forme translatée soit v Ø = t I0, 0, p 2 M = O m le vecteur de translation de la mise à l' échelle non uniforme h : Eö E est la mise à l' échelle non uniforme de centre o et rapports l1 = 2, l2 = 3 2 et l3 = 1 4 " p œ ImHcL, hJt m O HpLN = 2 CosHuL e1 + 3 2 SinHuL e2 + I 1 4 II v 2 M - p 2 M + p 2 M e3 Représentation d'une homothetie et une mise à l'échelle non uniforme d'un cylindre dans l'espace euclidien !3 130 | ü 5.4.4. Projections orthogonales Maintenant, nous allons examiner certains des transformation affine les plus traditionnellement utilisé dans l'architecture à savoir les projections affines. les projections orthogonales affines sont généralement connus dans l'architecture que le plan, élévation, coupe, et il n'est pas nécessaire de souligner l'importance de ces types de représentations de formes dans l'architecture. En fait, les projections orthogonales sont un type particulier de projections affines où la direction de la projection est perpendiculaire au sous-espace affine sur lequel nous projetons. Pour la perspective, nous avons besoin de comprendre quelques notions de la géométrie projective afin de la définir, mais il y a aussi une version affine qui la plus souvent utilisée dans l'architecture. Ces projections orthogonales affine: le plan, l'élévation et la section sont connus comme le dessin technique d'un bâtiment ou un projet qui correspond à la définition de l'architecture. Ils sont utilisés pour développer une idée de conception en une proposition cohérente, de communiquer des idées et des concepts et convaincre le client des mérites d'une conception et de permettre à un entrepreneur pour le construire. Ils sont aussi utilisés comme un dossier du travail accompli, et de faire un enregistrement d'un bâtiment qui existe déjà. Représentation de la projection orthographique architectural Projection [5] r : Eö E, projection affine , r Ø : E Øö E Ø , projection vectoriel F Õ E sous - espace affine dont le sous - espace vectoriel directeur est F Ø , G Õ E sous - espace affine dont le sous - espace vectoriel directeur est G Ø E Ø = F Ø $G Ø ï " p œ E , F › Kp + G Ø O = 8rHpL< un point Ki.e. la projection de p sur F parallèle à G Ø O r Ø est la projection vectorielle de E Ø sur F Ø parallèle à G Ø , où v Ø = v1 Ø $v2 Ø ï r Ø Jv Ø N = v1 Ø , r Ø F Ø = id F Ø ï G Ø = ker r Ø et F Ø = ker Jr Ø - id E ØN ï E Ø = ker r Ø $kerJr Ø - id E ØN ï r Ø Jr Ø N = r Ø , FixHrL = F et rHEL = F | 131Projection [5] E = Xo, e1, e2, e3 \ = !3 , F = Xo, e1, e2 \ = !2 , G = Xo, e3 \ = ! r : Eö E, rHpL = rJo + o p N = o + r Ø Ho p L la projection de p sur F parallèle à G Ø r Ø est projection vectorielle de o p E ` = !4 , r ` Hp ` L est la matrice représentant de la projection dans E ` = !4 " p, v œ !4 , p ` = x1 x2 x3 1 et v ` = v1 v2 v3 1 r ` Hp ` L = 1 0 0 v1 0 1 0 v2 0 0 0 v3 0 0 0 1 x1 x2 x3 1 = x1 + v1 x2 + v2 0 + v3 1 projection sur le plan x - y r ` Hp ` L = 0 0 0 v1 0 1 0 v2 0 0 1 v3 0 0 0 1 x1 x2 x3 1 = 0 + v1 x2 + v2 x3 + v3 1 projection sur le plan y - z r ` Hp ` L = 1 0 0 v1 0 0 0 v2 0 0 1 v3 0 0 0 1 x1 x2 x3 1 = x1 + v1 0 + v2 x3 + v3 1 projection sur le plan x - z Affine projection orthogonale d'une forme dans l'espace euclidien !3 Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle on applique la projection affine. ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I v 2 M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD= soit v Ø = t H1, 1, 0L le vecteur de translation de la projection affine r : Eö E est la projection affine sur le plan x - z " p œ ImHcL, rHpL = CosHuL e1 + 3 e2 + I v 2 M e3 Représentation d'une projection orthogonale d'un cylindre dans l'espace euclidien !3 132 | ü 5.4.5 Conception en utilisant la géométrie affine Maintenant que nous avons défini ces transformation affine essentiel, nous allons maintenant montrer comment lesutiliser comme outils pour la conception, dans la partie qui suit, nous allons montrer quelques projets architecturaux où l'idée principale de la conception a été basée sur la transformation affine. L'idée était de créer un bâtiment de faible hauteur qui sera composée d'une série des composants, ces composants peuvent être considérés comme des ensembles de vecteurs ou de points qui seront progressivement transformé le long de la longueur du bâtiment, en utilisant des transformations affine comme mise à l'échelle et translations. Représentation de la série des composants qui transforment le long de la longueur du bâtiment Représentation de la forme architecturale générée à partir des série de composants | 133Plus de conception utilisant des transformations affines Maintenant que nous avons montré le principe de base, nous allons montrer des conceptions plus élaborées utilisant cette méthode des transformations affines. Représentation de la manière dont ces éléments se transforment dans le plan et dans la coupe Représentation du bâtiment de faible hauteur conçu par des transformations affines 134 | Plus de conception utilisant des transformations affines Dans ces deux exemples suivants, les transformations des composantes sont liées à certaines propriétés ambiantes des activités, qu'ils abriteront en termes de programme architectural. Ces propriétés ambiantes n'ont pas été testés en termes de ingénierie environnementale, mais notre accent est mis sur la méthode géométrique en utilisant des transformations affines et le lien avec les ambiances est plus hypothétique. Dans ce premier exemple, les transformations sont liées à la chaleur des activités dans chacun des composants, allant d'un extrême à l'autre. Représentation de la manière dont les composants ont différentes températures Représentation des différentes activités intérieures avec leurs différentes températures | 135Plus de conception utilisant des transformation affines Dans ce second exemple, c'est le flux d'air chaud qui est stimulé par les différentes formes de composants qui, comme dans le premier exemple créerait des différents espaces ambiantes pour différentes activités. Représentation de la manière dont les composants auront des flux d'air différents Représentation des différentes ambiances provoquées par les différentes composantes 136 | Plus de conception utilisant des transformation affines Dans ce qui suit, nous allons présenter une autre application de transformation affine, cette fois au lieu de travailler à l'échelle du bâtiment, nous allons transformer les composants à l'échelle éléments de façade pour créer des pavages. Dans cet exemple, il existe deux principales transformations affines: le premier est sur le réseau où se trouve le composent, ce qui à son tour déforme le composant elliptique et la seconde est la rotation de ce composant. Représentation de la transformation affine du réseau et le composant Représentation du motif généré en utilisant une transformation affine sur le réseau et le composant | 137ü 5.5. Géométrie projective ü 5.5.1. Espace projectif et groupe projectif Notre étude de symétrie nous a amené à comprendre la géométrie euclidienne comme l'étude des propriétés géométriques invariantes par le groupe euclidien (de transformations euclidiennes) comme une spécialisation de géométrie affines qui en elle-même l'étude des propriétés géométriques invariantes par le groupe affine (des transformations affines). De même, la géométrie projective serait l'étude des propriétés géométriques invariantes par le groupe projectif (des transformations projectives); naturellement, la géométrie projective a un contexte différent avec des notions telles que l'espace projectif, homographie, coordonnées homogènes. Un aspect important de la géométrie projective qui est différente de la géométrie euclidienne est que les lignes parallèles se rencontrent aux points à l'infini; cette notion a son origine dans l'invention de la perspective linéaire par des artistes de la Renaissance. En géométrie euclidienne, les angles et les distances sont invariantes par transformations euclidiennes, en géométrie affine, colinéarité, le parallélisme et des rapports de distance le long de lignes parallèles sont invariantes par transformation affine. En géométrie projective, la structure de l'incidence et de la relation de conjugués harmonique projective (entre autres) sont conservées sous des transformations projectives. Avant de discuter en détail la perspective, nous allons d'abord définir l'espace projectif et la transformation projective, qui est plus radical dans son expression que les transformations affine et euclidienne, exprimé par une translation et une transformation linéaire. Représentation du plan projectif réel comme une sphère S 2 où les points antipodaux sont identifiés Espace projectif [5] E Ø est un # - espace vectoriel et # est un corps commutatif et # * = #\ 80< # * äE Ø \ 80<ö E Ø \ 80< , Jl, x Ø Nö l.x Ø = l x Ø est une action de groupe PKE Ø O = E Ø \ 80<ì# * est l' espace projectif de E Ø Kl' ensemble de droites de E Ø O x = PHxL œ PKE Ø O est un point dansl' espace projectif de E Ø , x = OrbHxL = :y Ø œ E Ø \ 80< y Ø = l.x Ø > dim PKE Ø O = dim E Ø - 1 si E Ø = !n+1ïPKE Ø O = PnH!L l' espace projectif réel et x = @x0 : ... : xnD les coordonnées homogènes 138 | Espace projectif comme une variété [9] Ui Õ PnH#L ouvert, Ui = 8@x0 : ... : xnD xi " 0< pour i = 0, ..., n où PnH#L = ‹0§i§nUi et HUi , jiL est une carte de PnH#L ji : Ui Õ PnH#Lö # n , @x0 : ... : xnD ö x0 xi , .., xi xi fl , .., xn xi est un difféomorphisme lisse toutesles cartes de l' atlas maximal $ = HUi , jiLiœI sont compatibles ï PnH#L est une variété différentiable Sous-espace projectif [5] F Ø Õ E Ø sous - espace vectoriel ï PKF Ø O Õ PKE Ø O est le sous - espace projectif si H Ø est un hyperplan vectorielKi.e. codim H Ø = 1O ïPKH Ø O est un hyperplan projectif S = 8p0, .., pk< est un ensemble de points de PKE Ø O ïXS\ est le plus petit sous - espace projectif de PKE Ø O contenant S p0 = PHDiL, où Di = # vi Ø est une droite vectorielle E Ø et F Ø = vectJ:vi Ø , i = 0, ..., k>N pour i = 0, ..., k, vi Ø sont linéairement indépendantï pi = PHDiL = PJ# vi Ø N sont projectivement indépendants Transformation projective (homographie) [5] E Ø , E Ø ' deux espaces vectoriels, PKE Ø O, PKE Ø 'Oleurs espaces projectifs associés f Ø : E Øö E Ø ' est une application linéaire continue ï " D Ø Õ E Ø est une droite vectorielle f Ø KD Ø O = 0 Ø E Ø ' si D Ø Õ ker f Ø ou f Ø KD Ø O = D' Ø une droite vectorielle de E Ø ' ï PKf Ø O : PKE Ø O \P ker f Ø ö PKE Ø 'O, PKf Ø O HDL = PKf Ø KD Ø OO = P KD' Ø O est une application projective si f Ø est un isomorphisme ï PKf Ø O est une transformation projective Hou une homographieL Groupe projectif [5] G P KE Ø O = :PKf Ø O : E Øö E Ø , transformation projective> est le groupe projectif muni de la loi PKf Ø OÎPJg Ø N = PKf Ø Î g Ø O P : GLKE Ø Oö G P KE Ø O est un groupe de isomorphism ZKGLKE Ø OO = :l.id E Ø , l œ # * > isomorphe à # * ïGLKE Ø Oì# * .id E Ø = PGL KE Ø O est le groupe projectif si E Ø = # n+1ï GLn+1 H#Lë# * = PGLn+1H#L est le groupe linéaire projective Le perspective HprojectiveL est une homographie qui est un élément du groupe projectif | 139ü 5.5.2. Bref historique de la perspective Le système de perspective que nous tenons pour acquis aujourd'hui est une invention relativement récente dans l'histoire de l'art. Avant le 14ème siècle, il n'y avait presque aucune tentative de dépeindre de façon réaliste le monde en trois dimensions dans l'art dans la manière dont nous sommes maintenant habitués à voir. L'art des périodes byzantines, médiévales et gothiques riches comme il était, il n'a fait aucune tentative pour créer l'illusion de la profondeur et de l'espace. Il n'était pas jusqu'à ce que les peintres de la pré-renaissance, comme Giotto et Duccio qu'une idée précoce de perspective a été en cours d'expérimentation. Ils ont utilisé les ombres à grand effet de créer une illusion de profondeur, mais il était encore loin d'être le genre de perspective que nous connaissons aujourd'hui. La première image connue à utiliser la perspective linéaire a été créé par la polymathe Filippo Brunelleschi, il dépeint le baptistère de Florence à partir de la grille d'entrée de la cathé- drale inachevée. Le système de la perspective linéaire projeté l'illusion de profondeur sur un plan à deux dimensions par l'utilisation de points de fuite à laquelle toutes les lignes convergent, au niveau des yeux sur l'horizon. Masaccio a été le premier grand peintre du début de la Renaissance qui a démontré commandement intégral des nouvelles règles de la perspective, les personnages de ses peintures ont un volume et les bâtiments et le paysage se retirent de façon réaliste dans la distance. Mosaccio est considéré aujourd'hui comme l'initiateur du nouveau style de réalisme florentin. À la fin du 15ème siècle, les artistes étaient en commande totale de la perspective et ont réussi à créer dans leur art un monde beau et réaliste. Derrière ces changements dans les méthodes artistiques et l'utilisation de la perspective était un désir renouvelé à décrire la beauté de la nature et de démêler sa beauté mathématique, avec les œuvres des maîtres de la Renaissance comme Léonard de Vinci. Les développements dans la perspective linéaire n'ont pas été seulement limitées à la Renaissance italienne, mais aussi la Renaissance du nord dans les œuvres des maîtres hollandais tels que Jan van Eyck, dont les peintures ont exprimé un haut niveau de détails en perspective. Cette corrélation entre les arts et les mathématiques a atteint son apogée avec le développement de la géométrie projective ayant ses origines dans la théorie de la perspective; les mathématiciens et les artistes étaient intéressés par les principes qui ont régi cette technique artistique. En particulier, l'intérêt pour les lignes de vue et les lignes parallèles qui convergent à un point de fuite, qui est connu plus tard comme le points à l'infini. La théorie de la perspective représente un moment unique où l'architecture, l'art et les mathématiques ont partagé un intérêt commun directe, un moment où de nouveaux concepts en mathématiques ont été créés à partir des origines artistiques. Le mathé- maticien et architecte Girard Desargues était l'un des premiers à poser les bases de ce qui sera la géométrie projective; sur la base de son travail sur la perspective. Desargues introduit une nouvelle technique pour l'élaboration de la perspective sans attirer le point de fuite (i.e. qu'ils se situent en dehors du plan de l'image); contrairement aux techniques de la perspective linéaire communes qui commencent par dessiner les points de fuite. Cette technique repose sur des mesures de l'objet, et des constructions des échelles dans le plan de l'image, ces échelles sont construits à partir des mesures et sont utilisés de manière à préserver la distance et la dimension dans l'image. Une fois les échelles ont été établies, l'artiste peut tout simplement utiliser un compas et une règle pour décrire le sujet souhaité de manière appropriée en perspective. Suite à cette construction de la perspective, Desargues crée son théorème qui stipule que si trois lignes droites reliant les sommets correspondants de deux triangles, les trois intersections des paires de côtés correspondants se trouvent sur une ligne droite. Représentation du système des miroirs de Filippo Brunelleschi pour construire la perspective 140 | Théorème de Desargues théorème de Desargues (affine) théorème de Desargues (projective) Théorème de Desargues (affine) [5] soit HA B CL et HA' B' C'L deux triangles dans un plan affine E tel que A " A', B " B' and C " C' , HB CL êê HB' C'L, HC AL êê HC' A'L and HA BL êê HA' B'L ïHA A'L, HB B'L and HC C'Lsont parallèles ou concurant Théorème de Desargues (projective) [5] soit A, B, C Het A', B', C'L trois points projectivement indépendants dans un plan projectif tel que A " A', B " B' et C " C' , P = HB CL › HB' C'L, Q = HC AL › HC' A'L et R = HA BL › HA' B'L alors P, Q, R sont alignés óHA A'L, HB B'L et HC C'Lsont concurant Représentation de la pyramide visuelle de Alberti montrant le théorème de Desargues Il existe un lien clair entre ce théorème et la perspective linéaire ceci peut être vu dans l'image représentant la technique de la pyramide visuelle d'Alberti. Ici, le triangle A B C se trouve dans le plan de sol (la base de la pyramide), le triangle A ' B ' C' se trouve dans le plan de l'image, le point E au cours de laquelle la lignes de vue (raccordement sommets correspondants) se rencontrent est l'œil de la l'artiste , la sommet de la pyramide visuelle. Ce théorème établir le lien entre les études de la perspective à la géométrie projective moderne. Considérons par exemple l'intersection HA BL › HA' B'L si elle est dans le plan contenant les deux lignes, c'est garanti par le théorème, Cependant, si les droites sont parallèles, dans le plan dans lequel ils se trouvent, ils ne se coupent dans ce plan. Cependant, le théorème garantit ces lignes se croisent; Desargues introduit un point où deux lignes parallèles se croisent à savoir le point à l'infini. | 141ü 5.5.3. Points à l'infini Depuis l'époque de Desargues, la géométrie projective a été élargi pour devenir un champ unique en mathématiques comme nous l'avons montré avec ses propres réglages et opérations (espace projectif, transformations projectives), mais cet espace projectif moderne peut être développée de la même manière qu'il était en géométrie projective classique. Nous avons construit plus tôt l'espace projectif réel comme l'ensemble des droites de l'espace euclidien, maintenant, nous allons montrer comment ce connecter à l'idée des lignes de vue de l'art de la perspective. Nous allons nous concentrer uniquement sur l'espace euclidien !3 et le plan projectif réel P2H!L et puis nous allons donner la définition générale formelle de l'espace projectif abstrait. Voyons d'abord prétendons que sur une ligne de vue, il est seulement un point que l'on voit, l'objet qui est le plus proche contiendra ce point, donc pour une ligne de vue que vous choisissez, le résultat est que vous voyez un seul point correspondant à la ligne de vue comme on le voit dans la formulation suivante. Voyons d'abord prétendons que sur une ligne de vue, il y a seulement un point que l'on voit, l'objet qui est le plus proche contiendra ce point, donc pour une ligne de vue que vous choisissez, le résultat est que vous voyez un seul point correspondant à la ligne de vue comme on le voit dans la formulation suivante. !* ä !3 \ 80<ö !3 \ 80< , Jl, x Ø Nö l.x Ø = l x Ø est une action de groupe, P2H!L = !3 \ 80< ë!* est le plan projectif de !3 x Ø = Hx1, x2, x3L est équivalent à l.x Ø = l x Ø = y Ø = Hl x1, l x2, l x3L Hi.e. ilsse trouvent sur la même ligne de vueL x = PHxL œ P2H!L est un point dansle plan projectif, x = OrbHxL = :y Ø œ !3 y Ø = l.x Ø > Nous procédons maintenant à construire le plan projectif réel; Imaginez que vous êtes debout à l'origine et il y a une toile dans l'espace euclidien !3 au niveau du plan y = 1. Vous pouvez regarder dans n'importe quelle direction et vous verrez un point situé sur la ligne de vue; cette ligne de vue lorsqu'il est étendu à l'infini ferait l'une des deux choses, soit elle coupe le plan y = 1 ou elle est parallèle à savoir dans y = 0 plan. Si la ligne coupe le plan y = 1 au point d'intersection, par exemple Hx1, 1, x3L dans l'espace euclidien !3 alors Hx1, 1, x3L est dans le point d'intersection dans le plan projectif. Toutefois, si la ligne est parallèle au plan y = 1, le point dans le plan projectif d'intersection serait Hx1, 0, x3L (i.e. le point à l'infini). Cela nous indique que le plan projectif est l'union de l'ensemble des points dans le plan y = 1 (isomorphe à !2 ) et l'ensemble de points à l'infini, donc P2H!L = !3 ‹ 8points à ¶<. Maintenant, nous définissons les lignes dans le plan projectif Hi.e. par l' équation a X1 + b X3 + c = 0L, en accord avec notre toile y = 1 plan, si nous pensons d'une ligne dans ce plan compte tenu de notre relation d'équivalence, nous pouvons prendre le point Hx1 ê x2 , 1, x3 ê x2L en tant que représentant de certain point Hx1, x2, x3L dans !3with HX1 = x1 ê x2 and X3 = x3 ê x2L. De cette façon, l'équation de la ligne a X1 + b X3 + c = 0 est bien définie dans le plan projectif puisque a Hx1 ê x2L + b Hx3 ê x2L + c = a x1 + b x3 + c x2 = 0 et a x1 + b x3 + c x2 = 0 est bien défini dans le plan projectif. C'est parce que tout point Hl x1, l x2, l x3L est une solution de l'équation puisque a l x1 + b l x3 + c l x2 = lHa x1 + b x3 + c x2L = l .0 = 0. Maintenant, nous regardons ce qui se passe aux droites parallèles dans le plan projectif. Nous savons que les lignes parallèles ont la même pente si l'on considère les lignes X3 = HaêbL X1 + c = 0 et X3 = HaêbL X1 + d = 0 avec HaêbL la pente en commun, maintenant en multipliant les équations par b et substitution par X1 = x1 ê x2 et X3 = x3 ê x2, nous obtenons les deux équations b x3 - a x1 - c b x2 = 0 et b x3 - a x1 - d b x2 = 0. Pour trouver le point d'intersection nous supposons x2 = 1, ce qui nous donne les équations x1 = HbêaL - Hc bêaL x2 et x1 = HbêaL - Hd bêaL x2 qui donne le point d'intersection Hbêa, 0, 1L, Cela signifie que les points d'intersections des lignes parallèles en effet se situent sur le plan y = 0 (i.e. à l'infini) [10]. Maintenant que nous avons compris le construction mathématique de la perspective linéaire du point de vue de la géométrie projective moderne, nous allons maintenant donner la définition générale et abstraite des points à l'infini en utilisant des coordonnées homogènes et aller plus loin pour définir le perspective tant que transformation projective. 142 | ü 5.5.4. Construction de la perspective Coordonnées homogènes [5] E Ø = # n+1ï PKE Ø O = PnH#L = PI# n+1 M estson espace projectif associé si v Ø = HX0, ..., XnL , v' Ø = HX0 ', ..., Xn 'L D Ø = v v' , $ l œ # * , Xi = l Xi ' pour i = 0, ..., n p œ PnH#L, p = PKD Ø O = @X0 : ... : XnD = @X0 ' : ... : Xn 'D Hi = 8p = @X0 : ... : XnD œ PnH#L Xi = 0< est un hyperplan projectif Projectivisation de l'espace affine [5] E Ø est # - espace vectoriel, E estson espace affine associé à E ` son extension vectoriel ï PHE ` L = E ‹ PKE Ø O est la projectivisation de E où E est un ouvert affine de PHE ` L avec un complémentaire le hyperplan projectif PKE Ø O = E¶ Points à l'infini [5] E Ø = # n+1ï PKE Ø O = PnH#L estson espace projectif associé H0 Ø = :p = HX0, ..., XnL œ E Ø X0 = 0> est l' hyperplan vectoriel PKH0 Ø O = H0 = 8p = @X0 : ... : XnD œ PnH#L X0 = 0< est l' hyperplan projectif associé PKH0 Ø O c = H0 est un ouvert affine dans PnH#L ï p œ H0, p = B1 : x1 = X1 X0 : ... : xn = Xn X0 F H0 = e0 Ø + H0 Ø avec e0 Ø comme origine et He1, ..., enL comme base ï p œ H0, p = Hx1, ..., xnL coordonnées cartésiennes de même, si E un espace affine, dim E = n E = Xo, e1, ..., en \ = # n et E ` = #$# n son extension vectoriel ï p œ E, p = Hx1, ..., xnL coordonnées cartésiennes et p ` œ E ` , p ` = Hx0, x1, ..., xnL coordonnées cartésiennes ï PnH#L = PI# n+1 M = PHE ` L = E ‹ E¶ E = 8@1 : x1 : ... : xnD, Hx1, ..., xnL œ # n < E¶ = PH8x0 = 0 0, $ h : ° h¥E > h tel que 1 ° h¥E ° f Ha + hL - f HaL - f ' HaL.h¥F § e f est différentiable en a ó f Ha + hL = f HaL + f ' HaL.h +°h¥E.eHhL , où eHhL öhØ0 0F , h " 0 Aapplications composées [2] HE, ° .¥EL , HF, ° .¥FL and HG, ° .¥GL trois espaces vectoriels normés f : U Õ EöF , g : V Õ FöG , supposons f HaL = b œ V et W = f -1 HVL Õ U un ouvert de E , a œ W h = g Î f : W Õ EöG supposons f est différentiable en a et g est différentiable en b = f HaL alors h est différentiable en a et h' HaL = g ' H f HaLLÎ f ' HaL où f ' HaL œ 'HE, FL , g ' HaL œ 'HF, GL , h' HaL œ 'HE, GL | 149Différentiabilité d'applications [2] cas : 1 E , F1, ..., Fn n + 1 espaces vectoriels normés , U ouvert de E, f : U Õ EöF = F1µ ...µFn y œ F ï y = Hy1, ..., ynL tel que pour 1 § i § n yi œ Fi , °y¥p = I⁄i=1 n †yi §Fi p M 1 p et °y¥¶ = Sup i=1,..,n †yi §Fi projection, pi : FöFi , piHyL = yi injection canonique , ui : FiöF , uiHyiL = H0, .., 0, yi , 0, ..., 0L pour 1 § i § n , pi et ui sont des applications continues linéaires donc différentiable piÎui = idFi et ⁄i=1 n uiÎ pi = idF pour a œ U , f est différentiable en a ó " i = 1, ..., n fi = piÎ f : U Õ EöFi est différentiable en a et f ' HaL = ⁄i=1 n uiÎ fi ' HaL , où f ' HaL œ 'HE, FL et fi ' HaL œ 'HE, FiL cas : 2 E1, ..., En, F n + 1 espaces vectoriels normés , U ouvert de E = E1µ ...µEn , f : U Õ E = E1µ ...µEn öF x œ E ï x = Hx1, ..., xnL , °x¥E = Sup i=1,..,n †xi §Ei pour a œ U , a = Ha1, ..., anL et h = Hh1, ..., hnL application partielle f Îli , li : EiöE , liHxiL = a + uiHxi - aiL = Ha1, .., ai-1, xi , ai+1, ..., anL = a - uiHaiL + uiHxiL li est différentiable en xi et li ' HxiL = ui , f Îli : li -1 HUL Õ EiöF , f Îli est différentiable car li et f sont différentiables pour a œ U , f est différentiable en a ó " i = 1, ..., n les applications partielles sont différentiables en les ai cette différentielle est notée ! f !xi HaL la dérivée partielle par rapport à xi en a ! f !xi HaL = f ' HaLÎui , f ' HaL = ⁄i=1 n ! f !xi HaLÎ pi ï pour a, h œ U , f ' HaL.h = ⁄i=1 n ! f !xi HaL.hi cas : 3 E = !n , F = !p espaces vectoriels normés, U ouvert de E, f : U Õ EöF , f Hx1, ..., xnL = I f1Hx1, ..., xnL, ..., fpHx1, ..., xnLM f est différentiable ó " i = 1, ..., p , " j = 1, ..., n fi est différentiable fi : !nö! ï l' existence de ! fi !x j HxL , où ! fi !x j HxL œ 'H!, !L º ! la matrice jacobienne pour a, h œ !n J f HaL = ! f1 !x1 HaL .. ! f1 !xn HaL : : : ! fp !x1 HaL .. ! fp !xn HaL , f ' HaL.h = J f HaL.h = ! f1 !x1 HaL .. ! f1 !xn HaL : : : ! fp !x1 HaL .. ! fp !xn HaL h1 : hn ligne i : ⁄k=1 n ! fi !xk HaL.hk 150 | Maintenant, nous allons donner deux théorèmes fondamentaux équivalents en calcul différentiel, à savoir, le théorème d'inversion locale et le théorème des fonctions implicites. Difféomorphisme [2] E, F deux espaces vectoriels normés, U Õ E ouvert f : U Õ EöF C1 Hi.e. différentiable etsa dérivée est continueL, bijective et f -1 est C 1 ï f est un C 1 difféomorphisme Théorème d'inversion locale (difféomorphisme local) [2] E, F sont des espaces de Banach, x œ U Õ E ouvert f : U Õ EöF est C 1 est f ' HxL : EöF est un isomorphisme ï $ V œ #x et W œ #f HxL f : VöW est un C 1 difféomorphisme Théorème des fonctions implicites [2] E, F, G sont des espaces de Banach, Hx, yL œ U Õ EäF ouvert , f : U Õ EäFöG tel que f Hx, yL = 0, f est C 1 sur U et #y f Hx, yL œ IsomHF, GL ï $ V œ #Hx,yL , W œ #x et j : Wö F C1 Hx, yL œ V , f Hx, yL = 0 ó x œ W , y = jHxL et j' HxL = -I#y f Hx, j HxLLM-1 Î#x f Hx, jHxLL Théorème des fonctions implicites (en dimension finie) [2] f : U Õ !n ä!pö!p , f Hx, yL = 0, f est C 1 sur U et detIJac fyHx, yLM " 0 ï $ V œ #x , W œ #y V äW Õ U Õ !n ä!p et j : Vö W C1 x œ V , y œ W, f Hx, yL = 0 ó x œ V , y = jHxL Représentation de la théorème des fonctions implicites Ces théorèmes sont en fait équivalent, et le théorème des fonctions implicites a été utilisé plus tôt dans la définition des surfaces locales qui recouvrent une surface algébriquement définis; et qui permettent alors de faire toutes les opérations définies plus tard. | 151ü 6.2. Géométrie différentielle des courbes ü 6.2.1. Définition d'une courbe régulière Auparavant, nous avons donné une définition plus généralisée des courbes et des surfaces, comme des variétés de dimensions un et deux, définies par paramétrage local, maintenant nous allons les définir plus en détail avec des explication des notions mathématiques nécessaires. Courbe paramétrée [1] a : I Õ Ha, bL Õ !ö!n est une courbe parametrique à condition que a can be étendue en fonction différentiable par morceaux à partir de Ha, bL à !n aHIL est la trace d ' a et S Õ !n est paramétrée par a si $ I Õ ! aHIL = S Courbe régulière [1] a : Ha, bL Õ ! ö!n une courbe régulière si " t œ Ha, bL a est différentiable et °a' HtL¥ " 0"H","n L si " t œ Ha, bL °a' HtL¥ = 1 alors a est de vitesse unité Maintenant, nous définissons les champs de vecteurs sur la courbe et le repère de Frenet et après la courbure des courbes et leur longueurs de l'arc. Intuitivement la courbure d'une courbe, mesure l'échec d'une courbe pour être une ligne droite, plus la vitesse tourne le long d'une courbe, plus la courbure. Maintenant, nous démontrons le contrôle de la forme en utilisant l'analyse, à savoir en tout point de la courbe nous savons son espace tangent, la longueur de la courbe, sa courbure et sa torsion, avec cette information, nous pouvons concevoir et décider beaucoup de choses sur cette courbe. Représentation du rayon de courbure d'une courbe en un point 152 | Vélocité de la courbe [1] a : I Õ ! ö!n une courbe avec aHtL = Ha1HtL, ..., anHtLL , t œ I alorsla vélocité de f est donnée par l' application a' HtL = Ha1 ' HtL, ..., an ' HtLL , où a' HtL œ 'H!, !n L , a' HtL est une application linéaire vHtL = °a' HtL¥ est la vitesse de a en t, a'' HtL est l' accélération de a en t pour n = 3, a : Ha, bL ö!3 , aHtL = Ha1HtL, a2HtL, a3HtLL la vélocité , l' accélération et la vitesse sont donnés par a' HtL = Ha1 ' HtL, a2 ' HtL, a3 ' HtLL et v1HtL = °a' HtL¥ a'' HtL = Ha1 '' HtL, a2 '' HtL, a3 '' HtLL et v2HtL = °a'' HtL¥ a''' HtL = Ha1 ''' HtL, a2 ''' HtL, a3 ''' HtLL et v3HtL = °a' HtLä a'' HtL¥ Champ de vecteur de la courbe [1] un champ de vecteursle long a est une application Y qui associe à chaque t œ Ha, bL un vecteur YHtL au point aHtL YHtL = Hy1HtL, ..., ynHtLL , Y est différentiableó " i = 1, ..., n yi : Ha, bL ö! est différentiable parfois, nous devons faire la distinction entre le vecteur YHtL en aHtL et le vecteur parallèle à celui à l' origine soit f : Ha, bL ö! , f différentiable et X, Y champs de vecteursle long a alors f YHtL = f HtL YHtL , H f YL' = f ' Y + f Y ' HX + YL' = X ' + Y ' , XX, Y\' = XX ', Y\ + XX, Y '\ HJ YL' = J Y ' , où J est la structure complexe, HJHx, yL = H-y, xLL Champs de vecteurs tangente et normale normalisé de la courbe plane [1] g : Ha, bL ö!2 , gHtL = HxHtL, yHtLL, une courbe régulière H°g' HtL¥ " 0L et différentiable par morceaux T 2 HtL = g' HtL °g' HtL¥ est le vecteur tangent à la courbe normalisé g at t œ Ha, bL N 2 HtL = JJ g' HtL °g' HtL¥ N est le vecteur normal à la courbe normalisé g at t œ Ha, bL , où J est la structure complexe IJ 2 = -id"2 M Repère de Frenet le long d'une courbe dans l'espace [1] a : Ha, bL Õ ! ö!3 est une courbe régulière si " t œ Ha, bL a est différentiable et °a' HtL¥ " 0"I","3 M THtL = a' HtL °a' HtL¥ est le champ de vecteur tangent unitaire de a NHtL = BHtLäTHtL est le champ de vecteur normal principal de a BHtL = a' HtLäa'' HtL °a' HtLäa'' HtL¥ est le champ de vecteur binormale unité de a Homotopies de la courbe régulière [1] l : !ö! est fonction scalaire qui pourrait être remplacée par lesfonctions de la longueur de l' arc, la courbure ou la torsion a, bT, bN, bB : Ha, bL Õ ! ö!3 courbes régulières bTHtL = aHtL + †lHtL§ THtL bNHtL = aHtL + †lHtL§ NHtL bBHtL = aHtL + †lHtL§ BHtL T La, l, N La, l , B La, l : Ha, bL Õ !ä@0, 1Dö!3 T La, lHt, uL = aHtL + u †lHtL§ THtL T La, lHt, 0L = aHtL et T La, lHt, 1L = bTHtL N La, lHt, uL = aHtL + u †lHtL§ NHtL N La, lHt, 0L = aHtL et N La, lHt, 1L = bNHtL B La, lHt, uL = aHtL + u †lHtL§ BHtL B La, lHt, 0L = aHtL et B La, lHt, 1L = bBHtL T La, l, N La, l et B La, l sont des homotopies entre a et bT, bN, bB respectivement | 153ü 6.2.2. Analyse d’une courbe régulière Courbure de la courbe plane [1] g : Ha, bL ö!2 , gHtL = HxHtL, yHtLL, une courbe régulière H°g' HtL¥ " 0L et différentiable par morceaux kgHtL = g'' HtL. J g' HtL °g' HtL¥3 = x' HtL y'' HtL - x'' HtL y' HtL Ix' 2 HtL + y' 2 HtLM3ê2 = "!Ig'' HtL i g' HtLM °g' HtL¥3 est la courbure de g , rk2HtL = 1 kgHtL est le rayon de courbure si g' HtL = 0 ou g' HtL n' existe pas ï kgHtL n' est pas défini etsi g'' HtL = 0 ï kgHtL s' annule b : Hc, dL ö!2 , une courbe de vitesse unité H°b' HsL¥ = 1, " s œ Hc, dLL ï b'' = kb J b'sa courbure signée La courbure et la torsion d'une courbe de l'espace [1] KHtL = °a' HtLäa'' HtL¥ °a' HtL¥3 est la fonction de courbure de a , rKHtL = 1 KaHtL est le rayon de la fonction de courbure de a tHtL = Xa' HtLäa'' HtL, a''' HtL\ °a' HtLäa'' HtL¥2 est la fonction de torsion de a KbHsL = °b'' HsL¥ est la courbure de b Ine s' annule jamais et Kb = °kb•si b est contenu dans !2 M La longueur de l'arc [1] a : Ha, bL Õ ! ö!n une courbe, soit I = Ha, bL supposons a est defind et différentiable en a et b LHaL = Ÿa b °a' HtL¥ „s est la longueur de a ne dépend pas de la paramétrisation de a SaHtL = Ÿt0 t °a' HuL¥ „u est la fonction de longueur de l' arc de a à partir de t0 œ Ha, bL SbHtL = Ÿt0 t °b' HuL¥ „u = t - t0 est la longueur de l' arc d ' une courbe de vitesse unité b : Hc, dLö!n à partir de t0 Analyse d'une courbe régulière [1] L'équation de la courbe de base est donnée par j : U Õ @0, 4 pD Õ !ö!3 , jHtL = It + SinI t 2 M - 1 100 SinHtL, SinI t 2 M, 1 - CosHtL + SinI t 2 MM le repère de Frenet jHt=3 pL = {T, N, B} jHt=3 pL={ 1 0 0 , 0 1 10 -3 10 , 0 3 10 1 10 } la longueur de l'arc jHt=3 pL = 12.1154 , la courbure jHt=3 pL = 0.774992 et la torsion jHt=3 pL = 0 Représentation du repère de Frenet sur une courbe régulière 154 | Jusqu'à présent, nous avons défini le repère de Frenet sur une courbe qui va nous permettre de définir les champs de vecteurs sur la courbe, qui à son tour est un outil de conception utile. Ensuite nous avons défini l'analyse de courbure et la longueur de l'arc de la courbe qui peut être également utilisé dans la conception d'autres courbes à partir de la courbe initiale. Avant de commencer à concevoir de nouvelles courbes à partir de courbes initiales à l'aide de ces définitions, nous allons définir une autre analyse utile qui est de trouver des points d'intersection entre les courbes. Points d'intersection si a, b deux droites , avec a, b, x, y œ !3 aHtL = a + t x et bHsL = b + s y ï aHtL = bHsL ï a1HtL a2HtL a3HtL = b1HsL b2HsL b3HsL ï a1 - b1 a2 - b2 a3 - b3 = -x1 y1 -x2 y2 -x3 y3 t s si a est une courbe et b est une droite, nous pouvons toujours trouver des points d ' intersection algébriquement en résolvant aHtL = bHsL si a est une droite et c un plan , avec a, c, x, y, z œ !3 aHtL = a + t x et cHu, vL = c + u y + v z ï aHtL = cHu, vL ï a1HtL a2HtL a3HtL = c1Hu, vL c2Hu, vL c3Hu, vL ï a1 - c1 a2 - c2 a3 - c3 = -x1 y1 z1 -x2 y2 z2 -x3 y3 z3 t u v ï t u v = -x1 y1 z1 -x2 y2 z2 -x3 y3 z3 -1 a1 - c1 a2 - c2 a3 - c3 si a est une courbe et c un plan, nous pouvons toujours trouver des points d ' intersection algébriquement en résolvant aHtL = cHu, vL Les points d'intersection de ligne / courbe et de courbe / plan a, b : U Õ @0, 1D Õ ! ö!3 , aHtL = I2 CosH2 p t - pL, 2 SinH2 p t - pL , H2 p t-pL 2 M , bHsL = H4 s, 0 , 2 p s - pL c : % Õ @-2, 2Dä@-2, 2D Õ !2 ö!3 , cHu, vL = H0, u - 2, v L aHtL = bHsL ï le point d ' intersection est H2, 0, 0L aHtL = cHu, vLï le point d ' intersection est H0, -2, -0.785L Représentation des intersections de ligne / courbe et de courbe / plan | 155ü 6.2.3. Conception en utilisant l'analyse d’une courbe régulière Avec ces définitions, nous pouvons déjà donner un exemple sur la façon d'utiliser l'analyse pour générer de nouvelles formes de celles définies précédemment. Par exemple, la courbe spirale allongée que nous avons défini plus haut va être utilisé comme notre courbe de base et nous allons définir son champ de vecteur normal et sa courbure et les utiliser pour dessiner une autre courbe. La courbure et la torsion peuvent être visualisées sur le domaine de la courbe, afin de voir clairement où elles sont les plus importantes et où elles ne sont pas définies. Conception en utilisant l'analyse (homotopies sur une courbe régulière) Le champ de vecteur normal défini sur cette courbe nous donne l'homotopie N LjHt, uL = jHtL + u †rKHtL§ NHtL rK : U Õ @0, 4 pD Õ !ö!, rKHtL = 1 KjHtL = °j' HtL¥3 °j' HtLäj'' HtL¥ le rayon de courbure Représentation des deux courbes reliées par une homotopie Représentation des tubes où le rayon de la section transversale varie avec la courbure 156 | ü 6.2.4. Tubes le long des courbes Maintenant, on peut construire une surface à partir d'un champ de vecteur le long d'une courbe, à savoir un tube le long de la courbe Tube le long d'une courbe [1] a : Ha, bL ö!3 une courbe , avec HT, N, B L est le repère de Frenet de a N et B sont perpendiculaires à a au point t , " t œ Ha, bL, HN, B L former une base orthonormée dans !2 ft0 : uö CosHuL NHt0L + SinHuL BHt0L en un t0 fixé, le cercle ft0 HuL est perpendiculaire à aHt0L pour t œ Ha, bL , le cercle ft0 HuLse déplace le long a et la trace de f est appelé le tube autour de a le tube autour de a est définie par c : % Õ !2ö!3 , ca, l, mHt, uL = aHtL + HlHtL CosHuL NaHt0L + mHtL SinHuL BaHt0LL , où l, m : U Õ !ö! sont deux fonction scalaire Tube autour de le noeud de tore L' équation de la courbe de base est donnée par j : U Õ @0, 2 pD Õ !ö!3 , jHtL = HH8 + 3 CosH5 tLL CosH2 tL, H8 + 3 CosH5 tLL SinH2 tL, 5 SinH5 tLL nous définissonslesfonctions scalaires l, m et l' équation pour le tube le long de j l, m : U Õ !ö! , l = 3 4 , mHtL = 100 Kj HtL 2 cj : % Õ !2ö!3 , cjHt, uL = jHtL + Il CosHuL NjHtL + mHtL SinHuL BjHtLM où KjHtL est la fonction de courbure de j et NjHtL, BjHtLsont les vecteurs normale et binormale de j au point t Représentation d'une surface tube autour d'un noeud de tore | 157ü 6.2.5. Conception utilisant des tubes Avec cette définition du tube le long de la courbe, nous allons montrer un exemple comment d'utiliser cette définition pour générer des surfaces de potentiel architecturale. l' équation de la courbe de base est donnée par j : U Õ @0, 2 pD Õ !ö!3 , jHtL = ICosH3 uL, SinH2 uL, 3 10 I 7 10 + SinH3 uLMM l' équation du tube le long de la courbe j cj : % Õ !2ö!3 , cjHu, vL = jHuL + 1 2 I 23 20 CosI v 2 M BjHuL + 2 5 SinI v 2 M NjHuLM où NjHuL, BjHuLsont les vecteurs normale et binormale de j au point u Représentation de la courbe de section transversale en mouvement le long de la courbe de trajectoire Maintenant, nous allons démontrer avec un exemple concret l'application de l'analyse d'une courbe régulière dans une conception architecturale. L'idée de la génération de forme était de travailler à partir d'une courbe dans l'espace et de générer une surface à partir de cette courbe. Représentation l'application en architecture pour la conception utilisant des tubes 158 | Conception en utilisant le tube le long de la courbe en CAD Maintenant que nous avons défini le tube le long d'une courbe et la fonction de NURBS plus tôt, nous allons montrer d'autres exemples de l'utilisation de cette méthode d'un tube le long d'une courbe pour générer des formes architecturales, ces exemples ont été réalisées en utilisant le logiciel de modélisation NURBS. Représentation du processus de la création de courbes transversales le long d'une courbe Dans cet exemple, nous pouvons voir la qualité sculpturale qui peut être introduit en utilisant le procédé d'un tube le long d'une courbe et la variation de la taille de la courbe transversale en utilisant une fonction à valeurs réelles le long de la courbe. Représentation de la surface tube en suivant les courbes transversales le long de la courbe de trajectoire | 159Plus de conception utilisant des tubes Dans cet exemple, on montre une conception de la forme d'un bâtiment construit entièrement à partir d'un tube le long d'une courbe avec des variation de l'échelle et de la rotation de la courbe transversale telle qu'elle progresse le long de la courbe de trajectoire. La surface tube peut être recoupé par des plans horizontaux pour obtenir des plans d'étage de base. Représentation des plans d'étage internes obtenus par l'intersection de la surface tube avec des plans horizontaux Représentation de la forme d'un bâtiment construit par la méthode du tube le long d'une courbe 160 | Plus de conception utilisant des tubes Maintenant, nous allons montrer d'autres exemples de générer une forme architecturale utilisant cette méthode du tube le long d'une courbe, cet exemple a également été conçu à l'aide d’un logiciel de CAO. On voit cidessous que dans ces exemples, nous n'avons pas créé une surface, mais les courbes transversales ont été utilisés pour créer des éléments discrets; ces éléments pourraient être des éléments structurels. Représentation d'une forme structurelle développée en utilisant le tube le long de la courbe Représentation d'une forme structurelle développée en utilisant le tube le long de la courbe montrant les sections | 161ü 6.3. Géométrie différentielle des surfaces ü 6.3.1. Calcul vectoriel Nous commençons par l'analyse d'une application f : !nö!m et en particulier pour le cas n = 2 et m = 3, c'est ce qu'on appelle une surface locale ou un patch. La surface locale est de plusieurs manières l'analogue en deux dimensions de la courbe dans l'espace, que nous avons défini plus tôt. Représentation de l'espace tangent à une surface régulière Vecteurs tangents à !n [1] Un vecteur tangent vp à l' espace euclidien !n se compose d ' une paire de points v, p œ !n v est appelé la partie vecteur et p est appelé le point d ' application de vp Espace tangent !p n [1] soit p œ !n , l' espace tangent de !n en p est l' ensemble !p n = 9vp v œ !n =, l' espace tangent !p n est une copie de l' espace vectoriel !n il y a un isomorphisme canonique entre eux donnée par vp # v ce qui nous permet de transformer !p n à un espace vectoriel avec toutesses propriétés " p, v, w œ !n , l œ ! , et J la structure complexe de !2 IJ 2 = -IM vp + wp = Hv + wLp , lIvpM = Hl vLp , Yvp, wp] = Xv, w\ , °Yvp, wp]• § ± vpµ ± wpµ J vp = HJ vLp , YJ vp, J wp] = Yvp, wp] " p, v , w œ !3 , vp äwp = HväwLp , ±vp äwpµ 2 = ±vpµ 2 ±wpµ 2 - Yvp, wp] 2 162 | Tangent vectors as directional derivatives [1] f , g : !nö! fonctions différentiables, vp , wp vecteurs tangents à !n en p œ !n , l, m œ ! vp@ f D = d d t f Hp + t vL t=0 Ila dérivée directionnelle dansla direction vpM , vp@ f D = ⁄i=1 n ! !ui f HpL vi Il vp + m wpM@ f D = l vp@ f D + m wp@ f D , vp@l f + m gD = l vp@ f D + m vp@gD , vp@ f gD = f HpL vp@gD + gHpL vp@ f D g1, ..., gk : !nö! et F : !kö! fonctions différentiables vp , wp vecteurs tangents à !n en p œ !n et f = FHg1, ..., gkL , vp@ f D = ⁄i=1 n ! !ui FHg1HpL, ..., gkHpLL vp@giD Difféomorphisme [1] % Õ !n ouvert, A Õ % , F è : % Õ !nö!m F è HpL = I f1 è HpL, ...., fm è HpLM, fi è : !nö! for i = 1, ..., m IF è différentiable car fi è différentiableM F : A Õ !nö!m, F = F è A IF est la restriction de F è MïF est différentiable un difféomorphisme F entre % et V Õ !m est une application différentiable F : %öV qui a un inverse différentiable F -1 : Vö% Application tangente [1] % Õ !n ouvert, F : %ö!m application différentiable, p œ %, " vp œ !p n F* : !p nö!FHpL m est appelé l' application tangente de F en p F*IvpM = FHp + t vL' H0L Hla vélocité initiale de la courbe t # FHp + t vLL , F*IvpM = Ivp@ f1D, ...., vp@ fmDMFHpL si a : Ha, bLö% une courbe ï HFÎaL' HtL = F*Ha' HtLL etsi vp = a' H0L et aH0L = p ï F*IvpM = HFÎaL' H0L Champ de vecteurs [1] % Õ !n ouvert, un champ de vecteurs V est une application qui associe à chaquep œ % un vecteur tangent VHpL œ !p n f : %ö! différentiable, alors V agit sur f par V@ f D HpL = VHpL@ f D le champ de vecteurs est dit être différentiable à condition que V@ f D : %ö! est différentiable si f l' est V est un champ de vecteursil existe des fonctions vi : %ö! Hpour i = 1, ..., nL tel que V = ⁄i=1 n vi Ui Fonctions coordonnes naturelles et repère naturel [1] Fonctions coordonnes naturelles de !n 8u1, ..., un< are defined by uiHpL = pi , pour p = Hp1, ..., pnL dansles cas particuliers de ! , !2 , !3 f lesfonctions coordonnes naturelles sont désignés par t, 8u, v< and 8x, y, z< le champ de vecteurs UiHpL = H0, ..., 1, ..., 0Lp avec le 1 apparaissant dansla i ème position le repère naturel de !n 8U1, ..., Un< il est évident que Ui@ f D = ! f !ui pour toute fonction différentiable f Matrice jacobienne [1] % Õ !n ouvert, F : %ö!m application différentiable, p œ %, F = H f1, ...., fmL, la matrice jacobienne est la matrice JHFL HpL = ! f1 !u1 HpL .. ! fm !u1 HpL : .. : ! f1 !un HpL .. ! fm !un HpL Gradient f : !nö! fonction différentiable, le gradient de f est le champ de vecteurs grad f = ⁄i=1 n ! f !ui Ui | 163ü 6.3.2. Définition d'une surface régulière Nous pouvons maintenant définir ces notions de champs de vecteurs et la tangence à une surface locale (patch) qui, avec les notions de l'injectivité et la régularité sont les ingrédients essentiels pour définir les champs de vecteurs et la tangence à une surface régulière. Surface locale (patch) dans !n [1] % Õ !2 ouvert, A Õ %, q œ % , c è : %ö!n est une application différentiable c : Aö!n est une surface locale à condition que c peut être étendue à c è , cHAL est la trace de c une surface locale peut être écrit comme un n - uplet de la fonctions cHu, vL = Hx1Hu, vL, ..., xn Hu, vLL Les dérivées partielles de la surface locale [1] % Õ !2 ouvert, q œ % c : %ö!n une surface locale ï c*I ! !u qM = I !x1 !u HqL, ..., !xn !u HqLM cHqL = cuHqL, où c* est l' application de poussée en avant de c cuHu, vL = I !x1 !u Hu, vL, ..., !xn !u Hu, vLM , cvHu, vL = I !x1 !v Hu, vL, ..., !xn !v Hu, vLM cu uHu, vL = J ! 2 x1 !u 2 Hu, vL, ..., ! 2 xn !u 2 Hu, vLN , cv vHu, vL = J ! 2 x1 !v 2 Hu, vL, ..., ! 2 xn !v 2 Hu, vLN cu vHu, vL = I ! !v I !x1 !u M Hu, vL, ..., ! !v I !xn !u M Hu, vLM = cv uHu, vL Normes VuHu, vL = °cuHu, vL¥ , VvHu, vL = °cvHu, vL¥ , Vu ä v Hu, vL = °cuHu, vLä cvHu, vL¥ Jacobienne % Õ !2 ouvert, c : %ö!n une surface locale ïest la matrice jacobienne est l' application JHcL Hu, vL = !c1 !u Hu, vL .. !cm !u Hu, vL !c1 !v Hu, vL .. !cm !v Hu, vL = cu Hu, vL cv Hu, vL Injectivité de la surface locale [1] % Õ !2 ouvert, q œ %, c : %ö!n une surface locale injective à condition que " Hu1, v1L et Hu2, v2L œ % , cHu1, v1L = cHu2, v2L ó Hu1, v1L = Hu2, v2L Régularité de la surface locale [1] c : %ö!n une surface locale réguliere ó JHcL Hu, vL est de rang 2 pour tousHu, vL œ % ce qui est équivalent à " Hu, vL œ % , cuHu, vL et cvHu, vLsont linéairement indépendants, sens de det Xcu, cu\ Xcu, cv\ Xcv , cu\ Xcv , cv\ " 0 c : %ö!n une surface locale réguliere en q œ % ó c* : !q nö !cHqL n est injective c : %ö!n une surface locale réguliere en œ % ï $ %q un voisinage de q c : %qö cI%qM est un difféomorphisme c : %ö!3 une surface locale réguliere en q œ % ó cuHqLä cvHqL " 0 Pour définir la tangence de la la surface, nous allons utiliser l'idée intuitive d'une courbe dont la trace se trouve dans la surface. Cette idée est tout à fait essentiel dans la géométrie différentielle des surfaces dans l'espace euclidien à trois dimensions, car une tangente à la surface peut être considérée comme une tangente à cette courbe. 164 | Naturellement, la surface locale vient avec les deux courbes de paramètres dans les directions u et v si nous commençons par les définir et nous définissons une courbe générale dont la trace se trouve dans cette surface locale. Courbes de paramètres [1] % Õ !2 ouvert, Hu0, v0L œ % , c : %ö!n une surface locale alorsles courbes u # cHu, v0L and v # cHu0, vL sont appeléesles courbes des paramètres u et v de c Courbe dont la trace se situe sur la surface locale [1] % Õ !2 ouvert, p = cHu0, v0L œ cH%L , c : %ö!n une surface local régulier telle que c : %ö cH%L est un homéomorphisme a : Ha, bLö!n une courbe dont la trace se situe sur la trace cH%L ï $ ! u, v : Ha, bLö ! différentiable telle que aHtL = cHuHtL, vHtLL pour t œ Ha, bL , a' HtL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL un vecteur tangent à c en p est un vecteur tangent vp œ !p n est tel que aH0L = p et a' H0L = vp Espace tangent à la surface locale [1] % Õ !2 ouvert, p œ cHUL , c : %ö!n une surface locale réguliere , on note l' ensemble des vecteurs tangents à c en p par cH%Lp où cH%Lp forme un espace vectoriel de dimension 2 qui est engendré par cuHu0, v0L et cvHu0, v0L cH%Lp ¨ = 9zp œ !p n " vp œ cH%Lp , Yzp, vp] = 0= et !p n = cH%Lp$ cH%Lp ¨ Champs de vecteurs sur la surface locale [1] % Õ !2 ouvert, q œ % et p = cHqL , c : %ö!n une surface locale , un champ de vecteurs V sur c est une application qui associe à chaque q œ % un vecteur tangent VHqL œ !p n V est tangent à c si VHqL œ cH%LcHqL " q œ % , V est normal à c si YVHqL, vp] = 0 " vp œ cH%Lp et " q œ % Champ de vecteurs normal unitaire [1] % Õ !2 ouvert , c : %ö!3 une surface locale injective , UHu, vL = cuä cv °cuä cv¥ Hu, vL le vecteur normal unitaire à la surface locale Enfin, nous allons maintenant définir les notions de la tangence, des champs de vecteurs d'une surface régulière (variété de dimension two par paramétrisation locale). Surface régulière (variété lisse de deux dimension par paramétrisation locale) [1] % Õ !2 ouvert , & Õ !n est une surface régulière à condition que " p œ & $ # un voisinage de la p et !n et $ c : %öH# › &L Õ !n où c est differetiable, c : %ö# ›& est un homéomorphisme et c : %ö& est une surface locale réguliere c : %ö !n est une surface locale réguliere ï " q œ % $ %q un voisinage de q cI%qM est une surface régulière c : %ö !n une surface locale injective régulière ï cI%qM est une surface régulière A partir de maintenant, nous allons toujours utiliser le terme surface régulière pour désigner une variété riemannienne lisse de deux dimensions (qui signifie tout simplement une variété lisse de deux dimensions avec une métrique riemannienne), cette définition d'une surface régulière est également connu comme une surface abstraite. | 165ü 6.3.3. Analyse d’une surface régulière ü 6.3.3.1. Champs de vecteurs Carte d'une surface régulière [3] c : %ö& est une surface locale réguliere sur & , HcH%L = UL Õ & ouvert, Ic -1 = jM : Uö !2 homéomorphisme Une carte sur une surface régulière est définie comme le couple : HU, jL ou H%, cL Fonction sur la surface [3] f :) Õ &ö ! est différentiable en p œ) à condition que pour c : %ö& avec p œ cH%L Õ) la composition f Î c : %ö ! est différentiable en c -1 HpL si f est différentiable en tout points de) on dit que f est différentiable sur) f : &ö ! est différentiable Hou lisseL à condition que " p œ &, $ HU, jL carte de & en p f Îj -1 : jHULö ! est différentiable Hou lisseL Différentiabilité d'une courbe sur une surface régulière [3] % Õ !2 ouvert, & Õ !n est une surface régulière , c : %ö& une surface régulière , a : Ha, bLö!n " t œ Ha, bL aHtL œ & , a est différentiable à condition que c -1 Îa : Ha, bLö % est différentiable Vecteur tangent à la surface régulière [3] & Õ !n est une surface régulière, p œ &, CHp, &L est l' ensemble des couplesHI, aL a : Iö& , aH0L = p ~ est une relation d ' équivalence sur CHp, &L telle que HI1, a1L~HI2, a2L équivalent ó " HU, jL carte de & en p, j : U Õ &ö !2 , HjÎa1L' H0L = HjÎa2L' H0L ï un vecteur tangent à & en p est une classe d ' équivalence @I, aD = vp aH0L = p and a' H0L = vp &p est l' ensemble des vecteurs tangents à & en p, &p est isomorphe à !2 Ietson espace tangent !jHpL 2 M par l' application Dp j : &pö !jHpL 2 , Dp jH@I, aDL = Dp jIvpM = HjÎaL' H0L Application tangente [3] c : % Õ !2ö& surface locale réguliere, q œ % Õ !2 , cHqL = p œ & et HU, jL carte de & " HI1, g1L~HI2, g2L œ CIq, !2 Mï HI1, cÎg1L~HI2, cÎg2L et ai = cÎgi pour i = 1, 2 ï nous pouvons définir l' application tangente entre les espaces tangents de la surfaces régulières % et & ï Tq c : %q Õ !q 2ö &p, Tq cH@I, gDL = Tq cIvqM = @I, cÎgD = @I, aD = vp Dp jIvpM = DcHqL jH@I, cÎgDL = HjÎ cÎgL' H0L = Dq jÎ cHg' H0LL Espace tangent à la surface régulière [3] % Õ !2 ouvert, & Õ !n est une surface régulière, q œ % et p œ & et vp est un vecteur tangent à & en p &p = 9vp œ !p n vp vecteur tangent à & en p= est l' espace tangent à & en p, un sous - espace vectoriel de !p n de dimension 2 si c : %ö& est une surface locale régulière Hi.e. un plongementL ï TcHqL cH%L = Im ITq c : %q Õ !q 2ö &pM = &p &p ¨ = 9zp œ !p n " vp œ &p , Yzp, vp] = 0= and !p n = &p$&p ¨ 166 | Intuitivement, un champ de vecteurs sur une surface & est une application qui associe à chaque point p un vecteur tangent vp mais ici nous allons définir la généralisation d'un champ de vecteurs comme une section du fibré tangent sur une surface régulière. Vector Bundle to a regular surface [3] & une surface régulière, E est l' espace total, P : Eö & is a vector bundle of rank = n , $ U Õ & ouvert f : P -1 HULö U ä!n un difféomorphisme " p œ & , " e œ Ep et fp : P -1 HpLö !n IP -1 HpL = Ep la fibre estM f : P -1 HpLö 8p<ä !n , fHeL = IPHeL = p, fpHeLM isomorphisme d ' espaces vectoriels Fibré tangent sur une surface régulière [3] & une surface régulière, p œ &, &p estson espace tangent à p T& = ‹pœ# &p = 9Ip, vpM p œ & et vp œ &p= est le fibré tangent de & V : &öT&, VHpL = vp œ &p, V est appelée une section de T& qui est un champ de vecteurs tangent GH&, T&L est l' ensemble de touteslessections Fibré normal sur une surface régulière [4] & une surface régulière, & est une sous - variété de * = !n , p œ &, &p estson espace tangent à p Np is &p ¨ est orthogonal à l' espace tangent en p , #N & = ‹pœ# *p ë&p est le fibré normal de & N& = ‹pœ# Np = 9Ip, npM p œ & et np œ &p ¨ = est le fibré normal de & N&ö#N & , Ip, npM # Ip, AnpEM est un isomorphisme canonique N : &öN&, NHpL = np œ &p ¨ , N est appelée une section de N& qui est un champ de vecteurs normal " p œ &, g œ GI*, T * *#2 M une métrique riemannienne sur * ï gpIvp, npM = 0 GH&, N&L est l' ensemble de touteslessections Fibré contangent et fibré alterné sur une surface régulière [3] & une surface régulière, p œ &, &p * = 'I&p, !M est le dual de son espace tangent en p T * & = ‹pœ# &p * = 9Ip, lpM p œ & et lp œ &p * = est le fibré cotangent de & l : &öT * &, lHpL = lp œ &p * , l est appelée une section de T * & qui est une 1 - forme différentielle GH&, T * &L est l' ensemble de touteslessections fl k T * & = ‹pœ# fl k &p * = 9Ip, lpM p œ & et lp œ fl k &p * = est la k ième puissance du fibré cotangent de & l : &öfl k T * &, lHpL = lp œ fl k &p * , l est appelée une section de fl k T * & qui est une k - forme différentielle GI&, fl k T * &M est l' ensemble de touteslessections Hcomme dim & = 2 , k = 0, 1, 2L Système de coordonnées pour une surface régulière [3] U Õ & une surface régulière, x1, x2 œ C ¶HU, !L j : Uö!2 , jHpL = Hx1HpL, x2HpLL difféomorphisme ï HU, jL est un système de coordonnées ï H# x1, # x2L est un repère de T& et Hd x1, d x2L est un repère de T * & X = HX1 # x1 + X2 # x2L œ GH&, T&L , f œ C ¶H&, !L , l = Hl1 d x1 + l2 d x2L œ H&, T * &L d f = #x1 f d x1 + #x2 f d x2 , où Xi = X@xiD = Xd xi , X\ et li = Xl, # xi\ pour i = 1, 2 X@ f D = Xd f , X\ = X1 #x1 f + X2 #x2 f | 167Pousser en avant des champs de vecteurs sur la surface régulière [3] % Õ !2 est une surface régulière, c : % Õ !2ö& une surface locale régulière U Õ % ouvert, Hu, vL œ C ¶HU, !L j : Uö!2 , jHqL = HuHqL, vHqLL difféomorphisme ï HU, jL est un système de coordonnées " V œ GH%, T%L , V = V1 ! !u + V2 ! !v est un champ de vecteurs tangent de %, où V1, V2 œ C ¶HU, !L " g : Iö %, gHtL = HuHtL, vHtLL , VHqL = VHgHtLL = g' HtL = HuÎgL' HtL I ! !u gHtL M +HvÎgL' HtL I ! !v gHtL M ï c*HVL œ GH&, T&L un champ de vecteurs tangent de & " p œ &, c*HVL HpL = Tc -1 HpL cAVIc -1 HpLME = Tq c@VHqLD est le poussé en avant de V c*HVL = V1 c*I ! !u M + V2 c*I ! !v M = V1 cu + V2 cv " a : Iö &, aHtL = cHgHtLL = cHuHtL, vHtLL , c*HVL HpL = c*HVL HaHtLL = a' HtL = HuÎgL' HtL Icu gHtL M + HuÎgL' HtL Icv gHtL M Produit extérieur [3] E , F espaces vectoriels, w : E kö # est une forme k - linéaire, sk le groupe de permutation de 81, ..., k< " s œ sk , wHxsH1L , ..., xsHkL L = es wHx1, ..., xkL ï w est antisymétrique " Hx1, ..., xkL œ E k , $ i " j xi = x j ï wHx1, ..., xkL = 0 ï w est alternée w alternée ó w antisymétrique fl k E * est l' ensemble des formes k - linéaire alternées fl 0 E * = # , fl 1 E * = E * = 'HE, #L et fl k E * est la k ième puissance extérieure de E * f : EöF est une application linéaire , a œ fl k F * ï f * : fl k F *ö fl k E * , f * a œ fl k E * est le tiré en arrière de a f * a : E kö #, f * aHx1, ..., xkL = aH f Hx1L, ..., f HxkLL Tirer en arrière des formes différentielles d'une surface régulière [3] U Õ !n , V Õ !m ouvert, p œ U Wk HUL = C ¶IU, fl k H!n L * M est l' espace des k - formes différentielles de U avec W0 HUL = C ¶HU, !L HeiLi base de !n , Hei * Li base de H!n L * et HeI * LIÕ81,...,n< base de fl k H!n L * f : UöV lisse, Dp f : Upö Vf HpL , IDp f M * : fl k H!mL *ö fl k H!n L * a œ Wk HVL ï f * : Wk HVLö Wk HUL, f * a œ Wk HUL est la tirée en arrière de a f * a : Uö fl k H!n L * , f * aHpL œ fl k H!n L * , f * aHpL = IDp f M * aH f HpLL ï f * aHpL : !n ä ...ä!nö!, f * aHpL Hx1, ..., xkL = aH f HpLLADp f Hx1L, ..., Dp f HxkLE & une surface régulière, p œ &, &p estson espace tangent en p , HU, jL est une carte de & en p , fl k T * & le fibré des k - formes alternées de & Dp j : &pö !jHpL 2 isométrie , IDp jM * : fl k I!jHpL 2 M *ö fl k &p * ïA IDp jM * E -1 : fl k &p *öfl k I!jHpL 2 M * ï GI&, fl k T * &M bijection Wk HUL , a # Ip # A IDp jM * E -1 aHpLM Vecteurs unitaires tangent et normal à la surface régulière [1] % Õ !2 ouvert, q œ % et p = cHqL c : %ö& Õ !3 , cHu, vL = Hx1Hu, vL, x2Hu, vL, x3Hu, vLL une surface locale injective régulière cU Hu, vL = cu °cu¥ Hu, vL est le champ de vecteur tangent unitaire dansla direction u cV Hu, vL = cv °cv¥ Hu, vL est le champ de vecteur tangent unitaire dansla direction v cNHu, vL = cuä cv °cuä cv¥ Hu, vL est le champ de vecteur unitaire normal à la surface !p 3 = &p$&p ¨ = VectH8cU , cV , cN 0, XHi, ixL = ix i , if i = 0, XHi, ixL = 0 RHi, ix , !r , rr , hrL : U Õ @0, 2 pD Õ !ö!, RHi, ix , !r , rr , hrL HuL = I1 + !r SinI Hu+H1-2 XHi,ixLL pL 2 M hr M + !r Sin rr i Ju+J p XHi,ixL ix NN 2 hr L'équation du profil rH!o, !a, !c , !d, ra, rb, rc , haL : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2 rH!o, !a, !c , !d, ra, rb, rc , haL Hu, vL = IrxH!o, !a, !c , !d, ra, rb, rc , haL Hu, vL, ryH!o, !a, !c , !d, ra, rb, rc , haL Hu, vLM rH!o, !a, !c , !d, ra, rb, rc , haL Hu, vL = Jv + !o !c SinHrc uL SinHrb vL, J1 + !oJ2 + CosJraJv + p ra NNN J1 + !d SinJHra !aL Jv + p ra NNha NNN L'équation totale de la robe cDIJT, !r, ia, ix a, ib, ix b, ic , ix c, !b, !o, !a, !c , !d, ra, rb, rc , ha, !r , rr , hr M : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 cDIJT, !r, ia, ix a, ib, ix b, ic , ix c, !b, !o, !a, !c , !d, ra, rb, rc , ha, !r , rr , hr M Hu, vL = IICosHJT vL ICosI!r v 4 M 8 HHia + 1L CosHuL RHia, ix a, !r , rr , hrL HuL + !b CosHHia + 1L uLL + SinI!r v 2 M 4 HHib + 1L CosHuL RHib, ix b, !r , rr , hrL HuL + !b CosHHib + 1L uLL + SinI!r v 4 M 8 HHic + 1L CosHuL RHic , ix c, !r , rr , hrL HuL + !b CosHHic + 1L uLLM - SinHJT vL ICosI!r v 4 M 8 HHia + 1L SinHuL RHia, ix a, !r , rr , hrL HuL + !b SinHHia + 1L uLL + SinI!r v 2 M 4 HHib + 1L SinHuL RHib, ix b, !r , rr , hrL HuL + !b SinHHib + 1L uLL + SinI!r v 4 M 8 HHic + 1L SinHuL RHic , ix c, !r , rr , hrL HuL + !b SinHHic + 1L uLLMM ryH!o, !a, !c , !d, ra, rb, rc , haL Hu, vL, ICosHJT vL ICosI!r v 4 M 8 HHia + 1L SinHuL RHia, ix a, !r , rr , hrL HuL + !b SinHHia + 1L uLL + SinI!r v 2 M 4 HHib + 1L SinHuL RHib, ix b, !r , rr , hrL HuL + !b SinHHib + 1L uLL + SinI!r v 4 M 8 HHic + 1L SinHuL RHic , ix c, !r , rr , hrL HuL + !b SinHHic + 1L uLLM + SinHJT vL ICosI!r v 4 M 8 HHia + 1L CosHuL RHia, ix a, !r , rr , hrL HuL + !b CosHHia + 1L uLL + SinI!r v 2 M 4 HHib + 1L CosHuL RHib, ix b, !r , rr , hrL HuL + !b CosHHib + 1L uLL + SinI!r v 4 M 8 HHic + 1L CosHuL RHic , ix c, !r , rr , hrL HuL + !b CosHHic + 1L uLLMM ryH!o, !a, !c , !d, ra, rb, rc , haL Hu, vL, Hia + ib + ic + 1L rxH!o, !a, !c , !d, ra, rb, rc , haL Hu, vLM 174 | Les paramètres de l'option choisie pour la surface de la robe JT = 0.3, !r = 1, ia = 0, ix a = 1, ib = 3, ix b = 1, ic = 2, ix c = 2, !b = 0.08, !o = 1, !a = 0.9, !c = -0.6, !d = 0.3, ra = 2.5, rb = 2.9, rc = 2, ha = 2, !r = 0.11, rr = 1, hr = 2 cc , b : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 b est la surface d ' une spline bicubique cc = cDIJT, !r, ia, ix a, ib, ix b, ic , ix c, !b, !o, !a, !c , !d, ra, rb, rc , ha, !r , rr , hr M Vcc, b : H% Õ @0, 2 pDä@0, 2 pDLä@0, 1D Õ !3ö!3 Vcc, bHu, v, tL = ccHu - HJT vL , vL + t HbHu, vL - ccHu - HJT vL , vLL est l' homotopie entre cc et b cHu, vL = Vcc, bIu, v, 7 10 M est la surface déformée "adapté" Représentation de la surface adapté à l'aide de l'homotopie | 175ü 6.3.3.3. Courbes intégrales et systèmes dynamiques L'étude des champs de vecteurs nous amène naturellement à l'étude de flot et des courbes intégrales et des systèmes dynamiques continus par la suite. Donc, nous commençons par définir la notion de courbe intégrale et le flot d'un champ de vecteurs, puis plus tard, nous allons examiner certains systèmes dynamiques du plan et leur poussé en avant sur une surface régulière. Représentation d'un système dynamique (flot d'un champ de vecteurs dans !2 ) Courbe intégrale d'un champ de vecteurs [3] & surface régulière, V œ GH&, T&L est un champ de vecteurs tangent de & I Õ ! ouvert, a : Iö & " t œ I, a' HtL = VHaHtLL ï HI, aL est appelée la courbe intégrale deV si 0 œ I et aH0L = p ï HI, aL est d ' origine p , Ip est l' intervalle de vie de p et apHtL est la courbe intégrale si & est compacte le champ de vecteurs est complet et Ip = ! Flot d'un champ de vecteurs [3] & surface régulière, V œ GH&, T&L est un champ de vecteurs tangent & W = 9Ht, pL œ !ä&, t œ Ip= Hetsi V est complet W = !ä&L , F : W ö &, F Ht, pL = apHtL est une application lisse " t œ !, Wt = 9p œ & t œ Ip= , Ft : Wtö &, FtHpL = apHtL est appelée le flot de V ï " p œ Wt Õ &, Ft=0HpL = p , Ft+s HpL = FtÎFsHpL et Tp Ft@VHpLD = V@FtHpLD c : % Õ !2ö& surface locale réguliere, V est un champ de vecteurs tangent de % ï c*HVL œ GH&, T&L un champ de vecteur de tangente de & , si Ft est le flot de V ï cÎFtÎ c -1 est le flot de c*HVL Maintenant, nous allons étudier certains des systèmes dynamiques du plan, puis nous allons utiliser le poussé en avant pour le flot du champ de vecteurs d'une surface régulière. Système dynamique comme le flot d'un champ de vecteurs [5] F est un champ de vecteurs sur U Õ !n , " x œ !n , FHxL = H f1HxL, ..., fnHxLL est C k Hk ¥ 1L d x d t = FHxL , est le système différentiel d xi d t = fiHxL for i = 1, ..., n le flot F Ht, xL est la solution de d x d t = FHxL qui dépend de la condition initiale x telle que Ft=0HxL = x , Ft+s HxL = FtÎFsHxL est un système dynamique continu sur U Õ !n un point fixe est le point x œ !n FHxL = 0 Hi.e. le champ de vecteurs est nul en xL si le système estsousla forme d x d t = FHxL = A.x avec A œ MnH#L il est appelé un système dynamique linéaire ï FtHxL = ‰t A .x0 est le flot de F, axHtL = FtHxL = xHtL est la courbe intégrale et 0# n est le seul point fixe où ‰ t A = ⁄k¥0 t k A k k! 176 | Système dynamique du plan [5] V est un champ de vecteurs sur % Õ !2 , " q œ % , VHu, vL = HV1Hu, vL, V2Hu, vLL le système est d u d t = V1Hu, vL , d v d t = V2Hu, vL le flot F Ht, qL est la solution du système, F Ht, qL = gqHtL est une courbe intégrale de V si le système est linéaire, il est dans cette forme d u d t d v d t = a11 a12 a21 a22 u v , avec a11 a12 a21 a22 = A œ M2H!L dans ce cas, le seul point fixe est H0, 0L la nature de ce point fixe est déterminée par les valeurs propres de A cas : l1, l2 œ !, l1 " l2 " 0 l1, l2 > 0ïH0, 0L est répulsif , l1, l2 < 0 ïH0, 0L est attractif , l1 < 0, l2 > 0ïH0, 0L est col cas : l1 = l2 ReHl1L = ReHl2L = 0ïH0, 0L est centre ReHlL > 0ïH0, 0L est foyer répulsif, ReHlL < 0ïH0, 0L est foyer attractif Le flot de poussé en avant d'un champ de vecteurs linéaire % Õ @-p, pDä@-p, pD et cH%L = & sont des surfaces régulières, c : % Õ !2ö& Õ !3 , cHu, vL = ICosHu + pL SinI Hv+pL 2 M, SinHu + pL SinI Hv+pL 2 M, 1 - CosI Hv+pL 2 MM V = V1 ! !u + V2 ! !v est champ de vecteurs de % ï c*HVL = V1 cu + V2 cv est champ de vecteurs de & le système différentiel est d u d t d v d t = vHtL -uHtL est un système dynamique linéaire g : Iö %, gHtL = HuHtL, vHtLL VHqL = VHgHtLL = g' HtL ï gHtL = YtHu, vL = HuHtL, vHtLL = Hu0 CosHtL + v0 SinHtL, v0 CosHtL - u0 SinHtLL est le flot de V a : Iö &, aHtL = cHgHtLL = cHuHtL, vHtLL c*HVL HpL = c*HVL HaHtLL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL ï aHtL = FtHcHu, vLL = cÎYtÎ c -1 HcHu, vLL = cÎYtHu, vL = cHgHtLL = cHuHtL, vHtLL est le flot de c*HVL aHtL = I-CosHu0 CosHtL + v0 SinHtLL SinI 1 2 Hp + v0 CosHtL - u0 SinHtLLM, -SinI 1 2 Hp + v0 CosHtL - u0 SinHtLLM SinHu0 CosHtL + v0 SinHtLL, 1 - CosI 1 2 Hp + v0 CosHtL - u0 SinHtLLMM Représentation du flot d'un champ de vecteurs linéaire du plan et son poussé en avant dans la surface | 177Le flot de poussé en avant d'un champ de vecteurs non linéaire % Õ @-p, pDä@-p, pD et cH%L = & sont des surfaces régulières, c : % Õ !2ö& Õ !3 , cHu, vL = ICosHu + pL SinI Hv+pL 2 M, SinHu + pL SinI Hv+pL 2 M, 1 - CosI Hv+pL 2 MM V = V1 ! !u +V2 ! !v est champ de vecteurs de % ï c*HVL = V1 cu + V2 cv est champ de vecteurs de & le système différentiel est d u d t d v d t = -uHtL vHtL + u 2 HtL est un système dynamique non linéaire g : Iö %, gHtL = HuHtL, vHtLL VHqL = VHgHtLL = g' HtL ï gHtL = YtHu, vL = HuHtL, vHtLL = Ju0 ‰ -t , Jv0 + u0 2 3 N ‰ t - J u0 2 3 N ‰ -2 t N est le flot de V a : Iö &, aHtL = cHgHtLL = cHuHtL, vHtLL c*HVL HpL = c*HVL HaHtLL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL ï aHtL = FtHcHu, vLL = cHgHtLL est le flot de c*HVL aHtL = J-CosHu0 ‰ -t L SinJ 1 2 Jp + Jv0 + u0 2 3 N ‰ t - J u0 2 3 N ‰ -2 t NN, -SinHu0 ‰ -t L SinJ 1 2 Jp + Jv0 + u0 2 3 N ‰ t - J u0 2 3 N ‰ -2 t NN, 1 - CosJ 1 2 Jp + Jv0 + u0 2 3 N ‰ t - J u0 2 3 N ‰ -2 t NNN Représentation du flot d'un champ de vecteurs non linéaire du plan et son poussé en avant sur la surface La courbe intégrale d'un champ de vecteur d'une surface peut être utilisé comme un outil de conception, car après tout, c'est une courbe paramétrique dont la trace se trouve sur la surface qui permet toutes les opérations que nous avons définies sur les courbes régulières. Maintenant, en utilisant une surface et un système dynamique linéaire que nous avons défini plus tôt, nous nous allons concevoir une homotopie de la courbe intégrale. 178 | ü 6.3.3.4. Conception en utilisant des courbes intégrales La courbe intégrale aHtL = I-CosHu0 CosHtL + v0 SinHtLL I1 + SinHv0 CosHtL - u0 SinHtLL2 M I1 - 1 p I-p + 9 10 Hp + v0 CosHtL - u0 SinHtLLM SinH2 Hp + u0 CosHtL + v0 SinHtLLL4 M, -I1 + SinHv0 CosHtL - u0 SinHtLL2 M SinHu0 CosHtL + v0 SinHtLL I1 - 1 p I-p + 9 10 Hp + v0 CosHtL - u0 SinHtLLM SinH2 Hp + u0 CosHtL + v0 SinHtLLL4 M, 2 Hp + v0 CosHtL - u0 SinHtL + SinHv0 CosHtL - u0 SinHtLLLM L'homotopie Le champ de vecteurs normal défini sur cette courbe nous donne l' homotopie N LaHt, uL = aHtL + u †rKHtL§ NHtL Représentation d'une homotopie entre une courbe intégrale et la courbe définie par sa normale et sa courbure | 179ü 6.3.3.5. Métrique riemannienne sur une surface régulière Nous commençons par définir la distance infinitésimale qui définit la métrique riemannienne (soit la première forme fondamentale) sur une surface régulière (comme une image d’une surface locale régulière injective). Géométriquement d s peut être interprété comme la distance infinitésimale d’un point cHu, vL à cHu + d u , v + d vL mesurée le long la surface, De même, nous allons définir l’aire de la surface courbe en utilisant la même logique de la distance courbe. Ces analyses serait la deuxième analyse, nous réalisons sur notre surface régulière, il nous donne des informations comme l’aire de la surface, mais aussi des informations sur la courbe se situant dans la surface. Cet outil est d’être en mesure d’envoyer des courbes planes du plan à une surface régulière, il offre beaucoup de possibilités de conception pour les architectes intéressés dans la conception sur des toits ou des façades incurvées. Depuis que nous avons défini plus haut nos surfaces comme des variétés différentiables de deux dimensions en utilisant le paramétrage local et les cartes, la métrique riemannienne décrit les distances et les aires dans chaque carte locale, et cette surface a alors la structure d’une variété riemannienne de dimension deux. Chaque sous-variété lisse de !n a une métrique riemannienne induite g sur chaque espace tangent qui est une restriction du produit scalaire de !n , qui est un H0, 2L tenseur défini positif. Dans chaque carte locale une métrique riemannienne est donnée par l’attribution d’une matrice 2ä2 définie positive à chaque point; quand une carte différente est adoptée, la matrice est transformée selon la matrice jacobienne du changement de coordonnées. Une variété riemannienne connexe porte la structure d’un espace métrique dont la fonction de la distance est la longueur de l’arc d’une géodésique minimisante. Variété riemannienne [6] & variété lisse, p œ &, gp est un produit scalaire sur son espace tangent &p X, Y œ GH&, T&L sont des champs de vecteurs tangents de & , gp : &p ä&pö ! p # gpHXHpL, YHpLL fonction lisse ï H&, gL variété riemannienne et la famille gp de produits scalaires est appelé une métrique riemannienne Métrique riemannienne [6] c : %ö& une surface locale sur la surface régulière , U Õ & ouvert, p œ U Hu, vLsystème de coordonnées de % ïH#u, #vL est une base de vecteurs tangents à % et Hd u, d vL est la base duale Hx1, x2L est un système de coordonnées sur & ïH# x1, # x2L est une base de vecteurs tangents à & and Hd x1, d x2L est la base duale g œ GI&, T *  M est le tenseur métrique g = ⁄i, j gi j d xi%d x j = g1,1 Hd x1L 2 + 2 g1,2 d x1 d x2 + g2,2Hd x2L 2 = Hd sL 2 " p œ U, gi j = gI# xi , # x j M = Y# xi , # x j] = pour i, j = 1, 2 est la componant du tenseur métrique c * : W2 H&L ö W2 H%L, c * g est la tirée en arrière de g, c * g œ W2 H%L , c * g : %öT * %#2 c * gHqL œ T * %#2 , où q œ %, #u, #v œ %q c * gHqL : %q ä%qö !, c * gHpL H#u, #vL = gHcHqLLADq cH#uL, Dq cH#vLE = gHpL Hc*H#uL, c*H#vLL où # x1 = c*H#uL = cu et # x2 = c*H#vL = cv ï g1,1 Î c = E, g1,2 Î c = g2,1 Î c = F, g2,2 Î c = G c * g = c* Ag1,1Hd x1L 2 + 2 g1,2 d x1 d x2 + g2,2Hd x2L 2 E = EHd uL 2 + 2 F d u d v + GHd vL 2 si U Õ !n , H#u1, ..., #unL est le repère naturel i.e. #ui = ei = H0, ..., 1, ..., 0L avec 1 à la i ème position ï gp : Up äUpö !, I⁄i ai #ui , ⁄j bj #uj M # ⁄i ai bi ï gp = Yei , e j] = di j la métrique riemannienne est la métrique euclidienne canonique Les coefficients de la première forme fondamentale [1] E, F, G : !nö ! , E = °cu¥ 2 , F = Xcu, cv\ , G = °cv¥ 2 et la matrice E F F G est définie positive 180 | La distance infinitismal (i.e. la première forme fondamentale) [1] c : %ö !n a patch , Hd sL 2 = E Hd uL 2 + 2 F Hd uL Hd vL + G Hd vL 2 est la première forme fondamentale a : Ha, bLö!n a curve whose trace lies on the trace cH%L , aHtL = cHuHtL, vHtLL et d s d t = E I d u d t M 2 + 2 F I d u d t M I d v d t M + G I d v d t M 2 sHtL = Ÿc t E I d u d t M 2 + 2 F I d u d t M I d v d t M + G I d v d t M 2 „t est la fonction de longueur de l' arc de a à partir de aHcL L’aire infinitismal [1] d V = d x1Ô ...Ôd xn est l' élément volume infinitésimal de !n , d A = E G - F 2 d u ä d v , où E G - F 2 = °cu ä cv¥ = °cu¥ °cv¥ sinq est l' aire du parallélogramme engendré par °cu¥ et °cv¥ c : %ö !n une surface locale injective régulière , AHcH%LL = Ÿ& E G - F 2 d u ä d v est l' aire de cH%L Variété riemannienne comme espace métrique [6] H&, gL variété riemannienne, p, q œ & c : Ha, bLö& une courbe dans & ï La b HcL := Ÿa b gHc' HtL, c' HtLL d t = Ÿa b °c' HtL¥ d t avec un changement de variables nous paramétrer c parsa longueur de l' arc i.e. " t œ Ha, bL, °c' HtL¥ = 1 d : &ä&ö!+ , dHp, qL = inf LHgL est la borne inférieure sur toutesles courbes différentiables g à partir de p et finissant à q Connexion sur une surface régulière [6] & une surface régulière, une connexion ou dérivée covariante sur & est l' application D : GH&, T&Lä GH&, T&Lö GH&, T&L " X, Y, Z œ GH&, T&L , f , g œ C ¶H&, !L DX : GH&, T&Lö GH&, T&L Df X+ g Y = f DX + g DY , DX HY + ZL = DX Y + DX Z , DX H f YL = X@ f D Y + f DX Y avec le système de coordonnées de & est Hx1, x2L , Y = Y1 # x1 + Y2 # x2ï DX Y = X@Y1D # x1 + X@Y2D # x2 Champ de vecteurs le long d’une courbe dans une surface régulière [6] & une surface régulière, X, Y, Z œ GH&, T&L , I Õ ! ouvert, a : Iö & une courbe intégrale de X a' HtL = XHaHtLL, YHaHtLL = ZHaHtLLï DX YHaHtLL = DX ZHaHtLL V est un champ de vecteursle long a si " t œ I , VHtL œ &aHtL si a : Iö & est une courbe régulière injective ï V ' HtL = Da' HtL V , où V HaHtLL = VHtL Symboles de Christoffel [6] & une surface régulière Hmuni d ' une métrique riemannienneL, D estsa connexion riemannienne, Hx1, x2L estson système de coordonnées ï Gi j k = d xk ID!xi # x j M pour i, j, k = 1, 2 sont lessymboles de Cristoffel D par rapport à Hx1, x2L ï D!xi # x j = Gi j 1 # x1 + Gi j 2 # x2 où Gi j k = Gj i k c : %ö !n une surface locale régulière, alorslessymboles de Christoffel Gi j k pour i, j, k = 1, 2 correspondants à c sont définis par G1,1 1 = G Eu -2 F Fu+F Ev 2 IE G-F 2 M , G1,2 1 = G Ev - F Gu 2 IE G-F 2 M , G2,2 1 = 2 G Fv -G Gu-F Gv 2 IE G-F 2 M G1,1 2 = 2 E Fu -E Ev-F Eu 2 IE G-F 2 M , G1,2 2 = E Gu - F Ev 2 IE G-F 2 M , G2,2 2 = E Gv -2 F Fv+F Gu 2 IE G-F 2 M avec G1,2 1 = G2,1 1 and G1,2 2 = G2,1 2 | 181Maintenant, nous démontrons le contrôle de la forme à l’aide de notre deuxième analyse, à savoir donner l’aire de la surface, la longueur de la courbe entre deux points quelconques sur la surface et le traçage de la courbe qui se trouvant sur la surface. Deuxième analyse d’une surface régulière L’équation de la surface de base est donnée par c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 c1Hu, vL = 3 2 ICosHuL + 5 2 CosI u 2 M 8 M I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM c2Hu, vL = 3 SinHuL I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM c3Hu, vL = v - SinHvL, cHu, vL = Hc1Hu, vL, c2Hu, vL, c3Hu, vLL l’équation de la courbe plane dont la trace se situe dans le domaine q1, q2 œ %, q1 = I 2 3 p, pM and q2 = I 3 2 p, 3 2 pM g : U Õ @0, 2 pD Õ !ö!2 , gHtL = q1 + t 2 p Hq2 - q1L = HuHtL, vHtLL = I 2 p 3 + 5 t 12 , p + t 4 M , where d u d t = 5 12 , d v d t = 1 4 l’équation de la courbe a dont la trace se trouve dans la surface a : U Õ @0, 2 pD Õ !ö!3 , aHtL = HcÎgL HtL = cHuHtL, vHtLL = Ha1HtL, a2HtL, a3HtLL a1HtL = c1HuHtL, vHtLL = 3 2 I2 + 7 20 CosI 1 2 Ip + t 4 MMM J1 - CosI 1 2 Ip + t 4 MM6 + SinI 1 2 Ip + t 4 MMN J 5 2 CosI 1 2 I 2 p 3 + 5 t 12 MM8 - SinI p 6 + 5 t 12 MN a2HtL = c2HuHtL, vHtLL = 3 I2 + 7 20 CosI 1 2 Ip + t 4 MMM CosI p 6 + 5 t 12 M J1 - CosI 1 2 Ip + t 4 MM6 + SinI 1 2 Ip + t 4 MMN a3HtL = c3HuHtL, vHtLL = p + t 4 + SinI t 4 M aH0L = cHq1L = cHuH0L, vH0LL = p1 and aH2 pL = cHq2L = cHuH2 pL, vH2 pLL = p2 " t œ U , a' HtL = HcÎgL' HtL = cuHuHtL, vHtLL I d u d t M + cvHuHtL, vHtLL I d u d t M = HHcÎgL1 ç HtL, HcÎgL2 ç HtL, HcÎgL3 ç HtLL la longueur de l’arc entre p1 et p2 dans la surface E, F, G : !3ö!, E = °cu¥ 2 , F = Xcu, cv\ , G = °cv¥ 2 d s d t = E I d u d t M 2 + F I d u d t M I d v d t M + G I d v d t M 2 est la première forme fondamentale SHtL = Ÿc t E I d u d t M 2 + F I d u d t M I d v d t M + G I d v d t M 2 est la fonction de longueur de l' arc de a SH2 pL = 23.298 est la longueur de l' arc de a à partir de aH0L = p1 et finissant à aH2 pL = p2 L’aire de la surface Ac@Hu0, v0L, Hun, vnLD = Ÿv0 vn Ÿu0 un E G - F 2 d u ä d v est la fonction de l' aire de c Ac@H0, 0L, H2 p, 2 pLD = 1213 est l' aire de c à partir de cH0, 0L et finissant à cH2 p, 2 pL Représentation de la courbe entre deux points sur une surface régulière 182 | ü 6.3.3.6. Conception en utilisant la métrique riemannienne Exemple de conception en utilisant la longueur de l’arc d’une courbe dans une surface régulière L’équation de la courbe a dont la trace se situe dans la surface j : U Õ @0, 2 pD Õ !ö!3 , jHtL = HcÎgL HtL = cHuHtL, vHtLL jHtL = I-CosHCosHtLL SinI 1 2 I 6 p 5 + SinHtLMM, -SinHCosHtLL SinI 1 2 I 6 p 5 + SinHtLMM, 1 - CosI 1 2 I 6 p 5 + SinHtLMMM SH2 pL = 4.375 est la longueur de l' arc de j à partir de jH0L et finissant à jH2 pL N LjHt, uL = jHtL + u SHtL NHtL est le champ de vecteurs normal défini sur cette courbe Représentation de l’envoi d’une courbe du plan à une surface régulière Représentation d’une conception utilisant une courbe dans la surface et son champ de vecteurs normal | 183Exemple de conception utilisant l’aire de la surface Dans l’exemple suivant, nous allons montrer le calcul d’aire peut être utilisé comme un outil de conception, à savoir dans la conception de la tour ci-dessous, l’aire de chaque plancher horizontal détermine la hauteur du plafond au-dessus de lui. Ceci à son tour détermine la taille des ouvertures, ce qui permet par exemple lumière d’atteindre plus profondément dans le plancher avec des aires supérieures. Représentation de la variation des hauteurs de plafond en fonction de la superficie de chaque étage Maintenant que nous avons créé une variation de la hauteur du plafond à chaque étage porportional à la superficie de chaque étage (plafond plus haut pour une aire plus grande), nous allons de manière similaire créer des variations dans la taille des ouvertures en porportion à l’hauteur du plafond. Représentation de la variation de la taille des ouvertures à chaque étage en fonction des aires 184 | ü 6.3.3.7. Volume contenu par une surface régulière Après le calcul de l’aire d’une surface régulière en intégrant d A = E G - F 2 d uÔd v qui est une forme différentielle (donnée localement dans la carte Hx1, x2L et la base d uÔd v = c* Hd x1Ôd x2L où Hd x1, d x2L est le repère pour T * & ). Cette forme différentielle est de même degré que la dimension de la variété à savoir de degré deux. Cette forme différentielle est appelé une forme de volume puisqu’elle n’est jamais nulle sur la variété et son degré est égale à la dimension de la variété, donc du point de vue de la variété, le volume est l’intégration de la forme de volume. En d’autres termes, puisque la surface est une variété de deux dimensions ce que nous appelons l’aire est essentiellement le volume de la surface, mais dans l’architecture, nous sommes également intéressés au volume dans !3 contenue par le plongement de la variété dans !3 Dans cette perspective, nous allons traiter la surface comme une application de deux variables avec son image dans !3 , et calculer le volume de solide contenue par cette surface à l’aide des techniques usuelles de changement des variables dans !3 (coordonnées polaires, sphériques et cylindriques). En plus du changement de variables, nous allons utiliser aussi la technique de balayage volumétrique, qui est simplement calculer l’aire de la surface plane obtenue en coupant le volume par un plan, puis l’intégration de cette aire en tant que fonction réelle le long de direction de la hauteur. Ce volume contenu par la surface est la troisième analyse, nous allons faire sur une surface régulière, son application dans l’architecture est tout à fait clair. Dans cette recherche, nous allons montrer un exemple comment le calcul du volume peut être utilisé en combinaison avec le calcul de l’aire comme un outil pour tester l’aptitude de certaines variations d’une surface donnée dans un algorithme d’optimisation. Par exemple, étant donné un grand espace de variations d’une surface, nous aimerions trouver ceux avec un plus grand rapport volume / surface en d’autres termes, nous essayons de s’approcher de la sphère algorithmiquement. Représentation du volume du cylindre | 185s-algèbre (tribu) [7] E un ensemble non vide, $ , C sont des classes des parties de E, $ est une s - algèbre HtribuLsi f œ $ , si A œ $ïA c œ $ etsi HAnLn¥0 une suite d ' éléments de $ ï‹n¥0 An œ $ sHCL = ›CÕ! $ est la tribu engendrée, etsi C = 8Ha, bL ouvert -¶ < a § b < ¶ , a, b œ !<ï sHCL = +H!L est la tribu borélienne % est une topologie si f, E œ %, si HOnLn¥0 une suite d ' éléments de % ï‹n¥0On œ % etsi HOnL0§n¥N une suite d ' éléments de % ï›0§n¥N On œ % dans un espace topologique HE, %L la tribu borélienne +H%L = sH%L Fonctions mesurables et boréliennes [7] f : HE, $Lö HF, +L est mesurableó " B œ + , f -1 HBL Õ $ , f : HE, $Lö HE1 ä ...äEn, $1% ....%$nL, xö H f1HxL, ..., fnHxLL est mesurable ó " i œ 1, ..., n , fi : HE, $Lö HEi , $iL est mesurable f : HE1 ä ...äEn, $1% ....%$nLö H!, +H!LL, Hx1, ..., xnLö f Hx1, ..., xnL est mesurable ó " i œ 1, ..., n , fi : HEi , $iLö H!, +H!LL est mesurable f : HE, $Lö H!, +H!LL est mesurable ó " a œ ! , f -1 HHa, ¶LL = 8 f > a< Õ $ f : HE, %Lö HF, #L est continue, +H%L = sH%L ï f est borélienne f : HE, +H%LLö HF, +H#LL est mesurable Mesure de Lebesgue et fonction l-intégrable [7] E un ensemble non vide, $ une tribu m : HE, $Lö@0, ¶D, A œ $ömHAL mHfL = 0 et HAnLn¥1 suite d ' éléments 2 à 2 disjoints, mH⁄n¥1 AnL = ⁄n¥1mHAnL ï m est une mesure positive et pour f : HE, $, mLö I!+ , +H!+ LM mesurable ï mHAL = ŸA f ,m l : H!, +H!LLö@0, ¶D " B œ +H!L, " x œ !, lHBL = lHx + BL, lH@a, bDL = b - a et lH8a det H cu c Nc L det Hc ww Nw L det Hws c Nw L , soit YHtL = uHtL vHtL sHtL wHtL et Y0 = u0 v0 s0 w0 ïY ' HtL = FHYHtLL et YH0L = Y0 système de équations différentielles ordinaires avec le problème de la valeur initiale ï d u d t d v d t d s d t d w d t = f1 Hu HtL, v HtL, sHtL, w HtLL f2 Hu HtL, v HtL, sHtL, w HtLL f3 Hu HtL, v HtL, sHtL, w HtLL f4 Hu HtL, v HtL, sHtL, w HtLL = det HcHuHtL, vHtL,sHtL, wHtLL cvHuHtL, vHtLL NcHuHtL, vHtLLL det H cuHuHtL, vHtLL c HuHtL, vHtL,sHtL, wHtLL Nc HuHtL, vHtLL L det Hc HuHtL, vHtL,sHtL, wHtLL wwHsHtL, wHtLL NwHsHtL, wHtLL L det HwsHsHtL, wHtLL c HuHtL, vHtL,sHtL, wHtLL Nw HsHtL, wHtLLL | 205Courbe d’intersection entre une sphère et un tore Les équations des surfaces de base sont donnés par c, w : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 cHu, vL = ISinI v 2 M CosHuL, SinI v 2 M SinHuL, CosI v 2 MM wHs, wL = KCosHsL I1 + CosHwL 2 M + K 2+ 3 2 O, I1 + CosHwL 2 M SinHsL, SinHwL 2 O nous devons trouver le point de départ de la courbe d ' intersection i.e. q1 = Hu0, v0L et q2 = Hs0, w0L cHu0, v0L = wHs0, w0L si u0 = 0 ets0 = p ï les courbes de paramètres cHu0, vL et wHs0, wLse coupent en hauteur = 1 2 en utilisant des fonctions inverses nous sommes en mesure de trouver v0 et w0 Y ' HtL = FHYHtLL et YH0L = Y0 ï YHtL = HuHtL, vHtL, sHtL, wHtLL les équations des des courbes planes g et b dont les traces se situe dans les domaines %Õ@0, 2 pDä@0, 2 pD Hu0, v0L œ %, Hu0, v0L = H0, 2.0944L , g : U Õ @0, 2 pD Õ !ö!2 , gHtL = HuHtL, vHtLL Hs0, w0L œ %, Hs0, w0L = Ip, p 2 M , b : U Õ @0, 2 pD Õ !ö!2 , bHtL = HuHtL, vHtLL les équations de la courbe d’intersection de la surface sont aHtL = cHuHtL, vHtLL = wHsHtL, wHtLL Représentation de la courbe d’intersection de deux surfaces régulières 206 | ü 6.3.3.14. Conception en utilisant l’intersection entre les surfaces régulières Maintenant que nous avons défini l’intersection de surfaces paramétriques, nous allons montrer comment ces intersections peuvent être utiles du point de vue de la conception architecturale. Dans cet exemple, on montre que la forme des ouvertures dans la peau d’un bâtiment peut être déterminée par la courbe résultant de l’intersection d’une surface cylindrique avec la surface principale de la forme. Cette surface cylindrique est réalisé en extrudant une courbe dans l’espace tangent à la surface principale en un point donné le long de la normale en ce point; outre on peut faire varier le rayon de la base du cylindre en le définissant comme une fonction de la distance entre le point donné et un autre objet. Représentation d’une courbe d’intersection comme le contour de la forme de l’ouverture et ses variations Représentation des ouvertures dans la peau du bâtiment basées sur des courbes d’intersection | 207ü 6.3.4. Surfaces spéciales ü 6.3.4.1. Surfaces non orientables Maintenant, nous allons définir une famille importante des surfaces ce sont les surfaces non orientables. Représentation des surfaces non orientables Orientation d’un espace vectoriel [3] E espace vectorie dim E < ¶ , E a deux classes d ' équivalence d ' orientation surses bases B, B' œ 8bases de E< , B équivalente à B' ó det MB B' > 0 , où MB B' est la matrice de changement de base !n admet une orientation canonique avec la base canonique, qui est dansle sens direct f : U Õ !nö V Õ !n difféomorphisme, f préserve l' orientation si detJacx f > 0 , pour x œ U Orientation d’une variété [3] & variété différentiable, 8HUi , jiL< atlas de & est orientable si " i, j detJacx jjÎji -1 > 0 , pour x œ ji IUi › Uj M & variété différentiable est orientable sison atlas maximal est orientable IOpM pœ# famille d ' orientations de l' espace tangent &p , Op est continue si " p œ Ui , dp ji : &pö !n préserve l' orientation & variété différentiable est orientable ó IOpM pœ# est une famille continue Orientation des surfaces régulières [1] & Õ !3 surface régulière, & est orientable ó $ une application continue U : &ö &p ¨ , p # UHpL où UHpL est un vecteur normal unitaire à & en point p si & est la trace d ' une surface locale injective régulière ï & est orientable si & est une surface orientable connexe ï & a exactement deux vecteurs normal unitaires définis globalement 208 | Ruban de Mobius et la bouteille de Klein [3] M le ruban de Möbius est construit comme le quotient !2 ë% par l' action de groupe %ä !2 ö !2 , Hk, Hu, vLL = k.Hu, vL = Iu + k, H-1L k vM K la bouteille de Klein est construit comme le quotient de !2 ë%2 par l' action de groupe %2 ä !2 ö !2 , HHk, lL, Hu, vLL = Hk, lL.Hu, vL = Iu + k, H-1L k v + lM nous pouvons construire un plongement du ruban de Möbius et une immersion de la bouteille de Klein dans !3 by the parametrizations cM : !2ö!3 , cM Hu, vL = II1 + 2 p + Hv - pL CosI u 2 MM CosHuL, I1 + 2 p + Hv - pL CosI u 2 MM SinHuL, Hv - pL SinI u 2 MM cK : !2ö!3 , cKHu, vL = ICosHuL Ip - CosI u 2 M CosHvL - SinI u 2 M SinH2 Hv - pLLM, SinHuL Ip - CosI u 2 M CosHvL - SinI u 2 M SinH2 Hv - pLLM, -CosHvL SinI u 2 M + CosI u 2 M SinH2 Hv - pLLM Représentation du ruban de Möbius montrant la famille non continue d’orientations IOpM pœM Représentation de la bouteille de Klein montrant son non orientabilité et un ruban de Möbius dedans | 209ü 6.3.4.2. Conception en utilisant des surfaces non orientables Maintenant, nous allons montrer un exemple d’une conception architecturale basée sur une surface non orientable. Dans cet exemple, nous allons utiliser le plongement du ruban de Möbius dans !3 , cela peut entraîner dans de nombreuses applications architecturales. À savoir que la distinction entre l’extérieur et l’intérieur du bâtiment n’est plus là, qui donne lieu à un jeu beaucoup plus riche entre le sentiment d’être à l’intérieur ou à l’extérieur. Représentation de la conception d’un ruban de Möbius plié plusieurs fois sur lui-même Représentation d’une conception architecturale utilisant le ruban de Möbius 210 | ü 6.3.4.3. Surfaces réglées et développables Avec ces définitions des courbes asymptotiques nous allons maintenant définir les surfaces réglées et développables, comme nous l’avons mentionné plus tôt, ils sont d’une importance particulière pour la conception architecturale parce qu’elles contiennent des lignes droites qui rend la réalisation de ces formes plus facile. Par exemple, la tangente développable à une hélice peut être construit à partir d’une feuille de papier en découpant un disque et tournant la partie restante autour d’un cylindre. Représentation de la construction d’une surfaces réglée Surfaces réglée [1] & Õ !3 surface régulière, a, g : Ha, bL Õ !ö!3 avec a' " 0 , c : %ö&, cHu, vL = aHuL + v gHuL est la paramétrisation de & c est une surface locale réglée, a est la courbe de base directrice et g est la courbe génératrice Hvecteur directeurL v # cHu0, vL = aHu0L + v gHu0L sont leslignes droites dirigeantesHi.e. des courbes asymptotiquesL & a deux surfaces locales réglées distinctes sur elle ï & est doublement réglées & est une surface réglée ï " p œ & , .HpL la courbure gaussienne est non positives | 211Il existe deux formes extrêmes des surfaces réglées: les surfaces réglées planes et les surfaces réglées non cylindriques. Les surfaces réglées planes sont celle qui ont une courbure gaussienne nulle (i.e. développables), géométriquement elles sont de trois types, la développable tangente, le cylindre et le cône; Surfaces réglée plane [1] & est une surface réglée , p, q œ !3 , a : Ha, bL Õ !ö!3 , c : %ö& , est la paramétrisation de & cHu, vL = aHuL + v a' HuL est la développable tangente cHu, vL = aHuL + v q est le cylindre généralisé cHu, vL = v a HuL + q le cône est généralisée & est une surface réglées plane ï g = 0 ï f = 0 et " p œ & , .HpL = 0 la courbure gaussienne est égale à zéro b : Hc, dL Õ !ö!3 , est une courbe de vitesse unitaire et cHu, vL = bHuL + v b' HuL est la tangente développable ï E = 1 + v 2 Kb 2 , F = 1 et G = 1 , le coefficient de la première forme fondamentale dépend uniquement de la courbure de b régularité c est une développable tangente alors est régulière partout sauf sur a Hoù a est une courbe régulière, KHaL " 0 L c est un cylindre généralisé alors est régulière partout tant que a'äq " 0 c est un cône généralisé alors est régulière partout tant que v a ä a' " 0 Surfaces réglées non cylindriques [1] & Õ !3 surface régulière , a, g : Ha, bL Õ !ö!3 avec a' " 0 , c : %ö&, cHu, vL = aHuL + v gHuL est la paramétrisation de& & est une surface réglées non cylindrique si g ä g' " 0 partout sur & Courbe de striction [1] c è Hu, vL = aHuL + v gHuL est une surface réglée non cylindrique et cHu, vL = sHuL + v dHuL est un reparamétrage où °d¥ = 1 et Xs', d'\ = 0 ï s est la courbe de striction de c è Hil ne dépend pas du choix de la courbe de baseL cHu, vL = sHuL + v dHuL est un reparamétrage où °d¥ = 1 ï c paramétrisation d ' une surface réglées plane telle que si s' HuL = 0 ï & est un cône si d' HuL = 0 ï & est un cylindre si s', d' " 0 ï & est une tangente développable Paramètre de distribution [1] cHu, vL = sHuL + v dHuL est une surface réglée non cylindrique ï p = Xs',däd'\ Xd',d'\ est le paramètre de distribution cHu, vL = sHuL + v dHuL est une surface réglée non cylindrique le long de v # v dHuL la courbure gaussienne .Hu, vL vض 0 .Hu, vL = 0 ó pHuL = 0 pHuL " 0 ï .Hu, vL est continue et †.Hu, vL§ assume son maximum à v = 0 c est une surface réglée ï c est régulière lorsque v " 0 ou lorsque v = 0 et pHuL " 0 la courbure gaussienne d ' une surface réglée est donnée par . = -pHuL IpHuL 2+v 2 M 2 212 | Surface réglée (développable) [1] L’équation de la surface réglée développable tangente est donnée par a : U Õ @0, 4 pD Õ !ö!3 , aHuL = ICosHuL, SinHuL, u 5 M c : % Õ @0, 4 pDä@0, 2D Õ !2ö!3 , cHu, vL = aHuL + v a' HuL °a' HuL¥ = JCosHuL - 3 v SinHuL 10 , 3 v CosHuL 10 + SinHuL, u 3 + v 10 N l’équation de la surface réglée cylindre généralisé est donnée par a : U Õ @0, 2 pD Õ !ö!3 , aHuL = H2 CosHuL, SinH2 uL, 0L , q = H1, 0, 1L c : % Õ @0, 2 pDä@0, 2D Õ !2ö!3 , cHu, vL = aHuL + v q = Hv + 2 CosHuL, SinH2 uL, vL l’équation de la surface réglée cône généralisé est donnée par a : U Õ @0, 2 pD Õ !ö!3 , aHuL = H2 CosHuL, SinH2 uL, -2L , q = H0, 0, -1L c : % Õ @0, 2 pDä@0, 2D Õ !2ö!3 , cHu, vL = v aHuL + q = H2 v CosHuL, v SinH2 uL, -1 - 2 vL Surface réglée (non cylindrique) [1] L’équation de la surface hélicoïdale est donnée par s, d : U Õ @0, 2 pD Õ !ö!3 , sHuL = H0, 0, uL, dHuL = H CosHuL, SinHuL, 0L , avec dHuLä d' HuL = I0, 0, CosHuL 2 + SinHuL 2 M Hi.e.s' annule jamaisL c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = sHuL + v dHuL = Hv CosHuL, v SinHuL, uL s' HuL = H0, 0, 1L , d' HuL = H- SinHuL, CosHuL, 0L et Xs' HuL, d' HuL\ = 0 ï s est la courbe de striction pHuL = Xs' HuL,dHuLäd' HuL\ Xd' HuL,d' HuL\ = CosHuL 2+ SinHuL 2 1 = 1 est le paramètre de distribution l’équation de la surface de paraboloïde hyperbolique est donné par s, d : U Õ @0, 2 pD Õ !ö!3 , sHuL = Hu, 0, 0L, dHuL = H 0, 1, uL , with dHuLä d' HuL = H1, 0, 0L Hi.e. never vanishesL c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = sHuL + v dHuL = Hu, v, u vL s' HuL = H1, 0, 0L , d' HuL = H0, 0, 1L et Xs' HuL, d' HuL\ = 0 ï s est la courbe de striction pHuL = Xs' HuL,dHuLäd' HuL\ Xd' HuL,d' HuL\ = 1 1 = 1 est le paramètre de distribution Représentation des surfaces réglées planes (développables) Représentation des surfaces réglées non cylindrique | 213ü 6.3.4.4. Conception en utilisant les surfaces réglées Après notre étude de surfaces réglées, nous allons montrer un projet de conception architecturale où ces méthodes ont été utilisées pour concevoir la forme. Conception en utilisant les surfaces réglées (homotopies sur un courbes régulières) Les équations des courbes a : @0, 2 pD Õ !ö!3 , aHuL = II4 CosHuL - 3 10 CosH4 uLM, I4 SinHuL - 3 10 SinH4 uLM, 4M g : @0, 2 pD Õ !ö!3 , gHuL = H12 CosHuL, 12 SinHuL , 0L D : @0, 2 pD Õ !ö!3 , DHuL = H3 CosHuL, 3 SinHuL, 0L b : @0, 2 pD Õ !ö!3 , bHuL = H10 CosHuL, 10 SinHuL, 4 + 2 SinH3 uLL Les équations des surfaces cab : @0, 2 pDä@0, 1D Õ !2ö!3 , cabHu, vL = bHuL + v HaHuL - bHuLL cbg : @0, 2 pDä@0, 1D Õ !2ö!3 , cbgHu, vL = gHuL + v HbHuL - gHuLL caD : @0, 2 pDä@0, 1D Õ !2ö!3 , caDHu, vL = DHuL + v HaHuL - DHuLL Représentation d’une conception architecturale en utilisant les surfaces réglées 214 | Plus des conceptions architecturales en utilisant surfaces réglées L’intérêt de l’architecture dans les surfaces réglées en général et les développables (plates), en particulier parce que leur construction peut être réalisée en utilisant des éléments plats (i.e. éléments de courbure gaussienne nulle); qui est bien sûr moins cher et plus facile d’un point de vue pratique. Représentation des dirigeantes de la surface qui devient les éléments structurels Représentation d’une conception architecturale en utilisant des surfaces réglées | 215ü 6.3.4.5. Surfaces de révolution Notre étude des courbes asymptotiques et la définition de comment les trouver nous a conduit à l’étude des surfaces réglées, qui, comme nous l’avons mentionné plus tôt sont d’une grande utilité dans la conception architecturale surtout les développables. De manière similaire, notre étude des courbes principales et la définition analytique de la façon de les trouver nous conduiraient à l’étude des surfaces de révolution, qui sont aussi d’une grande importance dans la conception architecturale pour leur symétrie rotationnelle. Représentation d’une surface de révolution Surface de révolution [1] ¤un plan dans !3 , L Õ ¤est une ligne Haxe de révolutionL et C Õ ¤un ensemble de pointsHcourbe de profilL ï & est une surface de révolution de C autour de L Supposons ¤est le plan x - z et L est l' axe z et a : Ha, bL Õ !öC , aHvL = HjHvL, yHvLL est la paramétrisation de C qui est différentiable c : %ö&, cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL est le paramétrage standard de & ¤›& est une courbe méridienne et L ¨ › & est une courbe parallèle 216 | Courbure de la surface de révolution (surface locale principale) [1] a : Ha, bL Õ !ö!2 , aHvL = HjHvL, yHvLL est une courbe de profil c : %ö&, cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL est le paramétrage standard de & E, F, G, e, f , g, k1, k2, ., / sont tous constantesle long des parallèles E = j2 , F = 0 , G = j' 2 + y' 2 , e = -†j§ y' j' 2+y' 2 , f = 0 , g = signHjL Hj'' y'-j' y''L j' 2+y' 2 et UHu, vL = signHjL Hy' CosHuL-y' SinHuL,j'L j' 2+y' 2 k1 = e E = -y' †j§ j' 2+y' 2 , k2 = g G = signHjL Hj'' y'-j' y''L Ij' 2+y' 2 M 3 2 , . = -y' 2 j'' + j' y' y'' jIj' 2+y' 2 M 2 et / = jHj'' y'-j' y''L - y' Ij' 2+y' 2 M 2 †j§ Ij' 2+y' 2 M 3 2 si aHvL = HjHvL, yHvLL a une vitesse unitaire Hi.e. " v œ Ha, bL , °aHvL¥ = 1L alors nous avons E = j2 , F = 0 , G = 1 , e = -†j§ y' , f = 0 , g = signHjL Hj'' y' - j' y''L et UHu, vL = signHjL Hy' CosHuL - y' SinHuL, j'L k1 = e E = -y' †j§ , k2 = g G = signHjL Hj'' y' - j' y''L , . = -j'' j et / = 1 2 JsignHjL Hj'' y' - j' y''L - y' †j§ N & surface de révolution qui est minimale ï & est contenu dans un plan ou une caténoïde Surface de révolution [1] L’équation de la surface caténoïde est donnée par a : U Õ @0, 2 pD Õ !ö!2 , aHvL = HjHvL, yHvLL = HCoshHvL, vL c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL CoshHvL, SinHuL CoshHvL, vL k1 = e E = - 1 Cosh2 Hv , k2 = g G = 1 Cosh2 HvL ï / = k1+ k2 2 = 0 ïla caténoïde est une surface minimale Représentation d’une surface de révolution (caténoïde) | 217Conception utilisant la surface de révolution Les surfaces de révolution ont été un outil fondamental de conception en architecture, c’est bien sûr très claire dans la conception des dômes et des coupoles. Dans cet exemple, nous allons montrer la conception d’un dôme à l’aide de la répétition d’un élément profil le long de la base circulaire et la hauteur de cet élément profil est en relation avec sa distance par rapport au centre de la base circulaire. Cela signifie qu’il va être identique partout, nous donnant des éléments propres de la surface de révolution. Représentation de la répétition de l’élément profilé le long de la base circulaire Représentation de la structure en dôme résultante 218 | Plus de conception en utilisant la surface de révolution Maintenant, on va étendre l’idée de révolution en utilisant différentes formes de la courbe de base autre que le cercle et les différentes positions pour le point central, ce qui conduirait à des éléments de surface non identiques, et ne produirait pas une surface de révolution. Mais l’idée de la construction d’un élément profil le long d’une courbe de base est toujours respectée et les résultats pourrait être intéressant du point de vue architectural.- Représentation des composants générés sur une base carré centré et décentré Représentation des composants générés le long de n’importe quelle forme de la courbe de base | 219ü 6.3.4.6. Surfaces à courbure constante Maintenant, nous allons définir les surfaces de révolution à courbure constante abord à courbure positive et ensuite à courbure négative, pour cela nous avons besoin d’utiliser la notion de la fonction elliptique et l’intégrale elliptique. La sphère de rayon a présente une courbure Gaussienne constante positive (. = 1ëa 2 M, Imaginez maintenant prendre la moitié de cette sphère et le plier de différentes manières sans l’étirer, et puisqu’il n’y a pas d’étirement la courbure gaussienne est un invariant isométrique (la sphère complète est cependant rigide). Maintenant, nous essayons de trouver ces surfaces (dans cet exemple, les différentes demi sphères) en trouvant des restrictions sur une paramétrisation c de &. L’intérêt de cela d’un point de vue architectural est tout à fait évident, à savoir parce que ce sera un outil de conception très utile de trouver la famille de surfaces qui ont la même aire, mais différentes formes. Représentation des espaces à deux dimensions de courbures constantes négatifs, positifs et zéro 220 | Elliptic integral [1] EHf mL = Ÿ0 f I1 - m Sin2 HqLM2 „ q est l' intégrale elliptique du second type, EI p 2 mM est l' intégrale elliptique complète " f œ Ip 2 , p 2 M , EHf 1L = SinHfL ï EHf mL est une généralisation de la fonction sin -ÂEHÂf -mL = Ÿ0 f I1 - m Sinh2 HqLM2 „ q ï -ÂEHÂf -mL est une généralisation de la fonction sinh Surfaces de révolution à courbure constante positive [1] M Õ !3 surface de révolution, " p œ M, .HpL = 1 a 2 ï M est contenue dans une surface & paramétrée par cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL aHvL = HjHvL, yHvLL courbe de profil , jHvL = b CosI v a M , yHvL = Ÿ0 v 1 - b 2 a 2 ISin I t a MM2 „t = a EJ v a b 2 a 2 N SHa, bL est une surface de révolution dont la courbe de profil est a si b = a ï v œ Ap 2 , p 2 E et SHa, aL est la sphère de rayon a si b œ H0, aLï v œ @-¶, ¶D et SHa, bL est une broche Hsurfaces en forme de football L si a œ H0, bLï v œ A-a ArcSinI a b M, a ArcSinI a b ME et SHa, bL est un renflement Hsurfaces en forme d ' un baril L Surfaces de révolution à courbure négative constante [1] M Õ !3 surface de révolution, " p œ M, .HpL = - 1 a 2 ï M est contenue dans une surface & paramétrée par cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL aHvL = HjHvL, yHvLL courbe de profil, qui a trois types Pseudosphère aHvL = a e -v a , Ÿ0 v 1 - e -2 t a „t , " 0 b v < ¶ et aHvL = a e v a , Ÿ0 v 1 - e -2 t a , „t , " -¶ < v b 0 Hyperboloïde b positive , v œ A-a Sinh-1 I a b M, a Sinh-1 I a b ME ï jHvL = b Cosh I v a M , yHvL = Ÿ0 v 1 - b 2 a 2 ISinh I t a MM2 „t = - a EJ  v a -b 2 a 2 N Conique b œ H0, aD , v œ B-a Sinh-1 a 2-b 2 b , a Sinh-1 a 2-b 2 b F ï jHvL = b Sinh I v a M , yHvL = Ÿ0 v 1 - b 2 a 2 ICosh I t a MM2 „t = - a 2 - b 2 EJ  v a -b 2 a 2-b 2 N | 221Les trois types de surface de révolution à courbure constante positive on fixe a = 1ïla courbure gaussienne constante = 1 l’équation du type broche SI1, 2 3 M est donnée par c : % Õ @0, 2 pDäAp 2 , p 2 E Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I 2 3 CosHuL CosHvL, 2 3 SinHuL CosHvL , EIv 4 9 MM son aire A SJ1, 2 3 N AI0, - p 2 M, I2 p, p 2 ME = 8.377 l’équation du type sphère SH1, 1L est donnée par c : % Õ @0, 2 pDäAp 2 , p 2 E Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL CosHvL, SinHuL CosHvL , EHv 1LL son aire A SH1,1LAI0, - p 2 M, I2 p, p 2 ME = 4 p l’équation du type renflement SI1, 3 2 M est donnée par c : % Õ @0, 2 pDäA-ArcSinI 2 3 M, ArcSinI 2 3 ME Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I 3 2 CosHuL CosHvL, 3 2 SinHuL CosHvL , 2 3 EIv 9 4 MM l’équation du type renflement SH1, 2L est donnée par c : % Õ @0, 2 pDäA-ArcSinI 1 2 M, ArcSinI 1 2 ME Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = H2 CosHuL CosHvL, 2 SinHuL CosHvL , EHv 4LL l’équation du type renflement SH1, 3L est donnée par c : % Õ @0, 2 pDäA-ArcSinI 1 3 M, ArcSinI 1 3 ME Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I3 CosHuL CosI 3 v 2 M, 3 SinHuL CosI 3 v 2 M , EHv 9LM leur aires A SJ1, 3 2 N AI0, -ArcSinI 2 3 MM, I2 p, ArcSinI 2 3 MME = A SH1,2LAI0, -ArcSinI 1 2 MM, I2 p, ArcSinI 1 2 MME = A SH1,3LAI0, -ArcSinI 1 3 MM, I2 p, ArcSinI 1 3 MME = 4 p Représentation des trois types de surface de révolution à courbure constante positive 222 | Les trois types de surface de révolution à courbure négative constante on fixe a = 1ïla courbure gaussienne constante = -1 the equation of the pseudo sphere type is given by c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = ICosHuL SinHvL, SinHuL SinHvL , CosHvL + LogITanI v 2 MMM son aire A@H0, 0L, H2 p, 2 pLD = 25.132 the equation of the hyperboloid type is given by c : % Õ @0, 2 pDäA-ArcSinh-1 H1L, ArcSinh-1 H1LE Õ !2ö!3 , cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL SinHvL, SinHuL SinHvL , - EH v -1LL son aire AAI0, -ArcSinh-1 H1LM, I2 p, ArcSinh-1 H1LME = 17.519 the equation of the conic type is given by c : % Õ @0, 2 pDäA-ArcSin-1 I 3 M, ArcSin-1 I 3 ME Õ !2ö!3 cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = K 1 2 CosHuL SinhHvL, 1 2 SinHuL SinhHvL , -  3 2 EJ v -1 2 3 NO son aire AAI0, -ArcSin-1 H2LM, I2 p, ArcSin-1 H2LME = 1.91 Représentation des trois types de surface de révolution à courbure négative constante | 223ü 6.3.4.7. Surfaces minimales Dans cette section, nous allons étudier une autre propriété importante d’analyse de surface qui est pratique dans la conception architecturale, à savoir la capacité à trouver la surface minimale dans une famille de surfaces. Une surface minimale est une surface d’aire minimale au sein d’une famille de surfaces, et elles est aussi une surface dont la courbure moyenne est identiquement nulle. Afin de montrer l’équivalence de ces deux définitions, nous devons définir la fonction de la variation normale qui représente la façon dont la surface & change lorsqu’elle est tiré dans le sens normal, et comment la courbure moyenne est nulle si et seulement si la dérivée première de la fonction de l’aire s’annule. Domaine borné et région [1] & Õ !n surface régulière , O Õ & est un ouvert connexe HdomaineL f : S 1 ö fIS 1 M = #O la frontière de O, f homéomorphisme différentiable l' application tangente f* " 0 sauf pour un nombre fini de points, et D = O ‹ #O est une région de & D est bornée si $ m œ ! " p œ D , °p¥ § m c : %ö & est une surface locale réguliere, D Õ & est une région bornée AHDL = Ÿc -1 HDL E G - F 2 d u d v = Ÿc -1 HDL °cu ä cv¥ d u d v est l' aire de D Variation normale et la disparition courbure moyenne [1] c : %ö !3 est une surface locale réguliere, W Õ % est une région bornée, h : W ö ! différentiable, e > 0 , U est la normale unitaire c : H-e, eLä W ö !3 , cHtL Hu, vL = cHu, vL + t hHu, vL UHu, vL est la variation normale de c et W EHtL = Xc HtLu , c HtLu \ , FHtL = Xc HtLu , c HtLv \ et GHtL = Xc HtLv , c HtLv \ pouresuffisamment petite EH0L = E, FH0L = F et GH0L = G AHtL = ŸW EHtL GHtL - FHtL 2 d u ä d v est l' aire de cHtL Hu, vL A' H0L = -2 ŸW h / E G - F 2 d u ä d v , où / est la courbure moyenne c est minimal sur W ó A' H0L = 0 pour une variation normale de c et W par rapport à toute h : W ö ! Représentation de la surface Enneper (exemple d’une surface minimale) 224 | ü 6.4. Références [1] Modern differential geometry of curves and surfaces, Alfred Gray, CRC Press, 1993 [2] Cours de Calcul différentiel et équations différentielles, Mireille Chaleyat-Maurel, Université Paris Descartes, Paris, 2011 [3] Cours de Géométrie Différentielle, Laurent Charles, Université Pierre et Marie Curie, Paris, 2012 [4] Cours de Géométrie et topologie Différentielles, Alexandru Oancea, Université Pierre et Marie Curie, Paris, 2013 [5] Cours de Théorie des systèmes dynamiques, Jean-Pierre Françoise, Université Pierre et Marie Curie, Paris, 2012 [6] Cours de Géométrie Riemannienne, Alexandru Oancea, Université Pierre et Marie Curie, Paris, 2013 [7] Cours d’Intégration et théorie de la mesure, Valentine Genon-Catalot, Université Paris Descartes, Paris, 2011 [8] Tracing surface intersection with validated ODE system solver, H.Mukundan, K.H.Ko, T.Maekawa, T.Sakkalis, N.M.Patrikalakis, MIT, Cambridge, 2004 | 2257. Opérations algorithmiques ü 7.1. Dessin automatisé Après avoir défini une palette d’opérations (algébrique et analytique), nous allons maintenant définir certaines opérations algorithmiques qui utilisent dans une large mesure à la fois les deux autres opérations. Les opérations algorithmiques sont probablement les plus accessibles pour les architectes car elles sont moins abstraites que les opérations algébriques et analytiques. Dans cette partie de l’étude, nous allons voir quelques applications architecturales des propriétés définies dans les chapitres précédents qui étaient assez abstraites et loin du domaine architectural. Les algorithmes sont rien d’autre que des ensembles d’instructions qui peuvent être exécutées automatiquement et souvent de manière itérative, pour cette raison, ils sont les méthodes utilisées pour accomplir des tâches répétitives avec une grande précision et pour un grand nombre de fois. Les opérations algorithmiques traite des objets géométriques discrets en utilisant des méthodes computationnelles donc elles sont naturellement liés à des notions de géométrie discrète et combinatoire, ainsi que la géométrie computationnelle. Les géométries discrètes et combinatoires sont des branches de géométrie qui étudient les propriétés combinatoires et des méthodes constructives des objets géométriques discrets, tandis que la géométrie computationnelle est une branche de l’informatique consacrée à l’étude des algorithmes qui peuvent être déclaré en termes de la géométrie. La géométrie computationnelle peut être divisé en géométrie computationnelle combinatoire et numériques; la computationnelle combinatoire est naturellement porté sur l’utilisation des algorithmes pour résoudre des problèmes combinatoires. Alors que la géométrie computationnelle numérique (aussi connu comme la modélisation géométrique) est plus soucieux de la modélisation et la représentation des courbes et des surfaces en utilisant des méthodes paramétriques telles que splines de Bézier et NURBS. Il existe de nombreuses façons d’appliquer les opérations algorithmiques dans l’architecture, mais nous allons définir deux directions principales que nous allons appeler: le dessin automatisé et la méthode de recherche. Le dessin automatisé est essentiellement d’automatiser le processus de dessin des éléments répétitifs, un exemple classique de cela, sera le dessin de panneaux, fenêtres, poutres, escalier, etc. Cette pratique a connu une croissance très populaire récemment auprès des architectes en raison du développement de logiciels basé sur des scripts qui permet aux architectes de réaliser ces tâches. Dans le dessin automatisé, nous allons utiliser des notions et des techniques de la géométrie combinatoire et computationnelle, par exemple créer des pavages et de trouver le point le plus proche d’un point donné dans un ensemble fini. Mais avant d’entrer dans les techniques combinatoires et computationnelles, nous allons montrer comment créer des surfaces qui peuvent être utilisés comme des éléments architecturaux dans la peau générale défini par la surface principale. Jusqu’ici, nous avons été préoccupés seulement par la création de cette surface principale qui pourrait être comprise comme l’enveloppe du bâtiment, mais bien sûr, la conception architecturale est non seulement la conception de l’enveloppe extérieure, il comprend également la conception de l’organisation interne, par exemple escalier et subdivisions internes. Nous tenons à regrouper ces opérations relatives à l’organisation interne avec les opérations algorithmiques, même si elles ne sont pas entièrement computationnelles, c’est parce qu’ils traitent des surfaces séparées (éléments), par exemple, les niveaux différents de sol ou des étapes dans un escalier. Après ceux-ci nous allons nous concentrer davantage sur les techniques computationnelles et combinatoires à générer des motifs d’objets architecturaux. Dans la deuxième partie de ce chapitre à savoir la méthode de recherche, nous allons explorer les techniques des optimisations et nous aurons un supplément de la biologie de l’évolution afin de nous aider à comprendre les origines de la terminologie dans les algorithmes génétiques. Pour le moment, nous commençons avec le dessin automatisé pour créer des éléments d’organisation interne. 226 | ü 7.1.1. Organisation interne ü 7.1.1.1. Circulation verticale La première de ces applications serait la création d’éléments d’organisation interne de base par exemple des connexions verticales comme les escaliers et les séparateurs d’espace comme les surfaces de séparation verticales et horizontales. L’équation du cylindre de base est donnée par c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 , cHu, vL = ICosHuL, SinHuL, v 2 M Ii = AHi - 1L I 2 p 2 m M, HiL I 2 p 2 m ME, lesintervalles de i = 1, ..., 2 m, où m est le nombre d ' étages l' équation de la courbe plane par morceaux g dont la trace se situe dansle domaine Hm = 3L est donnée par g : U Õ @0, 2 pD Õ !ö!2 , gHtL = HuHtL, vHtLL si t œ I1, gHtL = It, 2 t - 0 3 2 pM, si t œ I2, gHtL = It, 1 3 2 pM si t œ I3, gHtL = It, 2 t - 1 3 2 pM, si t œ I4, gHtL = It, 2 3 2 pM si t œ I5, gHtL = It, 2 t - 2 3 2 pM, si t œ I6, gHtL = It, 2 3 2 pM l' équation de la courbe par morceaux dansle cylindre est aHtL = cHuHtL, vHtLL si t œ I1, aHtL = ICosHtL, SinHtL, 1 2 I2 t - 0 3 2 pMM, si t œ I2, aHtL = ICosHtL, SinHtL, 1 2 I 1 3 2 pMM si t œ I3, aHtL = ICosHtL, SinHtL, 1 2 I2 t - 1 3 2 pMM, si t œ I4, aHtL = ICosHtL, SinHtL, 1 2 I 2 3 2 pMM si t œ I5, aHtL = ICosHtL, SinHtL, 1 2 I2 t - 2 3 2 pMM, si t œ I6, aHtL = ICosHtL, SinHtL, 1 2 I 2 3 2 pMM l' équation de la surface est un escalier YHt, uL = cHuHtL, vHtLL + u †lHtL§ cNHuHtL, vHtLL où lHtL = 1 est une fonction scalaire et cNHuHtL, vHtLL est la normale à la surface du cylindre restreinte à a si t œ I1, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I2 t - 0 3 2 pMM, si t œ I2, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I 1 3 2 pMM si t œ I3, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I2 t - 1 3 2 pMM, si t œ I4, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I 2 3 2 pMM si t œ I5, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I2 t - 2 3 2 pMM, si t œ I6, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL, 1 2 I 2 3 2 pMM Représentation de l’élément de circulation verticale | 227ü 7.1.1.2. Séparation et la division de l’espace Après l’escalier, nous allons définir les murs et les sols qui divise l’espace interne l’équation de la surface de base est donnée par c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 cHu, vL = I 3 2 ICosHuL + 5 2 CosI u 2 M 8 M I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM, 3 SinHuL I2 + 35 100 CosI v 2 MM I1 - CosI v 2 M 6 + SinI v 2 MM, v - SinHvLM les points dans le domaine % Õ [0, 2 p]ä[0, 2 p] q1 = I0, 3 p 5 M, q2 = I0, 11 p 10 M, q3 = Ip, 3 p 5 M, q4 = Ip, 11 p 10 M, q5 = q2+q4 2 , q6 = I2 p, 3 p 5 M, q7 = q3+q6 2 les équations des courbes dans le domaine d : U Õ @0, 2 pD Õ !ö!2 , dHtL = q2 + t 2 p Hq5 - q2L = Hd1HtL, d2HtLL s : U Õ @0, 2 pD Õ !ö!2 , sHtL = q4 + t 2 p Hq5 - q4L = Hs1HtL, s2HtLL h : U Õ @0, 2 pD Õ !ö!2 , hHtL = q3 + t 2 p Hq7 - q3L = Hh1HtL, h2HtLL q : U Õ @0, 2 pD Õ !ö!2 , qHtL = q6 + t 2 p Hq7 - q6L = Hq1HtL, q2HtLL g : U Õ @0, 2 pD Õ !ö!2 , gHtL = q1 + t 2 p Hq2 - q1L = Hg1HtL, g2HtLL b : U Õ @0, 2 pD Õ !ö!2 , bHtL = q3 + t 2 p Hq4 - q3L = Hb1HtL, b2HtLL les équations des éléments de séparation (murs et sols) cw : % Õ @0, 2 pDä@0, 1D Õ !2ö!3 , cwHt, uL = cHg1HtL, g2HtLL + u HcHb1HtL, b2HtLL - cHg1HtL, g2HtLLL cf1 : % Õ @0, 2 pDä@0, 1D Õ !2ö!3 , cf1 Ht, uL = cHd1HtL, d2HtLL + u HcHs1HtL, s2HtLL - cHd1HtL, d2HtLLL cf2 : % Õ @0, 2 pDä@0, 1D Õ !2ö!3 , cf2 Ht, uL = cHh1HtL, h2HtLL + u HcHq1HtL, q2HtLL - cHh1HtL, h2HtLLL Représentation des éléments de séparation et de division de l’espace 228 | ü 7.1.1.3. Renflement et transition douce Après les murs et les sols qui divise l’espace intérieur, nous allons définir une manière plus fluide pour désigner les différentes zones de l’espace, un peu comme un paysage avec des renflements. l’équation de la surface de base est donnée par c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 cHu, vL = Iv CosHuL I 13 10 + CosHuL 5 M I1 + 1 2 SinH2 uL 3 M, v SinHuL I 13 10+ CosHuL 5 M I1 + 1 2 SinH2 uL 3 M, 3 SinI v 2 MM l’équation de la surface renflée h1, h2 : U Õ @0, 2 pD Õ !ö!, h1HuL = SinI Hp+uL 2 M 10 and h2HvL = SinI v 2 M 10 cL : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 cLHu, vL = Jv CosHuL J 13 10 + CosHuL 5 N J1 + 1 2 SinH2 uL 3 N, v SinHuL J 13 10 + CosHuL 5 N J1 + 1 2 SinH2 uL 3 N, 3 SinI v 2 M h1HuL h2HvLN Représentation de la surface renflée Maintenant, nous allons montrer un exemple concret où la fonction de renflement a été utilisé pour générer des variations de la surface du sol qui peuvent être utilisés à différentes fins architecturales par exemple des éléments de sièges. Représentation de l’utilisation architecturale de la fonction de renflement | 229ü 7.1.2. Tâches répétitives ü 7.1.2.1. Opération géométrique répétée Une autre forme de dessin automatisé est faire des tâches répétitives, nous démontrons dans l’exemple suivant: le calcul de l’intersection d’un ensemble de droites et les plans d’un cube; ici ces droites sont tangentes à une courbe spirale contenue dans le cube. k = 4; max = 10; b = 81, 1, 1<; a = 8max ê 2, max ê 2, 0< + b; Tmin = -0.5; Tmax = 1.; ndiv = 200; Ts = 0.0; Tstep = HTmax - TminL ê ndiv; F@T_D := a + 8Exp@TD Cos@8 TD, Exp@TD Sin@8 TD, 4 Exp@TD<; G@T_D := 8Cos@8 TD - 8 Sin@8 TD, Sin@8 TD + 8 Cos@8 TD, 4<; L@T_, t_D := F@TD + t G@TD; cPlnorth@u_, v_D := 8u, max, v<; cPlsouth@u_, v_D := 8u, 0, v<; cPleast@u_, v_D := 8max, u, v<; cPlwest@u_, v_D := 80, u, v<; cPlbottom@u_, v_D := 8u, v, 0<; cPlup@u_, v_D := 8u, v, max<; TabL = Table@L@T, tD, 8T, Tmin, Tmax, Tstep 0, RandomInteger@81, ia 0, RandomInteger@81, ib 0, RandomInteger@81, ic, MeshStyle Ø 88Thickness@0.002D, White<, 8Thickness@0.002D, White<<, BoundaryStyle Ø 8Thickness@0.008D, White<, PlotRange Ø All, PlotLabel Ø 9"n°" , p=, Boxed Ø False, Axes Ø FalseF; ParamVal@@pDD = 99"n°" , p=, 8JT, !r, ia, ixa, ib, ixb, ic, ixc, !b, !o, !a, !c, !d, ra, rb, rc, ha, !r, rr, hr<=; , 8p, 1, Apocalypse 1, If@WinDist < Test, Chosen = WinDist; ChosenT = WinPt, Chosen = Test; ChosenT = 8Ps@@kDD, s@@kDD 1, If@WDist < Dees@@k, 1DD, kozen = WDist; kozenI = WI, kozen = Dees@@k, 1DD; kozenI = kDD; WDist = kozen; WI = kozenI; , 8k, 1, n est un groupe cyclique sousla multiplication de l' ordre n Groupe dièdre [3] pour tout polygone régulier à n arête, il possède 2 n différent symétriesHn symétries de rotation et n symétries de réflexionL Dn = Xr, s\ = 9r k s l r n = 1, s 2 = 1 et s -1 r s = r -1 = lesrotations et lesréflexions des ce polygone associés Groupe «wallpaper» [4] E2 groupe de symétrie du plan euclidien, L Õ !2 est un réseau à 2 dimensions W Õ E2 est un groupe de «wallpaper» sison sous - groupe de translation H est engendré par deux translation indépendant etson groupe ponctuel J est fini L = 9y œ !2 h œ H , y = hH0"2 L = = 9n t1 + m t2 n, m œ Z , H t1, t2L une base de !2 = il n' y a que 5 types de réseaux : obliques, rectangulaire, rectangulaire centrée, carrées et hexagonales Théorème de restriction cristallographique [4] L’ordre de rotation dans un groupe de «wallpaper» ne peut être que 2,3,4 ou 6 On note les groupes «wallpaper» avec la notation cristallographique, le nom complet est composé de quatre symboles: le premier symbole représente le type de réseau, p pour pour primitive et c centrée. Ceci est suivi par un chiffre n indiquant les symétrie de rotation: 1 (aucun), 2, 3, 4 ou 6, les deux symboles suivants sont soit m, g ou 1. Un m Hou gL à la place de la troisième symbole signifie qu’il y a une ligne de réflexion (ou une ligne de réflexion glissée) perpendiculaire à l’axe x, tandis que 1 signifie qu’il n’y a pas de ligne de n’importe quel type. Enfin, le dernier symbole m Hou gL représente une ligne de réflexion (ou une ligne de réflexion glissée) à un angle a avec l’axe x, l’angle dépend du plus grand ordre de rotation comme suit: a = 90° pour n = 1, 2; a = 60° pour n = 3, 6; a = 45° pour n = 4. La courte notation supprime des chiffres ou un m qui peut être déduit. Par exemple, le groupe p 3 m 1 représente un groupe avec 120° rotation, une ligne de réflexion perpendiculaire à l’axe x, et aucune réflexion ou ligne de réflexion glissée à un angle de 60° . Les opérateurs de chaque groupe de «wallpaper» utilisent le symboles bien établis présentés dans le tableau suivant. 248 | Les groupes de «wallpaper» Représentation des opérateurs des groupes de «wallpaper» Dans les groupes de «wallpaper», nous avons trois types de réseaux: obliques, carrées et hexagonales, ce qui est naturel parce que nous l’avons mentionné plus tôt que les seuls pavages réguliers du plan sont carré, triangulaire et hexagonale, et chacun des groupes de «wallpaper» en avoir un de ces pavages réguliers comme son réseau. Wallpaper group crytallographic shortened point group underneath lattice 1 p1 1 C1 oblique 2 p2 2 C2 oblique 3 pm m D1 rectangular 4 pg m D1 rectangular 5 cm m D1 rectangular 6 p2mm 2 mm D2 rectangular 7 p2mg 2 mm D2 rectangular 8 p2gg 2 mm D2 rectangular 9 c2mm 2 mm D2 rectangular 10 p4 4 C4 square 11 p4mm 4 mm D4 square 12 p4gm 4 mm D4 square 13 p3 3 C3 hexagonal 14 p3m1 3 m D3 hexagonal 15 p31m 3 m D3 hexagonal 16 p6 6 C6 hexagonal 17 p6mm 6 mm D6 hexagonal Représentation des 17 groupes de «wallpaper» avec leurs notations et réseaux | 249ü 7.1.4.3. Conception en utilisant le groupe de «wallpaper» Nous allons maintenant mettre l’accent sur l’un de ces groupes afin de montrer comment l’utiliser dans la conception architecturale, le groupe, nous allons étudier est p 3 m 1. Ce groupe a un groupe ponctuel D3, un réseau hexagonal, trois centres rotation différentes d’ordre 3 et trois réflexions dans les trois côtés d’un triangle équilatéral, et trois réflexions de glissées dans trois directions distinctes, dont les axes sont situés en mi-chemin entre les axes parallèles adjacents de réflexion. Le réseau hexagonal est construite par les vecteurs 8t1, t2< où t1est un vecteur de longueur minimum et t2 = RHt1L, avec R une rotation de 120° . si J = D3, alors groupe ponctuel contient trois réflexions; avec les lignes de réflexions séparées par des angles de 60° , comme M est une réflexion dans D3, alors M R est une réflexion dont la ligne de réflexion fait un angle de 60° avec celle de M. Les lignes de réflexion pour D3 doivent être des lignes de réflexion pour D6 car D3 est un sousgroupe de D6; cela indique que D3 peut agir de deux façons par rapport à un réseau hexagonal proposée. Les lignes de réflexion peuvent être 30° , 90° et 150°par rapport au t1. La rotation par 120° et la ligne de réflexion sur 30° génèrent le groupe D3,l , où l signifie longue. Ce groupe contient une ligne de réflexion sur 150° , qui est la grande diagonale du parallélogramme et le groupe de «wallpaper» associé à D3,l est p 3 m 1. De même, les lignes de réflexion peuvent être 0 ° , 60° et 120° par rapport au t1. La rotation par 120° et la ligne de réflexion sur 0 ° génèrent le groupe D3,s , où s signifie court. Ce groupe contient une réflexion sur 60° , qui est la petite diagonale du parallélogramme et le groupe de «wallpaper» associé à D3,s est p 3 1 m. Représentation d’un pavage utilisant le groupe de «wallpaper» p 3 m 1 et montrent la domaine fondamental Les paramètres de l' option choisie JT = 0.3, !r = 1, ia = 0, ix a = 1, ib = 3, ix b = 1, ic = 2, ix c = 2, !b = 0.08, !o = 1, !a = 0.9, !c = -0.6, !d = 0.3, ra = 2.5, rb = 2.9, rc = 2, ha = 2, !r = 0.11, rr = 1, hr = 2 250 | Même que nous avons fait pour générer un grand nombre de surfaces qui sont candidats à la forme générale d’une conception à l’aide d’un petit algorithme, nous pouvons utiliser un autre algorithme pour automatiser le processus de dessin des éléments répétitifs. Par exemple, si nous tenons à couvrir la surface de la robe avec le pavage ci-dessus, nous aimerions écrire les instructions pour dessiner un élément, puis un processus itératif pour dessiner le reste. L’algorithme de pavage de la surface Un = 2 p ; Vn = p J 3 N; A = 7 H6L; ndu = A; ndv = A; us = Un ê ndu; vs = Vn ê ndv; F@u_, v_D := FocBu, 2 v 3 F; p = Table@F@u, vD, 8u, 0, Un, us<, 8v, 0, Vn, vs 0 " x œ A avec °x - x * ¥ § d ï f Hx * L § f HxL x * est un maximum local si $ d > 0 " x œ A avec °x - x * ¥ § d ï f Hx * L ¥ f HxL Un grand nombre d’algorithmes proposés pour résoudre des problèmes non convexes ne sont pas capables de faire la distinction entre les solutions optimales locales et la solution optimale globale, les algorithmes et les méthodes utilisées dans la résolution de ces problèmes non convexes (c’est à dire la convergence vers une solution optimale en un temps fini) appartiennent à la domaine de l’optimisation globale. Il existe trois approches principales pour les problèmes d’optimisation globale: méthodes déterministes comme les méthodes de plan de coupe, les méthodes stochastiques comme les méthodes de Monte Carlo et (méta) heuristiques comme les algorithmes évolutionnaires. Dans cette recherche, nous allons nous concentrer principalement sur stochastiques et (méta) heuristiques, spécialement les algorithmes évolutionnaires. La méthode de Newton [6] f : !n Ø !n C 1 et f ' HxL ! 0, x œ !n supposons f HxL = x 2 - a ï f ' HxL = 2 x ï xn +1 = xn - f Hxn L f ' Hxn L = 1 2 Ixn - a xn M avec xn Ø nض a l' équation de la limite : x = x - C f HxL, avec C = 1 f ' HxL , nous allonsl' utiliser pour trouver la solution de f HxL = x 2 - 3 f@x_D := x 2 - 3; df@f_D@x_D := Evaluate@!x f@xDD xo = 10.0; xp = xo; DoBxc = xp - f@xpD df@fD@xpD ; If@xc == xp, x! = xc; Break@D, xp = xcD;, 8i, 1, 20 OP, OP = OC; Hom@@kDD = OC; NInd = NInd + 1; ODess@@kDD = Table@Graphics@Comp@@iDDD, 8i, 1, ndu OP, OP = OC; OV@@pDD = OC; OF@@pDD = ParametricPlot3DBcScarlet@a, r, m, b, n, k, c, d, eD@u, vD, 8u, 0, 2 p<, 8v, 0, 2 p<, PlotStyle Ø 8Black<, Mesh Ø :RangeB0, 2 p, 2 20 pF, RangeB0, 2 p, 2 10 pF>, MeshStyle Ø 88Thickness@0.001D, White<, 8Thickness@0.001D, White<<, BoundaryStyle Ø 8Thickness@0.008D, White<, PlotRange Ø All, PlotLabel Ø 9"n°" , p=, Boxed Ø False, Axes Ø FalseF; RGraph@@pDD = 8p, OC<; NInd = NInd + 1; , OP = OP; OV@@pDD = 0; F; , 8p, 1, Apocalypse. HAL Id: tel-00978366 https://tel.archives-ouvertes.fr/tel-00978366 Submitted on 14 Apr 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITÉ PARIS-SUD ÉCOLE DOCTORALE Sciences et Technologie de l’Information, des Télécommunications et des Systèmes INRIA Paris-Rocquencourt DISCIPLINE : Génie Informatique THÈSE DE DOCTORAT présentée et soutenue publiquement le 03/04/2014 par Falou NDOYE Ordonnancement temps réel préemptif multiprocesseur avec prise en compte du coût du système d’exploitation Composition du jury : Directeur de thèse : Yves SOREL Directeur de recherche (INRIA Paris-Rocquencourt) Rapporteurs : Emmanuel GROLLEAU Professeur (ISAE-ENSMA Poitiers) Jean-Luc SCHARBARG Professeur (INPT/ENSEEIHT Toulouse) Examinateurs : Alain MERIGOT Professeur (Université Paris-Sud Orsay) Laurent GEORGE Maître de conférences HDR (Université Marne-la-Vallée)2 Résumé Dans cette thèse nous étudions le problème d’ordonnancement temps réel multiprocesseur préemptif avec prise en compte du coût exact du système d’exploitation. Ce coût est formé de deux parties : une partie facile à déterminer, correspondant au coût de l’ordonnanceur et une partie difficile à déterminer, correspondant au coût de la préemption. Cette difficulté est due au fait qu’une préemption peut en engendrer une autre, pouvant ainsi créer un phénomène d’avalanche. Dans un premier temps, nous avons étudié l’ordonnancement hors ligne multiprocesseur de tâches indépendantes avec prise en compte du coût exact de la préemption et proposé une analyse d’ordonnançabilité fondée sur une heuristique d’ordonnancement multiprocesseur. Cette heuristique utilise la stratégie d’ordonnancement multiprocesseur par partitionnement. Pour prendre en compte le coût exact de la préemption sur chaque processeur nous avons utilisé la condition d’ordonnançabilité proposée par Meumeu et Sorel. Cette condition d’ordonnançabilité pour des tâches à priorités fixes, est basée sur une opération binaire d’ordonnancement qui permet de compter le nombre exact de préemption et d’ajouter leur coût dans l’analyse d’ordonnançabilité des tâches. L’heuristique proposée permet de maximiser le facteur d’utilisation restant afin de répartir équitablement les tâches sur les processeurs et de réduire leur temps de réponse. Elle produit une table d’ordonnancement hors ligne. Dans un second temps, nous avons étudié l’ordonnancement hors ligne multiprocesseur de tâches dépendantes avec prise en compte du coût exact de la préemption. Puisque la condition d’ordonnançabilité utilisée pour ordonnancer les tâches indépendantes ne s’applique qu’à des tâches à priorités fixes, elle ne permet pas de gérer les inversions de priorités que peuvent entraîner les tâches dépendantes. Nous avons donc proposé une nouvelle condition d’ordonnançabilité pour des tâches à priorités dynamiques. Elle prend en compte le coût exact de la préemption et les dépendances sans aucune perte de données. Ensuite en utilisant toujours la stratégie d’ordonnancement par partitionnement, nous avons proposé pour des tâches dépendantes une heuristique d’ordonnancement multiprocesseur qui réutilise cette nouvelle condition d’ordonnançabilité au niveau de chaque processeur. Cette heuristique d’ordonnancement prend en compte les coûts de communication inter-processeurs. Elle permet aussi de minimiser sur chaque processeur le makespan (temps total d’exécution) des tâches. Cette heuristique produit pour chaque processeur une table d’ordonnancement hors ligne contenant les dates de début et de fin de chaque tâches et de chaque commmunication interprocesseur. En supposant que nous avons une architecture multiprocesseur de type dirigée par le temps (Time Trigger TT) pour laquelle tous les processeurs ont une référence de temps unique, nous avons proposé pour chacun des processeurs un3 ordonnanceur en ligne qui utilise la table d’ordonnancement produite lors de l’ordonnancement hors ligne. Cet ordonnanceur en ligne a l’avantage d’avoir un coût constant et facile à déterminer de manière exacte. En effet il correspond uniquement au temps de lecture dans la table d’ordonnancement pour obtenir la tâche sélectionnée lors de l’analyse d’ordonnançabilité hors ligne, alors que dans les “ordonnanceurs classiques” en ligne ce coût correspond à mettre à jour la liste des tâches qui sont dans l’état prêt à l’exécution puis à sélectionner une tâche selon un algorithme, par exemple RM, DM, EDF, etc. Il varie donc avec le nombre de tâches prêtes à s’exécuter qui change d’une invocation à l’autre de l’ordonnanceur. C’est ce coût qui est utilisé dans les analyses d’ordonnançabilités évoquées ci-dessus. Un autre avantage est qu’il n’est pas nécessaire de synchroniser l’accès aux mémoires de données partagées par plusieurs tâches, car cette synchronisation a été déjà effectuée lors de l’analyse d’ordonnançabilité hors ligne.5 Rémerciements Je tiens à remercier Yves Sorel, mon directeur de thèse, de m’avoir accueilli comme stagiaire au sein de l’équipe-projet AOSTE et ensuite m’avoir donné l’opportunité de faire une thèse. Il a su guider mes travaux tout en me laissant mon autonomie. Je remercie également Emmanuel Grolleau et Jean Luc-Scharbarg qui ont accepté d’être les rapporteurs de cette thèse. De même, un grand merci à Alain Merigot et Laurent George qui ont accepté de faire partie des membres du jury. Je remercie aussi tous les membres de l’équipe-projet AOSTE pour les bons moments passés ensemble. Enfin, mention spéciale à ma fammille et à mes amis qui m’ont soutenus tout au long de cette thèse.Table des matières Liste des figures 7 Liste des tableaux 8 Introduction générale 11 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 I Concepts de base et État de l’art 15 1 Concepts de base 17 1.1 Système temps réel . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1.2 Classification des systèmes temps réel . . . . . . . . . . . 17 1.2 Tâche temps réel . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Tâches périodiques . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.1 Tâches concrètes/non concrètes . . . . . . . . . . . . . . 19 1.3.2 Tâches synchrones/asynchrones . . . . . . . . . . . . . . 20 1.4 Contraintes temps réel . . . . . . . . . . . . . . . . . . . . . . . 20 1.4.1 Échéances . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4.2 Périodicité stricte . . . . . . . . . . . . . . . . . . . . . . 21 1.4.3 Dépendances entre tâches . . . . . . . . . . . . . . . . . 21 1.4.4 Latence . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.5 Ordonnancement des systèmes temps réel . . . . . . . . . . . . . 22 1.5.1 Algorithmes d’ordonnancement . . . . . . . . . . . . . . 22 1.5.2 Analyse de faisabilité . . . . . . . . . . . . . . . . . . . . 24 1.5.3 Analyse d’ordonnançabilité . . . . . . . . . . . . . . . . 24 1.5.3.1 Approche analytique . . . . . . . . . . . . . . . 24 1.5.3.2 Approche par simulation . . . . . . . . . . . . 252 TABLE DES MATIÈRES 1.6 Viabilité d’une condition d’ordonnançabilité . . . . . . . . . . . . 25 1.7 Ordonnanceur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.7.1 Invocation de l’ordonnanceur . . . . . . . . . . . . . . . 26 1.7.2 États et gestion des tâches . . . . . . . . . . . . . . . . . 26 1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2 État de l’art 29 2.1 Ordonnancement monoprocesseur . . . . . . . . . . . . . . . . . 29 2.1.1 Priorités fixes . . . . . . . . . . . . . . . . . . . . . . . . 29 2.1.1.1 Priorités fixes aux tâches . . . . . . . . . . . . 29 2.1.1.2 Priorités fixes aux instances . . . . . . . . . . . 30 2.1.2 Priorités dynamiques . . . . . . . . . . . . . . . . . . . . 31 2.2 Ordonnancement multiprocesseur . . . . . . . . . . . . . . . . . 31 2.2.1 Architecture multiprocesseur . . . . . . . . . . . . . . . . 31 2.2.2 Stratégies d’ordonnancement . . . . . . . . . . . . . . . . 32 2.2.2.1 Stratégie par partitionnement . . . . . . . . . . 33 2.2.2.2 Stratégie globale . . . . . . . . . . . . . . . . . 35 2.2.2.3 Stratégie par semi-partitionnement . . . . . . . 37 2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.1 Méthodes exactes . . . . . . . . . . . . . . . . . . . . . . 37 2.3.1.1 Branch & Bound . . . . . . . . . . . . . . . . . 38 2.3.1.2 Branch & Cut . . . . . . . . . . . . . . . . . . 38 2.3.1.3 Programmation par contraintes . . . . . . . . . 38 2.3.1.4 Programmation linéaire . . . . . . . . . . . . . 39 2.3.1.5 Programmation dynamique . . . . . . . . . . . 40 2.3.1.6 Les Réseaux de flots . . . . . . . . . . . . . . . 40 2.3.2 Méthodes approchées . . . . . . . . . . . . . . . . . . . . 41 2.3.2.1 Méthodes de recherche non guidées ou métaheuristiques . . . . . . . . . . . . . . . . . . . 41 2.3.2.1.1 Recuit simulé . . . . . . . . . . . . . 41 2.3.2.1.2 Recherche Tabou . . . . . . . . . . . 41 2.3.2.1.3 Algorithmes génétiques . . . . . . . . 42 2.3.2.2 Méthodes guidées ou heuristiques . . . . . . . . 42 2.3.2.2.1 Heuristiques gloutonnes . . . . . . . . 43 2.3.2.2.2 Heuristiques de listes . . . . . . . . . 44 2.3.2.2.3 Heuristiques de regroupement ou "clustering" . . . . . . . . . . . . . . . . . 44 2.3.2.2.4 Heuristique de duplication de tâches . 45 2.4 Ordonnancement de tâches dépendantes . . . . . . . . . . . . . . 45 2.4.1 Transfert de données . . . . . . . . . . . . . . . . . . . . 46TABLE DES MATIÈRES 3 2.4.2 Partage de ressources . . . . . . . . . . . . . . . . . . . . 46 2.4.3 Protocoles de synchronisation monoprocesseur . . . . . . 48 2.4.3.1 Priority Inheritance Protocol (PIP) . . . . . . . 48 2.4.3.2 Priority Ceiling Protocol (PCP) . . . . . . . . . 49 2.4.3.3 Stack Resource Policy (SRP) . . . . . . . . . . 49 2.4.4 Protocoles de synchronisation multiprocesseur . . . . . . 50 2.4.4.1 MPCP . . . . . . . . . . . . . . . . . . . . . . 50 2.4.4.2 MSRP . . . . . . . . . . . . . . . . . . . . . . 50 2.5 Ordonnancement avec prise en compte du coût de l’OS . . . . . . 50 2.5.1 Coût de l’ordonnanceur . . . . . . . . . . . . . . . . . . . 51 2.5.2 Coût de la préemption . . . . . . . . . . . . . . . . . . . 51 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 II Ordonnancement temps réel multiprocesseur de tâches indépendantes avec prise en compte du coût exact de la pré- emption 55 3 Ordonnancement monoprocesseur de tâches indépendantes 57 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3 Intervalle d’étude de l’ordonnancement . . . . . . . . . . . . . . 58 3.4 Opération binaire d’ordonnancement ⊕ . . . . . . . . . . . . . . 58 3.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5 Analyse d’ordonnançabilité avec ⊕ . . . . . . . . . . . . . . . . . 60 3.6 Facteur d’utilisation du processeur avec coût de la préemption . . 62 3.7 Impact du coût de la préemption dans l’analyse d’ordonnançabilité 62 3.8 Viabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4 Ordonnancement multiprocesseur de tâches indépendantes 69 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2 Modèle de tâches et d’architecture . . . . . . . . . . . . . . . . . 69 4.3 Heuristique d’ordonnancement . . . . . . . . . . . . . . . . . . . 70 4.3.1 Fonction de coût . . . . . . . . . . . . . . . . . . . . . . 70 4.3.2 Principe de l’heuristique . . . . . . . . . . . . . . . . . . 71 4.4 Étude de performances . . . . . . . . . . . . . . . . . . . . . . . 71 4.4.1 Heuristiques BF et W F . . . . . . . . . . . . . . . . . . 73 4.4.2 Algorithme exact B&B . . . . . . . . . . . . . . . . . . 76 4.4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 764 TABLE DES MATIÈRES 4.4.3.1 Comparaison des temps d’exécution . . . . . . 76 4.4.3.2 Comparaison des taux de succès . . . . . . . . 79 4.4.3.3 Comparaison des temps de réponse de l’ordonnancement des tâches . . . . . . . . . . . . . . 80 4.4.3.4 Comparaison des moyennes des facteurs d’utilisation restants . . . . . . . . . . . . . . . . . 81 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 III Ordonnancement temps réel multiprocesseur de tâches dépendantes avec prise en compte du coût exact de la pré- emption 83 5 Ordonnancement monoprocesseur de tâches dépendantes 85 5.1 Modèle de tâches et notations . . . . . . . . . . . . . . . . . . . . 86 5.1.1 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . 86 5.1.2 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Intervalle d’étude de l’ordonnancement . . . . . . . . . . . . . . 88 5.3 Mécanisme de transfert de données . . . . . . . . . . . . . . . . . 88 5.4 Synchronisation de l’accès aux mémoires de données . . . . . . . 91 5.5 Analyse d’ordonnançabilité hors ligne . . . . . . . . . . . . . . . 93 5.5.1 Sélection de la tâche à exécuter . . . . . . . . . . . . . . 94 5.5.2 Durée restant à exécuter avec coût exact de la préemption 96 5.5.3 Échéance relative à une date d’appel de l’ordonnanceur . . 98 5.5.4 Condition d’ordonnançabilité . . . . . . . . . . . . . . . 98 5.5.5 Prochaine date d’appel de l’ordonnanceur hors ligne . . . 100 5.5.6 Algorithme d’analyse d’ordonnançabilité monoprocesseur 101 5.5.7 Application . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.6 Viabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6 Ordonnancement multiprocesseur de tâches dépendantes 107 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.3 Modèle d’architecture . . . . . . . . . . . . . . . . . . . . . . . . 108 6.4 Allocation des tâches aux processeurs . . . . . . . . . . . . . . . 109 6.4.1 Condition nécessaire d’ordonnançabilité . . . . . . . . . 109 6.4.2 Fonction de coût . . . . . . . . . . . . . . . . . . . . . . 111 6.4.3 Heuristique d’allocation . . . . . . . . . . . . . . . . . . 112 6.5 Analyse d’ordonnançabilité multiprocesseur . . . . . . . . . . . 113 6.5.1 Communication inter-processeurs . . . . . . . . . . . . . 114TABLE DES MATIÈRES 5 6.5.2 Analyse d’ordonnançabilité des tâches allouées à un processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.5.3 Condition d’ordonnançabilité multiprocesseur . . . . . . . 121 6.5.4 Algorithme d’analyse d’ordonnançabilité multiprocesseur 121 6.6 Heuristique d’ordonnancement multiprocesseur de tâches dépendantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.8 Étude de performance . . . . . . . . . . . . . . . . . . . . . . . . 128 6.8.1 Générateur de graphes de tâches dépendantes . . . . . . . 133 6.8.2 Graphe de processeurs . . . . . . . . . . . . . . . . . . . 136 6.8.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.8.3.1 Temps d’exécutions des algorithmes . . . . . . 136 6.8.3.2 Taux de succès . . . . . . . . . . . . . . . . . . 138 6.8.3.3 Makespan . . . . . . . . . . . . . . . . . . . . 139 6.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7 Ordonnanceur en ligne avec prise en compte du coût exact de la pré- emption 143 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.2 Principe de l’ordonnanceur . . . . . . . . . . . . . . . . . . . . . 143 7.3 Implantation de l’ordonnanceur . . . . . . . . . . . . . . . . . . . 145 7.4 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 7.5 Gestion des communications inter-processeurs . . . . . . . . . . . 149 7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Conclusion générale et perspectives 153 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Table des figures 1.1 Système réactif temps réel . . . . . . . . . . . . . . . . . . . . . 18 1.2 Paramètres dynamiques de l’instance k de τi . . . . . . . . . . . . 20 1.3 Exemple de graphe de dépendances . . . . . . . . . . . . . . . . 22 1.4 Illustration de la latence d’un graphe de tâches . . . . . . . . . . 22 1.5 États et transitions d’une tâche . . . . . . . . . . . . . . . . . . . 27 2.1 Illustration des pertes de données . . . . . . . . . . . . . . . . . . 47 2.2 Inversion de priorités . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3 Inter-blocage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.4 Illustration du coût de l’ordonnanceur . . . . . . . . . . . . . . . 51 2.5 Illustration du coût de la préemption . . . . . . . . . . . . . . . . 52 3.1 Illustration du PET de l’instance k de τ2 . . . . . . . . . . . . . . 60 3.2 Opération ⊕ entre deux tâches . . . . . . . . . . . . . . . . . . . 66 3.3 Impact du coût de la préemption . . . . . . . . . . . . . . . . . . 67 4.1 Comparaison des temps d’exécution avec variation du nombre de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.2 Comparaison des temps d’exécution avec variation du nombre de processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.3 Comparaison des taux de succès . . . . . . . . . . . . . . . . . . 79 4.4 Comparaison des temps de réponse de l’ordonnancement des tâches 80 4.5 Comparaison des moyennes des facteurs d’utilisations restants sur les processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1 Graphe G5 de dépendances de données . . . . . . . . . . . . . . . 86 5.2 Illustration des mémoires de données . . . . . . . . . . . . . . . 86 5.3 Graphe G3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4 Illustration du transfert de données des tâches dans G3 . . . . . . 90 5.5 Motifs d’exécution des tâches de Γ3 . . . . . . . . . . . . . . . . 90 5.6 Illustration du principe d’héritage de priorités . . . . . . . . . . . 92 5.7 Illustration de c1(t) et c2(t) . . . . . . . . . . . . . . . . . . . . . 978 TABLE DES FIGURES 5.8 Illustration de di(t) . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.9 Illustration des dates d’appel de l’ordonnanceur . . . . . . . . . . 102 5.10 Graphe G ′ 3 représentant Γ3 . . . . . . . . . . . . . . . . . . . . . 102 5.11 Résultat de l’ordonnancement de Γ3 . . . . . . . . . . . . . . . . 105 6.1 Illustration d’un graphe d’architecture . . . . . . . . . . . . . . . 108 6.2 Illustration de r (1,k) j et Dk j . . . . . . . . . . . . . . . . . . . . . . 111 6.3 Illustration de la marge d’exécution de τj . . . . . . . . . . . . . 112 6.4 Illustration d’un processeur de communication . . . . . . . . . . . 115 6.5 Illustration d’une communication entre deux processeurs . . . . . 116 6.6 Graphe G8 de dépendances de données . . . . . . . . . . . . . . . 124 6.7 Graphe d’architecture de P2 . . . . . . . . . . . . . . . . . . . . 124 6.8 Résultat de l’ordonnancement des tâches sur p1 et sur p2 . . . . . 132 6.9 Comparaison des durées d’exécution des algorithmes . . . . . . . 137 6.10 Comparaison des durées d’exécution des algorithmes . . . . . . . 138 6.11 Comparaison des taux de succès des algorithmes . . . . . . . . . 139 6.12 Comparaison des makespan . . . . . . . . . . . . . . . . . . . . . 140 7.1 Exemple de déroulement de l’algorithme 12 . . . . . . . . . . . . 150 clearemptydoublepageListe des tableaux 5.1 Résumé des notations . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Table d’ordonnancement de Γ3 . . . . . . . . . . . . . . . . . . . 104 6.1 Table d’ordonnancement du processeur p1 . . . . . . . . . . . . . 129 6.2 Table d’ordonnancement du processeur p2 . . . . . . . . . . . . . 130 6.3 Table d’ordonnancement du processeur de communication pcom12 131 7.1 Table d’ordonnancement T de τ1 et τ2 . . . . . . . . . . . . . . . 149Introduction générale Contexte Cette thèse s’inscrit dans le cadre des recherches menées dans l’équipe-projet AOSTE (Analyse et Optimisation des Systèmes Temps réel Embarquée) d’INRIA Paris-Rocquencourt sur les systèmes distribués temps réel embarqués que l’on trouve dans les domaines applicatifs tels que l’automobile, l’avionique, le ferroviaire, etc. Ces systèmes étant critiques, il faut assurer que les contraintes temps réel et les contraintes de ressources sont satisfaites au risque de conséquences catastrophiques, par exemple de pertes humaines. Satisfaire ces contraintes temps réel et de ressources est d’autant plus difficile que les architectures cibles actuelles sont multicomposant (multiprocesseur, distribués, multi/many-core, parallèles). Les spécifications fonctionnelles et les simulations réalisées par les automaticiens conduisent à ce que les fonctions, qui deviendront des tâches temps réel, aient des périodes différentes, des dépendance entre elles, des contraintes d’échéance et de latence. Afin d’assurer que les conditions d’ordonnançabilités temps réel soient réellement respectées lorsqu’une application s’exécute en temps réel sur une architecture cible, il faut prendre en compte dans l’analyse d’ordonnançabilité le coût du système d’exploitation (OS pour “Operating System”) qui réalise effectivement l’ordonnancement pendant la vie de l’application, mais qui est en général approximé, voire négligé. Ceci conduit au mieux à du gaspillage de ressources et au pire au non respect des contraintes temps réel lors du fonctionnement de l’application. Objectifs Le coût du système d’exploitation est composé de deux parties : une partie facile à déterminer, correspondant au coût de l’ordonnanceur et une partie dif- ficile à déterminer, correspondant au coût de la préemption. Cette difficulté est due au fait qu’une préemption peut en engendrer une autre, pouvant ainsi créer un phénomène d’avalanche [Yom09]. Meumeu et Sorel [Yom09] ont proposé une12 LISTE DES TABLEAUX condition d’ordonnançabilité qui permet de prendre en compte le coût exact de la préemption, donc le coût de l’OS. Mais cette condition d’ordonnançabilité n’est applicable qu’à des tâches indépendantes à priorités fixes et sur une architecture monoprocesseur. Notre premier objectif est d’étendre cette condition d’ordonnan- çabilité pour étudier l’ordonnancement de tâches temps réel indépendantes sur une architecture multiprocesseur et en tenant compte du coût exact de la préemption. Les applications temps réel embarquées étant généralement composées de tâches dépendantes, notre deuxième objectif est d’étudier l’ordonnancement de tâches dépendantes sur une architecture multiprocesseur et toujours avec prise en compte du coût exact de la préemption. Pour cela nous allons étudier une nouvelle condition d’ordonnançabilité pour des tâches dépendantes, qui permet de prendre en compte le coût exact de la préemption puisque la condition d’ordonnançabilité proposée par Meumeu et Sorel est applicable uniquement pour des tâches indépendantes à priorités fixes et ne permet donc pas de gérer les inversions de priorités que peut entraîner l’ordonnancement de tâches dépendantes. Enfin notre troisième et dernier objectif est, à partir de l’analyse d’ordonnançabilité que nous avons proposée, d’utiliser la table d’ordonnancement déterminée hors ligne dans un nouveau type d’ordonnanceur en ligne prenant mieux en compte le coût de l’OS que les ordonnanceurs classiques. Plan de la thèse Ce manuscrit est constitué de trois parties. La première partie est consacrée aux concepts de bases de l’ordonnancement temps réel pour faciliter la compréhension de la suite de la thèse et à l’état de l’art dans lequel on met l’accent sur les méthodes d’allocation des tâches dans l’ordonnancement multiprocesseur, sur la prise en compte du coût exact de la préemption et sur les dépendances de données. La deuxième partie est consacrée à l’ordonnancement multiprocesseur de tâches indépendantes avec prise en compte du coût exact de la préemption. Dans le premier chapitre de cette partie on présente la condition d’ordonnançabilité proposée par Meumeu et Sorel qui permet de prendre en compte le coût exact de la préemption en monoprocesseur pour des tâches à priorités fixes. Le deuxième chapitre de cette deuxième partie présente l’étude d’ordonnancement multiprocesseur de tâches indépendantes qui étend la condition d’ordonnançabilité de Meumeu et Sorel en multiprocesseur. La troisième partie est consacrée à l’ordonnancement multiprocesseur de tâches dépendantes. Dans le premier chapitre de cette partie, on étudie l’ordonnancement des tâches dépendantes en monoprocesseur en proposant une nouvelle condition d’ordonnançabilité qui permet d’ordonnancer des tâches dépendantes en prenantLISTE DES TABLEAUX 13 en compte du coût exact de la préemption et les transferts de données entre tâches qui conduisent à des inversions de priorités. Dans le deuxième chapitre de cette partie, on présente l’étude d’ordonnancement multiprocesseur de tâches dépendantes qui étend cette nouvelle condition d’ordonnançabilité monoprocesseur en multiprocesseur tout en tenant compte le coût exact de la préemption et les coûts de communication inter-processeurs. Dans le troisième chapitre de cette partie, on présente l’ordonnanceur en ligne de chaque processeur qui utilise la table d’ordonnancement produite hors ligne, pour ce processeur.Première partie Concepts de base et État de l’artChapitre 1 Concepts de base L’objectif de ce chapitre est de présenter les concepts de base de l’ordonnancement temps réel. 1.1 Système temps réel 1.1.1 Définition Un système réactif doit réagir continûment aux stimuli venant d’un processus qu’il cherche à commander. Un système temps réel est un système réactif qui doit respecter des contraintes de temps. Un système temps réel doit être capable de traiter les informations venant du processus dans un délai qui ne nuit pas à la commande du processus. Réagir trop tard peut conduire à des conséquences catastrophiques pour le système lui-même ou le processus. Le respect des contraintes temporelles est la principale contrainte à satisfaire. La validité d’un système temps réel dépend non seulement des résultats du traitement effectué mais aussi de l’aspect temporel (un calcul juste mais hors délai est un calcul non valable). Dans un système temps réel, les évènements d’entrée sont produits par des capteurs et les évènements de sortie sont consommés par des actionneurs. La figure 1.1 donne une illustration d’un système réactif temps réel. On rencontre des applications temps réel dans le domaine de l’aéronautique, l’automobile, télécommunication, robotique, etc. 1.1.2 Classification des systèmes temps réel La criticité des contraintes temporelles conduit à classifier les système temps réel en trois catégories suivantes :18 Concepts de base Processus Évènements entrée Stimuli Capteurs Évènements sortie Réactions Actionneurs SYSTÈME RÉACTIF TEMPS RÉEL FIGURE 1.1 – Système réactif temps réel – système temps réel strict : c’est un système soumis à des contraintes temporelles strictes, c’est-à-dire pour lequel la moindre faute temporelle peut avoir des conséquences humaines ou économiques catastrophiques. La plupart des applications dans les domaines avioniques, automobile, etc., sont temps réel strict; – système temps réel souple : c’est un système soumis à des contraintes temporelles souples, un certain nombre de fautes temporelles peut être tolérées. On parle alors de qualité de service; – système temps réel mixte : c’est un système soumis à des contraintes temporelles strictes et à des contraintes temporelles souples. 1.2 Tâche temps réel Une tâche temps réel est formée d’un ensemble d’instructions pouvant s’exé- cuter en séquence sur un ou plusieurs processeurs et respecter des contraintes de temps. Dans la suite nous ferons l’hypothèse qu’une tâche ne s’exécutera pas en parallèle. Elle peut se répéter un nombre quelconque de fois, éventuellement infini. Chacune de ses exécutions est appelée instance ou travail ("job"). Un système temps réel est composé d’un ensemble de tâches temps réel soumises à des contraintes temps réel (voir la section 1.4). Une tâche temps réel peut être : – périodique : ses instances (exécutions) se répètent indéfiniment et il existe une durée constante entre deux activations d’instances successives appelée période, – sporadique : ses instances (exécutions) se répètent indéfiniment et il existe une durée minimum entre deux instances successives, – apériodique : il y a pas de corrélation entre deux instances successives.1.3 Tâches périodiques 19 1.3 Tâches périodiques Le modèle de tâches périodiques classique dit de Liu et Layland de [LL73] est le plus utilisé dans la modélisation des systèmes temps réel. Ce modèle permet de définir plusieurs paramètres pour une tâche. Ces paramètres sont de deux types : paramètres statiques relatifs à la tâche elle-même et les paramètres dynamiques relatif à chaque instance de la tâche. Les paramètres statiques de base d’une tâche périodique τi = (r 1 i , Ci , Di , Ti) sont : – r 1 i (release time) : date de première activation de la tâche τi , date à laquelle τi peut commencer sa toute première exécution, – Ci (computing time) : durée d’exécution de τi . Ce paramètre est considéré dans plusieurs travaux sur l’ordonnancement temps réel comme le pire cas des temps d’exécution (WCET pour Worst Case Execution Time) sur le processeur sur lequel elle va s’exécuter; – Di : échéance relative ou délai critique relatif à chaque activation de τi , – Ti : période d’exécution de τi . D’autres paramètres statiques sont dérivés des paramètre de base : – ui = Ci Ti : le facteur d’utilisation du processeur par τi , ui ≤ 1, – CHi = Ci Di : la densité de la tâche τi , CHi ≤ 1. Les paramètres dynamiques d’une tâches déterminent le comportement pendant l’exécution de la tâche τi . Ces paramètres sont définis pour chaque instance k noté τ k i par : – r k i (release time) : date à laquelle τ k i peut commencer son exécution appelée date d’activation ou date de réveil de la tâche, – s k i , f k i : respectivement la date de début d’exécution effective et date de fin d’exécution de τ k i , – Rk i : temps de réponse de τ k i donné par Rk i = f k i − r k i . Le pire temps de réponse de τi noté Ri est défini par Ri = max{Rk i }k≥1; – d k i = r k i + Di : échéance absolue de τ k i relative à r k i , c’est la date dont le dépassement entraîne une faute temporelle, – L k i (t) (laxity) : c’est la laxité de l’instance τ k i à la date t, qui représente le retard maximum pour reprendre l’exécution de la tâche τi quand elle s’exé- cute seule. 1.3.1 Tâches concrètes/non concrètes Si toutes les dates de première activation de toutes les tâches sont connues on dit que les tâches sont concrètes. Au contraire si on ne connaît pas ces dates de première activation on dit que ces tâches sont non concrètes.20 Concepts de base r k s i + Ti k i f k i Rk i Ci Lk i (t) Di r k i t Ti τ k i d k i FIGURE 1.2 – Paramètres dynamiques de l’instance k de τi 1.3.2 Tâches synchrones/asynchrones Si toutes les tâches sont concrètes et ont les mêmes dates de première activation, on dit que les tâches sont à activations synchrones. Sinon, elles sont asynchrones. 1.4 Contraintes temps réel Dans l’ordonnancement temps réel, les tâches peuvent être soumises à plusieurs contraintes telles que des contraintes d’échéances, de périodicité stricte, de dépendances et de précédences, etc. 1.4.1 Échéances Les contraintes d’échéances permettent d’exprimer une condition sur la date de fin d’exécution au plus tard d’une tâche. Considérons un système de tâches périodiques, suivant la relation entre la période Ti et l’échéance relative Di de chaque tâche τi nous distinguons trois types d’échéances : – Di = Ti : à chaque activation de τi , la tâche τi doit être exécutée avant sa prochaine activation. On parle de tâches à échéances sur activations, échéances implicites, ou échéances sur requêtes; – Di ≤ Ti : à chaque activation de τi , la tâche τi doit être exécutée au plus tard à une date inférieure ou égale à la date de sa prochaine activation. On parle de tâches à échéances contraintes; – Di 6= Ti : il n’y a pas de corrélation entre la date de fin d’exécution au plus tard de τi lors d’une activation et sa prochaine activation de τi . On peut avoir Di ≤ Ti ou Di > Ti , on parle de tâches à échéances arbitraires.1.4 Contraintes temps réel 21 1.4.2 Périodicité stricte Considérons une tâche périodique τi dans un système de tâches temps réel, une contrainte de périodicité stricte impose que le temps qui s’écoule entre deux dates de début d’exécution consécutives s k i et s k+1 i corresponde exactement à la période de la tâche τi . L’intérêt de cette contrainte est que la connaissance de la date de début effective de la première instance s 1 i de τi implique la connaissance de la date de début effective de toutes les instances suivantes de la même tâche [Cuc04], cela s’exprime par la relation s k+1 i = s 1 i + kTi , ∀k ≥ 1. C’est une contrainte qui est utile pour les tâches correspondant aux capteurs et actionneurs et les traitements réalisant une boucle de commande d’un processus. 1.4.3 Dépendances entre tâches Une dépendance entre deux tâches τi et τj peut être de deux types : une dépendance de précédence et/ou une dépendance de données. Une dépendance de pré- cédence entre (τi , τj ) impose que la tâche τj commence son exécution après que la tâche τi ait complètement fini de s’exécuter [Cuc04, HCAL89, CL87, Xu93]. Les contraintes de précédences sont indirectement des contraintes temps réel et on dit que la tâche τi est un prédécesseur de la tâche τj et τj est un successeur de τi . Si τi s’exécute exactement une fois avant une exécution de τj on a une contrainte de précédence simple sinon une contrainte de précédence étendue [RCR01, FGPR11, PFB+11]. Une dépendance de données signifie que la tâche τi produit une donnée qui est consommée par τj [Cuc04, HCAL89], cette dépendance entraîne forcément une précédence entre les tâches. Les tâches sont dites indépendantes lorsqu’elles ne sont définies que par leurs paramètres temporels. L’ensemble des dépendances entre les tâches peut être modélisé par un graphe orienté où les sommets représentent les tâches et l’ensemble des arcs la relation de dépendances entre les tâches. Cette relation est antisymétrique et transitive, c’est donc une relation d’ordre sur l’exécution des tâches. C’est une relation d’ordre partiel car certaines tâches ne sont pas dépendantes. Un exemple de graphe de dépendances de tâches est présenté sur la figure 5.1. On distingue deux types de dépendances de données : – sans pertes de données : les données, produites par chaque instance de la tâche productrice sont toutes consommées par l’instance de la tâche consommatrice, – avec pertes de données : la tâche consommatrice peut perdre des données qui sont écrasées par d’autres données produites par l’exécution d’autres instances de la tâche productrice.22 Concepts de base τ3 τ4 τ1 τ2 FIGURE 1.3 – Exemple de graphe de dépendances 1.4.4 Latence La latence est définie pour des tâches dépendantes éventuellement par transitivité dans le cas d’un chemin de tâches. Soient τi et τj deux liées par un chemin dans un graphe de tâches dépendantes. La latence entre τi et τj notée L(τi , τj ) est la durée entre le début d’exécution de τi et la fin d’exécution de τj . La figure 1.4 donne une illustration de la latence entre deux tâches. τ1 τ2 τ3 τ4 L(τ1, τ3) FIGURE 1.4 – Illustration de la latence d’un graphe de tâches Une contrainte de latence entre τi et τj signifie que L(τi , τj ) doit être inférieure ou égale à une certaine valeur. 1.5 Ordonnancement des systèmes temps réel 1.5.1 Algorithmes d’ordonnancement Un système temps réel est constitué d’un ou plusieurs processeurs et d’un ensemble de tâches ayant des contraintes temps réel. Un algorithme d’ordonnancement détermine l’ordre total et les dates de démarrage des exécutions des tâches sur un ou plusieurs processeurs. Il existe plusieurs classes d’algorithmes d’ordonnancement temps réel.1.5 Ordonnancement des systèmes temps réel 23 Monoprocesseur/Multiprocesseur L’ordonnancement est de type monoprocesseur si toutes les tâches s’exécutent sur un seul processeur. Si les tâches peuvent s’exécuter sur plusieurs processeurs l’ordonnancement est multiprocesseur. Préemptif/Non préemptif Un algorithme d’ordonnancement est préemptif lorsqu’une tâche s’exécutant sur un processeur peut être suspendue au profit d’une tâche, dite plus prioritaire, puis reprendre son exécution plus tard. Dans le cas contraire il est non préemptif. En ligne/Hors ligne Un algorithme d’ordonnancement hors ligne (“off-line” en anglais) construit la séquence complète des dates de début d’exécution des tâches sur la base des paramètres temporels. Cette séquence est connue avant l’exécution de l’ensemble des tâches. En pratique, l’ordonnancement a la forme d’un plan hors ligne (ou statique), exécuté de façon répétitive ou cyclique. Un ordonnancement en ligne (“on-line” en anglais) construit la séquence des dates de début d’exécution des tâches à partir des paramètres temporels des tâches pendant l’exécution de l’ensemble des tâches. Les algorithmes en ligne sont plus robustes vis-à-vis des dépassements des WCETs. Priorité fixe/dynamique Un algorithme d’ordonnancement est à priorités fixes, si les priorités des tâches sont basées sur des paramètres statiques (par exemple la période). Il existe des algorithmes d’ordonnancement à priorités fixes aux tâches et d’autres qui sont à priorité fixes aux instances (“job”). Un algorithme d’ordonnancement est à priorités dynamiques, si les priorités des tâches sont basées sur des paramètres dynamiques (par exemple la laxité). Optimal/Non optimal Par définition, un algorithme d’ordonnancement optimal pour une classe de problème d’ordonnancement donnée (hors ligne, en ligne, priorités fixes ou dynamiques, etc.) est tel que : si un système est ordonnançable par au moins un algorithme de la même classe, alors le système est aussi ordonnançable par l’algorithme d’ordonnancement optimal. En conséquence, si un système n’est pas24 Concepts de base ordonnançable par l’algorithme d’ordonnancement optimal d’une classe donnée, alors il ne l’est pas par aucun autre algorithme d’ordonnancement de la même classe. 1.5.2 Analyse de faisabilité Une analyse de faisabilité d’un ensemble de tâches permet de déterminer s’il existe un algorithme d’ordonnancement qui peut ordonnancer cet ensemble de tâches. La condition que doit vérifier l’ensemble des tâches pour être faisable est appelée condition de faisabilité. 1.5.3 Analyse d’ordonnançabilité Une analyse d’ordonnançabilité d’un ensemble de tâches permet de vérifier si cet ensemble de tâches est ordonnançable relativement à un algorithme d’ordonnancement, c’est-à-dire vérifier que toute instance de chaque tâche respecterason échéance. La condition que doit vérifier l’ensemble des tâches pour être ordonnançable est appelée condition d’ordonnançabilité. Définition 1.5.1 Une condition d’ordonnançabilité suffisante est une condition qui lorsqu’elle est vérifiée par toutes les tâches assure que celles-ci sont ordonnançables. Dans le cas contraire, elles ne sont pas forcément non ordonnançables. Définition 1.5.2 Une condition d’ordonnançabilité nécessaire est une condition qui lorsqu’elle n’est pas vérifiée par toutes les tâches assure que celles-ci ne sont pas ordonnançables. Dans le cas contraire, elles ne sont pas forcément ordonnan- çables. Définition 1.5.3 Une condition d’ordonnançabilité nécessaire et suffisante est une condition qui lorsqu’elle n’est pas vérifiée par toutes les tâches assure que celles-ci ne sont pas ordonnançables et dans le cas contraire assure que celles-ci sont ordonnançables. Une analyse d’ordonnançabilité peut se faire selon deux approches. 1.5.3.1 Approche analytique L’analyse d’ordonnançabilité par approche analytique consiste à identifier le ou les pires cas d’exécution et de déterminer analytiquement une condition d’ordonnançabilité des tâches. Dans cette approche on peut utiliser :1.6 Viabilité d’une condition d’ordonnançabilité 25 – le facteur d’utilisation des tâches : dans certains cas le facteur d’utilisation des tâches permet de conclure si un ensemble de tâches est ordonnançable ou non, – le pire temps de réponse : le pire temps de réponse d’une tâches est calculé puis comparé à son échéance. Si une tâche a un pire temps de réponse inférieur ou égal à son échéance relative alors elle est ordonnançable; – le temps de demande processeur : c’est le temps requis par le processeur pour exécuter un ensemble de tâches activées puis terminées dans un intervalle donné. Si ce temps est inférieur à la longueur de l’intervalle considéré alors les tâches activées dans cet intervalle sont faisables. Sinon les tâches ne sont pas faisables. 1.5.3.2 Approche par simulation L’approche par simulation revient à faire l’analyse temporelle de l’exécution des tâches temps réel. Lorsque les tâches sont périodiques, cette exécution dure indéfiniment. Il suffit alors de faire l’analyse temporelle sur un intervalle fini appelé intervalle d’étude de l’ordonnancement [LM80, Goo99]. Ainsi si toutes les tâches respectent leurs contraintes sur cet intervalle alors le système de tâches est ordonnançable. 1.6 Viabilité d’une condition d’ordonnançabilité Une condition d’ordonnançabilité est dite viable (“sustainable”) si l’ordonnancement trouvé grace à cette condition d’ordonnançabilité reste valide lors de l’exécution quand intervient un changement intuitivement positif c’est-à-dire par exemple la dimunition de la durée d’exécution d’une tâche, l’augmentation de la période d’une tâche ou de l’échéance relative, etc. Dans ce travail, on suppose que les périodes et les échéances ne seront pas modifiées. Donc nous considérons qu’une condition d’ordonnançabilité est viable (“sustainable”) lorsque l’ordonnancement qu’elle trouve reste valide même si la durée d’exécution d’une tâche diminue lors de son exécution. 1.7 Ordonnanceur Un ordonnanceur temps réel est un programme temps réel chargé d’allouer une ou des tâche(s) à ordonnancer au(x) processeur(s). Il est invoqué à certains instants. Et ceci suivant un algorithme ordonnancement donné de tel sorte que toutes les tâches respectent leurs contraintes temps réel.26 Concepts de base 1.7.1 Invocation de l’ordonnanceur Il existe plusieurs manières d’invoquer un ordonnanceur : – invocation guidée par les évènements (Event-Trigger ET) [CMTN08] : l’ordonnanceur est invoqué sur réception d’un évènement tel que l’activation d’une tâche, la libération d’une ressource (processeur, périphériques d’entrées et de sorties, etc.), la fin d’exécution d’une tâche. Ce mode d’invocation est utilisé dans l’ordonnancement en ligne qui prend les décisions d’ordonnancement en fonction des évènements qui se produisent lors de l’exécution des tâches; – invocation guidée par le temps (Time-Trigger TT) [Kop98] : les invocations sont indépendantes des évènements. Les dates d’invocation de l’ordonnanceur sont fixées avant l’exécution des tâches et sont généralement périodiques. Cela définit des tranches de temps (slot) pendant lesquelles on peut effectuer un traitement, alors que dans les approches dirigées par les évènements (Event-Trigger) le traitement est directement activé par un événement. Ce mode d’invocation de l’ordonnanceur est utilisé dans l’ordonnancement hors ligne où toutes les décisions d’ordonnancement ont été prises hors ligne. 1.7.2 États et gestion des tâches Le partage du ou des processeur(s) et des ressources introduit plusieurs états pour une tâche : – Inactif : la tâche n’est pas encore activée, – Prêt : la tâche est activée et elle dispose de toutes les ressources dont elle a besoin pour s’exécuter, – Bloqué : la tâche est en attente de ressources, – Exécution : la tâche s’exécute, – Passif : la tâche n’a pas de requête en cours, elle a fini son exécution. L’ordonnanceur est chargé d’assurer la transition d’une tâche d’un état à un autre. À chaque invocation, l’ordonnanceur met à jour la liste des tâches prêtes en y ajoutant toutes les tâches activées et qui disposent de leurs ressources et en supprimant les tâches qui ont fini leurs exécutions ou qui sont bloquées par l’attente d’une ressource. Ensuite parmi les tâches prêtes, l’ordonnanceur sélectionne la tâche la plus prioritaire pour s’exécuter. Ainsi, une tâche dans l’état inactif peut passer à l’état prêt. Une tâche à l’état prêt peut passer à l’état exécution ou à l’état bloqué. Une tâche à l’état exécution peut revenir à l’état prêt si elle est préemptée par une autre tâche plus prioritaire, elle peut passer à l’état bloqué si elle attend la1.8 Conclusion 27 libération d’une ressource ou si elle a fini son exécution, elle passe à l’état passif. Une tâche peut passer de l’état bloqué à l’état prêt. Et enfin une tâche peut passer de l’état passif à l’état prêt. La figure 1.5 donne une illustration des différents états et leurs transitions. ré-activation blocage activation Bloqué Exécution P assif Inactif P rêt sélection préemption terminaison déblocage FIGURE 1.5 – États et transitions d’une tâche 1.8 Conclusion Dans ce chapitre nous avons présenté les concepts de base de l’ordonnancement temps réel que nous aurons à utiliser dans la suite de cette thèse. Dans le chapitre qui suit nous allons présenter un état de l’art l’ordonnancement temps réel.28 Concepts de baseChapitre 2 État de l’art Après avoir défini les concepts de base de l’ordonnancement temps réel, nous présentons dans ce chapitre un état de l’art de l’ordonnancement temps réel monoprocesseur et multiprocesseur. 2.1 Ordonnancement monoprocesseur 2.1.1 Priorités fixes 2.1.1.1 Priorités fixes aux tâches Une priorité fixe aux tâches est une priorité qui ne varie pas au cours de l’exé- cution de la tâche. Les algorithmes d’ordonnancement à priorités fixes aux tâche les plus utilisés sont “Rate Monotonic” et “Deadline Monotonic”. Rate Monotonic (RM) L’algorithme d’ordonnancement RM a été introduit par Liu et Layland en 1973 [LL73]. C’est un algorithme d’ordonnancement préemptif qui s’applique à des tâches périodiques indépendantes, et à échéance sur requête (Ti = Di). La priorité d’une tâche est inversement proportionelle à sa période, c’est-à-dire que plus la période d’une tâche est petite, plus sa priorité est grande. Cet algorithme est optimal dans la classe des algorithmes à priorités fixes pour les tâches indépendantes préemptibles à échéance sur requête non conrètes ou synchrones. Une condition suffisante d’ordonnançabilité de l’algorithme d’ordonnancement RM [LL73] pour un ensemble de tâches périodiques Γn à échéance sur requête est donnée par : Xn i=1 Ci Ti ≤ n(2 1 n − 1)30 État de l’art Deadline Monotonic (DM) L’algorithme d’ordonnancement DM a été introduit par Leung et Whitehead en 1982 [LW82] pour des tâches à échéance sur contrainte. La priorité d’une tâche est inversement proportionelle à son échéance relative, c’est-à-dire que plus l’échéance relative d’une tâche est petite, plus sa priorité est grande. Cet algorithme est optimal dans la classe des algorithmes préemptif à priorités fixes pour les tâches indépendantes préemptibles à échéance contrainte (Di ≤ Ti). La condition suffi- sante d’ordonnançabilité de l’algorithme d’ordonnancement DM [LW82] pour un ensemble de tâches périodiques Γn à échéance sur contrainte est donnée par : ∀τi ∈ Γn, Ci + X j∈hp(τi) ⌈ Di Tj ⌉.Ci ≤ Di avec hp(τi) est l’ensemble de tâches de Γn de priorités supérieures ou égales à celle de τi , n’incluant pas τi . Analyse du temps de réponse Le temps de réponse des tâches peut être utilisé pour faire l’analyse d’ordonnançabilité. Ainsi Joseph and Pandya [JP86] ont proposé une condition d’ordonnançabilité nécessaire et suffisante basée sur le calcul du pire temps réponse. Si Γn, un ensemble de tâches, est ordonnancé par un algorithme à priorités fixes aux tâches, le pire temps de réponse de τi ∈ Γn est donné par le plus petit point fixe (supérieur à Ci) de : Ri = Ci + X j∈hp(τi) ⌈ Ri Ti ⌉.Ci (2.1) avec hp(τi) est l’ensemble de tâches de Γn de priorités supérieures ou égales à celle de τi . Déterminer la valeur de Ri pour τi est équivalent à résoudre le point fixe 2.1. Ainsi dans le cas des échéances contraintes, Γn est ordonnançable par l’ordonnancement à priorités fixes aux tâches si et seulement si : ∀τi ∈ Γn, Ri ≤ Di 2.1.1.2 Priorités fixes aux instances Une priorité fixe au niveau des instances est une priorité qui ne varie pas au cours de l’exécution des instances. L’algorithme d’ordonnancement à priorités fixes aux instances le plus utilisé est “Earliest Deadline First”.2.2 Ordonnancement multiprocesseur 31 Earliest Deadline First (EDF) L’algorithme d’ordonnancement EDF a été introduit par Lui et Layland en 1973 [LL73]. C’est un algorithme d’ordonnancement qui peut être préemptif ou non préemptif et qui s’applique à des tâches périodiques indépendantes à échéance sur requête (Ti = Di). La plus grande priorité à la date t est allouée à la tâche dont l’échéance absolue est la plus proche. EDF est optimal pour les tâches indépendantes préemptibles. Une condition d’ordonnançabilité nécessaire et suffisante de EDF pour un ensemble de tâches périodiques à échéance sur requête noté Γn est donnée par : ∀τi ∈ Γn, Xn i=1 Ci Ti ≤ 1 2.1.2 Priorités dynamiques Une priorité dynamique varie durant l’exécution d’une instance. L’algorithme d’ordonnancement à priorités dynamiques le plus utilisé est “Least laxity Fisrt”. Least-Laxity First(LLF) L’algorithme d’ordonnancement LLF se base sur la laxité. La tâche dont la laxité est la plus faible comparée à toutes les tâches prêtes aura la plus grande priorité [Mok83]. Cet algorithme est optimal pour les tâches indépendantes pré- emptibles. D’après [CDKM00], la condition d’ordonnançabilité de LLF et celle de EDF sont les mêmes. c’est-à-dire que la condition d’ordonnançabilité nécessaire et suffisante de LLF pour un ensemble de tâches périodiques à échéance sur requête Γn est donnée par : ∀τi ∈ Γn, Xn i=1 Ci Ti ≤ 1 Lorsque plusieurs tâches possèdent la même laxité, l’algorithme LLF a l’inconvénient d’engendrer un grand nombre de préemption ce qui explique qu’il soit aussi peu utilisé dans le cas monoprocesseur [Bim07]. 2.2 Ordonnancement multiprocesseur 2.2.1 Architecture multiprocesseur Une architecture multiprocesseur est composée de plusieurs processeurs. Plusieurs tâches peuvent s’exécuter en parallèle sur les différents processeurs. Une32 État de l’art architecture multiprocesseurs peut être composée de : – processeurs identiques : processeurs qui ont la même puissance de calcul, – processeurs uniforme : chaque processeur est caractérisé par sa puissance de calcul (nombre d’instructions traitées par seconde), avec l’interprétation suivante : lorsqu’un travail (instance d’une tâche) s’exécute sur un processeur de puissance de calcul s pendant t unités de temps, il réalise s × t instructions sur ce processeur. La vitesse de progression d’un travail varie d’un processeur à un autre; – processeurs indépendants : un taux d’exécution ri,j est associé à chaque couple de travail-processeur (τ k i , pj ), avec l’interprétation suivante : si le travail τ k i s’exécute sur pj pendant t unités de temps alors τ k i réalise ri,j × t instructions. La vitesse de progression sur un processeur varie d’un travail à un autre. Selon le type de mémoire nous pouvons distinguer : – une architecture multiprocesseur parallèle : les processeurs ont une mémoire partagée par le bais de laquelle ils communiquent, – une architecture multiprocesseur distribuée : chaque processeur à sa propre mémoire et les communications inter-processeurs se font par envoi/réception de messages. 2.2.2 Stratégies d’ordonnancement Considérons un ensemble de n tâches temps réel indépendantes préemptibles à échéances sur requètes noté Γn et une architecture multiprocesseur composée de m processeurs. Un algorithme d’ordonnancement multiprocesseur détermine pour chaque tâche, le processeur sur lequel cette tâche doit s’exécuter (problème d’allocation) et sur chaque processeur, la date et l’ordre de démarrage d’exécution des tâches (problème d’ordonnancement). Dans l’ordonnancement temps réel multiprocesseur nous distinguons deux cas : – nombre de processeurs non fixé [DL78, OS93, OS95], donc nous pouvons utiliser autant de processeurs que nécessaire pour l’ordonnancement, – nombre de processeurs fixé [OB98, BLOS95], donc impossible de dépasser ce nombre. Dans le premier cas nous n’avons pas besoins de faire une analyse d’ordonnançabilité car le système de tâches à ordonnancer sera toujours ordonnançable (il suffit de prendre un processeur par tâche). Par contre dans le cas où le nombre de processeurs est fixé il peut arriver que le système ne soit pas ordonnançable, ce2.2 Ordonnancement multiprocesseur 33 qui nécessite une étude d’ordonnançabilité. L’ordonnancement temps réel multiprocesseur peut être effectué en utilisant la stratégie d’ordonnancement par partitionnement ou la stratégie d’ordonnancement globale. Il existe aussi une stratégie d’ordonnancement hybride dite de semi-partitionnement obtenue par combinaison de la stratégie globale et par partitionnement. Dans la suite de ce documents nous limiterons à utiliser le terme stratégie par partitionnement pour désigner la stratégie d’ordonnancement par partitionnement (respectivement stratégie globale pour désigner stratégie d’ordonnancement global). 2.2.2.1 Stratégie par partitionnement La stratégie par partitionnement [Goo07, DB09, ZA05, AJ] consiste à partitionner l’ensemble des n tâches en m sous-ensembles disjoints (Γ 1 , Γ 2 , · · · , Γ m tels que ∪ m i=1Γ i=Γn et m étant le nombre de processeurs) puis d’ordonnancer chaque sous-ensemble de tâches Γ i sur un processeur pj avec une stratégie d’ordonnancement “locale” monoprocesseur. Il y a un ordonnanceur par processeur. Les tâches allouées aux processeurs ne sont pas autorisées à migrer d’un processeur à l’autre, la préemption ne peut entraîner de migration. La stratégie par partitionnement a l’avantage de ramener le problème d’ordonnancement multiprocesseur en plusieurs problèmes d’ordonnancement monoprocesseur pour lesquels il existe de très nombreuses solutions dans la littérature. Cependant le partitionnement des tâches est NP-difficile [GJ79] car équivalent au problème de “Bin Packing” [CGMV98] qui consiste à ranger un ensemble d’objets de tailles diffé- rentes dans un nombre minimum de boîtes de tailles identiques. Les travaux sur l’ordonnancement temps réel multiprocesseur avec un nombre de processeurs non fixé qui utilisent la stratégie de partitionnement ont principalement comme objectif de minimiser le nombre de processeurs nécessaires à l’ordonnancement. Parmi ces travaux nous avons : – dans la famille des algorithmes d’ordonnancement à priorités fixes aux tâches, Dhall et Liu [DL78], sont les premiers à proposer deux algorithmes pré- emptifs avec des tâches indépendantes et périodiques utilisant les heuristiques de “Bin Packing” (voir 2.3.2.2.1 ) sur processeurs identiques: RateMonotonic-Next-Fit (RM-NF) et Rate-Monotonic-First-Fit (RM-FF). Ces deux algorithmes d’ordonnancement multiprocesseur utilisent Rate Monotonic pour l’ordonnancement des tâches sur chaque processeur et les heuristiques respectivement “next-fit” et “first-fit” comme heuristiques d’allo-34 État de l’art cation des tâches aux processeurs. Dans RM-NF et RM-FF les tâches sont triées dans l’ordre croissant de leurs périodes avant le début de l’allocation. Oh et Son ont repris dans [OS93] ces deux algorithmes d’ordonnancement pour corriger une erreur sur l’évaluation des performances et présentent RM-BF utilisant la méthode d’allocation “best-fit”; – dans [DD86, OS95] est proposé l’algorithme RM First-Fit Decreasing Utilisation Factor (RM-FFDUF), un algorithme similaire à “first-fit” où les tâches sont triées dans l’ordre décroissant de leurs facteurs d’utilisation avant l’allocation; – deux autres algorithmes à priorités fixes aux tâches sont proposés dans [BLOS95]. Ce sont le RM-Small-Tasks (RM-ST) et RM-General-Tasks (RMGT). Le premier algorithme RM-ST alloue les tâches aux processeurs avec l’heuristique “next-fit”, mais partitionne les tâches de telle sorte que β (dé- fini dans le théorème 5 [BLOS95]) ait la plus petite valeur possible. Le deuxième algorithme RM-GT partitionne l’ensemble des tâches en deux groupes selon le critère défini dans [BLOS95], ensuite sur les tâches du premier groupe RM-ST est appliqué, et sur le second groupe de tâches “first-fit” est appliqué, avec la condition d’ordonnançabilité définie dans [LSD89]; – dans le cas des algorithmes d’ordonnancement préemptifs à priorités fixes aux instances, Lopez et al. dans [LDG04] présentent EDF-NF,EDF-FF et EDF-WF, des algorithmes d’ordonnancement multiprocesseur utilisant EDF pour l’ordonnancement et les heuristiques de “bin packing” pour l’allocation des tâches. Au lieu de considérer un nombre infini de processeurs disponibles, d’autres travaux fixent ce nombre et cherchent des conditions d’ordonnançabité pour le système de tâches. Parmi ces travaux : – Oh et Baker [OB98] montrent qu’en appliquant “first-fit” sous RM on peut ordonnancer n’importe quel ensemble de tâches Γ sur m ≥ 2 processeurs identiques. Dans ce même article ils ont démontré qu’avec un algorithme d’ordonnancement multiprocesseur préemptif à priorités fixes aux tâches, le pire facteur d’utilisation des m processeurs noté Umin est borné par : m(21/2 − 1) < Umin ≤ (m + 1)/(1 + 2(m+1)) m étant le nombre de processeurs. Le pire facteur d’utilisation des processeurs Umin est défini tel que si Un = Pn i=1 Ci Ti ≤ Umin alors le système constitué des n tâches est ordonnançable sur les m processeurs; – dans [LDG03] Lopez et al. ont amélioré la borne du facteur d’utilisation définie dans [OB98] et l’ont montrée égale à : URM−F F (n, m) = (m −1)(2(1/2−1)) + (n− m + 1)(21/(n−m+1) −1) (2.2)2.2 Ordonnancement multiprocesseur 35 Ce résultat est particulièrement intéressant dans le cas ou le nombre de processeurs est petit. Si les facteurs d’utilisation des tâches sont plus petits qu’un nombre α alors URM−F F est donné par : URM−F F (n, m, α) = (m−1)(21/(β+1)−1)β+(n−β(m−1))(21/(n−β(m−1))−1) (2.3) Où β = ⌊1/log2(α + 1)⌋. En remplaçant α par 1 dans 2.3 on retrouve 2.2; – Buchard et Liebeher dans [BLOS95] ont calculé les bornes maximales des facteurs d’utilisation des algorithmes RM-ST et RM-GT. Avec un système de m ≥ 2 processeurs, URM−ST = (m − 2)(1 − α) + 1 − ln2, α étant le facteur d’utilisation maximal de l’ensemble des n tâches. Donc l’algorithme RM-ST trouve un partitionnement possible sur un ensemble de m processeurs si la somme des facteurs d’utilisation des tâches périodiques notée Un reste inférieure à URM−ST . Avec RM-GT le résultat est différent, URM−GT est donné par URM−GT = 0.5(m − 1.42) et ne dépend pas de α et si Un ≤ URM−GT alors le systèmes de tâches est ordonnançable. Dans [LGD04] est récapitulé le calcul des bornes maximales et minimales des facteurs d’utilisation permettant de garantir les conditions d’ordonnançabilité d’un ensemble de n tâches sur m processeurs avec RM; – concernant les algorithmes à priorités fixes aux instances, il existe des algorithmes préemptifs basés sur EDF qui fournissent des conditions d’ordonnançabilité utilisant le facteur d’utilisation des processeurs : EDF-FF et EDF-BF dans [LGDG00] avec UEDF −F F = UEDF −BF = βEDF m+1 βEDF +1 (avec βEDF = ⌊ 1 α ⌋ et α représentant le facteur d’utilisation maximal des tâches ); – dans [ESHA94, ESHA90], les algorithmes génétiques sont utilisés pour ré- soudre le problème d’ordonnancement avec des contraintes de précédences. 2.2.2.2 Stratégie globale Une stratégie gloable applique globalement un algorithme d’ordonnancement sur l’ensemble de l’architecture multiprocesseur [Goo07, DB09, ZA05]. Toutes les tâches sont dans la même queue des tâches prêtes qui est partagée par l’ensemble des processeurs. Dans cette queue les m tâches les plus prioritaires sont sélectionnées pour être exécutées sur les m processeurs, par exemple en utilisant globalement RM, EDF, etc. Pour ces stratégies globales outre la préemption des tâches, les migrations de ces dernières sont autorisées. Une tâche peut commencer son exécution sur un processeur (soit pj ), être préemptée par l’arrivée d’une nouvelle tâche plus prioritaire et reprendre son exécution sur un autre processeur (disons pj ′, j′ 6= j). Dans la stratégie globale, nous avons un seul ordonnanceur et préempter une tâches revient éventuellement à la faire migrer vers un autre processeur. C’est ce phénomène de migration de tâches qui caractérise la stratégie36 État de l’art globale. L’avantage de la stratégie d’ordonnancement globale est de permettre une meilleure utilisation des processeurs. Son inconvénient est que le coût de migration des tâches est non négligeable. Parmi les travaux basés sur la stratégie globale notons : – pour les tâches indépendantes, préemptives et périodiques, il existe plusieurs algorithmes d’ordonnancement à priorités fixes aux instances [SB02, Bar04, BG03, GFB03] ou fixes aux tâches [ABJ01, RM00] qui reposent sur la stratégie globale. Dans [SB02] est présenté l’algorithme EDF-US sur m processeurs identiques (avec des tâches indépendantes et périodiques) avec comme condition d’ordonnançabilité Un ≤ m2/(2m − 1), Un est la somme des facteurs d’utilisation des tâches à ordonnancer. Cet algorithme est une modification de EDF en choisissant les priorités des tâches selon la règle suivante : si ui > m/(2m − 1) alors aux “jobs” de la tâche τi est allouée la plus haute priorité, sinon si ui ≤ m/(2m − 1) on applique EDF. Goossens et al. [GFB03] ont donné la condition suffisante d’ordonnaçabilité avec EDF pour des tâches périodiques à échéances sur requête, suivante: si Un ≤ m(1 − α) + α, α = max(ui), 1 ≤ i ≤ n alors le système de tâches Γ est ordonnançable sur les m processeurs. – un algorithme à priorités fixes aux tâches RM-US similaire à EDF-US est présenté dans [ABJ01] avec Umin = m2/(3m − 2). Des algorithmes d’ordonnancement préemptifs à priorités fixes aux instances avec des tâches sporadiques sont présentés dans [BG08, AB08, Bar07, BB08]. Dans [Bak03] nous avons un algorithme à priorités fixes aux tâches avec Deadline Monotonic qui donne le résultat suivant : avec des tâches périodiques et m ≥ 2 processeurs, la condition suffisante d’ordonnançabilité est donnée par: Un ≤ m 2 (1 − α)α. – dans [AJ03] nous avons des algorithmes d’ordonnancement basés sur la notion d’équité proportionnée (proportionate fairness). Ces algorithmes dits “pfair” diffèrent des algorithmes d’ordonnancement classiques dans la mesure où il est requis avec ces algorithmes que les tâches s’exécutent à un taux régulier (quasi constant) en divisant une tâche en série de sous-tâches. Ces sous-tâches doivent s’exécuter dans des intervalles de tailles identiques appelés fenêtre. Il faut noter que les stratégies globales et par partitionnement ne sont pas comparables d’après Leung et Whitehead [LW82]. Ils ont montré que pour les algorithmes d’ordonnancement à priorités fixes : i) il y a des systèmes de tâches pé- riodiques qui sont ordonnançables en utilisant m processeurs identiques à l’aide d’une approche partitionnée mais pour lesquels aucune stratégie globale existe2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 37 pour les ordonnancer, ii) il y a des systèmes de tâches périodiques ordonnan- çables avec une approche globale en utilisant m processeurs mais pour lesquels aucun partitionnement de m sous-ensembles ordonnançables existe. 2.2.2.3 Stratégie par semi-partitionnement Elle est obtenue par combinaison de la stratégie par partitionnement et de la stratégie globale. Chaque tâche est allouée à un processeur pour toute son exé- cution, cependant si une tâche ne peut s’exécuter entièrement sur aucun processeur, son exécution est partagée sur deux ou plusieurs processeurs dont la charge maximale n’est pas atteinte (les migrations sont autorisées pour ce type de tâches). Différents types d’algorithmes de semi-partitionnement sont présentés dans [KY08, AT06, KY07]. Cette approche permet de minimiser les migrations de tâches. 2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur Les termes allocation, distribution, partitionnement ou assignation des tâches sont équivalents dans le vocabulaire de l’ordonnancement temps réel multiprocesseur. Dans la suite on utilisera le terme allocation. Allouer une tâche à un processeur signifie l’exécuter sur un processeur de façon à ce que cette tâche et toutes les autres tâches, qui sont déjà allouées à ce même processeur, soient ordonnançables selon une condition d’ordonnançabilité qui est précisée. L’allocation d’une tâche à un processeur se faisant en fonction d’un critère, le problème à résoudre est un problème d’optimisation. Le critère d’optimisation peut être le nombre de processeurs, le facteur d’utilisation, la latence, etc. Dans cette partie nous étudions les différentes méthodes existantes dans la résolution du problème d’allocation des tâches temps réel. Nous distinguons deux grandes catégories de méthodes de résolution : celles qui sont dites exactes et les méthodes approchées. 2.3.1 Méthodes exactes Une méthode exacte est une méthode qui cherche, en parcourant toutes les allocations possibles, une solution (l’ordonnancement où toutes les contraintes sont respectées), si jamais celle-ci existe. Par ailleurs si cette méthode ne trouve pas de solutions, on en déduit que le problème n’a pas de solution. Et puisque le problème d’allocation inclut une optimisation, la solution trouvée par une méthode exacte est la meilleure solution possible dite optimale.38 État de l’art 2.3.1.1 Branch & Bound L’algorithme de “Branch and Bound” (B&B) (séparation et évaluation) [CY90, Tal09] est basé sur l’énumération de toutes les solutions du problème d’optimisation. L’espace de recherche est exploré dynamiquement en construisant un arbre dont la racine représente le problème à résoudre avec son espace de recherche associé. Les feuilles de l’arbre sont les solutions potentielles au problème et les noeuds internes les solutions partielles (en ordonnancement c’est une solution ne contenant pas toutes les tâches). La solution optimale est la meilleure parmi les solutions potentielles. La construction et l’exploration de cet arbre se font à l’aide de deux opérations : la séparation et l’évaluation des solutions partielles. L’opération de séparation détermine l’ordre de parcours de l’espace des solutions partielles (parcours en profondeur, en largeur, etc.). L’évaluation des solutions partielles se fait à l’aide d’une fonction coût qui permet d’exclure ou de garder une solution partielle. La performance d’un algorithme de B&B dépend non seulement de la méthode de séparation des solutions partielles mais aussi de la fonction de coût utilisée pour évaluer ces solutions. L’algorithme de B&B est utilisé dans de nombreux travaux d’ordonnancement temps réel multiprocesseur comme dans [CY90, Xu93, PSA97]. 2.3.1.2 Branch & Cut L’algorithme de “Branch and Cut” [Mit02] utilise aussi un arbre pour repré- senter l’espace des solutions mais toutes les solutions ne sont pas énumérées. En effet pour chaque tâche candidate à l’ordonnancement, l’algorithme teste son ordonnançabilité sur chaque processeur puis à l’aide d’une fonction de coût il sé- lectionne le meilleur processeur pour la tâche sélectionnée. Si la tâche τi n’est ordonnançable sur aucun processeur alors l’algorithme de “Branch and Cut” fait un retour-arrière (“backtrack”), il revient à la tâche τi−1 qui a été ordonnancée juste avant et il lui cherche un autre processeur. Si aucun processeur n’est trouvé pour ordonnancer la tâche τi−1 alors l’algorithme B&C fait un deuxième retourarrière. Tant qu’une tâche reste non allouée, ces retour-arrières sont itérés jusqu’à la première tâche qui a été allouée pour lui chercher un autre processeur. Ce qui permet de trouver une allocation possible si toutefois elle existe. 2.3.1.3 Programmation par contraintes La programmation par contrainte (PPC) [Ben06, Hla04] est utilisée pour ré- soudre plusieurs types de problèmes tels que la planification, l’ordonnancement, etc. Dans la PPC, le problème est modélisé à l’aide de variables de décisions et de contraintes, où une contrainte est une relation entre une ou plusieurs variables2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 39 qui limite les valeurs que peuvent prendre simultanément chacune des variables qui est liée à cette contrainte. Un domaine est associé à chaque variable et celuici est constitué de l’ensemble des valeurs pouvant être affectées à cette variable. Lorsque le domaine d’une variable est réduit à une valeur, on dit que la variable est instanciée. Un ensemble de variables instanciées est une instanciation. Une solution au problème est alors définie comme une instanciation des variables qui satisfait la conjonction de toutes les contraintes. Les algorithmes de recherche de solutions en PPC s’appuient généralement sur la propagation de contraintes pour réduire l’espace de recherche de solutions. La propagation de contraintes est le mécanisme qui consiste à déduire de nouvelles contraintes à chaque fois qu’un domaine de variable est modifié. Les algorithmes de recherche de solutions garantissent de trouver une solution, si toutefois elle existe, sinon ils peuvent prouver qu’il n’existe pas une solution qui satisfait toutes les contraintes. Cette technique de programmation par contraintes a été utilisée dans plusieurs travaux [Hla04, PEHDN08, EJ00, CA95] pour résoudre le problème d’ordonnancement temps réel multiprocesseur. 2.3.1.4 Programmation linéaire La programmation linéaire (PL) [Van96, DT03] permet de résoudre les problèmes d’optimisation dont la fonction objective et les contraintes sont linéaires. C’est un domaine central dans l’optimisation car les problèmes de programmation linéaire sont les problèmes d’optimisation les plus faciles (toutes les contraintes y sont linéaires). Dans un problème de PL, il est toujours question de minimiser ou de maximiser une fonction objectif exprimée à l’aide de variables de décisions. Les solutions à trouver doivent être représentées par des variables réelles. S’il est nécessaire d’utiliser des variables discrètes dans la modélisation, on parle de programmation linéaire en nombre entiers (PLNE). Un problème de PLNE est un problème de PL dans lequel on ajoute la contrainte supplémentaire que certaines variables ne peuvent prendre que des valeurs entières. La programmation linéaire mixte (PLM), permet de traiter des problèmes dans lesquels les variables sont mixtes (entières et réelles) [She11]. Dans [Sub05] est présenté une formulation sous la forme de PLNE pour le problème d’ordonnancement des tâches temps réel dépendantes dans un système multiprocesseur homogène.40 État de l’art 2.3.1.5 Programmation dynamique La programmation dynamique [Sar84] est basée sur la division récursive d’un problème en plusieurs sous-problèmes plus simples. Elle applique le principe de l’optimalité formulée par R. Bellman qui est le suivant : “Dans une séquence optimale de décisions, quelle que soit la première décision prise, les décisions subséquentes forment une sous-séquence optimale, compte tenu des résultats de la première décision”. Ce principe implique que le problème à étudier puisse être formulé comme l’évolution d’un système. Il est aussi nécessaire de pouvoir dé- composer le problème en plusieurs étapes qui permet une grande économie de calculs. 2.3.1.6 Les Réseaux de flots Un réseau de flots [FJF62] est un graphe dont chaque arc a une capacité et reçoit une quantité de flots. Le flot reçu par un arc ne doit pas dépasser la capacité de l’arc. Dans un réseau de flots la quantité de flots entrant par un sommet doit être égale à la quantité de flot qui ressort par ce même sommet, à l’exception du sommet source qui n’a pas d’arcs entrants et de sommet puits qui n’a pas d’arcs sortants. Il est également possible d’avoir plusieurs sources et puits dans un réseau de flots et d’associer un coût à chaque arc correspondant au coût d’utilisation de cet arc. Dans les réseaux de flots, le problème du minimum k-coupe [FJF62] consiste à déterminer un ensemble d’arcs du graphe de telle sorte que la suppression de ses arcs sépare le graphe en exactement k composantes connexes (dans une composante connexe pour deux sommets il existe au moins un chemin qui les relie) et chaque composante a au moins un sommet puits ou un sommet source. En représentant les tâches et les processeurs dans un même graphe comme un réseau de flots dont les puits et sources sont les processeurs, la solution au problème du minimum k-coupe permet de résoudre le problème d’allocation des tâches en considérant que k est le nombre de processeurs disponibles pour l’allocation des tâches. Généralement les travaux utilisant les réseaux de flots pour résoudre le problème d’allocation des tâches ne prennent pas en compte les contraintes temps réel [Sto77, CHMTE80]. Dans [BF97] un modèle de réseau de flots est présenté pour l’allocation des tâches temps réel avec respect des contraintes de temps dans le cas de tâches indépendantes.2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 41 2.3.2 Méthodes approchées Les méthodes exactes, bien que produisant des solutions optimales ne sont pas généralement applicables à cause de leur temps de calcul prohibitif pour des problèmes réalistes. Les méthodes approchées permettent des donner des solutions qui dans la plupart des cas ne sont pas optimales, mais ont des temps de calcul acceptables qui les rendent applicables dans les problèmes de grandes tailles. Nous distinguons deux catégories de méthodes approchées, les méthodes de recherches non guidées qui ne dépendent pas du domaine étudié appelées aussi métaheuristiques et les méthodes guidées ou heuristiques qui dépendent du domaine étudié. 2.3.2.1 Méthodes de recherche non guidées ou métaheuristiques Ce sont des méthodes d’optimisation globales inspirées de plusieurs domaines tels que l’intelligence artificielle, la biologie, la sidérurgie, etc. Nous distinguons celles qui sont basées sur la notion de population de solutions [Tal09, CCH+99] (ensemble de solutions appelées individus) comme les algorithmes génétiques et celles qui se basent sur la recherche locale [Tal09, VM05, EL97] comme le recuit simulé. Dans cette dernière, la solution, déterminée à l’aide d’une fonction de coût, est remplacée par la meilleure solution située dans son voisinage. Le recuit simulé et la méthode Tabou font parties de ces métaheuristiques qui utilisent la recherche locale. 2.3.2.1.1 Recuit simulé L’algorithme de recuit simulé [Tal09] commence par générer de façon aléatoire une solution initiale unique. À cette solution initiale sont associées une fonction d’énergie qui caractérise le système et une température pour permettre à l’algorithme de passer d’une phase à l’autre où la valeur de l’énergie diminue puis augmente pour diminuer par la suite jusqu’à l’obtention d’une valeur minimale, qui correspond à l’optimum global. Cette température est appelée “facteur d’agitation aléatoire”. En ordonnancement temps réel la fonction d’énergie peut être une combinaison de plusieurs paramètres tels que le temps de réponse, les coûts de communications inter-processeurs, etc. Dans [TBW92, CA95], le recuit simulé est utilisé pour résoudre le problème d’allocation des tâches temps réel avec des contraintes de précédences et des coûts de communication inter-processeurs. 2.3.2.1.2 Recherche Tabou42 État de l’art Un algorithme de recherche Tabou [Tal09, GL93] combine une procédure de recherche locale avec un certain nombre de règles et de mécanismes lui permettant de surmonter l’inconvénient des optimums locaux, tout en évitant les problèmes de cycles (visiter plusieurs fois une solution). En effet il possède une mémoire (une liste tabou) qui garde les mouvements déjà effectués pour éviter d’y revenir et d’être piégé dans un cycle qui impliquera la convergence vers un optimum local. Cela permet d’explorer d’autres espaces de solutions et d’améliorer les solutions. Les algorithmes de recherche tabou peuvent être utilisés dans la résolution du problème d’ordonnancement temps réel multiprocesseur avec des contraintes de précédences et des coûts de communication. [KBKP04, FGLM96]. 2.3.2.1.3 Algorithmes génétiques Les algorithmes génétiques [Tal09] s’inspirent de l’évolution biologique des espèces en exploitant la sélection et la survie de l’espèce la mieux adaptée. Le principe des algorithmes génétiques repose sur la sélection des individus qui représentent les solutions. La reproduction se fait dans le but de générer une autre population avec de meilleurs individus, en leur transmettant certaines de leur caractéristiques. Une fonction de coût est utilisée afin d’évaluer les individus et de sélectionner les meilleurs pour constituer une autre population, à laquelle on appliquera de nouveau la sélection et la reproduction. Ce processus est réitéré jusqu’à ce qu’un critère d’arrêt soit atteint. La reproduction des individus est réalisée avec le croisement et la mutation. Le croisement consiste à couper deux individus en un point qui peut être choisi aléatoirement et à échanger les parties coupées. La mutation, quand à elle, modifie les gènes des individus afin de produire d’autres individus (par exemple en ordonnancement on crée d’autres solution à partir d’une solution existante en modifiant l’allocation des tâches dans cette solution) [Tal09]. Dans [ESHA94, ESHA90], les algorithmes génétiques sont utilisés pour ré- soudre le problème d’ordonnancement temps réel multiprocesseur avec des contraintes de précédences. 2.3.2.2 Méthodes guidées ou heuristiques Les méthodes d’allocation que nous présentons dans cette partie sont guidées par le domaine de l’ordonnancement temps réel multiprocesseur. Ce qui justifie l’utilisation par la suite de la notion de tâche, de processeur, de coûts de communication, etc. Ces méthodes heuristiques sont basées sur l’évolution d’une solution partielle (solution qui ne contient pas toutes les tâches à allouer). Bien que2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 43 ces heuristiques soient plus rapides que les métaheuristiques, à fortiori que les méthodes exactes, expérimentalement les heuristiques fournissent des solutions moins proches de l’optimal que les métaheuristiques. 2.3.2.2.1 Heuristiques gloutonnes Les heuristiques gloutonnes construisent la solution incrémentalement. À chaque étape de l’heuristique gloutonne une tâche est rajoutée selon un critère glouton, correspondant à une décision locale déterminant le meilleur choix (à court terme) [Tal09, VM05]. Chaque choix fait est définitif, ces algorithmes n’autorisent pas les retour-arrières (“backtracking”). Ainsi, les solutions obtenues sont très dépendantes de l’ordre de considération des tâches. Les heuristiques gloutonnes donnent très rapidement des solutions qui sont rarement optimales. Parmi les heuristiques gloutonnes nous avons les heuristiques utilisées dans la résolution du problème de remplissage de boîtes (“bin packing”). Par la suite nous utiliserons la terminologie heuristiques de“bin packing” pour désigner ces types d’heuristiques. Dans le problème d’ordonnancement multiprocesseur, chaque tâche est modé- lisée par un objet et la taille de cet objet est modélisée par le facteur d’utilisation du processeur par cette tâche. Chaque processeur est modélisé par une boîte de capacité égale à la charge maximale que l’on peut atteindre sur ce processeur avec un algorithme d’ordonnancement fixé. Voici quelques heuristiques gloutonnes : – heuristique “next-fit” : Étape 1: initialiser le compteur des tâches i=1 Étape 2: initialiser le compteur des processeurs j=1 Étape 3: Si τi est ordonnançable sur pj (selon Liu et Layland [LL73] par exemple) alors allouer τi à pj ; Sinon j = j + 1 et allouer τi à pj Étape 4: Si i < n alors i = i + 1 et reprendre à partir de l’étape 3, sinon fin et système ordonnançable avec j processeurs; – heuristique “first-fit” : avec “next-fit” si la tâche τi n’est pas ordonnançable sur pj on passe immé- diatement à pj+1 même si τi est ordonnançable sur l’un des j − 1 processeurs déjà utilisés. Ce qui a tendance à augmenter le nombre de processeurs. L’heuristique “first-fit” tente d’abord d’allouer une tâche au processeur, de plus petit indice j parmi les processeurs déjà utilisés et pouvant l’ordonnancer. Si cela est impossible on passe à un processeur vide; – heuristique “best-fit” :44 État de l’art cette heuristique alloue une tâche au processeur en suivant une fonction coût f définie pour chaque processeur (par exemple la capacité restante du processeur). Ainsi une tâche est allouée au processeur de plus petite valeur de f qui peut l’ordonnancer. Si deux processeurs ont la même valeur de f, la tâche est allouée au processeur de plus petit indice; – heuristique de “worst-fit” : c’est une heuristique similaire à “best-fit”, mais avec “worst-fit”, une tâche est allouée au processeur ayant la plus grande valeur de la fonction coût f. Ces heuristiques de type “bin packing”, cherchent uniquement à minimiser le nombre de processeurs utilisés dans le partitionnement des tâches, à l’exception de “best-fit” et “worst-fit” avec lesquels nous pouvons optimiser une fonction de coût définie. 2.3.2.2.2 Heuristiques de listes Généralement ces méthodes heuristiques utilisent un graphe acyclique orienté (GAD) pour représenter les dépendances entres les tâches en associant des poids aux arcs (symbolisant les coûts de communication entre processeurs) qui relient les sommets (représentant les tâches), ainsi que des poids aux sommets (symbolisant les durées d’exécution des tâches). Les heuristiques de liste [SS97, ACD74, MKTM93] définissent une liste de tâches en attribuant à chacune d’elles une priorité. Cette liste détermine l’ordre du choix d’allocation d’une tâche aux différents processeurs. À chaque étape de l’heuristique, une tâche est sélectionnée dans la liste des tâches candidates pour être ordonnancée sur un processeur puis la liste est mise à jour (suppression de la tâche ordonnancée et ajout des tâches qui n’ont pas de prédécesseurs dans le graphe des tâches). Ceci est répété jusqu’à ce que la liste soit vide. Par opposition aux heuristiques gloutonnes, certaines approches des heuristiques de liste autorisent les retour-arrières [AaR95, Ram90] sur un choix quand une tâche ne peut pas être allouée à un processeur. Cela a pour consé- quence d’augmenter considérablement le temps de recherche et selon Adan et al. [AaR95] et Ramamritham [Ram90] n’améliore pas toujours les résultats. Sans les retour-arrières les heuristiques de listes sont rapides d’exécution mais, comme avec toutes les heuristiques, il y a un risque de ne pas trouver une solution alors qu’il en existe. 2.3.2.2.3 Heuristiques de regroupement ou "clustering" Les heuristiques de regroupement [CHMTE80, GVY90, KT00] consistent à regrouper les tâches en différents sous-ensembles appelés “clusters” (groupes)2.4 Ordonnancement de tâches dépendantes 45 en fonction des objectifs du problème (respect des contraintes temps réel, minimisation des coûts de communication, etc.), les tâches d’un “cluster” devant être ensuite allouées à un même processeur, ce qui diminue la taille du problème. La résolution du problème d’allocation par des heuristiques de regroupement est donc décomposée en deux phases. La première phase constitue le regroupement proprement dit et la seconde consiste à allouer les tâches sur les processeurs en fonctions des contraintes temps réel, de précédence entre les tâches, etc. Cette seconde phase peut être menée, par exemple, par des heuristiques de liste. Les heuristiques de regroupement ont l’avantage de réduire l’espace de recherche de solutions en explorant les “clusters” au lieu des tâches elles-mêmes. Par contre le regroupement des tâches en “clusters” peut engendrer la non satisfaction de contraintes (temps réel, minimisation du temps de réponse de l’ordonnancement, etc.). 2.3.2.2.4 Heuristique de duplication de tâches Ces heuristiques dupliquent les tâches sur les processeurs afin de minimiser une fonction coût qui peut être le temps de réponse de l’ordonnancement des tâches. Dans [XTL10] est présentée une heuristique de duplication de tâches appelée “Heterogeneous Earliest Finish with Duplicator” (HEFD). L’heuristique HEFD utilise le principe des heuristiques de liste en définissant une liste pour les tâches candidates à l’ordonnancement. À chaque étape de l’heuristique une tâche candidate est sélectionnée puis sur chaque processeur la date de démarrage au plus tôt de la tâche est déterminée par duplication des tâches prédécesseurs immédiats de cette tâche candidate sur tous les processeurs sur lesquels elles ne sont pas encore dupliquées. Si la duplication d’une tâche prédécesseur immédiat sur un processeur entraîne un retard sur la date de démarrage au plus tôt de la tâche candidate alors cette duplication est supprimée. Ensuite le processeur produisant la plus petite date de démarrage pour la tâche est sélectionnée pour ordonnancer la tâche candidate. 2.4 Ordonnancement de tâches dépendantes Comme nous l’avons vu à la section 1.4.3, une contrainte de dépendance entre tâches peut être une contrainte de précédence ou une contrainte de dépendances de données. Dans l’ordonnnancement de tâches avec des contraintes de précédences, il existe deux approches pour résoudre le problème. La première est basée sur les sémaphores [FGPR11] : un sémaphore est alloué à chaque précédence (τi , τj ), et la tâche successeur τj doit attendre que la tâche prédécesseur τi libère le sé- maphore avant de commencer son exécution. La deuxième approche est basées46 État de l’art sur la modification des priorités et des dates de premières activations des tâches [CSB90, FBG+10a]. Dans l’ordonnancement des tâches avec des contraintes de dépendances de données en plus des tenir compte des contraintes de précédences, il faut gérer le transfert et le partage de données entre tâches. 2.4.1 Transfert de données Soient τi et τj deux tâches de périodes respectives Ti et Tj liées par une contrainte de dépendances de données telle que τi est la tâche productrice et τj la tâche consommatrice. Dans le cas général le transfert de données entre ces tâches se fait dans un rapport k relativement à leurs périodes tel que si Ti < Tj alors Tj = kTi + r, sinon Ti = kTj + r avec k ∈ N ∗ et r ∈ N. Dans le cas où τi a une période plus petite que τj alors τj consomme k données produites par τi . Dans le cas où τi a une période plus grande ou égale à celle de τj alors τj consomme une ou plusieurs fois la donnée produite par τi . Si r 6= 0, il peut arriver que la tâche productrice τi produise k + 1 données avant que la tâche consommatrice τj ne consomme, sur ces k + 1 données seules les k données sont consommées par τj et la donnée qui reste est perdue. Ce qui fait qu’au total on perdrait une infinité de données. Pour illustrer ce cas prenons l’exemple de deux tâches τ1(0, 1, 3, 3) et τ2(3, 1, 7, 7) telles que τ1 est la tâche productrice de données et τ2 la tâche consommatrice de données. Nous avons T2 = 7 = 2 ∗ 3 + 1 = 2T1 + 1. Comme le montre la figure 2.1 ci-dessous, avant que la tâche consommatrice τ2 ne démarre sa 4 ème exécution, la productrice s’est exécutée trois fois donc a fourni trois données dont deux seulement sont consommée à la 4 ème exécution de τ2 et la donnée qui reste est perdue. Il peut y avoir plusieurs possibilités pour la tâche τj de consommer les données produites par τi [FBG+10b]. La tâche τj peut consommer la totalité des données produites par τi ou n’importe quel sous-ensemble des données. Par exemple dans [RCR01], la tâche τj ne consomme que la dernière donnée produite par τi . Par contre dans [Ker09, KS07] toutes les données produites par τi sont consommées par τj sans qu’aucune données ne soient perdues. 2.4.2 Partage de ressources Les dépendances de données entraînent des partages de données entre tâches. Les données produites par les tâches sont sauvegardées dans des mémoires considérées comme des ressources. Ces mémoires sont partagées entre les tâches productrices qui écrivent leurs données dans ces mémoires et les tâches consommatrices qui y lisent des données. Considérons deux taches τi et τj telles que τi produit des données que τj consomme. Lorsque τj se fait préempter par τi , les données dans la mémoire partagée par ces deux tâches peuvent être dans un état incon-2.4 Ordonnancement de tâches dépendantes 47 0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 3 10 17 24 31 38 45 facteur d’utilisation classique : 10/21 = 0.4762 facteur exact permanent d’utilisation : 10/21 = 0.4762 coût exact permanent de la préemption : 0/21 = 0.0000 tâche émission durée PTR période t1 0 1 1 3 t2 3 1 2 7 priorité : monotone par période (RM) coût d’une préemption : 0 ORDONNANÇABLE FIGURE 2.1 – Illustration des pertes de données sistant car τi risque de modifier les données qui ne seront plus les mêmes à la reprise de l’exécution de τj . Donc τi et τj ne doivent pas accéder en même temps à la mémoire tampon qu’elles partagent. On dit que les deux tâches ont des contraintes d’exclusions mutuelles [Kai81, SRL90]. Pour traiter ces contraintes d’exclusion mutuelles, les tâches sont exécutés dans des sections critiques [Kai81]. Une tâche qui s’exécute en section critique ne pourra pas être préemptée par une autre tâche. Lorsque la tâche τi , la plus prioritaire, attend la fin de la section critique de τj pour pouvoir s’exécuter, on parle d’inversion de priorité [SRL90] et on dit que τi est bloquée par τj . Un exemple d’inversion de priorité est présenté à la figue 2.2. On dit que deux ou plusieurs tâches sont en inter-blocage si chacune des tâches est bloquée en attente d’une ressource qui est utilisée par une autre tâche parmi ces tâches [Hav68]. Un exemple d’inter-blocage est présenté à la figure 2.3. Les section critiques doivent être utilisées convenablement afin d’éviter que des tâches moins prioritaires bloquent indéfiniment des tâches plus prioritaires48 État de l’art                    τ2 = (1, 2, 5, 5) τ3 = (1, 1, 4, 4) τ1 = (0.2, 8, 8) Utilisation de la mémoire buf1 0 1 2 3 4 5 6 7 8 9 1 3 4 2 5 6 7 8 1 2 3 4 5 6 7 8 9 9 t = 1, τ1 est préemptée par τ2 Utilisation de la mémoire buf2 t = 1, τ1 bloque τ3 sur b inversion de priorités FIGURE 2.2 – Inversion de priorités               Deadlock is formed at t = 3 t = 2, τ1 tentant d’utiliser la mémoire buf2, est préemtée par τ2 3 0 1 3 4 5 6 7 2 2 4 5 6 7 t = 3, τ2 tentant d’utiliser la mémoire buf1, est bloquée parτ1 τ1 = (0, 3, 6, 6) τ2 = (2, 2, 4, 4) Utilisation de la mémoire buf2 Utilisation de la mémoire buf1 FIGURE 2.3 – Inter-blocage mais aussi les inter-blocages. Pour cela plusieurs protocoles de synchronisation ont été proposés aussi bien en monoprocesseur qu’en multiprocesseur. 2.4.3 Protocoles de synchronisation monoprocesseur 2.4.3.1 Priority Inheritance Protocol (PIP) Le protocole de synchronisation PIP (Priority Inheritance Protocol) a été proposé par Sha and al. [SRL90]. Il est basé sur le principe de l’héritage de priorité.2.4 Ordonnancement de tâches dépendantes 49 Pour réduire la durée des inversions de priorités, lorsqu’une tâche τj bloque une autre tâche τi plus prioritaire qu’elle, τj hérite de la priorité de τi durant toute la durée de son exécution. Après son exécution τj reprend sa priorité initiale. Ceci permet d’éviter qu’une tâche de priorité intermédiaire (une tâche plus prioritaire que τj et moins prioritaire que τi) préempte τj ce qui allongerait le temps de blocage de τi . Ce protocole permet de réduire le temps de blocage mais ne permet pas d’éviter les inter-blocages. Ce protocole est utilisé dans le cas des algorithmes d’ordonnancement à priorités fixes. 2.4.3.2 Priority Ceiling Protocol (PCP) Le protocole de synchronisation PCP (Priority Ceiling Protocol) [SRL90] est une extension de PIP pour éviter les inter-blocages. Il est basé sur le principe de la priorité plafond . Une priorité plafond est donnée à chaque ressource. Cette priorité plafond est définie par la plus grande priorité des tâches qui utilisent cette ressource. À chaque instant t, on définit la priorité du système comme étant la plus grande priorité plafond parmi les ressources en cours d’utilisation à t. Une tâche τi ne pourra exécuter sa section critique que lorsque sa priorité est plus grande que la “priorité du système” qui est égale à la plus grande priorité parmi les priorités des ressources en cours d’utilisation. Sinon τj continue son exécution et hérite de la priorité de τi . Ceci permet d’éviter les inter-blocages. 2.4.3.3 Stack Resource Policy (SRP) Le protocole SRP (Stack Resource Policy MSRP) [Bak91], est la version de PCP avec des priorités dynamiques. Chaque instance d’une tâche possède un plafond de préemption. Une instance de la tâche τi ne pourra préempter une instance de la tâche τj que lorsque la priorité de l’instance de τi est supérieure au plafond de préemption de l’instance de la tâche τi . Chaque ressource a un plafond de pré- emption qui est le maximum des plafonds de préemption des instances pouvant utiliser cette ressource. On définit le plafond de préemption du système comme étant le plus grand plafond de préemption des ressources en cours d’utilisation. Une tâche τi ne peut exécuter une section critique que lorsque sa priorité est plus grande que le plafond de préemption de toutes les tâches actives et que son plafond de préemption est supérieur à celui du système. Les instances actives sont placées dans une pile dans l’ordre décroissant de leur priorité.50 État de l’art 2.4.4 Protocoles de synchronisation multiprocesseur 2.4.4.1 MPCP Le protocole MPCP (Multiprocessor Priority Ceiling Protocol) [Raj90] est une extension en multiprocesseur de PCP. Avec MPCP on distingue deux types de ressources. Les ressources locales sont partagées entre tâches sur le même processeur et les ressources globales sont partagées entre tâches allouées sur des processeurs différents. Chaque ressource globale a une priorité plafond égale à la plus grande priorité parmi celles des tâches pouvant utiliser cette ressource et la plus grande priorité du système (la plus grande priorité des ressources en cours d’utilisation sur les processeurs). Une tâche qui utilise une ressource globale est exécutée à la priorité de cette ressource. Dans le cas des ressources locales, MPCP fonctionne de la même manière que PCP. 2.4.4.2 MSRP Le protocole MSRP (Multiprocessor Stack Resource Policy MSRP) [GLN01] est une extension en multiprocesseur de SRP. Chaque processeur possède son propre plafond de préemption. Chaque processeur attribue à une ressource globale un plafond de préemption supérieur ou égal au plafond de préemption sur ce processeur. Lorsqu’une tâche utilise une ressource globale sur un processeur, ce processeur hérite du plafond de priorité de cette ressources globale. Dans le cas des ressources locales, MSRP fonctionne de la même manière que SRP. 2.5 Ordonnancement avec prise en compte du coût de l’OS Le coût du système d’exploitation est composé de deux parties. La première est appelée coût de l’ordonnanceur. Elle correspond au coût de sauvegarde de contexte du processeur, au coût de sélection de la tâche à exécuter et au coût de chargement de la tâche sélectionnée [KAS93]. La seconde partie est appelée coût de la préemption dû à l’ensemble des préemptions [Yom09]. Le coût d’une pré- emption correspond au coût de sauvegarde de contexte du processeur, de sélection de la tâche à exécuter et de restauration de contexte du processeur au moment de chaque préemption. Les travaux que nous avons présentés jusqu’à présent font l’hypothèse que le coût de l’OS est négligeable ou est approximé dans le pire temps d’exécution de chaque tâche.2.5 Ordonnancement avec prise en compte du coût de l’OS 51 2.5.1 Coût de l’ordonnanceur Le coût de l’ordonnanceur est illustré sur la figure 2.4. Ce coût se décompose en :      Coût de l’ordonnanceur τ k i r k i r k i + Ti FIGURE 2.4 – Illustration du coût de l’ordonnanceur – coût de sauvegarde de contexte du processeur, – coût de sélection de la tâche à exécuter, – coût de chargement pour exécution de la tâche sélectionnée. La sauvegarde du contexte de la tâche en cours d’exécution et de chargement de la tâche sélectionnée ont un coût fixe. Dans le cas d’un ordonnancement en ligne la sélection d’une tâche s’effectue pendant l’exécution des tâches. Cette sé- lection de la tâche à exécuter dépend du nombre de tâches dans l’état “Prêt” et donc son coût varie. Par contre dans le cas d’un ordonnancement hors ligne, la sélection d’une tâche s’effectue à partir d’une table d’ordonnancement qui a été déterminée avant l’exécution des tâches. Le coût de sélection est fixe et égal au coût de lecture dans une table. Dans la suite comme nous nous intéressons à l’ordonnancement hors ligne, le coût de l’ordonnanceur devient fixe. Pour le prendre en compte dans l’analyse d’ordonnançabilité, il suffira de l’ajouter au pire temps d’exécution de chaque tâche. Dans la suite du manuscrit on expliquera comment prendre en compte le coût exact de la préemption. 2.5.2 Coût de la préemption Lorsqu’une tâche se fait préempter par une autre tâche plus prioritaire, son contexte d’exécution est sauvegardé et celui-ci doit être restauré lors de sa resélection. Le coût de sauvegarde de contexte est pris en compte dans la durée d’exécution de la tâche qui préempte plutôt que dans la durée d’exécution de la tâche préemptée car, le coût de l’ordonnanceur qui est supposé inclus dans la durée d’exécution des tâches contient aussi la sauvegarde de contexte. Par contre la restauration du contexte de la tâche préemptée a lieu uniquement lors de sa reprise d’exécution. Cette restauration du contexte de la tâche préemptée est précédée par52 État de l’art une sélection de tâche et par une sauvegarde de contexte d’exécution de la tâche en cours. Cet ensemble de coût de sélection, de sauvegarde de contexte d’exé- cution de la tâche en cours et de restauration de contexte de la tâche préemptée, est appelé coût d’une préemption. Ce coût temporel de la préemption rallonge le temps de réponse de l’exécution de la tâche préemptée et peut causer à son tour d’autres préemptions pour d’autres tâches moins prioritaires. Cette accumulation de préemptions peut rendre non ordonnançable un système de tâches qui était initialement déclaré ordonnançable en négligeant le coût de la préemption. La figure 5.5.2 illustre le coût de la préemption. Coût d’une préemption r k 1 Préemption de τ k 2 r k 2 τ k 2 τ k 1 r k 1 + T1 r k 2 + T2 FIGURE 2.5 – Illustration du coût de la préemption Pour éviter de prendre en compte le coût de la préemption qui a un impact sur l’ordonnançabilité, certains travaux proposent de réduire le nombre de pré- emption [Bur94, WS99, SW00]. Dans [Bur94], un algorithme d’ordonnancement à priorités fixes et à préemptions différées est proposé. Cet algorithme considère que chaque exécution ou instance d’une tâche est constituée de plusieurs sousexécutions et une préemption ne peut avoir lieu qu’entre deux sous-exécutions. Ceci permet de réduire le nombre de préemptions d’une tâche au cours de son exécution. Dans [WS99, SW00] un autre algorithme d’ordonnancement avec plafond de priorité est proposé. Cet algorithme assigne à une tâche deux types de priorité : un priorité nominale et une priorité plafond. Avec cet algorithme, une préemption ne peut avoir lieu que lorsque la tâche qui préempte a une priorité nominale plus grande que la priorité de seuil de la tâche qu’elle veut préempter. Donc en choisissant comme il faut les priorités de seuil des tâches on peut réduire le nombre de préemptions. Cependant aucun de ces travaux ne prend en compte dans l’ordonnancement le coût lié à chaque préemption. En revanche d’autres travaux ont pris en compte le coût de la préemption. Dans le modèle de tâche Liu et Layland [LL73] le coût de la préemption est ap-2.6 Conclusion 53 proximé dans le WCET. Cette approximation se fait soit en prenant une marge faible, ce qui peut rendre un système de tâches non ordonnançables à l’exécution alors que ce système a été conclu ordonnançable. Ou bien l’approximation est faite en prenant une marge importante ce qui entraîne le gaspillage de la ressource processeur. C’est la raison pour laquelle nous devons prendre en compte le coût exact de la préemption, c’est-à-dire le coût lié à l’occurrence de chaque pré- emption. A. Burns and al. dans [BTW95] ont essayé de résoudre ce problème en présentant une analyse d’ordonnançabilité basée sur le temps de réponse qui prend en compte le coût global lié au nombre maximum de préemptions. Sauf que dans ce cas on une borne maximum du nombre de préemptions et non pas le nombre exact. Dans [ERC95], Ripoll and al. se sont eux aussi intéressés au nombre exact de préemption en faisant l’ordonnancement tâche après tâche et en comptant le nombre de préemption. Mais ils ne prennent pas en compte les préemption engendrées par d’autres préemptions car ils n’ajoutent pas le coût lié à l’occurrence de chaque préemption. Dans [Yom09] Meumeu et Sorel ont proposé une analyse d’ordonnançabilité d’un ensemble de tâches indépendantes périodiques qui permet de prendre en compte le coût exact de la préemption. Cette analyse est basée sur une opération binaire d’ordonnancement appelée ⊕ qui permet de compter le nombre exact de préemptions de chaque instance d’une tâche puis ajoute le coût associé à ces pré- emptions à son WCET ce qui permet d’obtenir une nouvelle durée d’exécution de la tâche avec prise en compte du coût exact de la préemption. Cette durée appelée PET (“Préemption Execution Time”) est utilisée dans l’analyse d’ordonnançabilité des tâches. Puisque prendre en compte le coût exact de l’ordonnanceur revient à rajouter son coût fixe dans le WCET de chaque tâche, ceci avant l’exécution des tâches, on supposera que le coût de l’ordonnanceur est inclus dans le WCET des tâches. Donc prendre en compte le coût exact de l’OS revient à prendre en compte le coût exact de la préemption. Donc dans la suite nous concentrerons notre étude sur le coût exact de la préemption. 2.6 Conclusion Dans ce chapitre nous avons présenté un état de l’art sur l’ordonnancement temps réel en mettant l’accent sur les méthodes d’allocation des tâches dans l’ordonnancement multiprocesseur, sur la prise en compte du coût exact de la pré- emption et sur les dépendances de données. Dans la seconde partie de cette thèse nous étudierons l’ordonnancement multiprocesseur des tâches indépendantes avec prise en compte du coût exact de la préemption. Pour cela nous réutiliserons les concepts définis dans cet état de l’art.Deuxième partie Ordonnancement temps réel multiprocesseur de tâches indépendantes avec prise en compte du coût exact de la préemptionChapitre 3 Ordonnancement monoprocesseur de tâches indépendantes 3.1 Introduction Comme nous l’avons présenté dans l’état de l’art, la prise en compte du coût exact de la préemption dans l’analyse d’ordonnançabilité de tâches temps réel est peu étudiée. Les seuls travaux que nous avons trouvés dans l’état de l’art sont ceux de Meumeu et Sorel [Yom09] qui ont présenté l’opération d’ordonnancement ⊕ dans le cas de l’ordonnancement monoprocesseur. Ce chapitre donne une présentation simplifiée de l’opération ⊕. Nous allons aussi dans ce chapitre prouver la viabilité (“sustainabilty”) de l’analyse d’ordonnançabilité basée sur cette opération dans le cas d’un ordonnancement à priorités fixes. 3.2 Modèle de tâches Considérons l’ensemble Γn de tâches temps réel périodiques indépendantes concrètes. Chaque tâche τi = (r 1 i , Ci , Ti , Di) est caractérisée par une date de première activation r 1 i , une pire durée d’exécution Ci n’incluant pas les coûts de préemption contrairement au modèle classique de Liu et Layland [LL73], une pé- riode Ti et une échéance relative Di . Les tâches étant périodiques, la date de la k ème activation de τi est donnée par r k i = r k i + (k − 1)Ti . La tâche τi doit terminer son exécution avant la date d k i = r k i +Di . Le temps qui s’écoule entre la date d’activation et la date de fin d’exécution de la k ème activation de τi désigne le temps de réponse Rk i de la k ème instance de τi . On suppose que l’inégalité Ci ≤ Di = Ti est toujours vérifiée. Nous supposons aussi que le processeur que nous considérons n’a pas de cache, ni “pipeline” ou d’architecture interne complexe.58 Ordonnancement monoprocesseur de tâches indépendantes 3.3 Intervalle d’étude de l’ordonnancement L’opération d’ordonnancement ⊕ utilise l’approche par simulation présentée à la section 1.5.3.2 de l’état de l’art pour faire l’analyse d’ordonnançabilité des tâches. Cette simulation est réalisée sur un intervalle d’étude défini. Cet intervalle est déterminé à l’aide du théorème 3.3.1 ci-dessous. Théorème 3.3.1 [Yom09] Soit Γn = {τ1, τ2, · · · , τn} un ensemble de n tâches pé- riodiques indépendantes concrètes tel que τi = (r 1 i , Ci , Ti , Di), avec i = 1, · · · , n, rangées par priorités décroissantes relativement à un algorithme d’ordonnancement à priorités fixes noté Algo, c’est-à-dire i < j implique que la priorité de τi est supérieure à la priorité de τj . Soit (si)i∈N∗ la suite définie par    s1 = r 1 1 si = r 1 i +  (si−1−r 1 i ) + Ti  · Ti , 2 ≤ i ≤ n S’il existe un ordonnancement valide de Γn jusqu’à la date sn + Hn où Hn = ppcm{Ti |i = 1, · · · , n} et x + = max(x, 0), alors cet ordonnancement est valide et périodique de période Hn à partir de sn. D’après le théorème 3.3.1, l’exécution de l’ensemble des tâches Γn est périodique à partir de la date sn et sa période est égale à Hn = ppcm{Ti |i = 1, · · · , n}. L’intervalle défini par [rmin, sn] avec rmin = min{r 1 i }τi∈Γn est appelé phase transitoire et l’intervalle défini par [sn, sn + Hn] est appelé la phase permanente qui se répète indéfiniment. Donc un intervalle d’étude de l’ordonnancement de Γn est donné par In = [rmin, sn + Hn]. En considérant uniquement l’ordonnancement des i premières tâches on parle d’ordonnancement de niveau i et un intervalle d’étude de l’ordonnancement des i tâches est donné par Ii = [rmin, si + Hi ] avec Hi = ppcm{Tj | j = 1, · · · , i}. 3.4 Opération binaire d’ordonnancement ⊕ 3.4.1 Principe L’opération d’ordonnancement ⊕ a été proposée par Meumeu [Yom09]. C’est une opération binaire, c’est-à-dire qu’elle ne s’applique qu’entre deux opérandes : un opérande de gauche op1 appelé tâche exécutée et un opérande de droite op2 appelé tâche exécutable telles que le résultat R est donné par R = op1 ⊕ op2. Par convention l’opérande de gauche est toujours plus prioritaire que l’opérande de droite. On représente une instance de la tâche exécutable op2 par une séquence3.4 Opération binaire d’ordonnancement ⊕ 59 de symboles de “e2” en gras suivi par une séquence de symbole de “a”. Chaque symbole de “e2” de la tâche exécutable représente une unité de temps exécutable, c’est-à-dire une unité de temps que op2, la tâche à exécuter, doit exécuter. Chaque symbole “a” représente une unité de temps libre. Nous représentons une instance de la tâche exécutée op1 par de séquences de symbole de “e” suivi par de sé- quences de symboles de “a” qui ne se suivent pas forcément et qui peuvent se répéter indéfiniment. Chaque symbole “e1” de la tâche exécutée op1 représente une unité exécutée par op1, c’est-à-dire une unité de temps que op1 a déjà exécutée. Le principe de l’opération ⊕ est de remplacer les unités de temps “a” libres de la tâche exécutée op1 par les unités de temps exécutables “e2” de la tâche op2. Pour cela, puisque les deux opérandes ne sont pas comparables, on les référence par rapport à la même origine de temps, puis on répète l’exécution de op1 autant de fois qu’il y a d’instances de op1 sur l’intervalle d’étude I2. Ensuite on réécrit le premier opérande op1 en fonction du nombre d’instances du second opérande op2 sur l’intervalle d’étude I2. Le résultat R = op1 ⊕ op2 est une tâche exécutée, composée de séquences de symboles de “e1”, de séquences de symboles de “e2”, suivies de séquences de symboles de “a” qui ne se suivent pas forcément et qui peuvent se répéter indéfiniment. Soient deux tâches périodiques concrètes τi = (r 1 i , Ci , Ti , Di) et τi+1 = (r 1 i+1, Ci+1, Ti+1, Di+1). On suppose que τi est plus prioritaire que τi+1. On veut ordonnancer τi et τi+1 en utilisant ⊕. τi étant la plus prioritaire on a R = τi⊕ τi+1. On étudie l’ordonnançabilité de τi et τi+1 sur l’intervalle Ii+1 = [rmin, Si+1+ Hi+1] avec rmin = min{r 1 j }τj∈{τi,τi+1} et Si+1, déterminé à l’aide du théorème 3.3.1. L’exécution de τi est périodique de période Ti et se répète indéfiniment à partir de r 1 i . Le coût d’une préemption est supposé être une constante donnée par α. Définition 3.4.1 La durée d’exécution de la tâche τi+1 sur son instance k avec prise en compte du coût exact de la préemption appelée “Preemption Execution Time” (PET) est donnée par : C k i+1 = Ci+1 + npk i+1 ∗ α npk i+1 est le nombre exact de préemption de τi+1 sur son instance k. La figure 3.1 donne une illustration du PET. Le nombre npk i+1 de préemptions de la tâche τi+1 sur son instance k est calculé selon le principe suivant : – npk i+1 est initialisé à zéro au début de l’instance k,60 Ordonnancement monoprocesseur de tâches indépendantes τ k 2 r k r 2 + T2 k 2 Coût d’une préemption Préemption de τ k 2 τ k 1 r k 1 r k r 1 + 2T1 k 1 + T1 Ck 2 = C2 + 2α FIGURE 3.1 – Illustration du PET de l’instance k de τ2 – à chaque fois que τi+1 est préemptée par τi , npk i+1 est incrémenté de 1 et on ajoute α unités de temps à la durée d’exécution qui reste à τi+1 pour finir son exécution. Ceci permet de prendre en compte les préemptions engendrées par d’autres préemptions; – à la fin de l’instance k, npk i+1 correspond au nombre exact de préemptions de τi+1. L’algorithme 1 ci-dessous présente les différentes étapes de l’ordonnancement de τi et τi+1 utilisant ⊕. 3.4.2 Application Pour illustrer l’ordonnancement avec ⊕ on considère les tâches τ1 = (1, 2, 4; 4) et τ2 = (0, 2, 6, 6) avec τ1 plus prioritaire que τ2. L’intervalle d’étude de l’ordonnancement de τ1 et τ2 est calculé à l’aide du théorème 3.3.1. Cet intervalle est donné par I2 = [0, 18]. La figure 3.2 ci-dessous donne les différentes étapes de l’ordonnancement avec ⊕. 3.5 Analyse d’ordonnançabilité avec ⊕ Soit un ensemble de tâches périodiques concrètes Γn = {τ1, τ2 · · · , τn} où les tâches sont triées dans l’orde décroissant de leurs priorités selon l’algorithme à priorités fixes noté Algo. Puisque l’opération d’ordonnancement ⊕ ne s’applique qu’entre deux opérandes à la fois, alors ⊕ est appliquée n − 1 fois et de façon itérative pour faire l’analyse d’ordonnancement de l’ensemble Γn. Ainsi si Rn est3.5 Analyse d’ordonnançabilité avec ⊕ 61 Algorithme 1 R = τi ⊕ τi+1 1: Calculer l’intervalle d’étude de l’ordonnancement de τi et τi+1 noté Ii+1 2: Référencer τi et τj par rapport à la même origine de temps rmin = min{r 1 j }τj∈{τi,τi+1} 3: Répéter l’exécution de τi autant de fois qu’il y a d’instances de τi sur l’intervalle Ii+1. Ceci est possible car τi est la plus prioritaire donc elle peut s’exécuter sans être préemptée 4: Délimiter toutes les instances de τi+1 sur l’intervalle Ii+1. Soit ni+1 le nombre d’instances de τi+1 sur Ii+1 5: ordonnançable ← vrai 6: k ← 1 7: tant que (k ≤ ni+1) et (ordonnançable = vrai) faire 8: Calculer C k i+1, la durée d’exécution de τi+1 sur son instance k avec le coût exact de la préemption 9: Compter le nombre d’unités de temps libres ”a” sur l’instance k de τi . On note par idlek ce nombre. 10: si idlek < Ck i+1 alors 11: ordonnançable ← f aux 12: sinon 13: τi+1 ne rate pas son échéance sur l’instance k 14: Remplacer les C k i+1 premières unités de temps libres ”a” par des unités de temps ei+1 exécutées par τi+1 15: fin si 16: fin tant que 17: si ordonnançable = vrai alors 18: τi et τi+1 sont ordonnançables et R le résultat de l’ordonnancement de τi et τi+1 est donné par Ii+1 avec des exécutions de τi et de τi+1. Cet ordonnancement est périodique de période Hi+1 = ppcm(Ti , Ti+1) et se répète indéfiniment à partir de si+1 déterminé à l’aide du théorème 3.3.1 19: sinon 20: τi et τi+1 ne sont pas ordonnançables car il existe une instance de τi+1 dans laquelle τi+1 n’est pas ordonnançable. 21: fin si62 Ordonnancement monoprocesseur de tâches indépendantes le résultat de l’ordonnancement de Γn, alors Rn est obtenu par : ( R1 = τ1 Ri+1 = Ri ⊕ τi+1, 1 ≤ i < n À la fin de l’analyse d’ordonnançabilité, nous pouvons produire la table d’ordonnancement des tâches qui contient les dates de début et de fin d’exécution de chaque tâche. Il faut noter que c’est le choix de priorité qui détermine l’ordre d’application de ⊕, de la tâche la plus prioritaire à la moins prioritaire. La complexité de l’analyse d’ordonnançabilité de Γn basée ⊕ est évaluée à O(n.l) avec l = ppcm{Ti : τi ∈ Γn}. 3.6 Facteur d’utilisation du processeur avec coût de la préemption Le facteur d’utilisation classique du processeur pour l’ensemble de tâches Γn = {τ1, τ2, · · · , , τn} avec τi = (r 1 i , Ci , Ti , Di) est donné par : U = Xn i=1 Ci Ti Lorsque le coût de la préemption est prise en compte, la durée d’exécution d’une tâche τi avec le coût de la préemption sur une instance k est donnée par C k i ≥ Ci . C k i est obtenu en ajoutant sur la durée d’exécution Ci le coût associé au nombre de préemptions de τi sur l’instance k. On note par ni le nombre d’instances de la tâche τi sur les deux phases (transitoire et permanente) de l’ordonnancement. Définition 3.6.1 Le facteur d’utilisation du processeur avec prise en compte du coût exact de la préemption noté U ∗ est défini par : U ∗ = Xn i=1 C ∗ i Ti avec C∗ i = Xni k=1 C k i ni (3.1) 3.7 Impact du coût de la préemption dans l’analyse d’ordonnançabilité Dans cette section nous présentons l’impact du coût de la préemption dans l’analyse d’ordonnançabilité des tâches. Pour cela nous considérons deux cas.3.7 Impact du coût de la préemption dans l’analyse d’ordonnançabilité 63 Dans le cas 1 on suppose que le coût de la préemption est négligeable (α = 0). Dans le cas 2 on suppose que le coût de la préemption n’est pas approximé dans la pire durée d’exécution des tâches (α = 1). Pour montrer l’impact du coût de la préemption, nous comparons les taux de succès de l’analyse d’ordonnançabilité dans les deux cas. Soit un ensemble E composé de plusieurs ensembles de tâches, le taux de succès d’un algorithme A sur E est défini par : nombre d′ ensembles de tâches ordonnançables avec A nombre total d′ensembles de tâches dans E (3.2) Afin de comparer les taux de succès de l’analyse d’ordonnançabilité avec ⊕, nous générons aléatoirement, en utilisant l’outil FORTAS [CG11] fondé sur l’algorithme de Bini [BB05], 15 ensembles chacun composé de 10 ensembles de tâches. Chaque ensemble de tâches est composé de 10 tâches. On calcule le taux de succès de ⊕ dans les deux cas et sur chaque ensemble d’ensembles de tâches. La courbe des taux de succès dans chacun des deux cas et les résultats sont présentés par la figure 3.3. Sur l’axe des ordonnées nous avons les taux de succès et sur l’axe des abscisses, les moyenne des facteurs d’utilisation des ensembles de tâches. En ce qui concerne les conditions techniques de test, l’ordinateur utilisé est un DELL muni d’un processeur IntelCoreTM 2 Duo (2,66 GHz, mémoire RAM 4Go). Dans la figure 3.3, on observe que jusqu’à un facteur d’utilisation moyen inférieur à 0.8, dans les deux cas nous avons des taux de succès de 1. Ce qui signifie que le coût des préemptions éventuelles dans le cas 2 n’affecte pas l’ordonnançabilité des ensembles de tâches. À partir d’un facteur d’utilisation moyen supérieur à 0.77, le taux de succès dans le cas 2 décroît jusqu’à 0. Par contre dans le cas 1, pour les ensembles d’ensembles de tâches avec des facteurs d’utilisation moyens entre 0.8 et 0.9, le taux de succès reste égal à 1 avant de décroître à 0.8. Ceci signifie que parmi les ensembles d’ensembles de tâches de facteurs d’utilisation moyen supérieur à 0.9 aucun ensemble de tâches n’est ordonnançable avec la prise en compte du coût exact de la préemption par contre sans prise en compte du coût de la préemption certains ensembles de tâches sont ordonnançables. Cela confirme le fait qu’en prenant en compte le coût exact de la préemption dans l’analyse d’ordonnançabilité des tâches, un ensemble de tâches peut être non ordonnançable alors qu’il a été déclaré ordonnançable en négligeant le coût de la préemption. Ceci dépend des facteurs d’utilisation des tâches et aussi du coût de chaque pré- emption. Dans notre exemple ceci semble être vérifié uniquement pour des tâches qui chargent beaucoup le processeur, mais même dans le cas contraire si le coût d’une préemption est élevé ce fait reste vérifié.64 Ordonnancement monoprocesseur de tâches indépendantes 3.8 Viabilité Dans cette section nous allons montrer que l’analyse d’ordonnançabilité basée sur ⊕ est viable. Cette viabilité est prouvée si un ensemble de tâches est ordonnançable avec ⊕, alors cet ensemble de tâches reste ordonnançable, même si une ou plusieurs tâches ont des durées d’exécution plus petites que celles considérées lors de l’analyse d’ordonnançabilité. Théorème 3.8.1 Soit un ensemble de tâches périodiques concrètes Γn = {τ1, · · · , τi , · · · , τn} où les tâches sont triées dans l’ordre décroissant de leurs priorités selon l’algorithme à priorités fixes noté Algo avec τi = (r 1 i , Ci , Ti , Di). Si Γn est ordonnançable avec ⊕, lors de l’exécution en remplaçant τ ′ i = (r 1 i , C′ i , Ti , Di) par τi avec C ′ i ≤ Ci alors Γ ′ n = {τ1, · · · , τ ′ i , · · · , τn} est aussi ordonnançable. Preuve on suppose que Γn = {τ1, · · · , τi , · · · , τn} est ordonnançable avec ⊕. Nous allons montrer par contradiction que Γ ′ n = {τ1, · · · , τ ′ i , · · · , τn} est aussi ordonnançable avec ⊕. Pour cela supposons que Γ ′ n n’est pas ordonnançable avec ⊕. Ce qui veut dire que ∃τl ∈ Γ ′ n tel que τl n’est pas ordonnançable. Puisque les i − 1 premières tâches de Γn sont les plus prioritaires et sont les mêmes que dans Γn alors leur ordonnancement ne change pas donc i ≤ l ≤ n. Supposons que l = i ce qui veut dire que c’est la tâche τ ′ i qui n’est pas ordonnançable, alors il existe une instance k de τ ′ i dans laquelle on ne peut exécuter toutes les C ′k i unités de temps de la tâche τ ′ i . Puisque nous avons des tâches indé- pendantes avec des priorités fixes et que de plus τi et τ ′ i ont la même priorité donc si C ′ i ≤ Ci alors C ′k i ≤ C k i ∀k ≥ 1. Il existe alors une instance k de la tâche τi dans laquelle on ne peut pas exécuter toutes les C k i unités de temps de τi . Ce qui veux dire que τi n’est pas ordonnançable donc Γn n’est pas ordonnançable. Ce qui est absurde d’après notre hypothèse de départ disant que Γn est ordonnançable. De la même manière on montre que si i < l ≤ n alors Γn n’est pas ordonnan- çable. Donc on a prouvé que si Γ ′ n n’est pas ordonnançable alors Γn ne l’est pas. D’où Γn ordonnançable entraîne que Γ ′ n soit aussi ordonnançable. 3.9 Conclusion Dans ce chapitre nous avons présenté le principe de l’analyse d’ordonnançabilité basée sur l’opération binaire d’ordonnancement ⊕ qui permet de prendre en compte le coût exact de la préemption en monoprocesseur. Ensuite nous avons montré que cette analyse d’ordonnançabilité est viable c’est dire si la durée d’exé- cution des tâches diminue au cours de leur exécution alors l’ensemble des tâches reste toujours ordonnançable. Dans le chapitre suivant, nous allons utiliser cette Caract´erisation locale de fautes dans les syst`emes large ´echelle Romaric Ludinard To cite this version: Romaric Ludinard. Caract´erisation locale de fautes dans les syst`emes large ´echelle. Networking and Internet Architecture. Universit´e de Rennes 1, 2014. French. HAL Id: tel-01094191 https://hal.inria.fr/tel-01094191 Submitted on 11 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.ANNEE 2014 ´ THESE / UNIVERSIT ` E DE RENNES 1 ´ sous le sceau de l’Universite Europ ´ eenne de Bretagne ´ pour le grade de DOCTEUR DE L’UNIVERSITE DE RENNES 1 ´ Mention : Informatique Ecole doctorale Matisse ´ present ´ ee par ´ Romaric LUDINARD prepar ´ ee´ a l’unit ` e de recherche INRIA Rennes - Bretagne Atlantique ´ Universite de Rennes 1 ´ Caracterisation locale ´ de fautes dans les systemes large ` echelle ´ These soutenue ` a Rennes ` le 02 octobre 2014 devant le jury compose de : ´ Ludovic ME´ / President ´ Professeur, Supelec, Rennes ´ Roberto BALDONI / Rapporteur Full Professor, Sapienza Universita Di Roma, Rome ` Sebastien T ´ IXEUIL / Rapporteur Professeur, UPMC, LIP6, Paris Emmanuelle ANCEAUME / Co-encadrante de th`ese Chargee de recherche CNRS, IRISA, Rennes ´ Marc-Olivier KILLIJIAN / Examinateur Directeur de recherche CNRS, LAAS, Toulouse Erwan LE MERRER / Examinateur Chercheur, Technicolor R&I, Rennes Bruno SERICOLA / Directeur de th`ese Directeur de Recherche, Inria, Rennes Franc¸ois TAIANI / Examinateur Professeur, Universite de Rennes 1, Rennes ´Remerciements Les travaux pr´esent´es dans ce manuscrit n’auraient jamais pu voir le jour sans le concours et le soutien d’un certain nombre de gens, tant durant la th`ese elle-mˆeme que pendant la (longue) p´eriode de cheminement qui l’a pr´ec´ed´ee. Malheureusement, la mise en place d’une liste exhaustive de remerciements est une tˆache ardue et je vais certainement en oublier certains. J’esp`ere ne pas commettre trop de fautes et que les personnes concern´ees ne m’en tiendront pas rigueur. Afin de simplifier cet exercice et tenter de limiter mes propres oublis, je vais proc´eder `a des remerciements par ensemble coh´erent de personnes et de mani`ere `a peu pr`es ant´echronologique. Pour commencer, je souhaite remercier Ludovic M´e, Professeur `a Sup´elec, pour avoir accept´e de pr´esider mon jury de doctorat, ainsi que pour les diverses et riches interactions que nous avons pu avoir au cours des diff´erents projets men´es avant ma th`ese. Je remercie tr`es chaleureusement Roberto Baldoni, Full Professor `a l’Universit´e La Sapienza `a Rome, et S´ebastien Tixeuil, Professeur `a l’UMPC / LIP6, pour leurs lectures que j’imagine nombreuses et attentives, leurs remarques et critiques vis-`avis de ce manuscrit. Enfin, je souhaite remercier Marc-Olivier Killijian, Directeur de Recherche CNRS au LAAS, et Fran¸cois Taiani, Professeur `a l’Universit´e de Rennes 1, d’avoir accept´e le rˆole d’examinateur dans ce jury. Mes remerciements suivants s’adressent aux personnes avec qui j’ai pu travailler directement pendant ces trois ans (et quelques mois) qui sont les piliers de ces travaux. Il est ´evident que sans leur concours, cette th`ese serait tout autre. Un grand merci `a Erwan Le Merrer et Gilles Straub de Technicolor pour leur travail en amont de cette th`ese. Merci aussi pour l’accueil au sein de l’´equipe, l’accompagnement, les discussions, le travail men´e et la souplesse dont ils ont parfois du faire preuve. Un grand merci aussi `a Erwan pour l’interface avec Willem et Pierre, et `a Gilles pour l’interface avec d’autres. Je remercie bien ´evidemment Bruno Sericola, mon directeur de th`ese, pour son encadrement, son soucis du d´etail et de la pr´ecision ainsi que pour ses nombreuses remarques pertinentes. Enfin, une reconnaissance infinie `a Emmanuelle Anceaume, non pas tant pour l’encadrement pendant ces trois ann´ees de doctorat que pour la totalit´e du travail accompli ensemble depuis 8 ans. Merci pour son soutien, sa compr´ehension et son enthousiasme communicatif. Mes excuses au passage `a nos voisins de bureau qui nous ont incit´e plusieurs fois `a fermer la porte du bureau... J’ai le plaisir d’ˆetre Attach´e Temporaire d’Enseignement et de Recherche `a l’ISTIC pour l’ann´ee universitaire 2014-2015. Parmi les personnes qui constituent les 12 Remerciements diff´erentes ´equipes p´edagogiques auxquelles j’appartiens, je souhaite remercier tout particuli`erement Delphine Demange et Catherine Belleann´ee pour leur compr´ehension, leur support et leur soutien dans les semaines qui ont pr´ec´ed´e ma soutenance de th`ese. Je tiens tout particuli`erement `a remercier Yann Busnel et Jean-Louis Marchand que je connais depuis un certain temps, mais avec qui j’ai eu l’occasion de collaborer pendant ma th`ese. Cette collaboration a men´e `a l’un des r´esultats centraux de ce manuscrit et de mes travaux de th`ese. Pendant la dur´ee de ma th`ese j’ai ´et´e bilocalis´e entre mon bureau au centre de recherche Inria Rennes - Bretagne Atlantique au sein de l”´equipe Dionysos et Technicolor R&I `a Rennes. Je remercie chaleureusement les membres de ces deux ´equipes pour leur accueil et les discussions, s´eminaires, caf´es, sprints... que nous avons pu partager. Un clin d’œil particulier `a Alexandre Van Kempen et Nicolas Le Scouarnec pour le travail men´e sur le papier Gateways. Avant de commencer cette th`ese je suis intervenu dans diff´erents projets de recherche en tant qu’ing´enieur. Ces exp´eriences se sont montr´ees tr`es riches et font partie du chemin qui m’a men´e `a cette th`ese. Je remercie les personnes avec qui j’ai pu travailler dans le cadre de ces projets, et plus particuli`erement Fr´ed´eric Tronel, Michel Hurfin, JeanPierre Le Narzul, Eric Totel, Fr´ed´eric Majorczyk, Aina Ravoaja, Francisco Brasileiro ´ et Erwan Abgrall. Cette particularit´e a fait les joies d’un certain nombre de gens qui ont du travailler `a mettre en place les modalit´es pour que le financement de cette th`ese soit possible. Je remercie tout sp´ecialement Caroline Lebaron et Thierry G´elin qui ´etaient en premi`ere ligne pour la mise en place des aspects l´egaux de cette th`ese. Je dois enfin remercier les gens de mon entourage. Je remercie tout d’abord ma famille, entre autres pour le support question vignes quand j’´etais pris par la r´edaction et encore une fois ma m`ere, en particulier pour le support culinaire pour le pot de th`ese. Un grand merci `a Sara pour sa pr´esence et son soutien, en particulier pour les moments o`u la recherche d´eborde sur nos moments `a nous. Merci encore `a elle d’avoir chapeaut´e une bonne part du off du pot de th`ese de mani`ere transparente pour moi, et merci d’avance pour ce qu’il reste `a venir. Merci `a ceux qui ont suivi la mˆeme voie et qui ne sont certainement pas ´etrangers `a ce cheminement : la joyeuse compagnie de la smash-bavette (J´er´emy, Benoit Gronchon, JPio, Fanfou´e), les (ex-)doctorants Kostas, Antoine, H´everson, Erwan Raffin, Julien Stainer... Merci aux amis, ceux pr´esents pour mes 30 ans `a la conf´erence OPODIS 2012 : Yves-Alexis, Marie, Delf, Alex, Fred, merci aussi `a Pierre-Louis, Julien & Solenn, `a ceux qui n’ont pu ˆetre l`a : Ben Roux & Sol`ene, Jean-Loup, Nono... et enfin aux adeptes des chaˆınes de mails infinies : Marie & Alex, Marine & Vincent, J´e, Thom, Mathieu, Elo. ´Table des mati`eres Remerciements 1 Introduction 7 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Probl´ematique consid´er´ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Contexte de cette ´etude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1 Terminologie et mod`ele 15 1.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Mod`eles de d´efaillances consid´er´es . . . . . . . . . . . . . . . . . . . . . 17 1.3 Syst`eme large ´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2 Travaux connexes 23 2.1 Syst`emes large ´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.1 Gestion de la population . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.2 G´erer le dynamisme de la population . . . . . . . . . . . . . . . . 25 2.1.3 G´erer les comportement fautifs . . . . . . . . . . . . . . . . . . . 26 2.2 Organisation des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.1 Partitionnement de donn´ees statiques . . . . . . . . . . . . . . . 30 2.2.2 Donn´ees dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 Etat global du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . ´ 34 2.3.2 Caract´erisation de fautes . . . . . . . . . . . . . . . . . . . . . . 35 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3 Caract´erisation de fautes 43 3.1 Mod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.1.1 Pr´eliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.2 Terminologie et notations employ´ees . . . . . . . . . . . . . . . . 44 3.1.3 Mod´elisation de l’impact des fautes . . . . . . . . . . . . . . . . . 48 3.2 Probl`emes ´etudi´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 34 Table des mati`eres 3.3 Conditions d’appartenance `a Ik, Mk ou Uk . . . . . . . . . . . . . . . . . 55 3.3.1 Condition n´ecessaire et suffisante pour l’appartenance `a Ik . . . . 57 3.3.2 Condition suffisante pour l’appartenance `a Mk . . . . . . . . . . 57 3.3.3 Condition n´ecessaire et suffisante pour l’appartenance `a Mk . . . 60 3.3.4 Condition n´ecessaire et suffisante pour l’appartenance `a Uk . . . 62 3.3.5 Equivalence de caract´erisations . . . . . . . . . . . . . . . . . . . ´ 62 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4 Mise en œuvre algorithmique et ´evaluation 69 4.1 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.1 Calcul des ensembles ayant un mouvement r-coh´erent maximal . 69 4.1.2 Caract´erisation des fautes . . . . . . . . . . . . . . . . . . . . . . 76 4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 80 4.2.1 Param`etres de simulation . . . . . . . . . . . . . . . . . . . . . . 86 4.2.2 Comparaison des algorithmes . . . . . . . . . . . . . . . . . . . . 88 4.2.3 Impact de la fr´equence d’´echantillonnage des ´etats du syst`eme . 92 4.2.4 Pertinence du mod`ele . . . . . . . . . . . . . . . . . . . . . . . . 93 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5 FixMe : Une architecture auto-organisante pour la caract´erisation de fautes 101 5.1 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.2 Architecture de l’espace des qualit´es . . . . . . . . . . . . . . . . . . . . 104 5.2.1 El´ements de l’architecture FixMe . . . . . . . . . . . . . . . . . . ´ 104 5.2.2 Op´erations de FixMe . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.3 Gestion interne des seeds . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.5 Utilisation de FixMe pour la caract´erisation de fautes . . . . . . . . . . 118 5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6 Etude locale de PeerCube 131 ´ 6.1 Fonctionnement de PeerCube . . . . . . . . . . . . . . . . . . . . . . . . 131 6.1.1 Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.1.2 Op´erations de PeerCube . . . . . . . . . . . . . . . . . . . . . . . 133 6.2 Adversaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.2.1 Identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.2.2 Strat´egie de l’adversaire . . . . . . . . . . . . . . . . . . . . . . . 142 6.3 Mod´elisation d’un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 144 6.4 Etude de la composition d’un cluster . . . . . . . . . . . . . . . . . . . . ´ 154Table des mati`eres 5 6.4.1 Esp´erance du temps total pass´e dans les ´etats sains et pollu´es . . 155 6.4.2 Temps successifs pass´es dans les ´etats sains et pollu´es . . . . . . 157 6.4.3 Probabilit´es d’absorption . . . . . . . . . . . . . . . . . . . . . . 160 6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7 Evaluation de PeerCube 167 ´ 7.1 Etude de l’overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 167 7.1.1 Esp´erance de la proportion de clusters sains et pollu´es . . . . . . 168 7.1.2 Instant du premier changement topologique . . . . . . . . . . . . 172 7.2 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8 Conclusion 189 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Liste des publications 197 Revues internationales avec comit´e de lecture . . . . . . . . . . . . . . . . . . 197 Conf´erences internationales avec comit´e de lecture . . . . . . . . . . . . . . . 197 Workshops et conf´erences francophones . . . . . . . . . . . . . . . . . . . . . 198 Brevets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Table des figures 209 Liste des tableaux 213 Liste des algorithmes 2156 Table des mati`eresIntroduction Internet est un r´eseau de r´eseaux sans centre n´evralgique servant de support `a divers services tels que les communications ´electroniques, la messagerie instantan´ee, la vid´eo `a la demande ou le World Wide Web. L’acc`es `a Internet et son utilisation au quotidien se sont largement d´emocratis´es depuis sa cr´eation. En France, l’autorit´e de r´egulation des communications ´electroniques et des postes [ARC13] recensait au troisi`eme trimestre 2013, environ 24 millions d’abonnements au haut et tr`es haut d´ebit. Ces abonn´es sont r´epartis entre quelques fournisseurs d’acc`es `a Internet. Un fournisseur d’acc`es `a Internet, ou op´erateur de r´eseau, g`ere un r´eseau qui lui est propre et qui est connect´e `a d’autres r´eseaux au sein d’Internet. Un fournisseur d’acc`es `a Internet fournit `a ses utilisateurs une connexion `a Internet. Chaque utilisateur se connecte `a Internet au travers d’un ´equipement appel´e ”passerelle de connexion”. Ainsi connect´e, l’utilisateur peut ainsi utiliser les services bas´es sur Internet. Exemple 1 La figure 1 repr´esente une interconnexion possible de trois r´eseaux de fournisseurs d’acc`es `a Internet ( Fai 1, Fai 2 et Fai 3). Chaque utilisateur est connect´e `a Internet au travers d’une passerelle de connexion Internet repr´esent´e par les ronds bleus. Les passerelles de connexion sont reli´ees `a des routeurs Ri. Les routeurs sont reli´ees entre eux. Les fournisseurs de services d´eploient des serveurs au sein d’Internet afin de d´elivrer un service aux utilisateurs. La figure 1 illustre un positionnement possible de ces serveurs. La notation S y x repr´esente le serveur x d´elivrant le service sy. Par exemple, le service s1 est d´elivr´e par les serveurs S 1 1 , S 1 5 et S 1 6 . Notons que le service s1 est d´elivr´e par un serveur pr´esent dans chacun des trois r´eseaux. A l’inverse le service ` s4 n’est d´elivr´e que par un unique serveur S 4 4 pr´esent dans le r´eseau g´er´e par Fai 2. Enfin, les utilisateurs 1 `a 6 peuvent acc´eder au service s2 par le serveur S 2 8 . Supervision Malheureusement, chacun des ´el´ements pr´esents dans le r´eseau ou impliqu´es dans les services consomm´es par les utilisateurs peut potentiellement exhiber des d´efaillances. Par exemple, un routeur peut omettre de renvoyer temporairement le trafic qu’il re¸coit, sa bande passante peut ˆetre satur´ee ou il peut dupliquer des messages. De la mˆeme mani`ere, des messages peuvent ˆetre perdus sur les liens de communication, les serveurs 78 Introduction R1 R2 R3 R4 R5 R6 R7 R8 R9 1 2 3 5 4 6 7 8 9 10 S 1 1 S 2 2 S 3 3 S 4 4 S 1 5 S 1 6 S 5 7 S 2 8 S 4 9 Fai 1 Fai 2 Fai 3 Figure 1 – Disposition de serveurs au sein d’Internet peuvent ˆetre temporairement indisponibles et les passerelles de connexions peuvent avoir un comportement d´egrad´e voire devenir inop´erantes. La supervision d’un syst`eme est la tˆache qui consiste `a collecter et analyser des donn´ees du syst`eme de mani`ere continue afin de s’assurer du bon fonctionnement de celui-ci. La supervision d’un syst`eme permet ainsi de d´eceler si le syst`eme devient d´efaillant, c’est-`a-dire que le service qu’il d´elivre d´evie du service attendu. Les fournisseurs d’acc`es `a Internet et de services supervisent le syst`eme afin d’intervenir rapidement lorsqu’une d´efaillance est d´etect´ee. Les protocoles de supervision tels que Simple Network Managment Protocol (SNMP) [CFSD90] ou TR-69 [Bro] d´efinissent le comportement des entit´es supervis´ees ainsi que leurs interactions avec le superviseur qui collecte et analyse ces donn´ees. Les entit´es supervis´ees ex´ecutent une supervision locale de leur ´etat interne. Ces donn´ees sont disponibles `a la demande du superviseur ou lui sont envoy´ees p´eriodiquement. En cas de d´efaillance, un administrateur peut ex´ecuter des proc´edures locales sur l’entit´e supervis´ee `a des fins de diagnostic. Le diagnostic est la tˆache d’identification des causes d’une d´efaillance. Ces protocoles sont largement employ´es dans le cadre de la supervision d’´el´ements r´eseaux comme les routeurs. Le service assur´e par ces ´el´ements est local et consiste `a faire transiter des informations d’une interface vers une autre en fonction d’un ensemble de r`egles pr´e´etablies appel´ee “politique de routage”. Par exemple, un routeur se montre d´efaillant s’il ne fait plus transiter les informations, les fait transiter de mani`ere erron´ee ou s’il met trop de temps `a le faire. D’autre part, les protocoles de routage r´eseau sont redondants. De cette mani`ere, si un routeur est d´efaillant, le service est d´elivr´e en empruntant un chemin alternatif. La d´efaillance du routeur est ainsi masqu´ee `a l’utilisateur et permet `a l’op´erateur de rechercher les causes de cette d´efaillance, sans rupture de service.Introduction 9 Exemple 2 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons que l’utilisateur 4 consomme le service s4. Celui-ci est d´elivr´e par S 4 4 en empruntant les routeurs R2, R5 et R7. Si le routeur R5 devient d´efaillant, un chemin alternatif est emprunt´e de mani`ere transparente pour l’utilisateur, par exemple R2, R4 et R7. Probl´ematique consid´er´ee A l’inverse des ´equipements r´eseaux qui assurent un service local et dont on peut ` masquer les d´efaillances par l’utilisation de chemins redondants, les passerelles de connexion constituent un point unique de d´efaillance. En effet, une d´efaillance de la passerelle de connexion am`ene `a une d´egradation des services consomm´es par l’utilisateur. Par cons´equent, il est primordial pour l’op´erateur de superviser ces ´equipements afin de diagnostiquer au plus vite une d´efaillance et assurer la connexion de l’utilisateur `a Internet. De mani`ere similaire aux ´equipements r´eseau, on peut imaginer que chaque passerelle de connexion supervise la qualit´e des services consomm´es. Ainsi, lorsque la passerelle de connexion est d´efaillante, celle-ci peut notifier l’op´erateur r´eseau. Dans la pratique cette approche n’est pas employ´ee. L’exemple suivant illustre les limites de cette approche. Exemple 3 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons que l’utilisateur 5 consomme le service s2. Cas 1 Supposons que la passerelle de connexion 5 soit d´efaillante, la qualit´e du service s2 per¸cue par la passerelle diminue, la passerelle envoie une alarme `a l’op´erateur. Cas 2 Supposons `a pr´esent que le service s2 est d´elivr´e `a l’utilisateur 5 par le serveur S 2 8 . Consid´erons de plus que le serveur S 2 8 est d´efaillant, le service s2 est d´elivr´e par le serveur S 2 2 . Dans ce cas, l’utilisateur 5 per¸coit une variation de la qualit´e du service s2 li´ee au changement de serveur envoie une alarme `a l’op´erateur. Pourtant, la passerelle de connexion 5 n’est pas d´efaillante, l’alarme est inutile (faux positif ). Cas 3 Consid´erons `a pr´esent que les utilisateurs 1, 2, 3, 4, 5 et 6 consomment le service s2 d´elivr´e par le serveur S 2 8 . De la mˆeme mani`ere, si le serveur S 2 8 est d´efaillant, le service s2 pourra ˆetre d´elivr´e par le serveur S 2 2 . Dans ce cas, chaque utilisateur per¸coit une variation de qualit´e du service s2 et envoie donc une alarme `a l’op´erateur. Pourtant, aucune des passerelles de connexion 1, 2, 3, 4, 5, 6 n’est d´efaillante, ces alarmes sont inutiles. Afin d’´eviter de surcharger l’op´erateur avec des alarmes non pertinentes, ce type d’approche est d´esactiv´e dans la pratique. Comme l’illustre cet exemple, cette approche peut engendrer de nombreux faux positifs. Pour cette raison, ce type d’approche pour les passerelles de connexion est d´esactiv´e dans la pratique. Les protocoles SNMP ou TR-69 ne sont utilis´es que pour des tˆaches d’administration ou de diagnostic. Les fournisseurs d’acc`es `a Internet pallient10 Introduction l’absence de d´etection de d´efaillance automatique en d´el´eguant cette tˆache aux utilisateurs finaux et en utilisant des centres d’appels. Un utilisateur peut ainsi contacter un centre d’appel s’il per¸coit une d´efaillance et un technicien peut ´eventuellement rechercher les causes de la d´efaillance per¸cue par l’utilisateur. Bien qu’utilis´ee en pratique, cette approche n’est pourtant pas satisfaisante pour trois raisons. Tout d’abord, cette solution n´ecessite une activit´e humaine permanente pour r´epondre aux sollicitations des utilisateurs et ´eventuellement chercher `a localiser la d´efaillance per¸cue ainsi que les causes de celle-ci. D’autre part, il peut y avoir un d´elai important entre l’apparition de la d´efaillance et la notification de l’utilisateur, rendant ainsi plus difficile le travail de diagnostic. Enfin, les utilisateurs peuvent contacter le centre d’appel de l’op´erateur pour des raisons ind´ependantes du fonctionnement de la passerelle de connexion, comme illustr´e dans les cas 2 et 3 de l’exemple 3, nuisant ainsi `a l’efficacit´e d’une telle solution. Exemple 4 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons le cas 3 de l’exemple pr´ec´edent. Dans ce cas, les utilisateurs 1, 2, 3, 4, 5 et 6 consomment le service s2 d´elivr´e par le serveur S 2 8 . Si le serveur S 2 8 est d´efaillant, le service s2 pourra ˆetre d´elivr´e par le serveur S 2 2 . Dans ce cas, chaque utilisateur per¸coit une variation de qualit´e du service s2 et envoie donc une alarme `a l’op´erateur. Ces alarmes ne sont pas r´ev´elatrices de d´efaillances des passerelles de connexion 1, 2, 3, 4, 5, 6 et sont donc consid´er´ees comme des faux positifs. Afin d’´eviter la trop forte proportion de faux positifs, ce type d’alarmes est d´esactiv´e dans la pratique. En effet, l’approche actuelle consid`ere que chacune de ces alarmes, prise individuellement, constitue un faux positif, et donc que celles-ci n’apportent aucune information. Pour autant, si on consid`ere l’ensemble de ces alarmes, elles sont r´ev´elatrices d’une d´efaillance per¸cue par un grand nombre d’utilisateurs. Il semble donc int´eressant d’utiliser ces alarmes afin de faire la distinction entre les d´efaillances per¸cues par un petit nombre d’utilisateurs et les d´efaillances per¸cues par un grand nombre d’utilisateurs. L’exemple 4 nous montre que les variations de qualit´es per¸cues par les utilisateurs sont corr´el´ees lorsqu’ils per¸coivent une d´efaillance due `a une mˆeme cause appel´ee faute. Il semble donc int´eressant d’exploiter cette corr´elation afin de distinguer d’une part les d´efaillances per¸cues par un petit nombre d’utilisateurs, comme dans le cas d’une d´efaillance de passerelle de connexion, de celles per¸cues par un grand nombre d’utilisateurs, comme dans le cas d’une d´efaillance d’un ´equipement r´eseau ou d’un serveur. Dans le premier cas, nous parlerons de “faute isol´ee” tandis que dans le second cas nous parlerons de “faute massive”. La question qui se pose naturellement est alors la suivante : Dans quelle mesure et sous quelles conditions est-il possible de distinguer les fautes isol´ees des fautes massives, en ne se basant que sur les perceptions des utilisateurs ?Introduction 11 Contexte de cette ´etude L’exemple 4 illustre l’intuition que nous allons d´evelopper dans ce document : les utilisateurs ayant per¸cu des variations de qualit´es similaires sont susceptibles d’avoir per¸cu une mˆeme d´efaillance. Cependant, afin de clarifier cette intuition, l’exemple 4 occulte certains aspects du contexte consid´er´e. Tout d’abord, cette ´etude se place dans le contexte d’un r´eseau de fournisseur d’acc`es `a Internet. Par cons´equent, nous consid´erons ici plusieurs milliers (voire millions) d’utilisateurs connect´es et consommant divers services. D’autre part, nous consid´erons que plusieurs fautes sont susceptibles d’impacter le syst`eme dans un intervalle de temps restreint. Dans ce cas, le nombre d’alarmes dues `a des variations de qualit´es peut ˆetre tr`es grand et toutes les variations de qualit´es per¸cues ne sont donc pas n´ecessairement corr´el´ees entre elles. Enfin, la figure 1 d´ecrit repr´esente une interconnexion possible de trois r´eseaux de fournisseurs d’acc`es `a Internet ainsi que le placement des serveurs et des utilisateurs dans cette interconnexion. Cette illustration est utile pour d´ecrire la situation de l’exemple 4 mais n’est pas utilis´ee pour regrouper les variations de qualit´es similaires. Par cons´equent, les travaux d´ecrits dans ce document ne s’appuient pas sur la connaissance du r´eseau d’interconnexion, la position des diff´erents serveurs et utilisateurs dans le r´eseau. Organisation du document Le reste de ce document est organis´e en huit chapitres. Chapitre 1 Ce chapitre d´ecrit les concepts n´ecessaires aux travaux d´ecrits dans ce document. Plus pr´ecis´ement, les notions de faute, erreur et d´efaillance, relatives `a la sˆuret´e de fonctionnement sont rappel´ees. Dans un second temps, la notion de syst`eme large ´echelle est pr´esent´ee. Chapitre 2 Ce chapitre donne un aper¸cu des principales approches employ´ees dans la conception de syst`emes large ´echelle. Ensuite, ce chapitre d´ecrit diff´erentes familles d’algorithmes de clustering de donn´ees, le clustering ´etant la tˆache consistant `a regrouper les donn´ees similaires ensemble. Enfin, les principaux travaux existants sur la supervision et la caract´erisation de fautes dans les syst`emes large ´echelle sont pr´esent´es et discut´es. Chapitre 3 Ce chapitre d´ecrit un cadre id´eal permettant de mod´eliser l’impact des fautes dans le syst`eme sur les qualit´es des services per¸cues par les entit´es supervis´ees. Malgr´e ce cadre id´eal, nous montrons qu’il est impossible de d´eterminer de mani`ere certaine, pour chaque entit´e supervis´ee, si la d´efaillance qu’elle per¸coit est due `a une faute isol´ee ou `a une faute massive. Cependant, en assouplissant les choix possibles pour la caract´erisation du type de faute (isol´ee, massive ou ind´etermin´ee), on peut alors d´eterminer pour chaque variation anormale de qualit´e, le type de faute `a lui associer. Cette caract´erisation ne n´ecessite la connaissance que d’un sous-ensemble des entit´es12 Introduction du syst`eme. Celle-ci s’appuie sur la connaissance des entit´es percevant des qualit´es et des variations similaires et est aussi pr´ecise que celle que ferait un observateur ayant acc`es `a l’ensemble des entit´es du syst`eme. Chapitre 4 Ce chapitre fournit les algorithmes n´ecessaires `a la caract´erisation des fautes d´ecrite au chapitre 3. Nous montrons que ces algorithmes peuvent ˆetre ex´ecut´es localement et ne requi`erent qu’une connaissance partielle des entit´es du syst`eme. Ces algorithmes sont ´evalu´es et compar´es au travers de diverses simulations. Enfin, nous discutons de la pertinence du mod`ele que nous avons mis en place. Chapitre 5 Ce chapitre d´ecrit la mise en place de FixMe, une architecture autoorganis´ee permettant aux entit´es de trouver de mani`ere efficace les autres entit´es percevant des qualit´es similaires et ayant subi les mˆemes variations de qualit´e. Les algorithmes d´ecrivant les diff´erentes op´erations `a la mise en œuvre de cette architecture sont d´ecrits, ainsi que la complexit´e algorithmique de ces op´erations. Enfin, la mise en œuvre des algorithmes d´ecrits dans le chapitre 4 dans le cadre de cette architecture est d´ecrite. Chapitre 6 FixMe est form´e de deux niveaux, : le premier permettant g´erer les entit´es suivant la qualit´e per¸cue et le second, nomm´e PeerCube, g´erant les entit´es percevant une mˆeme qualit´e. Ce chapitre pr´esente le fonctionnement basique de PeerCube puis une ´evaluation de performance de ces composants ´el´ementaires. Nous y ´etudions le comportement de ces composants dans le pire cas d’ex´ecution, c’est-`a-dire en pr´esence d’un adversaire visant `a corrompre le syst`eme. Chapitre 7 Ce chapitre pr´esente une ´evaluation de performance de PeerCube dans son ensemble dans le pire cas d’ex´ecution. En s’appuyant sur l’´etude men´ee au chapitre 6, nous montrons que cette architecture est r´esiliente au churn (i.e., les entr´ees / sorties du syst`eme ont un impact restreint sur celui-ci) et qu’un adversaire n’a qu’un pouvoir limit´e sur cette architecture. Chapitre 8 Ce chapitre termine le pr´esent document. Les diff´erents chapitres et contributions y sont r´esum´es. Les pistes d’am´eliorations ainsi que les questions ouvertes et pistes de r´eflexion sont ensuite pr´esent´ees. Contributions et publications Les publications relatives au pr´esent document apparaissent dans la section bibliographie de ce chapitre d’introduction. Plus sp´ecifiquement, les contributions dont je suis le principal contributeur portent sur : — Les concepts, la mod´elisation et la mise en œuvre algorithmique abord´es aux chapitres 3 et 4. Ces travaux ont ´et´e pr´esent´e `a la conf´erence DSN [ABL+14a]Bibliographie 13 et `a AlgoTel [ABL+14b]. De plus, ces travaux ont conduit `a un d´epˆot de brevet [LLSS13] en collaboration avec Technicolor. — L’architecture pr´esent´ee dans le chapitre 5. Ce travail a ´et´e pr´esent´e `a OPODIS en 2012 [ALL+12] puis `a AlgoTel en 2013 [ALL+13b] ainsi que dans une conf´erence industrielle [ALL+13a]. De plus, ce travail a fait l’objet d’un d´epˆot de brevet [LLSS12] en collaboration avec Technicolor. — La mod´elisation probabiliste de PeerCube abord´ee au chapitre 6. Ce travail a ´et´e pr´esent´e en 2011 `a DSN [ASLT11] et `a CFIP [ALST11]. La liste compl`ete de mes publications se situe `a la fin du pr´esent document. Bibliographie [ABL+14a] E. Anceaume, Y. Busnel, E. Le Merrer, R. Ludinard, J-L. Marchand et B. Sericola : Anomaly Characterization in Large Scale Networks. Dans Proceedings of the 44th International Conference on Dependable Systems and Networks, DSN, juin 2014. [ABL+14b] E. Anceaume, Y. Busnel, E. Le Merrer, R. Ludinard, J-L. Marchand, B. Sericola et G. Straub : Anomaly Characterization Problems. Dans 16`emes Rencontres Francophones sur les Aspects Algorithmiques des T´el´ecommunications, AlgoTel, pages 1–4, 2014. [ALL+12] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : FixMe : A Self-organizing Isolated Anomaly Detection Architecture for Large Scale Distributed Systems. Dans Proceedings of the 16th International Conference On Principles Of Distributed Systems, OPODIS, pages 1–12, d´ecembre 2012. [ALL+13a] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : A Self-organising Isolated Anomaly Detection Architecture for Large Scale Systems. Dans Nem-Summit, octobre 2013. [ALL+13b] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : FixMe : D´etection R´epartie de D´efaillances Isol´ees. Dans 15`emes Rencontres Francophones sur les Aspects Algorithmiques des T´el´ecommunications, AlgoTel, pages 1–4, mai 2013. [ALST11] E. Anceaume, R. Ludinard, B. Sericola et F. Tronel : Mod´elisation et Evaluation des Attaques Cibl´ees dans un Overlay Structur´e. Dans ´ Colloque Francophone sur l’Ing´enierie des Protocoles, CFIP, 2011. [ARC13] ARCEP : Haut et tr`es haut d´ebit sur r´eseaux fixes au 30 septembre 2013. http://www.arcep.fr/index.php?id=12115, novembre 2013. [ASLT11] E. Anceaume, B. Sericola, R. Ludinard et F. Tronel : Modeling and Evaluating Targeted Attacks in Large Scale Dynamic Systems. Dans Proceedings of the 41rst International Conference on Dependable Systems and Networks, DSN, pages 347–358, juin 2011.14 Introduction [Bro] Broadband Forum : TR-069 CPE WAN Management Protocol Issue 1, Amend.4, 2011. [CFSD90] J. D. Case, M. Fedor, M. L. Schoffstall et J. Davin : Simple Network Management Protocol (SNMP). Rapport technique, IETF, 1990. [LLSS12] E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : Method for Isolated Anomaly Detection in Large-scale Data Processing Systems. patent no. 12306237.4, octobre 2012. [LLSS13] E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : Method for Isolated Anomaly Detection in Large-scale Audio/Video/Data Processing Systems. patent no. 13306029.3, juillet 2013.Chapitre 1 Terminologie et mod`ele Ce chapitre rappelle les d´efinitions que nous utiliserons tout au long de ce document et pr´esente le contexte dans lequel se place nos travaux, `a savoir les syst`emes large ´echelle. 1.1 Terminologie Nous rappelons dans cette section les d´efinitions de Jean-Claude Laprie employ´ees dans [Lap96, ALRL04]. Fautes, erreurs et d´efaillances Un syst`eme est une entit´e qui interagit avec d’autres entit´es afin de rendre un service. L’utilisateur est une entit´e particuli`ere qui interagit avec le syst`eme consid´er´e afin d’utiliser le service qu’il d´elivre. Le service est correct si le service d´elivr´e accomplit la fonction du syst`eme, i.e., ce pour quoi le syst`eme est destin´e. La sˆuret´e de fonctionnement d’un syst`eme est d´efinie comme ”la propri´et´e qui permet `a ses utilisateurs de placer une confiance justifi´ee dans la qualit´e du service qu’il leur d´elivre”. Un syst`eme est d´efaillant lorsque le service qu’il d´elivre d´evie du service correct ou attendu. Une d´efaillance est la cons´equence d’une faute dans le syst`eme. Un ´etat d’erreur d´esigne l’´etat anormal du syst`eme, r´esultant de l’activation d’une faute et pouvant potentiellement amener `a une d´efaillance. L’erreur permet de lier la faute `a la d´efaillance per¸cue par l’utilisateur. Ces notions sont d´ependantes du syst`eme consid´er´e. Ainsi, un mˆeme ´ev´enement pourra ˆetre une faute, une erreur ou une d´efaillance suivant le point de vue fonctionnel consid´er´e. Consid´erons un syst`eme constitu´e d’un serveur d´elivrant un service. En cas de panne ´electrique (faute), le serveur n’est plus aliment´e (erreur) et ne peut plus d´elivrer son service (d´efaillance). Un syst`eme est g´en´eralement compos´e de sous-syst`emes qui interagissent entre eux. Une d´efaillance de l’un de ces sous-syst`emes peut-ˆetre consid´er´ee comme une faute dans le syst`eme global. 1516 Mod`ele R1 R2 R3 R4 R5 R6 R7 R8 R9 1 2 3 5 4 6 7 8 9 10 S 1 1 S 2 2 S 3 3 S 4 4 S 1 5 S 1 6 S 5 7 S 2 8 S 4 9 Figure 1.1 – Disposition de serveurs au sein d’Internet Mod`eles de d´efaillances L’activation d’une faute dans le syst`eme peut avoir des cons´equences variables. Les d´efaillances peuvent ˆetre cat´egoris´ees suivant deux aspects : le domaine de d´efaillance et la coh´erence des d´efaillances. Le premier aspect porte sur le service rendu par le syst`eme et le d´elai n´ecessaire pour fournir ce service. On parle de d´efaillance en valeur lorsque le syst`eme d´elivre une valeur ou un service erron´e. Lorsque le service n’est pas d´elivr´e au moment attendu (trop tˆot ou trop tard), on parle de d´efaillance temporelle. Lorsque le service n’est plus rendu, on parle de d´efaillance par arrˆet. D’autre part, on dit d’une d´efaillance qu’elle est coh´erente si tous les utilisateurs per¸coivent la mˆeme d´eviation du service vis-`a-vis du service attendu. Enfin, si le comportement d’une entit´e du syst`eme d´evie de mani`ere arbitraire de son comportement normal ou attendu, on parle de d´efaillance byzantine. Dans un syst`eme de communication par message, l’absence d’´emission de message par une entit´e peut constituer une d´efaillance coh´erente. A l’inverse, une entit´e envoyant des messages avec un contenu ` incorrect (d´efaillance en valeur), au mauvais moment (d´efaillance temporelle) ou non pr´evus constitue une d´efaillance byzantine. Exemple 5 La figure 1.1 illustre un exemple de syst`eme que nous consid´erons dans le cadre de ce document. Le syst`eme est constitu´e d’une ensemble de routeurs interconnect´es par des liens, de serveurs d´elivrant des services et de passerelles utilisateurs. Chaque utilisateur consomme des services propos´es par le syst`eme de mani`ere transparente comme illustr´e sur la figure 1.2. Dans cette figure, le service s2 est d´elivr´e par les serveurs S 2 2 et S 2 8 , tandis que le service s3 n’est fourni que par le serveur S 3 3 . L’utilisateur 5 consomme ces deux services s2 et s3. Consid´erons le serveur S 3 3 comme un sous-syst`eme du syst`eme consid´er´e. Si une panne ´electrique (faute) se produit au niveau du serveur S 3 3 , celui-ci n’est plus aliment´e (erreur), le service s3 n’est plus rendu (d´efaillance). Dans le contexte du syst`eme global, la d´efaillance du serveur S 3 3 constitue une faute. Le serveur S 3 3 est le seul `a d´elivrerMod`eles de d´efaillances consid´er´es 17 1 2 3 5 4 6 7 8 9 10 s1 s2 s3 s4 s5 Figure 1.2 – Acc`es au services le service s3. Celui-ci n’est plus rendu, il s’agit d’une d´efaillance par arrˆet. Tous les utilisateurs du syst`eme souhaitant consommer le service s3 per¸coivent cette d´efaillance. Il s’agit d’une d´efaillance coh´erente. Consid´erons `a pr´esent le serveur S 2 8 comme un sous-syst`eme du syst`eme consid´er´e. Dans les mˆemes circonstances, si une panne ´electrique (faute) se produit au niveau du serveur S 2 8 , celui-ci n’est plus aliment´e (erreur) et ne rend plus le service s2. Dans le contexte du syst`eme global, la d´efaillance du serveur S 2 8 constitue l’activation d’une faute. On suppose ici que le serveur S 2 2 prend le relais du serveur S 2 8 , il d´elivre le service s2 `a l’utilisateur 5. Deux cas se pr´esentent : — Si ce service est d´elivr´e sans perte de qualit´e, il n’y a pas de d´efaillance. — A l’inverse, une d´efaillance est pr´esente s’il y a une d´egradation de qualit´e. ` De plus, les entit´es 1, 2, 3, 4, 6 per¸coivent la mˆeme d´efaillance. Il s’agit d’une d´efaillance coh´erente. Consid´erons enfin l’ensemble des serveurs S 2 8 et S 2 2 comme un sous-syst`eme du syst`eme consid´er´e. Dans les mˆemes circonstances, si une panne ´electrique (faute) se produit au niveau du serveur S 2 8 , celui-ci n’est plus aliment´e (erreur) et ne rend plus le service s2. Dans le contexte du syst`eme global, la d´efaillance du serveur S 2 8 constitue l’activation d’une faute. On suppose ici que le serveur S 2 2 prend le relais du serveur S 2 8 , il d´elivre le service s2 `a l’utilisateur 5. Deux cas se pr´esentent : — Si ce service est d´elivr´e sans perte de qualit´e, il n’y a pas de d´efaillance. — A l’inverse, une d´efaillance est pr´esente s’il y a une d´egradation de qualit´e. De ` plus, les entit´es 1, 2, 3, 4, 6 per¸coivent la mˆeme d´efaillance. Cependant, l’entit´e 10 dont le service est d´elivr´e par le serveur S 2 2 ne per¸coit pas de variation de qualit´e. Il ne s’agit donc pas d’une d´efaillance coh´erente. 1.2 Mod`eles de d´efaillances consid´er´es Nous nous int´eressons dans le cadre de ce document `a la supervision d’un sousensemble des entit´es du syst`eme. On s´epare ces entit´es en deux sous-ensembles : d’un18 Mod`ele cot´e les entit´es supervis´ees, qui consomment des services fournis par le syst`eme tels que VoIP, VOD, ..., et de l’autre les entit´es qui sont impliqu´ees dans le fonctionnement ou l’acheminement du service d´elivr´e. Ce second ensemble contient les liens de communication, les serveurs, les routeurs r´eseau, etc... et est appel´e environnement. Dans la figure 1.2, les entit´es supervis´ees sont repr´esent´ees par les ronds bleus et l’environnement par le nuage central. Nous consid´ererons dans ce document que les fautes activ´ees au sein de l’environnement peuvent conduire `a des d´efaillances temporelles et coh´erentes. De plus, nous supposerons que ces d´efaillances v´erifient un ensemble de contraintes d´ecrites au chapitre 3. La validit´e de cette hypoth`ese sera discut´ee lors de l’´evaluation de l’approche d´ecrite dans ce document au chapitre 4. D’autre part, nous consid´erons dans les chapitres 3, 4 et 5 que les entit´es supervis´ees sont sujettes `a des fautes donnant lieu `a des d´efaillances de mˆeme nature : des d´efaillances temporelles et coh´erentes. Nous supposons dans ce document que les entit´es supervis´ees effectuent r´eguli`erement des mesures de qualit´e des services consomm´es. Lorsqu’une faute est activ´ee, sur une entit´e supervis´ee ou au sein de l’environnement, ces mesures varient de fa¸con anormale. Nous supposons l’existence d’un m´ecanisme permettant de d´etecter ces variations anormales. Nous pouvons envisager deux types d’approches pour la mise en œuvre pratique de ce m´ecanisme de d´etection : les outils de d´etection de changement ou les outils pr´edictifs. Ces m´ethodes supposent qu’en l’absence de d´efaillances, les valeurs mesur´ees sont repr´esentatives d’une variable al´eatoire de loi inconnue. La pr´esence d’une d´efaillance se traduit alors par un changement de distribution des valeurs mesur´ees. La d´etection de changement est un outil d’analyse s´equentielle visant `a d´etecter les changements dans la distribution de valeurs d’une s´erie temporelle. Lorsque ces mesures varient subitement, ces valeurs ne suivent plus cette distribution. Les outils de d´etection de changement permettent de d´etecter cette variation. Un tel m´ecanisme peut ˆetre par exemple mis en œuvre au moyen de Cusum (Cumulative Sum control chart) [Pag54]. Les mod`eles pr´edictifs, quant `a eux, estiment `a chaque instant la valeur de la future mesure. Une diff´erence trop importante entre la mesure effectu´ee `a l’instant suivant et la mesure pr´edite constitue une d´efaillance. Les m´ethodes de lissage exponentiel [Hol04, Win60] qui calculent une moyenne (potentiellement pond´er´ee) sur les derni`eres valeurs mesur´ees et l’utilisent comme pr´evision ou les filtres de Kalman [Kal60] qui permettent d’estimer l’´etat d’un syst`eme dynamique `a partir d’une s´erie de mesures incompl`etes ou bruit´ees sont des m´ethodes pr´edictives. Les chapitres 6 et 7 sont d´edi´es `a la mod´elisation probabiliste et l’´evaluation de PeerCube qui constitue une partie du syst`eme propos´e. Afin d’´evaluer la pertinence de cette approche, nous consid´erons un mod`ele de d´efaillances plus fort que celui consid´er´e au d´ebut de ce document. Dans ces chapitres, nous consid´erons un adversaire contrˆolant une partie des entit´es supervis´ees du syst`eme. Ces entit´es agissent en collusion et sont sujettes `a des d´efaillances byzantines. De cette mani`ere, nous ´evaluons ce syst`eme dans un pire cas.Syst`eme large ´echelle 19 1.3 Syst`eme large ´echelle Cette section d´efinit la notion de syst`eme large ´echelle et pr´esente les principes g´en´eraux qui r´egissent la conception de ces syst`emes ainsi que les probl´ematiques associ´ees. Un syst`eme est dit ”large ´echelle” s’il est compos´e d’un tr`es grand nombre d’entit´es. On dit qu’un syst`eme ”passe `a l’´echelle”, s’il reste capable de d´elivrer le service pour lequel il a ´et´e con¸cu, mˆeme lorsque le nombre d’entit´es qui le compose devient tr`es important. Plus pr´ecis´ement, un syst`eme large ´echelle est un syst`eme dans lequel les entit´es interagissent au moyen d’algorithmes locaux. Ce type d’algorithmes ne d´epend que de l’´etat de l’entit´e ainsi que de son voisinage proche. Cette notion de voisinage varie suivant les syst`emes. Un tel syst`eme passe `a l’´echelle si les complexit´es spatiales (stockage, m´emoire, ...) et temporelles (nombre de messages, temps de r´eponses, ...) des algorithmes ex´ecut´es par les entit´es sont sous-lin´eaires en fonction du nombre d’entit´es pr´esentes dans ce syst`eme. Les syst`emes pair-`a-pairs sont un exemple de syst`eme large ´echelle dans la mesure o`u il n’est pas inhabituel qu’ils soient compos´es de plusieurs millions d’entit´es. Le partage de fichiers est une application bien connue bas´ee sur ce type de syst`eme. Dans ce type d’application, chaque entit´e joue `a la fois de rˆole de client et de serveur. L’augmentation du nombre d’entit´es impliqu´ees dans le syst`eme contribue `a faciliter les ´echanges de fichiers. Ce type de syst`eme passe `a l’´echelle. Un protocole est un ensemble de r`egles r´egissant les traitements effectu´es par les entit´es ainsi que la communication entre ces entit´es en vue de rendre le service pour lequel le syst`eme est con¸cu. Afin que le syst`eme passe `a l’´echelle, il est n´ecessaire que le protocole consid´er´e utilise des algorithmes locaux. Les entit´es du syst`eme sont organis´ees logiquement afin que chacune est acc`es `a son voisinage et non `a l’int´egralit´e du syst`eme. Une architecture ou overlay d´esigne la structure logique issue de cette organisation logique, permettant ainsi de d´efinir le voisinage d’une entit´e. On distingue trois enjeux dans la conception de syst`emes large ´echelle : 1. la gestion du grand nombre d’entit´es dans le syst`eme 2. la gestion du dynamisme des entit´es dans le syst`eme 3. la gestion des fautes dans le syst`eme Gestion de la population Afin d’assurer la propri´et´e de passage `a l’´echelle, les protocoles de ce type de syst`eme ne s’appuient que sur un sous-ensemble des entit´es du syst`eme appel´e voisinage. Un protocole d´efinit une structure de r´eseau logique. Ce r´eseau constitue le substrat n´ecessaire `a la mise en œuvre du service pour lequel le syst`eme est mis en place. On distingue classiquement deux familles de protocoles : les protocoles `a architecture non structur´ee et ceux `a architecture structur´ee. Dans le cas des architectures non structur´ees, le lien logique qui unit deux entit´es du syst`eme n’a pas de s´emantique. Ces protocoles engendrent g´en´eralement un graphe de communication proche d’un graphe al´eatoire. Les overlays non structur´es sont g´en´eralement employ´es dans le cas de protocoles d’agr´egation de donn´ees ou afin20 Mod`ele de g´erer simplement une grande population d’entit´es. En revanche, ces protocoles ne sont pas adapt´es `a la recherche de donn´ees. En effet, en l’absence de s´emantique sur les liens logiques unissant les entit´es du syst`eme, il n’est pas possible d’effectuer une recherche d´eterministe dans ce type de structure. Par cons´equent, la localisation d’une entit´e se fait par inondation n´ecessitant ainsi un grand nombre de communications. A l’inverse, dans le cas des architectures structur´ees, une s´emantique d´efinit le lien ` unissant deux entit´es du syst`eme. Ces protocoles engendrent g´en´eralement des graphe de communication proches d’un graphe r´egulier. L’exemple le plus courant d’architecture structur´ee est la table de hachage distribu´ee (DHT). Dans ce type d’architecture, chaque entit´e se voit attribuer un identifiant unique de m bits issu d’une fonction de hachage (par exemple MD5 [Riv92] ou SHA-1 [EJ01]). Une entit´e est alors connect´ee `a une autre si ces deux entit´es satisfont une condition particuli`ere d´efinie par le protocole concern´e. L’espace des identifiants {0, 1} m est partitionn´e entre toutes les entit´es du syst`eme. De la mˆeme mani`ere que pour les entit´es, un identifiant unique de m bits est attribu´e `a chaque donn´ee g´er´ee par le syst`eme. Chaque donn´ee est g´er´ee par l’entit´e la plus proche de son identifiant, au sens d’une distance d´efinie par le protocole. Les DHT offrent ainsi une association (cl´e, valeur) mise en œuvre par les entit´es pr´esentes dans le syst`eme en utilisant les propri´et´es du graphe de communication. Dans ce document, nous nous concentrerons sur ce type d’architecture. Gestion du dynamisme Les entit´es d’un syst`eme large ´echelle peuvent avoir tendance `a entrer et sortir du syst`eme. N´eanmoins ces entr´ees / sorties ne constituent pas des d´efaillance par arrˆet, ce type de comportement est usuel dans un syst`eme large ´echelle. A chaque entr´ee ou sortie d’une entit´e du syst`eme, le r´eseau logique d’inter- ` connexion des entit´es doit ˆetre mis `a jour afin d’´eviter un partitionnement du r´eseau logique ou des incoh´erences. Cette op´eration de mise `a jour peut s’av´erer coˆuteuse et il est donc n´ecessaire que les protocoles employ´es g`erent ces mises `a jour de mani`ere de mani`ere locale afin de conserver la propri´et´e de passage `a l’´echelle. Gestion des comportements fautifs Les entit´es qui composent un syst`eme large ´echelle sont susceptibles de subir des d´efaillances byzantines. Dans ce cas, l’entit´e n’ex´ecute plus le protocole d´efini et exhibe un comportement arbitraire. Par cons´equent, une telle entit´e peut fournir des informations erron´ees aux entit´es de son voisinage pouvant mettre en p´eril la logique du r´eseau d’interconnexion des entit´es ou l’ex´ecution du protocole d´efini par les entit´es de son propre voisinage. La gestion des comportements fautifs constitue un ´el´ement cl´e de la conception de ces syst`emes. Bibliographie [ALRL04] A. Avizienis, J. C. Laprie, B. Randell et C. Landwehr : Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1):11–33, janvier 2004.Bibliographie 21 [EJ01] D. Eastlake et P. Jones : US Secure Hash Algorithm 1 (SHA1). Rapport technique, IETF, 2001. [Hol04] C. C. Holt : Forecasting seasonals and trends by exponentially weighted moving averages. International Journal of Forecasting, 20(1):5–10, 2004. [Kal60] R. E. Kalman : A New Approach to Linear Filtering and Prediction Problems. Transactions of the ASME–Journal of Basic Engineering, 82:35–45, 1960. [Lap96] J. C. Laprie : Guide de la sˆuret´e de fonctionnement. C´epadu`es-Editions, 1996. [Pag54] E. S. Page : Continuous Inspection Schemes. Biometrika, 41(1/2):100–115, juin 1954. [Riv92] R. Rivest : The MD5 Message-Digest Algorithm. Rapport technique, IETF, 1992. [Win60] P. R. Winters : Forecasting Sales by Exponentially Weighted Moving Averages. Management Science, 6:324–342, 1960.22 Mod`eleChapitre 2 Travaux connexes Nous nous int´eressons dans le cadre de cette th`ese `a distinguer les fautes massives, donnant lieu `a une d´efaillance per¸cue par un grand nombre d’entit´es du syst`eme, des fautes isol´ees amenant `a une d´efaillance per¸cue par un nombre restreint d’entit´es. Cette distinction est fait dans le cadre d’un r´eseau large ´echelle et se base sur la perception de la qualit´e des services consomm´es par les entit´es supervis´ees sans connaissance de l’environnement. Nous pr´esentons dans ce chapitre les approches employ´ees dans la conception des syst`emes large ´echelle. Nous pr´esentons ensuite diverses approches visant `a regrouper les donn´ees similaires. Enfin, nous pr´esentons les travaux existants majeurs sur la d´etection de fautes massives ou isol´ees dans les syst`emes large ´echelle. 2.1 Syst`emes large ´echelle Comme nous l’avons vu au chapitre pr´ec´edent, on distingue trois enjeux dans la conception de syst`emes large ´echelle : 1. la gestion du grand nombre d’entit´es dans le syst`eme, 2. la gestion du dynamisme des entit´es dans le syst`eme, 3. la gestion des fautes dans le syst`eme. Cette section d´etaille les principales approches employ´ees pour la conception de syst`emes large ´echelle. 2.1.1 Gestion de la population Les tables de hachage distribu´ees (DHT) sont largement utilis´ees pour la conception de syst`emes large ´echelle. Ces DHT permettent pour organiser logiquement les entit´es du syst`eme afin que chacune d’elles ait acc`es `a un sous-ensemble des entit´es du syst`eme (ce sous-ensemble est appel´e voisinage) et non au syst`eme dans son int´egralit´e. De cette mani`ere, la propri´et´e de passage `a l’´echelle est assur´ee. Il existe un grand nombre de DHT, cette partie pr´esente succinctement deux d’entre elles : CAN [RFH+01], con¸cu en 2001 par Ratnasamy, Francis, Handley, Karp et Shenker, et Chord [SMK+01], con¸cu 2324 Travaux connexes en 2001 par Stoica, Morris, Karger, Kaashoek et Balakrishnan. Ces DHT font partie des trois DHT originelles propos´ees en 2001 : Chord, CAN et Pastry [RD01]. Content Addressable Network [RFH+01] (CAN) Dans CAN, les entit´es sont plac´ees dans un espace virtuel `a d dimensions ayant une structure torique. Chaque entit´e est responsable d’une zone de cet espace. Un lien logique relie les entit´es g´erant des zones voisines dans cet espace, assurant ainsi la connectivit´e de l’ensemble du syst`eme. Lorsqu’une nouvelle entit´e rejoint le syst`eme, celle-ci contacte l’entit´e responsable de la zone qu’elle doit occuper. Cette zone est s´epar´ee en deux nouvelles zones que chacune des entit´es va g´erer. A l’inverse, lorsqu’une entit´e quitte le syst`eme, la zone ` dont elle avait la charge est transf´er´ee `a l’entit´e la plus proche. Si les deux zones sont voisines et de mˆeme surface, celles-ci sont fusionn´ees. La recherche de donn´ees dans ce syst`eme se fait de proche en proche en contactant l’entit´e voisine la plus proche de la destination comme l’illustre la figure 2.1. Dans le cas d’un syst`eme compos´e de n entit´es, une recherche n´ecessite de contacter en moyenne O n 1/d entit´es afin de trouver la donn´ee ou la zone recherch´ee. 1 2 3 4 5 6 7 8 Figure 2.1 – Illustration de CAN pour d = 2 Chord [SMK+01] De mani`ere similaire, Chord organise ses entit´es au moyen de leur identifiant `a m bits. Ces identifiants sont issus de la fonction de hachage SHA-1 (m = 160). Les entit´es sont ordonn´ees sur un anneau unidimensionnel. Chaque entit´e g`ere alors la portion de l’anneau entre sa position sur celui-ci et l’entit´e suivante dans l’anneau. A la diff´erence de CAN qui relie les entit´es voisines dans l’espace virtuel, ` Chord connecte des entit´es `a des distances variables. Ainsi, si une entit´e a pour identit´e p, alors elle sera reli´ee `a chaque entit´e g´erant les positions p + 2i , 0 < i < 160 dans l’anneau. Ces entit´es forment le voisinage de l’entit´e p. La figure 2.2 illustre un anneau Chord pour m = 4. On a n = 16 entit´es dans le syst`eme. L’entit´e 0 est li´ee aux entit´es 1, 2, 4 et 8. Ces liens sont repr´esent´es par les fl`eches pleines. Lors d’une recherche de l’entit´e 11, l’entit´e 0 recherche dans son voisinage, l’entit´e qui pr´ec`ede 11 dans le sens horaire de l’anneau : l’entit´e 8. Celle-ci r´eit`ere la recherche, contacte l’entit´e 10 qui contacte `a son tour l’entit´e 11. Le parcours de cette recherche est repr´esent´e par les fl`eches pointill´ees. Dans un syst`eme comportantSyst`emes large ´echelle 25 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Figure 2.2 – Illustration de l’anneau Chord pour m = 4 n entit´es, l’utilisation de liens longs permet de d´efinir une notion de voisinage diff´erente du voisinage physique sur l’anneau. De cette mani`ere, une recherche peut traverser la moiti´e de l’anneau en un saut et permet ainsi une recherche efficace d’une donn´ee en contactant O(log n) entit´es en moyenne. 2.1.2 G´erer le dynamisme de la population Les DHT sont parfaitement adapt´ees pour g´erer de large populations d’entit´es. De plus elles sont auto-organisantes : l’espace des identifiants est partitionn´e dynamiquement entre les entit´es pr´esentes dans le syst`eme. D’autre part, ces protocoles offrent des complexit´es de communication logarithmiques. Cependant, en pr´esence de churn (fr´equence des entr´ees / sorties) important, la topologie devient tr`es dynamique et de nombreuses mises `a jours sont n´ecessaires. Des mise `a jours trop fr´equentes peuvent amener un probl`eme de coh´erence au niveau des entit´es. Dans le pire des cas, la topologie peut ˆetre scind´ee en plusieurs composantes connexes cr´eant ainsi diff´erentes DHT s´epar´ees. Cette partie pr´esente succinctement deux DHT r´esilientes aux dynamisme des entit´es dans le syst`eme : d’une part Kademlia [MM02], con¸cu en 2002 par Maymounkov et Mazi`eres, et d’autre part eQuus [LSW06], propos´e par Locher, Schmid et Wattenhofer en 2006. Kademlia [MM02] Dans Kademlia, la s´emantique du lien unissant deux entit´es est plus lˆache que dans les DHT telles que CAN ou Chord. Une entit´e dont l’identifiant `a m bits vaut b0b1 . . . bm−1 est li´ee `a m ensembles de k entit´es appel´es k-buckets. Le premier bucket contient k entit´es dont l’identifiant d´ebute par b0, le second par b0b1, le i-eme par b0b1 . . . bi−1. Une entit´e de Kademlia met `a jour son i-`eme k-bucket d`es qu’elle transf`ere un26 Travaux connexes message provenant d’une entit´e dont l’identifiant d´ebute par b0b1 . . . bi−1. Ainsi, chaque k-bucket contient les k derni`eres entit´es du syst`eme vues par l’entit´e courante. De cette mani`ere, chaque entit´e profite des messages qu’elle fait suivre pour garder une vue `a jour des entit´es effectivement pr´esentes dans le syst`eme. L’entit´e r´eduit ainsi le nombre de messages de mise-`a-jour pour maintenir la coh´erence de la topologie. De la mˆeme mani`ere que Chord, Kademlia emploie des liens de plus en plus ´eloign´es de l’entit´e courante. Une recherche dans cette architecture n´ecessite de contacter O(log n) entit´es, dans un syst`eme comportant n entit´es. eQuus [LSW06] eQuus emploie une m´ethode diff´erente pour g´erer le dynamisme des entit´es. Contrairement aux architectures pr´ec´edentes dans lesquelles chaque entit´e g`ere une partie de l’espace des identifiants, eQuus attribue cette gestion `a un ensemble d’entit´es appel´e clique. Une clique est un ensemble d’entit´es dont la taille est comprise entre deux param`etres du syst`eme L et U. De plus, chaque clique est identifi´ee de mani`ere unique par un identifiant i de d  m bits, tel que toutes les entit´es de la clique aient leur identifiant pr´efix´e par i. Lorsqu’une clique devient sur-peupl´ee, deux nouvelles cliques sont cr´e´ees en repartissant les entit´es entre elles. A l’inverse, lorsqu’une clique devient ` sous-peupl´ee, elle est fusionn´ee avec une clique existante. La recherche d’une donn´ee dans eQuus consiste alors `a trouver la clique contenant l’entit´e ou la donn´ee recherch´ee. L’utilisation des cliques permet de r´eduire le diam`etre moyen du graphe de communication engendr´e par le protocole, ainsi que le nombre de liens liant les cliques entre elles. Dans un syst`eme comportant n entit´es, l’utilisation des cliques identifi´ees par d bits permet ainsi une recherche efficace d’une donn´ee en contactant O(log2 d n) entit´es en moyenne. Le protocole eQuus absorbe le dynamisme des entit´es en distinguant deux types de mises-`a-jour des informations maintenues par celles-ci. La modification de la composition d’une clique est trait´ee imm´ediatement, toutes les entit´es de la clique mettent `a jour la composition de celle-ci. A l’inverse, les ` entit´es des cliques voisines re¸coivent plus rarement les mises-`a-jour. Une recherche dans eQuus consiste `a contacter toutes les entit´es pr´esentes dans une clique. Les fr´equences de mise-`a-jour intra et inter-cliques peuvent alors amener une diff´erence de compositions. Cette fr´equence des mise-`a-jour inter-clique est param´etr´ee de mani`ere `a ce que ces compositions soient d’intersection non vide tout en ´evitant les mises-`a-jours syst´ematiques. 2.1.3 G´erer les comportement fautifs Les protocoles que nous venons de pr´esenter sont capables de g´erer de grandes populations d’entit´es et tol`erent de mani`ere variable le dynamisme des entit´es au sein du syst`eme. N´eanmoins, ces protocoles ne fonctionnent qu’en l’absence de fautes byzantines. Une entit´e sujette `a une faute byzantine ou entit´e byzantine ne suit pas n´ecessairement le protocole. Elle se comporte de mani`ere arbitraire. Ce comportement peut mettre en p´eril la connectivit´e de l’architecture ou amener `a des recherches inabouties. Cette partie pr´esente succinctement deux DHT r´esilientes aux comporte-Syst`emes large ´echelle 27 ments byzantins : S-chord [FSY05], propos´e par Fiat, Saia et Young en 2005, et PeerCube [ABLR08], con¸cu par Anceaume, Brasileiro, Ludinard et Ravoaja en 2008. S-Chord [FSY05] Une am´elioration de Chord visant `a rendre celui-ci tol´erant aux fautes byzantines est d´ecrite dans [FSY05]. Pour chaque entit´e p de l’anneau est d´efini l’ensemble S(p) contenant les entit´es q du syst`eme dont la distance de q `a p n’exc`ede pas C(ln(n))/n, o`u n d´esigne le nombre d’entit´es dans le syst`eme et C est un param`etre du syst`eme. L’id´ee de S-Chord est de remplacer toutes les communications entre deux entit´es p et q par des communications entre les ensembles S(p) et S(q). La figure 2.3 illustre un anneau S-Chord pour m = 4 et C(ln n)/n = 2. On a n = 16 entit´es dans le syst`eme. Comme dans Chord, l’entit´e 0 est li´ee aux entit´es 1, 2, 4 et 8. Lors d’une recherche de l’entit´e 11, l’entit´e 0 contacte l’ensemble S(0) afin de contacter l’ensemble S(q) de l’entit´e li´ee la plus proche de 11 tout en la pr´ec´edent. L’ensemble S(0) contacte alors l’ensemble S(8). Cet ensemble r´eit`ere la recherche contacte l’ensemble S(10) qui contacte `a son tour l’entit´e S(11). Le parcours de cette recherche est repr´esent´e par les fl`eches pointill´ees. La figure 2.4 illustre toutes les communications engendr´ees par cette recherche. Cette approche pour tol´erer les comportements byzantins est sensiblement plus coˆuteuse en communications que le protocole Chord classique. En pr´esence de fautes byzantines ind´ependantes, c’est-`a-dire qui ne r´esultent pas d’entit´es malveillantes agissant en collusion, S-Chord assure ainsi qu’une recherche dans l’overlay compos´e de n entit´es n´ecessite en moyenne O log2 n  messages. Cependant, ce type d’approche engendre O log3 n  messages lors des entr´ees et sorties des entit´es du syst`eme.Cela signifie donc que ce type d’approche n’est pas adapt´e dans un contexte tr`es dynamique. PeerCube [ABLR08] De mani`ere similaire, PeerCube remplace la communication entre deux entit´es du syst`eme par une communication entre groupes d’entit´es. La topologie engendr´ee par ce protocole s’approche d’un hypercube parfait dans lequel les sommets sont constitu´es d’un groupe d’entit´es appel´es cluster. Chaque cluster est en charge d’une partie de l’espace des identifiants. Contrairement `a S-Chord dans lequel pour chaque entit´e p du syst`eme il existe un ensemble S(p) lui correspondant, PeerCube partitionne l’espace des identifiants entre les clusters. Ainsi plusieurs entit´es correspondent au mˆeme cluster. La communication au sein de l’architecture est assur´ee par les clusters. Afin de tol´erer le churn naturel pr´esent dans les syst`emes peer-to-peer, les clusters sont d´ecompos´es en deux sous-ensembles core et spare. Le premier forme une clique de taille constante γ et assure la connectivit´e du graphe tandis que le second agit comme un tampon et absorbe les entit´es entrantes dans le cluster de mani`ere transparente vis-`a-vis du reste du syst`eme. D’autre part, la faible taille γ permet de mettre en œuvre des algorithmes [CFNV04, KAD+07] de consensus tol´erants au byzantins afin de g´erer les mises `a jours de la composition du cluster. Les op´erations basiques de cette architecture n´ecessitent en moyenne O(log n) messages, avec n le nombre d’entit´es pr´esentes au sein du syst`eme. Enfin, bien que cette approche soit r´esiliente `a la pr´esence d’entit´es byzantines, celles ci peuvent prendre le contrˆole d’un cluster et mettre en p´eril l’ex´ecution de recherches dans le syst`eme. PeerCube emploie alors une technique de recherche redondante sur des chemins ind´ependants assurant ainsi un haut taux de succ`es28 Travaux connexes 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 S(0) S(8) S(10) S(11) Figure 2.3 – Illustration de l’anneau S-Chord pour m = 4 et C(ln n)/n = 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 S(0) S(8) S(10) S(11) Figure 2.4 – Illustration de l’anneau S-Chord pour m = 4 et C(ln n)/n = 2Organisation des donn´ees 29 000 100 001 101 010 110 011 111 1 2 3 4 5 6 7 8 9 10 11 12 Core du cluster de taille γ. Spare du cluster. Figure 2.5 – Illustration de l’architecture PeerCube. A gauche, l’organisation en hy- ` percube des clusters, `a droite la composition d’un cluster particulier. des recherches malgr´e la pr´esence de ces entit´es malveillantes. Une ´etude approfondie de cette architecture est fournie dans les chapitre 6 et 7 du pr´esent document. Nous avons pr´esent´e dans cette section un aper¸cu des travaux existants permettant de g´erer de grandes population d’entit´es au sein d’un syst`eme, ainsi que leur dynamisme et la pr´esence de fautes impactant ces entit´es. La section suivante traite des donn´ees g´en´er´ees par ces entit´es et porte plus particuli`erement sur les techniques visant `a regrouper les donn´ees similaires. 2.2 Organisation des donn´ees Les entit´es d’un syst`eme g´en`erent de mani`ere continue diverses donn´ees. Il peut s’agir de donn´ees applicatives ou de donn´ees relatives `a l’´etat interne des entit´es. En particulier, nous supposons dans le cadre de ce document que les entit´es effectuent r´eguli`erement des mesures de qualit´es des services consomm´es. De plus, nous supposons que l’activation d’une faute dans le syst`eme se traduit par une variation de ces mesures de qualit´e. Nous nous int´eressons dans le cadre de ce document `a distinguer les fautes pr´esentes dans le syst`eme suivant le nombre d’entit´es percevant les d´efaillances qui en r´esultent. Plus pr´ecis´ement, nous nous int´eressons aux fautes ayant un impact sur la qualit´e des services consomm´es par les entit´es supervis´ees. Nous faisons ici l’hypoth`ese suivante : l’activation d’une faute dans le syst`eme a un impact similaire sur la qualit´e du service per¸cue par les entit´es supervis´ees. Afin de distinguer une faute menant `a une d´efaillance30 Travaux connexes per¸cue par un grand nombre d’utilisateurs de celle per¸cue par un petit nombre d’entre eux, il est n´ecessaire de regrouper ensemble les variations similaires de qualit´es. On peut d´etecter les perceptions similaires en partitionnant les entit´es supervis´ees en fonction des qualit´es mesur´ees par celles-ci. Nous pr´esentons dans cette section divers travaux existants permettant de regrouper des donn´ees similaires. On distingue deux approches principales. Les approches bas´ees sur le partionnement des donn´ees statiques sont pr´esent´ees dans la sous-section 2.2.1. Les approches travaillant sur des donn´ees dynamiques sont pr´esent´ees dans la soussection 2.2.2. 2.2.1 Partitionnement de donn´ees statiques La clustering est la tˆache qui consiste `a diviser un ensemble de donn´ees D en sous-ensembles appel´es clusters de sorte que chaque donn´ee d’un sous-ensemble soit regroup´ee avec les donn´ees qui lui ressemblent le plus. La similarit´e est le crit`ere central pour l’identification de clusters dans l’ensemble de donn´ees D. On distingue diff´erentes notions de similarit´e qui engendrent plusieurs familles de m´ethodes de partitionnement. S’il existe une distance δ entre les donn´ees de D, celle-ci peut ˆetre utilis´ee pour partitionner l’ensemble D. Partitionnement hi´erarchique Les m´ethodes `a partitionnement hi´erarchique cherchent `a r´epartir les donn´ees d’un ensemble D parmi κ clusters, κ ´etant un param`etre d’entr´ee de l’algorithme. Initialement, ce type d’algorithme attribue `a chaque donn´ee x l’ensemble {x}. Ensuite, `a chaque ´etape, l’algorithme fusionne les ensembles les plus proches au sens d’une distance ∆ sur ces ensembles, et s’arrˆete lorsqu’il ne reste que κ ensembles. La diff´erence principale entre les diff´erents algorithmes `a partitionnement hi´erarchique se situe dans la mesure de distance entre ensemble de donn´ees. Par exemple, l’algorithme SLINK [Sib73] fusionne deux ensembles X, Y lorsque la distance ∆ inter-ensemble ∆(X, Y ) = minx∈X,y∈Y δ(x, y) est minimale. A l’inverse, l’algorithme ` CLINK [Def77] cherche `a minimiser le diam`etre de la r´eunion des ensembles X, Y en minimisant ∆(X, Y ) = maxx∈X,y∈Y δ(x, y). La complexit´e de ces algorithmes est O |D| 2  , ces algorithmes sont donc trop coˆuteux pour ˆetre utilis´es dans le contexte des syst`emes large ´echelle. Partitionnement orient´e distance Les m´ethodes `a partitionnement hi´erarchique n´ecessitent de travailler sur l’ensemble des donn´ees D induisant ainsi une complexit´e de calcul importante. Afin de r´eduire cette complexit´e, des algorithmes [HW79, DLR77] travaillant sur un sous-ensemble des donn´ees ont ´et´e propos´es. De la mˆeme mani`ere que les m´ethodes `a partitionnement hi´erarchique, le but de l’algorithme des κ-moyennes [HW79] est de partitionner les donn´ees de l’ensemble D en κ sous-ensembles. Cet algorithme est identique `a l’algorithme de quantification de Lloyd [DLR77]. Les donn´ees de D sont plac´ees dans un espace m´etrique E. L’algorithme est initialis´e avec un ensemble Σ = {σ1, . . . , σκ}.Organisation des donn´ees 31 Deux m´ethodes principales, d´ecrites dans [HE02], existent pour l’initialisation de l’algorithme des κ-moyennes. La m´ethode al´eatoire consiste `a choisir uniform´ement κ donn´ees de D afin de construire l’ensemble initial Σ. A l’inverse, la m´ethode Forgy ` consiste `a choisir uniform´ement κ points de l’espace E. L’algorithme associe ensuite `a chaque donnn´ee x ∈ D, l’´el´ement de Σ le plus proche au sens de la distance δ. Les ensembles Σi sont d´efinis par : ∀i ∈ {1, . . . , κ}, Σi = {x ∈ D | δ(x, σi) ≤ δ(x, σj )∀j ∈ {1, . . . , κ}}. Ces ensembles forment une partition de D. Les ´el´ements de Σ sont replac´es `a la position de l’isobarycentre des entit´es de Σi . On a : ∀1 ≤ i ≤ κ, σi = 1 |Σi | X j∈Σi j. Ce processus est r´ep´et´e jusqu’`a ce que les ´el´ements de Σ soient stables. Trouver un partitionnement d’un ensemble de donn´ees D en κ clusters se fait en appliquant l’algorithme des κ-moyennes. En revanche, trouver la partition qui minimise la distance au sein des parties est un probl`eme NP-difficile. Un probl`eme NP-difficile est un probl`eme de d´ecision pour lequel on ne sait pas v´erifier une solution en temps polynomial. Par cons´equent, on utilise des heuristiques pour le crit`ere d’arrˆet de l’algorithme. Une solution courante consiste `a fournir un nombre I d’it´erations et de consid´erer les parties Σi comme une partition valable. Dans un espace de dimension d, la complexit´e de cet algorithme est O(Idκ|D|)), avec I le nombre d’it´erations, κ le nombre sous-ensembles de la partition et D l’ensemble des donn´ees initial. Bien que cet algorithme ait une complexit´e lin´eaire en nombre de donn´ees trait´ees, celui-ci est facilement parall´elisable. D’autre part, l’algorithme heuristique construit it´erativement une partition minimisant la distance au sein des clusters. Cet algorithme converge donc vers un minimum local. Afin de pallier le biais introduit pas le choix initial de l’ensemble Σ, cet algorithme est ex´ecut´e `a diverses reprises afin d’´eviter un minimum local et ne conserver que la meilleure partition finale. L’algorithme des κ-moyennes est d´etaill´e dans le chapitre 5. Diff´erentes variantes de cet algorithme ont ´et´e propos´ees. A la diff´erence de l’algo- ` rithme des κ-moyennes qui calcule les ensembles Σi , 1 ≤ i ≤ κ centr´es sur l’isobarycentre de cet ensemble, l’algorithme κ-medoids [KR87] centre ces ensembles sur une donn´ee x ∈ D. De plus, cet algorithme utilise la norme 1 comme distance, le rendant plus robuste `a la pr´esence de donn´ees anormales. L’algorithme des c-moyennes [BEF84] quant `a lui n’effectue pas un partitionnement de l’ensemble des donn´ees D. A l’inverse, cet algorithme attribue `a chaque donn´ee ` x ∈ D, un degr´e d’appartenance `a chaque ensemble Σi , 1 ≤ κ. L’inconv´enient majeur de ces approches est le param´etrage de κ. En effet, il n’est pas possible de connaˆıtre a priori la valeur id´eale de ce param`etre. Des m´ethodes [PM00] visent `a estimer la valeur id´eale de ce param`etre pour l’ensemble de donn´ees D consid´er´e, n´ecessitant ainsi un pr´etraitement de l’ensemble des donn´ees.32 Travaux connexes Partitionnement orient´e densit´e Afin de s’affranchir des contraintes d’initialisation et du nombre κ de clusters recherch´es, d’autres approches ont ´et´e envisag´ees. L’algorithme DBSCAN [EKSX96] divise l’ensemble de donn´ees D en sous-ensembles de forte densit´e s´epar´es par des espaces de faible densit´e. L’algorithme DBSCAN est d´etaill´e dans le chapitre 4. Cet algorithme requiert deux param`etres, ε et m, et une distance δ. Le param`etre ε permet de d´efinir le voisinage d’une entit´e tandis que le param`etre m d´efinit un seuil de densit´e sur ce voisinage. Deux donn´ees x, y ∈ D sont voisines si δ(x, y) ≤ ε. Le voisinage Nε(x) d’une donn´ee x ∈ D est dense s’il contient plus de m donn´ees, la donn´ee x est alors dite centrale. L’algorithme DBSCAN parcourt l’ensemble des donn´ees D. Pour chaque donn´ee centrale non visit´ee, l’algorithme cr´ee un nouveau sous-ensemble et lui ajoute cette donn´ee ainsi que son voisinage. Si ce voisinage contient des donn´ees centrales, le voisinage de celles-ci est ajout´e au sousensemble courant. Les donn´ees sont ainsi trait´ees de proche en proche et le calcul du sous-ensemble courant s’arrˆete lorsque toutes les donn´ees centrales et leur voisinage ainsi atteignables ont ´et´e trait´ees. Cet algorithme n´ecessite de traiter toutes les donn´ees et pour chacune d’elle de construire son voisinage. Par cons´equent, la complexit´e de cet algorithme est O |D| 2  . L’utilisation de structure d’indexation de donn´ees spatiales du type R*-tree [BKSS90] permet de r´eduire cette complexit´e `a O(|D| log |D|). A la diff´erence de l’algorithme des ` κ-moyennes qui n´ecessite de sp´ecifier le nombre de sous-ensembles recherch´es, DBSCAN construit lui-mˆeme le nombre de sous-ensembles n´ecessaires. De plus, il n’y a pas de probl`eme d’initialisation, toute ex´ecution de l’algorithme m`ene globalement aux mˆemes sous-ensembles : une seule ex´ecution de l’algorithme est suffisante pour les construire. Cependant, il arrive que deux ex´ecutions attribuent une mˆeme donn´ee `a des sous-ensembles diff´erents. Cela arrive lorsqu’une donn´ee n’est pas centrale mais qu’elle appartient `a l’intersection des voisinages de deux donn´ees centrales appartenant `a des sous-ensembles diff´erents. Suivant l’ordre de traitement des donn´ees, celle-ci est class´ee dans l’un ou l’autre des sous-ensembles. L’algorithme DBSCAN d´efinit une notion de densit´e fonction de deux param`etres ε et m et construit des clusters `a partir de celle-ci. Si l’ensemble des donn´ees D est constitu´e de divers sous-ensembles de densit´es diff´erentes, DBSCAN ´echoue `a les retrouver. D’autres approches, par exemple OPTICS [ABKS99], ont ´et´e propos´ees afin de pallier cette limite. OPTICS suit la mˆeme id´ee que DBSCAN en distinguant les donn´ees centrales. Cependant, en introduisant une seconde distance ε 0 d´efinie comme la plus petite distance entre une donn´ee x ∈ D et une donn´ee y ∈ Nε(x), OPTICS peut g´erer des sous-ensembles de densit´es diff´erentes ε 0/m. D’autre part, GDBSCAN [SEKX98] est une g´en´eralisation de DBSCAN. Dans GDBSCAN, les deux param`etres ε et m sont remplac´es par des fonctions plus g´en´erales d´efinissant la notion de voisinage ainsi que la notion de densit´e. Cette g´en´eralisation permet alors de partitionner des donn´ees pour lesquelles il n’y a pas de notion de distance. 2.2.2 Donn´ees dynamiques Initialement, les techniques de clustering ont ´et´e utilis´ees sur des donn´ees statiques. Elles ont ´et´e ensuite ´etendues sur des donn´ees ayant une ´evolution temporelle. PlutˆotSupervision 33 que de consid´erer les donn´ees `a chaque instant et d’y appliquer les techniques de clustering que nous venons de voir, les approches [JYZ+08, JLO07] ´etudient l’´evolution, l’apparition et la disparition des clusters au cours du temps en fonction de l’´evolution temporelle des donn´ees. Cependant, comme nous l’avons vu, le clustering cherche `a regrouper des donn´ees similaires. La notion de similarit´e est centrale dans ce regroupement. Aucun des travaux que nous avons pr´esent´e ne borne l’´ecart de similarit´e entre deux donn´ees d’un mˆeme sous-ensemble. Par exemple, dans le cas de l’algorithme κ-moyennes, une donn´ee x ∈ D est associ´ee au plus proche ´el´ement σi , 1 ≤ i ≤ κ. C’est donc la position des σi qui d´etermine la distance maximale entre deux ´el´ements d’un mˆeme cluster Σi . Ainsi, la distance entre deux donn´ees x, y ∈ Σi peut ˆetre arbitrairement grande. De la mˆeme mani`ere dans le cas des algorithmes bas´es sur la densit´e des donn´ees, deux donn´ees appartiennent `a un mˆeme cluster s’il existe suffisamment de donn´ees centrales entre elles de sorte que ces donn´ees soient connect´ees de proche en proche par un chemin dense. Cette fois encore, deux donn´ees peuvent donc appartenir `a un mˆeme cluster tout en ayant une similarit´e tr`es faible. L’utilisation de la notion de groupe est une autre approche visant `a regrouper des donn´ees dynamiques. Un groupe est d´efini comme un ensemble contenant plus de τ donn´ees dont la distance maximale entre deux donn´ees n’exc`ede pas un param`etre fix´e r dans un intervalle de temps donn´e. Ces travaux portant sur la recherche de groupe tels que [BGHW06, BGHW08, BBG08, VBT09], s’int´eressent `a exhiber les donn´ees formant un groupe le plus longtemps possible sans contrainte de partitionnement des donn´ees. La recherche de mouvements de groupes d´ecrite se diff´erencie du clustering par trois aspects. 1. Ce type d’approche s’int´eresse `a exhiber l’ensemble des groupes auquel une donn´ee appartient, sans cependant imposer le partitionnement (appartenance `a un unique cluster) pr´esent dans le clustering. 2. A l’inverse du clustering, o`u l’on cherche `a construire des clusters, la recherche ` de mouvements de groupes est centr´ee sur les donn´ees et leur potentielle appartenance `a diff´erents ensembles. 3. Des donn´ees ayant une similarit´e trop faible ne peuvent ˆetre regroup´ees ensemble. On observe alors `a des instants discrets l’ensemble des donn´ees D et celles-ci sont regroup´ees en sous-ensembles dont la distance maximale entre deux ´el´ements n’exc`ede pas un seuil pr´ed´efini r `a chaque instant discret. Nous avons pr´esent´e dans cette section les diff´erents travaux existants permettant de regrouper ensemble des donn´ees similaires d’un ensemble de donn´ees. La section suivante pr´esente l’utilisation de ces techniques dans le contexte de la supervision d’entit´es et la caract´erisation de fautes. 2.3 Supervision Nous avons pr´esent´e dans les sections pr´ec´edentes diff´erents travaux existants permettant de g´erer un grand ensemble d’entit´es ainsi que les donn´ees qu’elles sont sus-34 Travaux connexes ceptibles de g´en´erer. Nous pr´esentons `a pr´esent l’utilisation de ces techniques dans le contexte de la supervision d’entit´es et la caract´erisation de fautes. 2.3.1 Etat global du syst`eme ´ Les entit´es supervis´ees g´en`erent de mani`ere continue un ensemble de donn´ees qui sont ensuite mises en forme au sein d’une interface de supervision au niveau d’une entit´e appel´ee superviseur. Ces donn´ees sont variables et peuvent par exemple repr´esenter l’´etat interne de l’entit´e, une qualit´e de service, etc... Les syst`emes de supervision sont des ´el´ements cl´es pour la caract´erisation des fautes dans le syst`eme. Le but de ces syst`emes est de rendre compte de mani`ere continue de l’´etat du syst`eme consid´er´e. Il est donc n´ecessaire pour ces syst`emes d’ˆetre capable d’appr´ehender le syst`eme supervis´e dans son ensemble, de mani`ere r´eactive et avec un faible surcoˆut afin de ne pas perturber le bon fonctionnement du syst`eme supervis´e. On distingue alors deux types d’approches dans la supervision : celles fournissant une vue agr´eg´ee du syst`eme et celles cherchant `a avoir une vision de l’´etat de chacun des ´el´ements du syst`eme supervis´e. Astrolabe [VRBV03] et SDIMS [YD04] organisent de mani`ere distribu´ee les entit´es du syst`eme supervis´e. Les entit´es sont organis´ees de mani`ere hi´erarchique en fonction des donn´ees g´en´er´ees qu’elles g´en`erent. Cette hi´erarchie permet alors de collecter et d’agr´eger les informations relatives aux entit´es du syst`eme. De cette mani`ere, ces syst`emes fournissent une vue r´esum´ee de la sant´e de l’ensemble du syst`eme. Les travaux d´ecrits dans ce document portent sur la supervision d’un ensemble d’entit´es et la caract´erisation de fautes, ces approches ne sont donc pas adapt´ees dans notre contexte. A l’inverse, Ganglia [MCC03], CoMon [PP06] et InfoTrack [ZTG ` +09] supervisent chacune des entit´es du syst`eme. Ces approches exploitent les similarit´es entre les donn´ees g´en´er´ees par les entit´es supervis´ees afin de r´eduire la communication entre les entit´es et l’interface de supervision. Par exemple, InfoTrack repose sur deux principes : autocorr´elation et clustering. Les entit´es supervis´ees sont regroup´ees en κ clusters (issus de l’ex´ecution de l’algorithme κ-moyennes) par rapport `a une mesure de similarit´e sur les donn´ees g´en´er´ees. Au sein de chaque cluster, l’entit´e dont les donn´ees g´en´er´ees sont les plus proches de la valeur m´ediane des donn´ees g´en´er´ees par l’ensemble des entit´es du cluster prend en charge la communication avec l’ext´erieur du cluster. Cette entit´e est appel´ee leader du cluster. Afin de diminuer la communication entre les entit´es, celles-ci sont munies d’outils de pr´ediction [Kal60]. Les leaders sont munis du mˆeme outil de pr´ediction. Ainsi, `a chaque instant le leader a acc`es aux mˆeme pr´edictions que chacune des entit´es du cluster. Par cons´equent, lorsque la donn´ee effective est proche de la donn´ee pr´edite, aucune communication entre l’entit´e et le leader n’est n´ecessaire. Dans le cas contraire, l’entit´e communique la donn´ee effective au leader. Le mˆeme m´ecanisme est mis en place entre les leaders de chaque cluster et le superviseur. Le leader maintient de plus un compteur pour chaque entit´e du cluster. Ce compteur est incr´ement´e lorsque le leader effectue une pr´ediction en accord avec la donn´ee g´en´er´ee par l’entit´e, et d´ecr´ement´e dans le cas contraire. Lorsque le compteur d’uneSupervision 35 entit´e est inf´erieur `a un seuil pr´ed´efini θ1, les donn´ees qu’elle g´en`ere ne sont plus en ad´equation avec les donn´ees g´en´er´ees par les autres entit´es du cluster. Cette entit´e est alors replac´ee dans un autre cluster plus appropri´e. A l’inverse, si un nombre ` θ2 d’entit´es du cluster doivent ˆetre replac´ees, cela signifie que le leader n’est plus repr´esentatif des entit´es du cluster. Un nouveau leader est alors choisi. Ces op´erations de maintenance sont effectu´ees de mani`ere centralis´ee par le superviseur. Les r´esultats exp´erimentaux montrent ainsi une diminution des coˆuts de communication de 50 `a 90% tout en conservant une haute `a pr´ecision (de 1 `a 5% d’erreur). Cependant, ce type d’approche n’est applicables qu’aux mesures locales (comme la charge CPU, consommation m´emoire, temps de fonctionnement sans red´emarrage, etc...). Ce type de mesure est continu et ne d´epend pas de l’activit´e utilisateur. De plus, la stabilit´e et pr´edictibilit´e de ce type de mesure permet de r´eduire efficacement les communications n´ecessaires `a la supervision. L’initialisation de ce type de solution repose sur l’ex´ecution d’algorithme de clustering par le superviseur. Cette ex´ecution initial est effectu´ee hors-ligne. Le partitionnement ainsi calcul´e est mis-`a-jour lorsqu’une entit´e doit ˆetre replac´ee. D’autre part, les variations dans ces mesures peuvent ˆetre symptomatiques d’une faute au niveau d’une entit´e supervis´ee. Ce type d’approche permet donc de d´etecter des d´efaillances par le replacement d’une entit´e mais ne permet pas de caract´eriser le type de faute sous-jacent. Les d´efaillances qui impactent un grand nombre d’entit´es sont donc tr`es coˆuteuses d’un point de vue algorithmique. L’absence de caract´erisation ne fournit donc pas d’indice sur les causes qui ont provoqu´e la d´efaillance. 2.3.2 Caract´erisation de fautes Lorsqu’une faute est activ´ee dans le syst`eme, celle-ci peut induire une d´efaillance. Cette d´efaillance se traduit par une d´egradation de la qualit´e du service rendu par le syst`eme. Les outils de supervision que l’on vient de pr´esenter sont destin´es `a fournir une vision globale de la sant´e du syst`eme. En revanche, ces outils ne permettent pas de localiser la faute qui a impact´e le syst`eme. La localisation de fautes [MA04] consiste `a d´eduire la cause effective d’une d´efaillance `a partir d’un ensemble d’observations. On distingue trois types d’approches pour la localisation de fautes. Le recours `a des syst`emes experts qui consiste `a mettre en place des r`egles ou des arbres de d´ecisions ; les mod`eles de propagation de fautes qui s’appuient sur des graphes de d´ependances, et enfin la connaissance du graphe de communication entre les entit´es. La connaissance suppl´ementaire requise dans le cadre de la localisation de fautes n’est pas envisageable dans le cadre de la supervision de syst`emes large ´echelle. Dans le cadre de cette th`ese, nous souhaitons caract´eriser les fautes qui induisent une d´efaillance dans le syst`eme suivant le nombre d’entit´es qui per¸coivent cette d´efaillance. Cette caract´erisation permettra ensuite de r´eduire la connaissance additionnelle n´ecessaire `a la localisation de fautes. Tiresias [HCDW12], Argus [YFG+12] et CEM [CBG10] sont trois approches li´ees `a la caract´erisation de fautes dans les r´eseaux large ´echelle. Ces trois approches reposent sur la perception de d´efaillances par les utilisateurs du syst`eme.36 Travaux connexes Tiresias Cette approche [HCDW12] classifie des donn´ees op´erationnelles d’apr`es six ´etapes. Ces donn´ees sont issues des appels des clients au service de support d’un FAI ainsi que de l’analyse des donn´ees de journalisation des pannes sur les ´equipements clients. Ces donn´ees sont horodat´ees et associ´ees `a un niveau hi´erarchique du r´eseau. Ces donn´ees proviennent de divers endroits dans le r´eseau, arrivent en masse et de mani`ere continue au niveau du serveur Tiresias. Le serveur maintient une fenˆetre temporelle divis´ee en diff´erents intervalles de temps. Une donn´ee est affect´ee `a l’intervalle de temps au cours duquel elle a ´et´e produite. Chaque donn´ee est ensuite plac´ee dans un arbre en fonction du niveau hi´erarchique qui lui est associ´e et un poids lui est attribu´e. Un traitement math´ematique est effectu´e sur les donn´ees dont le poids associ´e est situ´e au dessus d’un seuil pr´ed´efini θ. Ce traitement permet d’exhiber les donn´ees anormales traduisant l’activation d’une faute impactant un grand nombre d’utilisateurs. Cette approche souffre de trois limitations. Tout d’abord, Tiresias s’appuie sur les appels des utilisateurs et d´eporte donc la tˆache de d´etection de faute au niveau de l’utilisateur. Il n’y a donc pas de garantie sur le d´elai entre la d´etection de la faute par l’utilisateur et la notification au centre de support. D’autre part, chaque donn´ee est trait´ee manuellement par un technicien qui choisit le niveau hi´erarchique `a associer `a la donn´ee op´erationnelle. Ce traitement humain est donc source d’erreurs et est incompatible avec un traitement des donn´ees `a la vol´ee. Enfin, cette approche s’appuie sur la connaissance du r´eseau d’interconnexion et se limite de plus aux r´eseaux `a structure hi´erarchique (comme les r´eseaux IPTV). Argus De mani`ere similaire `a Tiresias, Argus [YFG+12] a une approche centralis´ee. Cette approche s’appuie sur le d´eploiement par les fournisseurs d’acc`es `a Internet de leurs propre r´eseaux de services CDN, VoIP, IPTV afin de mutualiser la tˆache de supervision. Ainsi, Argus tire parti des informations relatives `a la topologie r´eseau, au routage, `a la g´eographie, et aux mesures de performance de bout en bout. Comme la totalit´e de l’environnement est maˆıtris´e, Argus peut superviser les mesures de performance du point de vue serveur et non du point de vue du client. Ainsi, les utilisateurs sont clusteris´es de mani`ere hi´erarchique par rapport `a leur localisation dans la topologie r´eseau. Argus g´en`ere ensuite pour chaque groupe d’utilisateurs, une s´erie temporelle correspondant aux mesures de performances agr´eg´ees sur le groupe d’utilisateur concern´e. Ces s´eries temporelles sont ensuite utilis´ees pour d´etecter des fautes qui impactent tout ou partie du groupe d’utilisateur concern´e. L’approche centralis´ee d’Argus n´ecessite de traiter l’ensemble des donn´ees g´en´er´ees par l’ensemble des utilisateurs consommant les services propos´es au sein du r´eseau du FAI. Par cons´equent, il se pose un probl`eme clair vis-`a-vis du passage `a l’´echelle de cette solution. De plus, Argus adopte un point de vue totalement omniscient vis-`a-vis de la caract´erisation des fautes qui impactent le syst`eme : la topologie, le positionnement des diff´erents serveurs et des clients sont connus et utilis´es pour caract´eriser les fautes. CEM De la mˆeme mani`ere, CEM [CBG10, Cho10] cherche `a distinguer les fautes impactant un petit nombre d’entit´es supervis´ees des fautes dont la d´efaillance est per¸cueSupervision 37 par un grand nombre d’entit´es. Dans le cas d’une d´egradation anormale de la qualit´e d’un service consomm´e par une entit´e, celle-ci incr´emente un compteur situ´e une table de hachage distribu´ee [MM02]. La cl´e utilis´ee pour l’´ecriture dans la table de hachage distribu´ee correspond `a l’identifiant du syst`eme autonome auquel l’entit´e supervis´ee appartient. Un Syst`eme Autonome est un r´eseau au sein d’Internet dont la politique de routage est coh´erente. Les syst`emes autonomes sont interconnect´es et forment ainsi Internet. Le r´eseau d’un fournisseur d’acc`es `a Internet est g´en´eralement un Syst`eme Autonome. Chaque syst`eme autonome est identifi´e de mani`ere unique par une valeur utilis´ee lors du routage par BGP (Border Gateway Protocol [RLH06]) entre les diff´erents syst`emes autonomes. Plusieurs entit´es peuvent percevoir une d´efaillance mais cela ne suffit pas `a assurer qu’il s’agit d’une mˆeme d´efaillance induite par une mˆeme faute. Deux cas sont envisageables : Cas 1 diverses fautes concomitantes et ind´ependantes m`enent aux d´efaillances per¸cues par les entit´es, Cas 2 une unique faute provoque une d´efaillance per¸cue par ces mˆemes entit´es. Les auteurs de CEM proposent une mesure de vraisemblance not´ee LR. Cette mesure est utilis´ee comme un seuil permettant de faire la distinction entre ces deux cas. Cette mesure correspond au rapport LR = Pe/Pu entre la probabilit´e Pe que n entit´es distinctes per¸coivent des d´efaillances dues `a n fautes distinctes dans un intervalle de temps donn´e (permier cas) et la probabilit´e Pu que n entit´es per¸coivent une d´efaillance due `a une mˆeme faute dans ce mˆeme intervalle de temps (second cas). Une valeur de vraisemblance LR > 1 tend `a indiquer une d´efaillance li´ee au r´eseau tandis que LR ≤ 1 tend `a indiquer des d´efaillances individuelles. Cette approche est ensuite compar´ee aux donn´ees op´erationnelles de divers fournisseurs d’acc`es `a Internet. La valeur de LR est centrale dans la caract´erisation des fautes impactant le syst`eme. Celle-ci est positionn´ee statiquement `a partir des donn´ees issues des donn´ees op´erationnelles des divers fournisseurs d’acc`es `a Internet. Cette approche est ensuite appliqu´ee sur des mesures de qualit´e collect´ees `a partir de clients BitTorrent. Le r´esultat de la caract´erisation est ensuite compar´ee `a la vision des diff´erents fournisseurs d’acc`es `a Internet pendant la p´eriode consid´er´ee. Les r´esultats de cette comparaison sont difficiles `a interpr´eter. Sur l’ensemble des d´efaillances que les fournisseurs d’acc`es `a Internet attribuent `a des fautes massives, CEM en attribue 80% `a des fautes massives. Cependant, cette proportion repr´esente seulement 30% des d´efaillances attribu´ees `a des fautes massives par CEM. Les op´erateurs n’ont pas connaissance des 70% restant de d´efaillances d´ecel´ees par cette approche. Par cons´equent, il est impossible de savoir s’il s’agit de faux positifs de cette approche ou d’une tr`es forte proportion de d´efaillances ignor´ees par les fournisseurs d’acc`es `a Internet. Bien que cette approche soit une premi`ere approche vers la caract´erisation des fautes impactant le syst`eme en fonction du nombre d’entit´es percevant la d´efaillance induite, celle-ci pr´esente des limitations. Tout d’abord, celle-ci requi`ere une connaissance du r´eseau afin de regrouper ensemble les perceptions des entit´es d’un mˆeme syst`eme auto-38 Travaux connexes nome. Ensuite, le seuil de classification LR est fix´e de mani`ere empirique par l’analyse statistique de donn´ees issues de diff´erents fournisseurs d’acc`es `a Internet. Enfin, bien que cette approche soit un premier permettant de caract´eriser une faute en fonction de son impact, la validation de cette approche n’est pas tout `a fait convaincante dans la mesure o`u l’on ne sait pas si les 70% de d´efaillances suppl´ementaires d´ecel´ees constituent de r´eelles d´efaillances ou des faux positifs. Nous avons pr´esent´e dans ce chapitre les concepts n´ecessaires aux travaux d´ecrits dans ce document. De plus, nous avons d´ecrit les techniques classiques utilis´ees dans les syst`emes distribu´es large ´echelle ainsi que dans le cadre du clustering de donn´ees. Enfin, ces techniques nous ont permis de pr´esenter les travaux connexes existants sur la supervision et la caract´erisation de fautes dans les r´eseaux large ´echelle. Bibliographie [ABKS99] M. Ankerst, M. M. Breunig, H. P. Kriegel et J. Sander : OPTICS : Ordering Points To Identify the Clustering Structure. Dans Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 49–60, 1999. [ABLR08] E. Anceaume, F. Brasileiro, R. Ludinard et A. Ravoaja : Peercube : A hypercube-based p2p overlay robust against collusion and churn. Dans Proceedings of the IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO, pages 15–24, 2008. [BBG08] K. Buchin, M. Buchin et J. Gudmundsson : Detecting Single File Movement. Dans Proceedings of the 16th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems, pages 1–10, 2008. [BEF84] J. C Bezdek, R. Ehrlich et W. Full : FCM : The Fuzzy C-Means Clustering Algorithm. Computers & Geosciences, 10(2):191–203, 1984. [BGHW06] M. Benkert, J. Gudmundsson, F. Hubner ¨ et T. Wolle : Reporting flock patterns. Dans Proceedings of the 14th European Symposium on Algorithms, ESA, pages 660–671, 2006. [BGHW08] M. Benkert, J. Gudmundsson, F. Hubner ¨ et T. Wolle : Reporting Flock Patterns. Computational Geometry Theory and Applications, 41(3): 111–125, novembre 2008. [BKSS90] N. Beckmann, H. P. Kriegel, R. Schneider et B. Seeger : The R*- tree : An Efficient and Robust Access Method for Points and Rectangles. Dans Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 322–331, 1990. [CBG10] D. R. Choffnes, F. E. Bustamante et Z. Ge : Crowdsourcing Servicelevel Network Event Monitoring. Dans Proceedings of the ACM SIGCOMM Conference, pages 387–398, 2010.Bibliographie 39 [CFNV04] M. Correia, N. Ferreira Neves et P. Ver´ıssimo : How to Tolerate Half Less One Byzantine Nodes in Practical Distributed Systems. Dans Proceedings of the 23rd International Symposium on Reliable Distributed Systems, SRDS, pages 174–183, 2004. [Cho10] D. R. Choffnes : Service-Level Network Event Detection from Edge Systems. Th`ese de doctorat, Northeastern University, 2010. [Def77] D. Defays : An efficient algorithm for a complete link method. The Computer Journal, 20(4):364–366, 1977. [DLR77] A. P. Dempster, N. M. Laird et D. B. Rubin : Maximum Likelihood from Incomplete Data via the EM Algorithm. Journal of the Royal Statistical Society : Series B, 39:1–38, 1977. [EKSX96] M. Ester, H. P. Kriegel, J. Sander et X. Xu : A Density-Based Algorithm for Discovering Clusters in Large Spatial Databases with Noise. Dans Proceedings of the 2nd International Conference on Knowledge Discovery and Data Mining, KDD, pages 226–231, 1996. [FSY05] A. Fiat, J. Saia et M. Young : Making Chord Robust to Byzantine Attacks. Dans Proceedings of the 13rd European Symposium on Algorithms, ESA, pages 803–814, 2005. [HCDW12] C. Y. Hong, M. Caesar, N. Duffield et J. Wang : Tiresias : Online Anomaly Detection for Hierarchical Operational Network Data. Dans Proceedings of the 32nd IEEE International Conference on Distributed Computing Systems, ICDCS, pages 173–182, 2012. [HE02] G. Hamerly et C. Elkan : Alternatives to the K-means Algorithm That Find Better Clusterings. Dans Proceedings of the 11th International Conference on Information and Knowledge Management, CIKM, pages 600–607, 2002. [HW79] J. A. Hartigan et M. A. Wong : Algorithm AS 136 : A K-Means Clustering Algorithm. Journal of the Royal Statistical Society. Series C (Applied Statistics), 28(1):100–108, 1979. [JLO07] C. S. Jensen, D. Lin et Beng-Chin O. : Continuous Clustering of Moving Objects. Knowledge and Data Engineering, IEEE Transactions on, 19(9): 1161–1174, 2007. [JYZ+08] H. Jeung, M. L. Yiu, X. Zhou, C. S. Jensen et H. T. Shen : Discovery of Convoys in Trajectory Databases. Proceedings VLDB Endowment, 1(1): 1068–1080, aoˆut 2008. [KAD+07] R. Kotla, L. Alvisi, M. Dahlin, A. Clement et E. Wong : Zyzzyva : Speculative Byzantine Fault Tolerance. Dans Proceedings of the 21st ACM SIGOPS Symposium on Operating Systems Principles, SOSP, pages 45–58, 2007. [Kal60] R. E. Kalman : A New Approach to Linear Filtering and Prediction Problems. Transactions of the ASME–Journal of Basic Engineering, 82:35– 45, 1960.40 Travaux connexes [KR87] L. Kaufman et P. Rousseeuw : Clustering by Means of Medoids. Reports of the Faculty of Mathematics and Informatics. Delft University of Technology. 1987. [LSW06] T. Locher, S. Schmid et R. Wattenhofer : eQuus : A Provably Robust and Locality-Aware Peer-to-Peer System. Dans Proceedings of the 6th IEEE International Conference on Peer-to-Peer Computing, P2P, pages 3–11, 2006. [MA04] S. Malgorzata et S. S. Adarshpal : A survey of fault localization techniques in computer networks. Science of Computer Programming, 53(2):165–194, 2004. [MCC03] M. L. Massie, B. N. Chun et D. E. Culler : The Ganglia Distributed Monitoring System : Design, Implementation And Experience. Parallel Computing, 30:2004, 2003. [MM02] P. Maymounkov et D. Mazieres ` : Kademlia : A Peer-to-Peer Information System Based on the XOR Metric. Dans Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS, pages 53–65, 2002. [PM00] D. Pelleg et A. Moore : X-means : Extending K-means with Efficient Estimation of the Number of Clusters. Dans Proceedings of the 17th International Conference on Machine Learning, pages 727–734, 2000. [PP06] K. Park et V. S. Pai : CoMon : A Mostly-scalable Monitoring System for PlanetLab. SIGOPS Operating Systems Review, 40(1):65–74, janvier 2006. [RD01] A. Rowstron et P. Druschel : Pastry : Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems. Dans Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms, Middleware, pages 329–350, 2001. [RFH+01] S. Ratnasamy, P. Francis, M. Handley, R. Karp et S. Shenker : A Scalable Content-addressable Network. Dans Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, SIGCOMM, pages 161–172, 2001. [RLH06] Y. Rekhter, T. Li et S. Hares : RFC 4271 : A Border Gateway Protocol 4 (BGP-4). Rapport technique, IETF, 2006. [SEKX98] J. Sander, M. Ester, H.P. Kriegel et X. Xu : Density-Based Clustering in Spatial Databases : The Algorithm GDBSCAN and Its Applications. Data Mining and Knowledge Discovery, 2(2):169–194, 1998. [Sib73] R. Sibson : SLINK : an optimally efficient algorithm for the single-link cluster method. The Computer Journal, 16(1):30–34, 1973. [SMK+01] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek et H. Balakrishnan : Chord : A Scalable Peer-to-peer Lookup Service for Internet Applications. SIGCOMM Computer Communication Review, 31(4):149–160, aoˆut 2001.Bibliographie 41 [VBT09] M. R. Vieira, P. Bakalov et V. J. Tsotras : On-line Discovery of Flock Patterns in Spatio-temporal Data. Dans Proceedings of the 17th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems, GIS, pages 286–295, 2009. [VRBV03] R. Van Renesse, K. P. Birman et W. Vogels : Astrolabe : A Robust and Scalable Technology for Distributed System Monitoring, Management, and Data Mining. ACM Transactions Computer Systems, 21(2):164–206, mai 2003. [YD04] P. Yalagandula et M. Dahlin : A Scalable Distributed Information Management System. Dans Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, SIGCOMM, pages 379–390, 2004. [YFG+12] H. Yan, A. Flavel, Z. Ge, A. Gerber, D. Massey, C. Papadopoulos, H. Shah et J. Yates : Argus : End-to-End Service Anomaly Detection and Localization From an ISP’s Point of View. Dans Proceedings of the IEEE INFOCOM Conference, INFOCOM, pages 2756–2760, 2012. [ZTG+09] Y. Zhao, Y. Tan, Z. Gong, X. Gu et M. Wamboldt : Self-correlating Predictive Information Tracking for Large-scale Production Systems. Dans Proceedings of the 6th International Conference on Autonomic Computing, ICAC, pages 33–42, 2009.42 Travaux connexesChapitre 3 Caract´erisation de fautes Nous d´efinissons dans ce chapitre un mod`ele permettant de prendre en compte l’impact des fautes sur les perceptions des utilisateurs sans connaissance du r´eseau d’interconnexion. L’activation d’une faute dans le syst`eme peut induire une d´efaillance per¸cue par les utilisateurs. Cette d´efaillance est per¸cue au travers d’une variation anormale de la qualit´e d’un service consomm´e. Nous repr´esentons un sc´enario possible de fautes impactant le syst`eme au travers d’une partition d’anomalies. Cette mod´elisation va nous permettre de d´eterminer ce qui est discernable du point de vue des entit´es supervis´ees. Nous montrons qu’il est impossible de d´eterminer de mani`ere certaine pour chaque entit´e ayant per¸cu une d´efaillance si cette d´efaillance est due `a une faute locale (faute isol´ee) ou si cette d´efaillance est per¸cue par d’autres entit´es (faute massive). En assouplissant le crit`ere de faute (faute isol´ee, faute massive ou ´etat ind´etermin´e), il est possible de d´eterminer pour chaque variation de qualit´e anormale per¸cue, le type de faute `a lui associer. De plus, nous montrons que la seule connaissance du voisinage, en termes de qualit´es, de chaque entit´e est suffisante pour d´eterminer pour chaque entit´e le type de faute ayant induit la d´efaillance per¸cue. Une connaissance plus importante, telle que celle qu’aurait un observateur global du syst`eme, n’apporte pas plus d’informations permettant de caract´eriser de mani`ere certaine l’ensemble des fautes impactant le syst`eme. 3.1 Mod`ele Cette section pr´esente les notations et les concepts que nous utilisons pour la mod´elisation de l’impact des fautes sur les mesures de performances effectu´ees par les entit´es supervis´ees. Nous utilisons dans la suite de ce document les conventions suivantes : — les variables sont not´ees en lettres minuscules : j, `, p, q — les ensembles sont not´es en lettres majuscules : S, E — les familles d’ensemble sont not´ees en lettres majuscules calligraphi´ees : P — les intervalles discrets {1, . . . , n} sont not´es [[1, n]]. 4344 Caract´erisation de fautes L’ensemble des notations utilis´ees dans cette section est r´esum´e dans le tableau 3.1. 3.1.1 Pr´eliminaires On consid`ere un ensemble [[1, n]] d’entit´es supervis´ees. Chacune de ces n entit´es consomme des services au travers du r´eseau choisis parmis d services not´es s1, . . . , sd. A chaque instant discret ` k, l’entit´e j ∈ [[1, n]] ´evalue une mesure de performance qi,k(j) du service si `a valeurs dans [0, 1]. Si l’entit´e j ∈ [[1, n]] ne consomme pas le service si `a l’instant k, qi,k(j) vaut 0. On mod´elise les mesures effectu´ees `a l’instant k par l’entit´e j par un point pk(j) = (q1,k(j), . . . , qd,k(j)) de l’espace m´etrique E = [0, 1]d . On parlera aussi d’espace des qualit´es pour d´esigner cet espace. On mod´elise l’ensemble des mesures effectu´ees par les n entit´es par l’ensemble des points Sk de E, Sk = (pk(1), . . . , pk(n)). Cet ensemble de points Sk est appel´e ´etat du syst`eme ou configuration du syst`eme `a l’instant k. De plus, chaque entit´e est munie d’une fonction de d´etection de d´efaillance ak(j) qui retourne VRAI si une variation dans la mesure de performance d’un service consomm´e par l’entit´e j `a l’instant k peut ˆetre consid´er´ee comme une d´efaillance. La notion de d´efaillance est tr`es fortement d´ependante du type de mesure effectu´e et du service consomm´e. Des m´ethodes (par exemple [Pag54, Hol04, Win60]) permettant cette d´etection de d´efaillance ont ´et´e ´evoqu´ees auparavant et ne seront pas trait´ees ici. Des fautes peuvent apparaˆıtre dans le syst`eme et leur impact peut ˆetre per¸cu par diff´erentes entit´es. Nous nous int´eressons `a distinguer les fautes suivant le nombre d’entit´es supervis´ees impact´ees. D´efinition 1 (fautes isol´ees / massives) Etant donn´es ´ k ≥ 1, Sk−1, Sk et τ ∈ [[1, n − 1]], une faute impactant strictement plus de τ entit´es supervis´ees est appel´ee faute massive. Dans le cas contraire, on parle de faute isol´ee. Les entit´es observant des variations de performances similaires sont susceptibles de percevoir les mˆemes d´efaillances. On consid`ere ici qu’une mˆeme faute a un impact similaire sur les mesures effectu´ees par les entit´es. Nous traduisons cette intuition par l’hypoth`ese suivante : si les mesures effectu´ees par les entit´es avant la perception de la d´efaillance sont proches et qu’elles le sont encore apr`es la perception de celle-ci, alors la d´efaillance est due `a la mˆeme faute. Cette hypoth`ese est mod´elis´ee par une distance seuil entre les positions des entit´es dans l’espace des qualit´es : s’il existe une boule de rayon r contenant les positions de ces entit´es dans l’espace des qualit´es `a l’instant k−1 et une autre contenant les positions de ces mˆemes entit´es `a l’instant k alors ces entit´es ont per¸cu la mˆeme d´efaillance. On appellera ce rayon r le rayon de coh´erence. 3.1.2 Terminologie et notations employ´ees Afin de mod´eliser de l’impact des fautes sur le syst`eme, nous introduisons les notions que nous utiliserons tout au long de ce chapitre. Tout d’abord, dans un soucis de simplicit´e, nous utilisons la norme infinie k · k d´efinie pour tout x = (x1, . . . , xd) ∈ EMod`ele 45 par kxk = max{x1, . . . , xd}. D’autre part, la distance entre deux points x, y ∈ E est d´efinie par la norme du vecteur kx−yk. L’espace E ´etant de dimension finie d toutes les normes sont ´equivalentes et donc les r´esultats fournis restent valables `a des constantes pr`es. D´efinition 2 (Ensemble r-coh´erent) Pour tout r ∈ [0, 1/4), un sous-ensemble B ⊆ [[1, n]] est dit r-coh´erent `a l’instant k ≥ 0 si la distance maximale entre tous points i, j ∈ B est inf´erieure ou ´egale `a 2r : ∀(i, j) ∈ B 2 , kpk(i) − pk(j)k ≤ 2r. Propri´et´e 1 Pour tout k ≥ 0, pour tout r ∈ [0, 1/4) et pour tout B ⊆ [[1, n]], on a l’´equivalence suivante : ∃o ∈ E, ∀j ∈ B, kpk(j) − pk(o)k ≤ r ⇐⇒ B est r-coh´erent `a l’instant k. Preuve (⇒) Soient B ⊆ [[1, n]] et o ∈ E tels que pour tout j ∈ B, nous ayons kpk(j) − pk(o)k ≤ r. Cela implique que tous les ´el´ements de B sont contenus dans une boule de rayon r centr´ee en o. On a donc ∀(i, j) ∈ B2 , kpk(i) − pk(j)k ≤ 2r. Par cons´equent, B est un ensemble r-coh´erent. (⇐) Soit B = [[1, `]] ⊆ [[1, n]] un ensemble r-coh´erent `a l’instant k. D’apr`es la d´efinition 2 cela signifie que ∀(i, j) ∈ B2 , kpk(i) − pk(j)k ≤ 2r. De plus, d’apr`es la d´efinition de la norme employ´ee, la distance entre deux points (x, y) ∈ E2 est d´efinie par kx − yk = max{|x1 − y1|, . . . , |xd − yd|}. On a donc ∀(i, j) ∈ B2 , ∀m ∈ [[1, d]], |qm,k(i) − qm,k(j)| ≤ 2r. Soit le point o = (o1, . . . , od) ∈ E. On consid`ere la m- `eme coordonn´ee qm,k(j) de chaque point j ∈ B. Ces coordonn´ees sont toutes incluses dans le segment [min{qm,k(1), . . . , qm,k(`)}, max{qm,k(1), . . . , qm,k(`)}]. On d´efinit alors om comme le milieu de ce segment. On a : ∀m ∈ [[1, d]], om = max{qm,k(1), . . . , qm,k(`)} − min{qm,k(1), . . . , qm,k(`)} 2 . L’ensemble B ´etant r-coh´erent `a l’instant k, on a ∀(i, j) ∈ B2 , |qm,k(i) − qm,k(j)| ≤ 2r. Par cons´equent, on a ∀j ∈ B, ∀m ∈ [[1, d]], |om − qm,k(j)| ≤ r et donc ∀j ∈ B, kpk(j) − pk(o)k ≤ r. 2 D´efinition 3 (Ensemble r-coh´erent maximal) Pour tout r ∈ [0, 1/4), un sousensemble B ⊆ [[1, n]] est dit maximal r-coh´erent `a l’instant k si les deux conditions suivantes sont v´erifi´ees : — B est un ensemble r-coh´erent `a l’instant k, — ∀j ∈ [[1, n]] \ B, B ∪ {j} n’est pas un ensemble r-coh´erent `a l’instant k.46 Caract´erisation de fautes Sk 2 1 4 3 5 6 2r 2r Figure 3.1 – Les ensembles maximaux r-coh´erents B1 = {1, 2, 3, 4} et B2 = {1, 2, 3, 5, 6} contenant le point 1. Tout sous-ensemble de B1 ou B2 est aussi r-coh´erent. Exemple 6 La figure 3.1 illustre ces deux notions. On consid`ere un ensemble de 6 entit´es labellis´ees {1, 2, 3, 4, 5, 6} `a l’instant k. Ces entit´es consomment un unique service (donc d = 1) et mesurent la performance de celui-ci. On place ces entit´es dans l’espace des qualit´e E qui se r´eduit alors au segment [0, 1] et les points correspondent `a la position de chaque entit´e supervis´ee dans E. La distance entre tout couple d’´el´ements de B1 = {1, 2, 3, 4} ou tout couple d’´el´ements de B2 = {1, 2, 3, 5, 6} est inf´erieure `a 2r. Ces ensembles sont donc r-coh´erents. De plus, ces ensembles B1 et B2 sont maximaux : en effet, tout ajout `a B1 d’un ´el´ement de B2 augmente la distance maximale entre les ´el´ements de B1 au del`a de 2r brisant ainsi la condition de r-coh´erence. Le mˆeme raisonnement s’applique `a B2. Ces deux notions nous permettent d’introduire la notion de mouvement permettant de capturer les variations de perception des entit´es fortement corr´el´ees. D´efinition 4 (Mouvement r-coh´erent) Pour tout k ≥ 1, pour tout r ∈ [0, 1/4), un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k] si B est un ensemble r-coh´erent aux instants k − 1 et k. D´efinition 5 (Mouvement r-coh´erent maximal) Pour tout k ≥ 1, pour tout r ∈ [0, 1/4), un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent maximal dans l’intervalle de temps [k − 1, k] si les deux conditions suivantes sont v´erifi´ees : — B a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k], — ∀j ∈ [[1, n]] \ B, B ∪ {j} n’a pas de mouvement r-coh´erent dans l’intervalle de temps [k − 1, k]. Remarque 1 Si un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k], alors soit ce mouvement est maximal, soit il existe B0 ⊆ [[1, n]], B ⊆ B0 tel que B0 ait un mouvement maximal r-coh´erent. Exemple 7 La figure 3.2 illustre la notion de mouvements r-coh´erents. A gauche, sur ` la figure 3.2(a), sont repr´esent´ees les positions de six entit´es {1, 2, 3, 4, 5, 6} consommant un unique service aux instants k −1 et k ainsi que les ensembles r-coh´erents maximaux contenant chacune d’elles. La figure 3.2(b) repr´esente ces mˆemes entit´es dans l’espace des trajectoires T = E ×E. La variation de qualit´e per¸cue par l’entit´e j est repr´esent´ee par le point (q1,k−1(j), . . . , qd,k−1(j), q1,k(j), . . . , qd,k(j)).Mod`ele 47 Sk Sk−1 2 1 3 4 5 6 2r 2r 1 2 3 5 4 6 2r 2r 2r (a) Deux ensembles r-coh´erents maximaux `a l’instant k − 1 : {1, 2, 3, 5} et {1, 2, 3, 4, 6}. On a trois ensembles r-coh´erents maximaux `a l’instant k : {1, 2, 3, 5}, {1, 2, 3, 4}, {3, 4, 6}. Sk Sk−1 1 2 3 4 5 6 B1 B2 B3 (b) Trois ensembles ayant des mouvements rcoh´erents maximaux : B1 = {1, 2, 3, 5}, B2 = {1, 2, 3, 4}, B3 = {3, 4, 6}. Figure 3.2 – Repr´esentation des variations de qualit´e dans l’espace des trajectoires. La droite y = x est trac´ee en pointill´es, les points situ´es sur cette droite traduisent l’absence de variation de qualit´e mesur´ee par les entit´es dans l’intervalle de temps [k−1, k] : pour chacune d’elles on a pk(j) = pk−1(j). Les points situ´es au dessus de cette droite traduisent une am´elioration de la qualit´e mesur´ee par les entit´es dans l’intervalle de temps [k − 1, k] tandis que ceux situ´es en dessous traduisent une d´egradation de la qualit´e per¸cue par les entit´es dans l’intervalle de temps [k −1, k]. Ici, les six entit´es ont per¸cu une d´egradation de leur qualit´e. Les mouvements r-coh´erents correspondent aux points contenus dans le produit cart´esien d’une boule de rayon r `a l’instant k − 1 avec une autre boule de rayon r `a l’instant k. Ces mouvements sont repr´esent´es par les carr´es gris´es B1, B2 et B3. Nous utiliserons cette repr´esentation dans le reste de ce document. Finalement, nous classifions les mouvements r-coh´erents suivant le nombre d’entit´es supervis´ees qui les composent. Cette classification est au centre de la distinction que nous ´etablissons entre les fautes isol´ees et les fautes massives. D´efinition 6 (Mouvement τ -dense) Pour tout r ∈ [0, 1/4), pour tout τ ∈ [[1, n−1]], et pour tout sous-ensemble B ⊆ [[1, n]] ayant un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k], on dit que B a un mouvement r-coh´erent τ -dense dans l’intervalle de temps [k − 1, k] si |B| > τ , sinon on dit que B a un mouvement r-coh´erent non τ -dense dans cet intervalle. Dans la suite, on utilisera ”mouvement τ -dense” (respectivement ”mouvement non τ -dense”) au lieu de ”mouvement r-coh´erent τ -dense” (respectivement ” mouvement r-coh´erent non τ -dense”) lorsque le contexte est clair.48 Caract´erisation de fautes 3.1.3 Mod´elisation de l’impact des fautes Chaque entit´e supervis´ee j consomme un sous-ensemble des d services. Pour chaque service consomm´e, l’entit´e j effectue localement une mesure de performance de bout-enbout. Ces mesures de performances sont utilis´ees en entr´ee de la fonction de d´etection de d´efaillance ak(j). Si une variation de performance est consid´er´ee comme une d´efaillance par la fonction de d´etection de d´efaillance ak(j), celle-ci retourne VRAI. On d´efinit la trajectoire anormale d’une entit´e du syst`eme dans l’espace des qualit´es comme la cons´equence sur les mesures de performance d’une faute dans le syst`eme. D´efinition 7 (Trajectoire anormale) Une entit´e j ∈ [[1, n]] a une trajectoire anormale dans l’intervalle de temps [k − 1, k] si ak(j) = VRAI. L’ensemble des entit´es ayant une trajectoire anormale dans l’intervalle de temps [k−1, k] est not´e Ak. Formellement, on a : Ak = {j ∈ [[1, n]] | ak(j) = VRAI} . Nous cherchons `a d´eterminer pour chaque entit´e percevant une d´efaillance dans l’intervalle de temps [k − 1, k] si la faute qui a caus´e cette d´efaillance a impact´e un grand nombre d’entit´es ou seulement quelques unes. Pour cela, nous d´eterminons pour chaque entit´e la pr´esence d’autres entit´es dans son voisinage dans l’espace des qualit´es aux instants k−1 et k. Par exemple, si plus de τ entit´es ayant des trajectoires anormales restent proches les unes des autres, nous consid´erons que ces trajectoires anormales sont dues `a une mˆeme faute et donc que ces entit´es per¸coivent une d´efaillance due `a une faute massive. Nous pouvons alors restreindre la recherche des causes de cette d´efaillance `a ces seules entit´es impact´ees. Cependant, si l’intervalle de temps entre les instants de mesure est trop important, il est possible que ces mˆemes entit´es per¸coivent diff´erentes d´efaillances, rendant impossible toute reconstruction de sc´enario d’explication. Nous imposons donc trois restrictions n´ecessaires `a la reconstruction de ces sc´enarios : R1 : Dans l’intervalle de temps [k −1, k], la trajectoire anormale de l’entit´e supervis´ee j ∈ Ak n’est due qu’`a une unique faute. R2 : Une faute a un impact similaire sur toutes les entit´es supervis´ees qui la per¸coivent. En particulier, si un ensemble B d’entit´es supervis´ees forme un ensemble rcoh´erent avant la perception de la d´efaillance (i.e. `a l’instant k−1), alors celles-ci forment encore un ensemble r-coh´erent `a l’instant k et donc par la d´efinition 4, cet ensemble a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k]. R3 : Si une faute impacte strictement plus de τ entit´es alors pour chacune d’elles il existe un ensemble ayant un mouvement τ -dense. Celui-ci ne contient pas n´ecessairement l’ensemble des entit´es impact´ees par cette faute massive. R´eciproquement, dans un ensemble ayant un mouvement τ -dense, il existe au moins une entit´e ayant ´et´e effectivement impact´ee par une faute massive. Ces restrictions imposent que les entit´es percevant une d´efaillance due `a une faute massive aient un mouvement r-coh´erent. Cependant, une faute peut engendrer plusieursMod`ele 49 mouvements r-coh´erents `a des positions diff´erentes dans l’espace des qualit´es. Ces restrictions sont formalis´ees par le partitionnement de l’ensemble Ak en sous-ensembles ayant des mouvements r-coh´erents. Ce partitionnement est tel que : (i) tous les mouvements r-coh´erents non τ -denses sont suffisamment ´eloign´es les uns des autres, de sorte qu’il soit impossible de reconstituer un mouvement τ -dense `a partir de ces ´el´ements. En d’autres termes, la probabilit´e que plus de τ fautes ind´ependantes impactent des entit´es supervis´ees dont les mesures effectu´ees `a deux instants cons´ecutifs sont similaires est n´egligeable. Cette condition traduit le fait qu’il est impossible de distinguer une faute impactant un ensemble d’entit´es supervis´ees d’un ensemble de fautes impactant chacune une entit´e supervis´ee de mani`ere similaire aux autres fautes. Par exemple, des passerelles de connexion utilisateurs subissant chacune une faute isol´ee impactant la connexion r´eseau percevraient les mˆemes variations de mesure de performance qu’un ensemble de passerelles de connexion utilisateurs percevant une mˆeme d´efaillance r´eseau. (ii) tout mouvement r-coh´erents non τ -dense est suffisamment ´eloign´e d’un mouvement r-coh´erent τ -dense, de sorte qu’il soit impossible de les regrouper au sein d’un unique ensemble ayant un mouvement r-coh´erent τ -dense. En d’autres termes, la probabilit´e que plusieurs fautes ind´ependantes impactent plus de τ entit´es supervis´ees dont les mesures effectu´ees sont similaires est n´egligeable. Cette condition traduit le fait qu’il est impossible de distinguer une faute impactant un ensemble d’entit´es supervis´ees, de deux fautes impactant l’une un faible nombre (inf´erieur `a τ ) d’entit´es et la seconde le reste des entit´es. Consid´erons par exemple d’une part une passerelle utilisateur sujette `a une faute isol´ee et d’autre part un ensemble de passerelles de connexion utilisateurs percevant une mˆeme d´efaillance r´eseau, et supposons que toutes ces entit´es per¸coivent une mˆeme variation de qualit´e. Dans ce cas, l’entit´e sujette `a une faute isol´ee exhibe alors une trajectoire anormale similaire `a celles des autres entit´es. Il est donc impossible de discerner l’entit´e impact´ee par la faute isol´ee des autres entit´es percevant une faute massive. Afin de prendre en compte ces restrictions, nous partitionnons l’ensemble Ak des entit´es de [[1, n]] ayant une trajectoires anormales dans l’intervalle de temps [k − 1, k] en sous-ensembles appel´es anomalies. Les anomalies ont des mouvements r-coh´erents dans l’espace des qualit´es. Les entit´es d’une anomalie per¸coivent donc une d´efaillance de mani`ere coh´erente. Une partition d’anomalies Pk repr´esente un sc´enario possible de fautes, respectant les restrictions R1, R2 et R3, qui impactent le syst`eme. On dit que la partition d’anomalies a fait ´evoluer le syst`eme de l’´etat Sk−1 `a l’´etat Sk. Ce partitionnement de Ak est formellement d´efini comme suit. D´efinition 8 (Partition d’anomalies Pk) Pour tout k ≥ 1, pour tout τ ∈ [[1, n − 1]] et pour tout r ∈ [0, 1/4), la partition Pk de Ak est une partition d’anomalies `a l’instant k si elle est constitu´ee d’ensembles C1, . . . , C` , non vides et deux `a deux disjoints, ayant50 Caract´erisation de fautes des mouvements r-coh´erents et v´erifiant les conditions C1, C2 suivantes. Les ensembles C1, . . . , C` sont appel´es anomalies. C1 : ∀B ⊆ S |Ci|≤τ Ci , B a un mouvement r-coh´erent non τ -dense ou B n’a pas de mouvement r-coh´erent. C2 : ∀i ∈ [[1, `]], Ci a un mouvement r-coh´erent τ -dense ⇒ ∀B ⊆ S |Cj |≤τ Cj , B ∪ Ci n’a pas un mouvement r-coh´erent. Par extension, pour tout ´el´ement j ∈ Ak on notera Pk(j) l’unique partie de Pk contenant l’´el´ement j. Finalement on distingue les anomalies isol´ees des massives suivant le cardinal des parties C1, . . . , C` de Pk. D´efinition 9 (Anomalies Massives / Isol´ees ) Soit Pk une partition d’anomalies. Un ´el´ement C ∈ Pk est appel´e anomalie massive de Pk dans l’intervalle de temps [k − 1, k] si |C| > τ . Dans le cas contraire, on l’appelle anomalie isol´ee de Pk. L’ensemble des entit´es supervis´ees impact´ees par une anomalie massive de Pk dans l’intervalle de temps [k−1, k] est not´e MPk . De la mˆeme mani`ere on note IPk , l’ensemble des entit´es supervis´ees impact´ees par une anomalie isol´ees de Pk dans l’intervalle de temps [k − 1, k]. Formellement on a : MPk = {j ∈ Ak | |Pk(j)| > τ}, IPk = {j ∈ Ak | |Pk(j)| ≤ τ}. Ces ensembles sont compl´ementaires dans Ak et induisent une d´ecomposition naturelle de Ak. On a : Ak = MPk ∪ IPk et MPk ∩ IPk = ∅. (3.1) Bien que la d´efinition de partition d’anomalie puisse sembler complexe, le lemme 1 montre qu’on peut toujours construire une partition d’anomalies, et qu’en g´en´eral celleci n’est pas unique. Lemme 1 Pour tout k ≥ 1, pour tout Ak 6= ∅, pour tout τ ∈ [[1, n − 1]], pour tout r ∈ [0, 1/4) et pour tous ´etats cons´ecutifs Sk−1, Sk du syst`eme, il existe toujours une partition Pk de Ak qui est une partition d’anomalies. Cette partition n’est en g´en´eral pas unique. Preuve On montre dans un premier temps l’existence de partitions d’anomalies, puis on illustrera sur un exemple que celles ci ne sont pas n´ecessairement uniques. (Existence) L’algorithme 1 d´ecrit une mani`ere simple de construire une partition d’anomalies Pk de Ak. On initialise l’ensemble des entit´es `a traiter S avec les ´el´ements de Ak et le r´esultat Pk avec l’ensemble vide. Tant qu’il reste des ´el´ements `a traiter (i.e. S n’est pas vide), on choisit al´eatoirement un ´el´ement j dans S. On choisit alors un sous-ensemble C de S tel que j appartienne `a ce sous-ensemble C et que C aitMod`ele 51 Algorithme 1 : Construction d’une partition d’anomalie de Ak. Donn´ees : Sk−1, Sk, τ ∈ [[1, n − 1]], r ∈ 0, 1 4  . Entr´ees : Ak Sorties : Une partition d’anomalie 1 d´ebut 2 S ← Ak; 3 Pk ← {}; 4 tant que S 6= ∅ faire 5 Choisir j ∈ S; 6 Choisir C ⊆ S tel que j ∈ C, C 6∈ Pk et C a un mouvement r-consistent maximal dans S; 7 S ← S \ C ; 8 Pk ← Pk ∪ {C}; 9 fin 10 retourner Pk; 11 fin un mouvement maximal r-coh´erent parmi les ´el´ements de S. Cet ensemble C est alors ajout´e `a Pk et ses ´el´ements sont retir´es de S. A chaque it´eration, on supprime donc des ` ´el´ements de S. La taille de S est donc strictement d´ecroissante, l’algorithme termine. Montrons `a pr´esent par r´ecurrence qu’`a chaque it´eration Pk satisfait les conditions C1 et C2 de la d´efinition 8. Le premier ´el´ement ajout´e `a Pk a un mouvement r-coh´erent maximal par d´efinition. Comme il s’agit du premier ´el´ement, il n’existe pas d’autre partie de Pk permettant ´eventuellement de lui adjoindre des ´el´ements. Supposons `a pr´esent, qu’`a la fin de la `-i`eme it´eration, Pk = {C1, . . . , C`} satisfait les conditions C1 et C2 de la d´efinition 8. Montrons alors qu’`a la fin de l’it´eration suivante, Pk les satisfait encore. On choisit un ´el´ement j de S. On choisit ensuite C ⊆ S tel que j appartienne `a C et que C ait un mouvement maximal r-coh´erent parmi les ´el´ements de S. Par construction, ∀i ∈ [[1, `]], Ci ∈ Pk a un mouvement r-coh´erent maximal parmi les ´el´ements restants S \∪1≤i≤`Ci . Donc, d’apr`es la d´efinition 5, ∀j ∈ S \∪1≤i≤`Ci , Ci∪ {j} n’a pas un mouvement r-coh´erent. En particulier, ∀j ∈ C, ∀i ∈ [[1, `]], Ci ∪ {j} n’a pas un mouvement r-coh´erent et donc les conditions C1 et C2 sont satisfaites par Pk. Par hypoth`ese de r´ecurrence, Pk satisfait donc C1 et C2 `a chaque it´eration. Enfin, Ak n’est pas vide et donc pour tout ´el´ement j ∈ Ak, il existe une unique partie C ∈ Pk contenant j. A la fin de l’ex´ecution de l’algorithme, tous les ´el´ements de ` Ak appartiennent `a une partie de Pk et donc Pk est bien une partition de Ak. (Non unicit´e) Etant donn´es ´ Ak, Sk−1 and Sk, on illustre la possibilit´e de construire diverses partitions d’anomalies. Consid´erons l’exemple de la figure 3.3. Celle-ci illustre les mesures de performances prises par dix entit´es supervis´ees `a l’instant k en fonction de celles mesur´ees `a l’instant k−1, ainsi que les mouvements r-coh´erents maximaux possibles. Supposons qu’on a τ = 3 et que toutes les entit´es supervis´ees ont une trajectoire anormale dans l’intervalle de temps [k − 1, k]. Indexation de bases d’images : Evaluation de l’impact ´ ´emotionnel Syntyche Gbehounou To cite this version: Syntyche Gbehounou. Indexation de bases d’images : Evaluation de l’impact ´emotionnel. ´ Signal and Image Processing. Universit´e de Poitiers, 2014. French. HAL Id: tel-01089308 https://tel.archives-ouvertes.fr/tel-01089308 Submitted on 1 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE pour l’obtention du Grade de DOCTEUR DE L’UNIVERSITE DE POITIERS (Faculté des Sciences Fondamentales et Appliquées) (Diplôme National - Arrêté du 7 août 2006) École Doctorale: Sciences et Ingénierie pour l’Information, Mathématiques (S2IM) Secteur de recherche : Traitement du Signal et des images Présentée par: Syntyche GBEHOUNOU ************************ Indexation de bases d’images : Évaluation de l’impact émotionnel ************************ Directrice de thèse: Christine FERNANDEZ-MALOIGNE Co-Directeur de thèse: François LECELLIER ************************ Soutenue le 21 Novembre 2014 devant la Commission d’Examen composée de: ************************ Membres du jury Pr. Ludovic MACAIRE, LAGIS, Université de Lille, Rapporteur Pr. Denis PELLERIN, GIPSA-lab, Polytech’Grenoble, Rapporteur Pr. Theo GEVERS, Université d’Amsterdam, Pays-Bas, Examinateur MCF. Emmanuel DELLANDRÉA, LIRIS, École Centrale de Lyon, Examinateur Pr. Christine FERNANDEZ-MALOIGNE, XLIM-SIC, Université de Poitiers, Directrice de thèse MCF. François LECELLIER, XLIM-SIC, Université de Poitiers, Co-directeur de thèseRemerciements Je tiens tout d’abord, à remercier, les membres de mon jury de thèse : Messieurs Ludovic Macaire et Denis Pellerin qui m’ont fait l’honneur d’accepter de rapporter ce manuscrit, Messieurs Emmanuel Dellandréa et Theo Gevers qui ont accepté de participer à ce jury. Ensuite, concernant mon encadrement, je remercie ma directrice de thèse Madame Christine Fernandez-Maloigne, pour sa présence malgré un emploi du temps très chargé et ses remarques constructives durant toutes ces années. Un grand merci à Monsieur François Lecellier, mon co-directeur de thèse, pour ses conseils, le temps passé à débugguer mes codes et sa spontanéité. Encore merci à tous les deux pour votre confiance et tous vos conseils. J’ai découvert grâce à vous une passion pour l’enseignement et approfondi mon goût de la recherche. Je remercie toutes les personnes avec lesquelles j’ai travaillé et surtout collaboré pendant ma thèse : Vincent Courboulay, Enrico Calore, Daniele Marini, Ton Le Huu et Thierry Urruty. Merci Thierry pour nos discussions sur l’indexation et ses problématiques et surtout pour cette collaboration fructueuse. Je remercie tous les membres du laboratoire avec une pensée particulière pour tous les doctorants, post-doctorants, ingénieurs de recherche anciens et nouveaux avec lesquels nous avons discuté de la recherche, de la science et de nombreux autres sujets. J’aimerais également exprimer toute ma sympathie au personnel administratif de l’Université de Poitiers et du département XLIM-SIC pour leur disponibilité. Je souhaite remercier les étudiants qui ont créé chez moi l’envie d’enseigner au cours de ces 2 années de partage. Ce travail n’aurait pas pu être possible sans toutes les personnes qui ont pris le temps de participer aux différentes évaluations subjectives. Je leur exprime ici toute ma gratitude. J’aimerais exprimer toute ma gratitude à mes amis pour leur présence et leur patience pendant ces 3 années. Merci à Françoise, à Dimitri, à mes "cousins" pour leur soutien infaillible. J’aimerais finir en remerciant mes parents pour leur soutien infaillible et leur bienveillance. Merci d’avoir toujours été là pour moi malgré la distance, de m’avoir remonté le moral quand il fallait. Perside et Fabien merci de votre patience pendant toutes ces années et tout votre soutien pendant les dernières semaines de ma rédaction. iRemerciements iiTable des matières Remerciements i Tables des figures ix Liste des tableaux xi Notations et acronymes xiii Introduction générale 1 I Recherche d’images par le contenu 5 1 Solutions de recherche d’images par le contenu 9 1.1 Descripteurs d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Exemples de caractéristiques globales . . . . . . . . . . . . . . 11 1.1.2 Caractérisation locale : l’alternative aux insuffisances des descripteurs globaux . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Recherche des images les plus ressemblantes . . . . . . . . . . . . . . 20 1.2.1 Création du dictionnaire de mots visuels . . . . . . . . . . . . 21 1.2.2 Quelques méthodes de création de la signature visuelle d’une image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.3 Recherche des images similaires à partir de leurs signatures visuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3 Saillance visuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1 Qu’est-ce que l’attention visuelle ? . . . . . . . . . . . . . . . . 28 1.3.2 Différents modèles de saillance visuelle . . . . . . . . . . . . . 34 1.3.3 Modèle de saillance de Itti et Koch . . . . . . . . . . . . . . . 35 1.3.4 Évaluation des modèles de saillance visuelle . . . . . . . . . . 37 1.4 Quelques travaux intégrant la saillance visuelle en recherche d’images par le contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2 Notre approche pour l’indexation 39 2.1 Bases d’images utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2 Nos choix de descripteurs . . . . . . . . . . . . . . . . . . . . . . . . . 42 iiiTable des matières 2.3 Nouvelle méthode de construction du dictionnaire visuel : Iterative Random visual words Selection (IteRaSel) . . . . . . . . . . . . . . . 42 2.4 Évaluations de IteRaSel . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.4.1 Sélection aléatoire des mots . . . . . . . . . . . . . . . . . . . 45 2.4.2 Sélection aléatoire des mots visuels couplée à un processus itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.4.3 Stabilisation du processus aléatoire . . . . . . . . . . . . . . . 48 2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires . 49 2.4.5 Comparaison avec l’état de l’art . . . . . . . . . . . . . . . . . 50 2.4.6 Discussions autour des résultats . . . . . . . . . . . . . . . . . 52 2.5 Pondération des vecteurs de descripteurs par la saillance . . . . . . . 53 2.6 Évaluation de la saillance de certains détecteurs de points clés . . . . 55 2.6.1 Saillance visuelle des caractéristiques locales . . . . . . . . . . 55 2.6.2 Discussions autour de ces premiers résultats . . . . . . . . . . 61 2.7 Étude de l’importance des points clés saillants . . . . . . . . . . . . . 62 2.7.1 Impact de la suppression des points clés en fonction de leur saillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.7.2 Ajouts de points saillants . . . . . . . . . . . . . . . . . . . . . 64 2.7.3 Discussions autour des travaux sur la saillance . . . . . . . . . 65 II Reconnaissance de l’impact émotionnel des images 71 3 Reconnaissance des émotions dans la littérature 75 3.1 Définition et théories de l’émotion . . . . . . . . . . . . . . . . . . . . 76 3.2 Modélisations des émotions . . . . . . . . . . . . . . . . . . . . . . . . 77 3.3 Émotions et couleurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.4 Reconnaissance de l’impact émotionnel traitée comme une tâche de reconnaissance d’image dans la littérature . . . . . . . . . . . . . . . 83 3.4.1 Bases d’images de la littérature . . . . . . . . . . . . . . . . . 83 3.4.2 Systèmes de reconnaissance d’images basée émotion . . . . . . 86 4 Notre approche pour la reconnaissance des émotions 91 4.1 Proposition d’une nouvelle taxonomie de description des bases d’images pour l’étude des émotions . . . . . . . . . . . . . . . . . . . . . . . . 93 4.1.1 Critères d’évaluation des informations intrinsèques à la base . 93 4.1.2 Critères d’évaluation des informations extrinsèques à la base . 93 4.1.3 Critères d’évaluation de disponibilité de tests physiologiques effectués sur la base . . . . . . . . . . . . . . . . . . . . . . . . 94 4.1.4 Comparaison des bases de données évoquées dans le chapitre précédent avec nos critères . . . . . . . . . . . . . . . . . . . . 95 4.2 Nouvelle base pour l’étude de l’impact émotionnel : SENSE . . . . . . 97 4.3 Évaluations subjectives de notre base d’images . . . . . . . . . . . . . 98 4.3.1 Évaluations SENSE1 . . . . . . . . . . . . . . . . . . . . . . . 100 4.3.2 Évaluations SENSE2 . . . . . . . . . . . . . . . . . . . . . . . 102 4.3.3 Récapitulatif de la base SENSE à partir des critères proposés . 105 ivTable des matières 4.4 Évaluation de descripteurs bas-niveau pour la reconnaissance de l’impact émotionnel d’une image . . . . . . . . . . . . . . . . . . . . . . . 107 4.4.1 Descripteurs globaux . . . . . . . . . . . . . . . . . . . . . . . 107 4.4.2 Descripteurs locaux . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4.3 Protocole expérimental . . . . . . . . . . . . . . . . . . . . . . 110 4.4.4 Étude de l’impact du dictionnaire visuel . . . . . . . . . . . . 111 4.4.5 Évaluation de l’impact de la signature visuelle . . . . . . . . . 114 4.4.6 Récapitulatif des premiers résultats . . . . . . . . . . . . . . . 116 4.4.7 Présentation de nos résultats . . . . . . . . . . . . . . . . . . . 117 4.4.8 Comparaison de nos résultats avec la littérature . . . . . . . . 120 4.5 Prise en compte de la saillance visuelle . . . . . . . . . . . . . . . . . 121 4.5.1 Sélection dense des caractéristiques locales . . . . . . . . . . . 122 4.5.2 Classification des images de SENSE2 . . . . . . . . . . . . . . 123 4.6 Récapitulatif des différents résultats de l’évaluation des descripteurs de recherche d’images par le contenu . . . . . . . . . . . . . . . . . . 125 Conclusion générale et perspectives 131 A Calcul des CMI 137 Annexes 137 B Couleurs utilisées pour l’étude des émotions de couleurs 139 C Influence du genre sur l’évaluation de l’impact émotionnel des images de la base SENSE 143 D Résultats des évaluations EEG sur quelques images de SENSE 147 E Configuration des ensembles d’apprentissage et de test des bases SENSE et IAPS 151 Références bibliographiques 172 Liste des publications 175 vTable des matières viTable des figures 1.1 Exemple d’images présentant des variations géométriques et/ou des changements de plan de photographie. . . . . . . . . . . . . . . . . . 10 1.2 Principe de la différence de gaussiennes. . . . . . . . . . . . . . . . . 14 1.3 Voisinage du noyau considéré pour déterminer la caractéristique locale avec les algorithmes SUSAN et FAST. . . . . . . . . . . . . . . . . . 15 1.4 Illustration des caractéristiques locales détectées par les différents dé- tecteurs présentés dans cette sous-section. . . . . . . . . . . . . . . . 16 1.5 Différentes étapes de la description d’un point clé avec l’algorithme SIFT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.6 Illustration de la création de la signature visuelle d’une image à partir de ses descripteurs et d’un vocabulaire visuel. . . . . . . . . . . . . . 21 1.7 Exemple de quantification en 2D. . . . . . . . . . . . . . . . . . . . . 22 1.8 Illustration des différentes hypothèses de l’algorithme GMM. . . . . . 23 1.9 Illustration de la mise en œuvre de l’algorithme BoVW. . . . . . . . . 24 1.10 Illustration de la pyramide spatiale proposée par Lazebnik et al. . . . 27 1.11 Illustration de la structure de l’œil. . . . . . . . . . . . . . . . . . . . 29 1.12 Structure de la rétine. . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.13 La distribution des réponses rétiniennes au niveau du cortex. . . . . . 31 1.14 Différentes aires visuelles corticales. . . . . . . . . . . . . . . . . . . . 31 1.15 Traitement des informations provenant du cortex visuel primaire selon la modélisation de deux voies dorsale et ventrale . . . . . . . . . . . . 32 1.16 Architecture du modèle de saillance de Itti et Koch. . . . . . . . . . . 36 1.17 Exemple de carte de saillance. . . . . . . . . . . . . . . . . . . . . . . 37 2.1 Exemple de 4 images similaires de la base UKB. . . . . . . . . . . . . 41 2.2 Quelques images de la base Pascal VOC2012. . . . . . . . . . . . . . 41 2.3 Illustration d’une carte de saillance. . . . . . . . . . . . . . . . . . . . 43 2.4 Sélection aléatoire des mots visuels vs K-means. . . . . . . . . . . . . 45 2.5 Construction du dictionnaire final de façon itérative en partant de plusieurs dictionnaires visuels de 2048 mots choisis de façon aléatoire. 46 2.6 Étude de l’impact de la taille du dictionnaire visuel aléatoire initial. . 47 2.7 Score moyen obtenu après la combinaison des dictionnaires dans plusieurs configurations : β = {2, . . . , 9 , 10}. . . . . . . . . . . . . . . . . 48 2.8 Score moyen obtenu avec des dictionnaires finaux de plusieurs tailles générés à partir d’un dictionnaire de taille 4096. . . . . . . . . . . . . 50 viiTable des figures 2.9 Impact de la normalisation sur le score moyen. . . . . . . . . . . . . . 52 2.10 Étude du rang des images ressemblantes en pondérant les vecteurs de descripteurs par la saillance du point décrit. . . . . . . . . . . . . . . 54 2.11 Illustration du test de quelques seuils de saillance sur l’image. . . . . 56 2.12 Répartition des valeurs de saillance visuelle des images des 4 bases choisies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.13 Pourcentage des pixels ayant une saillance visuelle ≥ 0.4. . . . . . . . 58 2.14 Exemple d’une image par base pour illustrer la non corrélation entre le nombre de pixels ayant une saillance ≥ 0.4 dans l’image et celui de caractéristiques locales. . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.15 Illustration de la répartition des points clés saillants des 4 bases choisies. 60 2.16 Impact de la suppression des points clés en fonction de leur saillance. 63 2.17 Étude de la dépendance des résultats de l’importance des caracté- ristiques locales saillantes de la méthode de détection des caractéristiques : détection dense. . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.18 Remplacement des points détectés les moins saillants par les points les plus saillants issus de la détection dense. . . . . . . . . . . . . . . 65 3.1 Circumplex de Plutchik. . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.2 Circumplex de Russell. . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.3 Illustration des bases d’images de Machajdik et Hanbury. . . . . . . . 84 3.4 SAM utilisé durant les évaluations de IAPS. . . . . . . . . . . . . . . 85 3.5 Différentes classes reconstituées par Liu et al. pour l’évaluation de leur approche sur IAPS. . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.1 Quelques images de SENSE. . . . . . . . . . . . . . . . . . . . . . . . 97 4.2 Application de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.3 "Imagettes" correspondant aux images 4.1(a)-4.1(c) évaluées pendant SENSE2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.4 Illustration de l’hétérogénéité des expérimentations SENSE1. . . . . . 101 4.5 Résultats des évaluations SENSE1 selon les 3 classes d’émotions. . . . 101 4.6 Architecture du modèle d’attention visuelle de Perreira Da Silva et al. 103 4.7 Taux de bonne classification au cours de SENSE2 en fonction de la taille des régions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.8 Taux de classification moyen des images durant SENSE2. . . . . . . . 104 4.9 Exemple de casque utilisé pour récupérer le signal EEG. . . . . . . . 106 4.10 Positionnement des électrodes dans le système international 10-20. . . 106 4.11 Illustration de la segmentation en région couleurs. . . . . . . . . . . . 108 4.12 Partition spectrale des images de coefficients des transformées en ondelettes et en Wave Atoms . . . . . . . . . . . . . . . . . . . . . . . . 109 4.13 Illustration de la décomposition en Wave Atoms sur une image synthétique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.14 Taux de classification moyens pour SENSE1 et IAPS. . . . . . . . . . 112 4.15 Taux de bonne classification dans chacune des classes d’émotions pour chaque descripteur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.16 Taux de classification moyens pour les bases SENSE1 et IAPS. . . . . 115 4.17 Taux de bonne classification dans chaque classe d’émotions. . . . . . 116 viiiTable des figures 4.18 Résultats de l’étude de l’impact de la sélection des caractéristiques locales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.19 Taux de classification moyens obtenus sur SENSE2 et SENSE1. . . . 123 4.20 Taux de classification moyens pour les descripteurs locaux obtenus sur SENSE2 et SENSE1. . . . . . . . . . . . . . . . . . . . . . . . . . 124 4.21 Résumé de l’approche que nous avons utilisée pour la reconnaissance de l’impact émotionnel des images. . . . . . . . . . . . . . . . . . . . 125 B.1 Système colorimétrique de Munsell. . . . . . . . . . . . . . . . . . . . 140 C.1 Répartition des désaccords entre hommes et femmes lors de l’évaluation de l’impact émotionnel sur notre base. . . . . . . . . . . . . . . . 145 ixTable des figures xListe des tableaux 1 Liste des notations utilisées. . . . . . . . . . . . . . . . . . . . . . . . xiii 2 Liste des acronymes utilisés. . . . . . . . . . . . . . . . . . . . . . . . xiv 1.1 Comparaison des temps de calcul des détecteurs Harris, SUSAN et FAST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1 Scores moyens sur UKB. . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.2 Comparaison de notre meilleur score moyen avec quelques uns de la littérature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1 Comparaison des bases d’images de Machajdik et al. et IAPS. . . . . 96 4.2 Description de SENSE avec les critères proposés dans la Section 4.1. . 105 4.3 Matrice de confusion des couleurs IAPS_I . . . . . . . . . . . . . . . 114 4.4 Matrice de confusion des couleurs IAPS_S . . . . . . . . . . . . . . . 114 4.5 Taux moyens des classifications pour chaque descripteur. . . . . . . . 118 4.6 Comparaison des taux de classification avant et après une fusion MV. 119 B.1 Différentes couleurs évaluées au cours des expérimentations de Kaya et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 B.2 Différentes couleurs évaluées au cours des expérimentations de Ou et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 C.1 Nombre d’images dans chaque classe d’émotions en fonction du genre. 144 C.2 Différentes couleurs moyennes au sein des désaccords entre genre relevés sur notre base. . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 D.1 Corrélation entre les différentes sessions de tests dans la première configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 D.2 Corrélation entre les différentes sessions de tests dans la seconde confi- guration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 D.3 Corrélation entre la réponse SSVEP et la luminance. . . . . . . . . . 149 E.1 Nombre d’images dans les ensembles d’apprentissage et de test. . . . 151 xiListe des tableaux xiiNotations et acronymes Tableau 1: Liste des notations utilisées. Notation Signification I Image en niveaux de gris ou composante d’un plan couleur (x,y) Coordonnées d’un pixel en 2D det(M) Déterminant de la matrice M trace(M) Trace de la matrice M Ω Une région de l’image D Un ensemble de descripteurs de caractéristiques locales K Taille du dictionnaire visuel NI Nombre de caractéristiques locales par image NB Nombre de caractéristiques locales dans une base d’images NS Taille d’une suite binaire ND Taille d’un descripteur (Dimensionnalité) N Nombre d’images dans la base W Dictionnaire visuel d L2 A,B Distance euclidienne entre deux vecteurs A et B d Hamming A,B Distance de Hamming entre deux suites binaires A et B d χ 2 A,B Distance de χ 2 entre deux vecteurs A et B xiiiNotations et acronymes Tableau 2: Liste des acronymes utilisés. Acronyme Signification ACP Analyse en Composantes Principales BoVW Bag of Visuals Words (Sac de mots visuels) CBIR Content Based Image Retrival CM Colour Moments CMI Colour Moment Invariants DoG Difference of Gaussians EEG Électro-encéphalographie EM Expectation-Maximisation FAST Features From Accelerated Segment Test FV Fisher Vector (Vecteur de Fisher) GLOH Gradient Location and Orientation Histogram GMM Gaussian Mixture Model IA Intelligence Artificielle IAPS International Affective Picture System IG Information Gain (Gain d’information) KNN K Near Neighbours (K plus proches voisins) KP Keypoint (Point clé ou plus généralement une caractéristique locale) LoG Laplacian of Gaussian MSER Maximally Stable Extremal Regions MV Majoriting Voting NdG Niveau de gris OpSIFT Opponent-SIFT SENSE Studies of Emotions on Natural image DatabaSE SIFT Scale-Invariant Feature Transform SSVEP Steady-State Visually Evoked Potential SURF Speeded Up Robust Feature SUSAN Smallest Univalue Segment Assimiliating Nucleus SVH Système Visuel Humain SVM Support Vector Machine tf-idf term frequency-inverse document frequency UKB University of Kentucky Benchmark (Base d’images) VLAD Vector of Loccally Aggregated Descriptors WA Transformée en Wave Atoms WA4 Échelle 4 de la transformée en Wave Atoms WA5 Échelle 5 de la transformée en Wave Atoms xivIntroduction générale L’idée de doter des machines d’"intelligence" fut évoquée pour la première fois par Turing [Turing 50] en 1950. Depuis, plusieurs travaux de recherche prometteurs ont été menés avec des résultats très encourageants. Par exemple, l’intelligence artificielle (IA) a été utilisée durant la guerre du Golfe, pour améliorer les systèmes d’aide à la décision et les systèmes autonomes tels que les drones [His ]. Mais un évé- nement en particulier a marqué les esprits : la victoire en 1996 du "super-ordinateur" Deep Blue de IBM aux échecs face à Garry Kasparov, alors champion du monde. La performance a été qualifiée d’inédite. On découvre alors qu’une IA peut être plus performante que l’homme dans certains domaines précis. Depuis les recherches continuent et des solutions de plus en plus intelligentes sont proposées dans de différentes branches : la reconnaissance de formes, la vision par ordinateur, . . . . Aujourd’hui certains appareils photo sont capables de se déclencher dès que le sujet sourit. Ceci est rendu possible grâce à un logiciel embarqué de détection de visages. Nous pourrions citer d’autres exemples d’applications mais la branche qui nous intéresse le plus particulièrement dans cette thèse est la vision par ordinateur. Elle apporte des solutions en robotique, en système d’aide au diagnostic ou en recherche d’images, en tentant d’imiter la vision humaine ou animale. Malgré des résultats très encourageants, certains aspects lui résistent encore. Il s’agit des aspects de notre système de vision qui sont couplés à des processus cognitifs. La reconnaissance des émotions en est un exemple. C’est à cette tâche que nous nous sommes intéressés au cours de nos travaux de recherche. S’intéresser à la reconnaissance des émotions est loin d’être une tâche facile. En effet, les émotions sont des réactions complexes qui engagent à la fois le corps et l’esprit. Il faut ensuite se confronter à une littérature hétéroclite, de la définition de la notion d’émotion, aux solutions, en passant par les bases d’images. Une proposition de définition consensuelle a été proposée, en 2013 seulement, par David Sander [Sander 13]. Il définit alors l’émotion comme un phénomène rapide, déclenché par un événement. Le défi des solutions de reconnaissance de l’impact émotionnel des images est alors de trouver les caractéristiques de ces dernières qui déclenchent l’émotion. Plusieurs travaux ont été menés dans cette direction. Une première partie de la littérature est consacrée aux relations entre les émotions et les couleurs. Dans ces travaux l’émotion associée à une couleur [Beresniak 90, Boyatziz 93, Kaya 04, Ou 04a, Ou 04b, Ou 04c] ainsi qu’à des combinaisons de plusieurs couleurs [Ou 06, Solli 09, Ou 11] a été étudiée. Une autre partie a été consacrée à la reconnaissance des émotions à partir : 1Introduction générale – De la détection de visages [Tomkims 62, Scherer 84, Ekman 92, De Silva 97, Busso 04] associant alors une émotion à des traits du visage (sourcils, lèvres entre autres) ; – De la description sémantique des couleurs [Wang 05, Hong 06] ; – Des caractéristiques bas-niveau (couleurs, texture, formes, . . . ) des images [Yanulevskaya 08, Solli 10, Machajdik 10, Liu 11a]. Nous avons choisi d’inscrire nos travaux dans la famille des approches basées sur l’extraction de caractéristiques bas niveau, l’idéal étant qu’un ensemble d’entre elles soit suffisamment discriminant. Cette notion cependant dépend également des bases d’images. Les résultats de Machajdik et Hanbury [Machajdik 10] montrent que les couleurs sont très déterminantes pour la reconnaissance des émotions des images abstraites. Les descripteurs que nous avons retenus sont des caractéristiques de couleurs, textures, formes, objets. Ils sont, pour la plupart, traditionnellement utilisés en indexation. C’est d’ailleurs cette tâche de vision par ordinateur qui a inspiré nos travaux d’où la première partie ce manuscrit. Recherche d’images par le contenu L’idée est de retrouver des images partageant un contenu qui peut être associé à différentes caractéristiques. On peut rechercher des images à partir d’une couleur globale, d’une texture ou plus généralement des objets qu’elles contiennent. Les solutions doivent être le plus souvent robustes aux transformations géométriques et aux modifications des conditions d’éclairage et de prise de vue. On décrit alors les images à partir d’un ensemble de caractéristiques qui peuvent être locales (variations de la géométrie locale par exemple) [Harris 88, Lowe 99, Mikolajczyk 01, Matas 02] ou globales (couleurs) [Swain 91, Oliva 01, Hays 07, Li 08, Douze 09]. Ces dernières peuvent être directement mises en correspondance ou utilisées pour créer des signatures visuelles [Sivic 03, Perronnin 07, Jégou 10b]. La littérature sur le sujet est assez diversifiée et de nouvelles solutions sont fréquemment proposées notamment en termes de descripteurs, de méthodes de recherche des signatures visuelles pour s’adapter aux exigences des bases d’images de plus en plus grandes. Le domaine est également très actif proposant régulièrement des challenges pour évaluer les différentes solutions. Parmi les challenges les plus connus et qui se renouvellent souvent, on peut citer PASCAL Visual Object Classes challenge. Il est constitué de plusieurs bases d’images, fonction des années, Pascal VOC2007 [Everingham 07] et Pascal VOC2012 [Everingham 12] par exemple. Chacune de ces bases est divisée en ensembles d’apprentissage, de test et d’objets segmentés. En fonction de la tâche choisie, catégorisation ou segmentation en objets d’intérêt, on peut évaluer les ré- sultats de son système et se comparer efficacement à l’état de l’art. On ne peut pas parler de recherche d’images par le contenu sans évoquer le descripteur phare de ce domaine proposé par David G. Lowe en 1999 [Lowe 99] : SIFT (Scale-Invariant Feature Transform). C’est un descripteur de 128 dimensions dont la robustesse à plusieurs variations (translation, changement d’échelle, rotation) en fait l’un des descripteurs les plus utilisés et efficaces de la littérature [Lowe 99, Lowe 04, Ke 04, Nistér 06, van de Sande 10, Jégou 10b, Jégou 11]. Tout comme SIFT, une méthode de création de signature visuelle est très plébis- 2Introduction générale citée dans la littérature : la technique "Bag of Visual Words" (BoVW) ou "Sac de mots visuels". L’idée de cette solution, proposée, dans un premier temps, par Sivic et Zisserman [Sivic 03], est de s’inspirer de la méthode "Sac de mots" utilisée en catégorisation de texte, pour créer une signature visuelle pour la recherche d’images et de vidéos. Pour ce faire, on crée d’abord un dictionnaire visuel. On construit ensuite un histogramme des occurrences des mots de ce dernier dans chaque image. La toute première solution apportée dans ce manuscrit concerne la construction du vocabulaire visuel, souvent réalisée à partir d’un algorithme K-means. Ce dernier est sensible à la dimensionnalité : ses résultats tendent à baisser avec une dimensionnalité élévée, produisant même des résultats proches de l’aléatoire comme l’indiquent Parsons et al. [Parsons 04]. Nous proposons alors une construction du dictionnaire qui n’est pas sensible à ces problèmes de dimensionnalité combinant une sélection aléatoire des mots visuels à un processus itératif. Nos travaux ont été menés essentiellement sur les bases University of Kentucky Benchmark [Nistér 06] et Pascal VOC2012 [Everingham 12]. Nous avons utilisé la seconde pour construire nos mots visuels et la première pour tester notre approche. Reconnaissance de l’impact émotionnel des images Notre réflexion s’inspire de la recherche d’images par le contenu. Nous avons émis l’hypothèse que les descripteurs existants pourraient être utiles et tout aussi performants pour la reconnaissance des émotions. Dans ces travaux nous avons donc évalué leur pertinence pour la tâche en les comparant aux résultats de la littérature. Nous proposons également une nouvelle base d’images pour l’étude de l’impact émotionnel en nous inspirant des insuffisances de la littérature évoquées par Machajdik et Hanbury [Machajdik 10]. En effet, l’une des problématiques récurrentes concerne les bases d’images et leur évaluation. La plupart des auteurs construisent de nouvelles bases pour leurs travaux mais ne les publient pas ou ne donnent aucune information concernant les conditions d’évaluation. Une base apparaît néanmoins comme étant un consensus d’évaluation des solutions de recherche d’images basée émotion : IAPS [Lang 08]. C’est une base très bien évaluée mais qui présente quelques restrictions en termes d’utilisation nous obligeant à construire notre propre base d’images, entre autres pour étudier l’apport de la saillance visuelle. Ce phénomène de sélection de notre système visuel pourrait en effet permettre de réduire l’interprétation sémantique au cours des évaluations subjectives, par exemple en réduisant la taille de la zone observée à la région saillante. Ceci est impossible à faire avec les images de IAPS à cause des clauses d’utilisation. Plan Ce document est divisé en deux parties : une première sur la recherche d’images par le contenu et la seconde sur la reconnaissance de l’impact émotionnel des images. Dans le Chapitre 1, nous présentons quelques solutions de la littérature pour la recherche d’images par le contenu et nous finissons par une brève présentation de la saillance visuelle. Il ne s’agit pas d’un état de l’art exhaustif mais axé sur les travaux qui ont constitué le point de départ à notre réflexion. Une nouvelle méthode de construction du vocabulaire visuel est présentée et discutée dans le Chapitre 2. 3Introduction générale Toujours dans ce même chapitre, nous avons évalué l’importance des caractéristiques locales en fonction de leur valeur de saillance visuelle. Cette étude conclut la première partie de ce manuscrit. Dans la seconde partie, le Chapitre 3 est consacré à l’état de l’art sur la reconnaissance des émotions. Dans le dernier chapitre, nous proposons d’abord une taxonomie de comparaison des bases d’images avant de présenter notre base d’images et ses différentes évaluations subjectives. Nous avons ensuite comparé notre approche basée sur une architecture de recherche d’images par le contenu avec les résultats de la littérature. 4Première partie Recherche d’images par le contenuIntroduction Partie 1 De tous les progrès accomplis en informatique, il y en a un qui a particulièrement révolutionné notre façon de travailler : le stockage. De la première carte perforée de IBM en 1928 1 , aux supports de stockage actuels (les clés USB, les cartes mémoires, . . . ) en passant par les disques durs, les disquettes, les CD, des avancées notoires ont été constatées. Dieny et Ebels [Dieny 08] les évoquent également en affirmant que depuis le premier disque dur en 1956 2 , la capacité de stockage de ces disques n’a cessé de croître à un rythme moyen de 45% par an, conduisant en un demi-siècle à une augmentation de la densité de stockage de 8 ordres de grandeur. Ceci a entre autres contribué à l’explosion des bases multimédia. Les réseaux sociaux de partage de contenus multimédia se multiplient et la nécessité d’avoir des solutions de plus en plus intelligentes s’impose. Prenons l’exemple de deux réseaux de partage de photos phare, Flickr et Google+ dont les capacités de stockage sont impressionnantes : – Sur Flickr, en 2013, 586 millions d’images publiques ont été mises en ligne contre 518 millions en 2012 3 ; – Pas moins de 1.5 milliards de photos sont mises en ligne chaque semaine sur Google+ par les 300 millions d’utilisateurs actifs 4 . La reconnaissance d’images par le contenu appelée en anglais CBIR (Content Based Image Retrieval) se retrouve donc au cœur des besoins des moteurs de recherche et offrirait des solutions de choix pour les utilisateurs. Pour citer un exemple de solution très attractive, Google+ propose à ses utilisateurs des images animées de type "GIF" construites à partir d’un ensemble d’images représentant la même scène. Ce genre d’applications intéresse bien évidemment les abonnés qui n’y voient que des avantages. Nous ne visons pas ce type d’applications dans ces travaux qui cependant illustrent bien le potentiel d’un système de recherche d’images. Si nous nous en tenons à un système de reconnaissance d’images dit "basique" 5 , parmi les solutions "grand public" existantes, la plus connue est le moteur de recherche d’images de Google. D’autres moteurs de recherche d’images beaucoup moins connus mais tout aussi efficaces existent. Il s’agit, par exemple, de Bigimbaz 6 mis en place par les chercheurs Jégou et al. [Jégou 10a]. 1. La carte perforée 80 colonnes de IBM standardisée pour l’informatique 2. IBM 350 3. https://secure.flickr.com/photos/franckmichel/6855169886/in/photostream/ 4. http://www.techhive.com/article/2058687/google-wants-you-and-your-photos-to-never-ever-leave.html 5. Nous appelons ainsi tous les systèmes qui retrouvent un ensemble d’images ayant un ou plusieurs critères bas-niveau en commun 6. http://bigimbaz.inrialpes.fr/demo/ 7Introduction Partie 1 Les solutions existantes sont constamment améliorées pour s’adapter aux différents supports d’affichage et de travail. Les performances de ces systèmes d’indexation sont alors variées puisqu’ils ne répondent pas aux mêmes exigences : – Ceux qui ont des contraintes de rapidité ou des limites en termes de mémoire (par exemple, les applications sur les mobiles) se contenteront d’une solution algorithmique légère et peut-être un peu moins précise mais acceptable ; – Ceux qui ont des objectifs de précision (le cas de Bigimbaz) pourront s’octroyer des délais de réponses plus longs certes mais acceptables. Avec ces différentes applications en constante amélioration, on assiste à un domaine en perpétuelle évolution. Ceci explique le grand nombre de stratégies de travail proposées dans la littérature. De ce fait, nous ne proposerons pas un état de l’art exhaustif. Il sera axé sur les propositions qui ont constitué un point de départ à nos travaux. Cette partie comportera deux chapitres : – Un premier qui présentera quelques solutions à la problématique de recherche d’images par le contenu ; – Un second dans lequel nous exposerons nos axes d’amélioration de certaines solutions existantes. 8Chapitre 1 Solutions de recherche d’images par le contenu Sommaire 1.1 Descripteurs d’images . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Exemples de caractéristiques globales . . . . . . . . . . . 11 1.1.2 Caractérisation locale : l’alternative aux insuffisances des descripteurs globaux . . . . . . . . . . . . . . . . . . . . . 11 1.2 Recherche des images les plus ressemblantes . . . . . . . 20 1.2.1 Création du dictionnaire de mots visuels . . . . . . . . . . 21 1.2.2 Quelques méthodes de création de la signature visuelle d’une image . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.3 Recherche des images similaires à partir de leurs signatures visuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3 Saillance visuelle . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1 Qu’est-ce que l’attention visuelle ? . . . . . . . . . . . . . 28 1.3.2 Différents modèles de saillance visuelle . . . . . . . . . . . 34 1.3.3 Modèle de saillance de Itti et Koch . . . . . . . . . . . . . 35 1.3.4 Évaluation des modèles de saillance visuelle . . . . . . . . 37 1.4 Quelques travaux intégrant la saillance visuelle en recherche d’images par le contenu . . . . . . . . . . . . . . . 38 Introduction Une tâche d’indexation se décompose généralement en deux étapes : 1. Transformer l’image en matrice de valeurs : l’image est alors représentée par un ensemble de valeurs susceptibles d’être le plus robustes possible aux transformations géométriques, de point de vue entre autres ; 2. Comparer les matrices de représentation des images. Dans ce chapitre nous évoquerons quelques solutions de la littérature concernant ces deux étapes dans un système de recherche d’images par le contenu. 9Chapitre 1. Solutions de recherche d’images par le contenu 1.1 Descripteurs d’images Dans l’idéal les descripteurs doivent être robustes à un ensemble de variations notamment : – Les transformations géométriques de type rotation, translation, etc ; – Les changements de point de vue ; – Les changements d’échelle. Quelques-unes de ces variations sont illustrées sur la Figure 1.1. La robustesse à un changement de plan ou à toute modification de couleur est le plus souvent très complexes à obtenir. En effet, un changement de plan peut entraîner une occlu- (a) (b) (c) (d) (e) (f) Figure 1.1: Exemple d’images présentant des variations géométriques et/ou des changements de plan de photographie. Ces images sont issues de la base proposée par Nistér et al. [Nistér 06]. L’image 1.1(e) illustre l’occlusion des autres chiffres induite par le changement d’angle de prise de vue. sion, induisant ainsi un objet (une scène) incomplet (incomplète) comme on peut le voir sur l’image 1.1(e). D’ailleurs, sur cette même illustration, on peut constater un changement de luminosité. Le phénomène de "cropping" illustré sur la figure 1.1(f) peut être le résultat d’un changement d’échelle ou de point de vue. Malgré leur complexité, toutes ces variations doivent être au mieux intégrées dans la représentation des images afin que la tâche d’indexation exécutée par l’ordinateur se rapproche au mieux des vérités terrains proposées par l’humain. Deux types de solutions sont proposées dans la littérature pour la description des images : – Les descripteurs globaux qui permettent de définir la scène dans sa géné- ralité. Ils sont la plupart du temps relatifs à des informations de type couleurs, textures ; – Les descripteurs locaux qui décrivent le comportement local d’un point ou d’une région. Ces attributs peuvent être relatifs à la couleur, à la texture, à la géométrie ou à une combinaison de ces informations bas niveau. 10Chapitre 1. Solutions de recherche d’images par le contenu 1.1.1 Exemples de caractéristiques globales Plusieurs solutions ont été proposées en matière de description globale des images. La première solution et la plus répandue est l’utilisation des histogrammes "couleur" introduit par Swain et Ballard en 1991 [Swain 91]. Ils proposent d’utiliser une méthode de mise en correspondance nommée "intersection d’histogrammes". Cette dernière informe sur le nombre de pixels de l’histogramme de l’image requête qui sont présents dans l’image en cours d’analyse. Leur méthode est robuste à de nombreuses transformations qui induisent, la plupart du temps, en erreur les systèmes de recherche d’images par le contenu telles que : – Les "distractions" dans le fond de l’objet ; – Les changements des angles de prise de vue ; – Les occlusions ; – Les changements de résolution de l’image. Les résultats qu’ils obtiennent sont intéressants surtout pour des images dont les couleurs sont très discriminantes. Une autre représentation globale de l’image qui a obtenu de très bons résultats dans la littérature est le descripteur "GIST". Il a été introduit par Oliva et Torralba en 2001 [Oliva 01]. Il permet de représenter la structure dominante spatiale de la scène à partir d’un ensemble de dimensions perceptives (la naturalité de la scène, son ouverture, sa rugosité, son expansion et sa robustesse). Ces 5 dimensions "perceptives" ne sont pas calculées mais plutôt estimées à partir des informations spectrales et des informations grossièrement localisées. La première étape de l’algorithme est d’opérer un filtrage sur les images avec un banc de filtre de Gabor. Ensuite, des histogrammes d’orientations sont calculés sur des imagettes (régions locales) de dimensions paramétrables afin d’obtenir le descripteur final. Le descripteur GIST a été largement utilisé dans la littérature donnant des résultats satisfaisants [Hays 07, Li 08, Douze 09]. Malgré ces résultats ce descripteur n’est robuste qu’à très peu de variations. Il présente des limites face à une translation par exemple. Les descripteurs globaux donnés en exemple ci-dessus permettent d’obtenir des résultats intéressants dans la littérature. Ils présentent néanmoins des limitations majeures qui expliquent l’utilisation massive des descripteurs locaux. Se baser uniquement sur des informations globales ne permet pas toujours de distinguer le fond de l’objet, de gérer les problèmes d’occlusion, de "cropping", etc . . . 1.1.2 Caractérisation locale : l’alternative aux insuffisances des descripteurs globaux Contrairement aux descripteurs précédents, ces descripteurs s’intéressent aux structures locales. L’objectif est de capturer toutes les particularités locales afin d’augmenter la robustesse aux différentes transformations évoquées précédemment. Il faut, dans un premier temps, détecter les structures locales et ensuite les décrire. Notons quand même qu’on retrouve de plus en plus dans la littérature des solutions utilisant une détection dense [Perronnin 08, Gordoa 12]. Dans ce cas, tous ou qua- 11Chapitre 1. Solutions de recherche d’images par le contenu siment tous les pixels (choisis à l’aide d’une fenêtre) sont décrits afin de capturer beaucoup plus de variations. Nous n’aborderons pas ces propositions. Il n’y a pas de convention et les schémas d’échantillonnage dépendent essentiellement des applications (recherche dans de très grandes bases d’images, reconnaissance et classification d’objets, . . . ). Détection des caractéristiques locales Nous présenterons ici une sélection non exhaustive de détecteurs locaux. Le lecteur intéressé pourrait se référer au travail de Tuytelaars et al. [Tuytelaars 08], publié en 2008, pour plus de détails. La détection des caractéristiques locales est souvent la première étape de nombreux systèmes de vision par ordinateur, par exemple, pour du suivi ou de la reconnaissance d’objets. L’idée est de pouvoir détecter les mêmes régions/points après des transformations, comme un changement de perspective, une translation, une rotation ou encore un changement d’éclairage. Ceci est primordial pour avoir des résultats satisfaisants et proches de ceux de l’être humain. Cette propriété de robustesse leur confère d’être abusivement traitées d’invariantes comme le soulignent Mikolajczyk et al. [Mikolajczyk 05b]. Ils estiment que ces régions devraient être justement qualifiées de "covariantes". Elles devraient changer de façon covariante en fonction des différentes transformations. Les détecteurs de caractéristiques locales peuvent être classés de plusieurs manières. Schmid et al. [Schmid 00] proposent, par exemple, une catégorisation en 3 groupes contre une version plus détaillée en 8 groupes pour Tuytelaars et Mikolajczyk [Tuytelaars 08]. Nous utiliserons dans ce manuscrit la classification compacte en trois familles 1 : – Les méthodes "basées contour" qui extraient dans un premier temps des contours. À partir de ceux-ci, une recherche de la courbure maximale ou des points d’inflexion est faite pour détecter les caractéristiques locales. La recherche des points d’inflexion ou de courbure maximale peut être remplacée par une approximation polygonale. Les caractéristiques locales correspondent dans ce cas aux différents points d’intersection ; – Les méthodes "basées intensité" qui utilisent une mesure basée sur le niveau de gris du pixel pour indiquer si oui ou non on est en présence d’une caractéristique locale. La plupart des détecteurs que nous aborderons dans cette partie sont dans cette catégorie ; – Les méthodes de modèle paramétrique qui adaptent un modèle paramé- trique d’intensité au signal. Quelle que soit la famille des méthodes, les détecteurs peuvent être classés en trois groupes : – Les détecteurs de coins qui détectent les points possédant une courbure élevée dans une image 2D. Les coins se trouvent par exemple à différents types de jonctions, sur des surfaces très texturées ; – Les détecteurs de blobs qui produisent des ensembles cohérents de pixels ayant des propriétés constantes. Tous les pixels d’un blob peuvent être consi- 1. Les que nous avons testés entre dans l’une des 3 familles. 12Chapitre 1. Solutions de recherche d’images par le contenu dérés comme étant semblables les uns aux autres ; – Les détecteurs de régions qui sont basés directement ou indirectement sur des extractions de régions. Les caractéristiques locales doivent répondre à un ensemble de contraintes qui dé- pendent des besoins de l’application. Tuytelaars et Mikolajczyk [Tuytelaars 08] dé- crivent un ensemble de propriétés qu’elles doivent posséder dans l’idéal : – La répétabilité : si on prend deux images de la même scène prises dans des conditions de vue différentes, elles doivent partager un nombre important de caractéristiques détectées dans la partie commune de la scène ; – Le caractère distinctif/informatif : il est lié à la description de la caractéristique. Les modèles à l’origine des caractéristiques détectées doivent intégrer beaucoup de variations permettant ainsi de les distinguer et de les mettre en correspondance ; – La localité : pour réduire les probabilités d’occlusions et pour être robuste aux variations, les caractéristiques doivent être les plus locales possibles ; – La quantité : il faut un nombre de caractéristiques suffisant. Elles doivent refléter l’information contenue dans l’image afin d’en avoir une représentation compacte ; – La précision : plusieurs méthodes ont été proposées dans la littérature pour évaluer la précision locale des caractéristiques. Ces dernières doivent être localement précises aussi bien au regard de la position dans l’image qu’en respectant l’échelle et la forme si possible ; – L’efficacité : la détection des caractéristiques locales doit être adaptée aux applications critiques en temps. Cette liste de propriétés des caractéristiques locales n’est pas exhaustive. L’importance de ces propriétés dépend des applications. Si on considère par exemple l’efficacité, elle est intrinsèquement liée aux exigences de l’application et pourrait conditionner les autres. La précision quant à elle sera indispensable dans des applications de mise en correspondance de caractéristiques sur de grandes bases d’images. Tous les détecteurs que nous évoquerons par la suite ont été définis à la base pour des images en niveaux de gris. Ces dernières peuvent correspondre à l’image couleur convertie en niveaux de gris ou aux images de chaque composante couleur si on décide de faire des opérations marginales. Ceci implique que le terme "niveau de gris" que nous employons n’est rien d’autre que la valeur du pixel dans une représentation "uni-plan". L’un des détecteurs retrouvé le plus souvent dans la littérature est un détecteur de coins, proposé par Harris et Stephen en 1988 [Harris 88]. Ce détecteur comme beaucoup d’autres de la littérature [Tomasi 91, Förstner 94, Mikolajczyk 01] se base sur la matrice de la fonction d’auto-corrélation utilisée par Moravec en 1977 [Moravec 77]. En effet, Moravec a été le premier à développer un détecteur de caractéristiques locales basé sur le signal. Son détecteur s’appuie sur la fonction d’auto-corrélation. Il mesure les différences de niveaux de gris entre une fenêtre et des fenêtres glissantes changeant de directions. Harris et Stephen, dans leur amélioration du détecteur de Moravec, proposent d’utiliser la matrice d’auto-corrélation MHarris définie par 13Chapitre 1. Solutions de recherche d’images par le contenu l’équation (1.1), autour d’un pixel (x,y) dans une fenêtre F d’une image I. MHarris(x, y) =    P F Ix(xk, yk) 2 P F Ix(xk, yk)Iy(xk, yk) P F Ix(xk, yk)Iy(xk, yk) P F Iy(xk, yk) 2    , (1.1) où Ix correspond à la dérivée première suivant x et Iy la dérivée première suivant y. Les points ayant une grande valeur de C calculé avec l’équation (1.2) sont considérés comme étant des coins. C = det(MHarris) − k ∗ trace(MHarris) 2 (1.2) Ce détecteur est invariant à la rotation mais n’est pas très robuste aux changements d’échelle [Schmid 00]. En se basant sur le même principe que Harris et Stephen, Mikolajczyk et Schmid [Mikolajczyk 01] ont proposé un détecteur invariant à la rotation et aux changements d’échelle : le détecteur Harris-Laplace. Les points sont dans un premier temps détectés par une fonction de Harris sur plusieurs échelles. Ensuite, seuls ceux ayant une réponse maximale à la mesure locale (ici le laplacien) sont sélectionnés dans l’espace d’échelle. Lowe [Lowe 99], quant à lui, obtient l’invariance à l’échelle en convoluant l’image par un noyau issu de la différence des gaussiennes à plusieurs échelles. La Figure 1.2 illustre l’algorithme. Il a introduit en plus une pyramide spatiale avec plusieurs Figure 1.2: Principe de la différence de gaussiennes. niveaux appelés "octaves". D’une octave à une autre, l’image est sous-échantillonnée d’un facteur de 2. Cette méthode appelée DoG (Difference of Gaussians) est une approximation rapide de la méthode LoG (Laplacian of Gaussian) dont le noyau est particulièrement stable dans l’espace de l’échelle [Mikolajczyk 02]. La recherche des extrema locaux se fait dans un voisinage dont on définit la taille dans 3 échelles. Les extrema locaux permettent de détecter des structures de type blob. De ces trois détecteurs, Harris-Laplace a une meilleure répétabilité selon les travaux 14Chapitre 1. Solutions de recherche d’images par le contenu de Mikolajczyk et Schmid [Mikolajczyk 01] pour des scènes planes. Les détecteurs cités ci-dessus ne répondent pas toujours aux besoins des applications temps-réels ou avec des contraintes temporelles exigeantes. Des solutions ont donc été proposées parmi elles, le détecteur FAST (Features From Accelerated Segment Test) mis au point par Rosten et Drummond [Rosten 05, Rosten 06]. La version [Rosten 06] inclut l’utilisation de l’apprentissage pour rendre le détecteur plus rapide 2 . Ce détecteur se base sur le détecteur SUSAN (Smallest Univalue Segment Assimiliating Nucleus) introduit par Smith et Brady [Smith 97]. Pour chaque pixel de l’image, on considère un voisinage circulaire de rayon fixe. Le pixel central est appelé "noyau". Tous les pixels contenus dans le disque fermé ainsi défini, illustré sur la Figure 1.3(a), dont le niveau de gris se rapproche de celui du noyau sont affectés d’une grande pondération. Les pixels dans l’image, dont la valeur de niveau de gris correspond à un minimum local et est inférieure à un certain seuil sont désignés comme étant les caractéristiques locales. Elles correspondent en fait à des coins dans l’image. Le détecteur FAST reprend la même idée en ne considérant que les pixels sur le cercle. Le rayon du cercle est fixé à 4 et seulement les 16 voisins du noyau, définis suivant la Figure 1.3(b), sont traités. Le pixel central est désigné comme étant une caractéristique locale si au moins 12 pixels contigus ont des valeurs de niveau de gris inférieures à celle du noyau et à un certain seuil. Ce changement induit des gains en temps de calcul considérables comme le montre le Tableau 1.1. (a) SUSAN (b) FAST Figure 1.3: Voisinage du noyau considéré pour déterminer la caractéristique locale avec les algorithmes SUSAN (a) et FAST (b). Tous les détecteurs que nous avons décrits sont illustrés sur la Figure 1.4 dans les configurations suivantes : – Le détecteur de Harris (b) avec : k=0.06, le seuil de Harris est défini égal à 0.05 multiplié par la meilleure valeur de C calculée avec l’équation (1.2) et une taille de voisinage de 3x3. Ce détecteur a été calculé avec la librairie Opencv ; – Le détecteur Harris-Laplace (c) avec : k=0.06, le seuil de la fonction de Harris est égal à 10−9 et le seuil pour le laplacien est égal 0.03. Il a été obtenu avec 2. C’est d’ailleurs cette version qui est intégrée dans la bibliothèque Opencv que nous avons testée. 15Chapitre 1. Solutions de recherche d’images par le contenu Tableau 1.1: Comparaison des temps de calcul des détecteurs Harris, SUSAN et FAST. Les résultats présentés dans ce tableau sont ceux présentés dans [Rosten 05] pour une image de taille 768*288 pixels. Détecteurs FAST SUSAN Harris Temps (ms) 2.6 11.8 44 (a) Image originale (b) Harris : 47 points (c) Harris-Laplace : 914 points (d) DoG : 650 points (e) FAST : 759 points Figure 1.4: Illustration des caractéristiques locales détectées par les différents détecteurs présentés dans cette sous-section. le logiciel de van de Sande [van de Sande 10] ; – Le détecteur DoG (d) calculé avec la librairie Opencv à partir du détecteur du descripteur SIFT dans sa configuration par défaut ; – Le détecteur FAST (e) pour lequel le seuil de comparaison des niveaux de gris entre le "nucleus" et ses voisins fixé à 30. Il a été également calculé avec Opencv. On remarque que le nombre de caractéristiques locales varie d’un détecteur à l’autre en analysant les images de la Figure 1.4. Pour l’image 1.4(a) le détecteur qui propose le moins de caractéristiques locales est celui de Harris mais ceci ne généralise en rien la quantité de caractéristiques locales qu’il détecte. Ce comportement est avant tout lié au contenu de l’image. Comme nous l’avons dit en introduction à cette section, les détecteurs ne sont que la première étape d’une tâche de recherche d’images. L’étape suivante consiste à décrire les caractéristiques locales. Il existe dans la littérature un grand nombre de descripteurs répondant à des contraintes applicatives très différentes. Dans la section suivante, nous présenterons quelques-uns de ceux qui sont le plus souvent utilisés depuis une dizaine d’années environ en insistant sur ceux que nous avons retenus. 16Chapitre 1. Solutions de recherche d’images par le contenu Quelques descripteurs de caractéristiques locales Nous ne pouvons pas parler des descripteurs de caractéristiques locales utilisés en recherche d’images basée contenu sans évoquer le descripteur SIFT (Scale-Invariant Feature Transform). C’est l’un des descripteurs les plus utilisés dans la littérature [Lowe 99, Lowe 04, Ke 04, Nistér 06, van de Sande 10, Jégou 10b, Jégou 11] du fait de son efficacité. Il a été proposé par David G. Lowe en 1999 [Lowe 99] et répond à une bonne partie des contraintes d’une tâche de recherche d’images par le contenu évoquées précédemment. C’est un vecteur de caractéristiques locales qui décrit un pixel et qui est robuste : – À la translation ; – Au changement d’échelle ; – À la rotation ; – Aux changements d’éclairage ; – Aux projections affines ou 3D. Dans l’algorithme proposé par Lowe [Lowe 99] les caractéristiques locales sont dé- crites avec un détecteur de type DoG. Ensuite chaque caractéristique que nous appellerons "point clé" pour simplifier la lecture est décrite à l’aide d’un ensemble d’histogrammes des orientations comportant 8 intervalles. Pour ce faire, on définit une région de taille 16*16 autour du point clé. Cette région est ensuite divisée en 4 sous-régions de taille 4*4 dans lesquelles on calcule l’orientation et l’amplitude du gradient. À partir de ces informations on décrit le point par une concaténation de tous les histogrammes des 8 orientations du gradient dans chaque sous-région. L’histogramme de chaque sous-région de taille 4*4 est obtenu en faisant la somme des amplitudes du gradient en chaque point pondérée par une gaussienne centré sur le point clé, d’écart type égal à 1.5 fois le facteur d’échelle du point clé. L’orientation du gradient détermine l’intervalle à incrémenter dans l’histogramme. Toutes ces différentes étapes de l’algorithme de calcul du descripteur SIFT sont illustrées par la Figure 1.5. Le descripteur final est de taille 128=4*4*8. Figure 1.5: Différentes étapes de la description d’un point clé avec l’algorithme SIFT. Le point à décrire est représenté en rouge. Le cercle sur la figure du milieu illustre la gaussienne utilisée pour pondérer les amplitudes du gradient avant de construire l’histogramme final. L’algorithme initial utilise une image en niveaux de gris. Plusieurs extensions couleurs ont donc par la suite été proposées :C-SIFT [Abdel-Hakim 06, Burghouts 09] ou encore Opponent-SIFT [van de Sande 10] par exemple. Cette dernière serait plus adaptée à la reconnaissance d’images par le contenu selon van de Sande et al. 17Chapitre 1. Solutions de recherche d’images par le contenu [van de Sande 10] quand on ne dispose d’aucun a priori sur les bases d’images. C-SIFT, dans sa version actuelle, a été formalisé par Burghouts et Geusebroek [Burghouts 09] et prend en compte des informations relatives aux invariants couleur introduits par Geusebroek et al. [Geusebroek 01]. Ces invariants couleur sont obtenus à partir d’un modèle de couleurs antagonistes qui peut être approximé par l’équation :   Ê Êλ Êλλ   =   0.06 0.63 0.27 0.30 0.04 −0.35 0.34 −0.6 0.17   ∗   R G B   , (1.3) λ correspond à la longueur d’onde. L’idée d’intégrer les invariants couleur a été, dans un premier temps, suggérée par Abdel-Hakim et Farag [Abdel-Hakim 06] qui n’utilisaient alors que la seule propriété de réflectance correspondant au ratio entre Eb λ et Eb λλ. Burghouts et Geusebroek [Burghouts 09] proposent d’utiliser l’invariant photométrique sur l’intensité (ici la première composante du nouvel espace couleur) Wcw obtenu avec l’équation (1.4) et les invariants à l’ombre et à l’ombrage Cb λw et Cb λλw qui sont donnés respectivement par les équations (1.5) et (1.6). Wcw = Eb w Eb avec Eb w = q Eb2 x + Eb2 y (1.4) Eb x et Eb y désignent respectivement les dérivées spatiales de Eb suivant x et y. Cb λw = q Cb2 λx + Cb2 λy avec Cb λj = Eb λjEb − Eb λEb j Eb2 , (1.5) Cb λj = Eb λjEb − Eb λEb j Eb2 avec Cb λλj = Eb λλjEb − Eb λλEb j Eb2 , (1.6) j ∈ {x, y} et désigne les dérivées spatiales suivant x et y. Ce descripteur est plus robuste que SIFT en respectant les couleurs et les variations photométriques. Sa performance a été prouvée par van de Sande et al. [van de Sande 10] sur la base de données PASCAL VOC 2007 [Everingham 12] pour une tâche de classification d’images. Il vient en seconde position derrière OpponentSIFT pour les bases de données sans a priori. L’idée des Opponent-SIFT est de calculer un descripteur décrivant tous les canaux couleurs dans un espace "antagoniste" (01, 02, 03) défini par l’équation (1.7) créant ainsi un descripteur de taille 384=128*3 comme C-SIFT. Le nouvel espace est défini à partir des valeurs R (Rouge), G (Vert) et B (Bleu) des pixels de l’image.   01 02 03   =   R √−G 2 R+G √−2B 6 R+ √ G+B 3   (1.7) Dans la littérature, on retrouve beaucoup d’autres descripteurs dérivés de SIFT et de son fonctionnement. En effet, le descripteur SIFT n’est pas adapté à toutes les applications malgré ses bons résultats du fait de sa grande dimensionnalité. L’une 18Chapitre 1. Solutions de recherche d’images par le contenu des premières solutions a été apportée par Ke et Sukthankar qui proposent PCASIFT [Ke 04] un descripteur de 36 dimensions. Ce descripteur est certes plus rapide lors de l’étape de la mise en correspondance des vecteurs mais est moins distinctif que SIFT d’après l’étude comparative de Mikolajczyk et Schmid [Mikolajczyk 05a]. Toujours dans l’optique de créer un descripteur plus rapide mais tout aussi efficace que SIFT, Bay et al. ont proposé SURF (Speeded Up Robust Features) [Bay 06], un descripteur de 64 dimensions. SURF existe aussi en 128 dimensions mais la version en 64 dimensions donne des résultats très satisfaisants. Il ne s’agit pas seulement d’un nouveau descripteur mais d’un nouveau schéma détecteur/descripteur. Les caractéristiques locales sont détectées avec une matrice hessienne et l’algorithme utilise des images intégrales pour gagner en rapidité. Dans leurs travaux, les auteurs montrent que SURF est meilleur que SIFT ou encore PCA-SIFT pour de la reconnaissance d’objets d’art. On peut citer plusieurs autres descripteurs qui ont été proposés pour améliorer les résultats connus des SIFT, par exemple GLOH (Gradient Location and Orientation Histogram). Il a été proposé par Mikolajczyk et Schmid [Mikolajczyk 05a]. Il s’agit d’une variante de SIFT de dimension 128 mais qui compense sa grande dimensionnalité par une meilleure précision d’après leurs résultats. Les différences principales entre ce descripteur et SIFT sont les suivantes : – Le descripteur est calculé sur une grille "log-polaire" contrairement à la grille rectangulaire utilisée pour SIFT ; – La quantification de l’orientation du gradient est plus précise (16 orientations au lieu des 8 utilisées dans SIFT) ; – Pour réduire la dimensionnalité du descripteur GLOH à 128, les auteurs utilisent une ACP (Analyse en Composantes Principales). Hormis les extensions couleurs de SIFT de la littérature, tous les descripteurs évoqués ci-dessus ne considèrent que des images en niveaux de gris. Il existe néanmoins quelques solutions pour prendre en compte l’information couleur. Il s’agit entre autres des moments couleur et des invariants de moments couleur calculés dans une région dont on définit la taille autour du point clé. Les moments couleurs, que nous abrégerons CM (Colour Moments), permettent de mesurer la similarité couleur entre deux images. Ils sont basés sur les moments couleur généralisés proposés par Mindru et al. [Mindru 04] sur des patchs de l’image. Ils se calculent à partir des valeurs R, G, et B des pixels des régions considérées. L’ensemble des moments couleur généralisés M d’ordre p+q et de degré a+b+c d’une caractéristique locale dans une région Ω est obtenu grâce à l’équation (1.8). Mabc pq = ZZ Ω x p y q [R(x, y)]a [G(x, y)]b [B(x, y)]c dxdy (1.8) La plupart du temps, on ne considère que les moments de premier ordre et du second degré : Mabc 00 , Mabc 10 et Mabc 01 , ce qui correspond à 27 moments avec : (a, b, c) ∈    (1, 0, 0),(0, 1, 0),(0, 0, 1) (2, 0, 0),(0, 2, 0),(0, 0, 2) (1, 1, 0),(1, 0, 1),(0, 1, 1)    . On peut ajouter les 3 moments d’ordre 0 ; M000 00 , M000 10 et M00 01 qui sont des constantes. On obtiendrait alors 30 moments. 19Chapitre 1. Solutions de recherche d’images par le contenu Les invariants de moments couleur, abrégés CMI (Colour Moment Invariants) dans ce manuscrit, ont été également proposés par Mindru et al. [Mindru 04]. Ces derniers sont calculés à partir des CM. Pour considérer les trois canaux couleur, il faut utiliser les invariants "3-bandes" définis dans l’Annexe A. Tous les descripteurs évoqués précédemment ne sont pas facilement utilisables sur des systèmes embarqués du fait des contraintes en termes de mémoire de calcul posés par ces derniers. L’autre famille de propositions de la littérature concerne donc les descripteurs binaires. L’idée est de pouvoir résumer la plupart des informations d’un patch avec une suite binaire obtenue uniquement à partir de la comparaison des valeurs des pixels des images. L’utilisation de suites binaires a des avantages considérables. Lors de la comparaison de plusieurs images, on peut utiliser des distances de similarité très simples et rapides à mettre en œuvre : la distance de Hamming par exemple. Elle est définie par l’équation (1.9) entre deux suites binaires a et b de taille NS. Définition Soient deux suite binaires a et b de taille NS, leur distance de Hamming est donnée par : d Hamming (a,b) = N XS−1 i=0 ai ⊕ bi , ⊕ désignant le ou exclusif. (1.9) Comme exemple de descripteurs binaires, nous pouvons citer : – BRIEF (Binary Robust Independent Elementary Features) [Calonder 10] ; – FREAK (Fast Retina Keypoint) [Alahi 12] ; – BRISK (Binary Robust Invariant Scalable Keypoints) [Leutenegger 11]. Une fois les descripteurs calculés, l’étape suivante est la comparaison des images à partir de leurs vecteurs de descripteurs. 1.2 Recherche des images les plus ressemblantes Pour la recherche des images les plus ressemblantes, deux solutions intuitives existent : – Comparer les vecteurs de descripteurs entre eux en évaluant la répétition d’une ou de plusieurs caractéristiques locales ; – Créer une nouvelle signature de l’image facilement exploitable à partir des vecteurs de descripteurs. Dans la littérature, les deux solutions sont proposées et leur utilisation dépend le plus souvent des applications. Nous nous focaliserons sur la seconde solution. En effet, les vecteurs de descripteurs ne peuvent pas toujours être utilisés tels quels puisqu’ils sont de grandes dimensions (nombre de caractéristiques locales ∗ dimensions du descripteur), entraînant la nécessité d’une certaine mémoire de stockage pour la comparaison. La solution la plus répandue dans cette seconde famille de méthodes est communément appelée "Sac de mots visuels" que nous noterons BoVW (Bag of Visual Words) pour faciliter la lecture et la présentation des résultats. Cette solution a été 20Chapitre 1. Solutions de recherche d’images par le contenu initialement proposée par Sivic et Zisserman [Sivic 03] pour la recherche d’images et de vidéos. Elle s’inspire de la méthode "Sac de mots" utilisée en catégorisation de texte. L’idée est de créer une signature plus facilement exploitable pour chaque image à partir des mots visuels. On décidera alors que deux images sont visuellement proches si leurs signatures le sont. Le principe général est décrit sur la Figure 1.6. On notera d’ailleurs que la création du dictionnaire visuel doit se faire de préférence sur une(des) base(s) de données indépendante(s) de la base de tests pour inclure le plus de variabilité possible. Figure 1.6: Illustration de la création de la signature visuelle d’une image à partir de ses descripteurs et d’un vocabulaire visuel. 1.2.1 Création du dictionnaire de mots visuels L’idée sous-jacente à cette notion de "dictionnaire de mots visuels" est de disposer d’un ensemble de mots visuels le plus variés possible afin d’avoir une bonne représentation des images proches. La solution de la littérature est d’utiliser un algorithme de quantification pour définir les mots visuels. Un exemple est illustré sur la Figure 1.7. Il existe plusieurs choix de quantifications possibles. La solution la plus utilisée est l’algorithme K-means [Jégou 10b, van de Sande 10]. On effectue un clustering des différents vecteurs de descripteurs de la base "d’apprentissage" des mots en K clusters dont les centres constitueront les mots du futur dictionnaire visuel. Soient : – D l’ensemble des vecteurs de descripteurs de la base de construction des mots ; D est de taille NB∗taille du descripteur : par exemple, NB∗128 pour des descripteurs SIFT ou encore NB ∗ 24 pour des CMI, NB est le nombre de descripteurs dans toute la base. – W l’ensemble des mots visuels ; W est de taille K∗taille du descripteur. Le principe est le décrit par l’Algorithme 1. 21Chapitre 1. Solutions de recherche d’images par le contenu Figure 1.7: Exemple de quantification en 2D. Les points en rouge correspondent aux centroïdes des différentes régions qui seront retenus. Si on se place dans un contexte de construction de dictionnaire visuel ces points correspondraient aux mots visuels. Algorithme 1 : Algorithme de K-means Entrées : D, K Sorties : W Initialiser de façon aléatoire W; répéter Affecter à chaque centroïde tout vecteur de descripteurs tel que la distance entre le vecteur et le centroïde soit la plus petite; Modifier le centroïde des groupes qui se forment; jusqu’à Le centroïde de chaque groupe ne change plus; La distance entre le vecteur de descripteurs et le centroïde se fait le plus souvent avec une distance euclidienne dont la relation est donnée par l’équation (1.10). Définition Soient deux vecteurs A = [a1, a2, . . . , aND−1, aND ] et B = [b1, b2, . . . , bND−1, bND ] de taille ND (ND est le dimensionnalité du descripteur : pour SIFT, ND=128), la distance euclidienne entre A et B notée d L2 A,B est donnée par : d L2 A,B = vuutX ND i=1 (ai − bi) 2 . (1.10) Dans la mise en œuvre du K-means on peut jouer sur la distance de comparaison entre les vecteurs de descripteurs et les centroïdes. Ce qui peut donner lieu à des distributions uniformes ou encore gaussiennes. Le principal inconvénient de cette méthode est l’initialisation des mots visuels. Le dictionnaire final est très dépendant de la répartition des mots germes. Si les germes ne respectent pas la distribution des caractéristiques on a peu de chance d’avoir un dictionnaire final représentatif. Il existe plusieurs variantes de cet algorithme par exemple : – K-medians qui calcule la médiane au lieu de la moyenne et compare les vecteurs entre eux avec une distance L1 ; – K-medoids qui calcule un medoïde qui est un point du groupe de points qui minimise la dissimilarité avec les autres points du cluster. La dissimilarité 22Chapitre 1. Solutions de recherche d’images par le contenu entre les points peut être calculée avec une distance euclidienne, une distance de Manhattan ou une distance de Minkowski. Une autre solution de la littérature qui donne de très bons résultats pour la création du dictionnaire est l’algorithme GMM (Gaussian Mixture Model) [Perronnin 06, Perronnin 08]. L’idée dans ce cas est d’utiliser un modèle statistique pour trouver les différents mots visuels. L’ensemble des vecteurs de descripteurs est modélisé comme étant la somme de plusieurs gaussiennes pondérées par un poids π dont il faut déterminer la covariance et la moyenne. Les hypothèses suivantes, illustrées par la Figure 1.8, sont nécessaires pour définir le dictionnaire visuel à partir d’un GMM : 1. L’ensemble de vecteurs comporte K groupes qu’on note G ; 2. Chaque groupe gk est associé à une moyenne µk, une covariance σ 2 k et un poids πk ; 3. Les éléments de chaque groupe suivent une loi normale de moyenne µk et de covariance σ 2 k . Figure 1.8: Illustration des différentes hypothèses de l’algorithme GMM. Chaque vecteur di appartient donc à un groupe gk paramétré par θk = (µk, σ2 k ). L’ensemble des groupes G peut donc s’écrire comme étant une fonction de mélange de densité donnée par l’équation : G(D, Φ) = X K k=1 πkf(D, θk), (1.11) avec Φ = (π1, . . . , πk, θ1, . . . , θk) et f(D, θk) la loi normale multivariée paramétrée par θk. Φ est estimé avec un algorithme EM (Expectation-Maximisation) en trouvant le paramètre qui maximise la vraisemblance L(D, Φ) donnée par l’équation : L(D, Φ) = X N i=1 log X K k=1 πkf (Di , θk) ! . (1.12) On affecte pour finir chaque vecteur de descripteur di au groupe gk auquel il appartient si la probabilité a posteriori P(di∈gk ) calculée avec l’équation (1.13) est la plus grande. P(di ∈ gk) = πkf(di , θk) PK l=1 πlf(di , θl) (1.13) 23Chapitre 1. Solutions de recherche d’images par le contenu Les deux solutions de création de dictionnaire visuel présentées ci-dessus sont ensuite utilisées dans la représentation de chaque image pour la phase de recherche. Nous présenterons dans la sous-section suivante trois solutions de la littérature : – La première solution que nous avons évoquée au début de cette sous-section est la méthode BoVW [Sivic 03] qui est souvent utilisée après avoir construit le dictionnaire visuel avec un algorithme de type K-Means ; – La seconde technique, le vecteur de Fisher [Perronnin 07], se base sur le dictionnaire généré avec un GMM ; – La troisième solution que nous présenterons s’appelle VLAD (Vector of Loccally Aggregated Descriptors) [Jégou 10b]. C’est une approximation de la technique précédente avec un dictionnaire visuel construit avec un algorithme KMeans. 1.2.2 Quelques méthodes de création de la signature visuelle d’une image Sac de mots visuels Pour cette signature visuelle, l’idée est de compter dans chaque image l’occurrence des mots du dictionnaire visuel afin d’obtenir un histogramme de répartition. Le principe est illustré sur la Figure 1.9. Figure 1.9: Illustration de la mise en œuvre de l’algorithme BoVW. Au lieu de simplement représenter les images par un comptage des occurrences de chaque mot, on peut pondérer le "Sac de mots visuels". Le schéma de pondération standard s’appelle tf-idf (term frequency-inverse document frequency) [Sivic 03] et provient de la catégorisation de texte. Si on suppose que l’on dispose d’un dictionnaire de K mots, chaque document est alors représenté par un vecteur Hd = 24Chapitre 1. Solutions de recherche d’images par le contenu (h1, . . . , hk . . . , hK) ⊤ de fréquences pondérées obtenues avec l’équation (1.14). hk = nkd nd log N nk , (1.14) avec nkd le nombre d’occurrences du mot k dans le document d, nd le nombre total de mots dans le document d, nk le nombre d’occurrences du mot k dans la base et N le nombre de documents dans la base. Ce schéma de pondération permet de diminuer le poids des mots fréquents. La signature visuelle BoVW est de taille K. Elle présente notamment deux inconvénients qui dépendent surtout de sa mise en œuvre. Le premier est directement lié au dictionnaire utilisé. La plupart du temps on utilise un dictionnaire issu d’un algorithme K-Means. Cette quantification introduit des pertes d’information et a pour conséquence de nécessiter l’utilisation d’un dictionnaire de grande taille pour assurer la variabilité des mots [Perronnin 07]. La seconde insuffisance est la repré- sentation sous forme d’histogrammes. Compter les occurrences d’un mot visuel pour représenter une image beaucoup plus complexe introduit potentiellement un manque à gagner en précision au moment de la recherche. Ce sont ces deux raisons qui ont motivé Perronnin et Dance [Perronnin 07] à proposer l’utilisation des noyaux de Fisher pour la reconnaissance d’images en utilisant un dictionnaire visuel obtenu avec un GMM. Vecteur de Fisher Soient D = {dn, n=1,...,N } un ensemble représentant les descripteurs d’une image, uλ une fonction de densité de probabilité qui modélise un processus avec [λ1, . . . , λK] ′ le vecteur de K paramètres de uλ. L’idée est d’utiliser les outils statistiques pour calculer une fonction de score notée GD λ donnée par l’équation (1.15) qui calcule le gradient du log-ressemblance des données par rapport au modèle. Elle décrit ainsi la contribution de chaque paramètre au processus généré, en indiquant comment les paramètres du modèle généré uλ devraient être modifiés pour coller au mieux aux données D. G D λ = ∇λ log uλ (D) (1.15) Une fois ce gradient défini, on associe alors à chaque image un vecteur de Fisher G Dλ grâce à l’équation : G Dλ = LλG D λ = Lλ∇λ log uλ (D) = X N n=1 Lλ∇λ log uλ (dn), (1.16) dans laquelle Lλ est la racine carrée de la matrice d’information de Fisher Fλ définie par l’équation : Fλ = ED∼uλ  G D λ G D ′ λ  = Lλ ′ Lλ. (1.17) Le lecteur intéressé peut se référer au rapport de recherche publié en 2013 par Sánchez et al. [Sánchez 13] pour plus de détails. Dans les travaux, de Perronnin et Dance [Perronnin 07], uλ est un modèle de mélange gaussien (GMM) de K composantes qui correspond au vocabulaire visuel. En comparaison avec les résultats de la méthode 25Chapitre 1. Solutions de recherche d’images par le contenu BoVW, le vecteur de Fisher requière très peu de mots du fait de sa représentation. Dans leurs travaux Perronnin et Dance [Perronnin 07] n’ont eu besoin que de 100 mots pour la catégorisation d’images. VLAD (Vector of Locally Aggregated Descriptors) VLAD est une technique de représentation des images qui a été introduite par Jégou et al. [Jégou 10b] et peut être vue comme une version simplifié du vecteur de Fisher qui ne considère pas les statistiques d’ordre supérieures. Considérons : – un dictionnaire visuel W = {w1, . . . , wK} composé de K mots visuels générés avec un algorithme K-Means ; – un ensemble de descripteurs D = {d1, . . . , dNB } d’une base d’image. Chaque descripteur dn est associé à son plus proche mot visuel wk avec la relation : NN(dn) = argmin kdn − wkk. (1.18) Ensuite on calcule la valeur du VLAD avec l’équation : vk = X dn:NN(dn)=wk (dn − wk). (1.19) L’accumulation dans le calcul du VLAD de la différence dn − wk permet de caracté- riser la distribution du vecteur par rapport au centre. Les auteurs préconisent une normalisation L2 du VLAD avant de l’utiliser. Comme dans le cas de l’utilisation d’un noyau de Fisher, les VLAD ne nécessitent pas beaucoup de mots. Les auteurs ont d’ailleurs de très bons résultats avec 256 mots. La signature visuelle finale est de taille K∗dimensionnalité du descripteur : K*128 pour le descripteur SIFT par exemple. Toutes les techniques présentées ici permettent de créer une signature visuelle des images afin d’effectuer la comparaison des différentes signatures. Plusieurs travaux de la littérature [Grauman 05, Lazebnik 06, van de Sande 10] montrent qu’on peut optimiser l’étape de création des signatures en utilisant des pyramides spatiales. L’idée est de subdiviser l’image en plusieurs imagettes et de calculer une signature par subdivision. La signature finale peut être la concaténation de toutes les signatures pondérées différemment en fonction de leur niveau dans la pyramide spatiale. Il existe plusieurs options de pyramides spatiales. Celle proposée par Lazebnik et al. [Lazebnik 06], et également utilisée par van de Sande et al. [van de Sande 10], est illustrée par la Figure 1.10. Dans ce cas, le poids associé à chaque niveau de pyramide est donné par l’équation (1.20) : πl = 1 2 (L−l) , (1.20) avec L le nombre total de niveau et l=0, . . ., L-1. Que l’on utilise des signatures avec ou sans pyramides spatiales, l’étape suivante est la recherche des images similaires. 26Chapitre 1. Solutions de recherche d’images par le contenu (a) Niveau 0 (b) Niveau 1 (c) Niveau 2 Figure 1.10: Illustration de la pyramide spatiale proposée par Lazebnik et al. [Lazebnik 06]. 1.2.3 Recherche des images similaires à partir de leurs signatures visuelles Nous ne détaillerons pas les solutions de la littérature. En effet, la plupart est implémentée et facilement accessible 3 . Plusieurs solutions sont utilisables pour la recherche des images similaires à partir des signatures visuelles. On peut les classer en deux grands groupes : – Les solutions avec apprentissage pour la catégorisation ; – Les solutions sans apprentissage pour la recherche d’images ressemblantes par leur contenu. Nous n’aborderons pas la première classe de solutions puisqu’il existe une panoplie de classifieurs efficaces. Nous soulignerons juste que les SVM (Support Vector Machine) sont très utilisés [van de Sande 10] et offrent de très bons résultats. Les trois solutions de création de signatures des images présentées plus tôt dans ce manuscrit s’adaptent très bien à ces différents classifieurs. Une mention spéciale est faite pour les vecteurs de Fisher qui offrent de très bons résultats avec des classifieurs linéaires [Perronnin 07]. Pour des signatures visuelles BoVW et VLAD, la recherche des signatures les plus proches se fait traditionnellement avec l’équation : NN(S1) = argmin dist(S1, S2), (1.21) avec S1 la signature dont on recherche la plus proche voisine dans l’ensemble des signatures S des images de la base, S2 une signature de la base et dist la distance entre les deux signatures. Le plus souvent, on utilise la distance euclidienne mais on peut également utiliser la distance χ 2 dans le cas d’une signature visuelle de type "Sac de mots visuels" dont la relation est donnée par l’équation (1.22). Définition La distance χ 2 entre deux signatures visuelles S1 et S2 de taille K, notée d χ 2 S1,S2 , est donnée par : d χ 2 S1,S2 = X K i=1 (S1(i) − S2(i))2 S1(i) + S2(i) . (1.22) 3. https://gforge.inria.fr/projects/yael/, http://www.cs.umd.edu/~mount/ANN/, http://www.cs.ubc.ca/research/flann/ 27Chapitre 1. Solutions de recherche d’images par le contenu Cette méthode de recherche n’est pas toujours adaptable pour des recherches dans de grandes bases d’images (≥ 1 million d’images). En effet, le nombre de distances à calculer peut vite devenir problématique et induire des temps de recherche importants. Il existe plusieurs solutions de la littérature qui tentent de résoudre les différentes problématiques liées à la recherche des voisins dans de très grandes bases de données. Une solution au traditionnel algorithme de KNN est l’estimation des plus proches voisins les plus probables. Cette stratégie de recherche ne garantit pas toujours les voisins les plus proches mais les voisins le plus souvent proches. Dans la littérature plusieurs travaux ont été consacrés à cette solution dont [Arya 98, Indyk 98, Muja 09]. Si les signatures visuelles sont des vecteurs de Fisher, on pourrait également utiliser la mesure de similarité M proposée par Sánchez et al. [Sánchez 13] définie par l’équation : M (S1, S2) = G S1 ′ λ G S2 λ . (1.23) Nous venons de présenter quelques solutions de la littérature pour la reconnaissance d’images par le contenu. Ces solutions peuvent être classées dans la catégorie de "solutions classiques". En effet, d’autres solutions voient le jour en intégrant des informations de notre système visuel humain dans l’une des deux étapes que nous avons répertoriées au début de ce chapitre. On peut citer entre autres, l’utilisation de la saillance visuelle. Nous proposons alors, pour mieux appréhender son utilisation, de faire un état de l’art bref sur cette notion qui peut paraître simple, mais qui peut être ambigüe dans sa définition si on ne pose pas correctement le cadre. Si nous le qualifions de bref c’est parce que pour être complet, il devrait intégrer le point de vue biologique du système visuel humain ; ce que nous ne ferons que succinctement dans cet état de l’art. 1.3 Saillance visuelle Si on se réfère à la définition du Larousse en ligne, est saillant quelque chose qui "ressort" ; qui attire l’attention. Quand on parlera de saillance visuelle on s’intéressera alors à la notion d’attention visuelle. 1.3.1 Qu’est-ce que l’attention visuelle ? L’une des plus anciennes définitions de l’attention visuelle a été donnée par Williams James en 1890 [James 90] : "Everyone knows what attention is. It is the taking possession by the mind, in clear and vivid form, of one out of what seem several simultaneously possible objects or trains of thought. Focalization, concentration, of consciousness are of its essence. It implies withdrawal from some things in order to deal effectively with others." L’attention visuelle pourrait donc être définie comme étant la capacité du cerveau à sélectionner l’information visuelle pertinente en rejetant ce qui ne l’est pas dans un contexte particulier. Pour mieux comprendre ce phénomène, on devrait donc 28Chapitre 1. Solutions de recherche d’images par le contenu s’intéresser à ce qui se passe au niveau de notre système visuel humain (SVH). Plusieurs documents de la littérature abordent le système visuel humain. Nous ne ferons pas une description complète de ce système. Nous présenterons brièvement ce qui se passe au niveau de la rétine et le traitement du signal post-rétinien. Le lecteur intéressé pourra se référer à [Le Meur 05a, Perreira Da Silva 10a, Boujut 12]. Comment fonctionne le système visuel humain ? Comme le dit Boujut [Boujut 12], l’œil humain peut être comparé à un appareil photo numérique. Sur une caméra, l’image est projetée sur le capteur à travers la lentille. Pour prendre une bonne photo, l’image projetée doit être dans le focus du capteur, avec une luminosité adéquate (ni trop claire, ni trop foncée). La mise au point est effectuée en ajustant la distance entre la lentille et le capteur. La quantité de lumière est contrôlée par le diaphragme. L’œil humain a à peu près le même comportement. Une illustration de la structure de l’oeil est faite par la Figure 1.11. Figure 1.11: Illustration de la structure de l’œil [Oei ]. La mise au point est assurée par la cornée et le cristallin. L’iris commande l’ouverture. La partie photo-réceptrice de l’œil est appelée la rétine. L’image est projetée sur la rétine, qui est située à l’arrière de l’œil. Cette dernière est peuplée de cellules photosensibles. Lorsqu’une lumière arrive au niveau de l’œil, elle passe en premier par la cornée. Elle traverse ensuite la chambre antérieure pour atteindre le muscle de l’iris. Ce muscle contrôle la taille de la pupille, régulant ainsi la quantité de lumière rentrant. Enfin, la lumière passe à travers le cristallin, traverse le corps vitré et atteint la rétine. Cette dernière est un tissu neuronal très fin d’une épaisseur de 0.1 à 0.5 mm tapissant le fond de l’œil. C’est à ce niveau que s’effectue le premier traitement de l’information. Il consiste à traduire le message lumineux venant de l’extérieur en signaux nerveux utilisables et interprétables par les neurones des aires visuelles du cerveau. Comme on peut le voir sur la Figure 1.12, la rétine est constituée de plusieurs couches de cellules. Les cellules photoréceptrices constituent la couche la plus profonde de la rétine et sont de deux types : les cônes et les bâ- tonnets. Leur distribution n’est pas uniforme au niveau de la rétine. En effet, les cônes se concentrent au centre, dans la fovéa, alors que les bâtonnets sont situés à 29Chapitre 1. Solutions de recherche d’images par le contenu Figure 1.12: Structure de la rétine [Ret ]. la para fovéa et à la périphérie. Les cônes sont dédiés à la perception d’informations de moyennes à fortes luminances. Ces deux cellules photoréceptrices ne sont également pas sensibles à la même information. Les bâtonnets sont uniquement sensibles à la luminance alors que les cônes à la longueur d’onde. Comme le dit Le Meur [Le Meur 05a], comparativement aux bâtonnets, les cônes permettent d’avoir une représentation fine d’une scène observée en conservant l’essentiel de sa résolution spatiale et temporelle ; l’acuité visuelle est élevée dans la fovéa. Cette meilleure efficacité est liée à la façon dont l’information est distribuée par les cônes. Contrairement aux bâtonnets qui distribuent l’information à plusieurs cellules réceptrices, les cônes sont reliés uniquement à une cellule, en l’occurrence une cellule bipolaire. Une fois le signal lumineux arrivé au niveau de la rétine, un processus post-rétinien est mis en place. Les nerfs optiques venant des deux yeux se croisent pour former le chiasma optique illustré sur la Figure 1.13. Notons que ce phénomène est en partie responsable de la perception de la profondeur. En quittant le chiasma optique le traitement de l’information se fait de façon parallèle au niveau du cerveau. Elle circule à travers deux voies optiques pour atteindre le cortex visuel. Ce dernier occupe le lobe occipital du cerveau et est chargé de traiter les informations visuelles. L’étude du cortex visuel en neurosciences a permis de le découper en une multitudes de sous-régions fonctionnelles (V1, V2, V3, V4, MT, . . . ), illustrées sur la Figure 1.14, qui traitent chacune ou collectivement les multiples propriétés des informations provenant des voies visuelles (formes, couleurs, mouvements, etc.). Selon Jauzein [Jauzein 10], il existe quatre systèmes qui traitent en parallèle les diverses caractéristiques d’un objet. L’un détecte le mouvement, un autre la couleur, et les deux autres la forme : – La couleur est perçue lorsque les cellules sensibles, présentes dans les colonnes de l’aire V1 (cortex visuel primaire), envoient des signaux vers l’aire spécialisée V4 et vers les bandes minces de l’aire V2 qui sont connectées à cette dernière ; 30Chapitre 1. Solutions de recherche d’images par le contenu Figure 1.13: La distribution des réponses rétiniennes au niveau du cortex [Chi ]. Figure 1.14: Différentes aires visuelles corticales [Air ]. – La détection des formes colorées résulte d’échanges de signaux entre les régions inter-taches de V1, les régions inter-bandes de V2 et l’aire V4 ; – La détection du mouvement et des formes en mouvement se fait lorsque les aires V3 et V5 reçoivent des signaux en provenance directe de la couche 4B de l’aire V1 ou par l’intermédiaire des bandes larges de V2. Le processus complexe qui se déroule au niveau du cortex visuel n’est pas complètement défini. Plusieurs modèles ont été proposés dont celui à deux voies de traitement des informations issues du cortex visuel primaire [Perreira Da Silva 10a, Boujut 12]. Ce dernier (Figure 1.15) comprend : – La voie dorsale qui est associée à l’estimation de mouvement et la localisation 31Chapitre 1. Solutions de recherche d’images par le contenu d’objets. Elle entraîne les fonctions oculomotrices des yeux ; – La voie ventrale qui gère la perception visuelle. En utilisant les propriétés visuelles telles que la forme, les couleurs, etc, elle permet la reconnaissance et l’identification des objets. Elle est également liée au stockage dans la mémoire à long terme. Figure 1.15: Traitement des informations provenant du cortex visuel primaire selon la modélisation de deux voies dorsale et ventrale [Cor ]. La voie dorsale est représentée en vert, la voie ventrale en violet et le cortex visuel primaire en bleu. La complexité du SVH est en partie maîtrisée pour les parties rétiniennes et pour le cortex visuel primaire. À partir d’études neurophysiologiques et d’expérimentations psychophysiques, de nombreux mécanismes inhérents aux premiers traitements mis en jeu dans l’analyse visuelle peuvent être reproduits via des modèles mathématiques. Mais la connaissance des aires corticales supérieures (V2, V3, . . . ) et de leurs interactions reste encore très faible. Au mieux, est-on capable de leur affecter un type de tâches sans vraiment pouvoir définir et caractériser précisément les mécanismes mis en jeux [Le Meur 05a]. Cette brève présentation du SVH a pour but de sensibiliser le lecteur au fait que le cerveau n’est pas capable de considérer tous les détails. Ce système intrinsèquement limité, traite une quantité considérable d’informations visuelles en partie grâce à un mécanisme passif de réduction de la redondance des informations incidentes (champs récepteurs des cellules rétiniennes et corticales) [Le Meur 05a]. C’est là qu’entre en jeu le mécanisme de l’attention visuelle qui nous permet de sélectionner des informations visuelles spatio-temporelles pertinentes du monde visible. Ce mécanisme nous permet d’utiliser de façon optimisée nos ressources biologiques. Ainsi, seule une petite partie des informations incidentes est transmise aux aires supérieures de notre cerveau [Ballard 91]. Un mécanisme actif, est donc nécessaire [Le Meur 05a] : les mouvements oculaires. Bien que nous n’en ayons pas conscience, ces différents types de mouvements prennent la forme de mouvements de poursuites, de convergences, de saccades ou encore de fixations. Nous n’aborderons que les fixations et les saccades qui sont les deux mouvements oculaires principaux entrant en jeu lorsque nous essayons de fixer un objet. 32Chapitre 1. Solutions de recherche d’images par le contenu Les mouvements oculaires de saccades et de fixation Les définitions que nous donnons de ces mouvements oculaires sont celles de Le Meur [Le Meur 05a]. Les saccades sont des mouvements oculaires balistiques dont la vitesse est comprise entre 100 et 700 degrés par seconde. Ce type de mouvement permet de déplacer l’attention visuelle d’un endroit à un autre (un saut d’un point à un autre) afin de les inspecter par la partie la plus performante (en termes de résolution spatiale) de la rétine : la fovéa. Les saccades sont souvent considérées comme un mécanisme favorisant la sélection des informations visuelles pertinentes de notre champ visuel. La scrutation de notre monde visuel se fait donc par une série de sauts permettant le déplacement rapide de nos ressources sensorielles d’un point à un autre. Lorsqu’une saccade est effectuée en direction d’une cible particulière, la précision de la visée peut être soit très bonne soit mauvaise ; dans ce dernier cas, une seconde saccade ajuste le déplacement. Durant ces déplacements, notre pouvoir d’analyse est très faible signifiant que quasiment aucune information visuelle n’est traitée. Notons que le passage d’un point à un autre ne se fait pas forcément par le plus court chemin, c’est à dire la ligne droite. La trajectoire peut en effet être incurvée. Enfin, les saccades sont séparées par des phases de fixations. Ces dernières se produisent lorsque l’œil fixe une zone de notre environnement. À première vue, l’œil a donc une position stationnaire d’où le terme de fixation. Pourtant et paradoxalement, les fixations sont considérées comme des mouvements oculaires. L’explication est en fait très simple : lors d’une phase de fixation, l’œil est animé d’un mouvement résiduel. Ces légers mouvements permettent de décaler la zone examinée par la fovéa afin que cette dernière soit constamment excitée. Si l’œil était réellement stationnaire, c’est à dire en vision stabilisée, la perception visuelle disparaîtrait progressivement en raison du mécanisme inhibiteur de l’attention. Ce dernier consiste à inhiber une zone inspectée afin d’éviter que notre attention visuelle se porte continuellement sur cette même zone. L’attention visuelle Dans le mécanisme de l’attention visuelle, la notion de sélection est très importante. Cette dernière peut se faire de manière passive ou active. La première sélection se fait naturellement grâce au système visuel humain et à sa physiologie. La deuxième sélection dite active englobe les différentes focalisations. D’ailleurs, on distingue deux sortes de focalisations : – La focalisation "ouverte" qui correspond à un déplacement de la fovéa sur le stimulus par le biais d’un mouvement oculaire ; – La focalisation "couverte" qui est une faculté à focaliser notre attention sur une cible (objet ou position) sans déplacer nos yeux. L’attention visuelle peut également être exogène/endogène [Le Meur 05a, Boujut 12]. L’attention exogène (ou encore ascendante ou bottom-up) représente l’ensemble des processus automatiques déclenchés par les stimuli externes et captés par notre système visuel. C’est un mécanisme relativement éphémère piloté par les données de notre champ visuel et faisant référence à l’attention involontaire [Le Meur 05a]. Les modélisations computationnelles de la littérature pour ce genre d’attention visuelle 33Chapitre 1. Solutions de recherche d’images par le contenu essaient de reproduire ce qui se fait au niveau de la rétine et du système visuel humain. L’attention endogène (également appelée descendante ou top-down), quant à elle, est volontaire et dépend, par exemple, de nos objectifs. Beaucoup de modèles informatiques ont vu le jour pour approximer ce mécanisme d’attention visuelle. On les appelle plus généralement les modèles de saillance visuelle. Dans un état de l’art, Borji et Itti [Borji 13a] détaillent 65 des modèles de la littérature et les évaluent selon 13 critères. Nous présenterons leur taxonomie de classification des modèles de saillance. Nous ne détaillerons par contre pas les diffé- rentes métriques utilisables pour évaluer un modèle de saillance. Le lecteur intéressé pourra se référer aux travaux de [Le Meur 05a, Boujut 12, Borji 13b]. 1.3.2 Différents modèles de saillance visuelle Quand on parle des différentes modèles de saillance on se réduit souvent aux attentions Bottom-up et Top-down. On peut également distinguer dans la littérature des modèles qui utilisent l’information spatiale seule [Itti 98, Perreira Da Silva 12] ou combinée avec une information temporelle [Le Meur 05b, Marat 09, Borji 11]. Les modèles peuvent être également classés selon qu’ils soient orientés "espace" ou "objet" [Borji 13b]. Ceux basés "objet" essaient de segmenter ou de détecter les objets pour prédire les régions saillantes. En ce qui concerne les modèles basés "espace", l’idée est de prédire les endroits dans l’image ayant une forte probabilité d’attirer l’attention. Quel que soit le modèle de saillance visuelle, il peut être classé dans l’une des 8 catégories que proposent Borji et Itti : – Les modèles cognitifs qui s’inspirent des concepts cognitifs et essayent de mimer le fonctionnement du SVH [Le Meur 06, Kootstra 08]. – Les modèles bayésiens dans lesquels les connaissances a priori (par exemple le contexte de la scène) sont combinées avec les informations sensorielles (par exemple les caractéristiques de la scène) avec une règle bayésienne [Zhang 09, Li 10a]. – Les modèles décisionnels qui sous-entendent que les systèmes de perception évoluent pour produire des décisions sur les états de l’environnement qui sont optimales au sens d’une décision théorique (par exemple, la probabilité d’erreur minimum). Le point fondamental est que l’attention visuelle devrait être guidée par l’optimalité par rapport à la tâche finale [Gu 07, Mahadevan 10]. – Les modèles informationnels basés sur l’hypothèse que le calcul de la saillance localisée sert à maximiser l’information échantillonnée à partir de son environnement. Ils sélectionnent les parties les plus informatives de la scène [Li 10b, Wang 11]. – les modèles graphiques qui traitent des mouvements oculaires comme une série de temps. Puisqu’il existe des variables cachées qui influencent la génération des mouvements oculaires, des approches telles que les modèles de Markov cachés, les réseaux bayésiens dynamiques et les champs aléatoires conditionnels ont été intégrées [Chikkerur 10, Liu 11b]. – les modèles d’analyse spectrale pour lesquels le modèle de saillance est 34Chapitre 1. Solutions de recherche d’images par le contenu calculé dans le domaine fréquentiel [Achanta 09, Bian 09]. – les modèles construits à partir de système d’apprentissage [Judd 09, Kienzle 09]. – les autres modèles qui regroupent toutes les propositions qui ne correspondent à aucune des 7 précédentes catégories [Ramström 02, Garcia-Diaz 09, Rosin 09, Goferman 12]. À partir de ces catégories, on note que différents outils ont été testés pour modéliser l’attention visuelle. Certains modèles sont basés sur des opérations simples telles que des filtres de couleur, alors que d’autres effectuent un raisonnement complexe de haut niveau basé sur les réseaux bayésiens, modèles de Markov cachés ou des SVM [Boujut 12]. Le premier modèle d’attention visuel est le modèle Feature Integration Theory (FIT) [Treisman 80] proposé par Treisman et Gelade en 1980. Les auteurs avaient alors sélectionné un ensemble de caractéristiques pertinentes pour l’attention visuelle humaine. Cinq ans plus tard, Koch et Ullman [Koch 85] proposaient le concept de carte de saillance qui n’était rien d’autre qu’une carte topographique de l’attention visuelle. Ils ont alors utilisé la technique "winner-take-all" pour prédire le balayage du regard. Une zone d’inhibition est alors définie autour du point saillant permettant ainsi de passer au prochain point saillant de la carte. Ce modèle n’a été complétement développé qu’en 1998 par Itti [Itti 98]. C’est l’un des modèles qui a souvent servi de base dans la littérature et qui a été amélioré sous plusieurs aspects et que nous expliquons brièvement ci-après. 1.3.3 Modèle de saillance de Itti et Koch [Itti 98] Il s’agit d’un modèle de saillance bio-inspiré. Il est en effet basé sur le fonctionnement du système visuel humain. Son architecture est illustrée par la Figure 1.16. À partir d’une image, un ensemble de caractéristiques visuelles pré-attentives sont calculées. Ces dernières sont liées aux couleurs, à l’intensité et aux différentes orientations. Des cartes de caractérisation sont alors générées à partir de ces caractéristiques et leur fusion permet d’obtenir la carte de saillance. Pour générer les différentes caractéristiques visuelles pré-attentives, 3 canaux sont définis à partir d’une image (R,G,B) [Le Meur 05a] : – Le canal intensité obtenu grâce à l’équation : intensite = R + G + B 3 ; (1.24) – Le canal couleur composé de quatre composantes C1, C2, C3 et C4 issues de la 35Chapitre 1. Solutions de recherche d’images par le contenu Figure 1.16: Architecture du modèle de saillance de Itti et Koch. théorie des couleurs antagonistes : C1 = R − (G + B) 2 , (1.25) C2 = G − (R + B) 2 , (1.26) C3 = B − (G + R) 2 , (1.27) C4 = (G + R) 2 − |R − G| 2 − B; (1.28) – Le canal dédié aux composantes orientées est obtenu à partir d’une pyramide de Gabor orientée O(θ), où σ indique le niveau de la pyramide et θ ∈ {0˚, 45˚, 90˚, 135˚}. Une fois les différents canaux définis, une décomposition hiérarchique sur 9 niveaux via des pyramides gaussiennes est effectuée sur chaque composante. Ces pyramides 36Chapitre 1. Solutions de recherche d’images par le contenu sont censées représenter une approximation du pavage fréquentiel des cellules visuelles. Un mécanisme de centre/pourtour permet ensuite d’extraire des différents niveaux de la pyramide les informations pertinentes contrastant avec leur voisinage. Les cartes obtenues sont normalisées indépendamment les unes des autres et permettent de construire une carte de saillance par canal. La carte de saillance finale provient de la combinaison des différentes cartes. Les différents calculs de contraste ne sont pas détaillés ici mais le lecteur intéressé pourrait se référer à [Itti 98, Le Meur 05a]. Un exemple de carte de saillance est donnée sur la Figure 1.17. (a) Image originale (b) Carte de saillance Figure 1.17: Exemple de carte de saillance. Cette carte (b) est obtenue avec le logiciel GBVS (Graph-Based Visual Saliency) [Harel ] qui permet de calculer les cartes obtenues avec le modèle de Itti. 1.3.4 Évaluation des modèles de saillance visuelle L’évaluation des modèles de saillance visuelle se fait le plus souvent par rapport à une vérité-terrain. On compare alors les résultats du modèle aux fixations récupérées lors d’expériences oculométriques, ou dans le cas d’une saillance visuelle orienté objet à des segmentations en objets des images. Il existe plusieurs métriques dans la littérature [Perreira Da Silva 10a, Boujut 12, Borji 13b, Le Meur 13] mais elles peuvent être classées en trois groupes : – Les métriques basées valeurs : on peut citer la métrique NSS (Normalized Scanpath Saliency) qui correspond à la moyenne des valeurs de réponse à des positions de l’œil humain dans la carte de saillance, normalisée à une moyenne nulle et un écart-type de 1 d’un modèle. Une valeur de NSS égale à 1 indique que les positions des yeux des sujets tombent dans une région dont la saillance prédite est un écart-type au-dessus de la moyenne. Si cette valeur est supérieure à 1 alors cela signifie que le modèle de saillance indique une valeur de saillance élevée aux positions fixées par l’humain comparée à d’autres positions. En revanche, si elle est nulle alors le modèle ne fonctionne pas mieux qu’une prédiction aléatoire du regard ; – Les métriques basées positions : la métrique AUC (Area Under Curve) en est un exemple ; – Les métriques basées sur la distribution : la divergence de Kullback Leibler est par exemple une métrique de cette catégorie utilisée dans la littérature. Elle mesure la dissimilarité entre les distributions des positions réelles de l’œil et celles qui ont été prédites par le modèle de saillance visuelle. 37Chapitre 1. Solutions de recherche d’images par le contenu 1.4 Quelques travaux intégrant la saillance visuelle en recherche d’images par le contenu Dans la littérature, la saillance visuelle est massivement utilisée pour filtrer les caractéristiques locales [Gao 08, Liu 08]. Par exemple, Gao et al. [Gao 08] proposent de définir des régions saillantes en croisant la carte de saillance visuelle d’une image et ses caractéristiques locales. Ils ont intégré un schéma de pondération des régions saillantes à partir de leur taille et de leur position dans l’image. Dans leur approche, seules les trois plus grandes régions (taille supérieure à 5% de la taille de l’image) sont prises en compte. Une approche similaire a été proposée par Liu et al. [Liu 08]. À partir de cartes de saillance normalisées, des régions saillantes sont détectées. Les auteurs proposent d’utiliser deux informations relatives à la saillance visuelle de ces régions pour la recherche d’images par le contenu. La première est un histogramme qui calcule la proportion de points dans chaque région ayant une certaine valeur de saillance par rapport à toute l’image. La seconde encode l’information spatiale du focus d’attention visuelle. Elle permet de calculer la proportion de saillance visuelle dans la région saillante. D’autres utilisations de la saillance sont exploitées pour des thématiques de recherche d’images par le contenu avec de la sémantique [Wang 10]. Conclusions Dans ce chapitre, nous avons présenté quelques solutions de la littérature pour la mise en œuvre d’une tâche de recherche d’images par le contenu. Nous avons abordé les deux grandes étapes de cette tâche à savoir la caractérisation des images par un ensemble de descripteurs et ensuite la comparaison des différentes signatures visuelles. Nous nous sommes focalisés sur les descripteurs de caractéristiques locales et quelques solutions de la littérature pour la création de signature visuelle. Mais on peut également considérer le vecteur de caractéristiques locales comme étant une signature et l’utiliser tel quel pour la recherche des plus proches voisins avec une méthode d’appariement. Nous avons également abordé l’utilisation d’informations du SVH telle que la saillance visuelle. Nous avons alors présenté le fonctionnement du SVH dans les grandes lignes depuis la réception du signal lumineux par la rétine jusqu’à son traitement par le cortex visuel primaire. Ceci nous a permis d’introduire les différents modèles de saillance et notamment un modèle cognitif : celui de Itti et Koch. Cette revue de littérature nous permet d’introduire nos contributions pour la recherche d’images par le contenu. Dans le chapitre suivant, nous aborderons une mé- thode de recherche d’images par le contenu qui inclut des informations de saillance en se basant sur le modèle de Itti présenté dans cette partie. L’idée est de tirer profit de l’attention visuelle. Pour ce faire, nous avons d’abord évalué l’impact de la pondération des vecteurs de descripteurs de caractéristiques locales par la saillance au cours d’une tâche d’indexation. Nous avons ensuite étudié la saillance visuelle des différents détecteurs de caractéristiques présentés dans cette partie. Pour finir, nous avons ajouté des caractéristiques locales à partir d’un modèle d’attention visuel. 38Chapitre 2 Notre approche pour l’indexation Sommaire 2.1 Bases d’images utilisées . . . . . . . . . . . . . . . . . . . . 40 2.2 Nos choix de descripteurs . . . . . . . . . . . . . . . . . . 42 2.3 Nouvelle méthode de construction du dictionnaire visuel : Iterative Random visual words Selection (IteRaSel) 42 2.4 Évaluations de IteRaSel . . . . . . . . . . . . . . . . . . . 45 2.4.1 Sélection aléatoire des mots . . . . . . . . . . . . . . . . . 45 2.4.2 Sélection aléatoire des mots visuels couplée à un processus itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.4.3 Stabilisation du processus aléatoire . . . . . . . . . . . . . 48 2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires 49 2.4.5 Comparaison avec l’état de l’art . . . . . . . . . . . . . . 50 2.4.6 Discussions autour des résultats . . . . . . . . . . . . . . . 52 2.5 Pondération des vecteurs de descripteurs par la saillance 53 2.6 Évaluation de la saillance de certains détecteurs de points clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.6.1 Saillance visuelle des caractéristiques locales . . . . . . . . 55 2.6.2 Discussions autour de ces premiers résultats . . . . . . . . 61 2.7 Étude de l’importance des points clés saillants . . . . . . 62 2.7.1 Impact de la suppression des points clés en fonction de leur saillance . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.7.2 Ajouts de points saillants . . . . . . . . . . . . . . . . . . 64 2.7.3 Discussions autour des travaux sur la saillance . . . . . . 65 Introduction Dans ce chapitre consacré à nos premières contributions, nous présenterons nos travaux sur la recherche d’images par le contenu. Nous avons pris le parti de ne pas proposer le système d’indexation le plus performant possible mais d’apporter de nouvelles façons d’indexer les images. Nous proposons, dans un premier temps, 39Chapitre 2. Notre approche pour l’indexation une nouvelle construction de dictionnaire visuel. Grâce à ce nouvel algorithme, nous arrivons à des résultats quasi-similaires à ceux de la littérature avec une taille de dictionnaire très petite (294 pour le descripteur ayant les meilleurs résultats contre une moyenne de 20 000 dans la littérature). Nous avons essentiellement opté pour une représentation des images à partir d’un "Sac de mots visuels". Nous avons, d’abord, comparé les résultats de cette nouvelle méthode de construction du vocabulaire visuel aux résultats d’un K-means. Ensuite nous avons choisi d’intégrer la saillance visuelle à nos travaux. Ceci s’est fait de deux façons : – Pondération du vecteur de descripteurs par la saillance visuelle de la caracté- ristique locale qu’il décrit, avant l’étape de BoVW ; – Étudier la saillance des points clés détectés et l’importance de ces points en fonction de leur saillance pour la tâche de reconnaissance d’images. 2.1 Bases d’images utilisées Dans la littérature il existe plusieurs bases d’images pour évaluer un système de reconnaissance d’images par le contenu. Elles sont de plus en plus grandes et diversifiées [Nistér 06, Everingham 07, Huiskes 08, Huiskes 10, Everingham 12]. Nous avons opté pour la base University of Kentucky Benchmark proposée par Nistér et Stewénius [Nistér 06] pour effectuer nos tests. Cette base sera notée "UKB" dans la suite pour simplifier la lecture. Malgré sa petite taille, 10 200 images comparées au million d’images de MIRFlickr 1M [Huiskes 10] par exemple, c’est une base qui présente trois principaux avantages : – Les images sont regroupées par 4 présentant le même objet avec des changements différents (opérations géométriques, modification du point de vue, des conditions d’éclairage, . . . ). Un exemple est donné par les images de la Figure 2.1 ; – C’est une base facile d’accès et beaucoup de résultats existent pour pouvoir faire une comparaison efficace. Dans notre cas, nous prendrons comme réfé- rence les résultats obtenus par Jégou et al. [Jégou 10b, Jégou 12] ; – Le calcul de score sur UKB est simple ; il suffit de compter le nombre d’images ressemblantes (incluant la requête) retrouvées parmi les 4 premières. Le score moyen sur UKB est donc donné sur 4. Par exemple, un score de 3.5 indique que 3.5 images en moyenne sont retrouvées sur les 4 identiques existantes. Nous avons également utilisé la base Pascal VOC 2012 [Everingham 12] essentiellement pour la construction du dictionnaire visuel afin d’avoir une variabilité importante des mots. En effet, c’est une base qui contient 17 125 images de scènes réelles appartenant à l’une des 20 classes d’objets (personne, oiseau, avion, voiture, chaise entre autres). Les images de la Figure 2.2 illustrent bien la variabilité de cette base. Chaque classe inclut des éléments très différents. La classe "Oiseau" contient différents animaux, des oiseaux en plein vol ou posés. C’est une base qui est traditionnellement utilisée en classification du fait de sa complexité. En effet, deux classes peuvent cohabiter sur une même image comme c’est le cas des images 2.2(e), 2.2(h), 2.2(i). Sur l’image 2.2(e) non seulement la voiture est tronquée mais en plus on y 40Chapitre 2. Notre approche pour l’indexation Figure 2.1: Exemple de 4 images similaires de la base UKB. (a) (b) (c) (d) (e) (f) (g) (h) (i) Figure 2.2: Quelques images de la base Pascal VOC2012. Les images (a)-(c) illustrent la classe "Oiseau", (d)-(f) la classe "Voiture" et (g)-(i) la classe "Personne". voit un vélo. Sur l’image 2.2(h) on aperçoit un pilote dans l’avion et sur l’image 2.2(i) la classe "Personne" cohabite avec la classe "Sofa". 41Chapitre 2. Notre approche pour l’indexation 2.2 Nos choix de descripteurs Nous avons choisi de juger l’efficacité et la précision de cinq descripteurs de caractéristiques locales dans notre solution de recherche d’images par le contenu. Il s’agit de : – CM (Colour Moments) : 24 dimensions ; – CMI (Colour Moment Invariants) : 30 dimensions ; – SIFT (Scale-Invariant Feature Transform) : 128 dimensions ; – SURF (Speeded Up Robust Feature) : 64 dimensions ; – Opponent-SIFT que nous noterons OpSIFT pour la présentation des résultats : 384 dimensions. Exceptés les descripteurs SURF, tous les autres ont été calculés avec le logiciel ColorDescriptor proposé par van de Sande et al. [van de Sande 10]. Nous avons choisi comme détecteur, celui de Harris-Laplace qui offre de très bonnes performances notamment dans les travaux de Zhang et al. [Zhang 07] dans le cadre d’une tâche de classification. Pour tous les descripteurs sauf pour SURF, la configuration de notre détecteur est la suivante : – k=0.06 ; – le seuil de la fonction de Harris est égal à 10−9 ; – le seuil pour le laplacien est égal 0.03. Les descripteurs SURF ont été calculés avec Opencv avec un seuil du Hessian fixé à 300 puisqu’ils intègrent leur propre schéma de détection des caractéristiques locales. Tous les détecteurs sont appliqués sur les images en niveaux de gris. Les descripteurs SIFT et SURF n’exploitent que l’information en niveaux de gris ce qui n’est pas le cas pour CM, CMI et OpponentSIFT. 2.3 Nouvelle méthode de construction du dictionnaire visuel : Iterative Random visual words Selection (IteRaSel) Comme nous l’avons mentionné dans le chapitre précédent, la technique "Sac de mots visuels" est l’une des méthodes les plus utilisées pour la création de la signature d’une image. En effet, c’est une solution facile à mettre en œuvre et qui offre des résultats satisfaisants. Son inconvénient majeur est de nécessiter d’un dictionnaire de grande taille. La méthode traditionnelle de construction de ce dictionnaire est l’algorithme K-means. L’utilisation de cet algorithme doit prendre en compte la dimensionnalité des descripteurs. En effet, son efficacité tend à baisser avec une dimensionnalité élévée, produisant même des résultats proches de l’aléatoire comme l’indiquent Parsons et al. [Parsons 04]. Nous proposons alors une construction du dictionnaire qui n’est pas sensible à ces problèmes de dimensionnalité. Elle est basée sur une sélection aléatoire des mots. Nous l’avons nommé Iterative Random visual words Selection (IteRaSel). Deux solutions s’offrent à nous pour construire notre vocabulaire visuel à partir d’une sélection aléatoire des mots : 42Chapitre 2. Notre approche pour l’indexation – Choisir de façon aléatoire un certain nombre de descripteurs et les considérer comme les mots visuels ; – Créer un vocabulaire visuel synthétique en prenant en compte la dimension des descripteurs. Nous avons choisi la première solution pour la sélection des mots visuels de façon aléatoire. Une fois les mots choisis, seuls ceux ayant un gain d’information intéressant appartiendront au dictionnaire visuel final. Dans notre cas, nous avons choisi un critère d’information en analogie avec le schéma de pondération tf-idf. Le gain d’information du mot w, noté IGw, est donné par : IGw = nwD nD log N nw | {z } tf−idf + P SalwD nwD | {z } Saillance visuelle , (2.1) avec nwD le nombre d’occurrences du mot w dans l’ensemble des descripteurs de points clés de toute la base d’images ; cet ensemble de descripteurs de points clés est noté D, nD le nombre total de points clés de la base, nw le nombre d’images contenant le mot w dans la base, N le nombre d’images dans la base et SalwD le score de saillance de tous les points clés de la base assignés au mot w. On reconnait dans l’expression de IGw, le facteur de pondération tf-idf (équation (1.14)) dans la première partie de la somme. Pour l’estimation de la saillance visuelle, nous avons choisi d’utiliser le modèle d’attention visuelle de Itti. Nos cartes de saillance ont été calculées avec le logiciel GBVS (Graph-Based Visual Saliency) [Harel ]. Les valeurs de saillance sont comprises entre 0 et 1 ; 0 pour une caractéristique locale non saillante et 1 pour le maximum de saillance. Cela correspond à un pixel en blanc sur la carte de saillance illustrée sur la Figure 2.3. (a) Image originale (b) Carte de saillance Figure 2.3: Illustration d’une carte de saillance. L’algorithme 2 décrit notre méthode de construction de vocabulaire visuel. L’étape de tri mentionnée dans notre algorithme permet de supprimer les mots visuels ayant très peu de gain d’information. Nous avons défini un seuil α permettant de faire cette suppression. Il a été fixé à 10% après de nombreux tests. Si certains mots visuels ont un gain d’information nul (ce qui est fort probable puisque les mots sont choisis dans une base différente de celle de tests ; dans notre cas Pascal VOC2012 pour les mots et UKB pour les test), alors à la première itération ils sont supprimés sans prendre en compte α. Nous avons également supprimé les mots visuels ayant un gain d’information trop important à la première itération. Un seuil a été fixé par rapport à la taille de la base. Ceci permet d’éliminer les informations 43Chapitre 2. Notre approche pour l’indexation Algorithme 2 : Construction du vocabulaire visuel avec IteRaSel Entrées : D, K la taille souhaitée du dictionnaire visuel Sorties : W le vocabulaire visuel final Initialisation de W en choisissant de façon aléatoire un ensemble de mots visuels; répéter Affecter chaque point clé de l’ensemble D au mot visuel dont il est le plus proche par rapport à la distance euclidienne; Calculer le gain d’information IGw de chaque mot w à l’aide de l’équation (2.1); Trier et supprimer des mots en fonction de leur valeur de gain d’information; jusqu’à Taille de W 3 donne des résultats similaires mais avec un temps de construction du dictionnaire plus important. Les résultats des différentes évaluations sont également donnés dans la Section suivante. Une fois le dictionnaire visuel obtenu, nous l’avons utilisé pour créer les signatures visuelles des images à l’aide d’un "Sac de mots visuels". Si la distance entre les vecteurs de descripteurs et les mots visuels a été évaluée à l’aide d’une distance euclidienne, nous avons estimé la similarité des signatures visuelles avec une distance χ 2 . 44Chapitre 2. Notre approche pour l’indexation 2.4 Évaluations de IteRaSel Tous les résultats que nous présenterons ici concernent la base UKB. Les mots ont été construits à partir de Pascal VOC2012. Pour faciliter la lecture nous proposons les facilités de notation suivantes : – BoVW correspond à une signature visuelle de type "Sac de mots visuels" obtenue avec un dictionnaire issu d’un K-means; – IteRaSel correspond à une signature visuelle de type "Sac de mots visuels" obtenue avec notre algorithme de construction du vocabulaire visuel. 2.4.1 Sélection aléatoire des mots Dans un premier temps, nous avons comparé les résultats d’un dictionnaire obtenu simplement avec une sélection aléatoire des mots à ceux obtenus avec un algorithme K-Means. Les signatures visuelles utilisées sont des "Sacs de mots visuels". Les résultats sont illustrés sur la Figure 2.4. Seul le comportement de trois descripteurs est illustré, les deux autres ont le même comportement. Figure 2.4: Sélection aléatoire des mots visuels vs K-means. Sur ce graphique CMI correspond aux résultats obtenus avec un dictionnaire obtenu avec K-Means et randCMI à ceux obtenus avec une sélection aléatoire des mots dans l’ensemble des descripteurs des images de la base de construction des mots. Il en est de même pour les autres descripteurs. On remarque globalement, que BoVW obtient de meilleurs résultats pour les dictionnaires de petites tailles. Pour des tailles de dictionnaires plus importantes, une simple sélection aléatoire des mots permet d’avoir des scores équivalents. Il s’agit 45Chapitre 2. Notre approche pour l’indexation là d’un résultat très intéressant puisque la création d’un dictionnaire à partir d’un processus aléatoire prend beaucoup moins de temps. 2.4.2 Sélection aléatoire des mots visuels couplée à un processus itératif Si on se réfère à la Figure 2.4, le descripteur CMI est celui qui atteint les meilleurs résultats, tant avec un dictionnaire issu de K-Means qu’avec une sélection aléatoire des mots visuels. Nous nous focaliserons donc sur les résultats avec ce descripteur pour présenter l’impact du processus itératif sur la tâche de reconnaissance d’images sur UKB. Comme nous l’avons conclu précédemment de la Figure 2.4, la sélection aléatoire des mots obtient des résultats similaires à K-Means pour des dictionnaires de grande taille. Nous avons alors étudié le comportement du vocabulaire de mots visuels aléatoire en intégrant le processus itératif de construction du dictionnaire à l’aide de l’Algorithme 2. Figure 2.5: Construction du dictionnaire final de façon itérative en partant de plusieurs dictionnaires visuels de 2048 mots choisis de façon aléatoire. Entre 150 et 250 mots visuels les résultats sont constamment compris entre 3.05 et 3.15. La Figure 2.5 présente les résultats de plusieurs dictionnaires visuels construits de façon itérative à partir de 2048 mots visuels. Il faut noter que la taille des dictionnaires finaux n’est pas toujours identique en utilisant à chaque fois 2048 mots. Elle dépend du nombre de mots qui auront été supprimés pendant le processus. On peut mettre en évidence deux constatations : 1. Les résultats sont très stables. En effet, à partir d’un vocabulaire aléatoire, pour un nombre final donné de mots, le score moyen se situe dans une fenêtre 46Chapitre 2. Notre approche pour l’indexation très étroite. Par exemple, entre 150 et 250 mots, la valeur du score varie de 3.05 et 3.15 environ en sachant que le score maximal est de 4 ; 2. On atteint un score moyen élevé quelle que soit la taille des différents dictionnaires. Dans les précédents résultats précédents (Figure 2.4), ni BoVW ni la sélection aléatoire de vocabulaire n’a donné un score supérieur à 3. Le fait de procéder à une construction itérative permet donc d’améliorer l’indexation. Nous avons également étudié l’impact de la taille de l’ensemble aléatoire de mots visuels de départ. Pour cela nous avons choisi de tester des dictionnaires initiaux de taille appartenant à l’ensemble {1024, 2048, 4096, 8192, 16 384, 32 768, 65 536}. Les résultats sont illustrés par la Figure 2.6. Figure 2.6: Étude de l’impact de la taille du dictionnaire visuel aléatoire initial. Pour obtenir ces résultats, nous avons créé 10 dictionnaires visuels aléatoires pour chaque taille. Pour chaque taille, nous avons lancé l’Algorithme 2 10 fois, le score présenté est donc la moyenne des 10 scores moyens (un score sur 4 étant obtenu pour chacune des 10 200 images) pour chaque taille de dictionnaire visuel initial. Pour chacun de ces dictionnaires, nous avons généré des vocabulaires finaux de tailles comprises entre 50 et 500, par pas de 50. Les scores de chacun de ces dictionnaires visuels finaux sont donc des moyennes. On note un réel impact du nombre de mots initial sur l’ensemble des résultats. D’un côté, commencer la construction du dictionnaire avec 1024 mots n’est pas suffisant. D’autre part, utiliser un dictionnaire initial de plus de 4096 mots n’a aucune conséquence effective. Nous avons alors choisi ce seuil comme étant la taille maximale de notre dictionnaire initial. Comme nous l’avons évoqué dans la Section 2.3, nous avons opté pour une combinaison des vocabulaires visuels pour pallier l’instabilité de notre algorithme que pourrait induire le tirage aléatoire. 47Chapitre 2. Notre approche pour l’indexation 2.4.3 Stabilisation du processus aléatoire Puisque l’algorithme de construction de notre vocabulaire de mots visuels se base sur un processus aléatoire, il faut plusieurs tirages pour assurer une certaine stabilité du dictionnaire final. En plus du fait de générer plusieurs dictionnaires visuels initiaux, nous avons décidé de combiner les dictionnaires résultant de chaque tirage. Ce nouveau dictionnaire sert d’entrée à l’algorithme pour construire un nouveau dictionnaire qui sera utilisé pour calculer les signatures visuelles des images. Nous avons testé l’impact du nombre de dictionnaires combinés que nous avons nommé β dans la Section 2.3 en le faisant varier de 2 à 10. Comme précédemment, les résultats présentés ici ne concerne que le descripteur CMI. Figure 2.7: Score moyen obtenu après la combinaison des dictionnaires dans plusieurs configurations : β = {2, . . . , 9, 10}. Les dictionnaires ont été générés à partir de 1024, 2048 et 4196 mots visuels choisis de façon aléatoire. La Figure 2.7 illustre l’intérêt de grouper les dictionnaires pour en déduire un unique. On y voit que quelle que soit la taille du vocabulaire de mots visuels initial, les scores augmentent avec β, notamment de β = 2 à β = 3. Au delà de 3, les résultats évoluent très peu ce qui nous permet de conclure que β = 3 est un très bon compromis pour UKB. De plus, ce compromis permet de gagner sensiblement en temps de construction du dictionnaire par rapport à β = 8 par exemple. Nous avons testé d’autres techniques de combinaison des dictionnaires notamment : combiner les vocabulaires donnant les meilleurs scores moyens ou encore combiner plusieurs vocabulaires déjà issus d’un processus de combinaison. Aucune de ces méthodes n’a donné des résultats très concluants. Nous avons donc retenu cette technique de combinaison pour la stabilisation de l’algorithme d’autant plus qu’elle 48Chapitre 2. Notre approche pour l’indexation est facilement reproductible. Une fois l’algorithme définitif établi, nous avons étudié plus précisément le comportement de chacun des descripteurs que nous avons choisis. 2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires Les dictionnaires visuels utilisés pour tous les résultats présentés ici ont été obtenus de la façon suivante : 1. Sélection d’un ensemble de 4096 mots de façon aléatoire dans l’ensemble D des descripteurs des images de la base Pascal VOC2012 ; 2. Construction d’un vocabulaire visuel à partir de l’Algorithme 2 ; 3. Les étapes 1 et 2 sont répétées 2 fois conduisant ainsi à 3 vocabulaires visuels ; 4. Les trois vocabulaires visuels sont utilisés pour créer un dictionnaire final ; Une fois le vocabulaire visuel final obtenu, les "Sacs de mots visuels" des images de UKB sont construits. Ces signatures visuelles sont comparées avec une distance χ 2 . Les résultats obtenus avec les descripteurs que nous avons choisis sont donnés dans le Tableau 2.1. Tableau 2.1: Scores moyens sur UKB. K-Means et IteRaSel correspondent à l’algorithme utilisé pour construire le dictionnaire visuel. Descripteurs K-Means IteRaSel %(IteRaSel/K-Means) CMI 2.95 (K=2048) 3.22 (K=294) +7.4% CM 2.62 (K=2048) 2.81 (K=265) +7% SURF 2.69 (K=2048) 2.75 (K=253) +2.75% OpSIFT 2.30 (K=2048) 2.46 (K=159) +6.9% SIFT 2.19 (K=2048) 2.30 (K=187) +6.5% Quel que soit le descripteur, les résultats obtenus avec notre dictionnaire sont meilleurs comparés à ceux obtenus avec K-Means bien que K soit plus petit dans le cas de IteRaSel. Pour tous les descripteurs sauf SURF, nous obtenons une amélioration des résultats d’environ 7%. Pour les descripteurs SURF, l’amélioration est de près de 3%. Ceci démontre que notre méthode de sélection itérative des mots visuels est meilleure. Sans aucune connaissance a priori des descripteurs (dimensionnalité notamment), on améliore les résultats de K-means. Ces résultats sont d’autant plus intéressants que les descripteurs qui obtiennent les meilleurs scores moyens sont de petite dimensionnalité : 24 pour CMI (3.22) et 30 pour CM 1 (2.81). Nous avons focalisé la suite de nos travaux sur le descripteur CMI qui a l’avantage d’offrir des bons résultats pour une très petite taille comparé à SIFT ou ses extensions couleur. La Figure 2.8 présente les résultats de l’étude de l’impact de la 1. Les 3 moments d’ordre 0 sont inclus. 49Chapitre 2. Notre approche pour l’indexation Figure 2.8: Score moyen obtenu avec des dictionnaires finaux de plusieurs tailles générés à partir d’un dictionnaire de taille 4096. La courbe en rouge correspond à une tendance de l’ensemble des nuages de points. taille du dictionnaire final comprise entre 50 et 500 en utilisant un vocabulaire visuel initial composée de 4096 mots. La première conclusion en l’analysant est qu’on atteint de très bons résultats avec très peu de mots visuels : entre 250 et 300. On remarque également qu’on obtient un score moyen de 3 pour des dictionnaires de très petites tailles : entre 50 et 100. Ce résultat est très encourageant et très intéressant puisqu’il est bien supérieur à ceux qu’on obtient avec un dictionnaire de taille 2048 construit à partir d’un K-means (cf. Figure 2.4). Nous avons ensuite comparé nos résultats à certains obtenus dans la littérature. Nos comparaisons se feront essentiellement avec les signatures visuelles VLAD et FV que nous avons présentées dans le chapitre précédent. 2.4.5 Comparaison avec l’état de l’art Comme nous l’avons annoncé précédemment, nous ne présenterons que les résultats obtenus avec le descripteur CMI qui est celui qui obtient les meilleurs résultats dans nos expérimentations. On pourrait nous reprocher de ne pas nous attarder sur le descripteur SIFT largement utilisés dans la littérature, mais ils le sont à partir d’un vocabulaire de taille beaucoup plus importante que celle que nous visons [Jégou 10b, Jégou 12] dans une approche BoVW. Les meilleurs résultats obtenus avec les SIFT proviennent de signatures visuelles différentes : vocabulary trees [Nistér 06], VLAD et FV [Jégou 10b, Jégou 12]. En effet, ces techniques de construction de signatures visuelles conservent beaucoup plus d’informations qu’un simple comptage des occurrences d’un pattern visuel. Les résultats que nous allons présenter en ce qui concerne IteRaSel n’incluent au- 50Chapitre 2. Notre approche pour l’indexation cune normalisation des histogrammes de fréquence des mots visuels. En effet, lors de la normalisation L2 de nos histogrammes, nous avons constaté une baisse de nos résultats de 3.22 à 3.07 malgré le fait qu’elle soit souvent utilisée dans la littérature [Jégou 10b, Jégou 12]. Nous aborderons dans la dernière partie, nos différents tests de normalisation et leurs résultats. Nos résultats sans aucune normalisation Les scores présentés dans le Tableau 2.2 sont les meilleurs obtenus dans chacun des articles cités pour la méthode de création de signature visuelle. Le descripteur utilisé dans ces articles de la littérature est SIFT. Tableau 2.2: Comparaison de notre meilleur score moyen avec quelques uns de la littérature. FV correspond à la signature visuel "Vecteur de Fisher". Signature visuelle Meilleur score FV[Jégou 12] (SIFT K=256) 3.47 IteRaSel (CMI K=294) 3.22 VLAD [Jégou 10b] (SIFT K=64) 3.17 BoVW (CMI K=2048) 2.95 BoVW [Jégou 12] (SIFT K=20 000) 2.87 Les dictionnaires obtenus avec IteRaSel sont de tailles différentes pour tous les descripteurs. En effet, le nombre souhaité était de 256 mais avec le processus itératif et la suppression des mots, ce nombre optimum n’est pas toujours atteint. Si à une itération i on a une taille K ′ i > 256 et qu’à i + 1, K ′ i+1 < 256 alors on conservera le dictionnaire obtenu à l’itération i. En analysant le Tableau 2.2, on remarque que toutes les autres signatures visuelles obtiennent de meilleurs résultats comparées à BoVW malgré la taille de leur dictionnaire. La première conclusion est que les résultats d’une méthode utilisant la technique "Sac de mots visuels" (compter l’occurrence des mots visuels) dépendent énormément du vocabulaire visuel donc de sa construction. Certes, les VLAD ont été construits avec un dictionnaire visuel de très petite taille (64 mots) comparé au nôtre (294 mots) mais nos premiers résultats sont très encourageants. En effet, VLAD intègre plus d’informations que la signature "Sac de mots visuels". Évaluation de l’impact de la normalisation sur nos résultats Soit nbKP le nombre de points clés dans une image, nous avons testé des normalisations définies de la façon suivante : norm = (nbKP ) p , p ∈ {0, 0.1, 0.2, . . . , 0.9, 1}. (2.2) Notons que si p=1, il s’agit d’une normalisation L1 et si p=0, aucune normalisation n’est effectuée. Le facteur de normalisation a un grand impact sur les résultats comme le démontre 51Chapitre 2. Notre approche pour l’indexation Figure 2.9: Impact de la normalisation sur le score moyen. la Figure 2.9. On y voit que la valeur de p influence le score moyen final. Pour p=0, le cas dans lequel nous nous sommes placés précédemment pour comparer nos travaux à la littérature, on a l’un des plus bas scores. Pour toutes les distances évaluées, entre p=0 et 1, le score évolue atteignant son maximum dans l’intervalle [0.5, 1]. L’impact de la normalisation peut paraître infirme mais l’échelle étant de 4 sur UKB, le gain en reconnaissance est intéressant. Dans le cas de la distance χ 2 que nous avons utilisée pour la comparaison de nos signatures visuelles, entre le meilleur score moyen (p=0.6) et le cas p=0, on note une amélioration des résultats de 3.5%. À partir de cette étude, nous avons donc choisi notre score moyen de référence à p=0.5 : 3.35. Comme on peut également le voir sur cette Figure 2.9, le choix de la distance a un réel impact. Entre la distance L2 et la distance χ 2 , le gain est d’environ 17.6% quel que soit le facteur de normalisation. 2.4.6 Discussions autour des résultats Les résultats présentés dans toute la Section 2.4 montrent que l’approche de construction de dictionnaire que nous proposons permet d’améliorer les résultats obtenus avec un BoVW et ceci quel que soit le descripteur. Notre construction de vocabulaire visuel est très simple et pourtant les résultats obtenus sont proches des meilleurs de la littérature : 3.35 si on normalise nos histogrammes avec 294 mots et 3.47 avec FV pour un dictionnaire de 256 mots visuels. Ce taux de classification moyen est d’autant plus intéressant que la signature visuelle BoVW prend en compte très peu d’informations. Si le vocabulaire visuel est de taille K, la représentation BoVW contiendra K valeurs alors qu’un FV contient K*D (D étant la dimension du descripteurs) valeurs. La stabilité des résultats malgré le tirage aléatoire du début prouve leur répétabilité. Les autres intérêts de la méthode proposée concernent son indépendance de la dimensionnalité du descripteur ainsi que sa prise en compte de la variabilité de la base de tests. On peut déduire de nos différentes expérimentations que la sélection aléatoire des mots visuels d’une base d’images hétérogène peut donner d’aussi bons, voire de meilleurs résultats, qu’un K-Means. 52Chapitre 2. Notre approche pour l’indexation Nous ne l’avons pas abordé, mais nous avons testé le choix des mots à partir de la base UKB. Les différents scores moyens sont un peu plus bas (3.03) pour CMI ce qui indique que les mots doivent décrire une variabilité intéressante. L’hétérogénéité de la base d’images de sélection des mots est donc très importante. Une dernière conclusion à nos travaux concerne le descripteur CMI. C’est un descripteur qui n’est pas très plébiscité dans la littérature par rapport à SIFT qui cependant sur UKB, dans nos expérimentations, se révèle comme ayant les plus hauts scores de reconnaissance. Ceci pourrait être lié aux contenus des images de UKB. Les couleurs et leurs invariances suffiraient peut-être à représenter les différents objets/scènes. Notons quand même que dans la littérature, lorsque le descripteur SIFT est utilisé sur UKB, les meilleurs résultats sont obtenus avec VLAD ou FV. Cela voudrait peut-être dire que les 128 dimensions de SIFT encodent des informations de manière beaucoup plus fine et qu’il n’y a donc aucun intérêt à les représenter par un histogramme. Les différentes réductions de dimensionnalité qui sont faites pour passer de 128 à 64 [Jégou 10b, Jégou 12] et qui permettent d’avoir de meilleurs résultats sont aussi une piste de réflexion sur la nécessité des descripteurs de dimensions de plus en plus grandes. Dans la suite de ces travaux sur l’indexation, nous intègrerons l’apport du SVH en étudiant l’impact de la saillance visuelle dans nos expérimentations. Nous avons travaillé uniquement avec le descripteur CMI. Puisque la saillance visuelle n’est pas une information qui modifie la nature du descripteur de caractéristique locale, a priori, si les résultats s’améliorent, ils devraient avoir le même comportement avec un autre descripteur. La première façon d’utiliser la saillance visuelle, que nous avons testée, est la pondération des vecteurs de descripteurs par la valeur de la saillance visuelle de chaque caractéristique locale. Nous avons utilisé le modèle de saillance visuel proposé par Itti et al. [Itti 98] qui est le même que celui utilisé pour la construction du vocabulaire visuel dans l’algorithme IteRaSel. 2.5 Pondération des vecteurs de descripteurs par la saillance Nous avons pondéré chaque vecteur de descripteurs par la saillance de la caractéristique locale qu’il décrit avant de construire les sacs de mots. D’un point de vue score moyen, nous n’avons observé aucun changement des résultats obtenus sur UKB. On obtient le même score moyen avec ou sans la pondération par la saillance. La première conclusion de ce résultat est que la pondération des vecteurs de descripteurs par la saillance des caractéristiques qu’ils décrivent n’est pas une façon efficace d’utiliser cette information du système visuel humain. Cette conclusion n’est valable que sur la base UKB et pour le descripteur CMI. Nous pensons néanmoins que cela devrait être similaire quel que soit le descripteur puisque le facteur de pondération est le même. Nous avons alors essayé d’étudier l’apport de la saillance malgré le score moyen inchangé. Nous avons remarqué que les scores moyens ne sont pas les mêmes pour chaque image. Il y a donc bien un impact en utilisant ce système de pondération. 53Chapitre 2. Notre approche pour l’indexation Pour en savoir plus, nous avons regardé de plus près le rang des 4 images ressemblantes après la recherche des plus proches voisins. En effet, utilisant l’algorithme des K (K=4 pour UKB) plus proches voisins, toutes les 10 200 images de la base sont ordonnées en fonction de leur distance à la requête. Chacune d’elle se voit donc affecter un rang allant de 0 à 10 199. Figure 2.10: Étude du rang des images ressemblantes en pondérant les vecteurs de descripteurs par la saillance du point décrit. La notation AS signifie "Avec ondération par la saillance" et SS "Sans pondération". La Figure 2.10 illustre l’étude de la somme des 4 rangs. Nous avons fait cette étude pour trois valeurs différentes de p : 0, 0.5 et 1 définissant le facteur de normalisation des histogrammes donné par l’équation (2.2). En analysant ce graphique, on confirme la conclusion précédente. La pondération des vecteurs de caractéristiques par la saillance des points clés n’affecte pas énormément le résultat. En effet, pour les 3 normalisations étudiées, dans au moins 72% des cas les images retrouvées sont les mêmes. En effet : – Quand la somme des rangs est la même (le cas AS=SS), les 4 premières images retrouvées sont les bonnes ; – Quand la somme des rangs dans une configuration (AS ou SS) est inférieure à celle de l’autre configuration, alors au moins une image n’est pas parmi les 4 premières. La pondération par la saillance entraîne certes de moins bons résultats mais ceci dans de très faibles proportions (4%) maximum. Ces derniers sont compensés par les cas dans lesquels la pondération par la saillance améliore les rangs des 4 images ressemblantes. 54Chapitre 2. Notre approche pour l’indexation On peut conclure de cette étude des rangs des images que la pondération des vecteurs de caractéristiques par la saillance ne change en rien les résultats d’un point de vue score moyen des 4 images similaires. Elle permet néanmoins d’améliorer leurs rangs parmi les 10 200 images de la base. Puisque la pondération par la saillance des vecteurs de caractéristiques n’a aucun effet sur le score moyen, nous avons décidé d’étudier de plus près la saillance des détecteurs des points clés. En effet, les résultats précédents sous-entendent une hypothèse : les points clés trouvés avec le détecteur de Harris-Laplace ont une saillance équivalente, ce qui reviendrait à appliquer quasiment le même facteur de normalisation à tous les vecteurs de descripteurs. Pour vérifier cette hypothèse, nous avons évalué la saillance des points clés détectés par quatre détecteurs. 2.6 Évaluation de la saillance de certains détecteurs de points clés Nous avons effectué cette étude sur quatre bases d’images dont les deux bases que nous avons présentées dans la Section 2.1. Les deux autres bases sont des bases conçues pour l’étude de la saillance visuelle : – La base d’images de Le Meur et Baccino [Le Meur 06] qui contient 27 images ; notée LeMeur ; – La base d’images de Kootstra et al. [Kootstra 11] qui contient 101 images ; notée Kootstra. Les détecteurs évalués sont les suivants : – Harris ; – Harris-Laplace ; – DoG ; – FAST ; Les paramètres utilisés sont les mêmes que ceux utilisés pour la Figure 1.4 dans le chapitre précédent (1.1.2). 2.6.1 Saillance visuelle des caractéristiques locales Pour évaluer la saillance des points, nous avons défini un seuil à partir duquel on peut dire qu’un point est saillant ou non. Nos valeurs de saillance visuelles étant comprises entre 0 et 1, un seuil intuitif pourrait donc être 0.5. Nous avons préféré dé- terminé un seuil expérimental qui permet de définir une région saillante intéressante (reconnaissance de l’objet, de la scène). Nous avons testé plusieurs valeurs comprises entre 0.3 et 0.6. Certains sont illustrés sur la Figure 2.11. Nous avons choisi de le fixer à 0.4. En effet, cette valeur permet de pouvoir deviner plus facilement sur une grande partie des images l’objet (la scène) comparé à 0.5 par exemple. À l’inverse 0.3 est un peu trop bas. Un pixel sera donc considéré comme saillant si son intensité dans la carte de saillance est supérieure ou égale à 0.4. Le fait d’inclure des bases d’images traditionnellement utilisées pour l’étude de la saillance visuelle nous permet de vérifier l’indépendance de nos résultats à la nature de la base. 55Chapitre 2. Notre approche pour l’indexation (a) Image originale (b) t=0.3 (c) t=0.4 (d) t=0.5 Figure 2.11: Illustration du test de quelques seuils de saillance sur l’image. Nous avons choisi d’utiliser des graphiques de type "Boîtes à moustaches" pour illustrer cette étude. Sur ces graphiques, la ligne horizontale correspond à la valeur médiane de l’ensemble. Les valeurs représentées en rouge sont les "outliers". Leurs valeurs ne sont pas comprises dans l’intervalle : [(q1 − w(q3 − q1)),(q3 + w(q3 − q1))] , (2.3) avec q1 et q3 représentant respectivement les premier et troisième quartiles. Nous avons choisi w égal à 1.5, cette valeur correspondant à peu près à ±2.7σ et prendrait en compte 99.3% des données si elles suivent une loi normale. 2 Avant d’étudier la répartition de la saillance des points clés détectés, nous avons évalué la quantité de pixels saillants au vu du seuil que nous avons défini dans les 4 bases d’images. Sur la Figure 2.12, nous avons quantifié en 10 valeurs de façon uniforme la saillance. Cette opération nous permet d’étudier la distribution des pixels en fonction de la saillance. Le pourcentage d’"outliers" correspondant à la quantité d’informations a été calculé par rapport aux données initiales. Par exemple pour la base LeMeur composée de 27 images, on dispose de 270 (27x10 intervalles) valeurs. 1.48% indique que 4 valeurs sur les 270 ne rentrent pas dans l’intervalle défini par l’équation (2.3). Même si pour les bases UKB et Pascal VOC2012 il semble qu’il y ait un nombre important de points aberrants ("outliers"), en regardant leur taux (1.48% pour LeMeur, 1.58% pour Kootstra, 2.28% pour UKB et 1.99% pour Pascal VOC2012), on se rend compte qu’on reste dans les mêmes proportions. En effet sur UKB et Pascal VOC2012 il y a beaucoup plus d’images (10 200 pour UKB contre 27 pour LeMeur). Les "outliers" présents sur cette figure sont dus au fait que certaines images comportent plus d’informations saillantes que d’autres au sein d’une même base. Ce graphique est une première analyse globale des bases d’images. Pour les 4 bases d’images, le premier intervalle [0, 0.1] est celui qui a la médiane m la plus élevée : m > 30% pour LeMeur, m > 20% pour Kootstra, m > 40% pour UKB et 2. C’est la valeur qui est souvent utilisée par défaut. 56Chapitre 2. Notre approche pour l’indexation [0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1] 010203040506070 80 90 Quantification de la valeur de la saillance Pourcentage de pixels par intervalle (%) (a) LeMeur : 1.48% d’outliers [0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1] 0 10 20 30 40 50 60 70 80 90 Quantification de la valeur de la saillance Pourcentage de pixels par intervalle (%) (b) Kootstra : 1.58% d’outliers [0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1] 0 10 20 30 40 50 60 70 80 90 Quantification de la valeur de la saillance Pourcentage de pixels par intervalle (%) (c) UKB : 2.28% d’outliers [0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1] 0 10 20 30 40 50 60 70 80 90 Quantification de la valeur de la saillance Pourcentage de pixels par intervalle (%) (d) Pascal VOC2012 : 1.99% d’outliers Figure 2.12: Répartition des valeurs de saillance visuelle des images des 4 bases choisies. 57Chapitre 2. Notre approche pour l’indexation LeMeur Kootstra UKB Pascal VOC2012 0 10 20 30 40 50 60 70 80 90 100 Différentes bases Pourcentage de caractéristiques locales (%) Figure 2.13: Pourcentage des pixels ayant une saillance visuelle ≥ 0.4. m ∼ 30% pour Pascal VOC2012. Ces premiers résultats sont cohérents dans la mesure où, un modèle de saillance est sensé imiter notre système d’attention visuelle en sélectionnant très peu d’informations mais les plus pertinentes. Nous pourrions donc déjà conclure, que globalement, UKB et Pascal VOC2012 ne comportent pas énormément d’informations saillantes comparées aux bases LeMeur et Kootstra. Cette première conclusion se base sur les proportions de pixels présents dans le premier intervalle mais également dans les autres. Si nous nous intéressons aux taux de pixels saillants (≥ 0.4), les conclusions de la Figure 2.13 confirment les précédentes. En effet, les bases LeMeur et Kootstra ont les valeurs médianes les plus élevées. Ceci se comprend aisément puisque ce sont des bases d’images conçues pour les travaux sur la saillance visuelle. Les bases UKB et Pascal VOC2012 peuvent contenir plusieurs informations visuellement attractives de tailles différentes liées à la complexité de la scène ou aux différents objets. Notons également que la taille des objets ou des régions visuellement saillantes joue un rôle important dans ces résultats. Même si le pourcentage de pixels saillants est plus important sur LeMeur et Kootstra, globalement sur les 4 bases d’images la conclusion est la même : très peu de pixels ont une valeur de saillance visuelle supérieure ou égale à 0.4. Le fait que ces bases d’images contiennent globalement peu d’informations saillantes permet d’émettre la même hypothèse par rapport aux comportements des détecteurs : très peu de points détectés seront saillants. Dans la suite, nous nous sommes intéressés au comportement des détecteurs. Cette étude nous permettra de déterminer celui qui permet d’extraire le plus de points saillants dans les configurations que nous avons utilisées. Le but ici n’est pas de trouver la meilleure configuration des différents paramètres entrant en jeu dans le calcul des caractéristiques locales pour avoir de meilleurs résultats. Nous avons pris les valeurs par défaut proposées par les différents auteurs en supposant qu’elles correspondent à une certaine optimisation moyenne. Nous rappelons ici que le fait qu’un détecteur produise plus ou moins de points saillants n’est pas forcément lié à sa performance en matière de reconnaissance d’image par le contenu. Ce paramètre 58Chapitre 2. Notre approche pour l’indexation n’est d’ailleurs aucunement pris en compte dans l’évaluation des détecteurs à travers les différentes métriques de la littérature. (a) 393 216 pixels (b) 2716 points détectés (c) Carte de saillance 27.58% Pix et 51.36% KP (d) 196 608 pixels (e) 1519 points détectés (f) Carte de saillance 36.04% Pix et 74.52% KP (g) 307 200 pixels (h) 7 points détectés (i) Carte de saillance 9.57% Pix et 100% KP (j) 166 500 pixels (k) 9 points détectés (l) Carte de saillance 1.37% Pix et 100% KP Figure 2.14: Exemple d’une image par base pour illustrer la non corrélation entre le nombre de pixels ayant une saillance ≥ 0.4 dans l’image et celui de caractéristiques locales. Pour cette illustration, les caractéristiques locales sont extraites avec le détecteur de HarrisLaplace. Sur la première ligne, il s’agit d’une image de la base LeMeur, sur la deuxième d’une de la base Kootstra, sur la troisième de UKB et sur la dernière une de Pascal VOC2012. % Pix correspond au pourcentage de pixels dans l’image ayant une saillance ≥ 0.4 et %KP à celui des caractéristiques locales détectées remplissant les mêmes conditions. Nous tenons à préciser que nous avons étudié la corrélation entre le nombre de pixels ayant une valeur de saillance supérieure ou égale à 0.4 et celui de points clés respectant la même condition, et aucun lien n’a été trouvé. Le nombre de caractéristiques 59Chapitre 2. Notre approche pour l’indexation LeMeur Kootstra UKB Pascal VOC2012 0102030405060708090 100 Différentes bases Pourcentage de pixels (%) (a) Harris LeMeur Kootstra UKB Pascal VOC2012 0 10 20 30 40 50 60 70 80 90 100 Différentes bases Pourcentage de pixels (%) (b) Harris-Laplace LeMeur Kootstra UKB Pascal VOC2012 0 10 20 30 40 50 60 70 80 90 100 Différentes bases Pourcentage de pixels (%) (c) DOG LeMeur Kootstra UKB Pascal VOC2012 0 10 20 30 40 50 60 70 80 90 100 Différentes bases Pourcentage de pixels (%) (d) FAST Figure 2.15: Illustration de la répartition des points clés saillants des 4 bases choisies. 60Chapitre 2. Notre approche pour l’indexation est avant tout lié au contenu de l’image. La Figure 2.14 l’illustre bien. Les images que nous avons choisies sur cette figure ont un pourcentage relativement faible de pixels saillants et pourtant une grande partie (≥ 50%) des points clés détectés est saillante. Les images 2.14(g) et 2.14(j) illustrent bien la nécessité d’une certaine variation géométrique pour la détection des caractéristiques locales. L’autre conclusion, en observant les images de la Figure 2.14, est que si l’image recherchée est constituée d’un objet placé sur un fond homogène, malgré le peu de caractéristiques locales détectées, elles seront potentiellement saillantes. Les résultats de l’étude de la saillance visuelle des différentes caractéristiques locales sont présentés sur les graphiques de la Figure 2.15. Si on fait la moyenne des différentes médianes m, on obtient : m ∼ 50% pour Harris, m ∼ 32% pour Harris-Laplace, m ∼ 35% pour DoG et m ∼ 37% pour FAST. La première remarque concerne le détecteur de Harris. Ce dernier apparaît comme celui qui extrait le plus de points clés saillants malgré la nature des images de ces bases. On pourrait l’expliquer par le fait que ce détecteur mesure des différences d’intensités dans l’espace de l’image qui représenteraient une mesure de contraste intéressante pour capter la saillance visuelle. La différence entre les trois autres détecteurs est minime. Les ré- sultats de Harris-Laplace et DoG pourraient s’expliquer par le changement d’échelle qu’ils intègrent. Le détecteur Harris-Laplace bien qu’il soit présenté comme meilleur dans la littérature à celui de Harris par sa robustesse au changement d’échelle est globalement celui qui produit le moins de points clés saillants. Ces conclusions ne font que confirmer que les notions de saillance et de pertinence/importance peuvent être liées mais pas forcément interdépendantes. 2.6.2 Discussions autour de ces premiers résultats L’étude de la saillance visuelle des points clés que nous avons proposée n’avait jamais été faite et permet de mieux appréhender les détecteurs que nous avons utilisés. En conclusion générale à cette étude, on peut dire que, majoritairement, les détecteurs que nous avons choisis n’extraient que peu d’informations visuellement saillantes. Celles-ci peuvent être utiles si la tâche et la base le permettent. Si, dans la base d’images utilisée, les points saillants sont pertinents pour la reconnaissance d’images alors nous pensons que la saillance visuelle peut être utile pour du filtrage de points clés. D’ailleurs, Zdziarski et al. [Zdziarski 12] ont utilisé la saillance visuelle pour sélectionner les caractéristiques locales. En utilisant le descripteur SURF, la réduction du nombre de caractéristiques ne diminuait pas significativement les performances du classifieur. Ces premiers travaux présagent alors que la saillance visuelle peut très bien être incluse dans les solutions actuelles sans affecter leurs performances. Cette notion de filtrage est d’autant plus intéressante que, dans la littérature, l’échantillonnage dense est de plus en plus utilisé pour améliorer les performances des différents modèles [Gordoa 12, Delhumeau 13]. Si la saillance visuelle permet à l’humain de pouvoir catégoriser en un laps de temps très court des images, elle pourrait alléger les vecteurs de caractéristiques. Il s’agit évidemment d’un raccourci puisque dans la réalité, la reconnaissance et la catégorisation font appel à d’autres processus cognitifs. 61Chapitre 2. Notre approche pour l’indexation Nous pensons également que la saillance visuelle peut être utile pour ajouter des informations intéressantes dans certains cas. Ainsi, certains détecteurs de la litté- rature ont des limites notamment sur des images présentant très peu d’information géométrique : le cas de l’image 2.14(j) par exemple. L’une des solutions est de mettre en place une détection dense ou tout au moins de rajouter des points. Nous proposons alors d’ajouter des points en prenant en compte les spécificités des différents détecteurs. Le détecteur Harris-Laplace a priori est un bon compromis, ne serait-ce que sur UKB et Pascal VOC2012, pour ajouter des points saillants puisqu’il est celui qui en détecte le moins. Nous étudierons l’impact de cette opération dans la section suivante. Dans la suite la notion de saillance n’est plus définie par rapport au précédent seuil choisi de 0.4. Nous avons ordonné les pixels en fonction de leur saillance visuelle. 2.7 Étude de l’importance des points clés saillants Nous avons évalué l’importance des points clés en fonction de la valeur de leur saillance visuelle. Pour ce faire, nous avons procédé de deux façons : – Supprimer des points clés en fonction de leur saillance ; – Ajouter des caractéristiques locales visuellement saillantes. Cette étude s’est faite dans deux configurations. Dans un premier temps, nous avons travaillé avec les caractéristiques locales détectées avec Harris-Laplace et pour finir nous avons comparé les résultats à une détection dense. Pour cette quantification dense, nous avons utilisé une fenêtre de taille 15*15 tous les 6 pixels [van de Sande 10]. Sur les images de UKB de taille 640*480, nous obtenons 8190 caractéristiques locales. 2.7.1 Impact de la suppression des points clés en fonction de leur saillance Dans cette étude, nous avons supprimé les points clés en fonction de leur saillance. Nous avons étudié deux configurations après avoir rangé les points clés en fonction de leur saillance visuelle : – Suppression des points les moins saillants et des points les plus saillants ; – Remplacement des points les moins saillants par le même nombre de points les plus saillants issus de la quantification dense. Sur la Figure 2.16, on remarque que la suppression des points les moins saillants 3 n’affecte pas énormément le score moyen. Par exemple, si on considère la configuration "Sans normalisation", lorsqu’on supprime 20% des points les plus saillants, on obtient un score moyen de 2.92 alors qu’il faut supprimer 64% des points les moins saillants pour descendre à ce score. Cette différence de pourcentage rejoint les conclusions de l’étude des points clés saillants détectés. En effet, comme il y a très peu de points ayant une saillance élevés, si on considère les courbes "Saillants" et 3. Ici les points sont supprimés en fonction de leurs valeurs de saillance triées. La notion de saillance ici n’a rien à voir avec celle définie lors de l’étude de la saillance des détecteurs : le seuil 0.4. 62Chapitre 2. Notre approche pour l’indexation Figure 2.16: Impact de la suppression des points clés en fonction de leur saillance. Sailants et Saillants_Norma correspondent aux résultats de la suppression des points en triant la saillance par ordre décroissant (les points les plus saillants sont supprimés en premier) alors que NonSaillants et NonSaillants_Norma correspondent aux résultats de l’inverse (les points les moins saillants sont supprimés en premier). Norma indique que nous avons normalisé nos histogrammes de mots visuels avec p=0.5. "Saillants_Norma", dès les premières suppressions, on les élimine. Cela montre que les points les plus saillants détectés par Harris-Laplace sont importants sur UKB. Le comportement est le même avec la normalisation. Mais celle-ci permet cependant de gagner en précision : 3.21 à 20% ce qui correspond à peu près au score obtenu quand on n’applique aucune normalisation et qu’on conserve tous les points (3.22). Nous avons effectué les mêmes études en partant d’un ensemble de caractéristiques locales obtenues à partir d’une quantification dense. Cette nouvelle configuration dont les résultats sont présentés sur la Figure 2.17, nous permet d’étudier la dépendance des résultats précédents de la méthode de détection des caractéristiques locales. En se mettant dans une configuration d’échantillonnage dense, lorsqu’on ne supprime aucun point, le score moyen est de 3.27 avec le même dictionnaire visuel. Si on le compare au score moyen de 3.35 obtenu en appliquant une normalisation avec p=0.5 et un détecteur de Harris-Laplace en ne supprimant également aucun point, on se rend compte qu’on perd 2.39%. Sur UKB, l’échantillonnage dense que nous avons utilisé n’améliore pas les résultats et n’a donc aucun intérêt a priori puisqu’il est plus long. Ceci peut être dû au fait que plusieurs informations "parasites" (qui sont identiques dans plusieurs images) ont dues être décrites. En effet, étant potentiellement communes à plusieurs images, ces caractéristiques locales introduisent potentiellement des biais dans les "Sacs de mots visuels". D’ailleurs, la présence de ces informations "parasites" s’illustre par l’amélioration du taux de reconnaissance dans les premiers pourcentages supprimés : ∼ +2.75% à 65% de points non saillants 63Chapitre 2. Notre approche pour l’indexation Figure 2.17: Étude de la dépendance des résultats de l’importance des caractéristiques locales saillantes de la méthode de détection des caractéristiques : détection dense. supprimés 4 . Les résultats de la suppression des points les moins saillants dans une configuration dense reposent la question de l’utilité d’un nombre important de points. Même si le score moyen obtenu avec une détection dense est plus bas que notre score de référence, les résultats obtenus en étudiant l’impact de la suppression des points clés saillants sont identiques à ceux présentés sur la Figure 2.16. Les caractéristiques locales les plus saillantes sont plus importantes si on veut effectuer un filtrage sans affecter considérablement le score moyen. Elles sont d’autant plus importantes quand on fait une sélection dense puisqu’on peut facilement éliminer les motifs sporadiques. On peut conclure de cette première étude que les points clés les plus saillants sont très importants. En effet, ils permettent comme l’illustrent les courbes de la Figure 2.16 de garder une très bonne précision. Cette étude est d’autant plus intéressante qu’elle montre que les caractéristiques locales les moins saillantes, notamment sur UKB, peuvent être filtrées en définissant un certain pourcentage sans affecter énormément les résultats. Ces résultats rejoignent ceux obtenus par Zdziarski et al. [Zdziarski 12] en filtrant les descripteurs SURF par leur saillance. 2.7.2 Ajouts de points saillants Les signatures visuelles considérées pour cette étude n’ont pas été normalisées. Nous avons conclu des études précédentes que les points détectés les moins saillants n’étaient pas indispensables pour avoir un score de classification intéressant (supé- rieur ou égal à 3 par exemple). Quand on utilise le détecteur Harris-Laplace, sur 4. On a désormais 2867 caractéristiques par images. 64Chapitre 2. Notre approche pour l’indexation UKB, sans normalisation des signatures visuelles, il faut avoir supprimé 58% des points les moins saillants pour descendre en dessous de 3. Nous avons alors décidé de remplacer ces points par les points les plus saillants de la détection dense. Pour illustrer notre propos, supposons que nous désirons supprimer 4% des points les moins saillants détectés, nous remplaçons ces points par le même nombre de points les plus saillants issus de la détection dense. Les résultats de cette étude sont illustrés sur la Figure 2.18. Figure 2.18: Remplacement des points détectés les moins saillants par les points les plus saillants issus de la détection dense. Nous avons arrêté l’étude à la suppression de 90% des points les moins saillants parce qu’au delà, cela reviendrait tout simplement à ne considérer que les points détectés en dense. D’ailleurs, la première conclusion concerne la précision gardée après le remplacement de 90% des points. Ceci illustre d’autant plus l’importance des points saillants pour la reconnaissance des images de UKB. Si on ne remplaçait pas ces points, le taux de reconnaissance descendrait à 1.94. Le même constat est fait en supprimant 60% des points les moins saillants détectés avec Harris-Laplace. On note une amélioration de la reconnaissance de +3.75%. Le résultat le plus important se situe à 20%. La reconnaissance est meilleure que si on considérait simplement tous les points détectés avec Harris-Laplace, 3.27 au lieu de 3.22 soit une amélioration de +1%. Certes, cette amélioration est peu importante mais elle démontre que remplacer des points de saillance visuelle faible par d’autres de saillance visuelle forte ne dégrade pas du tout les résultats et a plutôt tendance à les améliorer. Ceci confirme alors que, sur cette base d’images, la saillance visuelle est très importante. Elle permet de garder une très bonne précision. 2.7.3 Discussions autour des travaux sur la saillance Nous avons proposé une étude de la saillance des points clés ainsi que leur importance. Dans un premier temps, nous avons analysé la saillance des caractéristiques 65Chapitre 2. Notre approche pour l’indexation locales détectées. Nous en avons conclu que, globalement, les bases d’images considé- rées ne contiennent pas énormément d’informations saillantes. Bien évidemment, ces résultats ne sont valables que dans le cas du modèle que nous avons utilisé. Même si ce modèle de saillance visuelle n’est pas celui qui donne les meilleurs résultats [Borji 13b], il nous a permis de faire un travail préliminaire. Pour toutes les bases que nous avons étudiées, la majorité des pixels a une valeur de saillance visuelle comprise entre 0 et 0.3. Nous avons aussi conclu de l’étude de la corrélation entre le pourcentage de pixels saillants dans une image et celui des caractéristiques locales saillantes détectées qu’il n’y avait aucun lien entre les deux. Il s’agit là d’un résultat prévisible puisque les deux informations sont liées au contenu de la scène mais sont issues de deux processus différents. Les résultats obtenus dans cette première partie confirment une fois encore qu’on peut avoir des informations importantes pour un système de recherche d’images par le contenu sans qu’elles soient les plus saillantes du point de vue de notre système de vision. Ceci se justifie par le taux de pourcentage de caractéristiques locales saillantes détectées. Même si le détecteur de Harris apparaît comme celui détectant le plus de points saillants, ceci ne le classerait en rien comme étant le plus efficace. Dans une seconde partie de ce chapitre, nous nous sommes focalisés sur l’importance des caractéristiques locales saillantes dans la tâche d’indexation de notre système. Nous avons remarqué que les points clés saillants étant très importants pour avoir des résultats intéressants : au moins un score de 3 sur 4. Il suffit de supprimer 20% des descripteurs des points clés les plus saillants pour que le score moyen descende à 2.92. Ces premiers résultats ont été confirmés lorsque nous avons remplacés les points clés les moins saillants par les points les plus saillants (dans la même proportion issus de la détection dense). D’ailleurs à 20%, on note une amélioration de +1% du taux de reconnaissance. Ces résultats permettent de conclure que sur la base UKB les points clés saillants sont importants d’autant plus que les résultats dans le cas d’une configuration dense sont identiques. Ces résultats ne dépendent alors aucunement de la méthodologie de détection des caractéristiques locales. Conclusion Dans ce chapitre consacré à nos premières contributions, nous avons travaillé avec deux bases : – la base UKB composée de 10 200 images, identiques 4 par 4 qui a constitué notre base de tests ; – la base Pascal VOC2012 composée de 17 125 images que nous avons utilisée essentiellement pour la construction du dictionnaire visuel. Nous avons proposé, dans un premier temps, une nouvelle façon de construire un dictionnaire visuel. Cette technique se base sur les précédents résultats liés à l’utilisation de l’algorithme K-Means sur des vecteurs de grande dimension. En effet, les clusters obtenus tendent vers une distribution aléatoire pour de grandes dimensions. Les descripteurs de caractéristiques locales traditionnellement utilisés en reconnaissance d’images tels que SIFT et leurs dérivés sont souvent de dimension 128. Notre algorithme se base sur une étape préliminaire de sélection aléatoire d’un en- 66Chapitre 2. Notre approche pour l’indexation semble de descripteurs de caractéristiques locales. Ensuite nous appliquons une suppression récursive en prenant en compte un gain d’information que nous avons défini. Les signatures visuelles ont ensuite été construites en utilisant la technique "Sac de mots visuels". Les résultats obtenus sont très satisfaisants sur la base UKB comparés à ceux de la littérature. En moyenne, notre algorithme permet un gain de 5% par rapport à l’algorithme BoVW [Sivic 03] avec un dictionnaire de taille 294. La taille du dictionnaire influence énormément les résultats des signatures de type "Sac de mots visuels". Traditionnellement les meilleurs résultats sont obtenus avec des vocabulaires visuels de tailles supérieures ou égales à 10 000. Le descripteur SIFT est très plébiscité alors que nous obtenons des très bons scores moyens avec le descripteur CMI sur UKB en comparaison aux signatures visuelles habituellement plus performantes telles que VLAD [Jégou 10b] et FV [Perronnin 07]. Ce sont là des résultats intéressants puisque ce descripteur est de taille 5 fois plus petite que SIFT. Ceci peut évidemment être dû à la nature des images de UKB et reste à vérifier sur d’autres bases. La seconde partie de nos travaux a été consacrée à l’utilisation de la saillance visuelle pour la reconnaissance d’images par le contenu. Nous avons d’abord testé la pondération par la saillance visuelle des caractéristiques visuelles. Ces premières expérimentations n’ont pas été concluantes en termes de score moyen sur UKB. Le seul impact que nous avons noté concerne le rang des 4 images les plus ressemblantes. Parmi les 10 200 images de la base, la pondération par la saillance améliore globalement leur rang. Ces résultats nous ont amené à étudier la saillance visuelle des détecteurs de caractéristiques locales. Pour ce faire, nous avons rajouté deux bases d’images conçues pour l’étude de la saillance visuelle : LeMeur et Kootstra. Des quatre détecteurs choisis (DoG, FAST, Harris et Harris-Laplace), celui de Harris est celui qui produit le plus de caractéristiques locales dans les régions saillantes. Le dé- tecteur Harris-Laplace qui est l’un des meilleurs de la littérature est celui qui détecte le moins de caractéristiques locales saillantes. Nous avons néanmoins étudié l’impact du filtrage de points clés par la saillance visuelle à partir de ce dernier puisqu’il est le plus utilisé. Les premiers résultats montrent que les points clés saillants sont très importants. Les mêmes résultats ont été obtenus dans une quantification dense des pixels des images montrant qu’ils ne sont pas dépendants de la nature de la sélection des caractéristiques locales mais probablement de la base. 67Chapitre 2. Notre approche pour l’indexation 68Conclusion Partie 1 Dans cette première partie dédiée à la reconnaissance d’images par le contenu, nous avons, dans un premier chapitre, fait une revue de la littérature axée sur les différentes techniques que nous avons ensuite utilisées dans nos contributions dé- taillées dans le second chapitre. Le Chapitre 1 nous a permis de rappeler et d’expliquer quelques notions fondamentales en indexation depuis la description des images jusqu’à la création de la signature visuelle. Deux solutions existent pour la description : une approche globale sur laquelle nous n’avons pas insisté et une approche locale. C’est cette dernière que nous avons choisie dans nos travaux présentés dans le Chapitre 2. Nous avons fait le choix de ne pas nous intéresser aux tâches de catégorisation et de classification dans cette première partie. Ce qui nous importe dans ces premières contributions c’est la précision des descripteurs et la robustesse de la méthode. Il est évident que nos résultats sont perfectibles, nous l’avons prouvé en montrant que la normalisation pouvait améliorer le score moyen sur UKB. La distance entre les signatures visuelles peut aussi également changer les résultats. Nous avons opté pour la distance χ 2 , en partie parce que la distance L2 impactait négativement nos résultats. Il s’agit là de différents leviers sur lesquels on peut pousser la réflexion. Celle-ci pourrait être menée depuis la création du dictionnaire jusqu’à la comparaison des signatures visuelles. Malgré la simplicité de l’algorithme de construction de dictionnaire visuel que nous avons proposé, les résultats obtenus sont très encourageants. Cet algorithme permet non seulement de gagner du temps lors de la création du dictionnaire, mais également de travailler avec un dictionnaire de petite taille sur UKB, rivalisant ainsi avec des méthodes telles que VLAD ou FV. Après ces premiers travaux, nous avons évalué la saillance des détecteurs de caractéristiques locales. Nous en avons conclu qu’aucune corrélation n’existait entre le nombre de pixels saillants et celui de points clés saillants détectés sur les quatre bases que nous avons testées. Le détecteur de Harris qui n’est pas forcément le plus performant de la littérature est celui qui détecte le plus de points dans les régions saillantes. Celui de Harris-Laplace détecte certes moins de points mais tous les points détectés dans les régions saillantes sont très importants pour la précision de l’indexation. Ces premiers résultats, très encourageants, nous ont permis d’apporter une seconde contribution pour la reconnaissance des émotions que nous exposerons dans la partie suivante. En effet, nous avons émis l’hypothèse que la précision des différents descripteurs de caractéristiques locales en reconnaissance d’images pourrait être utile pour cette tâche de haut niveau. Si dans 69Conclusion Partie 1 la première partie de nos travaux, nous n’avons pas utilisé de système d’apprentissage, pour la reconnaissance des émotions nous avons intégré un classifieur à notre approche. Dans la seconde partie de ce manuscrit, nous présenterons d’abord quelques solutions pour la reconnaissance des émotions. Ensuite nous exposerons notre approche basée sur les méthodes traditionnelles de reconnaissance d’images par le contenu. Pour constituer une vérité-terrain, nous avons construit une base qui a été évaluée en intégrant la saillance visuelle. Nous avons d’ailleurs défini un ensemble de critères pour décrire et comparer les différentes bases d’images pour la reconnaissance des émotions que nous présenterons dans le Chapitre 4. 70Deuxième partie Reconnaissance de l’impact émotionnel des imagesIntroduction Partie 2 Les outils actuels de reconnaissance d’images par le contenu sont de plus en plus performants. Néanmoins il y a encore une branche qui résiste aux progrès : celle de la reconnaissance des émotions induites par la visualisation d’une image. Si la reconnaissance des émotions à partir des visages commence à être bien maîtrisée, à travers les différents modèles de mouvements faciaux existants, l’impact émotionnel global d’une image quelconque est encore à l’état de test. Et pourtant c’est un domaine qui pourrait offrir de belles perspectives vu le développement des outils numériques et du tout connecté/intelligent. Les travaux sur les émotions et les images peuvent être classés en deux grands groupes. Le premier qui s’intéresse aux phénomènes biologiques régissant les émotions et le second qui essaie de proposer des solutions tentant d’approcher les vérités terrain. Nous ne nous intéresserons pas aux travaux focalisés sur la compréhension du phénomène émotionnel mais sur les solutions. Ainsi nous présenterons dans le premier chapitre quelques solutions de la littérature sur les émotions et les images ; des travaux sur les émotions et les couleurs aux solutions utilisant des descripteurs sémantiques et/ou bas niveaux. Nous évoquerons également quelques bases de la littérature dont nous discuterons dans le second chapitre. Ce dernier sera entièrement consacré à notre approche pour la reconnaissance des émotions. Nous avons choisi d’évaluer une architecture de recherche d’images par le contenu. Les descripteurs que nous avons retenus offrent de bons résultats pour cette tâche. Les contraintes des bases de la littérature nous ont obligés à construire une base d’images que nous avons évaluée au cours d’expérimentations subjectives. Nous avons choisi de segmenter les images par la saillance visuelle et d’étudier l’impact de cette segmentation aussi bien lors des évaluations que de la classification par notre approche computationnelle. 73Introduction Partie 2 74Chapitre 3 Reconnaissance des émotions dans la littérature Sommaire 3.1 Définition et théories de l’émotion . . . . . . . . . . . . . 76 3.2 Modélisations des émotions . . . . . . . . . . . . . . . . . 77 3.3 Émotions et couleurs . . . . . . . . . . . . . . . . . . . . . 79 3.4 Reconnaissance de l’impact émotionnel traitée comme une tâche de reconnaissance d’image dans la littérature 83 3.4.1 Bases d’images de la littérature . . . . . . . . . . . . . . . 83 3.4.2 Systèmes de reconnaissance d’images basée émotion . . . 86 Introduction Dans ce chapitre, nous reviendrons sur quelques travaux de la littérature sur la reconnaissance de l’impact émotionnel des images. Dans un premier temps, nous aborderons la question de la définition de l’émotion qui n’a trouvé un consensus que très récemment. Les théories contemporaines des émotions telles que proposent Coppin et Sander [Coppin 10] seront également abordées permettant ainsi de comprendre les deux modélisations des émotions retrouvées le plus souvent dans la littérature. Même si l’étude de l’impact émotionnel des images n’a pas encore un formalisme aussi bien défini que la reconnaissance d’images par le contenu, il existe un certain nombre de travaux dont une grande partie a été consacrée aux émotions et aux couleurs, aux harmonies couleur et aux préférences couleur. Les solutions de reconnaissance d’images par l’émotion utilisent le plus souvent les caractéristiques de l’image, bas-niveau ou haut-niveau extraites des couleurs. Dans le dernier cas de figure, une sémantique est extraite des différentes couleurs et ensuite affectée à l’image. Nous présenterons quelques solutions de la littérature avant de finir sur les propositions qui considèrent la reconnaissance des émotions comme une tâche d’indexation. Pour ce faire, certaines bases de la littérature seront présentées : les deux bases d’images proposées par Machajdik et Hanbury [Machajdik 10] et la base IAPS 75Chapitre 3. Reconnaissance des émotions dans la littérature (International Affective Picture System) [Lang 08]. Cette dernière est l’une des premières bases dédiée à l’étude des émotions largement évaluée et souvent utilisée dans la littérature pour tester et comparer les différents travaux. 3.1 Définition et théories de l’émotion Le concept d’émotion est utilisé de différentes manières selon qu’il est envisagé en référence à l’aspect stimulus, à l’expérience subjective, à une phase d’un processus, à une variable intermédiaire ou à une réponse. Après des années de débat, selon David Sander [Sander 13], les scientifiques sont arrivés à un consensus pour définir l’émotion. Il s’agirait d’un processus rapide, focalisé sur un événement et constitué de deux étapes : – Un mécanisme de déclenchement fondé sur la pertinence de l’événement (par exemple, l’événement est-il pertinent pour mes buts ?) ; – Une réponse émotionnelle à plusieurs composantes (les tendances à l’action, les réactions du système nerveux autonome contrôlant par exemple le rythme cardiaque, les expressions et les sentiments). Une émotion est brève et toujours déclenchée par un événement spécifique. Mais, d’après cette définition "consensuelle", c’est aussi un phénomène dynamique qui pré- sente de multiples composantes. C’est une réaction à un stimulus affectif, environnemental ou psychologique. L’émotion ressentie par rapport à une situation est propre à chaque individu, à son passé et son histoire de vie, ses capacités intellectuelles, son état psychologique. Les émotions fortes impliquent des répercussions physiques du ressentiment psychologique initial : la tristesse peut provoquer les larmes, la peur peut déclencher un cri, une perte urinaire parfois ou la joie peut générer un grand sourire, voire même des larmes. Une même situation implique des émotions diffé- rentes suivant l’individu concerné, le contexte et l’implication. On retrouve beaucoup d’autres définitions de l’émotion induisant alors un nombre élevé de théories de l’émotion. Coppin et Sander [Coppin 10] proposent un récapitulatif des théories et concepts contemporains des émotions. Ils en distinguent quatre : – l’approche scientifique des émotions : deux théories contradictoires se sont longtemps opposées à savoir les conceptions phériphéraliste et centraliste. D’une part James [James 90] et Lange [Lange 22], soutiennent que ce qui était considéré auparavant comme la conséquence de l’émotion en est en fait la cause. Le déclenchement d’une émotion spécifique serait déterminé par la perception d’un motif d’activation périphérique spécifique. Plus concrètement, nous aurions peur parce que nous constaterions que nous tremblons. D’un autre côté, selon Cannon [Cannon 27] et Bard [Bard 28], le déclenchement d’une émotion spécifique est déterminé par le traitement d’un stimulus au niveau du système nerveux central, le motif d’activation périphérique n’étant ni spécifique ni causal. Cette théorie met donc en avant l’importance du système nerveux central. Ainsi, les changements physiologiques ne sont pas conçus comme cause mais comme conséquence de l’émotion. Ces deux théories, certes opposées, sont fondées sur une approche physiolo- 76Chapitre 3. Reconnaissance des émotions dans la littérature gique des émotions. Toujours selon Coppin et Sander [Coppin 10], le débat James-Lange/Cannon-Bard a été important pour la prise de conscience du rôle de la cognition dans l’émotion. Ceci est très bien illustré par les travaux menés par Schachter [Schachter 62], qui figurent parmi l’une des contributions pionnières les plus influentes dans le champ des sciences affectives. En effet, Schachter considère qu’une émotion est déterminée par une interaction entre deux composantes : une activation physiologique (arousal) et une cognition concernant la situation déclenchante de cette activation physiologique. – les théories de l’évaluation cognitive de l’émotion : l’émotion est le fruit des évaluations cognitives que l’individu fait au sujet de l’événement, qu’il soit externe ou interne, ou de la situation, qui initie l’émotion. Ces théories sont également appelées "théories de l’appraisal". Selon Coppin et Sander, ces modèles postulent que les organismes explorent constamment leur environnement, réagissant aux stimuli pertinents. Ils soulignent que la contribution majeure de ces théories est de spécifier un ensemble standard de critères qui sont supposés sous-tendre le processus d’évaluation cognitive de l’émotion. Lors du déroulement d’un événement, l’individu concerné évaluerait l’importance de cet événement sur un certain nombre de critères. – les théories des émotions de base : une perspective évolutionniste, faisant l’hypothèse que l’évolution a joué un rôle central dans le façonnement des caractéristiques. Les pères de cette approche sont sont entre autres Darwin, Ekman, Izard, Plutchik [Rigoulot 08, Tayari 09]. Certains chercheurs ont avancé l’existence d’un nombre limité d’émotions fondamentales universelles, qui auraient ainsi chacune une fonction évolutionnaire. Ces dernières sont dites "basiques" ou "primaires" ou encore "fondamentales". Il faut noter que seulement cinq émotions de base sont communes aux différentes propositions (la tristesse, la colère, la joie, le dégoût et la peur). Les émotions plus complexes proviendraient quant à elles d’un mélange de ces émotions de base. – les théories dimensionnelles : l’affect peut être décrit en recourant à des dimensions élémentaires indépendantes, qu’il est possible de combiner, qui seraient des propriétés phénoménologiques basiques de l’expérience affective. Les deux dernières théories induisent les deux principales catégorisations des émotions qu’on retrouve, le plus souvent, dans les systèmes informatiques de reconnaissance des émotions issues des images et des vidéos. 3.2 Modélisations des émotions Ici nous revenons plus en détail sur les deux classifications habituelles des émotions sont : – l’approche catégorielle ; – l’approche dimensionnelle. 77Chapitre 3. Reconnaissance des émotions dans la littérature Dans l’approche catégorielle (discrète), les processus émotionnels peuvent être expliqués par un ensemble d’émotions basiques ou fondamentales. Cette approche intègre le modèle de Ekman [Ekman 92] et aussi celui de Plutchik [Plutchik 97] qui sont les plus connus. Ekman définit six émotions primaires qui sont la colère, le dégoût, la peur, la joie, la tristesse et la surprise. Plutchik quant à lui compare les émotions à une palette de couleurs comme on peut le voir sur la Figure 3.1. Il propose un modèle de huit émotions qui correspondent à des couleurs dites "primaires" et peuvent s’opposer par deux. Figure 3.1: Circumplex de Plutchik. Dans la littérature, beaucoup de travaux se basent sur une modélisation discrète des émotions, par exemple, ceux de Wei et al. [Wei 08], Paleari et Huet [Paleari 08], Kaya et Epps [Kaya 04] ou encore Machajdik et Hanbury [Machajdik 10], même si le nombre d’émotions n’est pas toujours le même. Les modèles de l’approche dimensionnelle se différencient des modèles de l’approche catégorielle par le fait que les émotions résultent d’un nombre fixé de concepts représentés dans un espace multidimensionnel. Les dimensions peuvent être un axe de plaisir, d’éveil ou de puissance. Ces dimensions varient en fonction des besoins du modèle. Le modèle le plus utilisé est celui de Russell (Figure 3.2) avec les dimensions valence et activation (Valence-Arousal) dans lequel : – La valence représente la manière dont se sent une personne quand elle regarde par exemple une image. Cette dimension varie du positif au négatif et permet de distinguer les émotions négatives et agréables. – L’activation correspond au niveau d’excitation corporel. Ces modèles permettent de représenter un très grand nombre d’émotions dans un espace bidimensionnel dont les dimensions varient d’une information trop présente 78Chapitre 3. Reconnaissance des émotions dans la littérature à pas assez. Cependant certaines émotions peuvent être confondues (la peur et la colère par exemple) ou non représentées du tout (entre autre la surprise) dans un modèle bidimensionnel de type valence/éveil. Figure 3.2: Circumplex de Russell. L’axe Déplaisant-Plaisant correspond à la valence et l’autre à l’activation. Dans les travaux sur les émotions, une grande partie de la littérature a été longtemps consacrée aux liens entre les émotions et les couleurs. Les auteurs sont d’accord sur le fait que chaque couleur transmet des émotions particulières. Comme le disent Ou et al. [Ou 04a], les couleurs jouent un rôle important dans la prise de décisions, évoquant différents sentiments émotionnels. Par contre aucune conclusion n’est unanime. Ces sentiments évoqués par une couleur ou des combinaisons de couleurs sont appelés "émotions de couleur" (colour emotions). 3.3 Émotions et couleurs Plusieurs travaux ont été menés sur l’étude des émotions liées aux couleurs notamment à travers l’influence de la culture, de l’âge, du genre, du niveau social. Nous ne ferons pas une revue de littérature détaillée mais tenterons d’évoquer quelques travaux intéressants et pionniers. Les études que nous présenterons ici ont été menées sur des patchs d’une couleur ou des paires de couleurs. Les premières études sur les couleurs et les émotions portent le plus souvent sur le rouge, le vert, le bleu et le jaune. En 1990, Daniel Beresniak [Beresniak 90] publiait que le rouge est une couleur vivante et excitante. En revanche, la combinaison "rouge+gris" provoquerait un sentiment tragique. Le jaune serait la couleur la plus gaie, la plus claire, rayonnante et jeune. Ce serait également une couleur tonique et éclatante. La couleur la plus dynamique serait l’orange. Cette couleur combinerait la gaité du jaune et l’action du rouge. Pour finir le bleu serait une couleur profonde et mystique qui appellerait au calme. Plus récemment en 2004, Kaya et al. [Kaya 04] ont fait évaluer par 98 étudiants 79Chapitre 3. Reconnaissance des émotions dans la littérature volontaires (44 hommes et 54 femmes) 13 couleurs. Le détail des couleurs est donné dans l’Annexe B. Les participants avaient pour consigne d’indiquer leur réponse émotionnelle à la couleur observée ainsi que la raison de ce choix. Chaque patch de couleur, de taille 10cm*12cm était affiché au milieu de l’écran. L’ordre des couleurs était aléatoire et les étudiants ne pouvaient associer qu’une émotion à un patch. Le vert a atteint le nombre le plus élevé d’émotions positives (sensations de relaxation, joie, confort, paix et espoir) dans 95.9% des cas. Cette couleur est souvent associée à la nature produisant ainsi un sentiment d’apaisement et de confort d’après leurs évaluations. Le jaune est perçu comme énergétique avec des émotions positives (93.9%). Les émotions souvent associées à cette couleur sont la joie et l’excitation parce qu’elle est associée au soleil. La couleur bleu est la troisième couleur avec le plus grand nombre de réponses positives. Elle est associée à l’océan et au ciel induisant ainsi un effet de calme et de relaxation. La couleur rouge est associée à l’amour et à la romance mais également au sang et au diable. Le blanc est associé à l’innocence, à la paix et à l’espoir parce qu’il ferait penser à une mariée, à la neige, à une colombe et au coton. Le blanc est aussi associé à la solitude et l’ennui. Le noir est associé à la dépression, la peur, la colère parce qu’il est associé à des événements tragiques. Il est également associé à la force, la santé et la richesse. Le gris est associé à des émotions négatives. Il fait référence au mauvais temps, à des sentiments de dépression, de tristesse et à l’ennui. La recherche en émotions liées à une couleur ou une combinaison de deux couleurs est désormais un domaine de recherche bien établi. En effet, en plus des travaux décrits ci-dessus, dans une série de publications, Ou et al. [Ou 04a, Ou 04b, Ou 04c] ont étudié les relations entre les émotions, les préférences et les couleurs. Ils ont d’ailleurs établi un modèle des émotions liées aux couleurs à partir d’expériences psychophysiques. Dans un premier temps, les observateurs (des étudiants britanniques et chinois) ont évalué différents patchs d’une couleur selon dix échelles d’émotions liées aux couleurs à savoir : Chaud-Froid, Lourd-Léger, Moderne-Classique, PropreSale, Actif-Passif, Dur-Doux, Tendu-Détendu, Frais-Pas Frais, Masculin-Féminin et Plaisant-Déplaisant. Une onzième a été ajoutée dans le cadre de la combinaison de deux couleurs [Ou 04b] : l’échelle Harmonieux-Disharmonieux. Le détail des couleurs est donné dans l’Annexe B. Leurs travaux ont prouvé qu’on pouvait réduire le nombre d’échelles d’émotions liées aux couleurs à trois catégories ou à trois facteurs d’émotions liées aux couleurs : l’activité, le poids et la chaleur d’une couleur. Ces trois facteurs d’émotions sont définis dans l’espace CIELAB et donnés par les équations (3.1)-(3.3). colour activity = −2.1 + 0.6  (L ∗ − 50)2 + (a ∗ − 3)2 + b ∗ − 17 1.4 !2   1 2 , (3.1) colour weight = −1.8 + 0.04 (100 − L ∗ ) + 0.45 cos (H ∗ ab − 100˚), (3.2) colour heat = −0.5 + 0.02 (C ∗ ab) 1.07 cos (H ∗ ab − 50˚), (3.3) avec H ∗ ab = arctan b ∗ a ∗ ! et C∗ ab = q a ∗2 + b ∗2 . (3.4) 80Chapitre 3. Reconnaissance des émotions dans la littérature Dans ces équations L ∗ , a ∗ et b ∗ sont les coordonnées de la couleur testée dans l’espace CIELAB. Les auteurs ont conclu que ces trois facteurs étaient en accord avec les travaux précédents entre autres ceux de Kobayashi [Kobayashi 81]. Influence de la culture, du genre et de l’âge Les résultats obtenus dans les travaux sur les couleurs et les émotions peuvent changer énormément en fonction de la culture des observateurs. En 1996, par exemple Saito [Saito 96] a trouvé que pour les Japonais le noir pouvait être lié à des sensations positives. Ou et al. [Ou 04a] ont également noté des différences entre les observateurs britanniques et chinois au cours de leurs évaluations sur des échelles d’émotions particulières : Tendu-Détendu et Plaisant-Déplaisant. Le genre peut également influencer les émotions liées aux couleurs. En 1993, Boyatzis et Varghese [Boyatziz 93] ont montré dans l’une de leurs études, que les filles sont particulièrement plus positives à l’égard des couleurs plus vives et négatives à l’égard des couleurs sombres. Quant aux garçons, ils étaient beaucoup plus susceptibles d’avoir une réaction émotionnelle positive pour les couleurs foncées. Globalement, tous les groupes (les garçons et les filles) ont une plus forte réaction positive pour les couleurs vives et plus de sentiments négatifs pour des couleurs plus sombres. Ils notent également que des réactions physiologiques sont liées à la couleur (tension musculaire, tonus ou réflex en réponse à certaines couleurs). Le rouge augmente la tension musculaire de la normale 23 unités à 42, le jaune à 30, et le bleu à 24. D’une façon généralisée, les couleurs chaudes (rouge, orange) sont stimulantes tandis que les couleurs froides (bleu, vert) sont associées à la détente. Cela pourrait être lié à l’humeur associée à ces couleurs. Plus récemment en 2001, Bradley et al. [Bradley 01] concluent de leurs expérimentations que les femmes ont tendance à évaluer "Faiblement positives" des images que les hommes classent neutres. Elles réagiraient également plus fortement face aux images négatives. Beke et al. [Beke 08] quant à eux ont étudié les préférences en fonction de l’âge. Les résultats indiquent d’importantes différences dépendant des changements neurophysiologiques, de la culture. De leur côté, Suk and Irtel [Suk 10] ne notent aucune différence majeure entre les réponses émotionnelles des participants pour une couleur en fonction de l’écran d’affichage. Émotions liées à des patchs texturés Certains auteurs dans la littérature ont analysé l’émotion liée à la couleur en ajoutant d’autres informations au patch couleur analysé. Lucassen et al. [Lucassen 10] ont par exemple, étudié l’émotion liée à des patchs de textures colorées. Ils ont choisi quatre des échelles d’émotions précédemment utilisées par Ou et al. [Ou 04a] : Chaud-Froid, Masculin-Féminin, Dur-doux et Lourd-Léger. Ils ont adopté une stratégie particulière de test : celle de ne pas montrer les échantillons les uns après les autres mais de les montrer par bloc. Ceci permettrait de réduire les erreurs de classification par les observateurs. L’expérimentation se déroule en deux phases de tests à une semaine d’intervalle. D’une façon générale, les observateurs reproduisent mieux leurs réponses sur les échantillons non texturés que sur des échantillons texturés du premier au second test. Ces derniers sont également plutôt du même avis en ce qui concerne les échantillons de textures en niveaux de gris. Les couleurs sombres et saturées entraînent par contre un désaccord entre les 81Chapitre 3. Reconnaissance des émotions dans la littérature sujets. Ceci s’est surtout constaté au niveau des échelles Chaud-Froid et Dur-Doux. Les auteurs ont conclu de leurs travaux que lorsque des échantillons texturés étaient utilisés dans l’étude de l’émotion liée à une couleur, la texture joue un rôle très important. Ils ont par exemple montré que l’échelle Dur-Doux était complètement dominée par la composante texture. Les autres échelles seraient dominées par les paramètres de couleur, mais la texture diminue le poids de la balance, notamment sur les échelles Masculin-Féminin, Lourd-Léger et Chaud-Froid. Harmonie de couleurs Un autre concept lié au problème de l’émotion d’une couleur est celui de l’harmonie de couleurs. En effet, les combinaisons de couleurs harmonieuses sont celles qui génèrent un effet plaisant lorsqu’elles sont vues dans un voisinage donné. Ou et Luo [Ou 06] ont étudié l’harmonie dans les combinaisons de deux couleurs afin de développer un modèle quantitatif pour la prédiction. Durant des expérimentations psychophysiques, les observateurs ont annoté des paires de couleurs. À partir de ces résultats, les auteurs ont développé un modèle composé de trois facteurs indépendants d’harmonie : l’effet chromatique HC, l’effet de la clarté HL et l’effet de la teinte HH. Ces trois facteurs sont combinés pour former un modèle d’harmonie de deux couleurs noté CH définissant l’harmonie de l’ensemble. L’écriture de ce modèle est donnée par l’équation (3.5) : CH = HC + HL + HH. (3.5) Soient deux couleurs C1 et C2 représentées dans l’espace CIELAB par (L ∗ 1 , a∗ 1 , b∗ 1 ) et (L ∗ 2 , a∗ 2 , b∗ 2 ) ; HC, HL et HH sont définis par les équations(3.6)-(3.8). HC = 0.04 + 0.53 tanh (0.8 − 0.045∆C) (3.6) ∆C = " (∆H ∗ ab) 2 + (∆C ∗ ab) 1.46 2 # 1 2 ∆H ∗ ab = |H ∗ ab1 − H ∗ ab2 | ∆C ∗ ab = |C ∗ ab1 − C ∗ ab2 | HL = HLsum + H∆L (3.7) HLsum = 0.28 + 0.54 tanh (−3.88 + 0.029Lsum) Lsum = L ∗ 1 + L ∗ 2 H∆L = 0.14 + 0.15 tanh (−2 + 0.2∆L) ∆L = |L ∗ 1 − L ∗ 2 | HH = HSY 1 + HSY 2 (3.8) HSY = EC(HS + EY ) EC = 0.5 + 0.5 tanh (−2 + 0.5C ∗ ab) HS = −0.08 − 0.14 sin(hab + 50˚) − 0.07 sin(2hab + 90˚) EY = 0.22L ∗ − 12.8 10 exp ( 90˚− hab 10 − exp ( 90˚− hab 10 )) Selon les auteurs, le modèle proposé montre un rendement satisfaisant pour la pré- diction de l’harmonie des combinaisons de deux couleurs. 82Chapitre 3. Reconnaissance des émotions dans la littérature Dans une extension de ces travaux à la combinaison de trois couleurs, en 2011 Ou et al. [Ou 11] vérifient l’hypothèse selon laquelle chaque paire de couleurs contribuerait de façon additive dans l’harmonie totale d’un ensemble de trois couleurs. Les résultats obtenus confirment que l’approche de l’additivité peut être utilisée comme un outil simple mais robuste pour prédire le score de l’harmonie d’une combinaison de trois couleurs. Ils en ont conclu que la même approche pouvait être utilisée pour une combinaison de plus de trois couleurs. Solli et al. [Solli 09] arrivent aux mêmes conclusions dans leurs travaux sur l’harmonie d’une image multi-colorée. Selon les auteurs, l’harmonie d’une image couleur peut être estimée à partir de l’ensemble des harmonies de toutes les paires de couleurs possibles qui la composent. Les combinaisons de couleurs non harmonieuses prennent cependant le pas sur celles harmonieuses. Cela signifie alors que si une image contient à la fois des combinaisons de deux couleurs harmonieuses et non harmonieuses, le score de combinaisons non harmonieuses est très important dans l’harmonie globale perçue. Outre l’évaluation des émotions en fonction de la couleur ou de l’harmonie, dans la littérature, la reconnaissance des émotions est également traitée comme une tâche de reconnaissance d’images. L’idée sous-jacente est d’utiliser les techniques traditionnelles de reconnaissance d’image pour aborder la reconnaissance de l’émotion. On va alors extraire des caractéristiques de l’image et les utiliser pour trouver l’impact émotionnel. 3.4 Reconnaissance de l’impact émotionnel traitée comme une tâche de reconnaissance d’image dans la littérature Pour considérer la reconnaissance des émotions comme une tâche de reconnaissance d’image, il faut dans un premier disposer de bases annotées. Ces dernières permettent d’évaluer les différentes propositions de la littérature. Le taux de réussite du système est alors donné par rapport à la vérité terrain. 3.4.1 Bases d’images de la littérature Différentes bases d’images ont été utilisées dans la littérature pour l’étude des émotions [Yanulevskaya 08, Machajdik 10, Solli 10]. Ces dernières sont généralement différentes par leur contenu qui varie des images abstraites aux photographies voire à des montages de scènes particuliers. Nous ne nous focaliserons que sur trois bases qui sont disponibles en téléchargement : – Les deux bases proposées par Machajdik et Hanbury [Machajdik 10] ; – La base IAPS (International Affective Picture System) [Lang 08]. 83Chapitre 3. Reconnaissance des émotions dans la littérature Les deux bases proposées par Machajdik et Hanbury Machajdik et Hanbury [Machajdik 10] ont publié deux bases d’images 1 : une base d’images abstraites et une base de photographies. Ils ont choisi une modélisation discrète des émotions en optant pour la catégorisation proposée par Mikels et al. [Mikels 05]. Ce modèle comporte l’amusement, l’excitation, la satisfaction et l’émerveillement comme émotions positives et la colère, le dégoût, la peur et la tristesse pour représenter les émotions négatives. (a) (b) (c) (d) (e) (f) Figure 3.3: Illustration des bases d’images de Machajdik et Hanbury. Les images 3.3(a)- 3.3(c) sont issues de la base d’images abstraites et les autres de celles des photographies. La base d’images abstraites proposée par les auteurs contient 280 images issues de la combinaison de couleurs et de textures, sans aucun objet reconnaissable. Les images 3.3(a)-3.3(c) illustrent cette première base d’images. Pour obtenir une vérité terrain, les images ont été annotées dans un sondage en ligne où les participants pouvaient choisir la meilleure catégorie émotionnelle pour chacune des 20 images composant une session. 230 participants ont évalué cet ensemble d’images et chaque image a été annotée en moyenne 14 fois. Pour chaque image, l’émotion retenue est celle ayant obtenue un maximum de votes. Les images pour lesquelles les votes des participants sont peu concluants ont été supprimées induisant alors 228 images correctement annotées. L’ensemble des photos artistiques, illustré par les images 3.3(d)-3.3(f), provient d’un site de partage de photographies artistiques 2 . Ces images ont été prises par des personnes désireuses d’évoquer une certaine émotion par une manipulation consciente 1. Elles sont téléchargeables sur le site http://www.imageemotion.org. 2. www.deviantart.com 84Chapitre 3. Reconnaissance des émotions dans la littérature du contenu de l’image, de la luminosité, des couleurs, . . . Cette base de données leur permet de déterminer si l’utilisation consciente de couleurs et de textures par les artistes améliore la classification. Pour ces images, l’émotion est déterminée par l’artiste qui met sa photographie en ligne. IAPS (International Affective Picture System) C’est une base d’images composée de photographies pour la recherche sur les émotions. Elle a été conçue depuis la fin des années 1980 par le CSEA (Center for the Study of Emotion & Attention) de l’Université de Floride. Les images de cette base ont été évaluées selon des échelles affectives : le plaisir, l’excitation et la domination. Ceci correspond à une représentation tridimensionnelle des émotions. La base contient plus de 1000 images 3 et chacune d’elles a été évaluée par environ 100 personnes. Les valeurs affectives de ces images ont été obtenues suite à 18 études séparées d’environ 60 images chacune. Pendant les évaluations, l’image était affichée pendant 6 secondes. Les participants adultes disposaient ensuite de 15 secondes (20 secondes pour les enfants) pour donner des scores à chacune des trois dimensions émotionnelles. La notation s’est fait à l’aide d’un système graphique : SAM (Self Assessment Mannequin) illustré par la Figure 3.4. Ce dernier classe : – De "souriant/heureux" à "fronçant les sourcils/malheureux" pour la dimension de la valence ; – De "excité/les yeux grand ouverts" à "détendu/endormi" pour la dimension de l’éveil ; – D’une grande figurine (tout en contrôle) à une petite figurine (dominé) pour la dimension de la dominance. Figure 3.4: SAM utilisé durant les évaluations de IAPS. La première ligne de figurines correspond à la valence, la ligne du milieu à l’éveil et la dernière la dominance. Les participants avaient le choix d’utiliser les états des 5 figurines ou de sélectionner un état entre deux figurines. Chaque dimension est ainsi décrite par une échelle de 3. Celle que nous avons reçue comporte 1182 images exactement. 85Chapitre 3. Reconnaissance des émotions dans la littérature 9 valeurs. Outre les évaluations sur la base d’une modélisation dimensionnelle ; la base IAPS a été annotée selon un modèle discret dans la littérature [Davis 95, Mikels 05]. Nous n’aborderons que les évaluations de Mikels at al. [Mikels 05] puisque le nombre d’images annotées est le plus important ; 490 images dont 203 négatives et 187. Le caractère négatif ou positif d’une image a été déterminé en fonction des valeurs des dimensions de valence et d’éveil. Les dimensions ayant un score de 1 à 9, sur l’axe du plaisir par exemple, 1 correspond à une émotion négative et 9 positive. Le modèle discret utilisé est le même que celui repris par Machajdik et Hanbury [Machajdik 10] que nous avons évoqué précédemment. Deux études ont été conduites séparément ; une pour les images positives et une autre pour les images négatives. Durant chaque étude, 60 étudiants (30 hommes et 30 femmes) ont participé aux évaluations en échange de crédits de cours. Ils pouvaient indiquer plusieurs labels émotionnels pour une même image. Il faut noter que les participants à chacune des deux études sont différents 4 . Dans chacune des deux études, l’ensemble des images a été divisé en deux sous-groupes aléatoires. Les observateurs ont été répartis en groupe de 4 à 15 et l’ordre des sous-groupes d’images a été contrebalancé pour les différents groupes de participants. Les trois bases d’images que nous avons présentées ont été évaluées par des solutions de reconnaissance d’images par l’émotion. IAPS est beaucoup plus souvent utilisée puisqu’elle sert en quelque sorte de consensus d’évaluation des solutions computationnelles. Elle tire cet avantage de ses différentes évaluations (dimensionnelle, discrète). 3.4.2 Systèmes de reconnaissance d’images basée émotion Tous les systèmes que nous évoquerons dans cette partie ont en commun leur utilisation d’au moins une technique de reconnaissance d’images. La plupart d’entre eux utilisent les caractéristiques bas-niveau de l’image soit pour construire une information haut-niveau relative aux émotions soit pour les utiliser avec un système de classification. Reconnaissance d’émotions basée sur la détection de visages La première famille des solutions que nous aborderons est assez particulière et restrictive. Il s’agit des solutions utilisant la détection de visages. Une émotion est alors associée à des traits du visage (sourcils, lèvres entre autres). De nombreux travaux portent ainsi sur le décodage de l’expression faciale émotionnelle ; ceux de Tomkims [Tomkims 62] en 1962, Scherer et Ekman [Scherer 84] en 1984 ou encore plus récemment ceux de Ekman en 1992 [Ekman 92]. Ce dernier est d’ailleurs le "mentor" de la célèbre série américaine "Lie to me". Les solutions de la littérature basées sur la détection de visages utilisent, pour la plupart, une modélisation discrète [De Silva 97, Busso 04]. Un système apparaît comme étant le standard pour la description des expressions faciales : il s’agit de la méthode 4. Aucun participant à l’étude 2 n’avait participé à l’étude 1. 86Chapitre 3. Reconnaissance des émotions dans la littérature de description des mouvements du visage FACS (Facial Action Coding System), dé- veloppée par les psychologues Paul Ekman et Wallace Friesen en 1978 [Ekman 78]. Les mouvements du visage sont décomposés en unités d’action AU (Action Unit). FACS repose sur la description de 46 AUs identifiées par un numéro. Par exemple, l’AU1 correspond au mouvement de lever les sourcils au niveau du nez. À partir de combinaisons des différentes unités d’action, on définit les émotions. La joie, par exemple, correspond à la combinaison des AUs 6 et 12. Reconnaissance d’émotions basée sur les caractéristiques de l’image L’autre famille de solutions dans la littérature est celle qui se base sur des caractéristiques de l’image qu’elles soient bas-niveau ou haut-niveau construites à partir d’une information bas-niveau, le plus souvent la couleur. Le premier groupe de travaux que nous évoquerons ici est celui des systèmes de reconnaissance d’images basée sur les émotions à partir de la description sémantique des couleurs. À partir de cette information, ils associent à une image une sémantique émotionnelle. Wang et Yu [Wang 05], à partir d’un algorithme de clustering flou, transforment les régions couleurs en termes sémantiques. Pour ce faire, dans un premier temps, les images sont segmentées dans l’espace couleur CIELAB. Ensuite, les régions segmentées sont exprimées dans l’espace CIELCH (la version cylindrique de l’espace CIELUV) [Sève 09]. L’utilisateur peut donc interroger leur système en construisant une requête composée de différentes notions émotionnelles sémantiques ou à partir de phrases. Toujours sur le même principe, Hong et Choi [Hong 06] présentent un système appelé FMV (Fuzzy Membership Value) qui extrait automatiquement une sorte d’interprétation sémantique des images couleur. Il permet à l’utilisateur de retrouver les images à partir de concepts sémantiques hautniveau tels que "naturel", "actif", . . . Les "concepts émotion" sont déduits de l’espace couleur HSI. Wang et al. [Wang 06] ont, quant à eux, utilisé un espace émotionnel tridimensionnel pour annoter les images et créer des requêtes sémantiques. Cet espace est basé sur des expérimentations psychologiques conduites avec 12 paires de mots émotionnels. Les trois dimensions de cet espace sont similaires à celles proposées par Ou et al. [Ou 04a] dont les relations sont données par les équations (3.1)-(3.3). Les caractéristiques d’images utilisées sont des histogrammes qui, combinés à un SVM prédisent les facteurs émotionnels. D’un autre côté, se développent des systèmes se basant essentiellement sur les caractéristiques bas-niveau. Celles qu’on retrouve le plus souvent sont liées à la couleur, à la texture, aux formes. Solli et Lenz [Solli 10] ont utilisé deux vecteurs de caractéristiques psychophysiques basées sur l’impact émotionnel de combinaisons de couleurs (histogramme d’émotions et le sac d’émotion). Ces descripteurs sont construits à partir des facteurs d’émotions définis par Ou et al. [Ou 04a] dont les relations sont données par les équations (3.1)-(3.3). Les auteurs ont comparé leurs performances à un algorithme exploitant l’histogramme RGB et deux descripteurs de caractéristiques locales qui sont SIFT [Lowe 99] et une de ses extensions couleur proposée par van De Weijer et Schmid [Van De Weijer 06]. Ils ont utilisé un SVM pour la classification. Ils ont évalué les quatre descripteurs sur 2 bases d’images : 87Chapitre 3. Reconnaissance des émotions dans la littérature – une première base construite à partir de 1.2 million d’images (de dimension maximale 128) de Picsearch 5 qui est une société suédoise qui développe et propose des services de recherche d’images pour les sites web ; – une seconde base de 750 000 images commerciales gérée par la société suédoise Matton Images 6 . Les images de cette base ont été redimensionnées comme celle de la première base. Leurs résultats montrent que l’histogramme d’émotions et le sac d’émotions accomplissent mieux la tâche de classification que les caractéristiques locales. Yanulevskaya et al. [Yanulevskaya 08] ont utilisé les statistiques locales de l’image pour classer une partie des images de IAPS. Ils ont utilisé le sous-ensemble de IAPS annoté de façon discrète par Mikels [Mikels 05]. Ils ont choisi les descripteurs Wiccest [Geusebroek 06] et des filtres de Gabor [Bovik 90]. Les premiers utilisent les statistiques de l’image pour modéliser efficacement des informations de texture. La texture est décrite par la distribution des bords. Ainsi, un histogramme d’un filtre gaussien dérivé est utilisé pour représenter les statistiques de bord. Les filtres de Gabor répondent, en effet, aux motifs réguliers dans une orientation donnée et sur une échelle de fréquence donnée. À partir de ces caractéristiques, les auteurs ont utilisé un SVM pour la reconnaissance des émotions. Ils concluent de leurs travaux que les émotions sont liées à des catégories spécifiques de la scène, comme des paysages ou des insectes. L’émerveillement et le dégoût pourraient être identifiés par la distribution des couleurs de l’image. La tristesse et les émotions positives indifférenciées seraient liés à des textures de la scène. Machajdik et Hanbury [Machajdik 10] ont également testé leur système sur le sousensemble de IAPS évalué par Mikels [Mikels 05]. Ils ont utilisé des attributs de couleur, de textures, de composition et de contenu (dont les visages humains). Ils ont conclu, dans un premier temps, que l’occurrence et la taille des visages humains étaient les caractéristiques déterminantes de l’amusement sur la base IAPS. Les émotions des images de cette base seraient fortement liées à leur contenu alors que les couleurs apparaissent plus importantes pour les images de la base de photographies. Pour finir, nous citerons les travaux de Liu et al. [Liu 11a] dont le système combine des caractéristiques bas-niveau et sémantiques à l’aide de la Théorie de l’Évidence [Smets 90] sur IAPS. La classification a été faite avec un SVM. Les différentes émotions des images de la base ont été regroupées en 4 groupes comme l’illustre la Figure 3.5. Leurs tests montrent que les descripteurs de textures LBP (Local Binary Pattern) [Ojala 02] et Tamura [Wu 05] sont ceux qui obtiennent les meilleures classifications. Au moment de la combinaison des différents résultats de classification, la fusion avec la Théorie de l’évidence donne de meilleurs résultats comparée à une simple moyenne des classifications, la classification minimale/maximale ou encore la fusion avec un algorithme de vote majoritaire. 5. http://www.picsearch.com/ 6. http://www.matton.com 88Chapitre 3. Reconnaissance des émotions dans la littérature Figure 3.5: Différentes classes reconstituées par Liu et al. pour l’évaluation de leur approche sur IAPS. Conclusions : Synthèse et critiques de l’état de l’art La première conclusion qui peut être tirée des différentes évaluations des émotions concerne l’aspect personnel et subjectif des émotions. Il s’agit d’un ressenti très dépendant du vécu de l’observateur. Le challenge de mise en place d’un système de reconnaissance des émotions est d’autant plus important que l’émotion ne dépend pas d’une seule caractéristique de l’image. Une émotion peut être liée à la texture comme l’ont montré Lucassen et al. [Lucassen 10]. Dans les travaux de Machajdik et Hanbury [Machajdik 10], les couleurs sont très déterminantes pour la reconnaissance des émotions des images abstraites. Ce résultat est tout à fait logique puisque ce sont les informations prépondérantes de ces images. Un système de reconnaissance d’émotions ne peut pas être universel. Les émotions sont certes liées aux couleurs mais dépendent aussi des cultures, du genre. Ceci induit la nécessité d’une vérité terrain la plus hétérogène possible. Le plus gros problème rencontré dans l’extraction de l’impact émotionnel d’une image est celui du manque d’harmonisation du choix du modèle émotionnel. La question récurrente est celle de la définition du modèle idéal. La modélisation discrète est largement utilisée. Cette dernière a pour principal inconvénient d’être basée sur des expressions faciales rendant parfois l’évaluation des images fastidieuse. D’un autre côté, elle est plus accessible à un grand nombre de personnes. Chaque auteur travaille donc sur le modèle qui lui convient le mieux en fonction de ses aspirations. Outre la modélisation de l’émotion, il faut citer l’absence de base de tests universelle même si IAPS fait désormais figure de compromis. Face à cette littérature hétéroclite sur les bases d’images et leur évaluation, nous proposons dans la Section 4.1 du chapitre suivant, un ensemble de critères pour décrire les bases d’images. Cet ensemble de critères permet également de comparer les bases et d’en faciliter le choix. Nous avons comparé les trois bases présentées dans ce chapitre et, à partir de leurs insuffisances dans le cadre de nos travaux, nous avons construit une nouvelle base. IAPS aurait pu répondre à nos attentes en matière de qualité d’évaluation si elle n’était pas aussi restrictive. En effet, nous avons décidé dans nos travaux d’inclure la saillance visuelle dans les évaluations, afin d’en étudier 89Chapitre 3. Reconnaissance des émotions dans la littérature l’impact. Ceci n’aurait pas été possible avec les images de IAPS qui ne sont pas publiables à grande échelle. En effet, nous avons pris le pari d’évaluer nos images en ligne puisque Internet apparaît comme étant un média facile et gratuit pour toucher un grand nombre de personnes. Les différentes conditions d’affichage ne posent a priori pas de problèmes, puisque, d’après les études de Suk and Irtel [Suk 10], aucune différence majeure n’a été notée entre les réponses émotionnelles des participants pour une couleur en fonction de l’écran d’affichage. Nous donnerons ensuite dans les Section 4.2 et 4.3 les détails sur notre base d’images et ses différentes évaluations. Pour la reconnaissance de l’impact émotionnel des images, nous avons opté pour une solution de type reconnaissance d’images par le contenu. Nous avons, comme pour nos solutions en indexation, évalué d’abord certains descripteurs présentés dans le Chapitre 2 pour cette tâche et ensuite inclus la saillance dans notre système pour en étudier l’impact. 90Chapitre 4 Notre approche pour la reconnaissance des émotions Sommaire 4.1 Proposition d’une nouvelle taxonomie de description des bases d’images pour l’étude des émotions . . . . . . 93 4.1.1 Critères d’évaluation des informations intrinsèques à la base 93 4.1.2 Critères d’évaluation des informations extrinsèques à la base 93 4.1.3 Critères d’évaluation de disponibilité de tests physiologiques effectués sur la base . . . . . . . . . . . . . . . . . 94 4.1.4 Comparaison des bases de données évoquées dans le chapitre précédent avec nos critères . . . . . . . . . . . . . . 95 4.2 Nouvelle base pour l’étude de l’impact émotionnel : SENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.3 Évaluations subjectives de notre base d’images . . . . . 98 4.3.1 Évaluations SENSE1 . . . . . . . . . . . . . . . . . . . . . 100 4.3.2 Évaluations SENSE2 . . . . . . . . . . . . . . . . . . . . . 102 4.3.3 Récapitulatif de la base SENSE à partir des critères proposés105 4.4 Évaluation de descripteurs bas-niveau pour la reconnaissance de l’impact émotionnel d’une image . . . . . . 107 4.4.1 Descripteurs globaux . . . . . . . . . . . . . . . . . . . . . 107 4.4.2 Descripteurs locaux . . . . . . . . . . . . . . . . . . . . . 109 4.4.3 Protocole expérimental . . . . . . . . . . . . . . . . . . . 110 4.4.4 Étude de l’impact du dictionnaire visuel . . . . . . . . . . 111 4.4.5 Évaluation de l’impact de la signature visuelle . . . . . . 114 4.4.6 Récapitulatif des premiers résultats . . . . . . . . . . . . . 116 4.4.7 Présentation de nos résultats . . . . . . . . . . . . . . . . 117 4.4.8 Comparaison de nos résultats avec la littérature . . . . . 120 4.5 Prise en compte de la saillance visuelle . . . . . . . . . . 121 4.5.1 Sélection dense des caractéristiques locales . . . . . . . . . 122 4.5.2 Classification des images de SENSE2 . . . . . . . . . . . . 123 4.6 Récapitulatif des différents résultats de l’évaluation des descripteurs de recherche d’images par le contenu . . . . 125 91Chapitre 4. Notre approche pour la reconnaissance des émotions Introduction Dans ce chapitre, nous présenterons dans un premier temps une nouvelle taxonomie de description des bases d’images pour l’étude des émotions. Cette nouvelle taxonomie permet de résumer rapidement et efficacement une base. En effet, ces bases représentent l’axe principal des recherches actuelles. Les résultats obtenus dans l’analyse des émotions issues des images dépendent essentiellement de leur contenu et de la qualité de leur évaluation. La proposition de critères de description a été faite en fonction des différentes insuffisances dont souffre la littérature. Nous partageons les mêmes constats que Machajdik et Hanbury [Machajdik 10] à propos des bases de la littérature qui ont, entre autres, relevé les insuffisances suivantes : – La plupart des bases d’images utilisées est inconnue (non publiée). – Dans la majorité des cas, aucune information n’est donnée sur la manière dont les images ont été sélectionnées. Par exemple, existerait-il un filtrage manuel qui pourrait potentiellement entrainer un biais ? – La description des bases est parfois incomplète ([Cho 04]). – Les mesures d’évaluations sont souvent très peu décrites ([Yanulevskaya 08]). – Une catégorisation arbitraire des émotions qui rend les comparaisons entre les différents travaux laborieuses. Outre les bases de données, les papiers concernant la mise en place d’une solution "computationnelle" de reconnaissance des émotions souffrent aussi de plusieurs biais. Dans la plupart des cas, les différentes stratégies de travail des auteurs rendent la comparaison des résultats difficile voire impossible. Une solution semble émerger comme consensus : évaluer les résultats de son système sur IAPS. Malgré cela, on ne peut pas parler de comparaison efficace. En effet, les images utilisées pour les ensembles d’apprentissage et de te test ne sont pas connus car exprimés en termes de pourcentages. Certes, les résultats sont évalués sur une même base mais les différents taux de classification ne peuvent justement être utilisés pour comparer la performance des différentes approches. On ne pourra donc pas juger un système plus performant qu’un autre, même sur IAPS si les images utilisées ne sont pas les mêmes. Il n’existe pas une base d’apprentissage et une de test comme c’est le cas dans certains challenges en indexation, sur Pascal VOC par exemple. Si IAPS fait figure de référence dans la littérature, elle présente entre autres inconvé- nients des termes restreints de son utilisation. Ceci nous a, en partie, conduit à créer notre propre base d’images que nous présenterons dans une seconde partie de ce chapitre. Il ne s’agit pas seulement d’une base d’images supplémentaire car nous l’avons évaluée sous un angle innovant en considérant un modèle d’attention visuel. Pour finir, nous présenterons notre solution de reconnaissance des émotions. Nous avons considéré la tâche de reconnaissance de l’impact émotionnel des images comme une surcouche à un système d’indexation. Cette hypothèse nous a donc conduit à n’utiliser que des descripteurs bas-niveau robustes et efficaces en reconnaissance d’image par le contenu. La prise en compte de la complexité de l’information "émotionnelle" s’est faite en utilisant un classifieur. Notre objectif n’est pas de proposer le système le plus performant possible mais surtout d’évaluer des outils de reconnaissance d’images par le contenu pour la tâche "haut-niveau" que nous nous sommes fixée. 92Chapitre 4. Notre approche pour la reconnaissance des émotions 4.1 Proposition d’une nouvelle taxonomie de description des bases d’images pour l’étude des émotions Comme nous l’avons évoqué dans le chapitre précédent, il existe de nombreuses bases d’images pour l’étude des émotions. Ces différentes bases sont très différentes de par leur contenu et leurs évaluations. Face à cette diversité nous proposons dans un premier temps un ensemble de critères permettant de les décrire/comparer facilement et rapidement. Cette nouvelle taxonomie a deux objectifs : – Comparer efficacement les différentes bases de la littérature ; – Résumer les différentes bases, facilitant ainsi un choix. Les critères que nous proposons peuvent être regroupés en trois groupes informationnels : – Les informations intrinsèques ; – Les informations extrinsèques ; – Les évaluations physiologiques disponibles. La dernière famille de critères peut paraître surprenante, mais du fait de leur complexité, les émotions sont étudiées sous plusieurs angles dont l’axe physiologique. Dans ce cadre plusieurs mesures physiologiques (EEG, rythme cardiaque, . . . ) sont explorées afin d’essayer de comprendre au mieux l’impact émotionnel des images. 4.1.1 Critères d’évaluation des informations intrinsèques à la base Nous avons proposé trois critères intrinsèques qui nous paraissent très informatifs et déterminants dans le choix d’une base de travail. Il s’agit : – Du nombre d’images dans la base ; – De l’évaluation moyenne de chaque image de la base qui informe sur le nombre moyen d’observateurs ayant évalué une image ; – De l’aspect "libre de droits d’utilisation" des images de la base qui permet de savoir si la base peut être annotée à nouveau différemment et si oui quelles en sont les conditions 1 . Ce dernier aspect est très important puisque certaines bases d’images (IAPS par exemple) peuvent être sensibles. Les informations intrinsèques pourraient être suffisantes dans certains cas mais sont incomplètes pour une description détaillée. 4.1.2 Critères d’évaluation des informations extrinsèques à la base Les informations extrinsèques suivantes peuvent compléter la description et faciliter la comparaison : 1. Toutes les modifications potentielles devront être faites ou évaluées dans le cadre de l’utilisation des bases pour des travaux de recherche sans aucun but lucratif. 93Chapitre 4. Notre approche pour la reconnaissance des émotions – La disponibilité de la base qui indique la rapidité de disponibilité de la base d’images pour la communauté. Par exemple les deux bases de données proposées par Machajdik et Hanburry [Machajdik 10] peuvent être directement téléchargées alors que la mise à disponibilité de IAPS [Lang 08] nécessite une demande ; – La modélisation des émotions considérée lors des tests : ce critère est très important puisque le choix d’une modélisation discrète ou dimensionnelle est intimement lié aux objectifs des travaux ; – L’hétérogénéité des évaluations en fonction du genre, de l’âge des participants : ce critère est très important pour garantir une évaluation cohérente ; – La nature de l’impact émotionnel des images : ce critère permet de savoir si la base d’images concernée est une base suscitant de fortes émotions. C’est un critère très important dans le cas où l’on souhaiterait organiser des nouveaux tests sur la base d’images 2 . Si on est en présence d’une base dont les images sont à fort impact émotionnel, il faudra veiller, pendant l’organisation des tests, à ne pas introduire des biais d’évaluation entre les images successives 3 ; – La complexité de la tâche d’évaluation qui décrit une évaluation accessible ou non au grand public. Par exemple, la modélisation dimensionnelle utilisée pour IAPS par le biais du SAM semble moins facile qu’un modèle discret, la dominance et l’éveil pouvant être difficiles à appréhender. Les deux familles d’informations proposées ci-dessus suffiraient amplement à dé- crire et comparer des bases d’images pour l’étude des émotions. Mais avec l’engouement actuel pour la compréhension de nos réactions face à des contenus numériques, on note un intérêt dans la littérature pour les tests physiologiques. 4.1.3 Critères d’évaluation de disponibilité de tests physiologiques effectués sur la base Les évaluations physiologiques à la présentation d’un stimuli émotionnel permettent d’associer potentiellement une émotion (repérée par des variations physiologiques) à une image ou à une série d’images. Parmi les mesures physiologiques potentiellement exploitables (rythme cardiaque, EEG, . . . ), nous nous focaliserons sur la réponse SSVEP (Steady-State Visually Evoked Potential). Dans la littérature [Kemp 02, Keil 03], cette dernière a prouvé qu’elle n’était pas seulement une réaction mécanique du cerveau à un stimulus de clignotement. Selon les auteurs de ces travaux, elle serait modulée par l’attention de l’utilisateur et l’état affectif. SSVEP est en fait un cas particulier de VEP (Visually Evoked Potential) qui dans le contexte d’une EEG (Électro-encéphalographie) est un potentiel électrique provoqué par la présentation d’un stimulus visuel. Ce potentiel peut être enregistré par le cerveau et la réponse SSVEP permet de récupérer les différentes valeurs enregistrées. Quand on désire étudier la réponse SSVEP le stimulus doit être 2. Bien évidemment en disposant des droits. 3. Il faudra dans ce cas, veiller à ce que l’impact émotionnel d’une image n’influe sur celui d’une autre. 94Chapitre 4. Notre approche pour la reconnaissance des émotions présenté plusieurs fois à une fréquence au moins supérieure à 3.5Hz. Le plus souvent, on considère des valeurs supérieures à 6Hz [Kemp 02, Friman 07]. Une réponse périodique peut être alors observée dans le signal EEG enregistré via des électrodes placées sur le cuir chevelu, en particulier dans la région occipitale du cerveau, où ré- side le cortex visuel. Les hypothèses de captation d’état affectif grâce aux réponses SSVEP ont été étudiées dans la littérature [Kemp 02, Keil 03, Wang 13]. Durant leurs évaluations, quelques images de IAPS ont été montrées à des groupes d’observateurs pendant que leur signal EEG était enregistré. Leurs résultats montrent via l’amplitude, la latence et de la topographie de la réponse SSVEP que cette dernière pourrait être corrélée à l’excitation et à la valence des images montrées. Avec ces nouveaux critères, il est désormais très facile de comparer les bases d’images et d’avoir un aperçu intéressant à leur sujet. 4.1.4 Comparaison des bases de données évoquées dans le chapitre précédent avec nos critères Le Tableau 4.1 présente les résultats de comparaison des deux bases d’images de Machajdik et al. [Machajdik 10] et IAPS [Lang 08] selon nos différents critères. Les premières conclusions de ce tableau concernent la qualité d’évaluation des images des bases Machajdik1 et Machajdik2. En effet, comparées à IAPS, elles souffrent d’une évaluation insuffisante et aucune information n’est disponible sur l’hétérogé- néité des participants. Ces deux bases restent néanmoins très intéressantes puisqu’elles sont facilement accessibles. Elles sont téléchargeables et aucune autorisation n’est nécessaire tant que l’on reste dans un cadre de recherche académique. Ce qui n’est pas le cas pour IAPS qui requiert une autorisation préalable en précisant les contours des travaux de recherche 4 . Le principal inconvénient de cet ensemble d’images est son aspect fortement sémantique. En effet, certaines images de la base sont manipulées, changeant complètement la sémantique de la scène. Par exemple, si on remplace un sèche-cheveux par un pistolet dans une scène où quelqu’un se sèche les cheveux, l’image devient dramatique. Étant donné les images aux contenus très porteurs de sémantique et la forte puissance de l’impact émotionnel de certaines d’entre elles, on pourrait se poser la question de l’organisation des tests. Certaines images n’auraient-elles pas biaisées l’évaluation ? Un filtrage particulier a t-il été fait ? Comment a été défini l’ordre des images dans les différentes séries ? Toutes sortes d’images ont-elles été évaluées par les enfants ? Autant de questions sur les conditions d’évaluation même si le nombre de participants permet de considérer cette base comme étant fiable. Aucun détail n’est donné dans la description de la base pour répondre à ces questions. Les trois bases comparées dans le Tableau 4.1 ont un inconvénient majeur : tout projet de modification de l’une d’entre elles doit être adressé aux auteurs. Dans les clauses de IAPS par exemple, aucune diffusion sur Internet n’est autorisée pour que la base ne soit pas largement connue du grand public introduisant ainsi des biais dans les évaluations. Ce dernier point réduit énormément nos possibilités de travail 4. Dans notre cas, nous avons reçu la base environ 1 mois après notre demande. 95Chapitre 4. Notre approche pour la reconnaissance des émotions Tableau 4.1: Comparaison des bases d’images de Machajdik et al.[Machajdik 10] et IAPS [Lang 08]. Machajdik1 correspond à l’ensemble des images de peintures abstraites et Machajdik2 aux photographies. Base d’images Machajdik1 Machajdik2 IAPS Informations intrinsèques Nombre d’images 228 807 > 1000 Évaluations par image (Moyenne) 14 1 ∼ 100 60 ∗ Images libres de droits Oui∗∗ Oui∗∗ Oui∗∗ Informations extrinsèques Disponibilité de la base +++ +++ ++ Modélisation des émotions Discrète Discrète Discrète ∗ Dimensionnelle Hétérogénéité des évaluations Non renseignée Non Oui Nature de l’impact émotionnel + ++ +++ Complexité de l’évaluation ++ ++ +++ Évaluations physiologiques disponibles Aucune Aucune EEG (SSVEP) ∗ Si on considère l’évaluation faite par Mikels et al. [Mikels 05] seulement 490 images ont été évaluées (203 images négatives et 187 images positives). ∗∗ Uniquement dans le cadre de travaux de recherche académique. Il existe des clauses spécifiques à l’évaluation des images de IAPS. Par exemple, ne pas les diffuser sur Internet pour que leur évaluation ne soit pas biaisée par la suite. Les deux autres bases d’images sont uniquement disponibles d’après les auteurs pour un usage scientifique. 96Chapitre 4. Notre approche pour la reconnaissance des émotions et nous a contraint à créer notre propre base d’images. En effet, nous avons pour objectif de tester d’autres stratégies d’évaluations des images dans le cadre de l’étude de l’impact émotionnel. Nous souhaitons notamment introduire la saillance visuelle dans l’évaluation des images. 4.2 Nouvelle base pour l’étude de l’impact émotionnel : SENSE Nous avons choisi de travailler sur des images "faiblement sémantiques". Toutes les images ayant une sémantique, la terminologie "faiblement sémantique" semble excessive. Il s’agit ici d’images qui ne provoquent pas d’émotions très fortes 5 . Ce sont essentiellement des images d’environnements de la vie quotidienne qui nous permettent de limiter l’interaction entre les émotions de chaque image lors des évaluations subjectives. C’est un aspect très important dans la mesure où il minimise les biais d’évaluation. Nous voulions que l’évaluation d’une image soit liée à son contenu et non pas à celui de celle qui la précède. Nous avons alors créé la base SENSE (Studies of Emotions on Natural image DatabaSE) composée de 350 images libres de droit et gratuites dans sa grande majorité. Elle comprend des paysages, des animaux, des personnages, des aliments, des bâtiments, comme l’illustre la figure 4.1. (a) (b) (c) (d) (e) (f) Figure 4.1: Quelques images de SENSE. Aucune manipulation d’images de type remplacement d’une partie de la scène par une autre n’a été effectuée. Les seules transformations "non naturelles" qui ont été 5. En comparaison à certaines images de IAPS. 97Chapitre 4. Notre approche pour la reconnaissance des émotions effectuées sont des rotations et des modifications de la balance des couleurs sur quelques images (2,29%). D’ailleurs l’image 4.1(e) est un exemple de modification de la balance des couleurs de l’image 4.1(d). Par ailleurs, notre base de données contient également très peu d’images avec des visages humains (4,86%). Ce dernier point s’explique par notre volonté de limiter l’interprétation des expressions des différents visages donnant l’impact émotionnel des images 6 . La base SENSE a ensuite été évaluée au cours de différentes expérimentations subjectives. 4.3 Évaluations subjectives de notre base d’images Les informations que nous avons recueillies pour quantifier l’impact émotionnel des images étaient : – La nature de l’émotion ; – La puissance de l’émotion. Figure 4.2: Application de test. Comme on peut le voir sur la Figure 4.2 qui correspond à l’application des expérimentations subjectives, la puissance de l’émotion variait de "Faible" à "Fort". La nature de l’émotion quant à elle était renseignée grâce à un choix entre "Négative", "Neutre" et "Positive". Ce choix de modélisation émotionnelle s’apparente à un modèle dimensionnel. Il se justifie par notre souhait de décorréler l’évaluation de l’impact émotionnel des mots traduisant les émotions basées essentiellement sur l’expression du visage (par exemple la surprise, la joie, la colère, la tristesse). Aussi cette modélisation nous permet d’avoir un protocole de tests facile et accessible à 6. Un image qui contient un visage triste n’a pas forcément un impact émotionnel négatif. Le contexte pourrait être plus important que l’expression faciale. 98Chapitre 4. Notre approche pour la reconnaissance des émotions tous les observateurs au vu des images "faiblement sémantiques" de notre base. Nous avons organisé deux types d’évaluations de notre base d’images. Les premières évaluation sont appelées SENSE1 et les secondes SENSE2 pour faciliter la lecture. Ces deux évaluations ont été organisées à plusieurs mois d’intervalle. Durant les évaluations SENSE1 qui sont illustrées par la Figure 4.2, les participants ont jugé des images entières. Les évaluations SENSE2 justifient pleinement la création de notre base en plus des insuffisances des trois bases évoquées dans la Section 4.1. Nous avons intégré à nos expérimentations un modèle d’attention visuelle. Au lieu d’évaluer les images entières, les sujets devaient annoter des "imagettes" qui correspondaient aux parties les plus saillantes (visuellement attractives). Des exemples de ces dernières sont donnés sur la Figure 4.3. (a) 61% (b) 27% (c) 6% Figure 4.3: "Imagettes" correspondant aux images 4.1(a)-4.1(c) évaluées pendant SENSE2. La taille des images est exprimée en ratio par rapport à la taille de l’image originale. SENSE2 a pour objectif principal d’étudier l’impact de la réduction des régions observées par un modèle de saillance sur l’évaluation de l’impact émotionnel. Les deux évaluations étaient disponibles sur Internet, nous permettant ainsi, d’avoir une bonne hétérogénéité d’observateurs et surtout une évaluation moyenne par image intéressante dans un délai relativement court 7 . Notons quand même qu’avant de lancer les évaluations SENSE1 et SENSE2 nous avons fait des tests préalables au laboratoire dans une salle de tests normalisée dans les même conditions d’affichage et d’éclairage contrôlées. Vingt cinq observateurs (28% de femmes et 72% d’hommes ; la moitié âgée de 18 à 24 ans, les autres âgés de 25 ans à plus de 50 ans) ont participé volontairement à ces expérimentations. Seulement 48 images ont été évaluées et ceci au cours de deux sessions séparées d’une semaine. Durant chacune des sessions les participants ont jugé 24 images. Certaines images étaient identiques mais présentées avec un traitement différent (changement de la dynamique des couleurs ou rotation) d’une série à l’autre, voire au sein de la même série. Les volontaires disposaient de 8 secondes pour noter chacune d’elles. Si le temps paraît aussi court c’est tout simplement pour augmenter les chances de 7. Un taux de participation globalement satisfaisant (≥ 50 personnes par image) était atteint au bout d’un mois. 99Chapitre 4. Notre approche pour la reconnaissance des émotions recueillir des émotions primaires et non des émotions qui découlent d’une éventuelle interprétation trop poussée de la sémantique du contenu de ces images. Ce temps est également comparable à celui utilisé lors des évaluations de IAPS. L’image à évaluer était affichée pendant 6 secondes et les participants disposaient de 15 secondes pour les adultes, 20 pour les enfants, pour indiquer leurs émotions selon le système de notation SAM (Self Assessment Mannequin). Ces premiers tests nous ont permis de jauger la capacité des participants à évaluer nos images selon le protocole défini. Certes, les premières évaluations de vérification de notre protocole de test se sont déroulées dans des conditions d’affichage et d’éclairage contrôlées, mais ces conditions ne sont pas indispensables pour la tâche visée. En effet, l’idée de nos travaux est d’avoir l’impact émotionnel dans des conditions d’affichage de tous les jours 8 . Durant SENSE1 et SENSE2 les volontaires ont évalué 24 images 9 , choisies de fa- çon pseudo-aléatoire dans la base de 350 images/imagettes, sans temps imposé. La consigne d’effectuer la tâche le plus rapidement possible leur a été donnée dès le début du test ; dans le but de recueillir leurs premières émotions. Cette consigne a bien été respectée. Par exemple, le temps d’observation moyen durant SENSE1 est de 6.6 secondes. Tous les résultats des tests n’ont pas été gardés. Nous avons éliminé, dans un premier temps, les réponses que nous jugions trop rapides (<3 secondes) et trop lentes (>8 secondes). Ces réponses ont été éliminées pour respecter les objectifs de nos expérimentations. Nous avons ensuite fait un filtrage d’adresses IP pour éviter que certaines personnes, tentées de repasser le test plusieurs fois, n’introduisent des biais. Normalement la probabilité d’avoir deux séries identiques de suite est faible du fait de la sélection pseudo-aléatoire. Pour éviter de supprimer des résultats intéressants venant d’adresses IP identiques (cas de l’Université de Poitiers par exemple), nous avons vérifié entre temps les adresses qui étaient retrouvées plusieurs fois. 4.3.1 Évaluations SENSE1 1741 participants dont 893 femmes soit 51.29% des sujets, ont effectué cette expérimentation à travers le monde (28 pays différents) comme le montre la Figure 4.4(a). Notons quand même que malgré cette diversité la grande majorité habite en France. Les aspects les plus intéressants sont la répartition quasi-similaire des sujets en fonction de leur genre (51.29% de femmes et 48.71% d’hommes) et l’hétérogénéité en fonction de la tranche d’âge. Comme on peut le voir sur la Figure 4.4(b), la base a été évaluée par des personnes de tous les âges allant de moins de 15 ans à plus de 50 ans. Nous avons quand même constaté qu’une grande partie des participants était âgée de 15 à 30 ans (81.1%). Notons que dans un souci de cohérence des résultats nous avons comparé ces résultats à ceux obtenus au cours des tests dans les conditions d’affichage contrôlées. Les résultats sont très proches confirmant ainsi que notre procédure de tests sur Internet 8. On ne pourra pas obliger un utilisateur à regarder une image ou une vidéo dans un pièce avec un éclairage standardisé, sur un écran d’une taille définie, . . . Ce sont là des contraintes qui ne correspondent en rien aux conditions d’utilisation des applications proposées aujourd’hui. 9. S’ils ont fait le test complet ; le test peut être arrêté à tout moment pour que les expérimentations restent plaisantes. 100Chapitre 4. Notre approche pour la reconnaissance des émotions est valide pour notre tâche. Chaque image a été évaluée par 104.81 personnes en moyenne. Seulement 6% de toute la base a été annoté par moins de 100 participants. L’image la moins annotée a été évaluée par 86 personnes différentes. (a) Répartition par pays de résidence (b) Répartition par âge Figure 4.4: Illustration de l’hétérogénéité des expérimentations SENSE1. 0 10 20 30 40 50 60 70 80 90 Neg Neut Pos Taux de classification moyen dans chaque classe d’émotion Figure 4.5: Résultats des évaluations SENSE1 selon les 3 classes d’émotions. Les moyennes présentées sur ce graphiques sont accompagnées des écart-type pour chaque classe. Sur cette figure Neg désigne les images négatives, Neut les neutres et Pos les positives. En dépit du fait que nous avons pris le parti de travailler sur des images "faiblement sémantiques", les participants à nos tests sont assez cohérents dans leurs évaluations. Sur la Figure 4.5 nous avons représenté le pourcentage moyen d’observateurs qui contribue à l’attribution de la classe d’émotion. Nous considérons qu’une image est classée dans une des trois classes d’émotions (Négative, Neutre ou Positive) si la différence entre les deux classes majoritaires est d’au moins 10% 10. Les participants aux expérimentations SENSE1 sont plus unanimes à propos des images positives et négatives que celles classées "Neutre". Ceci peut s’expliquer par la relative ambigüité du terme neutre. On peut associer le neutre à une image parce qu’on ne ressent rien ou parce qu’on ne sait pas comment définir ce qu’on ressent. Nous n’avons pas tous la même définition pour ce type d’émotions, ni les mêmes ressentis d’ailleurs. Nous 10. Si une image a classé de la façon suivante : 49%, 40%, 11% respectivement Négative, Neutre, Positive, elle sera considérée comme "Non catégorisée" puisque ((49 − 40) < 10). Les différents pourcentages correspondent au pourcentage de personnes ayant voté pour la classe. 101Chapitre 4. Notre approche pour la reconnaissance des émotions avons également évalué les différences entre genres sur notre base et les résultats sont présentés dans l’Annexe C. Malgré le nombre de participants, 61 images (17.43%) sont "non catégorisées". Nous avons émis l’hypothèse que ceci est dû à l’interprétation sémantique de leur contenu. Même en réduisant le temps d’observation, l’humain a toujours tendance à aller vers une interprétation sémantique des images. Nous avons alors opté pour une autre façon de réduire la possibilité d’interprétation sémantique : réduire la taille de l’image observée. Nous avons mis en place cette technique en utilisant un modèle d’attention visuelle bottom-up afin de concentrer l’évaluation sur les informations saillantes. 4.3.2 Évaluations SENSE2 Modèle d’attention visuelle utilisé pour générer les "imagettes" Notre hypothèse lors de la mise en œuvre de ces évaluations est que d’une part la réduction de la taille des régions observées pourrait améliorer les évaluations. D’autre part les émotions sont basées sur les caractéristiques bas niveau (certes réinterprétées par un processus haut niveau) qui peuvent être extraites avec un modèle de saillance. Pour ce faire, nous avons utilisé le modèle hybride proposé par Perreira Da Silva et al. [Perreira Da Silva 10b]. Ce dernier permet de modéliser l’évolution temporelle du focus visuel de l’attention. C’est un modèle d’attention visuelle bottom-up qui se base sur le modèle de Itti et al. [Itti 98] comme on peut le voir sur la Figure 4.6. La différence entre ce modèle et celui de Itti et al. [Itti 98] se situe au niveau de la seconde partie de l’architecture. La combinaison des différentes cartes se fait avec une approche compétitive : le système proies/prédateurs. Les auteurs ont démontré que c’est une manière optimale d’extraire de l’information. Selon eux, les équations proies/prédateurs sont particulièrement adaptées à ce genre de tâche : – Les systèmes proies/prédateurs étant dynamiques, ils incluent intrinsèquement une évolution temporelle de leurs activités. Ainsi le focus de l’attention visuel vu comme un prédateur peut évoluer dynamiquement ; – Le choix d’une méthode de fusion des différentes cartes est assez difficile sans aucun objectif. Une solution consisterait à développer une compétition entre les différentes cartes et attendre que l’équilibre se fasse avec le système proies/prédateurs. Cela reflètera alors la compétition entre l’émergence et l’inhibition des éléments qui attirent ou non notre attention ; – Les systèmes discrets peuvent certes avoir des comportements chaotiques mais ceci peut être intéressant dans certains cas. Ils permettraient l’émergence de chemins d’exploration de la scène visuelle d’origine, même dans les zones non saillantes, reflétant peut être quelque chose de l’ordre de la curiosité. Les auteurs ont d’ailleurs montré que malgré le comportement non déterministe des équations proies/prédateurs, le système présente des propriétés intéressantes de stabilité, de reproductibilité et de réactivité tout en permettant une exploration rapide et efficace de la scène. Nous avons utilisé les paramètres optimaux proposés par les auteurs pour créer les "imagettes", obtenues à partir du rectangle englobant des régions saillantes. Leur taille varie de 3% à 100% de la taille de l’image originale. 102Chapitre 4. Notre approche pour la reconnaissance des émotions Figure 4.6: Architecture du modèle d’attention visuelle de Perreira Da Silva et al. [Perreira Da Silva 10b]. Résultats des expérimentations SENSE2 1166 participants dont 624 femmes (53.49%) ont évaluée les 350 "imagettes". Durant SENSE2 chaque "imagette" a été évaluée par 65.39 personnes en moyenne. Seulement deux "imagettes" ont été évaluées par moins de 50 personnes. L’image la moins évaluée était jugée par 47 personnes. Durant ces évaluations, nous avons une nouvelle fois atteint un nombre intéressant d’observations par image. Les proportions de participations suivant l’âge sont équivalentes à celles de SENSE1. La première conclusion à l’analyse des résultats de SENSE2 est qu’une image de taille trop petite n’a aucun intérêt. En effet, toutes les "imagettes" de taille infé- rieure ou égale à 7% 11 ont été annotées "Neutre" ou sont "non catégorisées". Si on s’intéresse dans un second temps à l’impact de la réduction de la taille des images sur l’évaluation de l’impact émotionnel, on remarque d’après la Figure 4.7 que, pour les trois classes d’émotions 77% des images sont bien catégorisées avec des imagettes de taille supérieure ou égale à 50%. Ce résultat implique que l’utilisation d’un modèle de saillance bottom-up ne détruit pas l’information intéressante pour l’évaluation sauf dans le cas d’"imagettes" trop petites. Il s’agit d’une conclusion exploitable aussi bien pour les évaluations qui se voient améliorées que pour les systèmes de reconnaissance des émotions à partir des caractéristiques de l’image. 11. Cette taille correspondant au ratio entre la taille de l’"imagette" et celle de l’image originale. 103Chapitre 4. Notre approche pour la reconnaissance des émotions Figure 4.7: Taux de bonne classification au cours de SENSE2 en fonction de la taille des régions. Les taux de bonne classification sont donnés ici en référence aux résultats de SENSE1. L’extraction de caractéristiques pourrait être faite plus précisément dans ces régions saillantes. Si on s’intéresse enfin à l’impact de la réduction de la taille de la zone observée sur l’évaluation de l’impact émotionnel, on déduit d’après la Figure 4.8 que l’utilisation d’un modèle d’attention visuelle est une très bonne alternative. 0 10 20 30 40 50 60 70 80 90 100 P1 P2 P3 Taux de classification Taille des images évaluées durant SENSE2 Même classe que durant SENSE1 Catégorisée durant SENSE2 P1 : ]7%, 50%[ P2 : [50%, 70%[ P3 : [70%, 100%] Figure 4.8: Taux de classification moyen des images durant SENSE2. "Même classe que durant SENSE1" correspond aux images qui sont classées dans la même classe durant SENSE1 et SENSE2. "Catégorisée durant SENSE2" correspond aux images non catégorisées durant SENSE1 et désormais classée durant SENSE2. En effet, en moyenne près de 80% des images sont classées de la même façon. Le résultat le plus intéressant concerne les images "non catégorisées" durant SENSE1. 79% sont désormais classées le plus souvent dans l’une des deux classes majoritaires 104Chapitre 4. Notre approche pour la reconnaissance des émotions de SENSE1. On peut alors conclure que cette réduction de la taille de la zone observée réduit le temps d’analyse et permet de prendre des décisions plus probantes dans des délais courts. 4.3.3 Récapitulatif de la base SENSE à partir des critères proposés Dans le Tableau 4.2 nous présentons la description de SENSE à partir des critères que nous avons proposés. Tableau 4.2: Description de SENSE avec les critères proposés dans la Section 4.1. Informations intrinsèques Nombre d’images 350 Évaluations par image (Moyenne) ∼ 100 pour SENSE1 ∼ 65 pour SENSE2 Images libres de droits Oui∗ Informations extrinsèques Disponibilité de la base +++ Modélisation des émotions ∼ Dimensionnelle∗∗ Hétérogénéité des évaluations Oui Nature de l’impact émotionnel ++ Complexité de l’évaluation + Évaluations physiologiques disponibles Aucune ∗ Uniquement pour les recherches académiques. ∗∗ Notre modélisation des émotions est équivalente à un modèle dimensionnel. Même si le nombre d’images de notre base est 3 fois inférieur à celui de IAPS, elle reste une base convenablement évaluée (∼ 100 évaluations par images pour SENSE1 et ∼ 65 pour SENSE2) avec une hétérogénéité des observateurs intéressante. Dans le Tableau 4.2, nous avons indiqué qu’aucune évaluation physiologique n’est disponible. Cependant, nous avons évalué les réponses EEG sur 12 images de notre base. Du fait de ce nombre très faible, nous préférons ne pas les mettre à disposition. Les évaluations se sont déroulées en trois sessions et les images ont été présentées dans un ordre pseudo-aléatoire. Durant une session chaque image était affichée pendant 8 secondes avec un "scintillement" (flickering) à 10Hz. Ensuite une image noire était affichée pendant 5 secondes. L’évaluation reprenait jusqu’à ce que les 12 images aient été vues. Seulement 4 participants ont effectué volontairement nos évaluations. Le nombre peu élevé de participants s’explique par les contraintes de ces évaluations. Ils devaient porter un casque comme celui de la Figure 4.9. En plus du casque, on leur appliquait sur le cuir chevelu, au niveau de l’électrode concernée, un gel pour augmenter la conductivité au niveau du cuir chevelu. Le signal EEG a été enregistré à l’aide de 4 électrodes positionnées sur la région occipitale en Pz, POz, PO3 et PO4 suivant le système 10-20, proposé par Sharbrough 105Chapitre 4. Notre approche pour la reconnaissance des émotions Figure 4.9: Exemple de casque utilisé pour récupérer le signal EEG [Cas ]. Figure 4.10: Positionnement des électrodes dans le système international 10-20 [Ele ]. Les 4 potentiels que nous avons utilisées sont entourés en rouge. et al. [Sharbrough 91] et illustré par la Figure 4.10. Le but de ces évaluations était d’étudier une possible relation entre les réponses SSVEP sur une base d’images "faiblement sémantiques". En effet, la plupart des études de la littérature sont faites sur des images plus sémantiques telles que celle de IAPS qui provoquent des réponses émotionnelles très fortes. Nous avons conclu de nos analyses que la réponse SSVEP obtenue au cours de nos expérimentations était bel et bien liée au contenu de nos images. Pour plus d’informations, les résultats de cette étude de corrélation sont présentés dans l’Annexe D. 106Chapitre 4. Notre approche pour la reconnaissance des émotions Nous disposons désormais d’une base d’images convenablement évaluée qui nous servira, entre autres, pour l’apprentissage du système de reconnaissance de l’impact émotionnel des images que nous proposons. En effet, la reconnaissance de l’impact émotionnel des images étant une tâche de haut niveau, elle nécessite l’utilisation d’un classifieur. Les résultats de notre solution seront évalués par rapport à la littérature par le biais de tests sur IAPS. Malgré ces évaluations, on ne peut pas effectuer des comparaisons efficaces puisqu’aucune information n’est donnée dans la littérature sur : – Le détail des images de IAPS retenues ; – Le nombre d’images utilisé pour l’apprentissage/le test. 4.4 Évaluation de descripteurs bas-niveau pour la reconnaissance de l’impact émotionnel d’une image Nous avons utilisé des descripteurs locaux et globaux afin de capter un maximum d’informations bas niveau. On peut toujours en choisir d’autres ou chercher pourquoi l’un serait plus intéressant qu’un autre. Mais du fait de l’utilisation d’un classifieur, on ne pourrait véritablement conclure sur la pertinence d’un descripteur par rapport à un autre. Dans ce cas de figure, aussi bien le descripteur que le classifieur combinent leurs apports. Bien évidemment si le descripteur n’est pas approprié, le classifieur ne comblera pas le déficit. Notre stratégie a été, dans un premier temps, de considérer quelques descripteurs qu’on peut qualifier d’intuitifs (couleurs par exemple). Nous avons ensuite étudier le comportement de descripteurs très précis en indexation classique (SIFT, GIST, . . . ). Afin de normaliser le processus de calcul des descripteurs, nous avons opté pour un redimensionnement des images de manière à ce que la plus grande dimension soit égale à 256. Pour des descripteurs de textures nécessitant des images carrées, nous avons utilisé la technique de "zero padding" afin d’obtenir des images de taille 256*256. 4.4.1 Descripteurs globaux Les trois descripteurs globaux que nous avons retenus sont les couleurs, les textures et le descripteur GIST. Couleurs Comme nous l’avons évoqué dans le chapitre précédent, les couleurs sont les premières caractéristiques discriminantes des émotions. Pour identifier les différentes couleurs, nous avons utilisé une segmentation couleur par croissance de régions [Fernandez-Maloigne 04]. L’initialisation des germes s’est faite en procédant à une analyse d’histogramme en niveaux de gris. La conversion en niveaux de gris a été réalisée conformément au standard NTSC dont la relation 107Chapitre 4. Notre approche pour la reconnaissance des émotions est : NdG = 0.299R + 0.587G + 0.114B. (4.1) L’analyse d’histogramme a été faite sur l’image en niveaux de gris afin de gagner en temps de calcul dans la recherche des zones homogènes. Les germes considérés sont les maxima de cet histogramme. La croissance quant à elle s’est faite dans l’espace couleur CIELAB, par le biais de la distance ∆E, pour minimiser les problèmes d’apparition de fausses couleurs au moment de la comparaison entre la couleur du pixel à agglomérer et la couleur moyenne de la région croissante. La distance ∆E entre ces deux couleurs est donnée par l’équation : ∆E = r (L1 − L2) 2 + (a ∗ 1 − a ∗ 2 ) 2 + (b ∗ 1 − b ∗ 2 ) 2  , (4.2) avec (L1, a∗ 1 , b∗ 1 ) et (L2, a∗ 2 , b∗ 2 ) deux couleurs dans l’espace CIELAB à comparer. Nous n’avons conservé que la couleur moyenne des différentes régions. Il existe plusieurs solutions pour fixer la valeur de ∆E. Dans les standards de cet espace, une distance de ∆E ≤ 3 indique que deux couleurs sont visuellement identiques. Nous avons considéré un voisinage en 8-connexités et les seuils suivants : – Différence entre un pixel à ajouter et la région déjà existante : ∆E ≤ 5 ; – Différence inter-région pour décider de la fusion de deux couleurs : ∆E ≤ 6. Puisque nous n’avons gardé que les couleurs moyennes des régions, à cette étape aucune considération de la localisation de la région n’est faite. Les différents seuils ont été déduits expérimentalement et nous permettent d’avoir un nombre acceptable de régions et de respecter les couleurs présentes dans l’image comme l’illustrent les images de la Figure 4.11. (a) (b) Figure 4.11: Illustration de la segmentation en région couleurs. Textures Les textures ont aussi une place importante dans le ressenti émotionnel. Une grille par exemple, quelle que soit sa couleur, a une sémantique d’enfermement ; le métal ne fait pas le même effet, que ce soit au toucher ou à la vue, qu’un brin d’herbe. 108Chapitre 4. Notre approche pour la reconnaissance des émotions La caractérisation des textures a été faite à l’aide des coefficients Wave Atoms calculés sur les images en niveaux de gris, obtenues avec l’équation (4.1). Ils sont basés sur la décomposition introduite par Demanet et Ying [Demanet 09]. Les Wave Atoms sont, en première approximation, une variante de paquets d’ondelettes 2D avec une longueur d’onde d’échelle parabolique. Sur la Figure 4.12, nous avons illustré la partition spectrale des coefficients des transformées en ondelettes et en Wave Atoms. On remarque que la transformée en ondelettes permet une dé- composition en trois orientations : horizontale, verticale et diagonale. Le nombre d’orientations dans le cas d’une transformée en Wave Atoms est bien plus important et est fonction de l’échelle considérée. Ce paramètre est implicite et varie de manière plus fine. L’intérêt des Wave Atoms réside dans leur parcimonie pour les textures localement oscillantes. Ils ont montré leur fort pouvoir descriptif pour ce type de textures que ce soit pour la compression [Demanet 09] ou la segmentation [Lecellier 09]. (a) (b) Figure 4.12: Partition spectrale des images de coefficients des transformées en ondelettes (a) et en Wave Atoms (b) [Lecellier 09]. Nous avons considéré 5 niveaux de décomposition illustrés par la Figure 4.13. Nous n’avons conservé que les échelles 4 et 5 qui nous offrent un compromis entre le niveau de description et la parcimonie. L’échelle 4 est composée de 91 orientations ; chaque orientation ayant 24 ∗ 2 4 soit 256 coefficients. L’échelle 5 quant à elle comporte 32 orientations de 1024 coefficients chacune. 4.4.2 Descripteurs locaux Tous les descripteurs locaux que nous avons évalués ont déjà été présentés dans la Sous-Section 1.1.2 du Chapitre 1. Nous avons choisi d’étudier le comportement des descripteurs suivants pour une tâche de reconnaissance de l’impact émotionnel des images : – SIFT ; – CSIFT ; – OpSIFT ; 109Chapitre 4. Notre approche pour la reconnaissance des émotions (a) Image originale (b) Décomposition sur 5 niveaux Figure 4.13: Illustration de la décomposition en Wave Atoms sur une image synthétique. – CM ; – CMI. Sur les images de SENSE1 nous avons utilisé le détecteur de Harris-Laplace. Puisque les images de SENSE2 sont de taille variable et qu’il n’y a pas toujours de caractéristiques locales détectées avec Harris-Laplace, nous avons procédé à la même quantification dense que celle utilisée dans le Chapitre 2 (2.7.1). 4.4.3 Protocole expérimental Nous avons utilisé les BoVW et les VLAD comme méthodes de représentation de nos descripteurs à l’exception des GIST. Les VLAD ont été calculés essentiellement sur les descripteurs locaux. Plusieurs vocabulaires visuels ont été testés. Pour les descripteurs GIST nous avons effectué une ACP. En effet, Oliva et Torralba [Oliva 01] préconisent d’utiliser cette solution pour réduire les dimensions des descripteurs calculés sur des images de même taille (ce qui est notre cas). Nous avons sélectionné ensuite un nombre K de vecteurs propres pour la projection qui nous permet de conserver 98% de nos données Pour la classification des émotions, nous avons choisi trois classes qui correspondent aux différentes natures d’émotions que nous avons utilisées au cours de nos évaluations subjectives. En ce qui concerne les images de IAPS, nous avons essayé de reconstituer ces différentes classes d’émotions à partir des informations que nous avons reçues avec la base d’images. Nous avons choisi le classifieur SVM avec un noyau linéaire dans son extension multiclasses basée sur la stratégie "Un contre Un". Le but de nos travaux n’est pas d’avoir le système d’apprentissage le plus performant. Le choix du SVM se justifie surtout parce qu’il se présente dans de nombreux travaux comme étant le meilleur classifieur pour les émotions, par exemple ceux de [Liu 11a]. La liste des images avec les configurations d’ensemble d’apprentissage et de test est donnée dans l’Annexe E. 110Chapitre 4. Notre approche pour la reconnaissance des émotions Nous avons choisi d’évaluer l’impact de différents paramètres constituant un système de recherche d’images par le contenu. Ainsi, nous avons étudié l’impact du choix du dictionnaire visuel, de la signature visuelle avant de présenter nos résultats en fonction des conclusions de ces analyses. Dans la suite de ce document, SENSE1 désigne l’ensemble des images évaluées durant les expérimentations SENSE1 et idem pour SENSE2. 4.4.4 Étude de l’impact du dictionnaire visuel Au début de nos travaux, nous avons émis l’hypothèse, comme c’est souvent le cas en recherche d’images par le contenu, qu’un dictionnaire visuel très hétérogène nous permettrait de pouvoir représenter les différentes motifs intéressants dans le cadre de notre tâche. Nous avons donc décider d’étudier l’impact de ce dernier sur les résultats de classification en utilisant dans un premier temps une signature visuelle de type "Sac de mots" (BoVW). Nous avons utilisé pour ce faire deux constructions différentes de dictionnaire visuel : 1. La première version utilise l’algorithme K-Means (1) (une ACP dans le cas du descripteur GIST). Nous avons défini une taille du dictionnaire visuel fonction du nombre de descripteurs calculé sur la base d’apprentissage 12. Soit K la taille du dictionnaire visuel ; elle est obtenue à l’aide de l’équation (4.3) : K = √4 N ∗ d, (4.3) avec N le nombre total de descripteurs et d la dimensionnalité du descripteur. Nous avons construit deux vocabulaires visuels à partir de SENSE1 et IAPS. Les résultats seront présentés en utilisant l’écriture Base_Dictionnaire. Ainsi SENSE1_S correspond aux images de SENSE1 dont les signatures visuelles ont été construites à partir du dictionnaire visuel issu de SENSE1. Dans le cas de GIST, ceci revient à définir les axes principaux à partir d’une des deux bases. 2. La seconde configuration utilise l’algorithme IteRaSel présenté dans le Chapitre 2 (Section 2). Nous avons utilisé les vocabulaires visuels générés pour la comparaison avec l’état de l’art sur UKB. Le dictionnaire visuel utilisé dans ce cas est complètement indépendant des deux bases d’images SENSE et IAPS. Mais cette dernière configuration n’a été mise en œuvre que pour les descripteurs de caractéristiques locales CM, CMI, SIFT et OpSIFT. Nous avons donc trois vocabulaires visuels pour les caractéristiques locales et deux pour les descripteurs globaux. Nous étudierons leur impact dans le cadre d’une tâche de reconnaissance des émotions. Cette étude sera faite à partir de deux critères : – Le taux de classification moyen pour chaque descripteur ; – La matrice de confusion pour les trois classes d’émotions. Nous présenterons dans un premier temps les résultats de classification dans les trois classes d’émotions : Négative, Neutre et Positive. En analysant la Figure 4.14, on remarque de suite que tous les différents descripteurs 12. Dans ce cas, la base d’apprentissage désigne l’ensemble des images à partir desquelles le vocabulaire visuel a été construit. 111Chapitre 4. Notre approche pour la reconnaissance des émotions Figure 4.14: Taux de classification moyens pour SENSE1 et IAPS. n’ont pas le même comportement en fonction des bases d’images et des dictionnaires visuels. Certains descripteurs ont tendance à avoir un comportement stable d’une base à l’autre et d’un dictionnaire visuel à l’autre. C’est notamment le cas de CSIFT avec une légère amélioration du taux de classification ∼ +2% avec l’utilisation du dictionnaire visuel obtenu à partir de IAPS. Contrairement à ce dernier, les résultats de CM ont l’air de dépendre du dictionnaire mais aussi de la base d’images. Que ce soit sur IAPS ou sur SENSE1, on observe des écarts de taux de classification notamment avec le dictionnaire construit à partir de la base Pascal VOC2012 (IteRaSel). Ces différences de taux de classification sont d’autant plus importants sur IAPS avec un dictionnaire issu de l’algorithme IteRaSel : ∼ −30% au minimum. La couleur affecte différemment chacune des bases. Les couleurs obtenus à partir de SENSE1 obtiennent de meilleurs résultats que ce soit sur SENSE1 ou sur IAPS. Le dictionnaire visuel des couleurs issu de IAPS induit une perte de ∼ −15% s’agissant du taux de classification correcte sur SENSE1 comparé à celui construit à partir de SENSE1. Ce résultat pourrait s’expliquer par la grande variabilité en couleurs de notre base comparée à IAPS. Cette dernière comporte beaucoup d’images négatives avec des couleurs sombres alors que SENSE1 c’est le contraire. Pour finir, en ce qui concerne le descripteur Wave Atoms, les deux échelles donnent des résultats satisfaisants (> 33% qui est le taux de classification aléatoire) notamment avec un dictionnaire issu de IAPS sur les deux bases. Nous avons, dans un second temps, étudié ce qui se passe au sein de chaque classe à travers les matrices de confusion. Afin de simplifier les illustrations, seules les diagonales, correspondant au taux de bonne classification dans chaque classe seront représentées sur la Figure 4.15. Cette dernière permet de mieux analyser ce 112Chapitre 4. Notre approche pour la reconnaissance des émotions (a) IAPS : les résultats de la classe "Neutre" sont mis en évidence. Les images de cette classe sont très difficiles à reconnaître. (b) SENSE1 : IteRaSel permet de mieux reconnaître les images neutres. Figure 4.15: Taux de bonne classification dans chacune des classes d’émotions pour chaque descripteur. C’est tout à fait normal qu’il n’y ait aucun taux de bonne classification indiqué pour IteRaSel pour les descripteurs globaux : Couleurs, GIST, WA4 et WA5. Gist (98) indique que nous avons gardé 98% des informations lors de l’ACP. qui se passe pour chaque classe d’émotions. Les images neutres apparaissent comme étant les plus difficiles à classer surtout sur IAPS. Aucun descripteur ne fait mieux qu’une classification aléatoire. SIFT qui obtient les meilleurs résultats donne 30% 113Chapitre 4. Notre approche pour la reconnaissance des émotions pour SENSE1, 25% pour IAPS et 20% pour IteRaSel. Sur IAPS, un descripteur en particulier s’illustre comme étant le meilleur pour les images neutres avec le dictionnaire IteRaSel : CM (95% des images neutres bien classées sur IAPS et 57.32% sur SENSE). Ce résultat vient tout simplement du fait que, dans cette configuration, CM classifie la majorité des images dans la classe "Neutre" aussi bien pour SENSE1 que pour IAPS. C’est d’ailleurs ce qui explique que ce descripteur obtienne le taux de classification le plus bas (cf. Figure 4.14) avec le dictionnaire IteRaSel. Que ce soit avec le dictionnaire visuel issue de SENSE1 ou IAPS, la plupart des descripteurs ont un comportement quasi-identique pour les classes d’émotions "Né- gative" et "Positive". Les couleurs quant à elles permettent d’identifier les émotions positives et négatives. Nous nous sommes intéressé de plus près à la couleur du fait de tous les travaux dans la littérature qui lui sont consacrés. Ce descripteur qui offre un bon taux de classification moyen (cf. Figure 4.14), ne permet pas de correctement classer les images neutres. D’ailleurs sur IAPS, quel que soit le dictionnaire visuel, aucune image neutre n’est classée neutre. Elles sont toutes classées négatives ou positives comme on peut le voir dans les Tableaux 4.3 et 4.4. Ces tableaux correspondent aux matrices de confusion des couleurs pour IAPS. Tableau 4.3: Matrice de confusion des couleurs IAPS_I Neg Neut Pos Neg 81.97% 0 18.03% Neut 65% 0 35% Pos 74.14% 0 25.86% Tableau 4.4: Matrice de confusion des couleurs IAPS_S Neg Neut Pos Neg 85.25% 0 14.75% Neut 70% 0 30% Pos 75.86% 0 24.14% On conclut donc que ce descripteur permet surtout de classer les images négatives. En effet, pour les deux autres classes une simple classification aléatoire (33%) serait meilleure. Puisque nous avons décidé d’évaluer les outils de recherche d’images par le contenu pour la reconnaissance des émotions, l’autre facteur très déterminant dans les résultats est la signature visuelle. Nous avons donc étudié son impact. 4.4.5 Évaluation de l’impact de la signature visuelle Outre la représentation "Sac de mots", nous avons utilisé la signature visuelle VLAD. Pour ce faire, nous avons choisi K=64. En effet, comme nous l’avons déjà indiqué dans le Chapitre 1 (1.2.2), quand on utilise les VLAD on n’a besoin de très peu de mots. Comme lors de l’étude de l’impact du dictionnaire visuel, nous avons étudié le taux de classification moyen mais également les matrices de confusion. Pour ces travaux 114Chapitre 4. Notre approche pour la reconnaissance des émotions nous n’intégrons pas le dictionnaire IteRasel (qui n’a pas été utilisé pour les descripteurs globaux du fait de l’utilisation de la saillance visuelle), ni le descripteur GIST (qui ne peut être utilisé ni avec la signature visuelle BoVW ni avec VLAD). Figure 4.16: Taux de classification moyens pour les bases SENSE1 et IAPS. Nous avons mis en évidence le comportement des descripteurs globaux. Sur la Figure 4.16, nous avons représenté les taux de classification moyen pour les bases SENSE1 et IAPS. La première remarque concerne les descripteurs globaux : la signature visuelle VLAD ne leur conviendrait pas tous (les couleurs faisant l’exception) et ceci quel que soit le dictionnaire ou la base. Nous avons vérifié cette première conclusion en étudiant les classifications au sein de chaque classe d’émotions. Sur la Figure 4.17, nous avons mis en évidence le comportement des descripteurs globaux pour chaque signature visuelle pour les émotions négatives et positives. On ne note aucune différence importante. Les résultats dépendent aussi bien du descripteur, du dictionnaire visuel que de la base d’image. Si on considère le dictionnaire visuel construit à partir de SENSE1, la classe "Positive" est la plus affectée par le changement de signature visuelle pour la base SENSE1. C’est tout le contraire en ce qui concerne IAPS ; c’est plutôt la classe "Négative" qui est affectée. Le changement de signature visuelle affecte différemment SENSE1 et IAPS. En effet, sur la première les descripteurs globaux modifient leur comportement avec VLAD pour les images négatives sur IAPS et positives sur SENSE1. Ce sont des résultats peu surprenants dans la mesure où VLAD a été proposé pour les descripteurs de caractéristiques locales. Le fait que les bases soient affectées différemment est tout à fait logique du fait de leur contenu. IAPS contient énormément d’images négatives alors que pour SENSE1 c’est le contraire. Ceci implique que le taux de classification moyen sur ces deux bases dépend énormément du taux de reconnaissance au sein de la classe majoritaire. 115Chapitre 4. Notre approche pour la reconnaissance des émotions (a) Signature visuelle BOW (b) Signature visuelle VLAD Figure 4.17: Taux de bonne classification dans chaque classe d’émotion. Nous avons mis en évidence le comportement des descripteurs globaux pour les classes "Positive" et "Né- gative". 4.4.6 Récapitulatif des premiers résultats Dans un premier temps, nous avons étudié l’impact du dictionnaire visuel sur les résultats de classification. Cette étude nous a permis de vérifier notre hypothèse de 116Chapitre 4. Notre approche pour la reconnaissance des émotions départ concernant l’importance de l’hétérogénéité du vocabulaire dans le cadre de notre tâche. Si on ne considère que les taux de classification moyens sur les 3 classes d’émotions, à part quelques exceptions, les différents descripteurs ont un comportement équivalent en fonction des dictionnaires. Les différences principales se décèlent quand on s’intéresse à ce qui se passe au sein de chaque classe. On découvre alors que certains dictionnaires sont plus adaptés à certaines émotions. C’est le cas du dictionnaire IteRaSel qui est plus adapté pour les émotions neutres, ceci indépendamment de la base d’images ou du descripteur. L’autre conclusion générale à ces premiers travaux concerne la difficulté à identifier les émotions neutres. Il s’agit d’émotions complexes à modéliser. On comprend alors mieux pourquoi, dans la littérature, elles ne sont pas souvent traitées. C’est pour cette raison que, dans la suite, nous ne les considérons plus. Seules les images positives et négatives seront traitées. L’étude de l’impact de la signature visuelle n’a montré aucune différence importante. Néanmoins nous avons remarqué que la signature visuelle VLAD ne convenait pas aux descripteurs globaux (les couleurs faisant l’exception). Concrètement les descripteurs WA4 donne dans la majorité des cas des résultats moins bons qu’un tirage aléatoire (< 33%) avec la signature visuelle VLAD. D’une façon plus générale, les deux bases d’images sont affectées par la modification des signatures visuelles dans leur classe la plus représentative. Nous avons donc décidé dans la suite d’utiliser la signature visuelle "Sac de mots visuels" pour les descripteurs globaux et VLAD pour les descripteurs de caractéristiques locales. 4.4.7 Présentation de nos résultats Ayant supprimé la classe "Neutre", nous avons recommencé un apprentissage sur les classes "Positive" et "Négative". Nous présenterons d’abord les résultats de chaque descripteur et ensuite les résultats d’une combinaison avec une stratégie "Majority Voting". Comme nous l’avons annoncé précédemment, les descripteurs de caractéristiques locales seront représentés avec VLAD, les couleurs et les textures avec BoVW et GIST avec une projection après une ACP. Seuls les deux vocabulaires visuels construits à partir de K-means sur SENSE1 et de IAPS seront utilisés ici du fait de l’utilisation de VLAD. Nous préférons utilisés cet algorithme puisque cette signature visuelle a été définie à partir de ce type de dictionnaire visuel. Toutes les signatures visuelles sont normalisées L2. Le Tableau 4.5 présente les résultats de classification pour chaque descripteur. Comme nous l’avons déjà remarqué dans les évaluations précédentes, les différents descripteurs n’ont pas les mêmes comportements en fonction des bases et des dictionnaires visuels associés. Les mêmes conclusions faites sur 3 classes sont valables pour 2 classes d’émotions. Par exemple ; SIFT donne quasiment les mêmes résultats quelle que soit la configuration base d’images/dictionnaire visuel aussi bien pour la reconnaissance des images positives que négatives. Les descripteurs CMI et WA4 quant à eux paraissent beaucoup plus appropriés pour la reconnaissance des images négatives (3 configurations sur 4 ; la configuration IAPS_I est l’exception). Ces deux descripteurs peuvent d’ailleurs être considérés comme polyvalents pour la reconnaissance de l’impact émotionnel des images puisque dans chaque classe d’émotions ils permettent de reconnaître au moins 50% des images, garantissant un score meilleur 117Chapitre 4. Notre approche pour la reconnaissance des émotions Tableau 4.5: Taux moyens des classifications pour chaque descripteur. La signature visuelle BoVW a été utilisée pour les descripteurs globaux et VLAD pour les locaux. Les résultats en rouge correspondent à ceux qui sont moins bons qu’une classification aléatoire (< 50%). Configuration base de test_Dictionnaire visuel Descripteurs Classes d’émotions SENSE1_S SENSE1_I IAPS_S IAPS_I Moyenne Descripteurs globaux Couleurs Négative 40% 70% 85.25% 78.69% 68.49% Positive 80.21% 43.75% 27.59% 29.31% 45.22% WA4 Négative 50% 50% 77.05% 68.85% 61.48% Positive 30.21% 52.08% 20.69% 32.76% 33.94% WA5 Négative 30% 60% 57.38% 44.26% 47.91% Positive 50% 65.62% 41.38% 58.62% 53.91% GIST Négative 90% 40% 42.62% 62.3% 58.73% Positive 27.08% 61.46% 56.90% 37.93% 45.84% Descripteurs locaux CM Négative 10% 80% 40.98% 60.66% 47.91% Positive 88.54% 54.17% 68.97% 51.72% 65.85% CMI Négative 70% 60% 60.66% 86.89% 69.39% Positive 57.29% 58.33% 55.17% 27.59% 49.60% Négative 70% 70% 52.46% 60.66% 63.28% SIFT Positive 56.25% 52.08% 51.72% 53.45% 53.38% CSIFT Négative 80% 90% 73.77% 67.21% 77.75% Positive 50% 54.17% 53.45% 50% 51.91% OpSIFT Négative 60% 60% 65.57% 60.66% 61.56% Positive 47.92% 52.08% 48.28% 63.79% 53.02% Négative 55.55% 64.44% 61.75% 65.58% 61.83% Moyenne Positive 54.16% 54.86% 47.13% 45.02% 50.29% qu’une classification aléatoire. Le changement de dictionnaire visuel a peu d’impact globalement sur le comportement des descripteurs pour une classification en 2 classes. Néanmoins quelques-uns, comme CM, sont affectés sur la base SENSE1. Le taux d’images négatives reconnues est nettement supérieur avec le dictionnaire visuel construit à partir de IAPS (+70% sur SENSE1 et +20% sur IAPS). En ce qui concerne les images positives on observe l’effet inverse : -34% sur SENSE1 et -17% sur IAPS. Ceci illustre très bien l’impact de la variabilité de la base. En effet, IAPS contient énormément d’images négatives : le dictionnaire construit avec ses images permet de mieux reconnaître ces dernières. Construire le dictionnaire visuel avec SENSE1 améliore la reconnaissances des images positives puisque cette base en contient énormément. Globalement les caractéristiques basées sur les SIFT offrent de bons taux de pré- 118Chapitre 4. Notre approche pour la reconnaissance des émotions Tableau 4.6: Comparaison des taux de classification avant et après une fusion MV. Avant fusion Après fusion SENSE1_S Négative 55.56% 60% Positive 54.17% 57.29% Moyenne 54.86% 57.55% SENSE1_I Négative 64.44% 90% Positive 54.86% 64.58% Moyenne 59.65% 66.98% IAPS_S Négative 61.75% 75.41% Positive 47.13% 41.38% Moyenne 54.44% 58.82% IAPS_I Négative 65.58% 77.05% Positive 45.02% 46.55% Moyenne 55.30% 62.18% diction en utilisant un dictionnaire de seulement 64 mots et une signature visuelle VLAD. La meilleure reconnaissance d’images négatives est faite grâce à CSIFT avec 90% des images de SENSE1 reconnue avec le dictionnaire de IAPS. Les descripteurs globaux s’en sortent également très bien montrant ainsi une complémentarité entre les caractérisations des images que nous avons choisies. Ceci s’illustre très bien par les résultats de WA4 et WA5. Le premier est plus adapté pour les images négatives alors que le second sera préféré pour les positives. On pourrait également conclure que les images négatives sont beaucoup plus faciles à reconnaître sur les deux bases que nous avons choisies. La tâche de reconnaissance de l’impact émotionnel des images étant complexe, on ne peut choisir un seul descripteur. Le contenu des bases d’images joue un rôle important et les techniques de recherche d’images par le contenu s’adaptent très bien. Dans le Tableau 4.6, nous avons résumé le résultat de la comparaison des taux de classification moyens avant et après la fusion avec la méthode "Majority Voting" que nous notons MV. La classe finale de l’image correspond à celle donnée par un maximum de classifieurs. On constate une nette amélioration après la fusion MV. Par exemple la reconnaissance des images négatives est impacté positivement de 15% en moyenne. D’ailleurs les meilleurs taux de classification après la fusion sont obtenus avec le dictionnaire construit à partir de IAPS. Cette conclusion est également valable pour les images positives de notre base. Avant la fusion, 54.86% des images positives étaient reconnues contre 64.58% après. Notons que la fusion ne change pas les résultats de reconnaissance des images positives de IAPS qui sont en moyenne moins bons qu’une classification aléatoire. Si on considère plus généralement ces résultats après fusion, on remarque qu’ils sont 119Chapitre 4. Notre approche pour la reconnaissance des émotions améliorés surtout en ce qui concerne notre base d’images et ceci indépendamment des dictionnaires visuels et des émotions : – ∼ +15% pour les images négatives et ∼ +6% sur les positives ; – ∼ +17% avec le dictionnaire visuel de IAPS et ∼ +3.7% avec le dictionnaire visuel de SENSE1. Les premières analyses de nos travaux sur la reconnaissance de l’impact émotionnel des images à partir des techniques "traditionnelles" de recherche d’images par le contenu montre que : – Les différents descripteurs que nous avons choisis remplissent bien leur rôle. Certes les taux de classification ne sont pas comparables à ceux obtenus en CBIR mais nous avons remarqué un comportement relativement stable d’une configuration de dictionnaire visuelle à une autre, ; à l’exception du descripteur CM pour les émotions négatives. L’étude de l’impact de la signature visuelle a montré que les descripteurs locaux représentés avec VLAD donnaient de meilleurs résultats comparés à BoVW ; – Les descripteurs locaux et globaux sont complémentaires et nous ne pourrions conclure facilement à un descripteur idéal pour la tâche de reconnaissance des émotions. SIFT et ses extensions couleur offrent ici encore des résultats intéressants et pourraient à la rigueur si on devrait faire un choix, être ceux que nous retiendront. Comme nous l’avons remarqué dans nos travaux en recherche d’images par le contenu sur UKB dans la partie précédente, le descripteur CMI est encore un compromis intéressant. Une fois encore il se classe vraiment bien malgré sa dimensionnalité derrière SIFT et ses extensions en couleur ; – La fusion que nous proposons même basique permet d’améliorer considérablement les résultats notamment sur notre base et les images négatives. Nos travaux sur IAPS et SENSE1 montrent que ces dernières sont les images les mieux reconnues avec les descripteurs que nous avons choisis. 4.4.8 Comparaison de nos résultats avec la littérature Cette comparaison se fera essentiellement sur IAPS puisqu’elle sert souvent d’évaluation aux différents systèmes de la littérature. Nous avons évoqué dans la Section 4.1 que la comparaison des travaux de la littérature n’est pas toujours représentative. En effet, les modélisations des émotions diffèrent le plus souvent rendant alors la comparaison délicate. Nous avons choisi trois travaux de la littérature : – Ceux de Wei et al. [Wei 08] qui utilisent une description sémantiques des images pour la classification émotionnelle des images. Ils ont choisi une modélisation discrète des émotions en 8 classes : "Colère", "Désespoir", "Intérêt", "Irritation", "Joie", "Plaisir", "Fierté" et "Tristesse". Les taux de classification qu’ils obtiennent sont compris entre 33.25% pour la classe "Plaisir" et 50.25% pour "Joie". On ne dispose par contre d’aucune information sur la base d’images qu’ils ont utilisée ; – Ceux de Liu et al. [Liu 11a] qui utilisent des descripteurs de couleur, texture, forme et un ensemble de descripteurs sémantiques basés sur les couleurs. Les résultats qu’ils obtiennent sur IAPS sont en moyenne de 54.70% après une fusion avec la Théorie de l’ Évidence et 52.05% avec une fusion MV. Pour leur 120Chapitre 4. Notre approche pour la reconnaissance des émotions classification, ils ont retenu 4 classes en subdivisant le modèle dimensionnel Valence/Éveil subdivisant en 4 quadrants ; ceux définis par l’intersection des axes (Cf. Figure 3.5) ; – Ceux de Machajdik et al. [Machajdik 10] dans lesquels des attributs de couleur, textures, composition et contenu sont utilisés. Ils utilisent une catégorisation discrète en 8 classes qui sont : l’amusement, l’excitation, la satisfaction et l’émerveillement comme émotions positives et la colère, le dégoût, la peur et la tristesse pour représenter les émotions négatives. Les taux de classification moyens sont compris entre 55% et 65%. Le taux le plus bas est obtenu pour la classe "Satisfaction" et le plus élevé pour la classe "Émerveillement". Tout comme dans notre cas la répartition des images au sein des différentes classes d’émotions n’est pas équitable. La plus petite classe contient 8 images et la plus grande 63. Dans ces résultats, ils présentent les taux de classification de leur meilleur descripteur dans chaque catégorie. Si on compare, nos résultats à ceux obtenus dans les trois travaux ci-dessus, nous nous situons plutôt dans la moyenne haute sur IAPS avec des résultats de 54.44% et 55.30% avant fusion et 58.82% et 62.18% après. La méthodologie que nous avons adoptée nous permet d’égaler les méthodologies de la littérature voire de faire mieux s’agissant des taux de bonne classification. Notons qu’il ne s’agit là que d’un indice et non pas d’un jugement sur les méthodes du fait de l’éclectisme des travaux dans le domaine. Cette comparaison nous permet de valider notre approche qui si elle offrait des résultats très en dessous de la littérature pourrait être jugée d’inappropriée. Une fois cette validation de notre approche faite, nous avons intégré la saillance visuelle qui s’est avérée utile dans nos évaluations subjectives. En effet, les évaluations SENSE2 ont prouvé qu’elle pouvait permettre d’améliorer l’évaluation subjective des images par la réduction de la taille de la zone observée. Nous avons alors étudié l’apport de cette information dans notre approche. 4.5 Prise en compte de la saillance visuelle Nous n’avons effectué ce travail que sur les descripteurs de caractéristiques locales. Dans un premier temps, nous avons pondéré les différents vecteurs de descripteurs par la saillance visuelle des points clés. Les résultats obtenus d’un point de vue taux de classification correcte sont similaires à ceux obtenus dans le Chapitre 2. Aucune amélioration signifiante n’a été trouvée. Nous avons alors opté pour la classification des images de SENSE2. Pour rappel, ces images sont des vignettes représentant le rectangle englobant les régions saillantes que nous avons évaluées. Ces dernières sont de tailles différentes allant de 3% à 100% de la taille des images de SENSE1. Nous avons alors opté pour une stratégie de sélection des caractéristiques locales diffé- rentes. En effet, sur les plus petites images, le détecteur de Harris-Laplace que nous avons utilisé précédemment ne détecte pas toujours des caractéristiques locales dans la configuration que nous avons retenue. Nous avons alors opté pour une description dense des images de SENSE2 en utilisant une fenêtre de taille 15*15 tous les 6 121Chapitre 4. Notre approche pour la reconnaissance des émotions pixels. Cette étude a été faite avec le dictionnaire IteRaSel avec la signature visuelle BoVW ; elle correspond mieux à ce dictionnaire visuel. Pour que la comparaison des résultats de SENSE2 soit complète, nous présenterons d’abord les résultats de l’utilisation de la quantification dense sur SENSE1 et IAPS. 4.5.1 Sélection dense des caractéristiques locales Cette étude nous permet d’avoir un aperçu de l’impact de la sélection des caractéristiques locales. Les résultats de cette étude sont présentés sur la Figure 4.18. (a) Taux de classification moyens sur les 2 classes "Positive" et "Négative". (b) Taux de classification moyens pour chacune des classes "Positive" et "Négative". Figure 4.18: Résultats de l’étude de l’impact de la sélection des caractéristiques locales. Si on analyse les résultats en considérant les taux de classification moyen sur les 2 classes d’émotions, on remarque que la sélection des caractéristiques locales de façon dense n’améliore pas significativement les résultats. Les plus grandes différences se notent pour le descripteur CM et sur la base SENSE1. Si on regarde de plus près ce 122Chapitre 4. Notre approche pour la reconnaissance des émotions qui se passe dans chaque classe, on note que la classe d’émotions la plus affectée par la modification de la sélection des caractéristiques locales est la classe dominante de chaque base d’images. Les différences notées au niveau de la classification pour le descripteur CM se confirme dans ces classes dominantes. D’ailleurs, nous avons quelque part une explication du comportement de ce descripteur. Il s’agit d’un attribut qui représente les moments couleur d’une région autour d’une caractéristique locale. En effet, en faisant une quantification dense, on tombe sur des régions homogènes qui peuvent se répéter très souvent sans rien apporter à la description de l’image. Globalement, la sélection dense des caractéristiques locales n’améliore pas vraiment les résultats de classification. Le gain en taux de classification moyen est de +0.71% sur SENSE1 et +1.68% sur IAPS. 4.5.2 Classification des images de SENSE2 La classification des images de SENSE2 revient à faire un filtrage des caractéristiques locales par la saillance visuelle. Nous présenterons également les résultats pour une classification en 3 classes pour que l’analyse des résultats soit complète. Figure 4.19: Taux de classification moyens obtenus sur SENSE2 et SENSE1. Que ce soit dans le cadre d’une classification en 3 ou en 2 classes, SENSE2 donne des résultats équivalents voire meilleurs à ceux de SENSE1 excepté pour le descripteur CM comme on peut le voir sur la Figure 4.19. Les résultats obtenus avec ce descripteur sont cohérents du fait des conclusions précédentes. Les résultats s’améliorent de façon intéressante pour les descripteurs SIFT et OpSIFT ∼ +6% et +10% respectivement pour 3 et 2 classes. Si on analyse le comportement des descripteurs en fonction des classes d’émotions (Figure 4.20), on remarque que cette amélioration des résultats concerne essentiellement la classe "Négative" pour SIFT et la classe "Positive" pour OpSIFT. L’utilisation des images de SENSE2 améliore non seulement l’évaluation de notre bases au cours des tests subjectifs, mais en plus les émotions positives et négatives 123Chapitre 4. Notre approche pour la reconnaissance des émotions (a) Classification suivant 3 classes. (b) Classification suivant 2 classes. Figure 4.20: Taux de classification moyens pour les descripteurs locaux obtenus sur SENSE2 et SENSE1. sont mieux reconnues avec notre système. SIFT et OpSIFT sont les meilleurs suivis par CMI. Les images neutres restent toujours aussi complexes à reconnaître. Tout comme pendant l’évaluation, nous pouvons alors conclure que l’utilisation de la saillance visuelle, telle que nous l’avons présentée ici permet d’améliorer les résultats en augmentant le nombre d’images négatives et positives reconnues. Ces résultats sont d’autant plus intéressants qu’ils donnent des résultats satisfaisants et augurent de perspectives intéressantes. Notre hypothèse de départ de travailler sur une partie de l’image en espérant avoir des résultats intéressants se vérifie. Le filtrage par la saillance visuelle est donc une très bonne alternative de sélection dans notre approche de la reconnaissance de l’impact émotionnel des images. 124Chapitre 4. Notre approche pour la reconnaissance des émotions 4.6 Récapitulatif des différents résultats de l’évaluation des descripteurs de recherche d’images par le contenu Les travaux dont nous avons présenté les résultats s’articulent autour des deux bases d’images SENSE1 et SENSE2. Nous avons utilisé l’architecture d’un système de recherche d’images par le contenu que nous avons évaluée pour la reconnaissance de l’impact émotionnel des images illustré par la Figure 4.21. Figure 4.21: Résumé de l’approche que nous avons utilisée pour la reconnaissance de l’impact émotionnel des images. Comme pour une recherche d’images par le contenu, plusieurs étapes du processus peuvent modifier les résultats. Il s’agit notamment de la construction du dictionnaire visuel et du choix de la signature visuelle. Nous avons étudié l’impact de ces deux paramètres en utilisant 3 dictionnaires visuels différents et deux signatures visuelles. Le changement de dictionnaire visuel n’a pas montré d’impact considérable sur les résultats de classification. Les trois dictionnaires que nous avons utilisés sont issus des bases SENSE, IAPS et Pascal VOC2012. En ce qui concerne ce dernier, nous l’avons construit avec la méthode IteRaSel présentée dans le Chapitre 2. Cette étude nous a permis de vérifier notre hypothèse de départ concernant l’importance de l’hé- térogénéité du vocabulaire dans le cadre de notre tâche. Si on ne considère que les taux de classification moyens sur les 3 classes d’émotions, à part quelques exceptions, les descripteurs que nous avons choisis ont un comportement équivalent. Les diffé- rences principales se situent au sein de chaque classe. Nous avons alors découvert que certains dictionnaires sont plus adaptés pour certaines émotions. C’est le cas du dictionnaire IteRaSel qui est plus adapté pour les émotions neutres quelle que soit la base d’images et le descripteur. La modification de la signature visuelle, quant à elle, nous a permis de pouvoir choisir un type de signature visuelle en fonction de la nature du descripteur. Nous avons en effet conclu de nos analyses que la signature visuelle VLAD ne convenait pas aux 125Chapitre 4. Notre approche pour la reconnaissance des émotions descripteurs globaux et ceci quel que soit le dictionnaire ou la base. Cette constatation nous a permis de justifier nos choix de signatures visuelles pour la comparaison de nos résultats aux travaux de la littérature. Nous avons également exclu par la suite la classe "Neutre" du fait de sa complexité de reconnaissance. Nos résultats sont très encourageants et dans certaines configurations meilleurs que ceux de la littérature en matière de taux de reconnaissance. Ils montrent que les descripteurs locaux et globaux sont complémentaires pour la reconnaissance de l’impact émotionnel. Néanmoins le choix du descripteur le plus efficace ou le mieux indiqué reste délicat. SIFT et ses extensions couleur offrent des résultats intéressants et pourraient être préconisés. Le descripteur CMI est encore un compromis intéressant. Une fois encore, il se classe vraiment bien, malgré sa dimensionnalité, derrière SIFT et ses extensions couleur comme ce fût déjà le cas pour la recherche d’images par le contenu dans le Chapitre 2. Nous avons proposé d’utiliser une combinaison des ré- sultats des différentes descripteurs à l’aide de la méthode "Majority Voting". Cette fusion permet d’améliorer considérablement les résultats notamment sur notre base. Les images négatives sont également mieux reconnues sur les deux bases d’images. La comparaison avec les résultats de la littérature que nous avons faite n’est aucunement qualitative puisque les approches sont différentes. Elle permet d’avoir une idée des taux de classification de la littérature pour valider notre approche. La mé- thodologie que nous avons adoptée égale les résultats de la littérature s’agissant des taux de bonne classification. Nous nous situons plutôt dans la moyenne haute sur IAPS avec des résultats de 54.44% et 55.30% avant fusion et 58.82% et 62.18% après respectivement pour les images négatives et positives. Pour finir, nous avons étudié l’hypothèse que la réduction des images par la saillance visuelle pourrait également être intéressante pour la classification. Nous avons en effet noté une amélioration des résultats pour les classes "Négative" et "Positive". Cette amélioration est conséquente pour les descripteurs SIFT et OpSIFT ; ∼ +6% et ∼ +10% respectivement pour 3 et 2 classes. Ces résultats combinés aux pré- cédents, nous permettent de pouvoir préconiser l’utilisation de SIFT et OpSIFT comme descripteurs de caractéristiques locales pour la reconnaissance de l’impact émotionnel des images. Il s’agit là des deux meilleurs descripteurs si on considère toutes nos expérimentations. Conclusions Dans nos travaux, nous avons pris le parti de considérer la tâche de reconnaissance de l’impact émotionnel des images comme une tâche de recherche d’images par le contenu. Ici le contenu est une information haut niveau, fortement sémantique et influencée par le vécu de chacun. Cette dernière ne pourra pas être uniquement quantifiée avec des descripteurs bas niveau ou résumée par un ensemble fini et précis d’informations bas niveau. C’est ces deux derniers points qui rendent la tâche encore plus difficile surtout que la plupart des études faites dans le domaine sont très hétérogènes, dépendant de plusieurs critères dont les deux plus importants sont la base d’images et les descripteurs. Le premier point a été le plus handicapant dès le début de nos travaux. En effet, il n’existe aucun répertoire des différentes bases et on 126Chapitre 4. Notre approche pour la reconnaissance des émotions découvre le plus souvent au fil de la littérature les différentes évaluations disponibles. Nous avons alors proposé une nouvelle taxonomie afin de faciliter la comparaison et par la même occasion une description résumée de ces dernières. Chacune des bases de la littérature a ses contraintes qui peuvent être plus ou moins un frein. Nous nous sommes intéressés à trois bases en particulier de la littérature : les deux bases de Machajdik et al. [Machajdik 10] et IAPS [Lang 08]. Les deux premières parce que leurs auteurs furent les premiers à répertorier quelques insuffisances de la littérature et la dernière qui fait office de consensus pour évaluer ses résultats. Chacune souffre de différentes lacunes ; des défauts d’évaluation aux restrictions de distribution en passant par le contenu. Au vu de nos motivations d’évaluation, il nous paraissait indispensable de créer une nouvelle base et surtout de l’évaluer de façon convenable. La base SENSE que nous avons construite comporte 350 images évaluées de deux façons différentes : une évaluation classique et une évaluation en ré- duisant la taille des régions observées à partir de la saillance visuelle. Pour ces deux expérimentations subjectives, plus de 60 évaluations par images en moyenne avec une hétérogénéité des participants nous permettent de proposer une base d’images bien annotée à la communauté. L’utilisation de la saillance visuelle lors des évaluations dans nos tests a permis de réduire le nombre d’images non catégorisées. L’ambiguïté à été levée pour 79% des images concernées au cours des tests SENSE1. Ces évaluations nous ont servi de vérité terrain en plus de IAPS pour tester notre approche pour la reconnaissance de l’impact émotionnel des images. Nous avons choisi d’utiliser un schéma de recherche d’images par le contenu couplé à un système d’apprentissage pour la reconnaissance des émotions. Les descripteurs que nous avons retenus sont traditionnellement utilisés en CBIR et font preuve d’une précision intéressante. Nous avons alors émis et vérifié l’hypothèse que ces descripteurs bas niveau encoderaient également des informations intéressantes pour la tâche de haut niveau qui nous intéresse. Les deux signatures visuelles que nous avons retenues sont : BoVW et VLAD. Toutes les deux nécessitent la construction d’un dictionnaire traditionnellement issu d’un clustering K-means. Nous avons justement testé l’influence de ce dictionnaire en modifiant à la fois la base d’images mais également la technique de construction du dictionnaire. Nous avons utilisé la signature visuelle BoVW pour cette première étude et aucune modification conséquente n’a été notée. Néanmoins, nous avons remarqué que le dictionnaire IteRaSel se distinguait pour les images neutres, celles là même qui sont les plus complexes à reconnaître. Le choix de la signature visuelle affecte quant à lui différemment les descripteurs locaux et globaux. Ainsi nous avons remarqué que VLAD correspondait mieux aux descripteurs locaux et BoVW aux globaux. C’est donc cette configuration que nous avons retenue au moment de comparer nos travaux à ceux de la littérature. Les résultats de cette comparaison montrent que l’approche que nous avons retenue, illustrée par la Figure 4.21, semble convenir pour la tâche de reconnaissance de l’impact émotionnel. Nos taux de classification se situent dans la moyenne haute de la littérature. Les descripteurs de recherche d’images par le contenu peuvent donc être utilisés pour la reconnaissance de l’impact émotionnel. Au cours de nos différentes expérimentations, les résultats montrent une certaine complémentarité en fonction des classes d’émotions. La méthode basique "Majority Voting" que nous avons utilisée montre une performance intéressante sur les bases IAPS et SENSE1 notamment 127Chapitre 4. Notre approche pour la reconnaissance des émotions pour la reconnaissance des images négatives (∼ +15%). Dans la dernière partie de ce chapitre nous avons utilisé les images de SENSE2, mimant ainsi une segmentation de régions d’intérêt basée sur la saillance visuelle. Nous avons choisi des descripteurs locaux pour résumer ces régions en optant pour une sé- lection dense des caractéristiques locales. Ce choix est principalement motivé par la taille variable de ces régions segmentées : de 3% à 100% de la taille des images originales. Les taux de classification moyens sont globalement étonnamment plus élevés. Cette segmentation en régions d’intérêt grâce à la saillance visuelle semble résumer au mieux les images simulant la réduction d’ambiguïté constatée au cours des expé- rimentations subjectives. Le gain en taux de classification est remarquable au sein de la classe "Négative" avec les descripteurs SIFT et OpSIFT ∼ +6% et +10% respectivement pour 3 et 2 classes. Ces résultats augurent de bonnes perspectives que nous aborderons dans la conclusion générale de ce document. 128Conclusion Partie 2 Dans cette dernière partie consacrée à la reconnaissance des émotions, nous nous sommes, dans un premier temps, intéressés à l’état de l’art. L’émotion est un phénomène très personnel qui dépend du vécu de l’observateur. La tâche de mise en place d’un système de reconnaissance des émotions est alors d’autant plus complexe que l’émotion ne dépend pas d’une seule caractéristique de l’image. Elle peut être liée à la texture comme l’ont montré Lucassen et al. [Lucassen 10] ou à la nature de l’image. Dans les travaux de Machajdik et Hanbury [Machajdik 10], les couleurs sont très dé- terminantes pour la reconnaissance des émotions des images abstraites. De plus, on rencontre plusieurs problèmes dans la littérature du domaine. Le premier concerne le manque d’harmonisation du choix du modèle émotionnel. La modélisation discrète, largement utilisée est relative aux expressions faciales rendant parfois l’évaluation des images fastidieuse. D’un autre côté, elle est plus accessible à un grand nombre de personnes. Chaque auteur travaille donc sur le modèle qui lui convient en fonction de ses aspirations. Le second problème est l’absence de base de tests universelle même si IAPS fait figure de compromis pour évaluer les performances de son système. Nous avons donc proposé dans un premier temps, un ensemble de critères pour décrire les bases d’images qui permet également de comparer ces dernières et de faciliter le choix. Certaines bases de la littérature (IAPS entre autres) malgré leur évaluation consé- quente, présentent des contraintes d’utilisation très fortes (clauses de confidentialité rendant impossible l’organisation de nouvelles évaluations subjectives). Nous avons alors construit une nouvelle base d’images SENSE qui a été largement évaluée : plus de 60 annotations par images. Cette base ainsi que IAPS nous ont servi de vérité terrain pour évaluer notre approche. Nous avons voulu analyser l’apport de la saillance visuelle pour la reconnaissance de l’impact émotionnel. Ainsi nous avons fait évaluer des régions d’intérêt segmentées à partir de la saillance visuelle. Cette étude sur notre base nous a permis de conclure que cette segmentation améliore les évaluations à condition que les régions ne soient pas trop petites. Que ce soit avec les images ou avec les régions d’intérêt segmentées à partir de la saillance visuelle, nos résultats de classification à partir d’outils de recherche d’images par le contenu (BoVW, VLAD) sont très prometteurs. Comparés la littérature, sur IAPS nous nous situons plutôt dans la moyenne haute. Ceci témoigne alors que la méthode utilisée n’est pas inappropriée. L’architecture d’un système de recherche d’images par le contenu peut donc très bien être utilisée pour la reconnaissance des émotions. Les descripteurs locaux et globaux se complètent 129Conclusion Partie 2 parfaitement. La signature visuelle BoVW est suffisante mais VLAD semble plus adaptée pour les descripteurs locaux. 130Conclusion générale et perspectives Conclusion Dans cette conclusion, nous reviendrons sur les différents apports de nos travaux. Les résultats que nous avons présentés se basent sur des outils traditionnellement utilisés en recherche d’images par le contenu qui ont été aussi évalués tout au long de ce manuscrit : – Descripteurs de caractéristiques locales et globales ; – Dictionnaire visuel ; – Signatures visuelles BoVW et VLAD. Nous avons proposé un algorithme de construction de dictionnaire visuel à partir d’une sélection aléatoire de mots visuels couplée à un processus itératif. Cette solution se montre tout aussi efficace couplée à la signature visuelle BoVW pour des tailles de vocabulaire très petites (≤ 256) par rapport à celles de la littérature avec K-Means (souvent ≥ 10000). Dans nos travaux le descripteur CMI qui n’est pas très plébiscité dans la littérature égale les résultats de SIFT sur UKB. Tout au long de ce manuscrit, l’apport de la saillance a été évalué à différentes étapes du processus depuis la détection des caractéristiques locales jusqu’à l’évaluation des images pour la reconnaissance des émotions. Concernant la détection des caractéristiques locales, nous avons remarqué que très peu de détecteurs, parmi les quatre les plus utilisés dans la littérature que nous avons évalués, produisaient des points saillants. Ces premiers résultats nous indiquent que l’intégration de la saillance visuelle n’est pas implicite aux détecteurs de caracté- ristiques locales mais doit être additionnelle à cette étape. Le détecteur de Harris est celui qui produit le plus de points clés saillants sur les quatre bases d’images étudiées 13. Ces résultats ne remettent pas du tout en cause ceux sur la performance du détecteur Harris-Laplace [Zhang 07]. D’ailleurs, malgré les résultats du détecteur Harris-Laplace, les points clés les plus saillants sont très importants pour la recherche des images. En supprimant 20% des caractéristiques locales les plus saillantes, on perd 25% en taux de bonnes réponses sur la base UKB alors que les résultats sont quasiment identiques quand on supprime 20% des caractéristiques les 13. Pour rappel, 2 de ces bases sont utilisées en recherche d’images par le contenu et les 2 autres en évaluation de la saillance visuelle 131Conclusion générale et perspectives moins saillantes. Ces premiers résultats sur la saillance et le filtrage des points clés en recherche d’image par le contenu montrent tout l’intérêt d’utiliser cette information. Ils rejoignent également les résultats de Zdziarski et al. [Zdziarski 12] qui ont filtré les SURF en fonction de la saillance visuelle. La saillance visuelle a aussi montré un intérêt dans les travaux sur la reconnaissance des émotions. Pour cette tâche "haut niveau", nous avons proposé une nouvelle base d’images SENSE, largement annotée de façon très hétérogène. La saillance visuelle nous a permis d’améliorer l’évaluation de notre base d’images en réduisant l’interprétation sémantique. Nos résultats montrent qu’elle est utile à condition que la taille de la région observée ne soit pas trop petite. Ceci implique que l’objet/la scène doit être reconnaissable. Les résultats de classification des régions d’intérêt déduites de la saillance visuelle des images sont équivalents, voire meilleurs en fonction des descripteurs et des classes d’émotions, aux résultats obtenus en utilisant des images non segmentées. Cela justifie alors de la pertinence de cette information pour la reconnaissance de l’impact émotionnel notamment pour les images négatives avec les descripteurs SIFT et OpponentSIFT. Le gain en taux de classification d’environ 6% en témoigne. Plus généralement, les descripteurs que nous avons choisis (CM, CMI, Couleurs, CSIFT, GIST, SIFT, OpSIFT, WA4 et WA5) se sont montrés complémentaires pour la reconnaissance de l’impact des émotions aussi bien sur la base SENSE que sur IAPS. Si on devait en désigner comme étant le plus adapté ou le plus polyvalent, nous choisirons SIFT et/ou une de ses extensions couleur. Perspectives Nous avons étudié la saillance des détecteurs de caractéristiques locales et en avons déduit qu’ils n’incluent pas implicitement une notion de saillance visuelle pertinente. Ce résultat est d’autant plus logique qu’il est lié à leur construction. Nous avons prouvé, pour le descripteur de Harris-Laplace, que les caractéristiques locales non saillantes avaient très peu d’importance dans le résultat final. Une façon inté- ressante d’exploiter l’attention visuelle serait donc de remplacer les caractéristiques les moins saillantes par des pixels beaucoup plus saillants choisis de façon adéquate. Cette perspective a été entamée et de bons résultats ont été obtenus en remplaçant une partie des points clés les moins saillants par les caractéristiques les plus saillantes issues de la sélection "dense". Une idée serait de pousser la réflexion en les rempla- çant par les pixels les plus saillants de l’image, tout simplement. L’étude devrait être menée sur tous les détecteurs et les descripteurs afin de généraliser l’impact de la saillance sur UKB. Nous avons montré que Harris-Laplace ne détectait pas beaucoup de caractéristiques locales. On pourrait alors ajouter des points clés saillants en définissant un certain pourcentage de caractéristiques à considérer par image. Nous avons montré que la saillance visuelle peut être très utile aussi bien pour la recherche d’images par le contenu que pour la reconnaissance de l’impact émotionnel des images. Dans nos travaux nous avons fait le choix de modèles de saillance "Bottom-Up". La première raison est le nombre réduit de modèles "Top-Down" disponibles. Néanmoins une suite logique à nos travaux, notamment dans le cadre de la reconnaissance des émotions, serait d’étudier l’impact de l’utilisation d’un modèle 132Conclusion générale et perspectives "Top-Down". La segmentation en régions d’intérêt saillantes que nous avons utilisée se contente du rectangle englobant l’ensemble des zones à forte attention visuelle. Nous proposons en perspective à ces travaux de considérer les différentes régions saillantes indépendamment et de leur associer une émotion. L’émotion finale de l’image serait donc le résultat d’une combinaison de celle de chacune des régions. On reprendrait ainsi l’idée de Solli et al. [Solli 09] pour l’harmonie d’une image multi-colorée qui dépend de la combinaison entre les combinaisons de couleurs non harmonieuses et harmonieuses. La méthode de fusion pourrait être trouvée à partir d’évaluations subjectives pour trouver la pondération correcte entre les "patchs" négatifs et positifs. Pour finir on pourrait également étudier l’apport de chaque descripteur au moment de la fusion. Peut être qu’en fonction de la base et de la classe d’émotions il faudrait pondérer différemment les descripteurs ou n’en choisir qu’un certain nombre. 133Conclusion générale et perspectives 134AnnexesAnnexe A Calcul des CMI Le descripteur CMI se calcule à partir des moments couleur généralisés M d’ordre p+q et de degré a+b+c, notés Mabc pq . S02 = M2 00M0 00 (M1 00) 2 D02 = M11 00 M00 00 M10 00 M01 00 S12 = M2 10M0 01M1 01+M1 10M2 01M0 00+M0 10M1 01M2 00−M2 10M1 01M0 00−M1 10M0 01M2 00−M0 10M2 01M1 00 M2 00M1 00M0 00 D11 = M10 10 M01 01 M00 00 +M01 10 M00 01 M10 00 +M00 10M10 01 M01 00 −M10 10 M00 01 M01 00 −M01 10M10 01 M00 00 −M00 10 M01 01 M10 00 M10 00 M01 00M00 00 D1 12 = M11 10 M00 01 M10 00 +M10 10 M11 01 M00 00 +M00 10M10 01 M11 00 −M11 10 M10 01 M00 00 −M10 10M00 01 M11 00 −M00 10 M11 01 M10 00 M11 00 M10 00M00 00 D2 12 = M11 10 M00 01 M01 00 +M01 10 M11 01 M00 00 +M00 10M01 01 M11 00 −M11 10 M01 01 M00 00 −M01 10M00 01 M11 00 −M00 10 M11 01M0100 M11 00 M01 00M00 00 D3 12 = M02 10 M00 01 M10 00 +M10 10 M02 01 M00 00 +M00 10M10 01 M02 00 −M02 10 M10 01 M00 00 −M10 10M00 01 M02 00 −M00 10 M02 01 M10 00 M02 00 M10 00M00 00 D4 12 = M20 10 M01 01 M00 00 +M01 10 M00 01 M20 00 +M00 10M20 01 M01 00 −M20 10 M00 01 M01 00 −M01 10M20 01 M00 00 −M00 10 M01 01 M20 00 M20 00 M01 00M00 00 Dans ces différentes équations : – Mi pq vaut successivement Mi00 pq , M0i0 pq , M00i pq ; – Mij pq vaut successivement Mij0 pq , Mi0j pq , M0ij pq . 137Annexe A. Calcul des CMI 138Annexe B Couleurs utilisées pour l’étude des émotions de couleurs Dans le Tableau B.1, nous avons répertorié les différentes couleurs évaluées au cours des évaluations de Kaya et al. [Kaya 04] et dans le Tableau B.2 celles évaluées au cours des expérimentations de Ou et al. [Ou 04a] Tableau B.1: Différentes couleurs évaluées au cours des expérimentations de Kaya et al. [Kaya 04]. Couleurs Codage Munsell Rouge 5R 5/14 Jaune 7.5Y 9/10 Vert 2.5G 5/10 Bleu 10B 6/10 Violet 5P 5/10 Orange 5YR 7/12 Vert-Jaune 2.5GY 8/10 Bleu-Vert 5BG 7/8 Violet-Bleu 7.5PB 5/12 Rouge-Violet 10RP 4/12 Blanc N/9 Noir N/1 Gris N/5 Ces couleurs proviennent du système de Munsell [Munsell 05]. Dans ce système colorimétrique, les couleurs sont décrites dans un espace tridimensionnel (Teinte, Valeur, Chromaticité) comme l’illustre la Figure B.1. Dans ce système de couleur : – La teinte représente une nuance de couleur. Le système est basé sur les 5 teintes suivantes : R pour le Rouge, Y pour le Jaune, G pour le Vert, B pour le Bleu et P pour le Violet. À ces 5 teintes de base se rajoutent des teintes intermédiaires, 139Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs Figure B.1: Système colorimétrique de Munsell. par exemple, YR (Jaune-Rouge) pour la couleur orange. Chacune des couleurs est donnée en 10 nuances. Une teinte est définie par un chiffre s’étalant de 0 à 360˚. – La valeur représente la luminosité/clarté perçue. Elle s’échelonne de 0 pour le noir à 10 pour le blanc. – La chromaticité représente la pureté d’une couleur basée sur la perception visuelle. Elle commence à 0 pour le gris et n’a pas de limite supérieure. 140Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs Tableau B.2: Différentes couleurs évaluées au cours des expérimentations de Ou et al. [Ou 04a]. Notation NCS des couleurs L ∗ a ∗ b ∗ C ∗ h ∗ R-1080 45.9 61.7 29.1 68.2 2 Y-61070 84.8 6.3 82.0 82.3 86 G-2060 61.4 -49.7 17.8 52.8 160 R90B-3050 49.6 -8.9 -33.2 34.4 255 R70B-3060 38.0 13.8 -42.0 44.2 288 Y60R-5040 42.2 25.9 26.5 37.0 46 G80Y-4040 58.3 -3.2 40.3 40.4 94 B50G-5040 39.3 -28.2 -5.8 28.8 192 R70B-5030 41.4 5.0 -24.3 24.8 282 R-1020 84.7 17.1 5.6 18.0 18 Y-1030 89.0 1.6 39.4 39.4 88 B30G-1040 78.4 -26.7 -10.9 28.8 202 R60B-1040 74.0 11.3 -23.7 26.3 296 G50Y-4020 64.2 -8.2 19.0 20.7 113 B50G-5030 47.1 -22.0 -5.7 22.7 195 R50B-5020 49.8 10.8 -11.9 16.1 312 N-9000 15.7 0.3 -1.5 1.6 282 N-7000 43.2 0.3 0.2 0.4 37 N-3500 72.1 0.4 0.6 0.7 58 B-0502 97.8 -2.1 0.4 2.1 168 C ∗ et h∗ sont obtenus à partir des relations de l’Equation (3.4). 141Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs 142Annexe C Influence du genre sur l’évaluation de l’impact émotionnel des images de la base SENSE Introduction L’étude des différences cognitives et comportementales entre genre est un domaine très actif. L’objectif commun aux différents travaux est de trouver pourquoi les hommes et les femmes ne réagissent pas de la même façon dans certaines conditions et de modéliser ces différences. La majorité des travaux de recherche sur les différences induites par le genre peuvent être résumée en deux théories : – Les théories sociales : les différences entre hommes et femmes sont socialement construites et influencées par des facteurs tels que les rôles stéréotypes sexistes ([Fischer 04]). – Les théories biologiques : Les différences entre genre seraient dues aux diffé- rences biologiques ([Hofer 06]). On peut également retrouver dans la littérature des approches qui soutiennent la combinaison de ce ces deux théories ([Halpern 11]). Dans ces travaux, nous ne nous sommes pas intéressés à la raison de ces différences. Nous avons essayé de trouver les situations dans lesquelles les hommes et les femmes n’étaient pas d’accord lors de nos évaluations. Ces travaux s’inscrivent notamment dans l’esprit de vérifier les conclusions faites par Bradley et al [Bradley 01] lors de l’évaluation d’images. Au cours de leurs expériences, les femmes étaient plus réactives aux matériaux désagréables. Aussi, comparativement aux hommes, elles ont évalué "légèrement agréables" des images notés "neutres" par ces derniers. Nous tenons à signaler que les images utilisées par Bradley et al. sont beaucoup plus sémantiques que celles de notre base : elles proviennent de IAPS. 143Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel des images de la base SENSE Résultats de l’analyse des différences entre genre au cours de nos expérimentations subjectives Les résultats que nous présentons ici sont issus de l’analyse des expérimentations SENSE1. Pour rappel, les observateurs devaient indiquer la nature des émotions : "Négative", "Neutre" ou "Positive" et la puissance qui variait de "Faible" à "Fort" pour chaque image. 1741 participants dont 893 femmes soit 51.29% des sujets, ont effectué cette expérimentation à travers le monde (28 pays différents) avec une grande majorité vivant en France. Le point le plus intéressant pour cette analyse concerne la répartition quasi-similaire des sujets en fonction de leur genre (51.29% de femmes et 48,71% d’hommes). Tableau C.1: Nombre d’images dans chaque classe d’émotions en fonction du genre. Nature de l’émotion Femmes Hommes Négative 20% 14.57% Neutre 34.43% 43.43% Positive 43.43% 39.71% Non catégorisées 1.14% 2.29% Le Tableau C.1 résume la classification de notre base d’images en fonction du genre. La première conclusion à cette classification est que globalement, les femmes trouvent notre base d’images positive alors que les hommes la trouvent neutre. Elles ont évalué "Négative" beaucoup d’images que les hommes ont indiqué "Neutre". On pourrait alors conclure que les femmes attribueraient plus de "scores émotifs" ("Positive" et "Négative") que les hommes. Ces premières conclusions sont cohérentes avec celles de la littérature, par example ceux de [Barrett 98, Fischer 04]. Nous avons ensuite analysé les différences de jugements entre les hommes et les femmes. Ces résultats sont représentés sur la Figure C.1. Sur cette Figure, les conclusions précédentes sont confirmées. La grande partie des désaccords d’évaluation concerne les images classées "Négative" et "Positive" par les femmes qui sont classées "Neutre" par les hommes. Ceci peut s’expliquer par la complexité comme nous l’avons déjà évoqué des émotions neutres. Nous n’avons noté dans nos études aucune contradiction "PositiveFemmes_NegativeHommes" même si quelques cas de la configuration inverse existent. On pourrait alors déduire que les images classées "Positive" sur notre base par les femmes sont évaluées "Positive" ou "Neutre" par les hommes. Pour conclure cette étude, nous avons étudié les couleurs moyennes des images source des désaccords. Ces dernières sont résumées dans le Tableau C.2. On constate que les cas NegF_PosH et NegF_NeutH montrent la sensibilité des hommes aux couleurs froides et sombres. Ce premier résultat rejoint les conclusions de Odom et al. [Odom 00]. Ils ont également conclu que les hommes étaient beaucoup plus susceptibles d’avoir des réactions positives face aux couleurs sombres que 144Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel des images de la base SENSE Figure C.1: Répartition des désaccords entre hommes et femmes lors de l’évaluation de l’impact émotionnel sur notre base. Les annotations sont de la forme "jugementFemmes_jugementHommes". Ainsi PosF_NeutH correspond aux images jugées "Positive" par les femmes et "Neutre" par les hommes. Tableau C.2: Différentes couleurs moyennes au sein des désaccords entre genre relevés sur notre base. Type de désaccord Patchs représentant les couleurs moyennes NegF_PosH NeutF_NegH NeutF_PosH NegF_NeutH PosF_NeutH les femmes. Le cas NegF_NeutH est assez particulier. En effet, les femmes ont potentiellement interprété la sémantique des images contenant des couleurs sombres et froides. Dans le cas de nos études, ces images contiennent des grilles métalliques, des reptiles ou encore le mauvais temps. Conclusions L’évaluation de l’impact émotionnel des images peut être délicate si on n’adopte pas la bonne stratégie. Dans notre cas, au regard du contenu faiblement sémantique de notre base d’images, nous avons choisi une façon simple d’annoter les images. Cette dernière comprend deux paramètres : la nature de l’émotion et la puissance de l’émotion. L’étude des différences d’évaluation en fonction du genre s’est essentiellement faite sur la nature. Les résultats que nous obtenons sont cohérents avec ceux de la littérature. Les prin- 145Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel des images de la base SENSE cipaux désaccords concernent les images positives et négatives. Les femmes semblent plus sensibles aux couleurs claires et les hommes jugent de façon "moins négative" les images contenant des couleurs foncées. 146Annexe D Résultats des évaluations EEG sur quelques images de SENSE Les travaux que nous présentons ici ont été réalisés en 2013 en collaboration avec le département d’Informatique de l’Université de Milan (Dipartimento di Informatica, Università degli stidi di Milano) avec Enrico Calore alors doctorant et Daniele Marini, Professeur. Introduction Nous avons évalué les réponses EEG sur 12 images de notre base. Le but de ces évaluations étaient dans un premier temps d’étudier une possible relation entre les réponses SSVEP et ensuite la corrélation entre ces réponses et un descripteur basniveau des images. Dans cette étude préliminaire nous avons choisi la "luminance". Les évaluations se sont déroulées en trois sessions et ont été présentées dans un ordre pseudo-aléatoire. Durant une session chaque image était affichée pendant 8 secondes avec un "scintillement" à 10Hz. Ensuite une image toute noire est affichée pendant 5 secondes. L’évaluation reprend jusqu’à ce que les 12 images aient été vues. Seulement 4 participants ont effectué volontairement nos évaluations. Le signal EEG a été enregistré à l’aide de 4 électrodes positionnées sur la région occipitale en Pz, POz, PO3 et PO4 (cf. Figure 4.10) suivant le système 10-20, proposé par Sharbrough et al. [Sharbrough 91]. Étude de différentes corrélations Nous avons étudié la corrélation entre l’intensité de la réponse SSVEP des 4 participants à nos évaluations. Cette réponse SSVEP a été calculée avec une technique relativement nouvelle de l’état de l’art [Friman 07, Garcia-Molina 11]. Nous avons utilisé la corrélation de Pearson pour l’étude de la corrélation potentielle entre les différentes réponses. 1 1. Nous avons utilisé le logiciel PSPPIRE https://www.gnu.org/software/pspp/tour.html pour ce faire. 147Annexe D. Résultats des évaluations EEG sur quelques images de SENSE Dans un premier temps, nous avons évalué la corrélation entre les réponses SSVEP calculées pour les images des différents sessions de tests et les observateurs pour être sûre qu’il y existe une modulation significative de la réponse par le contenu des images. Nous avons considéré deux configurations : 1. Nous avons calculée la réponse SSVEP pour la durée totale d’affichage d’une image en utilisant l’algorithme de l’"Énergie Minimale" [Friman 07]. 2. Nous avons calculé avec le même algorithme la réponse SSVEP pour chaque seconde d’affichage et en avons fait une moyenne pour la durée totale de l’af- fichage. Tableau D.1: Corrélation entre les différentes sessions de tests dans la première configuration. Sessions S1_Moy_8s S2_Moy_8s S3_Moy_8s S1_Moy_8s Coef. Pearson 1 0.56 0.49 Importance - 0 0 Population 48 48 48 S2_Moy_8s Coef. Pearson 0.56 1 0.40 Importance 0 - 0 Population 48 48 48 S3_Moy_8s Coef. Pearson 0.49 0.40 1 Importance 0 0 - Population 48 48 48 Tableau D.2: Corrélation entre les différentes sessions de tests dans la seconde configuration. Sessions S1_Moy_1s S2_Moy_1s S3_Moy_1s S1_Moy_1s Coef. Pearson 1 0.62 0.61 Importance - 0 0 Population 48 48 48 S2_Moy_1s Coef. Pearson 0.62 1 0.68 Importance 0 - 0 Population 48 48 48 S3_Moy_1s Coef. Pearson 0.61 0.68 1 Importance 0 0 - Population 48 48 48 Dans le Tableau D.1, nous avons représenté la corrélation entre les différentes sessions dans la configuration 1 et dans le Tableau D.2 celle de la configuration 2. Dans ces deux tableaux, la population (qui correspond au nombre de réponses SSVEP considéré) est égale à 48 puisque nous avons étudié les réponses SSVEP pour les 4 148Annexe D. Résultats des évaluations EEG sur quelques images de SENSE participants (12 images/participant ⇒ 12 réponses/participant). Au regard des différents résultats de ces deux tableaux, l’hypothèse nulle de corrélation dans les deux configurations peut être rejetée. Une corrélation forte est à noter dans le seconde configuration entre les différentes sessions. Ceci confirme que les réponses SSVEP calculées sont bien corrélées au contenu des images. Tableau D.3: Corrélation entre la réponse SSVEP et la luminance. Sessions Luminance S1_Moy_1s Coef. Pearson 0.14 Importance 0.33 Population 48 S2_Moy_1s Coef. Pearson 0.12 Importance 0.43 Population 48 S3_Moy_1s Coef. Pearson 0.04 Importance 0.80 Population 48 Moyenne_1s Coef. Pearson 0.12 Importance 0.43 Population 48 S1_Moy_8s Coef. Pearson -0.24 Importance 0.10 Population 48 S2_Moy_8s Coef. Pearson -0.33 Importance 0.02 Population 48 S3_Moy_8s Coef. Pearson -0.07 Importance 0.63 Population 48 Moyenne_8s Coef. Pearson -0.27 Importance 0.06 Population 48 Dans le Tableau D.3, nous avons résumé les résultats de l’étude de corrélation entre les réponses SSVEP et la teinte des images. Cette dernière information bas-niveau peut être importante dans l’impact émotionnel d’une image. Nous avons ensuite gardé la valeur moyenne pour chaque image. En analysant les différents coefficients de Pearson, nous ne pouvons pas rejeter l’hypothèse nulle dans les deux configurations. Une exception néanmoins est faite pour la seconde série de test et ceci pour une réponse SSVEP calculée sur la durée totale d’observation. Ces résultats sont probablement dûs à la nature de nos images. En effet, comparées à celles d’IAPS, 149Annexe D. Résultats des évaluations EEG sur quelques images de SENSE nos images ne provoquent pas d’émotions fortes. Conclusions L’étude des réponses SSVEP associées aux différentes images nous permet de confirmer qu’il existe une corrélation forte entre les images de la base SENSE évaluées et les réponses SSVEP des différents observateurs. Par contre nous ne pouvons pas identifier à ce stade de l’étude préliminaire que nous avons conduite, quel descripteur bas-niveau module la réponse SSVEP. Une étude statistique signifiante doit être menée conjointement à d’autres évaluations subjectives plus importantes. 150Annexe E Configuration des ensembles d’apprentissage et de test des bases SENSE et IAPS Dans cette annexe nous donnons la constitution complète de nos ensembles d’apprentissage et de test pour les bases SENSE et IAPS. Le Tableau E.1 donne le nombre d’images que nous avons utilisé pour chacune des deux bases. Tableau E.1: Nombre d’images dans les ensembles d’apprentissage et de test Négative Neutre Positive Total Ensemble d’apprentissage IAPS 248 84 228 560 SENSE 53 53 53 159 Ensemble de test IAPS 61 20 58 139 SENSE 10 82 96 188 Le détail des images (numéro des images utilisées) est donné ci-dessous. Configuration des images de la base IAPS Ensemble d’apprentissage Images négatives 1019, 1050, 1051, 1052, 1080, 1090, 1110, 1111, 1114, 1120, 1201, 1202, 1271, 1274, 1275, 1280, 1303, 1304, 1525, 1930, 2095, 2120, 2141, 2205, 2278, 2301, 2455, 2456, 2490, 2520, 2590, 2683, 2691, 2692, 2700, 2703, 2715, 2717, 2722, 2730, 2751, 2753, 2799, 2800, 2900, 2981, 3000, 3001, 3015, 3016, 3017, 3019, 3051, 3053, 3059, 3060, 3062, 3063, 3064, 3068, 3071, 3080, 3100, 3101, 3103, 3110, 3120, 3130, 3140, 3150, 3160, 3168, 3180, 3181, 3185, 3191, 3212, 3213, 3215, 3216, 3225, 3230, 3261, 3266, 3301, 3350, 3400, 3500, 3550, 4621, 5970, 5971, 6021, 6022, 6190, 6200, 6211, 6212, 6213, 6220, 6231, 6241, 6242, 6243, 6250, 6260, 6263, 6300, 6312, 6313, 6315, 6350, 6370, 6410, 6415, 6510, 6530, 6540, 6550, 6555, 6561, 6562, 6563, 6570, 6821, 6825, 6830, 6831, 6836, 6838, 7135, 7136, 7361, 7380, 8230, 8485, 151Annexe E. Configuration des ensembles d’apprentissage et de test des bases SENSE et IAPS 9001, 9002, 9006, 9007, 9010, 9031, 9040, 9041, 9043, 9046, 9050, 9075, 9102, 9120, 9140, 9145, 9163, 9180, 9181, 9183, 9185, 9186, 9187, 9220, 9252, 9253, 9254, 9265, 9290, 9291, 9295, 9300, 9302, 9320, 9321, 9322, 9326, 9330, 9331, 9332, 9341, 9342, 9373, 9395, 9405, 9409, 9410, 9412, 9414, 9415, 9417, 9419, 9421, 9423, 9424, 9425, 9427, 9428, 9429, 9430, 9433, 9435, 9440, 9452, 9471, 9480, 9490, 9491, 9500, 9520, 9530, 9560, 9570, 9571, 9584, 9590, 9599, 9600, 9610, 9611, 9621, 9622, 9623, 9630, 9810, 9830, 9831, 9832, 9901, 9902, 9903, 9904, 9908, 9909, 9910, 9911, 9920, 9921, 9922, 9925, 9930, 9940, 9941, 2055.1 , 2352.2 , 2375.1 , 2900.1 , 3005.1 , 4664.2 , 6250.1 , 6570.1 , 9635.1 Images neutres 1810, 2038, 2190, 2191, 2206, 2210, 2214, 2215, 2221, 2230, 2270, 2271, 2372, 2381, 2383, 2393, 2410, 2411, 2440, 2480, 2495, 2514, 2516, 2518, 2580, 2595, 2749, 2752, 2830, 2850, 2870, 3210, 5120, 5395, 5455, 5500, 5740, 6000, 6150, 7000, 7003, 7004, 7009, 7010, 7030, 7034, 7036, 7040, 7050, 7056, 7080, 7090, 7110, 7130, 7140, 7150, 7161, 7170, 7175, 7179, 7187, 7190, 7205, 7207, 7224, 7233, 7234, 7235, 7255, 7490, 7495, 7496, 7510, 7550, 7560, 7590, 7640, 7700, 7705, 7950, 8232, 9070, 9210, 9700 Images positives 1340, 1410, 1440, 1441, 1463, 1500, 1510, 1540, 1600, 1601, 1603, 1604, 1620, 1630, 1670, 1710, 1721, 1722, 1731, 1740, 1811, 1812, 1850, 1910, 1999, 2030, 2035, 2040, 2050, 2057, 2058, 2060, 2071, 2075, 2080, 2091, 2151, 2152, 2153, 2154, 2156, 2158, 2160, 2165, 2208, 2209, 2216, 2222, 2250, 2260, 2274, 2299, 2303, 2304, 2306, 2310, 2314, 2331, 2332, 2339, 2341, 2344, 2345, 2346, 2352, 2360, 2362, 2370, 2387, 2388, 2391, 2395, 2501, 2510, 2530, 2540, 2560, 2598, 2650, 2655, 2791, 4002, 4003, 4180, 4220, 4250, 4290, 4310, 4490, 4500, 4520, 4550, 4599, 4601, 4603, 4607, 4609, 4610, 4611, 4612, 4616, 4617, 4622, 4623, 4626, 4628, 4640, 4641, 4645, 4650, 4651, 4652, 4656, 4658, 4659, 4660, 4666, 4670, 4676, 4677, 4681, 4687, 4689, 4690, 4700, 5000, 5001, 5010, 5199, 5200, 5201, 5202, 5215, 5220, 5260, 5270, 5450, 5460, 5470, 5480, 5594, 5600, 5611, 5621, 5626, 5629, 5631, 5660, 5725, 5760, 5764, 5779, 5781, 5811, 5814, 5820, 5829, 5830, 5831, 5833, 5870, 5890, 5891, 5910, 5994, 7200, 7220, 7230, 7270, 7280, 7282, 7284, 7289, 7325, 7330, 7350, 7390, 7400, 7405, 7410, 7460, 7470, 7480, 7481, 7501, 7502, 7508, 7530, 7570, 7580, 8021, 8030, 8034, 8041, 8080, 8090, 8120, 8161, 8162, 8163, 8180, 8185, 8186, 8190, 8200, 8208, 8210, 8260, 8300, 8320, 8330, 8340, 8370, 8371, 8380, 8400, 8461, 8465, 8470, 8490, 8496, 8497, 8499, 8500, 8502, 8503, 8510, 8531 Ensemble de test Images négatives 1070, 1113, 1220, 1300, 2053, 2276, 2457, 2688, 2710, 2750, 2811, 3010, 3030, 3061, 3069, 3102, 3131, 3170, 3195, 3220, 3300, 3530, 6020, 6210, 6230, 6244, 6311, 6360, 6520, 6560, 6571, 6834, 7359, 9000, 9008, 9042, 9090, 9160, 9184, 9250, 9280, 9301, 9325, 9340, 9400, 9413, 9420, 9426, 9432, 9470, 9495, 9561, 9592, 9620, 9800, 9900, 9905, 9912, 9927, 2345.1 , 3550.1 , Images neutres 2200, 2220, 2280, 2394, 2484, 2570, 2810, 4561, 5731, 7002, 7020, 7041, 7100, 7160, 7180, 7211, 7247, 7500, 7595, 8160 152Annexe E. Configuration des ensembles d’apprentissage et de test des bases SENSE et IAPS Images positives 1460, 1590, 1610, 1720, 1750, 1920, 2045, 2070, 2150, 2155, 2170, 2224, 2300, 2311, 2340, 2347, 2373, 2398, 2550, 2660, 4210, 4470, 4597, 4608, 4614, 4624, 4643, 4653, 4664, 4680, 4695, 5030, 5210, 5300, 5551, 5623, 5700, 5780, 5825, 5836, 5982, 7260, 7286, 7352, 7430, 7492, 7545, 8031, 8116, 8170, 8193, 8280, 8350, 8420, 8492, 8501, 8540, 2352.1 Configuration des images de la base SENSE Ensemble d’apprentissage Images négatives 320, 305, 338, 341, 319, 92, 171, 340, 313, 87, 211, 335, 93, 332, 330, 314, 307, 225, 334, 210, 141, 155, 327, 322, 333, 226, 216, 24, 172, 151, 90, 318, 154, 149, 107, 339, 323, 204, 170, 329, 303, 18, 100, 150, 308, 182, 189, 302, 106, 301, 57, 300, 348 Images neutres 242, 1, 227, 9, 5, 290, 19, 67, 239, 183, 175, 13, 291, 39, 312, 316, 224, 194, 21, 219, 77, 326, 304, 234, 120, 6, 310, 236, 17, 38, 243, 135, 315, 309, 233, 223, 231, 222, 167, 75, 64, 40, 252, 221, 198, 180, 11, 108, 317, 185, 176, 168, 144 Images positives 260, 343, 266, 76, 47, 164, 45, 2, 267, 196, 82, 337, 286, 264, 117, 29, 41, 342, 283, 113, 80, 125, 298, 78, 278, 272, 115, 10, 34, 345, 205, 131, 56, 279, 265, 159, 79, 287, 240, 165, 122, 346, 288, 281, 273, 53, 277, 129, 95, 81, 187, 297, 193 Ensemble de test Images négatives 35, 52, 68, 96, 103, 116, 137, 220, 311, 328 Images neutres 3, 7, 8, 12, 14, 16, 22, 27, 30, 33, 36, 42, 49, 59, 62, 63, 66, 84, 88, 89, 91, 98, 99, 104, 105, 109, 111, 112, 114, 118, 119, 121, 130, 140, 143, 145, 147, 148, 152, 153, 157, 158, 161, 169, 174, 177, 178, 184, 191, 192, 195, 200, 201, 202, 203, 209, 212, 214, 215, 217, 218, 228, 229, 232, 235, 237, 247, 250, 257, 259, 263, 268, 269, 275, 294, 306, 321, 324, 325, 331, 336, 347 Images positives 4, 15, 20, 23, 25, 26, 28, 31, 32, 37, 43, 44, 46, 48, 50, 54, 55, 58, 60, 61, 65, 69, 70, 72, 73, 74, 83, 85, 86, 94, 97, 101, 102, 110, 123, 124, 126, 127, 128, 132, 133, 134, 136, 138, 139, 142, 146, 156, 160, 162, 163, 166, 179, 181, 186, 188, 190, 197, 199, 206, 207, 208, 213, 230, 238, 241, 244, 245, 246, 248, 249, 251, 253, 254, 255, 256, 258, 261, 262, 270, 271, 274, 276, 280, 282, 284, 285, 289, 292, 293, 295, 296, 299, 344, 349, 350 153Annexe E. Configuration des ensembles d’apprentissage et de test des bases SENSE et IAPS 154Références bibliographiquesRéférences bibliographiques [Abdel-Hakim 06] A. E. Abdel-Hakim & A. A. Farag. CSIFT : A SIFT Descriptor with Color Invariant Characteristics. In Proceedings of the IEEE Computer Society Conference on Computer Vision and Pattern Recognition), 2006. Pages 17 et 18 [Achanta 09] R. Achanta, S. Hemami, F. Estrada & S. Susstrunk. Frequency-tuned salient region detection. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pages 1597–1604, June 2009. Page 35 [Air ] http://svtdaybyday.blogspot.fr/2014_04_01_archive. html. Page 31 [Alahi 12] A. Alahi, R. Ortiz & P. Vandergheynst. FREAK : Fast Retina Keypoint. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pages 510–517, June 2012. Page 20 [Arya 98] S. Arya, D. M. Mount, N. S. Netanyahu, R. Silverman & A. Y. Wu. An Optimal Algorithm for Approximate Nearest Neighbor Searching Fixed Dimensions. Journal of ACM, vol. 45, no. 6, pages 891–923, 1998. Page 28 [Ballard 91] D. H. Ballard. Animate Vision. Artif. Intell., vol. 48, no. 1, pages 57–86, 1991. Page 32 [Bard 28] P. Bard. A diencephalic mechanism for the expression of rage with special reference to the sympathetic nervous system. American Journal of Physiology – Legacy Content, vol. 84, no. 3, pages 490–515, 1928. Page 76 [Barrett 98] L. F. Barrett, L. Robin, P. R. Pietromonaco & Kristen M. Eyssell. Are Women the "More Emotional" Sex ? Evidence From Emotional Experiences in Social Context. Cognition & Emotion, vol. 12, no. 4, pages 555–578, 1998. Page 144 [Bay 06] H. Bay, T. Tuytelaars & L. Van Gool. SURF : Speeded Up Robust Features. vol. 3951 of Lecture Notes in Computer Science, pages 404–417. Springer Berlin Heidelberg, 2006. Page 19 157Références bibliographiques [Beke 08] L. Beke, G. Kutas, Y. Kwak, G. Y. Sung, D. Park & P. Bodrogi. Color preference of aged observers compared to young observers. Color Research & Application, vol. 33, no. 5, pages 381–394, 2008. Page 81 [Beresniak 90] D. Beresniak. Abc des couleurs leurs incidences dans votre vie quotidienne. 1990. Pages 1 et 79 [Bian 09] P. Bian & L. Zhang. Biological Plausibility of Spectral Domain Approach for Spatiotemporal Visual Saliency. In Proceedings of the 15th International Conference on Advances in Neuro-information Processing, vol. 1 of ICONIP’08, pages 251–258. Springer-Verlag, 2009. Page 35 [Borji 11] A. Borji, D. Sihite & L. Itti. Computational Modeling of Top-down Visual Attention in Interactive Environments. In Proceedings of the British Machine Vision Conference, pages 1–12. BMVA Press, 2011. Page 34 [Borji 13a] A. Borji & L. Itti. State-of-the-Art in Visual Attention Modeling. IEEE Trans. Pattern Anal. Mach. Intell., vol. 35, no. 1, pages 185–207, 2013. Page 34 [Borji 13b] A. Borji, D. Sihite & L. Itti. Quantitative Analysis of Human-Model Agreement in Visual Saliency Modeling : A Comparative Study. IEEE Transactions on Image Processing, vol. 22, no. 1, pages 55–69, 2013. Pages 34, 37 et 66 [Boujut 12] H. Boujut. Mesure Sans Référence de la Qualité des Vidéos Haute Définition Diffusées avec des Pertes de Transmission. Thèse, Université Bordeaux I : École doctorale de Mathématiques et d’Informatique, Sept. 2012. Pages 29, 31, 33, 34, 35 et 37 [Bovik 90] A. C. Bovik, M. Clark & W. S. Geisler. Multichannel Texture Analysis Using Localized Spatial Filters. IEEE Trans. Pattern Anal. Mach. Intell., vol. 12, no. 1, pages 55–73, 1990. Page 88 [Boyatziz 93] C.J. Boyatziz & R. Varghese. Children’s Emotional Associations With Colors. The Journal of Genetic Psychology, vol. 155, pages 77–85, 1993. Pages 1 et 81 [Bradley 01] M. M. Bradley, M. Codispoti, D. Sabatinelli & P. J. Lang. Emotion and Motivation II : Sex Differences in Picture Processing. Emotion, vol. 1, no. 3, pages 300–319, 2001. Pages 81 et 143 [Burghouts 09] G. J. Burghouts & J. M. Geusebroek. Performance Evaluation of Local Colour Invariants. Computer Vision and Image Understanding, vol. 113, pages 48–62, 2009. Pages 17 et 18 [Busso 04] C. Busso, Z. Deng, S. Yildirim, M. Bulut, C. M. Lee, A. Kazemzadeh, S. Lee, U. Neumann & S. Narayanan. Analysis of 158Références bibliographiques Emotion Recognition Using Facial Expressions, Speech and Multimodal Information. In Proceedings of the 6th International Conference on Multimodal Interfaces, pages 205–211. ACM, 2004. Pages 2 et 86 [Calonder 10] M. Calonder, V. Lepetit, C. Strecha & P. Fua. BRIEF : Binary Robust Independent Elementary Features. vol. 6314 of Lecture Notes in Computer Science, pages 778–792. Springer Berlin Heidelberg, 2010. Page 20 [Cannon 27] W. B. Cannon. The James-Lange Theory of Emotions : A Critical Examination and an Alternative Theory. The American Journal of Psychology, vol. 39, no. 1/4, pages 106– 124, 1927. Page 76 [Cas ] http://www.biosemi.com/headcap.htm. Page 106 [Chi ] http://www.kartable.fr/premiere-s/svt/1034/cours/ le-cerveau,1S07065. Page 31 [Chikkerur 10] S. Chikkerur, T. Serre, C. Tan & T. Poggio. What and where : A Bayesian inference theory of attention. Vision Research, vol. 50, no. 22, pages 2233–2247, 2010. Page 34 [Cho 04] S. Cho. Emotional image and musical information retrieval with interactive genetic algorithm. Proceedings of the IEEE, vol. 92, no. 4, pages 702–711, 2004. Page 92 [Coppin 10] D. Coppin G.and Sander. Théories et concepts contemporains en psychologie de l’émotion, pages 25–56. Hermès Science publications-Lavoisier, 2010. Pages 75, 76 et 77 [Cor ] http://commons.wikimedia.org/wiki/File:Ventraldorsal_streams.svg. Page 32 [Davis 95] W. J. Davis, M. A. Rahman, Libby J. Smith, Ayesha Burns, L. Senecal, D. McArthur, J. A. Halpern, A. Perlmutter, W. Sickels & W. Wagner. Properties of human affect induced by static color slides (IAPS) : dimensional, categorical and electromyographic analysis. Biological Psychology, vol. 41, no. 3, pages 229–253, 1995. Page 86 [De Silva 97] L. C. De Silva, T. Miyasato & R. Nakatsu. Facial emotion recognition using multi-modal information. In Proceedings of International Conference on Information, Communications and Signal Processing, vol. 1, pages 397–401, Sept. 1997. Pages 2 et 86 [Delhumeau 13] J. Delhumeau, P. Gosselin, H. Jégou & P. Pérez. Revisiting the VLAD Image Representation. In Proceedings of the 21st ACM International Conference on Multimedia, pages 653– 656. ACM, 2013. Page 61 [Demanet 09] L. Demanet L.and Ying. Wave atoms and time upscaling of wave equations. Numerische Mathematik, vol. 113, pages 1–71, 2009. Page 109 159Références bibliographiques [Dieny 08] B. Dieny & U. Ebels. Stockage de l’information : les acquis et les promesses du nanomagnétisme et de la spintronique. Clefs CEA, no. 56, pages 62–66, 2007-2008. Page 7 [Douze 09] M. Douze, H. Jégou, H. Sandhawalia & C. Amsaleg L.and Schmid. Evaluation of GIST Descriptors for Webscale Image Search. In Proceedings of the ACM International Conference on Image and Video Retrieval, pages 1–19. ACM, 2009. Pages 2 et 11 [Ekman 78] P. Ekman & W. V. Friesen. Facial action coding system : Manual, vol. 1-2. Consulting Psychologists Press, 1978. Page 87 [Ekman 92] P. Ekman. Facial expressions of emotions. Psychological science, vol. 3, no. 1, pages 34–38, 1992. Pages 2, 78 et 86 [Ele ] http://www.hindawi.com/journals/tswj/2013/618649/ fig2/. Page 106 [Everingham 07] M. Everingham, L. Van Gool, C. K. I. Williams, J. Winn & A. Zisserman. The PASCAL Visual Object Classes Challenge 2007 (VOC2007) Results, 2007. Pages 2 et 40 [Everingham 12] M. Everingham, L. Van Gool, C. K. I. Williams, J. Winn & A. Zisserman. The PASCAL Visual Object Classes Challenge 2012 (VOC2012)Results, 2012. Pages 2, 3, 18 et 40 [Fernandez-Maloigne 04] C. Fernandez-Maloigne, A. Trémeau & P. Bonton. Image numérique couleur : De l’acquisition au traitement. 2004. Page 107 [Fischer 04] A. H. Fischer, P. M. Rodriguez Mosquera, A.E. M. Van Vianen & A. S. R. Manstead. Gender and culture differences in emotion. Emotion, vol. 4, pages 87–94, 2004. Pages 143 et 144 [Friman 07] O. Friman, I. Volosyak & A. Graser. Multiple Channel Detection of Steady-State Visual Evoked Potentials for BrainComputer Interfaces. Biomedical Engineering, IEEE Transactions on, vol. 54, no. 4, pages 742–750, 2007. Pages 95, 147 et 148 [Förstner 94] W. Förstner. A framework for low level feature extraction. vol. 801 of Lecture Notes in Computer Science, pages 383– 394. Springer Berlin Heidelberg, 1994. Page 13 [Gao 08] K. Gao, S. Lin, Y. Zhang, S. Tang & H. Ren. Attention Model Based SIFT Keypoints Filtration for Image Retrieval. In Proceedings of the 7th IEEE/ACIS International Conference on Computer and Information Science, pages 191–196, May 2008. Page 38 [Garcia-Diaz 09] Antón Garcia-Diaz, Xosé. Fdez-Vidal, Xosé. Pardo & Raquel Dosil. Decorrelation and Distinctiveness Provide with 160Références bibliographiques Human-Like Saliency. In Advanced Concepts for Intelligent Vision Systems, vol. 5807 of Lecture Notes in Computer Science, pages 343–354. Springer Berlin Heidelberg, 2009. Page 35 [Garcia-Molina 11] G. Garcia-Molina & D. Zhu. Optimal spatial filtering for the steady state visual evoked potential : BCI application. In Proceedings of the 5th International IEEE/EMBS Conference on Neural Engineering, pages 156–160, 2011. Page 147 [Geusebroek 01] J. Geusebroek, R. van den Boomgaard, A. W. M. Smeulders & H. Geerts. Color Invariance. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 23, no. 12, 2001. Page 18 [Geusebroek 06] J. and Geusebroek. Compact Object Descriptors from Local Colour Invariant Histograms. In Proceedings of the British Machine Vision Conference, pages 1–10. BMVA Press, 2006. Page 88 [Goferman 12] S. Goferman, L. Zelnik-Manor & A. Tal. Context-Aware Saliency Detection. IEEE Trans. Pattern Anal. Mach. Intell., vol. 34, no. 10, pages 1915–1926, 2012. Page 35 [Gordoa 12] A. Gordoa, J. A. Rodriguez-Serrano, F. Perronnin & E. Valveny. Leveraging category-level labels for instance-level image retrieval. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pages 3045– 3052, June 2012. Pages 11 et 61 [Grauman 05] K. Grauman & T. Darrell. The pyramid match kernel : discriminative classification with sets of image features. In Proceedings of the 10th IEEE International Conference on Computer Vision, vol. 2, pages 1458–1465, Oct. 2005. Page 26 [Gu 07] J. Gu E.and Wang & N. I. Badler. Generating Sequence of Eye Fixations Using Decision-Theoretic Attention Model. In Attention in Cognitive Systems. Theories and Systems from an Interdisciplinary Viewpoint, vol. 4840 of Lecture Notes in Computer Science, pages 277–292. Springer Berlin Heidelberg, 2007. Page 34 [Halpern 11] D. F. Halpern. Sex differences in cognitive abilities. Psychology Press, 4th edition, 2011. Page 143 [Harel ] J. Harel. A Saliency Implementation in MATLAB. Pages 37 et 43 [Harris 88] C. Harris & M. Stephens. A Combined Corner and Edge Detector. In Proceedings of the 4th Alvey Vision Conference, pages 147–151, 1988. Pages 2 et 13 161Références bibliographiques [Hays 07] A. A. Hays J.and Efros. Scene Completion Using Millions of Photographs. In ACM SIGGRAPH Papers, 2007. Pages 2 et 11 [His ] https://sites.google.com/site/ int3llig3nc3artifici3ll3/retrospective-de-lhistoire-de-l-ia. Page 1 [Hofer 06] A. Hofer, C. M. Siedentopf, A. Ischebeck, M.A. Rettenbacher, M Verius, S. Felber & W. W. Fleischhacker. Gender differences in regional cerebral activity during the perception of emotion : A functional MRI study. NeuroImage, vol. 32, no. 2, pages 854–862, 2006. Page 143 [Hong 06] S. Hong & H. Choi. Color image semantic information retrieval system using human sensation and emotion. In Issues in Information Systems, vol. 7, pages 140–145, 2006. Pages 2 et 87 [Huiskes 08] M. J. Huiskes & M. S. Lew. The MIR Flickr Retrieval Evaluation. In Proceedings of the ACM International Conference on Multimedia Information Retrieval. ACM, 2008. Page 40 [Huiskes 10] M. J. Huiskes, B. Thomee & M. S. Lew. New Trends and Ideas in Visual Concept Detection : The MIR Flickr Retrieval Evaluation Initiative. In Proceedings of the ACM International Conference on Multimedia Information Retrieval, pages 527–536. ACM, 2010. Page 40 [Indyk 98] P. Indyk & R. Motwani. Approximate Nearest Neighbors : Towards Removing the Curse of Dimensionality. In Proceedings of the Thirtieth Annual ACM Symposium on Theory of Computing, pages 604–613. ACM, 1998. Page 28 [Itti 98] L. Itti, C. Koch & E. Niebur. A Model of Saliency-Based Visual Attention for Rapid Scene Analysis. IEEE Trans. Pattern Anal. Mach. Intell., vol. 20, no. 11, pages 1254–1259, 1998. Pages 34, 35, 37, 53 et 102 [James 90] W. James. The principles of psychology, vol. 1 of American science series : Advanced course. H. Holt, 1890. Pages 28 et 76 [Jauzein 10] F. Jauzein. Le traitement cérébral de l’information visuelle, 2010. Page 30 [Jégou 10a] H. Jégou, M. Douze & C. Schmid. Improving bag-of-features for large scale image search. International Journal of Computer Vision, vol. 87, no. 3, pages 316–336, Feb. 2010. Page 7 [Jégou 10b] H. Jégou, M. Douze, C. Schmid & P. Pérez. Aggregating local descriptors into a compact image representation. In Proceedings of the 23rd IEEE Conference on Computer Vision & 162Références bibliographiques Pattern Recognition, pages 3304–3311. IEEE Computer Society, 2010. Pages 2, 17, 21, 24, 26, 40, 50, 51, 53 et 67 [Jégou 11] H. Jégou, M. Douze & C. Schmid. Product Quantization for Nearest Neighbor Search. Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 33, no. 1, pages 117– 128, Jan. 2011. Pages 2 et 17 [Jégou 12] H. Jégou, F. Perronnin, M. Douze, J. Sanchez, P. Perez & C. Schmid. Aggregating Local Image Descriptors into Compact Codes. Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 34, no. 9, pages 1704–1716, Sept. 2012. Pages 40, 50, 51 et 53 [Judd 09] T. Judd, K. Ehinger, F. Durand & A. Torralba. Learning to Predict Where Humans Look. In Proceedings of the IEEE International Conference on Computer Vision, 2009. Page 35 [Kaya 04] Naz Kaya & Helen H. Epps. Color-Emotion associations : Past experience and personal preference. AIC Colors and Paints, Interim Meeting of the International Color Association, 2004. Pages 1, 78, 79 et 139 [Ke 04] Y. Ke & R. Sukthankar. PCA-SIFT : a more distinctive representation for local image descriptors. In Proceedings of the IEEE Computer Society Conference on Computer Vision and Pattern Recognition, vol. 2, pages 506–513, 2004. Pages 2, 17 et 19 [Keil 03] A. Keil, T. Gruber, M.. Müller, S. Moratti, M. Stolarova, M. Bradley & P.J. Lang. Early modulation of visual perception by emotional arousal : Evidence from steady-state visual evoked brain potentials. Cognitive, Affective, & Behavioral Neuroscience, vol. 3, no. 3, pages 195–206, 2003. Pages 94 et 95 [Kemp 02] A. H. Kemp, M. A. Gray, P. Eide, R. B. Silberstein & P. J. Nathan. Steady-State Visually Evoked Potential Topography during Processing of Emotional Valence in Healthy Subjects. NeuroImage, vol. 17, no. 4, pages 1684–1692, 2002. Pages 94 et 95 [Kienzle 09] W. Kienzle, M. O. Franz, B. Schölkopf & F. A. Wichmann. Center-surround patterns emerge as optimal predictors for human saccade targets. Journal of Vision, vol. 9, no. 5 :7, pages 1–15, 2009. Page 35 [Kobayashi 81] S. Kobayashi. The aim and method of the color image scale. Color Research & Application, vol. 6, no. 2, pages 93–107, 1981. Page 81 [Koch 85] C. Koch & S. Ullman. Shifts in Selective Visual Attention : Towards the Underlying Neural Circuitry. Human Neurobiology, vol. 4, pages 219–227, 1985. Page 35 163Références bibliographiques [Kootstra 08] G. Kootstra, A. Nederveen & B. Boer. Paying Attention to Symmetry. In Proceedings of the British Machine Vision Conference, pages 1–10. BMVA Press, 2008. Page 34 [Kootstra 11] G. Kootstra, B. de Boer & L. Schomaker. Predicting Eye Fixations on Complex Visual Stimuli Using Local Symmetry. Cognitive Computation, vol. 3, no. 1, pages 223–240, 2011. Page 55 [Lang 08] P. J. Lang, M. M. Bradley & B. N. Cuthbert. International affective picture system ( IAPS) : Affective ratings of pictures and instruction manual. Technical Report A-8. Rapport technique, University of Florida, 2008. Pages 3, 76, 83, 94, 95, 96 et 127 [Lange 22] C. G. Lange, W. James & I. A. Haupt. The emotions. Psychology classics. Williams & Wilkins Company, 1922. Page 76 [Lazebnik 06] S. Lazebnik, C. Schmid & J. Ponce. Beyond Bags of Features : Spatial Pyramid Matching for Recognizing Natural Scene Categories. In Proceedings of the IEEE Computer Society Conference on Computer Vision and Pattern Recognition, vol. 2, pages 2169–2178, 2006. Pages 26 et 27 [Le Meur 05a] O. Le Meur. Attention sélective en visualisation d’images fixes et animées affichées sur écran : Modèles et évaluation de performances-Applications. Thèse, École polytechnique de l’Université de Nantes : École doctorale STIM, Oct. 2005. Pages 29, 30, 32, 33, 34, 35 et 37 [Le Meur 05b] O. Le Meur, D. Thoreau, P. Le Callet & D. Barba. A spatiotemporal model of the selective human visual attention. In Proceedings of the IEEE International Conference on Image Processing, vol. 3, pages 1188–1191, Sept. 2005. Page 34 [Le Meur 06] O. Le Meur, P. Le Callet, D. Barba & D. Thoreau. A coherent computational approach to model bottom-up visual attention. Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 28, no. 5, pages 802–817, May 2006. Pages 34 et 55 [Le Meur 13] O. Le Meur & T. Baccino. Methods for comparing scanpaths and saliency maps : strengths and weaknesses. Behavior Research Methods, vol. 45, no. 1, pages 251–266, 2013. Page 37 [Lecellier 09] F. Lecellier. Les contours actifs basés région avec a priori de bruit, de texture et de forme : Application à l’échocardiographie. Thèse, Université de Caen, 2009. Page 109 [Leutenegger 11] S. Leutenegger, M. Chli & R. Y. Siegwart. BRISK : Binary Robust Invariant Scalable Keypoints. In Proceedings of the 164Références bibliographiques International Conference on Computer Vision, pages 2548– 2555. IEEE Computer Society, 2011. Page 20 [Li 08] X. Li, C. Wu, C. Zach, S. Lazebnik & J. Frahm. Modeling and Recognition of Landmark Image Collections Using Iconic Scene Graphs. In Proceedings of the 10th European Conference on Computer Vision : Part I, pages 427–440. Springer-Verlag, 2008. Pages 2 et 11 [Li 10a] J. Li, Y. Tian, T. Huang & W. Gao. Probabilistic MultiTask Learning for Visual Saliency Estimation in Video. International Journal of Computer Vision, vol. 90, no. 2, pages 150–165, 2010. Page 34 [Li 10b] Y. Li, Y. Zhou, J. Yan, Z. Niu & J. Yang. Visual Saliency Based on Conditional Entropy. In Computer Vision-ACCV, vol. 5994 of Lecture Notes in Computer Science, pages 246– 257. Springer Berlin Heidelberg, 2010. Page 34 [Liu 08] W. Liu, W. Xu & L. Li. A tentative study of visual attentionbased salient features for image retrieval. In Proceedings of the 7th World Congresson Intelligent Control and Automation, pages 7635–7639, June 2008. Page 38 [Liu 11a] E. Liu N.and Dellandréa & L. Chen. Evaluation of features and combination approaches for the classification of emotional semantics in images. In International Conference on Computer Vision Theory and Applications, 2011. Pages 2, 88, 110 et 120 [Liu 11b] T. Liu, Z. Yuan, J. Sun, J. Wang, N. Zheng, X. Tang & H. Shum. Learning to Detect a Salient Object. IEEE Trans. Pattern Anal. Mach. Intell., vol. 33, no. 2, pages 353–367, 2011. Page 34 [Lowe 99] D. G. Lowe. Object Recognition from Local Scale-Invariant Features. International Conference on Computer Vision, vol. 2, pages 1150–1157, 1999. Pages 2, 14, 17 et 87 [Lowe 04] D. G. Lowe. Distinctive Image Features from Scale-Invariant Keypoints. International Journal of Computer Vision, vol. 60, pages 91–110, 2004. Pages 2 et 17 [Lucassen 10] M. P. Lucassen, T. Gevers & A. Gijsenij. Adding texture to color : quantitative analysis of color emotions. In Proceedings of CGIV, 2010. Pages 81, 89 et 129 [Machajdik 10] J. Machajdik & A. Hanbury. Affective image classification using features inspired by psychology and art theory. In Proceedings of the international conference on Multimedia, pages 83–92, 2010. Pages 2, 3, 75, 78, 83, 84, 86, 88, 89, 92, 94, 95, 96, 121, 127 et 129 [Mahadevan 10] V. Mahadevan & N. Vasconcelos. Spatiotemporal Saliency in Dynamic Scenes. IEEE Transactions on Pattern Analysis 165Références bibliographiques and Machine Intelligence, vol. 32, no. 1, pages 171–177, 2010. Page 34 [Marat 09] S. Marat, T. Ho Phuoc, L. Granjon, N. Guyader, D. Pellerin & A. Guérin-Dugué. Modelling Spatio-Temporal Saliency to Predict Gaze Direction for Short Videos. International Journal of Computer Vision, vol. 82, no. 3, pages 231–243, 2009. Page 34 [Matas 02] J. Matas, O. Chum, M. Urban & T. Pajdla. Robust Wide Baseline Stereo from Maximally Stable Extremal Regions. In Proceedings of the British Machine Vision Conference, pages 1–10, 2002. Page 2 [Mikels 05] J. A. Mikels, B. L. Fredrickson, G. R. Larkin, C. M. Lindberg, S. J. Maglio & P. A. Reuter-Lorenz. Emotional category data on images from the international affective picture system. Behavior Research Methods, vol. 37, no. 4, pages 626–630, 2005. Pages 84, 86, 88 et 96 [Mikolajczyk 01] K. Mikolajczyk & C. Schmid. Indexing based on scale invariant interest points. In Proceedings of the 8th IEEE International Conference on Computer Vision, vol. 1, pages 525–531, 2001. Pages 2, 13, 14 et 15 [Mikolajczyk 02] K. Mikolajczyk & C. Schmid. An Affine Invariant Interest Point Detector. In Computer Vision-ECCV, vol. 2350 of Lecture Notes in Computer Science, pages 128–142. Springer Berlin Heidelberg, 2002. Page 14 [Mikolajczyk 05a] K. Mikolajczyk & C. Schmid. A performance evaluation of local descriptors. IEEE Transactions on Pattern Analysis & Machine Intelligence, vol. 27, no. 10, pages 1615–1630, 2005. Page 19 [Mikolajczyk 05b] K. Mikolajczyk, T. Tuytelaars, C. Schmid, A. Zisserman, J. Matas, F. Schaffalitzky, T. Kadir & L. Van Gool. A Comparison of Affine Region Detectors. Int. J. Comput. Vision, vol. 65, no. 1-2, pages 43–72, 2005. Page 12 [Mindru 04] F Mindru, T. Tuytelaars, L Van Gool & T. Moons. Moment invariants for recognition under changing viewpoint and illumination. Computer Vision and Image Understanding, vol. 94, no. 1–3, pages 3–27, 2004. Pages 19 et 20 [Moravec 77] H. P. Moravec. Towards Automatic Visual Obstacle Avoidance. In Proceedings of the 5th International Joint Conference on Artificial Intelligence, vol. 2, pages 584–584. Morgan Kaufmann Publishers Inc., 1977. Page 13 [Muja 09] M. Muja & D. G. Lowe. Fast approximate nearest neighbors with automatic algorithm configuration. In Proceedings of the International Conference on Computer Vision Theory and Applications, pages 331–340, 2009. Page 28 166Références bibliographiques [Munsell 05] A. H. Munsell. A color notation. G. H. Ellis Company, 1905. Page 139 [Nistér 06] D. Nistér & H. Stewénius. Scalable Recognition with a Vocabulary Tree. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, vol. 2, pages 2161– 2168, 2006. Pages 2, 3, 10, 17, 40 et 50 [Odom 00] A. S. Odom & S. S. Sholtz. The reds, whites, and blues of emotion : examining color hue effects on mood tones. 2000. Page 144 [Oei ] http://www.ophtalmo-mougins.com/anatomie-oeilophtalmo-06-alpes-maritimes-83-var.html. Page 29 [Ojala 02] T. Ojala, M. Pietikainen & T. Maenpaa. Multiresolution gray-scale and rotation invariant texture classification with local binary patterns. Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 24, no. 7, pages 971–987, July 2002. Page 88 [Oliva 01] A. Oliva & A. Torralba. Modeling the Shape of the Scene : A Holistic Representation of the Spatial Envelope. International Journal of Computer Vision, vol. 42, pages 145–175, 2001. Pages 2, 11 et 110 [Ou 04a] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study of colour emotion and colour preference. Part I : Colour emotions for single colours. Color Research & Application, vol. 29, no. 3, pages 232–240, 2004. Pages 1, 79, 80, 81, 87, 139 et 141 [Ou 04b] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study of colour emotion and colour preference. Part II : Colour emotions for two-colour combinations. Color Research & Application, vol. 29, no. 4, pages 292–298, 2004. Pages 1 et 80 [Ou 04c] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study of colour emotion and colour preference. Part III : Colour preference modeling. Color Research & Application, vol. 29, no. 5, pages 381–389, 2004. Pages 1 et 80 [Ou 06] L. C. Ou & M. R. Luo. A colour harmony model for twocolour combinations. Color Research & Application, vol. 31, no. 3, pages 191–204, 2006. Pages 1 et 82 [Ou 11] L. C. Ou, P. Chong, M. R. Luo & C. Minchew. Additivity of colour harmony. Color Research & Application, vol. 36, no. 5, pages 355–372, 2011. Pages 1 et 83 [Paleari 08] M. Paleari & B. Huet. Toward emotion indexing of multimedia excerpts. Proceedings on Content-Based Multimedia Indexing, International Workshop, pages 425–432, 2008. Page 78 167Références bibliographiques [Parsons 04] L. Parsons, E. Haque & H. Liu. Subspace clustering for high dimensional data : a review. In Proceedings of the ACM SIGKDD, vol. 6, pages 90–105. Explorations Newsletter, 2004. Pages 3 et 42 [Perreira Da Silva 10a] M. Perreira Da Silva. Modèle computationnel d’attention pour la vision adaptative. Thèse, Université de La Rochelle, 2010. Pages 29, 31 et 37 [Perreira Da Silva 10b] M. Perreira Da Silva, V. Courboulay, A. Prigent & P. Estraillier. Evaluation of preys/predators systems for visual attention simulation. In Proceedings of the International Conference on Computer Vision Theory and Applications, pages 275–282. INSTICC, 2010. Pages 102 et 103 [Perreira Da Silva 12] M. Perreira Da Silva & V. Courboulay. Implementation and evaluation of a computational model of attention for computer vision. In Developing and Applying Biologically-Inspired Vision Systems : Interdisciplinary Concepts, pages 273–306. Hershey, Pennsylvania : IGI Global., 2012. Page 34 [Perronnin 06] F. Perronnin, C. Dance, G. Csurka & M Bressan. Adapted vocabularies for generic visual categorization. In Proceedings of the ECCV, pages 464–475, 2006. Page 23 [Perronnin 07] F. Perronnin & C. R. Dance. Fisher Kernels on Visual Vocabularies for Image Categorization. In Proceedings of the IEEE Computer Society Conference on Computer Vision and Pattern Recognition. IEEE Computer Society, 2007. Pages 2, 24, 25, 26, 27 et 67 [Perronnin 08] F. Perronnin. Universal and Adapted Vocabularies for Generic Visual Categorization. Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 30, no. 7, pages 1243– 1256, July 2008. Pages 11 et 23 [Plutchik 97] R. Plutchik & H. R. Conte. Circumplex models of personality and emotions. American Psychological Association, 1997. Page 78 [Ramström 02] O. Ramström & H. Christensen. Visual Attention Using Game Theory. In Biologically Motivated Computer Vision, vol. 2525 of Lecture Notes in Computer Science, pages 462– 471. Springer Berlin Heidelberg, 2002. Page 35 [Ret ] http://commons.wikimedia.org/wiki/File:Retina.svg. Page 30 [Rigoulot 08] S. Rigoulot. Impact comportemental et électrophysiologique de l’information émotionnelle en vision périphérique. PhD thesis, Université de Lille II - École Doctorale de BiologieSanté, Sept. 2008. Page 77 168Références bibliographiques [Rosin 09] P. L. Rosin. A Simple Method for Detecting Salient Regions. Pattern Recogn., vol. 42, no. 11, pages 2363–2371, 2009. Page 35 [Rosten 05] E. Rosten & T. Drummond. Fusing points and lines for high performance tracking. In Proceedings of the IEEE International Conference on Computer Vision, vol. 2, pages 1508–1511, Oct. 2005. Pages 15 et 16 [Rosten 06] E. Rosten & T. Drummond. Machine learning for high-speed corner detection. In Proceedings of the European Conference on Computer Vision, vol. 1, pages 430–443, May 2006. Page 15 [Saito 96] M. Saito. Comparative studies on color preference in Japan and other Asian regions, with special emphasis on the preference for white. Color Research & Application, vol. 21, no. 1, pages 35–49, 1996. Page 81 [Sánchez 13] J. Sánchez, F. Perronnin, T. Mensink & J. Verbeek. Image Classification with the Fisher Vector : Theory and Practice. International Journal of Computer Vision, vol. 105, no. 3, pages 222–245, 2013. Pages 25 et 28 [Sander 13] D. Sander. Vers une définition de l’émotion. Cerveau&Psycho, no. 56, 2013. Pages 1 et 76 [Schachter 62] S. Schachter & J. Singer. Cognitive, social, and physiological determinants of emotional state. Psychological Review, vol. 69, no. 5, pages 379–399, 1962. Page 77 [Scherer 84] K. R. Scherer & P. Ekman. Approaches to emotions. Lavoisier, Jan. 1984. Pages 2 et 86 [Schmid 00] C. Schmid, R. Mohr & C. Bauckhage. Evaluation of Interest Point Detectors. Int. J. Comput. Vision, vol. 37, no. 2, pages 151–172, 2000. Pages 12 et 14 [Sève 09] R. Sève. Science de la couleur : Aspects physiques et perceptifs. Chalagam Edition, 2009. Page 87 [Sharbrough 91] F. Sharbrough, G. E. Chatrian, R. P. Lesser, H. Luders, M. Nuwer & T. W. Picton. American Electroencephalographic Society guidelines for standard electrode position nomenclature. J. Clin. Neurophysiol., vol. 8, pages 200–202, 1991. Pages 106 et 147 [Sivic 03] J. Sivic & A. Zisserman. Video Google : A Text Retrieval Approach to Object Matching in Videos. In Proceedings of the International Conference on Computer Vision, pages 1470–1477, 2003. Pages 2, 3, 21, 24 et 67 [Smets 90] P. Smets. The Combination of Evidence in the Transferable Belief Model. IEEE Trans. Pattern Anal. Mach. Intell., vol. 12, no. 5, pages 447–458, May 1990. Page 88 169Références bibliographiques [Smith 97] S. M. Smith & J. M. Brady. SUSAN&Mdash ;A New Approach to Low Level Image Processing. Int. J. Comput. Vision, vol. 23, no. 1, pages 45–78, May 1997. Page 15 [Solli 09] M. Solli & R. Lenz. Color harmony for image indexing. In Proceedings of the 12th International Conference on Computer Vision Workshops, pages 1885–1892, Sept. 2009. Pages 1, 83 et 133 [Solli 10] M. Solli & R. Lenz. Emotion Related Structures in Large Image Databases. In Proceedings of the ACM International Conference on Image and Video Retrieval, pages 398–405. ACM, 2010. Pages 2, 83 et 87 [Suk 10] H. Suk & H. Irtel. Emotional response to color across media. Color Research & Application, vol. 35, no. 1, pages 64–77, 2010. Pages 81 et 90 [Swain 91] M. J. Swain & D. H. Ballard. Color indexing. International Journal of Computer Vision, vol. 7, pages 11–32, 1991. Pages 2 et 11 [Tayari 09] I. Tayari, N. Le Thanh & C. Ben Amar. Modélisation des états émotionnels par un espace vectoriel multidimensionnel. Rapport technique, Laboratoire Informatique, Signaux et Systèmes de Sophia Antipolis, Déc. 2009. Page 77 [Tomasi 91] C. Tomasi & T. Kanade. Detection and Tracking of Point Features. Rapport technique, International Journal of Computer Vision, 1991. Page 13 [Tomkims 62] S. S. Tomkims. Affect imagery consciousness : The positive affects, vol. 1. Springer Publishing Company, 1962. Pages 2 et 86 [Treisman 80] A. Treisman & G. Gelade. A featureintegration theory of attention. Cognitive Psychology, vol. 12, pages 97–136, 1980. Page 35 [Turing 50] A. M. Turing. Computing Machinery and Intelligence, 1950. Page 1 [Tuytelaars 08] T. Tuytelaars & K. Mikolajczyk. Local Invariant Feature Detectors : A Survey. Foundations and Trends in Computer Graphics and Vision, vol. 3, no. 3, pages 177–280, 2008. Pages 12 et 13 [van de Sande 10] K. E. A. van de Sande, T. Gevers & C. G. M. Snoek. Evaluating Color Descriptors for Object and Scene Recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 32, no. 9, pages 1582–1596, 2010. Pages 2, 16, 17, 18, 21, 26, 27, 42 et 62 [Van De Weijer 06] J. Van De Weijer & C. Schmid. Coloring local feature extraction. In Proceedings of the European Conference on 170Références bibliographiques Computer Vision, vol. 3952 of Lecture Notes in Computer Science, pages 334–348. Springer, 2006. Page 87 [Wang 05] W. Wang & Y. Yu. Image Emotional Semantic Query Based on Color Semantic Description. In Proceedings of the The 4th International Conference on Machine Leraning and Cybernectics, vol. 7, pages 4571–4576, 2005. Pages 2 et 87 [Wang 06] W. Wang, Y. Yu & S. Jiang. Image Retrieval by Emotional Semantics : A Study of Emotional Space and Feature Extraction. In Proceedings of the IEEE International Conference on Systems, Man and Cybernetics, vol. 4, pages 3534–3539, Oct. 2006. Page 87 [Wang 10] B. Wang, X. Zhang, M. Wang & P. Zhao. Saliency distinguishing and applications to semantics extraction and retrieval of natural image. In Proceedings of the International Conference on Machine Learning and Cybernetics, vol. 2, pages 802–807, July 2010. Page 38 [Wang 11] C. Wang W.and Chen, Y. Wang, T. Jiang, F Fang & Y. Yao. Simulating human saccadic scanpaths on natural images. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pages 441–448, June 2011. Page 34 [Wang 13] S. Wang, G. Wu & Y. Zhu. Analysis of Affective Effects on Steady-State Visual Evoked Potential Responses. In Intelligent Autonomous Systems, vol. 194 of Advances in Intelligent Systems and Computing, pages 757–766. Springer Berlin Heidelberg, 2013. Page 95 [Wei 08] K. Wei, B. He, T. Zhang & W. He. Image emotional classification based on color semantic description, vol. 5139 of Lecture Notes in Computer Science, pages 485–491. Springer Berlin / Heidelberg, 2008. Pages 78 et 120 [Wu 05] Q. Wu, C. Zhou & C. Wang. Content-Based Affective Image Classification and Retrieval Using Support Vector Machines. In Affective Computing and Intelligent Interaction, vol. 3784 of Lecture Notes in Computer Science, pages 239–247. Springer Berlin Heidelberg, 2005. Page 88 [Yanulevskaya 08] V. Yanulevskaya, J. C. Van Gemert, K. Roth, A. K. Herbold, N. Sebe & J. M. Geusebroek. Emotional valence categorization using holistic image features. In Proceedings of the 15th IEEE International Conference on Image Processing, pages 101–104, 2008. Pages 2, 83, 88 et 92 [Zdziarski 12] Z. Zdziarski & R. Dahyot. Feature selection using visual saliency for content-based image retrieval. In Proceedings of the IET Irish Signals and Systems Conference, pages 1–6, 2012. Pages 61, 64 et 132 171Références bibliographiques [Zhang 07] J. Zhang, M. Marszalek, S. Lazebnik & C. Schmid. Local features and kernels for classification of texture and object categories : A comprehensive study. International Journal of Computer Vision, vol. 73, no. 2, pages 213–238, 2007. Pages 42 et 131 [Zhang 09] L. Zhang, M. H. Tong & W. Garrison. SUNDAy : Saliency Using Natural Statistics for Dynamic Analysis of Scenes. In Proceedings of the Cognitive Science Society Conference, 2009. Page 34 172Liste des publicationsListe des publications Revues nationales avec comité de lecture – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction et analyse de l’impact émotionnel des images, Traitement de Signal n˚3-4-5/2012, p. 409- 432. Conférences internationales avec actes et comité de lecture – T. Urruty, S. Gbèhounou, H. T. Le, J. Martinet, C. Fernandez-Maloigne, Iterative Random Visual Word Selection 4th International Conference on Multimedia Retrieval, 1-4 April 2014. – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Can salient interest regions resume emotional impact of an image ?, 15th International Conference on Computer Analysis of Images and Patterns, 27-29 August 2013, LNCS 8047, p. 515. – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Gender influences on subjective evaluations in image, 12th International AIC Colour Congress, 8-12 Juillet 2013. – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction of emotional impact in colour images, CGIV 2012, Vol. 6, Society for Imaging Science and Technology, 2012, p. 314-319. Conférences nationales avec actes et comité de lecture – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction et analyse de l’impact émotionnel des images, 18ème Congrès francophone sur la Reconnaissance des Formes et l’Intelligence Artificielle, 24-27 Janvier 2012. Exposés nationaux – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Les régions saillantes améliorent-elles l’évaluation de l’impact émotionnel des images ?, GDR ISIS, 26 Septembre 2013, Paris. – S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Extraction et analyse de l’impact émotionnel des images, Séminaire École Doctorale S2IM, 10-12 Avril 2013, Poitiers. 175Indexation de bases d’images : Évaluation de l’impact émotionnel Résumé : L’objectif de ce travail est de proposer une solution de reconnaissance de l’impact émotionnel des images en se basant sur les techniques utilisées en recherche d’images par le contenu. Nous partons des résultats intéressants de cette architecture pour la tester sur une tâche plus complexe. La tâche consiste à classifier les images en fonction de leurs émotions que nous avons définies "Négative", "Neutre" et "Positive". Les émotions sont liées aussi bien au contenu des images, qu’à notre vécu. On ne pourrait donc pas proposer un système de reconnaissance des émotions performant universel. Nous ne sommes pas sensible aux mêmes choses toute notre vie : certaines différences apparaissent avec l’âge et aussi en fonction du genre. Nous essaierons de nous affranchir de ces inconstances en ayant une évaluation des bases d’images la plus hétérogène possible. Notre première contribution va dans ce sens : nous proposons une base de 350 images très largement évaluée. Durant nos travaux, nous avons étudié l’apport de la saillance visuelle aussi bien pendant les expérimentations subjectives que pendant la classification des images. Les descripteurs, que nous avons choisis, ont été évalués dans leur majorité sur une base consacrée à la recherche d’images par le contenu afin de ne sélectionner que les plus pertinents. Notre approche qui tire les avantages d’une architecture bien codifiée, conduit à des résultats très intéressants aussi bien sur la base que nous avons construite que sur la base IAPS, qui sert de référence dans l’analyse de l’impact émotionnel des images. Mots-clés : Recherche d’images par le contenu, Sac de mots visuels, impact émotionnel des images, saillance visuelle, évaluations subjectives Image databases indexing : Emotional impact assessing Abstract : The goal of this work is to propose an efficient approach for emotional impact recognition based on CBIR techniques (descriptors, image representation). The main idea relies in classifying images according to their emotion which can be "Negative", "Neutral" or "Positive". Emotion is related to the image content and also to the personnal feelings. To achieve our goal we firstly need a correct assessed image database. Our first contribution is about this aspect. We proposed a set of 350 diversifed images rated by people around the world. Added to our choice to use CBIR methods, we studied the impact of visual saliency for the subjective evaluations and interest region segmentation for classification. The results are really interesting and prove that the CBIR methods are usefull for emotion recognition. The chosen desciptors are complementary and their performance are consistent on the database we have built and on IAPS, reference database for the analysis of the image emotional impact. Keywords : Content Based Image Retrieval, Bag of Visual Words, image emotional impact, visual saliency, subjective evaluations Doctorat de l’Université de Poitiers, Spécialité : Traitement du Signal et des images Thèse préparée et soutenue au Département SIC du Laboratoire XLIM, UMR 7252 Université de Poitiers, Bât. SP2MI, Téléport 2, Bvd Marie et Pierre Curie BP 30179, 86962 Futuroscope Chasseneuil Cedex France De nouveaux outils pour calculer avec des inductifs en Coq Pierre Boutillier To cite this version: Pierre Boutillier. De nouveaux outils pour calculer avec des inductifs en Coq. Programming Languages. Universit´e Paris-Diderot - Paris VII, 2014. French. HAL Id: tel-01054723 https://tel.archives-ouvertes.fr/tel-01054723 Submitted on 8 Aug 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Paris Diderot (Sorbonne Paris Cité) Laboratoire PPS – Éqipe πr 2 École Doctorale Sciences Mathématique de Paris Centre Thèse de doctorat spécialité Informatiqe De nouveaux outils pour Calculer avec des inductifs en Coq présentée et soutenue publiquement par Pierre Boutillier le 18 février 2014 devant le jury composé de M. Yves Bertot rapporteur M. Roberto Di Cosmo président M. Hugo Herbelin directeur M. Daniel Hirschkoff examinateur M. Conor McBride examinateur Mme. Christine Paulin-Mohring examinatrice M. Carsten Schuermann rapporteurÀ Madou et tonton Jean-Pierre,Mercis Le grade de docteur ne s’obtient jamais seul. J’ai le privilège d’avoir été merveilleusement entouré. Antichronologiquement, comme le veut la coutume, Yves Bertot et Carsten Schuermann ont dû endurer mon style et m’ont malgré tout autorisé à soutenir. Je leur suis énormément reconnaissant de l’eort d’une part et de la pertinence de leurs remarques d’autre part. D’autant que Carsten l’a fait dans une langue étrangère et Yves avec bienveillance. Les discussions avec Hugo m’ont toujours énormément éclairé sur comment aborder une question en conservant ma manière de penser ; vision, il me semble, que nous partageons. Ce manuscrit n’est « pas si pire » grâce à Pierre Letouzey qui m’a oert un peu de la rigueur qui fait tenir Coq debout pour relire exhaustivement ma thèse. Le reste de l’équipe πr 2 Yann, Matthieu, Alexis, Pierre-Louis, Pierre-Marie, Lourdes, Guillaume, Matthias, Sté- phane, Vincent ont tous joué un rôle dans l’écriture et/ou la conception de cette thèse et de sa soutenance. Christine, Frédérique et Thomas ont aussi beaucoup aidé à la genèse de ce document. Fernand Deligny (pédagogue) disait « Soit surtout présent lorsque tu n’es pas là. » C’est le tour de force que réussit Christine Paulin-Mohring avec l’équipe de développement de Coq ! Bien que nos échanges directs soient récents, son inuence ne l’est pas et je la remercie chaleureusement d’évaluer mon travail. Mon cerveau a été scientiquement façonné par Conor McBride. Mes quelques idées originales trouvent leur source dans sa folie. Avant lui, Daniel Hirschko (avec l’ensemble de l’équipe PLUME) m’avait dénitivement fait tomber dans les bras de la programmation comme support du raisonnement. Daniel fut aussi ma boussole aux moments clés de mon cheminement scientique. Daniel et Roberto Di Cosmo, qui m’honore de la présidence de mon jury, furent, de mes enseignants d’informatique, ceux qui m’ont le plus marqué. J’estime que l’enseignement fut une part importante de mon travail de thèse et je pense que si elle fut si plaisante, c’est grâce à leur modèle auxquel j’ai pu me raccrocher. Mes études supérieures doivent énormément au cadre dans lequel elles ont eu lieu. Il me faut donc remercier l’ENS Lyon et le Lycée Fenelon (et donc ceux qui les font ainsi) pour m’avoir d’abord séduit au premier regard, puis pour m’être fait me dire que même rentré par la fenêtre, l’année d’après j’y serai et enn pour ne m’avoir, mais alors pas du tout, déçu ensuite ! A tous les niveaux, les établissements que j’ai fréquentés tenaient debout grâce à leur responsable administratif. Merci pour tout ce travail de l’ombre ! Ma famille m’a donné la possibilité d’un épanouissement personnel rare. Mes parents ont réussi le tour de force de toujours m’encourager à être moi-même sans jamais abandonner l’idée d’améliorer mes torts. Je me suis construit grâce à leur persévérance. Toute la famille 5m’a énormément soutenu et me dire « nis ta thèse pour qu’ils puissent un peu se dire que tu n’as pas gâché toute la liberté qu’ils t’ont ménagée » a été l’un des moteurs irrationnels forts pour mener l’aventure au bout. Sneusneur est aussi à un tournant qu’elle devrait surmonter très fort, nous avons toujours fonctionné en symbiose. Ma thèse et beaucoup plus doivent quotidiennement énormément à Maud. 6Table des matières Introduction 9 Logiques constructives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Quantication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 La généralisation : les inductifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Correspondance preuves/programmes . . . . . . . . . . . . . . . . . . . . . . . . . 11 Machines universelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Programmation fonctionnelle avec types algébriques . . . . . . . . . . . . . . . . . 12 Types riches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Utilisation des données inductives . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Réduction des points xes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1 Un langage fonctionnel avec types riches 17 1.1 Conventions d’écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Le cœur fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3 Déclarations globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4 Types de données algébriques strictement positifs . . . . . . . . . . . . . . . 21 1.4.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.4.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Des structures de données d’exemple . . . . . . . . . . . . . . . . . . . . . . 24 1.6 Digression sur la représentation des constructeurs et des branches . . . . . . 26 1.7 Expressivité de l’analyse de cas . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2 Le filtrage en programmation fonctionnelle 29 2.1 Principe du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2 Reconnaitre un motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Construire un arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 Arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mécanique d’atomisation . . . . . . . . . . . . . . . . . . . . . . . . 34 7Table des matières 3 Encodage du filtrage dans l’analyse de cas 37 3.1 Le ltrage dépendant primitif . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Encodage du ltrage par des analyses de cas . . . . . . . . . . . . . . . . . . 38 3.2.1 Des types riches exprimant les problèmes d’unication . . . . . . . . 39 3.2.2 Manipulation des égalités d’index . . . . . . . . . . . . . . . . . . . . 40 3.3 Utilisabilité de l’encodage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4 Constructions génériques autour d’une analyse de cas dépendante . . . . . . 42 3.4.1 Coupures entrelacées . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.2 Elimination des branches impossibles . . . . . . . . . . . . . . . . . . 43 4 Du filtrage à l’analyse de cas structurellement 45 4.1 Squelette d’index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2 Quand les égalités sont inutiles . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3 Diagonalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4 Quand le diagonaliseur en dit trop . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5 Des clauses de retour pour éliminer tous les termes . . . . . . . . . . . . . . 53 4.5.1 Les index du type ne contiennent que des variables et des constructeurs 53 4.5.2 Hors du cadre pseudo-motif . . . . . . . . . . . . . . . . . . . . . . . 54 4.6 Digression sur les cas impossibles dans des points xes . . . . . . . . . . . . 55 4.7 Mécaniser la diagonalisation et compiler le ltrage . . . . . . . . . . . . . . . 56 4.7.1 Construire une analyse de cas à partir de sa clause de retour . . . . . 56 4.7.2 D’un arbre de décision à des analyses de cas . . . . . . . . . . . . . . 57 4.7.3 Extraire un diagonaliseur . . . . . . . . . . . . . . . . . . . . . . . . 59 4.8 Eléments de correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5 Simplifier un terme 63 5.1 Normalisation en appel par nom . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Trace des constantes dépliées . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3 Refolding Algebraic Krivine Abstract Machine . . . . . . . . . . . . . . . . . 69 5.4 Congurabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6 Etablir qu’un point fixe ne produit pas de calcul infini 75 6.1 Décroissance structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.2 Ranement lié à l’induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3 Ranement lié aux coupures entrelacées . . . . . . . . . . . . . . . . . . . . 81 6.4 Ranement lié à la réduction . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.4.1 Garder la forme βιδ normale . . . . . . . . . . . . . . . . . . . . . . . 82 6.4.2 Retrouver la réduction forte . . . . . . . . . . . . . . . . . . . . . . . 84 6.4.3 Questions d’ecacité . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.5 La règle ϕ de réduction impose une garde structurelle . . . . . . . . . . . . . 86 Conclusion et perspectives 89 8Introduction Aucune tâche n’est atomique. Toute action se décompose en opérations plus élémentaires. Agir demande en permanence de concevoir des algorithmes an de réaliser des activités complexes. Le concept de programme et son exécution ou calcul est bien antérieur à l’apparition des ordinateurs. L’informatique, la science qui les étudie, n’a donc pas attendu des machines aussi complexes pour susciter l’intérêt. La mécanisation n’a fait que démultiplier le besoin d’y rééchir formellement. L’humain a le souci de l’optimisation. Dès qu’il trouve un algorithme, il se demande comment faire la même chose en moins d’étapes ou par d’autres moyens. Pourtant, après modications, l’algorithme réalise-t-il eectivement toujours « la même chose » ? Nos cousins shadocks arment que « Plus un ordinateur va vite, plus il donne de bons résultats. . . ». Laissons-leur l’ambiguïté sur la notion de bon résultat et le pied de nez que j’y vois à mon ministère de tutelle. Cette introduction établit un cadre mathématique qui aborde formellement la question de la correction (le fait d’être correct) d’un résultat. Ce manuscrit n’y répond pas ; il aborde des problématiques pour faciliter l’utilisation de systèmes qui permettent d’y répondre. Nous allons d’abord énumérer des systèmes logiques dans lesquels prouver revient de plus en plus à manipuler des données et des fonctions. Il est légitime de parler de logique pour aborder la programmation et d’utiliser des structures de données pour appuyer un raisonnement logique. Nous basculerons en eet dans l’informatique en décrivant les découvertes qui ont identié les deux problématiques en donnant, suivant le point de vue, aux preuves un corps ou aux programmes une description de leur comportement. Ainsi, nous aboutirons à un langage de programmation pratique qui apporte des garanties fortes sur la bonne formation des programmes qu’il permet d’écrire. Nous aurons alors le socle nécessaire pour discuter nos problématiques. Logiques constructives Formaliser la logique est apparu comme un champ des mathématiques au cours du 19e siècle. Des primitives autour desquelles s’articule le raisonnement ont émergé. Parmi ces connecteurs : l’implication exprime la possibilité d’obtenir une propriété B à partir d’une propriété A et s’écrit A → B. Elle vient avec l’axiome que pour toute propriété A, A → A. la conjonction fait de deux propriétés une propriété. la disjonction introduit la notion de choix. Elle se construit en donnant l’une des deux possibilités. Elle demande de savoir agir dans les deux cas pour être détruite. 9Introduction faux n’a pas de règle d’obtention. Elle permet de nier toute proposition. Par ailleurs, les premiers systèmes formels venaient avec la supposition toujours faite jusque là que l’on peut toujours considérer qu’une propriété est soit vraie soit fausse (principe du tiers exclu). On parle aujourd’hui de logique classique. Dans les logiques classiques, prouver l’impossibilité qu’il n’existe pas revient à prouver qu’il existe. L’objet dont la non existence a été niée n’est pas pour autant construit. Un mouvement s’est constitué pour établir des logiques dans lesquelles prouver qu’il existe impose d’exhiber un témoin d’existence. Ce schéma de pensée appelé constructivisme a un intérêt particulier pour voir les preuves d’existence comme des algorithmes de construction. Quelles que soient les structures de données utilisées et les règles de raisonnement autorisées, il existe plusieurs manières de structurer un raisonnement. Parmi elles, la déduction naturelle dénit les connecteurs par deux types de règles : des règles pour les construire ou introduire et des règles pour les détruire ou utiliser. Cette manière de faire est assez intuitive lors de la construction de preuves par l’esprit humain. Le calcul des séquents est lui ecace lors du traitement mécanique des preuves. Pour chaque connecteur, il s’articule autour de règles dites gauches si on suppose avoir la donnée et de règles dites droites si on veut l’obtenir. antification Le type des entiers naturels, déni par l’arithmétique de Peano, représente une classe d’objet contenant une innité d’habitants distincts directement manipulables dans la logique. Les nombres sont construits à l’aide de deux primitives : une constante nommée zéro et une fonction injective successeur qui à tout entier associe l’entier suivant. Surtout, un nouveau concept arrive pour utiliser les nombres entiers : le raisonnement par récurrence. Il permet de prouver des propriétés qui dépendent d’un entier par un raisonnement potentiellement inni. Ce raisonnement est en réalité ni pour tout entier ni car il donne un comportement à adopter ni pour l’entier zéro et un comportement ni pour passer de la propriété pour un entier à cette propriété pour son successeur. L’arithmétique permet d’énoncer des propriétés qui parlent d’entiers naturels. Elle dispose en plus de l’implication d’une notion de quantication : une propriété peut parler des valeurs des objets qu’elle suppose. On peut écrire, pour tout entier naturel n, la propriété P dans laquelle n apparaît. La quantication est aussi utilisable pour permettre à une propriété de dépendre d’une autre propriété. Par ce biais, une propriété peut parler de toutes les propriétés (y compris ellemême). Un tel système est dit imprédicatif. Le système F de Girard est obtenu en ajoutant la quantication sur les propriétés à la logique minimale. Il forme ainsi le système d’expressivité minimale où les raisonnements imprédicatifs sont permis. L’imprédicativité est extrêmement expressive. En système F, les structures de données n’ont pas besoin d’être dénies. Elles sont toutes encodables au moyen de quantications et d’implications (voir les travaux de Böhm etBerarducci [9]). La puissance de l’imprédicativité cause des suspicions chez certains constructivistes quant à son admissibilité. Par contre, l’idée de ne pas se cantonner à un nombre ni de structures 10La généralisation : les inductifs de données a été réexploitée. De même, exprimer des propriétés qui varient selon la valeur des données dont elles dé- pendent s’est révélée une brique élémentaire des systèmes logiques constructifs. Le logical framework (LF) [48] ou λπ [20] est le langage générique pour raisonner sur ces systèmes. La généralisation : les inductifs Martin-Löf a proposé un système logique prédicatif disposant des structures de données de la logique intuitionniste et de quantications sur les valeurs. Pourtant, toutes les structures de données vues jusqu’ici ont toutes un canevas similaire. Elles sont engendrées par un nombre ni de constructeurs et les utiliser revient à énumérer le comportement à adopter dans le cas de chacun des constructeurs. De plus, prouver une propriété dans les cas récursifs peut se faire grâce à cette même propriété sur les sous-parties récursives. De cette constatation, Dybjer [22] a proposé une généralisation de la théorie des types de Martin-Löf avec un monde ouvert. Toute structure de données qui respecte un canevas assurant sa bonne formation est dénissable puis utilisable directement. Les systèmes logiques sont d’une importance fondamentale pour l’informatique. Ces recherches sont en réalité développées non pas seules mais en interaction avec l’informatique grâce à deux découvertes fondamentales du vingtième siècle. Pour poursuivre continûment le déroulé de cette introduction, elles sont présentées ici dans l’ordre antichronologique. Correspondance preuves/programmes Pour tenter d’assurer la correction des programmes, on a cherché à les classier. Pour cela, on leur a associé un type, une spécication construite par des règles d’inférence à partir de la syntaxe du programme qui spécie son comportement. Si l’on sait qu’un morceau de programme est une fonction qui prend un entier et renvoie une liste de vrai ou faux, nous savons qu’il est impossible de l’élever au carré ou de lui donner en entrée un tableau de nombres à virgule. L’intérêt premier des types est de signaler tôt et systématiquement au programmeur toute une classe d’erreurs qu’il a pu commettre, sans attendre que ce programme plante lors de son exécution. Mais avec leur introduction intervient une révolution. Les types ont donné corps au travail des logiciens constructivistes. Prouver que la propriété que A et B implique A ou B est identique à écrire une fonction qui prend la paire d’un élément de type A et d’un élément de B et qui renvoie un élément soit de type A soit de type B. C’est la correspondance de Curry-DeBruijn-Howard ; la logique nourrit l’informatique. Prouver des théorèmes est isomorphe à écrire des programmes si l’on est capable de donner un contenu calculatoire aux axiomes et aux constructeurs de notre logique. Le coeur de ce dispositif est la correspondance entre la fonction et l’implication logique. Autrement dit la logique minimale a pour langage correspondant le λ-calcul simplement typé. 11Introduction Le bloc de données et la conjonction de propriétés sont les deux facettes du même objet. Le choix et disjonction aussi. Derrière la récurrence, il y a un programme clair : les fonctions récursives, c’est-à-dire celles qui se rappellent elles-même. L’arithmétique de Péano a donc un langage de programmation correspondant dont le comportement calculatoire est basé sur le système T de Gödel. Burstall propose avec Hope [15] un langage de programmation ayant un mécanisme de ltrage pour raisonner par cas et la possibilité de dénir des types algébriques. Cette idée a mené à la dénition de la famille de langages fonctionnels ML ainsi qu’à Haskell [31] et a donné le support nécessaire à la dénition de la théorie des types de Martin-Löf. Machines universelles Avant la découverte de cette correspondance entre calculs qui terminent et preuves de théorème, les diérentes manières de calculer avait été prouvées équivalentes. Alan Turing cherchant à modéliser le comportement mécanique du mathématicien en le représentant comme une machine munie d’états d’esprits, d’un alphabet, d’un crayon, d’une gomme, de règles pour changer d’état d’esprit et agir localement sur le papier à partir de son état d’esprit et de ce qu’il lit et d’inniment de feuilles de papiers ; John von Neumann réalisant concrètement une machine capable de réaliser quelques opé- rations de lecture et d’écriture dans un dispositif de stockage d’informations qu’il nomme mémoire. Cette machine lisant quelles opérations elle doit faire à partir de sa mémoire ; Alonzo Church construisant le λ-calcul, un langage élémentaire pour parler des preuves mathématiques ; peuvent tous trois calculer les mêmes résultats ! Les preuves qu’un mathématicien peut écrire, il peut les manipuler mécaniquement. Ce qu’il peut faire mécaniquement en concevant un programme, une machine peut le faire. Voici la révolution qui créa l’informatique théorique : raisonner, c’est eectivement programmer, l’informatique peut nourrir la logique. Avec ces formalismes, il est facile de montrer que ces machines ne peuvent pas tout. Elles ne peuvent par exemple pas prédire dans tous les cas si un algorithme donné s’arrête après un nombre ni d’étapes de calcul. Cette question est plus élémentaire que savoir si deux algorithmes ont les même sorties pour les même entrées. Il n’y a aucune chance de répondre en toute généralité au problème de l’équivalence de programmes. Programmation fonctionnelle avec types algébriques La théorie des types de Martin-Löf généralisée propose sur le versant informatique un langage avec un monde ouvert où l’utilisateur peut introduire de nouvelles structures de données à la condition qu’elles soient correctement formées. Ces données sont ensuite utilisables grâce à des fonctions récursives ou du raisonnement par induction. On parle naturellement de structure de données inductives. 12Types riches Pour l’utilisateur, travailler avec des structures de données qu’il a dénies exactement pour son besoin lui permet d’écrire des programmes suivant son intuition sans se soucier d’encodage. L’étude mathématique justie la correction des programmes typés dans ce formalisme. Ce paradigme de programmation permet d’utiliser de manière sûre et simple les primitives des processeurs. Réaliser un choix est une des opérations élémentaires mises à la disposition du programmeur. Cette action consiste à exécuter une partie ou une autre d’un programme suivant la valeur d’une entrée. De manière primitive dans un processeur, l’opération de branchement conditionnel saute à une instruction plus lointaine en fonction du résultat d’une comparaison d’entiers. Historiquement, les langages impératifs (C, Java, . . .) proposent un opérateur de sélection de cas à partir de cette primitive. La commande switch n inspecte la valeur de l’entier n puis exécute le code situé entre case k: et break; si n = k. Un comportement par défaut, pour les k n’apparaissant pas, est spécié grâce à default:. Si un ordinateur ne manipule que des séquence de bits, ce n’est pas le cas de l’intuition humaine. Il est donc communément possible d’associer un nom à un nombre par #define FLEUR 12 an de clarier les programmes en écrivant switch (plante) { case FLEUR: cueillir; break; default: arroser}. Par contre, il n’existe aucune garantie sur l’exhaustivité ou la cohérence des choix donnés. Le programme switch (animal) { case FLEUR: promener; break; default: carresser} se révélera aberrant à l’exécution mais il est accepté par le logiciel chargé d’en permettre l’exécution : l’interpréteur ou le compilateur. De même, réserver un bloc de mémoire est primitif. L’accès aux champs d’un bloc dans les langages impératifs n’a par contre aucune garantie. Rien n’empèche donc de lire une mauvaise zone de mémoire. Ces problèmes sont pris en charge par les disciplines de typage. Types riches Les systèmes de type qui permettent le plus de contrôle sur les programmes autorisent les types à dépendre de valeurs. Ce gain entraîne deux complications : l’apparition d’annotation de type dans les termes et l’apparition de calculs dans les types (l’impossibilité de ne considérer que l’égalité syntaxique de types). Le modèle où l’utilisateur donne tout d’abord intégralement un programme ou une preuve, puis la machine le/la vérie dans un second temps n’est plus satisfaisant. Des annotations sont fastidieuses à écrire alors qu’il est possible d’écrire une fois pour toutes un programme permettant à l’ordinateur de les deviner. De longs calculs que l’utilisateur ne veut pas faire de tête sont parfois nécessaire pour connaître le type que doit avoir un terme. La machine et son utilisateur doivent interagir an de construire et vérier incrémentalement les termes. Les assistants de preuve sont des logiciels permettant de construire interactivement preuves ou programmes. Ce domaine de recherche prolique a généré de nombreuses tentatives aux objectifs multiples. Prouver des théorèmes avec des programmes simplement typés est par exemple permis par Isabelle [54], HOL-light [27] ou ACL2 [32]. On retrouve également des systèmes où la programmation peut être aussi dépendante que la preuve, par exemple Lego [51], Matita [1] 13Introduction ou Coq. Cayenne [3] puis Epigram [39] et Agda [14] orent par exemple des systèmes tournés en premier lieu vers la programmation. Twelf [49] (ou Dedukti [13]) tentent d’extraire l’universalité des systèmes logiques an de générer d’autres systèmes. Ces systèmes orent à l’utilisateur un langage de surface qui lui évite d’écrire exhaustivement les termes. L’interactivité minimale est une présentation par la machine du type du terme attendu en un point donné. Le choix de la forme à présenter est cruciale pour la compréhension humaine. Utilisation des données inductives Dans la diérentiation du langage de surface et de celui sur laquelle s’appuie la logique, ce manuscrit distingue des concepts qui sont confondus dans la littérature. Nous employerons des mots synonymes dans des sens distincts car notre propos est précisément de montrer les distinctions et les passerelles des uns aux autres. Intuitivement et en anticipant légèrement sur la suite qui dénit plus formellement chacun des termes, nous distinguons : — l’analyse de cas élémentaire, cette réécriture du principe d’élimination d’un inductif qui donne le comportement pour chacun des constructeurs et que l’on peut qualier de ltrage atomique. — le typage de l’analyse de cas, justement par étude de cas, qui assure que pour chacun des constructeurs, une réponse bien typée est apportée. Cette primitive est identique pour tous les éléments d’un type inductif. — le ltrage complexe, qui correspond au ltrage généralisé, celui que l’on retrouve dans les langages fonctionnels. Son exécution nécessite alors une phase de compilation vers une forme plus élémentaire. — et le typage par analyse de couverture, celui qui travaille sur une instance du type inductif spéciquement et permet de typer un ltrage (généralisé) directement. Dans le λ-calcul simplement typé ou paramétrique, les deux typages sont équivalents car tous les constructeurs ont le même type. Il n’y a donc pas réellement besoin de s’attarder sur la version élémentaire de l’opération qui n’est qu’un point de passage au cours de la compilation. Avec des types dépendants, la confusion a perduré alors que le ltrage (l’opération non atomique) n’est pas typable directement dans un système comme le notre qui n’a à disposition qu’un principe d’élimination générique. Qui plus est, l’opération complexe considérée primitive apporte avec elle un axiome supplémentaire (voir 1.7). Ce manuscrit parlera donc d’analyse de cas (élémentaire) et de ltrage (généralisé) en omettant les qualicatifs. Sa première contribution originale est de proposer une nouvelle compilation du second dans le premier. Cette première partie du manuscrit est décomposée en trois chapitres. Dans un premier temps, l’algorithme pour atomiser un ltrage complexe sans considération de typage est rappelé. Dans un deuxième temps, le système de typage direct du ltrage complexe tel qu’imaginé par Coquand est décrit. Nous présenterons le plongement que McBride a proposé dans les CCI en utilisant un axiome supplémentaire. Le chapitre 4 de ce manuscrit décrit une com- 14Réduction des points xes pilation d’un sous-ensemble signicatif des ltrages dans le CCI pur. C’est la continuité du travail réalisé par Herbelin et Cornes [18]. Réduction des points fixes Au lieu de dénir les récurseurs des types inductifs primitivement, un mécanisme géné- rique de point xe est proposé. Bien sûr, il faut s’assurer que les points xes ne peuvent pas produire de calculs innis. Avec un véricateur de terminaison, cette formulation est équivalente aux principes de récurrence [23]. Ces points xes sont dénissables par le biais de constantes globales autorisées à s’appeler elles-mêmes ou par des constructions locales aux systèmes. La seconde contribution originale de ce manuscrit est de simuler au niveau de l’utilisateur le premier système dans le second. La description de se mécanisme constitue le chapitre 5. Le véricateur de terminaison doit pouvoir interagir au mieux avec la volonté de l’utilisateur. Par exemple, il doit permettre la réutilisation de code. Il doit aussi ne pas être perturbé par les constructions dont le système a besoin pour assurer le typage du terme. La troisième contribution originale de ce manuscrit est un algorithme présenté chapitre 6 qui va dans ce sens. Il se base sur un critère syntaxique de décroissance structurelle. 151 Un langage fonctionnel avec types riches Le langage formel utilisé dans ce manuscrit est un λ-calcul à la Church avec des types algébriques et des constantes globales écrit en déduction naturelle. Il va être décrit progressivement dans ce chapitre. 1.1 Conventions d’écriture Des listes sont utilisées tout au long de ce manuscrit. L’écriture adoptée pour représenter la liste de n "x" est x1 · · · xn. Par convention, l’indice s dans x1 · · · xs est utilisé quand le nombre d’éléments n’importe pas. Les déclarations sont notées (x : T) où T est le type de la variable x. Les listes de déclarations (x : X) (y : Y) (z : Z) . . . dans lesquels x apparaît dans Y, x et y apparaissent dans Z, . . . seront intensivement utilisées. Elles sont appelées des télescopes et disposent d’une notation spécique : −−−−−−→ (ai : Ai ) désigne (a1 : A1) · · · (ai : Ai ). Remarque Dans l’assistant de preuve Coq, des dénitions (let z : Z := t in u) peuvent entrecroiser des déclarations au sein des télescopes pour obtenir (x : X) (y : Y) (z : Z := t) . . .. Il est néanmoins toujours possible de remplacer les variables dénies par leur dénition et de traiter des listes de déclarations uniquement. Ceci simplie la présentation. Le langage déni ici se traduit symbole pour symbole en une structure de données utilisables en pratique pour une implantation 1 , mis à part la représentation des variables. Une machine utilise des indices de Bruijn pour avoir une représentation canonique des variables, ce qui évite les problèmes de capture. Ce manuscrit utilise par souci de lisibilité des variables nommées en respectant les conventions usuelles. La convention de Barendregt évite les problèmes de capture en imposant des noms de variable tous distincts et l’α-équivalence identie les termes égaux à renommage des variables liées près. La syntaxe utilisée est une réminiscence de celle des versions 8 de Coq. Lors de dénitions abstraites, les couleurs et les noms tenteront de faciliter la lecture. Il sera par exemple question de termes t, de types T, de constantes globales c et de variables x. 1. Elle est exactement déduite de la structure Constr.t du code de Coq v8.5. 171 Un langage fonctionnel avec types riches 1.2 Le cœur fonctionnel 1.2.1 Syntaxe Le λ-calcul est un modèle de calcul qui permet de manipuler aisément des lieurs. Tous les programmes dans ce modèle sont construits à partir de fonctions. Le mot terme est communément employé pour désigner un de ces programmes. Il existe plusieurs formulations du λ-calcul. Ce manuscrit utilise une variante typée : le λ- calcul à la Church. Le but du typage est ici d’interdire les calculs innis. Certaines annotations de type sont explicites an que le typage reste décidable malgré des types très expressifs. Stefano Berardi et Jan Terlouw ont proposé un cadre très générique pour étudier les systèmes de type : les systèmes de types purs. Ce cadre est une généralisation du λ-cube de Barendregt ([4]) où chaque dimension représente une possibilité de dépendance en plus et chaque sommet un système de type connu. Le système de type utilisé ici est le sommet du λ-cube. Termes et types partagent la même syntaxe an de dépendre les uns des autres. Il a été introduit par Thierry Coquand [16] sous le nom de calcul des constructions. Sa syntaxe est donnée gure 1.1 u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type Figure 1.1 – Grammaire du cœur fonctionnel (CoC) L’abstraction de la variable x de type T dans le terme t s’écrit λ(x : T) ⇒ t. Par souci de concision, λ(x : X) ⇒ λ(y : Y) ⇒ t est noté λ(x : X) (y : Y) ⇒ t et λ(x : X) (y : X) ⇒ t est noté λ(x y : X) ⇒ t. L’application du terme u au terme t est noté t u sans symbole explicite. Elle est conventionnellement associative à gauche. Au niveau des types, le produit jouit des même facilités d’écriture que l’abstraction. Le terme ∀(x y : S) (z : T), s désigne ∀(x : S), ∀(y : S), ∀(z : T), s. Deux constantes, les sortes Set et Type sont aussi données. Le caractère _ est utilisé pour désigner une variable liée qui n’apparaît pas dans le corps du lieur. Ainsi dans le cas d’une abstraction sur une variable non utilisée, on écrit λ(_ : T) ⇒ t. Dans le cas du produit, A → B est une notation pour ∀(_ : A), B. 1.2.2 Evaluation Le calcul intervient lorsqu’un argument est appliqué à une abstraction. Une telle situation est appelée un rédex. Le terme se réduit alors vers le corps de la fonction dans lequel l’argument remplace la variable de l’abstraction. Cette opération s’appelle une β-contraction et se note formellement (λ(x : T) ⇒ t) u 7→β t[u/x] La notation t[u/x] désigne la substitution de la variable x par le terme u dans le terme t. 181.3 Déclarations globales La clôture par congruence 2 , réexivité et transitivité de cette réécriture est appelée réduction. Dans la suite, 7→β ferra référence à la réduction. Deux termes t et t’ sont convertibles (noté t ≡ t’) s’ils se réduisent sur un même terme : t 7→β v et t’ 7→β v. L’ordre dans lequel sont réalisées les réécritures n’a pas d’incidence sur la convertibilité. La réduction est conuante : quelle que soit la manière dont les réécritures sont réalisées à partir d’un terme, les termes obtenus restent toujours convertibles. En dénissant une réduction parallèle qui réalise la réécriture sur toutes les partie du terme en une seule étape, on obtient une réduction que l’on peut simuler à l’aide des règles dénies au-dessus. Cette réduction parallèle réduit les deux termes issus d’une paire critique sur le même terme en une étape (propriété du diamant). Les stratégies de réduction (discutées chapitre 5) n’auront donc pas d’eet sur l’expressivité. L’autre point important de la réduction est sa terminaison. Une valeur ou forme normale est un terme sur lequel aucune réécriture β n’est applicable sur aucune partie. Il est indispensable que tous les termes du langage se réduisent sur une valeur (unique par conséquence de la conuence). Le typage l’impose. La preuve passe par la construction d’un modèle et a fait en particulier l’objet de travaux par Coquand [16], Werner - Miquel [42], Lee [35], Barras [5], . . . 1.2.3 Typage Le système de type du calcul des constructions est présenté gure 1.2. La sorte s désigne indiéremment Set ou Type. Il est décrit sous la forme de jugements qui donne le type d’un terme à partir du type des variables apparaissant dans ce terme. Le type des variables est stocké dans un environnement (conventionnement nommé Γ) qui est soit vide (∅) soit composé de la déclaration de la variable x de type T suivi du sous contexte Γ (Γ, (x : T)). 1.3 Déclarations globales 1.3.1 Syntaxe L’utilisateur n’écrit pas un terme monolithique mais une succession de dénitions globales notées (c : T := t) qui forment un environnement ∆. Par réminiscence de la syntaxe de Coq, la syntaxe pour dénir la constante c dans les exemples de ce manuscrit est Definition c : T := t. Il est aussi possible de déclarer des axiomes. Ce sont des constantes sans valeur notée (x : T). Pour éviter les répétitions, Definition c : ∀(x : S), T := λ(x : S) ⇒ t. peut être écrit Definition c (x : S) : T := t. 2. Par congruence, nous entendons les règles de la forme t 7→β t’ et T 7→β T’ implique λ(x : T) ⇒ t 7→β λ(x : T’) ⇒ t’. 191 Un langage fonctionnel avec types riches Γ ⊢ t ∈ T Γ, (x : T) ⊢ x ∈ T Γ ⊢ S ∈ s Γ ⊢ y ∈ T Γ, (x : S) ⊢ y ∈ T Γ, (x : S) ⊢ t ∈ T Γ ⊢ ∀(x : S), T ∈ s Γ ⊢ λ(x : S) ⇒ t ∈ ∀(x : S), T Γ ⊢ Set ∈ Type Γ ⊢ t ∈ ∀(x : S),T Γ ⊢ u ∈ S T[u/x] ≡ T’ Γ ⊢ T’ ∈ s Γ ⊢ t u ∈ T’ Γ ⊢ S ∈ Set Γ, (x : S) ⊢ T ∈ Set Γ ⊢ ∀(x : S), T ∈ Set Γ ⊢ S ∈ s Γ, (x : S) ⊢ T ∈ Type Γ ⊢ ∀(x : S), T ∈ Type Figure 1.2 – Typage du calcul des constructions Les termes peuvent faire référence à des constantes globales précédemment dénies. Une constante est un constructeur de terme (gure 1.3). u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type | c Figure 1.3 – Grammaire de CoC avec dénition 1.3.2 Evaluation Au cours d’un calcul, une constante est remplacée par le corps de sa dénition donnée par l’environnement global (communément appelé ∆). Cette opération est appelée δ-expansion et se note : ∆, (c : T := t), ∆’ ⊢ c 7→δ t La réduction intègre maintenant cette règle de réécriture et est notée ∆ ⊢ 7→βδ . La conuence reste valable. La réduction parallèle conserve la propriété du diamant. Le dépliage de constante n’a pas d’incidence sur la terminaison. 1.3.3 Typage Le jugement de typage est maintenant paramétré par l’environnement des constantes dé- nies. Le type d’une constante est donné par cet environnement. ∆, (c : T := t), ∆’ ;Γ ⊢ c ∈ T ∆, (c : T), ∆’ ;Γ ⊢ c ∈ T 201.4 Types de données algébriques strictement positifs . L’environnement global doit être bien formé, c’est-à-dire vide ou obtenu par ajout de constantes aux noms frais et bien typées. ∆ ⊣ ∅ ⊣ ∆ ⊣ ∆ ;∅ ⊢ T ∈ s ∆ ;∅ ⊢ t ∈ T c < ∆ ∆, (c : T := t) ⊣ ∆ ⊣ ∆ ;∅ ⊢ T ∈ s c < ∆ ∆, (c : T) ⊣ Figure 1.4 – Environnements bien formés 1.4 Types de données algébriques strictement positifs 1.4.1 Syntaxe Le langage considéré jusqu’à maintenant permet de dénir des structures de données par codage imprédicatif. Néanmoins, comme suggéré dans l’introduction, manipuler des données de manière primitive est plus naturel. Les constructions utilisées pour rendre cela possible sont les structures inductives. L’ajout des types inductifs primitifs décrit ci dessous donne le Calcul des Constructions Inductives dû à Christine Paulin et Thierry Coquand [17]. Les structures de données sont dénies uniquement au sein de l’environnement global. La syntaxe des contextes globaux est enrichie de l’entrée     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     . Les exemples du manuscrit ainsi que la syntaxe de Coq v8 utilisent une syntaxe diérente plus lisible où le bloc ci-dessus est écrit Inductive I −−−−−−−−→ (am : Am): T := |(C1 : T1) · · · |(Ci : Ti ). La gure 1.5 montre une déclarations d’inductifs écrite en forme normale an d’introduire la terminologie employée pour les manipuler. Inductive I −−−−−−−−→ (am : Am) : ∀ −−−−−−−→ (bn : Bn), Set := | C1 : ∀ −−−−−−−−→ (x1s : T1s ), I a1 · · · am t11 · · · t1n · · · | Ci : ∀ −−−−−−−→ (xis : Tis ), I a1 · · · am ti1 · · · tin. Figure 1.5 – Squelette d’un inductif du CCI C1 · · · Cs sont les constructeurs du type inductif I. 211 Un langage fonctionnel avec types riches a1 · · · am sont les paramètres de l’inductif. b1 · · · bn forment la signature d’index de l’inductif. x1 · · · xs sont les arguments du constructeur C. t1 · · · tn sont les index du constructeur C. Par construction, — Le type des constructeurs doit être en forme constructeur par rapport à I. La syntaxe des forme constructeur par rapport à X est Co : := X t1 · · · ts | ∀(x : T), Co avec T = X u1 · · · us ou X n’apparaît dans T et X n’apparaît pas dans les termes t et u1 · · · us . L’occurrence nale de X est la conclusion du type du constructeur. — Les paramètres sont des constantes d’une dénition. Il doivent rester identiques dans la conclusion du type des constructeurs et dans la dénition de l’inductif. Un exemple d’inductif est la dénition de l’égalité donnée gure 1.6. Inductive eq (A : Set) (a : A) : A → Set := | eq_re :eq A a a. Lorsque l’on écrit eq T t u, la valeur du type T est imposée par les termes t et u. Par consé- quent, lorsque le type T n’est pas le point clé de l’explication, eq T t u est noté par la suite t = u. Figure 1.6 – Dénition de l’égalité Une fois dénis, inductifs et constructeurs sont utilisables dans les termes comme des constantes. Les constructeurs ont un statut particulier. Deux constructeurs sont prouvablement distincts et l’ensemble des habitants d’un type inductif est statiquement connu par l’environnement global. Grâce à cela, Christine Paulin a déni une règle d’élimination des données par analyse de cas. La syntaxe employée est donnée gure 1.7. case t predicate P of | br1 · · · | bri end Figure 1.7 – Analyse par cas sur t de type I u1 · · · um v1 · · · vn Le terme t inspecté par l’analyse de cas est appelé terme inspecté. L’annotation de typage P est appelée clause de retour ou prédicat de retour. Le terme brj appelé branche du constructeur Cj correspond au comportement du programme si le terme inspecté débute par le j-ième constructeur. An de fournir des noms pour représenter les arguments du constructeurs, une branche débute par autant d’abstractions que le constructeur lui correspondant a d’arguments. Le langage Gallina fournit une primitive plus haut niveau qui sera l’objet d’étude des chapitres suivants. Néanmoins, l’analyse de cas écrite en forme dite η-longue (où il y a un λ pour toutes les abstractions) s’injecte dans la syntaxe de Gallina en écrivant Terme de Constr.t case t predicate λ −−−−−−−→ (bn : B’n) (x : I u1 · · · um b1 · · · bn) ⇒ T of |λ −−−−−−−−−→ (x1s : T’1s ) ⇒ br1 · · · |λ −−−−−−−−→ (xis : T’is ) ⇒ bri end où T’jk := Tjk [u1 · · · um/a1 · · · am] et B’k := Bk [u1 · · · um/a1 · · · am] 221.4 Types de données algébriques strictement positifs Terme de Gallina match t as x in I b1 · · · bn return T with | C1 x11 · · · x1s => br1 · · · | Ci xi1 · · · xis => bri end L’analyse de cas n’est pas susante pour dénir des fonctions par analyse de cas récursives. Une notion de point xe est nécessaire. La syntaxe employée est fixi (f : T := t) où f est une variable libre dans t. L’indice i est appelé l’argument récursif du point xe. Il désigne le numéro de l’argument à inspecter pour savoir s’il faut déplier le point xe (comme expliqué section suivante). Fixpoint f (x_1 : S_1) · · · (x_i : S_i) : T := t. est un alias plus concis pour Definition f : ∀(x_1 : S_1) · · · (x_i : S_i), T := fixi (f : ∀(x_1 : S_1) · · · (x_i : S_i), T := λ(x_1 : S_1) · · · (x_i : S_i) ⇒t). En résumé, la grammaire exhaustive des termes est écrite gure 1.8. Elle est nommée minicalcul des constructions inductives car le calcul des constructions inductives à proprement parler inclus par exemple une hiérarchie innie de sortes avec sous-typage ou des structures de données coinductives qui sont hors du champ de l’étude réalisée dans ce manuscrit. u, t, S, T : := x | c | ∀(x : S), T | s | λ(x : T) ⇒ t | t u | C | I | case t predicate P of t1 · · · ts end | fixi (f : T := t) Figure 1.8 – Grammaire des termes utilisés (mini-CCI) 1.4.2 Evaluation Une analyse de cas dont le terme inspecté est le constructeur Cj appliqué à des arguments u1 · · · us se réduit vers la branche de Cj appliquée aux termes u1 · · · us . C’est la ι-contraction. ∆ ⊢ case Ci u1 · · · un predicate T of |t1 · · · |tm end 7→ι ti u1 · · · un La dernière règle est la ϕ-expansion. Un point xe se déplie si son argument récursif commence par un constructeur. Ce conditionnement du dépliage à la forme de l’un des arguments est indispensable. Remplacer systématique la variable représentant le point xe par le corps du point xe amène des dépliages innis lorsque la règle est appliquée sur des sous-termes ayant des variables libres. ∆ ⊢ (fixi (f : T := t)) u1 · · · ui-1 (C v1 · · · vn) 7→ϕ t[fixi (f : T := t)/f] u1 · · · ui-1 (C v1 · · · vn) La réduction enrichie de ces deux règles est notée ∆ ⊢ 7→βιϕδ . Sa conuence est toujours prouvable grâce à une réduction parallèle vériant la propriété du diamant. La terminaison demande la construction de nouveaux modèles qui furent par exemple l’objet du travail de Coquand - Paulin [46], Luo [37], Barras [6], . . . 231 Un langage fonctionnel avec types riches 1.4.3 Typage Un type algébrique I est un inductif si les occurrences de I dans les télescopes des arguments des constructeurs sont en positions strictement positives. Elles ne doivent jamais apparaître à gauche d’un produit dans un type. Pour le reste, on étend la règle de bonne formation des environnements globaux (gure 1.4) par la déclaration d’un type inductif : ∆ ⊣ ∆ ;∅ ⊢ ∀ −−−−−−−−→ (am : Am), T ∈ Type ∆ ;(I : ∀ −−−−−−−−→ (am : Am), T), ∅ ⊢ ∀ −−−−−−−−→ (am : Am), T1 ∈ Set · · · ∆ ;(I : ∀ −−−−−−−−→ (am : Am), T), ∅ ⊢ ∀ −−−−−−−−→ (am : Am), Ti ∈ Set ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     ⊣ Dans notre restriction mini-CCI, le type de l’inductif (Type) et de ses constructeurs (Set) sont xes alors qu’en Coq ils pourraient varier. L’extension du typage des termes est donné gure 1.9. Une fois un inductif déclaré dans l’environnement global, son type et le type de ses constructeurs sont directement donnés par cet environnement. Une analyse de cas est une écriture particulière du schéma d’élimination d’un inductif. ( Ce schéma correspond à l’encodage imprédicatif d’un inductif [47]). Lors d’une élimination dépendante, chaque branche attend un type diérent. Puisque les types dépendent des termes, le type d’une branche dépend du constructeur auquel il correspond. Le type global de la réponse renvoyée par l’analyse de cas est lui fonction du terme inspecté. Le typage d’un point xe n’est pas surprenant. L’originalité de la règle présentée est la condition Decr(∆,t,f,i). Il correspond à une condition de bonne formation appelée condition de garde qui interdit les points xes divergents. Son étude précise est l’objet du chapitre 6. Son principe général est de garantir que "le nombre de constructeurs en tête de l’argument récursif" est une grandeur strictement décroissante. Cette propriété garantit que seul un nombre ni d’appels récursifs peut avoir lieu si l’argument est un terme clos. 1.5 Des structures de données d’exemple Ce manuscrit réalise pour chaque partie une présentation incrémentale informelle des problématiques avant d’exposer la réponse formelle apportée. En plus des structures de données ayant des rôles très particuliers en théorie des types comme l’égalité déjà présentée gure 1.6, ces descriptions pédagogiques s’appuient sur des structures de données courantes. En premier lieu vient la représentation unaire des entiers naturels (gure 1.10) qui fournit une structure de donnée récursive élémentaire. 241.5 Des structures de données d’exemple ∆ ;Γ ⊢ t ∈ T ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     , ∆ ′ ;Γ ⊢ I ∈ ∀ −−−−−−−−→ (am : Am), T ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     , ∆ ′ ;Γ ⊢ Cj ∈ ∀ −−−−−−−−→ (am : Am), Tj ∆ ;Γ ⊢ z ∈ I u1 · · · um v1 · · · vn ∆ := ∆ ′ ,     (C1 : ∀ −−−−−−−→ (x1 : T1), I a1 · · · am t11 · · · t1n ) · · · (Ci : ∀ −−−−−−→ (xi : Ti ), I a1 · · · am ti1 · · · tin) @ −−−−−−−−→ (am : Am) → I : ∀ −−−−−−−→ (bn : Bn), Set     , ∆ ′′ B ′ k := Bk [u1 · · · um/a1 · · · am] T ′ jk := Tjk [u1 · · · um/a1 · · · am] ∆ ;Γ ⊢ P ∈ ∀ −−−−−−−→ (bn : B ′ n) (x : I u1 · · · um b1 · · · bn), s ∆ ;Γ ⊢ brk ∈ ∀ −−−−−−−→ (xk : T ′ k ), P tk 1 · · · tkn (Ck u1 · · · um xk1 · · · xks ) ∆ ;Γ ⊢ case z predicate P of | br1 · · · | bri end ∈ P v1 · · · vn z ∆ ;Γ ⊢ T ∈ s ∆ ;Γ, (f : T) ⊢ t ∈ T Decr(∆,t,f,i) ∆ ;Γ ⊢ fixi (f : T := t) ∈ T Figure 1.9 – Typage des inductifs du mini-calcul des constructions inductives 251 Un langage fonctionnel avec types riches Inductive nat : Set := | O :nat | S :nat → nat. Figure 1.10 – Les entiers naturels unaires (zéro ou le successeur d’un entier) Les listes simplement chaînées (gure 1.11) prennent un paramètre de type qui indique la nature des éléments qu’elles contiennent. Néanmoins, tous les constructeurs ont le même type. Si t est une liste d’entier, t peut aussi bien être nil que cons a b. Les deux constructeurs créent des listes d’entiers. Nous insistons ici car cette propriété n’est pas vrai pour les familles inductive ayant un index. Inductive list (A : Set) : Set := | nil :list A | cons :∀(t : A) (q : list A), list A. Figure 1.11 – Type avec paramètre : Les listes simplement chaînées Le prédicat de parité d’un entier naturel (gure 1.12) fournit une structure de données avec un index donc réellement dépendant. Il sera l’exemple canonique pour faire apparaître des branches impossibles. Inductive even : nat → Set := | even_O :even O | even_SS :∀(n : nat) (_ : even n), even (S (S n)). Figure 1.12 – Prédicat de parité sur les entiers Des structures plus compliquées ou ad hoc serviront ponctuellement par la suite. 1.6 Digression sur la représentation des constructeurs et des branches Des abstractions sont utilisées pour représenter les arguments du constructeur dans les branches d’une analyse de cas. Les constructeurs sont vus comme des constantes dont le type est fonctionnel. Ceci n’est pas conventionnel en programmation. Les langages qui ont le soucis de s’exécuter vite voient un constructeur comme un bloc et ces arguments comme des champs de ce bloc. L’analyse de cas n’introduit qu’une variable : celle qui représente le terme inspecté. Par contre, les branches disposent d’une primitive supplémentaire field i t qui donne le ième champs de t (à supposer qu’il s’agisse bien d’un bloc). La première solution simplie l’étude théorique et en particulier l’écriture de la règle de typage, tandis que l’intérêt intrinsèque de la seconde solution est le partage de code. Par exemple, si un utilisateur dénit la structure de donnée Inductive I : Set := | A :I → I | B :I | C :nat → I. puis écrit (en anticipant très légèrement la syntaxe présentée chapitre 2) 261.7 Expressivité de l’analyse de cas Definition destA (x : I) : I := match x with | A y => y | _ => x end. Les branches de B et de C devraient être identiques et donc pouvoir pointer vers le même code. En se souvenant que la machine utilise des indices de de Bruijn pour représenter les variables, c’est eectivement le cas avec λI . case 1 predicate λI . I of | field 1 1 | 1 | 1 end mais pas dans le formalisme du calcul des constructions inductives qui donne λI . case 1 predicate λI . I of | λI . 1 | 1 | λnat. 2 end Il est par ailleurs notable qu’une primitive de projection allégerait aussi les termes issus de l’utilisation d’inductifs à un seul constructeur. Il est bien sûr possible de dénir les projections de tels objets (par exemple proj1 nat even x). Néanmoins, la projection dénie comme une constante prend en argument les arguments de l’inductif (dans l’exemple nat et even alors qu’une projection primitive (ici field 1 x) n’en a pas besoin. Elle peut être typée directement au moyen de la dénition de l’inductif au sein de l’environnement global. 1.7 Expressivité de l’analyse de cas La clause de retour est explicite, elle peut donc être arbitrairement complexe. Elle est la clé de la grande expressivité de l’élimination dépendante. Une clause de retour débute par des abstractions représentant des généralisations des index du terme éliminé ainsi que le terme éliminé. Par exemple, supposons avoir un inductif K qui a un argument et au moins un constructeur H de type ∀(z : S), K z, la clause de retour pour un terme inspecté u de type K t a la forme λ(x : S) (y : K x) ⇒ T. Rien n’oblige le type attendu en retour à utiliser ces abstractions. Dans l’exemple, cela donnerait λ(x : S) (y : K x) ⇒ P avec t et u apparaissant dans P mais ni x ni y. Néanmoins, le type demandé dans chacune des branches est alors constant (exactement P) et décorrelé des index du constructeur de la branche (z dans le cas de H). On ne peut plus raner le type grâce aux informations fournies par le constructeur. De plus, les arguments du constructeur sont le plus souvent inutilisables car de types incompatibles. Dans le cas de la branche de H, le type attendu est ∀(z : S), (λ(x : S) (y : K x) ⇒ P) z (H z). Puisque x et y ne sont pas libres dans P, ce type ce réduit à ∀(z : S), P où z n’est pas libre dans P. Il est donc peu crédible de pouvoir utiliser z pour fournir du P. Pour rendre l’élimination utile, la clause de retour doit utiliser au maximum ces généralisations. Des contraintes de typage que nous allons expliciter limitent cette possibilité. Le type des abstractions découle uniquement de la dénition de l’inductif et non pas du type, plus précis, du terme éliminé. Or, généraliser les termes signie nécessairement géné- raliser parallèlement les types. Il existe alors des situations où il est impossible d’écrire un terme de type T k par analyse sur (k : K v) car il n’est pas possible de trouver (P : ∀(a : A) (b : K a), Set) tel que P v k ≡ T k. Au lieu d’une quantication universelle sur A, il serait souhaitable de pouvoir exprimer une propriété existentielle disant a doit être v. Comme si une analyse de cas dépendante demandait de pouvoir écrire en ce qui concerne des types des motifs où des égalités de variables sont exprimables. La section 3.2 revient sur cette considération. 271 Un langage fonctionnel avec types riches Une perte d’expressivité découle de cette contrainte. L’égalité de deux termes peut être exprimée comme un type de donnée du langage au moyen de la dénition gure 1.6. Elle est ainsi manipulable directement au sein du langage. Il est cependant impossible de dénir un terme ayant le type de la gure 1.13 par analyse sur e. La clause de retour qu’il faudrait : ∀(b : A) (e’ : eq A a b), eq (eq A a b) e’ (eq_re A a) est mal typée car eq_re A a a le type eq A a a et non pas eq A a b (le type de e’). Axiom UIP_re : ∀(A : Set) (a : A) (e : eq A a a), eq (eq A a a) e eq_re. Figure 1.13 – Unicité des preuves d’égalité Cet exemple n’est pas articiel et limite la programmation dépendante. Dans [28], Thomas Streicher et Martin Hofmann ont nommé K une formulation équivalente (gure 1.14) de cet axiome. Ils ont montré que K est indépendant du CCI. Il est en eet admissible mais il existe des modèles qui ne le réalisent pas. Axiom StreitherK (U : Set) : ∀(x : U) (P : x = x → Prop), P (eq_re x) → ∀(p : x = x), P p. Figure 1.14 – Axiome K Puisqu’il est compatible avec le calcul des constructions inductives, K peut être supposé. Un axiome étant une hypothèse globale qui n’a pas de dénition, il n’a jamais la possibilité de se réduire. Calculatoirement, un tel axiome est donc extrêmement préjudiciable à moins d’amener avec lui une forme faible d’irrelevance des preuves. En eet, la réduction peut être modiée pour ignorer la preuve d’égalité t = u qui bloque une réécriture. Si u et tsont convertibles, la réécriture est eacée. De plus, la section 3.2 montre que K est supposé lorsque l’élimination des inductifs est vu comme une couverture de tous les cas possibles. Il a longtemps été considéré comme regrettable qu’introduire K de manière externe au CCI bloque toutes les réductions de termes. Une règle d’élimination par cas des inductifs vériant K a donc été proposée dans [7]. L’apparition de la théorie homotopique des types [52] dans lesquels K n’est pas valable mais qui présente d’autres intérêts tempère ce point de vue et justie le travail présenté chapitre 4. 282 Le filtrage en programmation fonctionnelle Dans ce manuscrit, nous cherchons à exhiber que la présence de types dépendant rend profondément diérents l’analyse de cas élémentaire telle qu’elle est dénie dans le CCI et le ltrage généralisé tel qu’il apparaît dans les langages fonctionnels depuis HOPE (le premier langage avec des types algébriques). L’amalgame entre les deux notions est entretenu car Coq ore à l’utilisateur une primitive de ltrage généralisé. En réalité, ce ltrage est compilé par le système et cette première partie explique ce procédé de compilation. Dans les langages avec types algébriques paramétriques (comme par exemple Haskell, OCaml ou SML), il n’y pas besoin d’isoler l’analyse de cas élémentaire du point de vue du typage. Il est néanmoins nécessaire dans le processus de compilation vers un langage machine d’atomiser les tests. Ce travail a été décrit une première fois par Augustsson [2] puis étudié et optimisé de diérentes manières, par exemple, par Le Fessant, Maranget[34], Wadler[30, Chapitre 5]. Ce chapitre décrit ces travaux, vu que la structure intermédiaire qu’ils introduisent pour leur compilation est la structure intermédiaire que nous utilisons pour la nôtre. La compilation proposée par la littérature est optimisante. Des heuristiques permettent de réduire le nombre d’analyse des cas à réaliser pour simuler un ltrage. Ce manuscrit ne discute pas d’optimisation et se contente de décrire la compilation naïve. Néanmoins, il dénit la construction optimisante de la structure intermédiaire car il peut ainsi proter gratuitement du travail sur les optimisations fait dans la littérature. ltrage arbre de décision sauts conditionnels analyses de cas + encodage par égalités Chap 3 analyses de cas + encodage structurel Chap 4 Chap 2 Figure 2.1 – Plan de la première partie du manuscrit Les chapitres suivants expliquent les constructions nécessaire pour aller de la structure intermédiaire qui décrit les choix élémentaires à des analyses de cas du CCI bien typées. 292 Le ltrage en programmation fonctionnelle Ces chapitres sont successivement la description de la littérature et l’algorithme original que propose ce manuscrit. Ces chapitres s’occupent seulement de problèmes de types, mais ne reviendront plus sur l’atomisation qui est l’objet de l’étude qui suit. 2.1 Principe du filtrage Le ltrage (généralisé) n’analyse pas un seul terme mais une liste de termes en parallèle. Pour choisir le comportement à adopter, il peut inspecter les arguments d’un constructeur puis les arguments d’un constructeur argument d’un constructeur et ainsi de suite. Il n’est pas limité à discriminer selon le premier constructeur en tête du terme. Le ltrage permet de factoriser le comportement à adopter quand il est identique dans plusieurs cas, il permet par exemple d’écrire un cas par défaut. Enn, le ltrage permet de nommer des morceaux des termes inspectés an de s’en resservir pour décrire le comportement que la suite du calcul doit avoir. Fixpoint beq_half (m n : nat) : bool := match m, n with | O, O => true | S (S i), S j => beq_half i j | _ , _ => false end. Figure 2.2 – Exemple d’inspection en parallèle et en profondeur : n est il la moitié de m ? Un ltrage est constitué de la liste des termes à inspecter que nous appellerons les termes ltrés et d’une énumération de possibilités qui sont communément appelées les branches. Une branche de ltrage n’est pas composée que d’un terme comme l’est une branche d’analyse de cas. Une branche de ltrage est une paire d’un membre gauche composé d’une liste de motifs et d’un membre droit qui est un terme. Chaque branche a autant de motifs que le ltrage a de termes ltrés. La syntaxe des motifs (gure 2.3) permet d’établir une empreinte pour la tête d’un terme. Si un terme respecte la forme de cette empreinte, il coïncide avec le motif. La sémantique du ltrage est d’exécuter le membre droit de la première branche pour laquelle les membres gauches coïncident avec les termes inspectés en ayant eectué les substitutions nécessaires. Formellement, la sémantique est déni grâce à — Une opération ◦ de composition de « peut être substitution ». L’absence de substitution (⊥) est un élément absorbant. — une opération de substitution généralisée [p ← t] décrite gure 2.4 qui prend en argument un motif p et un terme t et renvoie peut être une substitution ; celle à appliquer si le terme coïncide avec le motif. — une opération ⊕ qui sélectionne le premier succès d’une liste de « peut être ». Elle s’écrit alors match t1 · · · tn with |p11 · · · p1n → u1 · · · |ps1 · · · psn → us end 7→ ⊕i (◦j[pij ← tj])ui . 302.1 Principe du ltrage Exemple Le terme cons O (cons (S (S O)) nil) coïncide avec le motif cons _ (cons (S _)) _ mais pas cons (S (S O)) nil ou cons (S O) (cons O nil) p : := C p1 · · · ps | _ | ( p1 | p2 ) | ( p as x ) Figure 2.3 – Syntaxe des motifs Le motif "_" est appelé joker, n’importe quel terme coïncide avec lui. Un terme coïncide avec le motif C p1 · · · ps si, une fois réduit, il est le constructeur C appliqué à des arguments coïncidant avec les motifs p1 · · · ps . Un terme coïncide avec ( p1 | p2 ) s’il coïncide avec p1 ou avec p2. Enn, un alias ( p as x ) est un lieur. Il associe le nom x au sous-terme coïncidant avec le motif p. Le motif ( _ as x ) est noté par simplicité x. [p ← t] [( p as x ) ← t] def = [t/x] ◦ [p ← t] [_ ← t] def = ∅ [( p | q ) ← t] def = [p ← t] ⊕ [q ← t] [Ci p1 · · · ps ← Ci t1 · · · ts] def = ◦k [pk ← tk ] [Ci p1 · · · ps ← Cj t1 · · · ts] def = ⊥ Figure 2.4 – Substitution généralisée pour un motif Il est notable que les motifs ne peuvent parler que de constructeurs et non pas de n’importe quelle déclaration de l’environnement global. L’avantage de ne traiter que des données à la structure statiquement dénie est de connaître l’espace inspecté. Il est par conséquent possible de vérier la bonne formation des ltrages en contrôlant l’exhaustivité et la non redondance des motifs. Il existe une autre forme de ltrage, non déterministe cette fois, en programmation logique. La problématique est alors diérente et les motifs sont moins contraints. Une branche de ltrage en programmation logique utilise des variables existentielles : "S’ il existe x tel que p(x) = t, exécute u" alors que les variables des motifs de la programmation fonctionnelle sont universelles : "pour tout x tel que p(x) = t, exécute u". Les motifs en programmation logique peuvent être non linéaires : une variable peut apparaître plusieurs fois, signiant que plusieurs parties d’un terme inspecté doivent être identiques. Il n’est alors plus question de savoir si un terme coïncide avec un motif mais de dé- terminer les classes d’équivalence auxquelles appartiennent les variables des motifs au sein des termes. Ce calcul est coûteux. Il repose sur un algorithme d’unication. Ce besoin de propriété existentielle au sein du typage de l’élimination dépendante des données a été exhibée section 1.7. C’est pourquoi cette autre forme de ltrage va apparaître section 3.2. Elle est donc mentionnée ici an de bien la diérencier de notre objet d’étude. 312 Le ltrage en programmation fonctionnelle 2.2 Reconnaitre un motif Au niveau du processeur, l’unique primitive qui permet le branchement est le saut conditionnel. Reconnaître un constructeur modélisé par un entier ne demande qu’une instruction de comparaison. L’analyse de cas se traduit aisément en sauts conditionnels. Reconnaître un motif n’est pas aussi immédiat. Pour exécuter un ltrage, la coïncidence avec un motif doit être décomposée en la vérication d’une succession de contraintes élé- mentaires. Un protocole doit donc être établi an de compiler le ltrage. Cette étape de compilation n’est pas nécessaire uniquement à l’exécution mais sert aussi aux contrôles de bonne formation du ltrage. Avec des types de données paramétriques, tous les motifs et toutes les branches ont le même type. Cette partie du typage est réalisable avant compilation. Par contre, contrôler la bonne formation des motifs consiste aussi à s’assurer que tous les cas possibles ont été traité et qu’il n’y a pas de redondance et donc de branches jamais exécutée. Cela revient à exhiber la complétude et la non surcharge de l’arbre des choix à réaliser pour déterminer la branche à suivre, c’est-à-dire travailler exactement sur la structure intermédiaire de la compilation du ltrage. La littérature propose deux langages intermédiaires pour la compilation : les automates bracktrackant [2, 34] et les arbres de décision [38]. Tous deux utilisent l’analyse de cas comme primitive mais le premier langage maximise la concision du code produit en reposant sur l’usage d’un cas par défaut et d’exceptions alors que le second minimise le nombre de comparaison et s’exprime uniquement par une succession d’analyses de cas telle que présentée section 1.4. A titre d’exemple, le résultat de la compilation de beq_half (gure 2.2) vers un automate backtrackant est donné gure 2.5.1 et vers un arbre de décision gure 2.5.2. Précisément, la syntaxe utilisée est celle du langage intermédiaire de la compilation d’OCaml dlambda. catch (case m of |O: case n of |O: true |_: exit 1 end |S: let k := (eld 1 m) in (case k of |S: case n of |S: beq_half (eld 1 k) (eld 1 n) |_: exit 1 end |_: exit 1 end) end with 1: false) (1) par backtraking automata case m of |O: case n of |O: true |S: false end |S: let k := (eld 1 m) in (case k of |O: false |S: case n of |O: false |S: beq_half (eld 1 k) (eld 1 n) end end) end (2) par arbre de décision Figure 2.5 – Compilation de beq_half Comme elle ne requiert pas d’autres primitives que des analyses de cas, la transformation d’un ltrage vers une succession d’analyses de cas au moyen d’un arbre de décision ouvre la porte au ltrage en calcul des constructions inductives. 322.3 Construire un arbre de décision Avec des types dépendants, chaque branche a un type diérent dépendant du cas considéré. Deux approches existent pour le typage du ltrage. — La première est un typage avant compilation grâce à une nouvelle théorie logique. Cette approche est décrite dans la section 3.1. — La seconde est de s’appuyer sur le typage de l’analyse de cas en CCI après compilation du ltrage vers ces derniers. Il faut alors non seulement trouver un arbre de décision mais aussi ajouter les annotations et les constructions nécessaires an de typer les analyses de cas générées. Ceci revient à trouver un algorithme pour créer des clauses de retour et des termes en tête de branche qui applique les coercions de type nécessaires. Le chapitre 3 décrit un algorithme pour encoder le typage primitif du ltrage que propose la section 3.1. Le chapitre 4 montre une manière alternative et inédite de concevoir des annotations qui ne demandent pas d’étendre la théorie. Ces deux chapitres considéreront qu’un arbre de décision non typé a déjà été construit à partir du ltrage à encoder. La n de ce chapitre se concentre justement sur cette étape ne parlant pas de types et donc pas de dépendance : comment transformer un ltrage en un arbre de décision. 2.3 Construire un arbre de décision 2.3.1 Arbre de décision Formellement, un arbre de décision est un terme dans la grammaire donnée en gure 2.6 agissant sur une pile de termes ltrés. p : := Tail (t) | Leafx : : p | Nodex(p1 · · · ps ) | Swapi j1 ··· j s : : p Figure 2.6 – Grammaire des arbres de décisions Tail (t) représente la n d’un arbre de décision. A condition que la pile des termes à ltrer soit bien vide, t est la réponse apportée. Leafx : : p est une feuille, c’est-à-dire que le terme en tête de pile n’est pas inspecté plus profondément et p indique comment se comporter pour la queue de la pile. La variable x est l’alias du terme ltré dépilé. Nodex(p1 · · · ps ) signie que le terme en tête de pile est inspecté et que le ieme p donne le comportement à suivre s’il s’agit du i e constructeur. Des variables correspondant aux arguments du constructeur sont empilées sur les termes à ltrer dans toutes les branches. Le terme ltré inspecté a pour alias x. Swapi j1 ··· js : : p est une opération d’optimisation. Elle extrude en tête le ième élément de la pile an de lui appliquer le traitement dicté par p. Cette opération n’est pas rigoureusement identique en présence de types dépendants ou non. D’une liste de termes ltrés réordonnable à souhait, nous passons à la manipulation de télescopes de termes, c’est- à-dire de liste ordonnée du point de vue du typage (les premiers termes apparaissent 332 Le ltrage en programmation fonctionnelle dans les types des suivants). Donner la priorité à un terme n’est donc pas uniquement retarder le traitement des autres, c’est aussi annuler le traitement des dépendances du terme choisi. La liste j1 · · · js donne les numéros des éléments de la liste à jeter car ils sont déterminés par l’analyse du terme sélectionné. hσ(Tail (t)) | i = σ(t) σ(Leafx : : p) | t, q = {x := t, σ }(p) | q D σ(Nodex(p1 · · · ps )) | Ci t1 · · · tn, qE = {x := Ci t1 · · · tn, σ }(pi ) | t1 · · · tn, q  σ(Swapi j1 ··· js : : p) | t1 · · · ti , q = σ(p) | ti , tk1 · · · tki’, q avec  tk1 · · · tki’ = {t1 · · · ti } - ( tj1 · · · tj s ) Figure 2.7 – Sémantique des arbres de décisions (σ est une substitution qui donne le terme correspondant à chaque alias) 2.3.2 Mécanique d’atomisation La liste des branches (appelée matrice des clauses) est transformée en un arbre de décision à l’aide d’une fonction qui travaille sur les colonnes de la matrice. motifs branches corps Figure 2.8 – Structure d’une matrice de clauses Les colonnes de la matrice peuvent être considérées comme une pile. Le travail est systé- matiquement eectué sur la première. L’algorithme présenté ici traite ce cas minimal. Optimiser la compilation du ltrage, c’est échanger l’ordre des colonnes an de réduire le nombre d’analyse de cas nécessaires en traitant les colonnes clés d’abord. Cela revient à introduire des constructeurs Swapi j1 ··· js : : p dans l’arbre de décision. L’algorithme minimal est le suivant : Quand la matrice n’a plus de colonne de motifs, il doit y avoir exactement une ligne. Moins révèle un ltrage non exhaustif, plus des motifs redondants. La réponse est alors Tail (t) avec t le terme de cette branche restante. Dans les autres cas, les alias de la première colonne sont uniés par α-renommage, soit x le nom de l’alias commun. ( p0 as x0 ) ( p1 as x1 ) ( p2 as x2 ) p0 p1 p2 [x/x0] [x/x1] [x/x2] 342.3 Construire un arbre de décision Ensuite, les disjonctions de la première colonne sont supprimées en dupliquant la ligne avec pour premier motif les deux cas de la disjonction. ( q1 | q2 ) p1 · · · ps t q1 p1 · · · ps q2 p1 · · · ps t t Enn, si tous les éléments de la première colonne sont des jokers, la réponse est Leafx : : p où p est l’arbre de décision correspondant à la matrice privée de sa première colonne. Sinon, il est temps d’analyser réellement le premier terme ltré. L’arbre de décision débute par Nodex(p1 · · · ps ). Pour obtenir la réponse pi au sous problème associé au constructeur Ci , on utilise une opération S qui renvoie la nouvelle matrice regroupant les motifs à traiter si le premier terme ltré commence par Ci . La fonction S Ci va transformer la première colonne de motifs en k nouvelles colonnes, avec k le nombre d’arguments de Ci . Pour cela, elle parcourt les lignes en regardant le motif de tête. — S’il s’agit du même Ci appliqué aux sous motifs m1 · · · mk , elle ajoute à la réponse une ligne constitué des m1 · · · mk concaténés au reste de la ligne. (Ci m1 · · · mk ) m1 · · · mk — Si le premier motif commence par un autre constructeur Cj , la ligne disparaît. (Cj m’1 · · · m’k’) ∅ — Un joker est transformé en k jokers tout en gardant le reste de la ligne. _ _1 · · · _k Cette procédure est décrite par Luc Maranget dans [38]. L’objet de son article est de réduire la taille de l’arbre de décision en permutant des colonnes. Il décrit des heuristiques de choix de la colonne à casser en priorité qui permettent d’égaler les performances de la compilation par automates backtrackant en utilisant des arbres de décisions. Dans un cadre avec types dépendant, l’étude de la correction et de la pertinence des heuristiques reste à traiter, ainsi que la proposition de nouvelles heuristiques spécialisées. 353 Encodage du filtrage dans l’analyse de cas 3.1 Le filtrage dépendant primitif Il existe des systèmes logiques dans lesquels le ltrage est l’élimination primitive des inductifs. Les langages Agda [45] et Beluga [50] sont basés sur un tel ltrage primitif dont le typage est assuré par analyse de couverture suivant les idées de Thierry Coquand dans [44]. Le principe est de garantir que l’ensemble des motifs membres gauche des branches couvrent l’ensemble des valeurs que peuvent prendre les termes ltrés. Le typage du ltrage par analyse de couverture présuppose trois classes de propriétés sur les constructeurs d’inductifs. discrimination Deux constructeurs syntaxiquement distincts sont nécessairement dié- rents. Par exemple, pour les entiers : ∀(P : Set) (n : nat), S n = O → P inversibilité Deux instances d’un constructeur sont identiques si et seulement si leurs arguments sont identiques. Pour les entiers : ∀(m n : nat), S m = S n → m = n acyclicité L’argument d’un constructeur d’inductif ne peut pas être égal au terme entier. Par exemple, pour les entiers naturels, ∀(P : Set) (n : nat), S n = n → P, ce qui est vrai également pour tous les S (S . . . (S n)) = n. Lors du typage d’une branche, la correspondance entre les index des termes ltrés et ceux du motif considéré ainsi qu’entre les termes ltrés et le cas considéré se ramène à un problème d’unication ayant pour règles les énoncés ci-dessus. Si t de type even u est éliminé, dans la branche de even_SS x y de type even (S (S x)), les problèmes d’unication sont u ? = (S (S x)) au niveau des index et t ? = (even_SS x y) pour le terme ltré. L’algorithme cherche une substitution des variables apparaissant dans les contraintes telle que les contraintes soient satisfaites. Les variables des motifs peuvent donc être métamorphosées au besoin en des variables existentielles qu’il faut substituer par un terme pour satisfaire les contraintes de type. — S’il existe une telle substitution, elle est appliquée aux types des variables libres et au type attendu en retour. Elle est aussi appliquée aux variables du motif qui ont été transformées ainsi qu’aux types des variables du motif. Dans l’exemple, le type de y contient x qui pourrait être part de la substitution. — S’il n’existe aucune substitution satisfaisant le problème, la branche est déclarée impossible et est eacée. Les variables du contexte sont ici vues comme des variables existentielles et non universelles. Le type UIP_re, l’axiome indépendant du CIC et équivalent à K déni gure 1.13, est 373 Encodage du ltrage dans l’analyse de cas de ce fait habité par le terme Agda 1 UIP_re : ∀ (A : Set) (a : A) (e : eq A a a) 7→ eq (eq A a a) e (eq_re A a) UIP_re .B .b (eq_re B b) = eq_re (eq B b b) (eq_re B b) Il est valide car il existe la substitution A := B, a := b telle que la branche eq_re soit bien typée. Toutes les éliminations ne peuvent pas être réalisées. Le comportement problématique apparaît quand les arguments du terme ltré sont autre chose que des variables et des constructeurs. Un terme ayant pour type (plus x y) = O ne peut pas être éliminé directement, l’algorithme d’unication ne sait ni inférer une substitution la plus générale telle que x + y ≡ 0 ni décréter qu’il n’y en a aucune et que ce cas est impossible. En eet, l’unication d’ordre supérieur en λ-calcul est indécidable (voir [29]). Cette restriction est nuancée en Agda en travaillant après réduction et en autorisant des termes quelconques mais syntaxiquement égaux après application de la substitution trouvée par ailleurs. Il est par exemple possible d’éliminer un terme de type (even (S (S O))) = (even (plus (S O) (S O))). 3.2 Encodage du filtrage par des analyses de cas Le ltrage est une manière concise et facile à relire de présenter des programmes. Cette concision est encore plus vraie avec des types dépendants quand les branches impossibles peuvent être omises. L’exemple systématique pour illustrer ce fait est de pouvoir écrire even_map2 : ∀ (n : nat) 7→ even n 7→ even n 7→ _ even_map2 .O even_O even_O = ? even_map2 .(S (S m)) (even_SS .m e1) (even_SS m e2) = ? sans rien dire des cas mixtes even_O/even_SS impossibles par typage. Il est donc souhaitable d’orir à l’utilisateur cette syntaxe de surface même si la logique sous-jacente ne traite que d’analyse de cas élémentaire. Conor McBride et James McKinna ont démontré dans [24] que l’expressivité de l’analyse par cas était celle du ltrage par analyse de couverture si l’on suppose l’axiome UIP de la - gure 1.13. La démonstration revient à construire une clause de retour et un entête de branche après avoir obtenu l’arbre de décision pour tous les ltrages typables par analyse de couverture [40]. Cristina Cornes [19] puis Matthieu Sozeau [53] ont mécanisé pour Coq la génération de telles clauses de retour et preuves en tête de branche. L’utilisateur dispose de la commande "Program" pour écrire des termes et des tactiques case_eq, inversion et dependent_destruction par échelle croissante d’automatisation dans les preuves. Sur des exemples fortement dépendants, ces techniques sont puissantes mais sourent des limitations de l’axiome K décrites section 1.7. 1. En Agda, .t signie justement que les contraintes de typage imposent de substituer cette variable de motif par le terme t. 383.2 Encodage du ltrage par des analyses de cas 3.2.1 Des types riches exprimant les problèmes d’unification L’encodage repose sur l’obtention et la manipulation explicite d’égalités dans le langage. Ces égalités correspondent aux problèmes d’unication entre les index des termes ltrés et ceux des constructeurs. Les propriétés précédentes des constructeurs (discrimination, inversibilité et acyclicité) doivent être ensuite bâties explicitement. Pour obtenir l’information, la solution est d’utiliser le prédicat de retour de l’analyse de cas. Lors de l’élimination d’un entier n pour produire un terme de type T, on rajoute arti- ciellement une égalité ce qui donne le prédicat de retour λ(m : nat) ⇒ m = n → T. L’analyse de cas dans son ensemble a maintenant le type n = n → T, ce qui peut bien redonner T quand on lui applique eq_re nat n. L’avantage est que la branche O attend maintenant un terme de type O = n → T, ce qui fournit l’égalité recherchée. De telles constructions avec la clause de retour jouent un rôle fondamental pour le typage de l’analyse de cas qui sera discuté plus amplement section 3.4.1. Dans l’exemple précédent, l’égalité ajoutée relie des objets de type xe (nat). L’encodage complet du ltrage exposé section précédente nécessite de poser des égalités sur des objets dont les types sont eux-même concernés par d’autres égalités. L’égalité simple dénie gure 1.6 ne sut plus, on a alors besoin de dénir une égalité hétérogène (gure 3.1). Inductive JMeq (A : Set) (a : A) : ∀(B : Set) (b : B), Set := | JMeq_re :JMeq A a A a. Figure 3.1 – Dénition de l’égalité hétérogène Par exemple, la gure 3.2 qui décrit l’inversion d’un double successeur d’un entier a besoin d’égalité hétérogène. En eet, E a le type even 2 alors que H a le type even m. L’hypothèse 2 = m ne sut pas à rendre ces deux types convertibles, ce qui empêche de typer E = H. Definition even_inv (E : even 2) : eq (even 2) E (even_SS O even_O) := case E predicate λ(m : nat) (H : even m) ⇒ 2 = m → JMeq (even 2) E (even m) H → eq (even 2) E (even_SS O even_O) of |even_O:λ(e1 : 2 = O) (e2 : JMeq (even 2) E (even O) even_O) ⇒ . . . |even_SS:λ(n : nat) (E’ : even n) ⇒ λ(e1 : 2 = (S (S n))) (e2 : JMeq (even 2) E (even (S (S n))) (even_SS n E’)) ⇒ . . . end (eq_re 2) (JMeq_re (even 2) E). 2 représente (S (S O)) Figure 3.2 – Exemple d’inversion avec égalité Même une fois exploitée l’égalité de 2 et m, il est impossible d’exploiter l’égalité hétérogène. Le problème de généralisation mal typée mais indispensable pour écrire une clause de retour apparaît pour réaliser le type de la gure 3.3 (il faudrait pouvoir dissocier les 2 instances de p dans les arguments de la constante rew (formellement dénie gure 3.7) pour pouvoir éliminer l’égalité h) exactement comme celui de la gure 1.13. Tous deux sont d’ailleurs logiquement équivalents à K. Une fois muni de cet axiome, l’encodage est mécaniquement réalisable. 393 Encodage du ltrage dans l’analyse de cas Axiom eq_rect_eq : ∀(U : Set) (p : U) (Q : U → Set) (x : Q p) (h : p = p), x = rew U Q p p x h. Figure 3.3 – Egalité modulo réécriture de type 3.2.2 Manipulation des égalités d’index Les règles utilisées par l’unication durant le typage du ltrage par analyse de couverture deviennent des lemmes utilisés pour réaliser des réécritures en tête de branches. Nous allons détailler comment ces lemmes sont construits et utilisés. An d’exprimer une propriété triviale mais qui n’apporte aucune information, on dénit la propriété True (gure 3.4). Pour exprimer une impossibilité dont tout se déduit, on utilise la propriété False (gure 3.5). Inductive True : Set := | I :True. Figure 3.4 – La propriété vraie Inductive False : Set :=. Figure 3.5 – La propriété fausse Puisque False n’a pas de constructeurs, son schéma d’élimination (gure 3.6) qui sera réutilisé section 4.6 permet toutes les folies. La gure 3.7 donne le schéma d’élimination de l’égalité. La possibilité qu’il ore d’avoir une propriété pour le terme de droite si on peut la prouver pour celui de gauche est non seulement le moyen de réaliser les réécritures mais aussi une pierre angulaire de l’élaboration des lemmes d’injectivité eux-mêmes. On peut remarquer qu’il est équivalent d’écrire m = O et case m predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(_ : nat) ⇒ False end. En eet, si m est eectivement O nous n’avons aucune information supplémentaire. En revanche, si m n’est pas O, on obtient une preuve de faux qui nous donne la possibilité de fournir une preuve de T pour tout T en utilisant false_rect. L’analyse par cas constitue une forme d’égalité pour les termes dans lesquels seuls des variables et des constructeurs apparaissent, ceux visibles comme des motifs. Cette remarque et rew sont des outils susants pour discriminer les constructeurs. Pour deux constructeurs distincts Ci et Cj alors le terme de la gure 3.8 a le type C_j = C_i → False 2 . Ce terme permet de conclure dans les cas absurdes. De manière moins intuitive mais tout aussi systématique, le type ∀(n : nat), m = S n → T n peut se reformuler case m predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(n : nat) ⇒ 2. ceci est couramment noté Ci , Cj 403.3 Utilisabilité de l’encodage Definition false_rect (P : Set) (x : False) : P := case x predicate λ(_ : False) ⇒ P of end. Figure 3.6 – ex falso quolibet Definition rew (A : Set) (P : A → Set) (a b : A) (p : P a) (e : eq A a b) : P b := case e predicate λ(c : A) (e’ : eq A a c) ⇒ P c of |eq_re:p end. Figure 3.7 – Brique élémentaire de la réécriture (équivalente au eq_rect de Coq) T n end. La correspondance entre m et S n est assurée. Si m s’avère être autre chose qu’un S dans une branche, la branche est une branche impossible. Il sut de fournir I comme preuve triviale (et inutile pour toute exécution). La preuve d’inversibilité écrite gure 3.9 utilise cette méthodologie. Pour les preuves d’acyclicité, on utilise des inductions sur la variable apparaissant des 2 cotés. Tous les cas sauf celui du constructeur qui apparaît en tête dans l’égalité cyclique utilisent une discrimination. Ce dernier cas est exactement l’appel récursif après usage d’un lemme d’inversibilité. 3.3 Utilisabilité de l’encodage Sur la face logique de la correspondance de Curry-deBruijn-Howard, un lemme de mathématique est rarement démontré pour être évalué. Les termes engendrés par une preuve non triviale sont volumineux. Coq propose pour des questions d’ecacité et de modularité de les masquer une fois qu’ils ont été vériés. L’utilisateur utilise de fait ses lemmes comme des constantes opaques la majorité du temps. Ceci rend anodin d’utiliser l’axiome K. De plus, les égalités explicitement introduites autorisent un raisonnement équationnel arbitrairement complexe et plus expressif que n’importe quelle théorie décidable. Par exemple, il peut s’agir d’exploiter l’arithmétique de Peano sur des égalités d’entiers impliquant addition et multiplication. De plus, si aucune égalité hétérogène n’est utilisée et que l’utilisation des égalités fournies dans les branches se limite à instancier des lemmes de discrimination et d’inversibilité similaires à ceux de la section précédente, le comportement calculatoire du ltrage n’est pas altéré. L’élimination d’un inductif au moyen de cette méthodologie est utile et utilisée. Un algorithme alternatif partiel mais ne nécessitant pas K sera néanmoins proposé dans le chapitre suivant. En eet, d’une part ce manuscrit met l’accent sur l’écriture de programmes et ses problématiques, d’autre part, un tel algorithme représente un support de réexion sur l’expressivité d’une analyse de cas sans K. 413 Encodage du ltrage dans l’analyse de cas Definition C_i_C_j_discr : C_i = C_j → False := λ(e : eq . . . C_j C_i) ⇒ rew . . . (λ(x : . . .) ⇒ case x predicate λ −−−−→ (_ : _) ⇒ Set of |C_j:True |C_s:False end) C_i C_j I e. Figure 3.8 – Discrimination en action Definition C_i_inj (a b : . . .) : C_i a = C_i b → a = b := λ(e : eq . . . (C_i a) (C_i b)) ⇒ rew . . . (λ(x : . . .) ⇒ case x predicate λ −−−−→ (_ : _) ⇒ Set of |C_i:λ(y : . . .) ⇒ eq . . . a y |_:λ −−−−→ (_ : _) ⇒ True end) (C_i a) (C_i b) (eq_re _ a) e. Figure 3.9 – Injection en action 3.4 Constructions génériques autour d’une analyse de cas dépendante 3.4.1 Coupures entrelacées Concevoir intelligemment des clauses de retour implique d’entrelacer l’élimination d’un inductif avec des redex de fonction. Sans considération de typage, il est plus naturel d’écrire le terme (1) que (2) de la gure 3.10. Les deux termes sont néanmoins équivalents et on parle de coupure commutative car il serait possible de réduire (2) vers (1). Fixpoint plus (m n : nat) : nat := case n predicate λ(_ : nat) ⇒ nat of |O:m |S:λ(n’ : nat) ⇒ S (plus m n’) end. Fixpoint plus (m n : nat) : nat := case n predicate λ(_ : nat) ⇒ nat → nat of |O:λ(m’ : nat) ⇒ m’ |S:λ(n’ m’ : nat) ⇒ S (plus m’ n’) end m. (1) (2) Figure 3.10 – Exemple de coupure commutative Pour raisonner sur des prédicats de parité d’entier dénis gure 1.12, les expressions (1) et (2) de la gure 3.11 sont radicalement diérentes. Dans (1), la correspondance de type entre les deux variables est perdue alors que dans (2), le type de e1’ est modié simultanément à e2 dans chaque branche. En eet, l’analyse par cas ne modie pas les types des variables libres (comme e1 qui est de type even n). Les types dans le contexte et les types des constructeurs sont désynchronisés 423.4 Constructions génériques autour d’une analyse de cas dépendante Definition even_inv (n : nat) (e1 e2 : even n) : . . . := case e2 predicate λ(m : nat) (_ : even m) ⇒ . . . of |even_0:. . . |even_SS:λ(m’ : nat) (e : even (S (S m’))) ⇒ . . . end. Definition even_inv (n : nat) (e1 e2 : even n) : . . . := case e2 predicate λ(m : nat) (_ : even m) ⇒ even m → . . . of |even_0:λ(e1’ : even O) ⇒ . . . |even_SS:λ(m’ : nat) (e e1’ : even (S (S m’))) ⇒ . . . end e1. (1) (2) Figure 3.11 – Coupure entrelacée sur les prédicats de parité dans les branches (La première branche indique que e2 est even_0 de type even O mais e1 n’a pas changé de type pour autant). Par contre, en abstrayant une variable, elle passe du contexte à la conclusion. Son type est réécrit dans la clause de retour (e1’ est cette copie de e1 au type plus précis). L’utilisation des abstractions permet la conservation des correspondances dans l’analyse par cas. Sur l’exemple, en inversant l’ordre d’introduction de e1 et e2, la coupure commutative aurait été inutile. L’introduction partielle de e2 uniquement pour laisser e1 dans la conclusion aurait su parce qu’alors on peut faire une η-réduction. Cette possibilité n’est pas systématique comme nous le verrons dans la section 4.3. Introduire une coupure pour obtenir une copie d’un terme dans un type en adéquation avec le type du constructeur de la branche considérée n’est pas utile uniquement pour les variables libres. La mémorisation de la valeur des index du type éliminé se fait de la même manière. Cette technique est par exemple décrite par Bertot et Castéran dans [11] avec des preuves d’égalité. Pour éliminer (p : even(plus (S x) O)) ecacement, mieux vaut savoir que plus (S x) O = O dans le premier cas (an d’éliminer ce cas) et plus (S x) O = S (S m’) dans le second. Nous plaçons pour cela le terme eq_re (plus (S x) O) comme argument du ltrage et réécrivons son type grâce à la clause de retour λ(m : nat) (e : even m) ⇒ eq nat (plus (S x) O) m → . . . an d’obtenir exactement les égalités recherchées. Elles peuvent ainsi servir à montrer que la branche est impossible ou à obtenir des correspondances entre les types des arguments du constructeur et ceux du contexte et de la conclusion. 3.4.2 Elimination des branches impossibles Si un inductif n’a pas d’index, la clause de retour de l’élimination d’un terme de ce type n’a qu’une unique variable, celle qui généralise le terme ltré. Le type attendu dans les branches est le type demandé en retour du ltrage dans lequel le terme éliminé est remplacé par le constructeur de la branche. Sur le cas des listes, la gure 3.12 montre que les termes PN et 433 Encodage du ltrage dans l’analyse de cas PC ont des types ranés. Definition case_list (A : Set) (P : list A → Set) (PN : P nil) (PC : ∀ (t : A) (q : list A) , P (cons t q)) (l : list A): P l := case l predicate λ(l’ : list A) ⇒ P l’ of |nil:PN |cons:λ(t : A) (q : list A) ⇒ PC t q end. Figure 3.12 – Principe d’élimination d’une liste La valeur de l’objet ltré est ranée dans les branches mais son type n’est pas modié. Le typage de la clause de retour ne pose pas de diculté. Un inductif ayant un ou des arguments comme Inductive I : ∀(a : A),Set := . . .. est fondamentalement diérent d’un inductif tel que Inductive J (a : A) : Set := . . .. n’ayant que des paramètres. Tous les constructeurs de J ont en eet le type J a alors que les constructeurs de I ont un type I t avec t quelconque et dépendant du constructeur. Alors que l’élimination de (j : J u) ne peut produire que des constructeurs de type J u, l’élimination de (k : I v) peut produire des constructeurs de type I t (où t dépend du constructeur). Une clause de retour sur J n’a donc pas besoin de dépendre de a. C’est pourquoi il n’y a pas de lieur pour les paramètres. Dans la syntaxe de Gallina, ils doivent apparaître comme des _. Une clause de retour sur I doit par contre avoir un type de la forme ∀(a : A) (b : I a), Set an que P v k et P t (C x y) soient simultanément typables. Le type des branches dépend des index du constructeur en même temps que du constructeur. Le type varie d’un constructeur à l’autre. L’élimination de k doit avoir une branche pour tous les constructeurs C de l’inductif I. Il est donc nécessaire de fournir un terme de type P t (C x y) même si t est incompatible avec v et qu’il est impossible que k soit le constructeur C. L’abstraction sur l’argument de l’inductif donne un moyen de parler de v dans la clause de retour. Par conséquent, l’incompatibilité de t et v est exprimable dans la clause de retour an que n’importe quel terme soit admis dans la branche C. C’est alors une branche impossible. Si un index débute par un constructeur CC, la clause de retour va faire une analyse de cas sur cet index qui revoit le type demandé dans le cas de CC et le type choisi pour peupler les branches impossibles dans les autres cas. Nous verrons avec précision à la section 4.3 comment écrire une clause de retour exhibant les incompatibilités. Dans le cadre présenté ici toutes les branches impossibles contiennent une preuve de discrimination. 444 Du filtrage à l’analyse de cas structurellement L’originalité de ce chapitre est de proposer une traduction des arbres de décision vers des analyses de cas sans utiliser la structure de données eq (et JMeq). Cette construction réduit le préjudice induit par l’absence de l’axiome K en éliminant des situations où l’encodage de la section 3.2 introduit inutilement des égalités hétérogènes. Elle ne tire pas avantage de l’acyclicyté des types de données. Néanmoins, sans axiome ni preuve par récurrence en tête de branche, le comportement calculatoire n’est jamais entravé. La taille syntaxique des termes est aussi potentiellement moindre et leur typage s’avère plus rapide. 4.1 Squelee d’index Les constructeurs en tête des index du type des termes inspectés jouent un rôle particulier. Ils sont distingués des autres termes en introduisant la notion de squelette d’index. Tout d’abord, nous notons p(t1 · · · ts ) le motif p vu comme un terme dans lequel le ième joker est remplacé par le terme ti . Le squelette du terme u est alors la paire d’un motif p et de termes t1 · · · ts ne débutant pas par un constructeur tels que u = p(t1 · · · ts ). Le motif p exprime alors ce sur quoi on peut ltrer. Les termes t1 · · · ts sont dénommés les feuilles du squelette. Les motifs de squelette utilisent une restriction de la syntaxe présentée gure 2.3 puisqu’ils ne contiennent ni alias ni choix. Par exemple, le squelette du terme even_SS (S (S n)) (even_SS n t) est (even_SS (S (S _)) (even_SS _ _), [n ;n ;t]). Deux squelettes sont compatibles si il existe une substitution des jokers de la partie motif de l’un qui permet d’obtenir la partie motif de l’autre. Pour tout terme u dans une famille inductive, le squelette d’index du type de u est la liste des squelettes des index de son type. 4.2 and les égalités sont inutiles Considérons l’élimination d’un terme x de type I a1 · · · as an d’obtenir un terme de type P. Dans le cas le plus simple, les a1 · · · as sont des variables deux à deux distinctes et de types identiques à ceux des index de I lors de sa dénition. Le terme x a dans ce cas un type aussi général que la signature de I. Il est alors inutile de recourir à des égalités pour éliminer x. La 454 Du ltrage à l’analyse de cas structurellement clause de retour s’écrit directement λ −−−−−→ (a’ : A) (x’ : I a’1 · · · a’s ) ⇒ P’ où P’ est P dans lequel sont réalisés les α-renommages ai -> a’i et x -> x’. Remarque Le terme P’ est une généralisation de P, les termes a1 · · · as , x (qui se trouvent être des variables) sont des objets immuables alors que les variables a’1 · · · a’s , x’ sont des abstractions pour diérents termes suivant les cas. Ce sont les outils du ranement des types dans les branches. Par rapport au typage direct du ltrage généralisé (chapitre 3), le sens dans lequel la correspondance entre les type est faite dans les branches est en quelque sorte inversé. Alors que l’unication ou les réécritures qui la simulent plongent les types des arguments du constructeur dans les types du contexte, c’est maintenant le type de retour qui est réécrit en correspondance avec le type du constructeur. En conséquence, si le type du constructeur est trop général, le type attendu est trop général (voir section 4.4). Si maintenant les index a1 · · · as de x ne sont plus nécessairement des variables, un deuxième cas favorable peut se produire. Les feuilles du squelette d’index du type de x peuvent être des variables deux à deux distinctes et de types découlant de la dénition de I. Les constatations pour écrire des lemmes d’injection (gure 3.9) sont alors réemployables. Une clause de retour avec égalité (section 3.2.2) x = C a b → P a b peut s’écrire case x predicate Set of |λ. . . ⇒ Q . . . |λ(a’ : _) (b’ : _) ⇒ P a’ b’ . . . |λ. . . ⇒ Q end. Les branches correspondant à des constructeurs dont l’index ne commence pas par C sont des branches impossibles. Comme expliqué section 3.4.2, le type Q peut donc a priori être choisi arbitrairement mais il est judicieux qu’il soit un type trivialement habité an d’avoir un terme de type Q canonique. Tous les cas d’une élimination d’un inductif doivent en eet être donnés, y compris ceux qui sont impossibles pour toute exécution car de type incompatible. Nous utiliserons dans un premier temps True (et I) (dénis gure 3.4) avant de raner ce choix section 4.6 pour une raison d’inférence de la terminaison des points xes, problème indépendant de celui considéré ici. Une clause de retour du ltrage d’un terme dont le type est un motif est donc caractérisé par une formulation comme match t as x’ in I p1 · · · pn return P with ... end avec les p1 · · · pn des motifs. Coq autorise d’ailleurs directement cette syntaxe. La structure pour donner le prédicat de retour in I p1 · · · pn return P est transformée en interne en λy1 · · · yn ⇒ « match y1 · · · yn with | p1 · · · pn => P | _ => True end » Le ltrage est entre guillemets car il s’agit d’un ltrage généralisé à compiler à son tour. Intuitivement, les termes qui composent ces clauses de retour sont un ltrage à un seul cas intéressant, celui qui isole le squelette d’index du terme ltré. Jean Francois Monin et Xiaomu Shi ont introduit le terme diagonaliseur pour parler d’eux dans [43]. La diérence d’expressivité entre le ltrage par couverture et le ltrage par analyse de cas est assez explicite avec les clauses de retour mises sous cette forme. Le motif utilisé ici est un motif de la programmation fonctionnelle, il doit être linéaire. Le motif de l’analyse de couverture est un motif de la programmation logique qui n’a pas cette contrainte. L’identication de deux types est exactement ce qui nécessite K. 464.3 Diagonalisation 4.3 Diagonalisation Pour pouvoir construire une clause de retour, il faut savoir : — extraire le squelette d’index, mais aussi, — abstraire les variables libres dont le type interfère avec l’objet ltré ou ses index. Conserver les liens avec les types des variables libres introduit les coupures entrelacées. Spécialiser la clause de retour suivant le squelette d’index élimine les branches impossibles. Cela demande du ltrage dans le diagonaliseur. Il y a donc du ltrage dans la clause de retour du ltrage. Cependant le ltrage dans la clause de retour a lieu sur le type d’un index du terme ltré. Il a donc lieu sur un inductif déni strictement plus tôt dans le contexte global. La terminaison est assurée, la lisibilité du résultat par contre ne l’est pas. Nos exemples explicatifs sont incrémentaux pour ne pas noyer le lecteur. Commençons par illustrer l’utilisation d’un squelette d’index et la reconnaissance de branches impossibles. Fournir un habitant du type False est et doit rester impossible. Il est pourtant possible d’écrire une preuve de ∀(H : even 1), False (pour even déni gure 1.12) par ltrage sur H. La clause de retour de l’élimination d’un terme de type even u a la forme λ(n : nat) (e : even n) ⇒ P n e. Les constructeurs S et O sont des constantes injectives. Le diagonaliseur de la gure 4.1 permet en ltrant sur n de montrer que P 1 _ renvoie False comme attendu mais que P (S (S m)) (even_SS m) et P O even_O demandent des termes de type True faciles à construire. Definition diag_even1 (n : nat) (e : even n) : Set := case n predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(m : nat) ⇒ case m predicate λ(_ : nat) ⇒ Set of |O:False |S:λ(_ : nat) ⇒ True end end. Definition even1 (H : even (S O)) : False := case H predicate λ(n : nat) (e : even n) ⇒ diag_even1 n e of |even_O:I |even_SS:λ(m : nat) ⇒ I end. Figure 4.1 – Diagonaliseur pour even 1 La section précédente a illustré deux techniques : généraliser le type attendu en retour de l’analyse de cas et incorporer aux clauses de retour la séparation des constructeurs. Mettons maintenant en œuvre pleinement ces constructions. Dans l’exemple précédent (x = C a b → P a b) les variables a b sont devenues a’ b’ à l’intérieur du case. Plus généralement, les variables qui apparaissent en feuilles du squelette d’index sont substituées autant que possible par les variables issues de l’analyse de cas. Une telle substitution n’est pas une opération sûre : si la 474 Du ltrage à l’analyse de cas structurellement variable substituée apparaît dans les paramètres de l’inductif ou apparaît à plusieurs feuilles, le terme construit est mal typé. La n de ce chapitre détaille notre heuristique (section 4.5). Ecrire un terme de type ∀(n : nat) (e : even (S (S n))), even n par analyse de cas sur e met en application ce principe. Le cas even_O est une branche impossible car O , S(S _) . L’argument m de even_SS est utilisé lui dans le type attendu. Le prédicat de diagonalisation est Definition diag_SS (n : nat) (e : even (S (S n))) : Set := case n predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(x : nat) ⇒ case x predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(m : nat) ⇒ even m end end. Figure 4.2 – Diagonaliseur pour inverser evenSS Nous n’utilisons ici que la feuille du squelette d’index dont le type n’est pas dépendant. Dès qu’est utilisée une variable dont le type évolue au cours du ranement du squelette d’index, une coupure entrelacée est nécessaire. En particulier, le type de la variable représentant la généralisation du terme ltré doit se raner au fur et à mesure que les index du terme ltré sont ranés. An d’illustrer cette armation, nous introduisons une nouvelle structure de données dépendante. La gure 4.3 déni la famille des ensembles nis. Le type Fin n représente l’ensemble [|1 .. n|]. Le constructeur F1 m représente le premier élément d’un ensemble à S m éléments alors que FS m f représente le (k + 1)-ième élément d’un ensemble à S m éléments si f représente le k-ième élément d’un ensemble à m éléments. Par exemple, Fin O est vide, Fin (S (S O)) contient F1 (S O) et FS (S O) (F1 O), etc. Inductive Fin : nat → Set := | F1 :∀(n : nat), Fin (S n) | FS :∀(n : nat), Fin n → Fin (S n). Figure 4.3 – Famille inductive des ensembles de taille xée Avec cette dénition, comment raisonner par cas sur un élément quelconque d’un ensemble non vide ? Supposons par exemple que t a le type Fin (S n) pour n xé et que l’on souhaite raisonner par cas dessus. Le but est alors d’écrire un terme de type ∀(n : nat) (f : Fin (S n)), P n f. Son diagonaliseur va nécessairement débuter par les abstractions issues de la dénition de la famille inductive : λ(k : nat) (f’ : Fin k) ⇒ . . .. il faut ensuite ltrer sur k pour retrouver qu’il est non nul sans perdre le fait que f’ a k éléments. La variable f’ est dans le contexte, une coupure entrelacée la remet dans la conclusion. La gure 4.4 montre le résultat. Les diagonaliseurs réalisent pour l’instant des ltrages sur nat, un inductif non dépendant. Les diagonaliseurs des analyses de cas du diagonaliseur étaient implicites car simples. Dans le cas général, il faut de nouveau prendre en considération dans le diagonaliseur les branches 484.3 Diagonalisation Definition diag_nS (k : nat) (f’ : Fin k) : Set := case k predicate λ(k’ : nat) ⇒ Fin k’ → Set of |O:λ(fo : Fin O) ⇒ True |S:λ(k’ : nat) (fs : Fin (S k’)) ⇒ P k’ fs end f’. λ(n : nat) (f : Fin n) ⇒ case f predicate diag_nS of |F1:λ(m : nat) ⇒ . . . : P m (F1 m) |FS:λ(m : nat) (f’ : Fin m) ⇒ . . . : P m (FS m f’) end Figure 4.4 – Diagonaliseur pour ensemble non vide impossibles, généraliser suivant les index et le terme éliminé mais aussi prévenir les désynchronisations des types des variables du contexte avec ceux des arguments du constructeur dans la branches. Bref, bâtir récursivement nos diagonaliseurs. Considérons par exemple l’élimination d’un prédicat (H : FLast (S n) (FS n f)) où FLast exprime la propriété d’être le dernier élément d’un ensemble non élémentaire (gure 4.5) pour conclure P n f H . Il faudra construire successivement trois diagonaliseurs. Inductive FLast : ∀(n : nat) (f : Fin n), Set := | FL1 :FLast (S O) (F1 O) | FLS :∀(n : nat) (f : Fin n), FLast n f → FLast (S n) (FS n f). Figure 4.5 – Dernier élément d’un ensemble Le prédicat de diagonalisation gure 4.7 débute par un ltrage sur l’entier. L’ensemble et le prédicat ne doivent pas être introduits an de conserver les dépendances de type. Le prédicat (diag_Fin : ∀(k : nat) (f : Fin (S k)) (H : Flast (S k) f), Set) doit ensuite par ltrage sur f être égal à P appliqué aux variables du dernier ltrage dans le cas FS et à True sinon. Pour conserver les correspondances de type alors qu’un constructeur apparaît dans le type de f, l’élimination a pour clause de retour le diagonaliseur diag_nat. Ici il existe un diagonaliseur bien plus simple donné gure 4.8 qui économise l’analyse de cas sur les entiers vu qu’ils sont arguments de l’ensemble. Néanmoins, la présence de diagonaliseurs dans les diagonaliseurs est générique et absolument nécessaire en général. Pour preuve, voici notre dernier exemple : l’inversion du prédicat d’égalité sur deux ensembles de même taille déni gure 4.6. Il met en oeuvre tous les mécanismes expliqués. Cette fois, tous sont nécessaires. Le résultat est indigeste, il est heureux que la section 4.7 donne l’algorithme formel pour le générer an que plus jamais il ne soit écrit manuellement. Inductive FinEq : ∀(n : nat), Fin n → Fin n → Set := | F1Eq :∀(n : nat), FinEq (S n) (F1 n) (F1 n) | FSEq :∀(n : nat) (f1 f2 : Fin n), FinEq n f1 f2 → FinEq (S n) (FS n f1) (FS n f2). Figure 4.6 – Prédicat d’égalité sur les éléments dans des ensembles de même taille 494 Du ltrage à l’analyse de cas structurellement Definition diag_FLS (m : nat) : ∀(f : Fin m) (H : FLast m f), Set := case m predicate λ(m’ : nat) ⇒ ∀(f : Fin m’) (H : FLast m’ f), Set of |O:λ(f’ : Fin O) (_ : FLast O f’) ⇒ True |S:λ(k : nat) ⇒ diag_Fin k end. where Definition diag_Fin (k : nat) (f : Fin (S k)) : ∀(H : FLast (S k) f), Set := case f predicate diag_nat of |FS:λ(j : nat) (f0 : Fin j) ⇒ λ(H : FLast (S j) (FS j f0)) ⇒ P j f0 H |F1:λ(j : nat) ⇒ λ(_ : FLast (S j) (F1 j)) ⇒ True end. and Definition diag_nat (i : nat) : ∀(f : Fin i), Set := case i predicate λ(i’ : nat) ⇒ ∀(f : Fin i’), Set of |O:λ(_ : Fin O) ⇒ True |S:λ(j : nat) ⇒ λ(f’ : Fin (S j)) ⇒ ∀(H : FLast (S j) f’), Set end. Figure 4.7 – Diagonaliseur pour ∀(H : FLast (S n) (FS n f)), P n f H λ(m : nat) (f : Fin m) ⇒ case f predicate λ(i : nat) (f’ : Fin i) ⇒ FLast i f’ → Set of |F1:λ(i : nat) (H : FLast (S i) (F1 i)) ⇒ True |FS:λ(i : nat) (f0 : Fin i) (H : FLast (S i) (FS i f0)) ⇒ P i f0 end Figure 4.8 – Diagonaliseur optimisé pour ∀(H : FLast (S n) (FS n f)), P n f H 504.3 Diagonalisation Definition diag_x1 (x1 : nat) : Fin x1 → Set := case x1 predicate λ(n2 : nat) ⇒ Fin n2 → Set of |O:λ(_ : Fin O) ⇒ True |S:λ(x0 : nat) ⇒ λ(f1’ : Fin (S x0)) ⇒ ∀(f2 : Fin (S x0)), FinEq (S x0) f1’ f2 → Set end. Definition diag_x2 (x2 : nat) : Fin x2 → Set := case x2 predicate λ(n3 : nat) ⇒ Fin n3 → Set of |O:λ(_ : Fin O) ⇒ True |S:λ(x0 : nat) ⇒ λ(f2’ : Fin (S x0)) ⇒ ∀(f1’’ : Fin x0), FinEq (S x0) (FS x0 f1’’) f2’ → Set end. Definition diag_H (n0 : nat) : ∀(f1 f2 : Fin n), FinEq n f1 f2 → Set := case n0 predicate λ(n1 : nat) ⇒ ∀(f4 f5 : Fin n1), FinEq n1 f4 f5 → Set of |O:λ(f4 f5 : Fin O) (_ : FinEq O f4 f5) ⇒ True |S:λ(x : nat) ⇒ λ(f4 : Fin (S x)) ⇒ case f4 predicate diag_x1 of |F1:λ(n1 : nat) ⇒ λ(f5 : Fin (S n1)) (_ : FinEq (S n1) (F1 n1) f5) ⇒ True |FS:λ(n1 : nat) (f5 : Fin (S n1)) ⇒ λ(f6 : Fin (S n1)) ⇒ (case f6 predicate diag_x2 of |F1:λ(n2 : nat) ⇒ λ(f7 : Fin n2) (_ : FinEq (S n2) (FS n2 f7) (F1 n2)) ⇒ True |FS:λ(n2 : nat) (f7 : Fin n2) ⇒ λ(f8 : Fin n2) (_ : FinEq (S n2) (FS n2 f8) (FS n2 f7)) ⇒ FinEq n2 f8 f7 end f5) end end. Definition invert_H (n : nat) (f1 f2 : Fin n) (H : FinEq (S n) (FS n f1) (FS n f2)) : FinEq n f1 f2 := case H predicate λ(n0 : nat) (f f0 : Fin n0) (H’ : FinEq n0 f f0) ⇒ diag_n f f0 H’ of |F1Eq:λ(_ : nat) ⇒ I |FSEq:λ(m : nat) (f’ f’’ : Fin m) (H0 : FinEq m f’ f’’) ⇒ H0 end. Figure 4.9 – Inversion du prédicat d’égalité sur deux ensembles non élémentaires 514 Du ltrage à l’analyse de cas structurellement 4.4 and le diagonaliseur en dit trop La construction du diagonaliseur est réalisée suivant l’intégralité du squelette d’index de l’objet ltré. Maintenant, il faut aussi se préoccuper des constructeurs de l’inductif correspondant et de leurs squelettes d’index. Jusqu’à maintenant, ces squelettes étaient soit égaux soit incompatibles avec le squelette de l’objet ltré. En réalité, ils peuvent être plus généraux. La forme normale du type attendu dans la branche est alors une analyse de cas sur l’un des arguments du constructeur. Pour habiter le type voulu, la branche commence par l’élimination de cet argument. Pour caricaturer, dénissons un inductif ayant un prédicat comme paramètre et un entier comme index et dont l’unique constructeur n’a pour but que d’empaqueter un habitant du prédicat pour un entier donné (gure 4.10). Supposons ensuite que l’on souhaite détruire un terme de type boite P (S n) pour P et n donnés. L’élimination a la structure indiquée en gure 4.11. Il a fallu raisonner par cas sur l’argument de contenu an de peupler le type demandé dans la branche puisque lui aussi est un raisonnement par cas sur cet argument. Inductive boite (D : nat → Set) : nat → Set := | contenu :∀(n : nat), D n → boite D n. Figure 4.10 – Une boite à D Definition ouvre_boite (D : nat → Set) (n : nat) (B : boite D (S n)) : T := let diag_boite := λ(m : nat) ⇒ case m predicate λ(m’ : nat) ⇒ Set of |O:True |S:λ(k : nat) ⇒ T end in case B predicate λ(m : nat) (_ : boite D m) ⇒ diag_boite m of |contenu:λ(n : nat) (x : P n) ⇒ case n predicate λ(n’ : nat) ⇒ diag_boite n’ of |O:True |S:λ(k : nat) ⇒ t end end. Figure 4.11 – Éliminer une grosse boite Voilà tout le nécessaire pour construire des clauses de retours et peupler les parties impossibles des branches si les index des termes ltrés peuvent être écrits sous la forme d’une liste de motifs du ltrage à la ML. Des situations hors de ce cadre peuvent néanmoins apparaître à tout moment, y compris dans les index des index soit dans des appels récursifs. Trouver un comportement le plus conservatif possible quand les termes sont trop généraux est indispensable pour écrire un algorithme générique utilisable en pratique. 524.5 Des clauses de retour pour éliminer tous les termes 4.5 Des clauses de retour pour éliminer tous les termes Nous venons de voir sur des exemples les méthodes que la compilation structurelle du ltrage utilise. Au-delà de ces exemples, quels sont les ltrages pour lesquels ces méthodes s’appliquent convenablement et sont susantes ? La diculté de construire une analyse de cas dépend du type de l’objet ltré. 4.5.1 Les index du type ne contiennent que des variables et des constructeurs Pour éliminer une structure de données n’ayant pas d’index, la section 1.7 a déjà remarqué qu’aucun type n’était variable dans la clause de retour et que le problème ne posait pas de diculté. En présence d’index mais pas de paramètres, la question est de savoir si ces index peuvent être vus comme des motifs. Construire une clause de retour structurellement se fait en eet au moyen d’un diagonaliseur et un diagonaliseur est construit par analyse de cas sur les index. Dans un motif de la programmation fonctionnelle, les variables sont des lieurs tous distincts. En renommant toutes les occurrences de ces variables dans le type attendu en retour de l’analyse de cas, on conserve un terme correctement typé. Construire des clauses de retour ne comporte alors pas de diculté. En présence de paramètre et d’index simultanément, les variables apparaissant à la fois dans les index et les paramètres sont problématiques. L’occurrence dans les index prend part au diagonaliseur et va donc être α-renommé dans la clause de retour alors que celle dans les paramètres n’y prend pas part et reste constante. Comment savoir alors quelles occurrences de la variable dans le type attendu en retour de l’analyse de cas renommer et ne pas renommer pour écrire la clause de retour ? Que se soit suite au problème d’occurrence simultané dans un paramètre d’une variable apparaissant dans un index ou de l’occurrence multiple dans les index, supposons que la condition de linéarité d’occurrence des variables ne soit pas satisfaite pour la variable o. Il faut alors réintroduire des degrés de liberté pour écrire un prédicat de retour. Nous voulons dissocier les occurrences de o dans Q (le type attendu en retour) en fonction de l’occurrence de o dans t’1 · · · t’s ou w’1 · · · w’s dont elles proviennent. Le problème se ramène concrè- tement à dénir (Q0 : ∀. . . (o1 : _) . . . (o2 : _) . . ., Set) dont le type suit la signature de l’inductif et tel que Q0 . . . o . . . o . . . = Q. Notre heuristique fait le choix d’utiliser autant que le typage le permet o2 puis autant que le typage le permet o1 puis o en dernier recourt. Elle est choisie pour maximiser la « typabilité » des termes générés. Quand ni o1 ni o2 ne peuvent être choisis mais qu’un o’ imaginaire uniable à la fois à o1, o2 et o le pourrait, nous avons aaire à un ltrage qui implique l’axiome K sur le type de o. o1 et o2 ne sont pas dissociables. Notre algorithme n’utilise lui que o. Il fournit ainsi un type qui ne varie pas suivant les branches et rend inexploitable l’élimination. L’information que o1 = o2 = o est perdue. Avant d’atteindre les feuilles du squelette d’index et les problèmes de généralisation, il a fallu extraire le motif du diagonaliseur. Pour cela : 534 Du ltrage à l’analyse de cas structurellement 1. Nous commençons par une phase conservative : — Quand une feuille du squelette d’index est une variable qui n’apparaît ni dans le type attendu en retour ni dans les types des feuilles suivantes, il est remplaçable par un _ (le joker des motifs). Par exemple, pour détruire (f : even m) an d’obtenir un entier, puisque m n’apparaît pas dans nat, il est parfaitement admissible d’écrire case f predicate λ(_ : nat) (_ : even _) ⇒ nat of . . . end — Dans la dénition d’un inductif, un index peut en déterminer un autre. Par exemple, dans FLast, l’entier est déterminé par l’ensemble car il en est la taille. Plus géné- ralement, à chaque fois que le type de l’inductif est de la forme ∀. . . (x : . . .) . . . (y : I t1 · · · ts ), Set et que x est l’une des feuilles du squelette d’index d’un des t1 · · · ts , y détermine x. Un index déterminé par ailleurs grâce à la dénition de l’inductif est remplaçable par un joker si, dans le type de l’objet ltré, il s’agit d’une variable ou que l’un des index le déterminant commence par un constructeur. — Un index déterminé par ailleurs ne l’est pas nécessairement qu’une seule fois. Dans la dénition de FinEq le premier index est déterminé par le second et/ou le troisième car les deux ensembles sont de même taille : l’entier donné. Lorsque deux index déterminant un même troisième commencent tous deux par un constructeur, le terme t correspondant à l’index déterminé apparaît comme argument des deux constructeurs. Une occurrence déterminant l’autre, t est remplaçable par un joker dans l’un des deux index déterminant en plus de remplacer l’index dé- terminé par _. 2. Si après cette phase, nous n’avons plus que des constructeurs, des jokers et des variables apparaissant linéairement, et hors des paramètres du type de l’objet ltré, nous voilà dans la situation optimale. Voici un motif caractérisant le problème qui va permettre la construction d’un diagonaliseur. 4.5.2 Hors du cadre pseudo-motif Nous allons maintenant nous attarder sur des ltrages qui ne sont pas couverts par le typage primitif. Comment éliminer une donnée dont les index du type sont des termes quelconques (des sortes, des produits des analyses de cas, . . .) ? Deux altermatives existent : perdre de l’information ou réintroduire les égalités explicites que nous souhaitions éviter. — On ramène le problème de générer une annotation de type pour une analyse de cas à un problème d’unication d’ordre supérieur Si l’un des t’ n’est pas une variable. L’algorithme tente d’abstraire t’ par une variable fraîche du type de l’argument correspondant dans la dénition de l’inductif. Les chances de résultat concluant sont minces et la correspondance de cet argument avec t’ est perdue. Quasi systématiquement, aucune occurrence substituable n’est trouvée et le type de retour demandé est constant suivant les branches. L’information est perdue par désynchronisation entre les types comme nous l’avons expliqué lorsque nous avons étudier les conséquence de ne pas utiliser les abstractions de la clause de retour section 3.4.2. 544.6 Digression sur les cas impossibles dans des points xes Si ces index n’apparaissent ni dans le type d’autres index non jokerisés ni dans le type attendu en retour de l’analyse de cas, il n’y aura pas de problème de typage mais il peut néanmoins appaitre des branches impossibles non reconnues comme telles. Prenons l’exemple de (x : nat) et (f : even (plus x (S O))). En détruisant f pour obtenir un nouvel entier (nat), il est tout-à-fait possible d’écrire la clause de retour λ(_ : nat) ⇒ nat. Nous n’avons pas l’information que la branche d’even_O est impossible même si eectivement x + 1 , 0. Les désagréments ont tendance à s’accumuler. Si une variable x apparaissant pourtant linéairement dans les index a un type contenant un autre index t’, x ne sera pas convenablement systématiquement renommée. Dans ∀(m n : nat) (f1 : Fin m) (f2 : Fin n) (f3 : Fin (plus n m)) (H : FLast (plus m n) f3), eq (Fin (plus m n)) (append m f1 n f2) f3, il est impossible d’éliminer H car la clause de retour est mauvaise que l’on écrive λ(x : nat) (y : Fin x) ⇒ x = plus m n → eq (Fin x) (append m f1 n f2) y ou eq (Fin (plus m n)) (append m f1 n f2) y — L’alternative est de réappliquer la stratégie des égalités explicites du chapitre précédent. Au lieu d’eacer ces termes u1 · · · us , on réalise une coupure entrelacée sur l’égalité en appliquant l’analyse de cas à eq_re ... y1 · · · eq_re ... ys an de se souvenir dans les branches à quoi sont égales les feuilles du squelette d’index. Il n’y a pas moyen de tirer avantage automatiquement des ces égalités car elles n’ont pas de constructeur en tête. Lorsque le terme de preuve est construit interactivement par tactique, l’utilisateur peut réagir manuellement aux informations retournées pour construire les branches après une élimination d’une inductif. La stratégie adoptable est diérente. Mieux vaut conserver toutes les informations de correspondance quitte à utiliser pour se faire des égalités (potentiellement hétérogènes) explicitement. 4.6 Digression sur les cas impossibles dans des points fixes Il doit être fait une remarque maintenant qui ne prend du sens qu’une fois les questions du contrôle de la bonne formation des points xes abordée (Chapitre 6) Une analyse de cas est considérée comme un argument admissible d’un appel récursif si toutes ses branches le sont. En particulier, si un inductif n’a, comme False, aucun constructeur, toutes les zéros branches d’un ltrage d’un terme de ce type sont des appels récursifs admissibles. An que les branches impossibles soient le plus invisibles possible, il faut les peupler par des termes qui sont des appels récursifs admissibles. C’est pourquoi, plutôt que I : True, Coq utilise dans les cas impossibles λ(x : False) ⇒ case x predicate λ(_ : False) ⇒ True of end : False → True. Ainsi, si v est un sous terme d’un argument récursif dans la dénition du point xe f, le terme f (Vhd v) est un appel récursif admissible pour la dénition Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A := let diag := λ(n : nat) ⇒ case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of |O:λ(_ : vector O) ⇒ False → True |S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A 554 Du ltrage à l’analyse de cas structurellement end in case v predicate diag of |Vnil:λ(x : False) ⇒ case x predicate λ(_ : False) ⇒ True of end |Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h end. mais pas pour la dénition Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A := let diag := λ(n : nat) ⇒ case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of |O:λ(_ : vector O) ⇒ True |S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A end in case v predicate diag of |Vnil:I |Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h end. car I n’est pas un sous terme ! 4.7 Mécaniser la diagonalisation et compiler le filtrage Le chapitre 2 indique comment obtenir un arbre de décision et une pile d’objet à ltrer à partir d’un ltrage. Cette partie va indiquer comment aller mécaniquement d’un arbre de décision à une succession d’analyse de cas. Toute la diculté est de gérer les types. Les opérations élémentaires sont toutes mutuellement récursives, c’est pourquoi l’exposé est nécessairement incrémental et non parallèle. Les fonctions impliquées sont — env ⊢ decl_branchenuméro_branche continuation_corps_branche type_branche = résultat pour construire une branche, — env ⊢ construire_case terme_éliminé clause_de_retour continuation_corps_branche = résultat pour construire une analyse de cas, — env ⊢ (type_terme_éliminé 7→ type_attendu_retour) ց résultat, variables_à_généraliser pour aller du type de l’objet analysé à un diagonaliseur, — env ⊢ || (terme_éliminé : index_type_terme_eliminé) 7→ [substitution]type_attendu_retour || = arbre_decision, variables_à_généraliser pour construire l’arbre de décision associé au type d’un terme éliminé, — et env ⊢ arbre_décision : type_attendu_retour ց résultat pour aller d’un arbre de décision à un terme du CCI. 4.7.1 Construire une analyse de cas à partir de sa clause de retour La première opération nécessaire est la construction d’une branche dirigée par son type. Il s’agit de la fonction decl_branche déclarée gure 4.12. On part du type que doit avoir la branche et d’une fonction de continuation pour construire la branche. Le système regarde le type : 564.7 Mécaniser la diagonalisation et compiler le ltrage — S’il reconnaît une branche impossible, il peuple la branche automatiquement et n’utilise pas la continuation. — Si le type est une analyse de cas sur l’un des arguments du constructeur, nous sommes dans la situation de la section 4.4. Le système fait une analyse de cas sur cette variable pour n’appeler la fonction de l’utilisateur que lorsque toutes les informations de typage auront été récupérées. — Dans les autres cas, c’est à la continuation d’agir. Γ ⊢ decl_branchei k T = t Γ ⊢ decl_branchei k (∀ −−−−→ (x : S), False → T) = (λ −−−−→ (x : S) (b : False) ⇒ ex_falso T b) Γ, −−−−→ (z : S) ⊢ (x 7→ * . , case x predicate P of |b1 · · · |bs end u1 · · · uj + / - ) ց diag, y1 · · · yn Γ, −−−−→ (z : S) ⊢ construire_case x diag k_branche = t Γ ⊢ decl_branchei k * . . . . , λ −−−−→ (z : S) ⇒ case x predicate P of |b1 · · · |bs end u1 · · · uj + / / / / - = λ −−−−→ (z : S) ⇒ t y1 · · · yn k_branche(Γ, T, i) = t ssi Γ ⊢ decl_branchei k T = t Γ ⊢ decl_branchei k T = k Γ T i Figure 4.12 – Dénition de la ième branche dirigée par son type T puis la continuation k La fonction decl_branche peuple les parties non informatives de la branche, celles qui sont issues d’un type de branche fourni par un diagonaliseur pour ne demander à l’utilisateur que les branches utiles lors de réductions. Grâce à elle, nous dénissons construire_case, la fonction décrite gure 4.13 qui construit une analyse de cas à partir d’un diagonaliseur et d’une continuation fournissant les habitants des branches utiles. 4.7.2 D’un arbre de décision à des analyses de cas Nous n’avons pas encore dit comment écrire une clause de retour mais nous savons ré- pondre aux artefacs qu’elle induit dans les termes. Il est alors possible de décrire gure 4.14 comment aller d’un arbre de décision à un terme. Cette procédure a besoin du type T du 574 Du ltrage à l’analyse de cas structurellement Γ ⊢ construire_case t diag k = o Γ ⊢ C1 ∈ ∀ −−−−−−−−−→ (z1n : S1n), I u11 · · · u1j · · · Γ ⊢ Cs ∈ ∀ −−−−−−−−→ (zsn : Ssn), I us1 · · · usj Γ ⊢ decl_branchei k (∀ −−−−−−−−−→ (z1n : S1n), T u11 · · · u1j (C1 z11 · · · z1n)) = b1 · · · Γ ⊢ decl_branchei k (∀ −−−−−−−−→ (zsn : Ssn), T us1 · · · usj (Cs zs1 · · · zsn)) = bs Γ ⊢ construire_case t T k = case t predicate T of |b1 · · · |bs end Figure 4.13 – Dénition de l’élimination de t à partir du prédicat de retour diag suivant la continuation k terme à construire et de l’environnement de typage Γ. Les alias présents dans les noeuds de l’arbre de décision doivent être des variables deux à deux distinctes et diérentes des variables de l’environnement. Cet invariant est garanti par les fonctions qui construisent un arbre de décision au moment où elles prennent en compte les alias donnés par l’utilisateur. Γ ⊢ st : T ց t Γ ⊢ Tail (t) : T ց t Γ, (x : S) ⊢ p : T ց t Γ ⊢ Leafx : : p : ∀ (x : S), T ց λ (x : S) ⇒ t Γ, (x : S) ⊢ (x 7→ T) ց diag, y1 · · · ys Γ, (x : S) ⊢ construire_case x diag k_case = t Γ ⊢ Nodex(st1 · · · stn) : ∀ (x : S), T ց λ (x : S) ⇒ t y1 · · · ys k_case(Γ, T, i) = t ssi Γ ⊢ sti : T ց t Figure 4.14 – D’un arbre de décision à un terme La générations des analyses de cas suit exactement la structure de l’arbre de décision : — A la n la substitution des alias par des variables est appliquée au membre droit de la branche — Une feuille est une abstraction. La substitution est enrichie du nouveau nom pour l’alias. — Si l’on sait obtenir les variables du contexte qu’il faut généraliser et le diagonaliseur qui correspondent à une élimination, nous savons construire l’analyse de cas qui correspond à un noeud. — Un échange introduit par des abstractions les éléments de la pile jusqu’à l’élément recherché, retire des éléments introduits ceux à oublier car ils sont imposés par le typage de l’élément recherché puis réapplique l’élément recherché suivi des éléments restants. L’échange introduit comme le noeud des coupures entrelacées mais avec des termes à ltrer plus tard et non des variables libres. 584.7 Mécaniser la diagonalisation et compiler le ltrage 4.7.3 Extraire un diagonaliseur Il reste à construire le diagonaliseur (gure 4.16), c’est-à-dire à extraire le squelette d’index d’un terme ltré, la généralisation des variables libres dont le type dépend des feuilles de ce squelette et à tenter la meilleurs abstraction possible du type attendu en retour en fonction de ces feuilles. Γ ⊢ || (t : u1 · · · us ) 7→ [σ]c || = p, x1 · · · xs Γ ⊢ || (t : u1 · · · us , q) 7→ [σ]T || = pi , −−−−−−−−→ (ym : Sm) ∀j , i,pj = Leafnj +m _ : : Tail (False → True) Γ ⊢ || (t : Ci u1 · · · us , q) 7→ [σ]T || = Nodex(p1 · · · pn ), −−−−−−−−→ (ym : Sm) {(a : A) ∈ Γ | u occurs_in A} = −−−−−→ (z : S’) x variable fraiche Γ ⊢ || (t : q, z1 · · · zs ) 7→ [σ, u 7→ x]T || = p, −−−−→ (y : S) Γ ⊢ || (t : u, q) 7→ [σ]T || = Leafx : : p, −−−−→ (y : S), −−−−−→ (z : S’) {(a : A) ∈ Γ | t occurs_in A} = −−−−→ (z : S) x et y1 · · · ys variables fraiches abstract_all_when_possible (σ, t 7→ x, z1 7→ y1 · · · zs 7→ ys ) T = v Γ ⊢ || (t : ∅) 7→ [σ]T || = Leafx, y1 · · · ys : : Tail (v), −−−−→ (y : S) Figure 4.15 – Construction du diagonaliseur La méthode pour trouver la meilleure abstraction d’un terme suivant des termes donnés est due à Chung-Kil Hur. Le problème est le suivant : Pour u1 · · · um une liste de termes de types respectifs S1 · · · Sm et un terme t de type T, trouver t’ tel que t’ u1 · · · um = t. Le terme t’ doit être bien typé. 1 Les termes u1 · · · um doivent en outre apparaître le moins possible dans t’. Nous ne chercherons pas à qualier formellement « le moins possible ». Celui-ci dissimule en eet la caractérisation de l’expressivité du ltrage sans l’axiome K, problème fondamental que ce manuscrit ne résout pas. A l’origine de l’algorithme réside un judicieux détournement. Coq ore à l’utilisateur un mécanisme d’arguments implicites. Si une constante attend par exemple comme argument un entier n puis un Fin n, quand l’utilisateur donne l’ensemble, il donne sa taille. Le premier argument étant nécessairement cette taille, l’utilisateur n’a pas besoin de la donner explicitement, le système peut l’inférer. Le premier argument est dénissable comme implicite donc non donné par l’utilisateur et le système remplace ce "trou" par le terme adéquat. Si u de type S apparaît dans t, remplaçons toutes les occurrences de u dans t par des "trous" qui se nomment en réalité des variables existentielles. Demandons au système de résoudre ses variables existentielles. Là où u est indispensable par typage, le système va le remettre. 1. D’ailleurs, obtenir son type demande déjà du travail. 594 Du ltrage à l’analyse de cas structurellement Ailleurs, remplaçons les variables restantes par une variable y fraîche pour obtenir t’. Le terme λ(y : S) ⇒ t’ est bien typé et convertible à t quand il est appliqué à u. Nous avons obtenu une solution d’abstraction sur un terme. Pour une liste de termes la solution est similaire mais compliquée par les dépendances de type entres les termes à abstraire. Il faut en eet commencer par le dernier élément du futur télescope an qu’ensuite son type soit lui aussi généralisé selon les termes dont il dépend. La fonction abstract_all_when_possible doit donner une réponse bien typée et telles que si σ ◦ σ ′ = id (σ’ est une substitution standard des variables vers les termes) alors σ’(abstract_all_when_possible σ T) = T. Γ ⊢ (t 7→ c) ց out, x1 · · · xs Γ ⊢ t ∈ I a1 · · · am u1 · · · us Γ ⊢ I a1 · · · am ∈ ∀ −−−−→ (x : S), Set Γ ⊢ || (t : u1 · · · us ) 7→ [ε]c || = st, −−−−−−−→ (yn : Tn) Γ ⊢ st : ∀ −−−−→ (x : S) (z : I a1 · · · am x1 · · · xs ) −−−−−−−→ (yn : Tn), Set ց o Γ ⊢ (t 7→ c) ց o, y1 · · · yn Figure 4.16 – Prédicat de retour out de l’élimination de t pour obtenir c 4.8 Eléments de correction Notre algorithme génère-t-il des termes bien typés ? Nous ne pouvons pas réellement exprimer cette propriété. Nous ne sommes pas capable de donner une règle de typage primitive pour le ltrage généralisé n’impliquant pas l’axiome K. La recherche sur ce sujet est très active au moment de l’écriture de ce manuscrit mais elle n’a pas encore abouti à une caractérisation. Nous ne pouvons donc pas énoncer de propriété telle que « si le ltrage est bien typé, le terme du CCI généré par l’algorithme ci-dessus est bien typé ». Or, si l’utilisateur écrit un ltrage qui n’a pas de sens, le résultat de sa compilation sera mal-typé. Par ailleurs, notre algorithme nissant par une phase heuristique, il y a peu d’espoir de pouvoir obtenir un résultat général. Cette question n’est néanmoins pas critique. DeBruijn a introduit un principe essentiel en informatique théorique : plutôt que certier la génération de témoins de manière complexe, assurons de manière simple a posteriori la correction du témoin exhibé. Nous adoptons exactement cette démarche car le noyau de Coq (un véricateur de type du CCI) vérie le bon typage de chacun des termes que nous générons. Il n’y a pas besoin de faire conance à notre algorithme du point de vu du typage. Le contrôle du terme généré par le véricateur de type n’exonère pas de toute vérication. L’utilisateur souhaite que le comportement calculatoire de la chaîne d’analyse de cas soit celui du ltrage généralisé dont elle découle. Cette adéquation entre le terme généré et son origine est correcte si la règle de réduction donné section 2.1 est simulable sur le terme compilé au moyen de βι-réductions du CCI. Cette preuve est réalisée en deux étapes : 604.8 Eléments de correction — La simulation du ltrage par des réductions d’arbres de décision (gure 2.7). Cette preuve est identique au cas de ML traité par [38]. — La simulation des réduction d’arbres de décisions par les analyses de cas construites. Le lemme cruciale est le suivant : lorsqu’une analyse de cas supplémentaire sur l’un des arguments a été générée dans une branche pour raner son type (la situation expliquée section 4.4), cette analyse de cas va être systématiquement réduite lorsqu’elle arrive en tête. Ce lemme se prouve en raisonnant sur la forme de l’argument : l’argument a nécessairement une forme qui va réduire l’analyse de cas pour que le terme éliminé ait le bon type. Pour les autres situations, nos manipulations n’ont concerné que les annotations de types et la preuve est immédiate. Jean-François Monin avait montré l’apport d’une telle manière d’écrire des termes en Coq. Nous apportons la possibilité de les écrire automatiquement. En ce sens, cette partie constitue un pas en avant sur le chemin de la programmation certiée. 615 Simplifier un terme Écrire sans assistance un terme complexe dans un langage à types riches est une chose ardue. Des systèmes pour guider l’écriture de programmes ont donc été réalisés. Que ce soit au moyen de tactiques [21] ou d’un mode d’édition interactif [41], une fonctionnalité clé est de pouvoir écrire des termes « à trous » puis de demander au système quel doit être le type des termes à mettre dans ces trous. L’utilisateur n’a pas à fournir un terme de type syntaxiquement égal à celui attendu mais un type qui lui est convertible. Pour faciliter la compréhension, il est même souhaitable que le système n’ache pas le type qu’il a inféré pour le trou mais plutôt une forme réduite. Ce chapitre propose un algorithme pour obtenir une forme réduite d’un terme. Nous parlons de forme réduite et non de forme normale car la forme normale n’est pas le représentant le plus lisible d’une classe d’équivalence pour la conversion. En eet, pour un humain, une constante (au nom bien choisie) est plus explicite que sa dénition. Une δ-expansion ne doit avoir lieu que si elle induit d’autres réductions. Definition plus : nat → nat → nat := fix2 (pl : nat → nat → nat := λ(m n : nat) ⇒ case n predicate λ(_ : nat) ⇒ nat of |O:m |S:λ(n’ : nat) ⇒ S (pl m n’) end). Definition succ : nat → nat := plus (S O). Figure 5.1 – L’addition et le successeur De plus, dans le CCI tel qu’il est déni actuellement, lors de normalisations impliquant des points xes, déplier puis replier une constante est nécessaire. Considérons par exemple la dénition de plus donnée gure 5.1. La forme normale de plus (S (S x)) y n’est pas S (S (plus x y)) mais : S (S (fix1 (pl : nat → nat → nat := λ(m n : nat) ⇒ case m predicate λ(_ : nat) ⇒ nat of |O:n |S:λ(m’ : nat) ⇒ S (pl m’ n) end) x y)) Après une présentation de la méthode de normalisation utilisée, nous détaillerons un moyen d’obtenir la forme escomptée. 5.1 Normalisation en appel par nom Suivant les schéma de compilation usuels (voir par exemple [26, 36]), la réduction d’un terme est réalisée en le traduisant vers un langage particulier (l’évaluation), en calculant 635 Simplier un terme dans ce langage (le calcul) puis en retraduisant le résultat vers un terme (la réication). Notre langage cible est un état de machine abstraite. Un état de machine abstraite est la paire d’un terme et d’une pile où sont stockés les destructeurs de type à appliquer au terme. La syntaxe des piles est donnée par sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us ), sk | Zx (i, (f : T := t) : : u1 · · · us ), sk ◦ t représente un argument attendant d’obtenir la fonction à laquelle il est appliqué. ZcaseT(u1 · · · us) stocke les branches d’une analyse de cas en attendant de connaître le constructeur par lequel débute le terme ltré. Zfix (i, (f : T := t) : : u1 · · · us) est un point xe attendant de savoir si son argument récursif s’évalue sur un constructeur appliqué pour se déplier. L’évaluation débute en plaçant le terme à réduire en face de la pile vide (∅). Les destructeurs de termes sont empilés. Lorsqu’un constructeur de type est atteint, la tête de la pile est inspectée pour déclencher si possible un calcul. Les règles de calcul pour la β-réduction de λ(x : T) ⇒ t sont : ◦ u, sk –[t] → (x : T) k k t[u/x] sk ∅ –[t] → (x : T) k hλ(x : T) ⇒ t | ∅i La continuation k du calcul sera la fonction d’évaluation. Pour les règles ι et ϕ, il faut extraire de la tête de pile les arguments du constructeur (les nœuds ◦ t). Nous notons t1 · · · tn⊕sk une pile constituée des nœuds applications ◦ t1 · · · ◦ tn puis de sk (ne débutant pas par une application). Les règles de calcul pour le ie constructeur Cisont t1 · · · ts ⊕ ZcaseT(u1 · · · un), sk i →k k ui (◦ t1 · · · ◦ ts , sk) t1 · · · ts⊕ i →k k v[fixj (f : T := v)/f] Zx (j, (f : T := v) : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci t1 · · · ts ), sk) t1 · · · ts ⊕ ∅ i →k hCi | ◦ t1 · · · ◦ ts , ∅i Le calcul prend encore une fois sa continuation k en argument an que tous les appels de fonction dans la machine abstraite soient récursifs terminaux. L’évaluation suit les règles de réécriture de la gure 5.2. La continuation k attendue par les opérations de calculs est la vision fonctionnelle des règles d’évaluations. Formellement, k t sk = hv | sk’i si et seulement si ∆ ⊢ ht | ski ↓CBN hv | sk’i. Une fois qu’il n’y a plus de coupure en tête du terme, l’état de machine abstraite est réié pour retrouver un terme en replaçant autour de la valeur obtenue les destructeurs de termes restant. Le processus est décrit gure 5.3 Ce procédé permet d’obtenir la forme normale de tête faible d’un terme par un calcul en appel par nom. Pour obtenir la forme normale forte, il faut traverser les fonctions et les 645.1 Normalisation en appel par nom ∆ ⊢ htmi | ski i ↓CBN htmo | skoi ∆ ⊢ ht | ◦ u, ski ↓CBN hv | sk’i ∆ ⊢ ht u | ski ↓CBN hv | sk’i sk –[t] → (x : T) k hv | sk’i ∆ ⊢ hλ(x : T) ⇒ t | ski ↓CBN hv | sk’i ∆ ⊢ ht | ZcaseP(u1 · · · us ), ski ↓CBN hv | sk’i ∆ ⊢ hcase t predicate P of u1 · · · us end | ski ↓CBN hv | sk’i ∆ ⊢ hui | Zx (i, (f : T := t) : : u1 · · · ui-1), ski ↓CBN hv | sk’i ∆ ⊢ hfixi (f : T := t) | ◦ u1 · · · ◦ ui , ski ↓CBN hv | sk’i ∆ ⊢ fixi (f : T := t) | u1 · · · ui-k⊕∅ ↓CBN fixi (f : T := t) | u1 · · · ui-k⊕∅ k ≤ i ∆ ⊢ hx | ski ↓CBN hx | ski ∆ ⊢ hI | ◦ t1 · · · ◦ ts , ∅i ↓CBN hI | ◦ t1 · · · ◦ ts , ∅i ∆, (c : T := t), ∆’ ⊢ ht | ski ↓CBN hv | sk’i ∆, (c : T := t), ∆’ ⊢ hc | ski ↓CBN hv | sk’i ∆ ⊢ hS | ∅i ↓CBN hS | ∅i ∆ ⊢ h∀(x : S), T | ∅i ↓CBN h∀(x : S), T | ∅i sk i →k hv | sk’i ∆ ⊢ hCi | ski ↓CBN hv | sk’i Figure 5.2 – Call By Name abstract machine hu | ski ↑ v ht | ∅i ↑ t hcase t predicate T of u1 · · · us end | ski ↑ v ht | ZcaseT(u1 · · · us ), ski ↑ v ht u | ski ↑ v ht | ◦ u, ski ↑ v hfixi (f : T := u) t1 · · · ti-1 t | ski ↑ v ht | Zx (i, (f : T := u) : : t1 · · · ti-1), ski ↑ v Figure 5.3 – Réinterprétation d’un état comme une valeur 655 Simplier un terme produits an de normaliser leur corps puis appliquer récursivement le même processus aux termes qui apparaissent dans les éléments de la pile avant de réaliser la réication. Notre machine est inecace car elle réalise les substitutions une par une au lieu d’utiliser un environnement. Cette machine avec des environnements est une machine de Krivine [33] ou plutôt une machine de Krivine avec types algébriques [6] puisqu’elle manipule des inductifs. Nous la présenterons section 5.3. Avant cela, traitons le cœur de notre contribution, les repliages de constante. 5.2 Trace des constantes dépliées Nous ajoutons aux états de machine de la section précédente une liste des constantes dé- pliées convertibles au terme de l’état. Cette liste va permettre de savoir quelle constante replier. Nous utilisons une liste car nous souhaitons traiter ce que nous nommons une cascade de constantes. Il s’agit d’une situation où une constante est dénie grâce à une autre constante. Par exemple, nombre de fonctions (telles que incr_ids gure 5.1) sur les listes (celle du langage dénie gure 1.11) sont dénies grâce aux itérateurs sur les listes (comme list_map) qui eux sont dénis par point xe et analyse de cas . Definition list_map (A B : Set) (f : A → B) : list A → list B := fix1 (map : list A → list B := λ(l : list A) ⇒ case l predicate λ(_ : list A) ⇒ list B of |nil:nil B |cons:λ(h : A) (t : list A) ⇒ cons (f h) (map t) end). Definition incr_ids : list nat → list nat := list_map nat nat succ. Figure 5.4 – Exemple d’itérateur et d’une de ses instances Formellement, un dépliage est un triplet constitué d’un nom de constante et de deux listes de termes appelées les paramètres et les arguments. Une liste de dépliage p est un repliage du terme t noté t p si pour tous ses éléments la constante appliquée aux paramètres est convertible à t appliqué aux arguments. Le point xe pl a pour dépliage (plus,[],[]) qui n’a ni argument ni paramètre mais on comprend le sens des paramètres pour donner un dépliage du point xe map : (list_map,[S, T, t],[]) (avec S, T et t les valeurs de A, B et f dans le cas considéré). L’intérêt des arguments est illustré par : pl a pour dépliage alternatif (succ,[],[S O]) Les primitives dont nous avons besoin sur les listes de dépliages sont dénies telles que — Si t u p alors t add_arg u p. — Pour u donné, si λ(x : T) ⇒ t p et pour tout (c,params,args) ∈ p, on a soit (args = u, _) soit (args = ∅), alors t[u/x] add_param u p. — Si c p et ∆(c) = t alors t add_cst c p. 665.2 Trace des constantes dépliées par (** val add_arg : term → cst_stk → cst_stk *) let add_arg arg = List.map (fun (a,b,c) → (a,b,c @ [arg])) (** val add_param : term → cst_stk → cst_stk *) let add_param param p = List.map (fun (a,b,c) → match c with |[] → (a,b @ [param],c) |_ : :q → (a,b,q)) p (** val add_cst : cst → cst_stk → cst_stk *) let add_cst cst p = (c,[],[]) : : p Les noeuds de la pile qui détruisent un inductif sont modiés. Une liste de dépliage est ajoutée. Elle représente un repliage de la réication du terme et de la pile jusqu’à ce noeud inclus. Il existe une fonction eacement triviale qui permet de retrouver une pile de machine appel par nom à partir d’une pile avec les traces en supprimant ces annotations. sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us/p), sk | Zx (i, (f : T := t)/p : : u1 · · · us ), sk Les étapes de calcul et d’évaluation (gure 5.5) sont modiées de telle sorte à maintenir un repliage du terme de l’état de la machine. Nous nommons RN cette nouvelle machine. L’évaluation enregistre aussi les repliages des destructeurs d’inductif lorsqu’elle les empile. ◦ u, sk p –[t] → (x : T) k k (add_param u p) (t[u/x]) sk ∅ p –[t] → (x : T) k hλ(x : T) ⇒ t | ∅i Maintenant que la machinerie est en place, le calcul sur les inductifs et la réication peuvent en tirer avantage. Pour cela, nous dénissons la notion de meilleur repliage. Lors du calcul de succ (S m), le repliage du point xe à l’intérieur de sa dénition est [(plus,[],[]) ;(succ,[],[S O])]. La constante dépliée en premier, le premier élément de la cascade, est en fond de repliage. Nous voulons l’utiliser autant que possible pour remplacer le terme déplié. C’est possible si le terme à replier est appliqué aux arguments du dépliage (c’est bon pour succ si le premier argument de pl est S O). Si ce n’est pas le cas, nous essayons avec le dépliage suivant (plus dans notre exemple). Les fonctions qui choisissent le meilleur repliage sont refold_term et refold_state. La fonction refold_term travaille comme une substitution qui regarde les arguments de la variable à substituer pour choisir par quoi substituer. La fonction refold_state travaille elle sur un état de machine abstraite. Elle inspecte les termes en tête de pile pour choisir par quoi elle va remplacer le terme. Par construction, le nombre d’arguments des dépliages dans un repliage est une fonction croissante. Un dépliage n’ayant pas d’argument peut toujours être utilisé car il n’y a alors aucune condition sur le contexte. Nous ne conservons donc en pratique qu’un seul dépliage sans argument en tête du dépliage. Lors du calcul de incr_ids (cons x y), le repliage du point xe est [(map_list, [nat;nat;succ], []) ;(incr_ids,[],[])] mais nous ne gardons que [(incr_ids,[],[])] qui est toujours utilisable. Lors du dépliage d’un point xe, le meilleur repliage du point xe est utilisé dans la substitution plutôt que la dénition du point xe. 675 Simplier un terme ∆ ⊢p htmi | ski i ↓RN htmo | skoi s p –[t] → (x : T) k hv | s’i ∆ ⊢p hλ(x : T) ⇒ t | si ↓RN hv | s’i ∆ ⊢add_arg u p ht | ◦ u, si ↓RN hv | s’i ∆ ⊢p ht u | si ↓RN hv | s’i ∆ ⊢p h∀(x : S), T | ∅i ↓RN h∀(x : S), T | ∅i sk i →k hv | sk’i ∆ ⊢p hCi | ski ↓RN hv | sk’i ∆ ⊢∅ t | ZcaseT(u1 · · · us/p), sk ↓RN hv | sk’i ∆ ⊢p hcase t predicate T of u1 · · · us end | ski ↓RN hv | sk’i ∆ ⊢∅ ui | Zx (i, (f : T := t)/p : : u1 · · · ui-1), sk ↓RN hv | sk’i ∆ ⊢p hfixi (f : T := t) | ◦ u1 · · · ◦ ui , ski ↓RN hv | sk’i ∆ ⊢p fixi (f : T := t) | u1 · · · ui-k⊕∅ ↓RN fixi (f : T := t) | u1 · · · ui-k⊕∅ ∆ ⊢p hx | ski ↓RN hx | ski ∆ ⊢p hI | ◦ t1 · · · ◦ ts , ∅i ↓RN hI | ◦ t1 · · · ◦ ts , ∅i ∆, (c : T := t), ∆’ ⊢add_cst c p ht | ski ↓RN hv | sk’i ∆, (c : T := t), ∆’ ⊢p hc | ski ↓RN hv | sk’i ∆ ⊢p hs | ∅i ↓RN hs | ∅i Figure 5.5 – Refoldant Call By Name abstract machine 685.3 Refolding Algebraic Krivine Abstract Machine t1 · · · ts ⊕ ZcaseT(u1 · · · us/p), sk i →k k ∅ ui (◦ t1 · · · ◦ ts , sk) t1 · · · ts⊕ i →k k ∅ v[refold_term p/f] Zx (j, (f : T := v)/p : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci t1 · · · ts ), sk) t1 · · · ts ⊕ ∅ i →k hCi | ◦ t1 · · · ◦ ts , ∅i Lorsqu’un éliminateur d’inductif est replié, le meilleur repliage est utilisé plutôt que la construction elle-même (gure 5.6). hu | ski ↑ v ht | ∅i ↑ t refold_state p (case t predicate T of u1 · · · us end) | sk ↑ v t | ZcaseT(u1 · · · us/p), sk ↑ v ht u | ski ↑ v ht | ◦ u, ski ↑ v refold_state p (fixi (f : T := u) t1 · · · ti-1 t) | sk ↑ v t | Zx (i, (f : T := u)/p : : t1 · · · ti-1), sk ↑ v Figure 5.6 – Réication du repliage d’une valeur La correction de notre machine est garantie par le théorème : Pour tout terme t et toute pile de machine sk, si ∆ ⊢p ht | ski ↓RN hv | si, t p et ∆ ⊢ ht | eacement(sk)i ↓CBN hv’ | s’i alors ∆ ⊢ v 7→βδ v’ et les termes apparaissant dans l’eacement de s se réduisent modulo βδ vers le terme à la même place dans s’. Toutes les réductions ι et ϕ possibles ont été réalisées. 5.3 Refolding Algebraic Krivine Abstract Machine La machine présentée jusqu’ici fonctionne mais elle est inecace. Elle est calculatoirement inecace comme nous l’avons déjà remarqué section 5.1. Pire, sa capacité à réaliser les repliages est limitée. Ces deux sous-optimalitées se corrigent en améliorant les substitutions. Pour comprendre le problème avec les repliages, revenons sur l’exemple succ (S m). Le système répond S (plus (S O) n) et non S (succ n) car le dépliage du point xe a lieu avant la substitution de m par S O dans le corps du point xe. L’argument de l’appel récursif au moment de la substitution ne correspond pas à l’argument demandé pour replier par succ, ce choix est donc éliminé. D’autre part, en repliant par la meilleure constante à chaque fois, les δ-réductions ont lieu à chaque fois. Lors de la réduction de plus m (S (S n)), la constante plus est dépliée deux fois. En retardant la substitution, les alternatives peuvent toutes deux être conservées an que dans un calcul, le point xe soit utilisé et que durant la réication, la constante donne un terme concis. Nous modions notre machine pour qu’elle manipule non plus des termes mais des clô- tures, c’est-à- dire des paires (terme, substitution). La grammaire des substitutions est constituée de trois types de noeuds, le premier pour les termes non évalués, le deuxième pour les constructeurs déjà calculés (car ils sont l’argument 695 Simplier un terme récursif d’un point xe) et le troisième pour les points xes dépliés qui stockent la cascade de constantes dont ils sont issus. σ : := ∅ |  x := Sapp σ’(t), σ | ( x := Scstrj σ1(t1) · · · σs (ts ), σ ) | {x := Sxi σ’(f : T := t)/cst, σ } La pile est modiée car tous les termes deviennent des clôtures. Comme dans les substitutions, un noeud particulier est ajouté pour des valeurs déjà calculées. Une fois réduit sur un constructeur, l’argument récursif d’un point xe doit en eet être réempilé an de procéder au dépliage du point xe. La fonction l⊕sk doit maintenant aussi extraire ces noeuds spéciaux. Remarque Avec des valeurs qui sont des clôtures et non plus des termes, un comportement remarquable de la machine apparaît. Le calcul de l’argument récursif pour autoriser le dé- pliage d’un point xe introduit de l’appel par valeur au sein de notre machine en appel par nom. Avant d’avoir des substitutions, nous réions implicitement cette valeur avant de la remettre dans la pile. sk : := ∅ | ◦ σ(t), sk | ZcaseT(σ(u1 · · · us )/cst), sk | Zx (i, σ(f : T := t)/cst : : σ1(u1) · · · σi-1(ui-1)), sk | Zcstri σ1(t1) · · · σs (ts ), sk Les repliages ne sont pas profondément diérents hormis qu’ils manipulent des clôtures. (** val add_arg : term → subst → cst_stk → cst_stk *) let add_arg arg sigma p = List.map (fun (a,b,c) → (a,b,c @ [arg, sigma])) p (** val add_param : term → subst → cst_stk → cst_stk *) let add_param param sigma p = List.map (fun (a,b,c) → match c with |[] → (a,b @ [param, sigma],c) |_ : :q → (a,b,q)) p (** val add_cst : cst → cst_stk → cst_stk *) let add_cst cst p = (c,[],[]) : : p Le calcul ne fait plus de substitution, il enrichit la substitution de la clôture. Les règles de réécriture sont moins claires du fait des clôtures mais seul change réellement le fait d’interroger la substitution quand une variable est atteinte. A la n de l’évaluation, il faut retourner d’une clôture à un terme en appliquant eectivement la substitution avant de réier l’état de la machine. La propagation d’une substitution σ dans un terme t pour obtenir u est notée u ⋉ σ. Cette nouvelle machine est meilleure que la précédente si elle réalise plus de repliage tout en calculant toujours toutes les ϕ expansions et les ι réductions possibles. Le théorème le garantissant serait qu’en appliquant les substitutions à la sortie de la machine, on ait un terme qui se βδ réduise sur la sortie de la machine appel par nom avec repliage. 5.4 Configurabilité Trouver la manière optimale de réduire une constante n’est pas du ressort d’un ordinateur car la notion elle-même n’est pas dénie. Certaines constantes masquent des preuves sans 705.4 Congurabilité ◦ σ(u), sk p –[t] σ’ → (x : T) k k (add_param u σ p) t (  x := Sapp σ(u), σ’ ) sk Zcstri σ1(t1) · · · σs (ts ), sk ∅ –[t] σ→ (x : T) k k ∅ t ({x := Scstri σ1(t1) · · · σs (ts ), σ }) sk ∅ p –[t] σ→ (x : T) k hσ(λ(x : T) ⇒ t) | ∅i σ1(t1) · · · σs (ts ) ⊕ ZcaseT(σ(u1 · · · us )/p), sk i →k k ∅ ui σ (◦ σ1(t1) · · · ◦ σs (ts ), sk) σ1(t1) · · · σs (ts )⊕ i →k k ∅ v ( ( f := Sxj σ(f : T := v)/p, σ ) ) Zx (j, σ(f : T := v)/p : : σ’1(u1) · · · σ’j-1(uj-1)), (σ’1(u1) · · · σ’j-1(uj-1), sk Zcstri σ1(t1) · · · σs (ts ), sk) σ1(t1) · · · σs (ts ) ⊕ ∅ i →k hCi | σ1(t1) · · · σs (ts ), ∅i contenu calculatoire et qu’en général on ne souhaite pas déplier. Certaines constantes sont des applications partielles d’autres constantes que l’on ne souhaite déplier que si elles ont elles-même un nombre susant d’arguments pour poursuivre des calculs. Enn les constantes représentant des point xes construits non pas à partir d’une analyse de cas élémentaire sur leur argument récursif mais à l’aide d’un ltrage complexe ne doivent se déplier que si les arguments permettent d’atteindre une feuille de l’arbre de décision du ltrage et non pas uniquement si l’argument récursif commence par un constructeur. D’autres situations sont imaginables. Bref, il faut orir à l’utilisateur de congurer pour chaque constante globale son comportement vis à vis du dépliage. Notre machine peut en tout cas comprendre ces directives : — Ne jamais se déplier, c’est ne pas se déplier ! — Ne pas se replier, c’est ne pas être mis dans la trace des constantes dépliées. — Contrôler le nombre d’arguments, c’est compter le nombre de noeuds ◦ t en tête de pile. — Nous savons déjà geler le dépliage d’un point xe en attendant de savoir si son argument récursif se réduit sur un constructeur. Nous pouvons similairement ajouter le nécessaire pour réduire les arguments d’une constante an de contrôler s’ils permettent d’atteindre une feuille d’un arbre de décision donné. En pratique, une table stockant les arbres de décision sous-jacents pour toutes les constantes est dénie. Elle est interrogée lorsque le terme de l’état de la machine est une constante. Le premier argument sur lequel travaille l’arbre de décision est placé en tête de machine et on empile un noeud Zconst (cst, arg1 · · · args , split_tree) qui stocke la constante, les arguments déjà traités et l’arbre de décision qui reste à parcourir. Le calcul dans le cas des constructeurs est enn étendu pour gérer ces noeuds Zconst (cst, arg1 · · · args , st). Si l’arbre de décision restant à considérer (st) est vide, la constante cst’ est eectivement dépliée. Sinon, le prochain argument argsk qu’il faut évaluer est mis en tête. 715 Simplier un terme ∆ ⊢p hσ(tmi ) | ski i ↓RK hσ’(tmo) | skoi ∆ ⊢add_arg u σ p hσ(t) | ◦ σ(u), ski ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(t u) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(s) | ∅i ↓RK hσ(s) | ∅i ∆ ⊢p hσ(∀(x : S), T) | ∅i ↓RK hσ(∀(x : S), T) | ∅i ∆ ⊢∅ σ(t) | ZcaseT(σ(u1 · · · us )/p), sk ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(case t predicate T of u1 · · · us end) | ski ↓RK hσ’(v) | sk’i sk i →k hσ’(v) | sk’i ∆ ⊢p hσ(Ci ) | ski ↓RK hσ’(v) | sk’i skp –[t] σ→ (x : T) k hσ’(v) | sk’i ∆ ⊢p hσ(λ(x : T) ⇒ t) | ski ↓RK hσ’(v) | sk’i ∆ ⊢∅ σi (ui ) | Zx (i, σ(f : T := t)/p : : σ1(u1) · · · σi-1(ui-1)), sk ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(fixi (f : T := t)) | ◦ σ1(u1) · · · ◦ σi (ui ), ski ↓RK hσ’(v) | sk’i sk = ◦ σ1(u1) · · · ◦ σi-k(ui-k), ∅ ∆ ⊢p hσ(fixi (f : T := t)) | ski ↓RK hσ(fixi (f : T := t)) | ski ∆ ⊢p hσ(t) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p (σ”,  x := Sapp σ(t), σ”’ )(x) | sk ↓RK hσ’(v) | sk’i (◦ σ1(u)1 · · · ◦ σs (u) s , sk) i →k hσ’(v) | sk’i ∆ ⊢p’ h(σ”, {x := Scstri σ1(u1) · · · σs (us ), σ”’})(x) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p D σ(fixj (f : T := t)) | skE ↓RK hσ’(v) | sk’i ∆ ⊢p D (σ”, ( x := Sxj σ(f : T := t)/p’, σ”’) )(x) | skE ↓RK hσ’(v) | sk’i ∆ ⊢p σ(I) | ◦ σ1(t)1 · · · ◦ σs (t) s , ∅ ↓RK σ(I) | ◦ σ1(t)1 · · · ◦ σs (t) s , ∅ ∆, (c : T := t), ∆’ ⊢add_cst c p h∅(t) | ski ↓RK hσ’(v) | sk’i ∆, (c : T := t), ∆’ ⊢p hσ(c) | ski ↓RK hσ’(v) | sk’i Figure 5.7 – Refoldant Krivine Abstract Machine 725.5 Discussion 5.5 Discussion La congurabilité ne sut pas à orir toutes les possibilités. Dans notre implantation, certains choix sont codés en dur, d’autres sont impossibles. Nous les discutons ici. Cascade de constante Il existe des systèmes logiques comme Agda [14] ou Matita [1] dont les points xes sont « génératifs ». Les points xes n’y sont pas des objets locaux mais des constantes globales capables de s’appeler elles-mêmes. Le problème des repliages est alors bien moins critique. Par contre, dans le cas d’une constante dénie comme list_map appliquée à une fonction particulière, exprimer les appels récursifs en fonction de cette constante plutôt que de l’itérateur est un gain. Notre système est donc plus qu’une simulation du cas génératif en présence de cascade de constantes. Pour autant, la réponse apportée n’est pas idéale. Elle est extrêmement sensible à la syntaxe et suppose une expertise de l’utilisateur an d’être exploitable. Un simple échange d’argument et le système est perdu. Par exemple, en dénissant plus par récurrence sur son premier argument puis succ m par plus m (S O), l’information conservée au cours de la réduction de succ (S n) est que pl (S n) (S O) est repliable en succ (S n), ce qui est vrai mais inutile. Le résultat obtenu est alors seulement S (plus n (S O)). Points fixes mutuels Nous n’en avons pas parlé car ils ne changeaient jusqu’ici rien à notre étude mais Coq ore la possibilité de dénir des types de donnée et des points xes mutuellement récursifs. La machine abstraite ne conserve que les noms des constantes qu’elle a dépliées au cours de la réduction. Il n’y a donc aucun moyen direct de connaître le nom de la constante globale qui correspond à un appel récursif à un autre point xe du paquet ! Replier ou réduire Les constantes dénies à partir de list_map sont toujours convenablement repliables car la fonction est un paramètre de la dénition. Dans le cas de list_fold, par contre, l’accumulateur évolue et les appels récursifs ne s’expriment pas forcément en fonction de la première constante. Nous choisissons de privilégier la réduction (et donc le repliage utilisant list_fold) sur la conservation de la constante haut niveau. L’autre choix peut avoir des usages. Contrôler le nombre de dépliages Supposons qu’un utilisateur ait un type impliquant plus n (S (S O)) qu’il souhaite exprimer en fonction de plus n (S O) et non n. Il ne peut ni dire de ne pas déplier plus ni se contenter d’en autoriser le dépliage. Il lui faut un moyen d’autoriser un unique dépliage. L’implantation eective permet ce comportement en ranant le moment où elle autorise certaines réductions. 736 Etablir qu’un point fixe ne produit pas de calcul infini Prenons le point xe fix1 (f : ∀(n : nat), False := λ(n : nat) ⇒ f O). D’après les règles de la gure 1.9 section 1.4, si on oublie la condition Decr, ce terme du CCI est bien typé. Pourtant, f (S O), par exemple, est une preuve close de False. Ainsi, pour toute proposition logique P, il existe une preuve de P (cf gure 3.6). Cette preuve est case (fix1 (f : ∀(n : nat), False := f O)) (S O) predicate λ(_ : False) ⇒ P of end. Le programmeur n’est pas plus satisfait que le mathématicien. Ce point xe n’est pas autre chose qu’une boucle innie qui ne répondra jamais de valeur. Toutes les garanties que nous souhaitons apporter sur les preuves/programmes s’écroulent donc si nous ne nous assurons pas que la réduction des point xes termine. C’est justement le rôle du jugement qui demande, dans l’exemple, Decr(∆,λ(n : nat) ⇒ f O,f,1) (La syntaxe qui nous allons introduire est ∆ ;{f := STRICT, ∅} # 1 f hλ(n : nat) ⇒ f O | ARGi). Son objectif est d’imposer la terminaison par décroissance structurelle de f suivant son 1 er argument. Un point xe dont le corps vérie cette propriété est dit gardé. Ce chapitre décrit comment le jugement de garde est déni. Partant du principe de base de décroissance structurelle, nous introduirons une à une quelques subtilités permettant de traiter un nombre toujours plus grand de cas de décroissance structurelle. Les premiers ra- nements, qui concernent les branches impossibles ou les points-xes imbriqués, existent dans Coq depuis le travail de Gimenez [23]. Nous introduirons et justierons ensuite les nouveaux ranements suivants : propagation des conditions de décroissance à travers les coupures entrelacées, propagation des conditions de décroissance à travers les βιϕ-rédex garantissant la réduction forte, prise en compte de questions d’ecacité. 6.1 Décroissance structurelle Les points xes ont été introduits en CCI an de manipuler les structures de données ré- cursives. Ils ne permettent que cela. La construction d’un point xe est structurée autour d’un argument de type inductif explicitement nommé. Il est appelé argument récursif. L’argument i dans fixi (f : T := t) est le numéro de l’argument récursif. Le principe de la garantie de terminaison des points xes est : A chaque dépliage d’un point xe, au moins un des constructeurs de tête de l’argument récursif est consommé . 756 Etablir qu’un point xe ne produit pas de calcul inni Par exemple, un point xe f appliqué à S (S O) ne peut faire des appels récursifs qu’à f (S O) ou f O. Il consomme un ou deux constructeurs. La description de l’algorithme qui assure que l’argument récursif d’un point xe décroît structurellement repose sur les concepts énumérés ici. La vérication de la propriété se base sur une classication des variables libres apparaissant dans la dénition du corps du point xe. NO signie que la variable n’est pas sous-terme de l’argument récursif. STRICT signie qu’elle est sous terme de l’argument récursif. ARG qu’elle est l’argument récursif lui-même. La catégorie à laquelle appartient chaque variable libre est stockée au sein d’un environnement que nous noterons Ψ. L’environnement ∆ contient lui les dénitions des constantes globales. Deux phases distinctes se succèdent. D’abord ∆ ;Ψ # i f ht | πi , le jugement principal, parcourt un terme t (le corps du point xe) à la recherche des appels récursifs à f pour les vérier. Cette tâche comporte deux aspects : — Quand un lieur est traversé, le statut de sous-terme de la nouvelle variable libre introduite est déterminé et mémorisé dans l’environnement. — Quand un appel récursif à f est atteint, son i-ième argument est contrôlé. Le second jugement vérie que ce terme est sous-terme. Il utilise pour cela les valeurs de sousterme des variables libres collectées dans l’environnement au fur et à mesure du parcours du corps du point xe. ∆ ;Ψ ⋄ ht | πi = spec donne la spécication de sous-terme spec d’un terme t (l’argument en position récursive d’un appel récursif) grâce aux spécications de sous-terme de ses variables libres. Ce jugement est appelé par le premier à chaque fois qu’il atteint un appel récursif. Calculer une valeur de sous-terme Le dernier argument (π) des jugements est une pile. Comme une pile de machine abstraite, elle donne la valeur des variables correspondant aux lieurs en tête du terme à inspecter. La diérence est que c’est ici une valeur de sous-terme et non un terme qui est associé à une variable. En réalité, le deuxième jugement décrit gure 6.1 est eectivement une machine abstraite pour la β-réduction en appel par valeur. Il s’agit d’une machine qui calcule des spécications de sous-terme. Le premier jugement embarque cette machine abstraite an de lancer des calculs avec un environnement correct. Ces machines ont une règle particulière : ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ t1 | renforce1(c)1 · · · renforce1(c)s = o1 · · · ∆ ;Ψ ⋄ tn | renforcen(c)1 · · · renforcen(c)s = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o 766.1 Décroissance structurelle ∆ ;Ψ ⋄ ht | πi = out ∆ ;Ψ ⋄ hx | πi = Ψ(x) ∆ ;Ψ ⋄ h∆(c) | πi = o ∆ ;Ψ ⋄ hc | πi = o ∆ ;Ψ ⋄ hs | ∅i = NO ∆ ;{x := s, Ψ} ⋄ ht | πi = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out ∆ ;{x := NO, Ψ} ⋄ ht | ∅i = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out ∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ ⋄ ht | s, πi = out ∆ ;Ψ ⋄ ht u | πi = out ∆ ;Ψ ⋄ h∀(x : S), T | ∅i = NO ∆ ;Ψ ⋄ hC | πi = NO ∆ ;Ψ ⋄ hI | πi = NO ∆ ;  g := NO, Ψ ⋄ t | NO1 · · · NOk = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ t1 | renforce1(c)1 · · · renforce1(c)s = o1 · · · ∆ ;Ψ ⋄ tn | renforcen(c)1 · · · renforcen(c)s = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o Figure 6.1 – Calcul de la spécication de sous terme d’un terme 776 Etablir qu’un point xe ne produit pas de calcul inni Cette règle est la clé de voûte de la garantie de la terminaison. Elle utilise deux fonctions sur les valeurs de sous-terme à expliquer. — Nous souhaitons que n soit un sous-terme si t de type nat est l’argument récursif ou déjà un sous-terme dans case t predicate λ(m : nat) ⇒ T of |O:a |S:λ(n : nat) ⇒ b end. Plus génériquement, la spécication STRICT est assignée aux variables représentant les arguments des constructeurs dans les branche lorsque le terme ltré a la spécication ARG. Pas à toutes les variables, si le terme ltré a le type I t1 · · · ts , uniquement aux variables de type ∀ −−−−→ (x : S), I u1 · · · us . Les autres ont la spécication NO. En eet, le CCI autorise la dénition de constructeurs dont le type est polymorphe comme par exemple Inductive I : Set := | C :(∀(P : Set), P → P) → I. La condition sur les types des arguments du constructeur est donc indispensable an que ne puisse pas être admise la dénition non terminante : Definition Paradox : False := (fix1 (ni : I → False := λ(i : I) ⇒ case i predicate λ(_ : I) ⇒ False of |C:λ(f : ∀ (P : Set) , P → P) ⇒ ni (f _ i) end)) (C (λ(P : Set) (x : P) ⇒ x)). Formellement, la description de la machine utilise une fonction qui donne la caractéristique de sous-terme des arguments d’un constructeur "du bon type" dans une branche en fonction de la caractéristique de sous-terme de l’objet ltré. Sa spécication est bien plus complexe que sa dénition car il s’agit de dire renforcei (NO) = NO1 · · · NOs et renforcei (ARG) = STRICT1 · · · STRICTs pour les arguments de Ci non polymorphes (NO1 · · · NOs sinon). renforcei (STRICT) = STRICT1 · · · STRICTs — L’autre problématique est de fusionner les valeurs de sous-terme de chacune des branches an de répondre la valeur de sous-terme de l’ensemble d’une analyse de cas. C’est objet de l’opération × dénie gure 6.2. Cette opération se doit d’être associative commutative an de ne pas être inuencée par l’ordre des branches. L’assistant de preuve de votre choix le garantit très facilement. Il faut de plus une caractéristique pour l’analyse de cas à zéro cas. Un inductif à zéro cas ne pouvant jamais être construit dans un contexte cohérent, son élimination ne peut avoir lieu que dans des cas d’absurdité, c’est-à-dire dans du code mort. Nous introduisons donc une spécication de sous-terme DEAD qui caractérise du code mort et qui est l’élément absorbant de l’opération ×. Une analyse de cas qui analyse du code mort est nécessairement du code mort. Il est donc admissible de faire un appel récursif sur un terme de spécication DEAD. Il n’arrivera en eet pas ! De même, renforcei (DEAD) = DEAD1 · · · DEADs , une analyse de cas de code mort a des branches qui sont du code mort donc jamais les arguments des constructeurs ne seront habités. Il ne reste alors plus qu’à donner le premier jugement, celui qui fait le contrôle des appels récursifs, dans la gure 6.3. La garantie de la terminaison de l’évaluation de fixi (f : T := t) est 786.2 Ranement lié à l’induction × STRICT ARG DEAD NO NO NO NO NO NO DEAD STRICT ARG DEAD ARG ARG ARG STRICT STRICT Figure 6.2 – Fusion de la valeur de sous termes de deux branches le jugement ∆ ;{f := NO, ∅} # i f ht | ∅i. La correction de cette condition de garde a été démontrée par Eduardo Gimenez [23] grâce à un algorithme qui, pour tout point xe dénissable dans ce système, dénit un inductif dont le principe de récurrence simule le point xe. Retour sur les branches impossibles d’une analyse de cas Nous sommes à présent en pleine mesure de comprendre la section 4.6. Si v est l’argument récursif, quelle est la valeur de sous-terme de Vhd v ? L’astuce est que, grâce aux constructions que nous venons de faire, False_rect a la spéci- cation de sous-terme DEAD. La branche impossible de nil n’est donc pas un handicap au fait que la spécication du code suivant soit bien STRICT : case v predicate diag of |nil:False_rect True |cons:λ(n : nat) (h : A) (t : vect A n) ⇒ h end 6.2 Rainement lié à l’induction Dans le corps t d’un point xe f peut apparaître la dénition d’un autre point xe g. On parle alors de points xes imbriqués. La garde des point xes imbriqués n’est pas contrôlée simultanément. D’abord, t est typé. Comme la dénition de g est dans t, le fait que g est gardé est contrôlé durant cette phase. Ensuite, on vérie la terminaison de f et seulement de f. Par contre, durant la vérication de f, g apparaît bel et bien. Il faut alors attribuer une valeur de sous-terme à g. Il faut de même attribuer une valeur de sous-terme à f. La prudence dicte que la spécication de sous-terme de f et g soit NO. De même, ce n’est pas parce que le ie argument de g est un STRICT quand f appelle g que le ie argument de g lors d’un appel récursif dans la dénition de g restera un argument de spécication STRICT. Il est donc indispensable que tous les arguments de g aient la spécication NO. Voilà justiée la règle ∆ ;Ψ # i f hT | ∅i ∆ ;  g := NO, Ψ # i f t | NO1 · · · NOk ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E et l’appel initial ∆ ;{f := NO, ∅} # i f ht | ∅i. 796 Etablir qu’un point xe ne produit pas de calcul inni ∆ ;Ψ # i f ht | πi ∆ ;Ψ # i f hx | πi ∆ ;Ψ # i f hI | πi ∆ ;Ψ # i f hS | ∅i ∆ ;{x := s, Ψ} # i f ht | πi ∆ ;Ψ # i f hλ(x : S) ⇒ t | s, πi ∆ ;Ψ # i f hs | ∅i ∆ ;Ψ # i f hC | πi ∆ ;Ψ # i f hS | ∅i ∆ ;{x := NO, Ψ} # i f ht | ∅i ∆ ;Ψ # i f hλ(x : S) ⇒ t | ∅i ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ # i f ht | s, πi ∆ ;Ψ # i f ht u | πi ∆ ;Ψ # i f hc | πi si = STRICT ∨ si = DEAD ∆ ;Ψ # i f f | s1 · · · sk ∆ ;Ψ # i f hS | ∅i ∆ ;{x := NO, Ψ} # i f hT | ∅i ∆ ;Ψ # i f h∀(x : S), T | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;  g := NO, Ψ # i f t | NO1 · · · NOk ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ # i f ht1 | renforce1(c)i · · · ∆ ;Ψ # i f htn | renforcen(c)i ∆ ;Ψ # i f hcase u predicate T of t1 · · · tn end | πi Figure 6.3 – Contrôle de la décroissance structurelle de f selon son i-ème argument. 806.3 Ranement lié aux coupures entrelacées Pourtant, deux considérations peuvent améliorer l’expressivité : 1. Même si les arguments de g en général peuvent devenir complètement quelconques au fur et à mesure des appels récursifs, l’argument récursif a lui l’obligation de décroître. Ainsi, si g est appelé avec un argument STRICT en position récursive, cet argument ne peut que rapetisser lors d’appels récursifs et rester donc forcément STRICT. La pile des arguments peut ne pas être complètement réinitialisée ; l’argument récursif a le droit de garder sa valeur. 2. Les variables représentant les points xes peuvent avoir la spécication STRICT. Il y a alors une forme de raisonnement par récurrence : Pour calculer si l’ensemble de la dénition d’un point xe est sous-terme, supposons que les appels récursifs qui apparaissent dans cette dénition sont sous-terme. La règle implémentée est donc ∆ ;Ψ # i f hT | ∅i ∆ ;  g := STRICT, Ψ # i f D t | NO1 · · · NOj-1, sj , NO1 · · · NOk-jE ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E et l’appel initial ∆ ;{f := STRICT, ∅} # i f ht | ∅i. Cette optimisation est présente dans les versions précédant la version 8.4 de Coq. La condition de garde jusque la version 8.3 de Coq est strictement composée des règles présentées jusqu’ici appliquées à la forme normale du corps du point xe. Nous abordons maintenant les ranements postérieurs qui constituent la contribution originale de ce manuscrit. 6.3 Rainement lié aux coupures entrelacées Le chapitre 4 a montré que les coupures entrelacées étaient essentielles à l’écriture d’analyse de cas dépendant. La contre-partie regrettable est que sont perdues en chemin les valeurs de sous-terme des arguments de l’analyse de cas. Avec les jugements des gures 6.3 et 6.1 fix1 (f : . . . := λ(x : nat) ⇒ . . . case . . . predicate . . . of . . . |λ(. . . : . . .) (x’ : nat) ⇒ f (pred x’) . . . end x . . .) est refusé car x’ n’est pas vu comme ARG. Une solution de contournement est simple. La pile des arguments construite avant d’atteindre une analyse de cas est transmise à chacune des branches de cette analyse de cas. Néanmoins, cette manoeuvre est mal typée. Les branches impossibles peuvent donc ne pas être en adéquation avec leur pile. Un invariant ne tient plus. La pile en regard d’un produit ou d’une sorte n’est plus forcément vide. La règle qui assure la terminaison d’une analyse de cas devient ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ # i f ht1 | renforce1(c), πi · · · ∆ ;Ψ # i f htn | renforcen(c), πi ∆ ;Ψ # i f hcase u predicate T of t1 · · · tn end | πi 816 Etablir qu’un point xe ne produit pas de calcul inni An de gérer la terminaison des branches impossibles (et donc d’un type incompatible avec la pile qui leur est présentée), nous modions les règles à propos des constructeurs de type (sorte et produit) pour qu’elles acceptent une pile : ∆ ;Ψ # i f hs | πi 6.4 Rainement lié à la réduction 6.4.1 Garder la forme βιδ normale Pour partager du code en utilisant par exemple des constantes globales, il arrive d’écrire des points xes dont le corps contient des coupures. Or, la présence de coupure perturbe la vérication de la terminaison. Un exemple extrême est de dénir la constante app qui applique une fonction à son argument. Si f est le point xe que l’on contrôle, app f x n’est pas gardé car f n’est appliqué directement à aucun argument donc pas à un sous-terme alors que f x peut être gardé si x est STRICT. Nous devons donc vérier non pas le corps du point xe mais la forme normale du corps du point xe. Pour le faire, nous simulons les β, lesι et les ϕ réductions au sein de nos jugements. Pour réaliser les ι réductions, le plus simple est d’ajouter une spécication de sous-terme qui signie : être le ie constructeur dont les arguments ont les spécications de sous-terme s1 · · · sn. Pour cela la règle qui donne la spécication d’un constructeur est modiée pour devenir ∆ ;Ψ ⋄ D Cj | c1 · · · cs E = CONSTRj (c1 · · · cs ) Parallèlement, la fonction renforce est enrichie d’une règle qui simule la ι-reduction en rendant leur spécication aux arguments du constructeur et rendant les autres branches code mort : renforcei (CONSTRj (o1 · · · os )) = o1 · · · os si i = j et DEAD1 · · · DEADs sinon. Pour réaliser les β-réductions, nous allons retrouver une pile et un environnement de machine abstraite standard où des termes sont stockés. Les nœuds qui stockent un terme sont notées WEAK(Ψ,t). Ils seront aussi notés STRONG(Ψ,t) dans certains cas. Cette deuxième construction est la conséquence d’une optimisation qui va être détaillée à la n de cette section. Le calcul des valeurs de sous-terme est identique dans les 2 cas. La vérication des appels récursifs pourrait être réalisée en n’utilisant que WEAK(Ψ,t). Des nœuds "variables libres dont la spécication de sous-terme est s" restent nécessaires. Nous les notons ⊤s. La fonction renforcei (s) est elle aussi modiée suite au changement de type des éléments de la pile. Si elle renvoyait o1 · · · os , elle renvoie maintenant ⊤o1 · · · ⊤os . Puisque l’environnement stocke parfois des termes et non des valeurs de sous-terme directement, la fonction ∆ ⇓ hs | πi = o présentée gure 6.4 permet de recalculer cette spécication de sous-terme. La description exhaustive de la machine qui normalise un terme et en calcule sa spécication de sous-terme en appel par nom est donnée gure 6.5. 826.4 Ranement lié à la réduction ∆ ⇓ hs | πi = o ∆ ⇓ h⊤s | πi = s ∆ ;Ψ ⋄ ht | πi = o ∆ ⇓ hSTRONG(Ψ,t) | πi = o ∆ ;Ψ ⋄ ht | πi = o ∆ ⇓ hWEAK(Ψ,t) | πi = o Figure 6.4 – Forcer le calcul d’une valeur de sous terme ∆ ;Ψ ⋄ ht | πi = out ∆ ⇓ hΨ(x) | πi = out ∆ ;Ψ ⋄ hx | πi = out ∆ ;{x := s, Ψ} ⋄ ht | πi = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out ∆ ;{x := ⊤NO, Ψ} ⋄ ht | ∅i = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht | ⊤c, πi = out ∆ ;Ψ ⋄ ht u | πi = out ∆ ;Ψ ⋄ hs | πi = NO ∆ ;Ψ ⋄ h∀(x : S), T | πi = NO ∆ ⇓ hc1 | ∅i = o1 · · · ∆ ⇓ hcs | ∅i = os ∆ ;Ψ ⋄ D Cj | c1 · · · cs E = CONSTRj (o1 · · · os ) ∆ ;Ψ ⋄ hI | πi = NO ∆ ⇓ D sj | ∅E = CONSTRk (c1 · · · cs ) ∆ ; ( g := WEAK(Ψ,fixj (g : T := t)), Ψ ) ⋄ t | s1 · · · sk = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ h∆(c) | πi = o ∆ ;Ψ ⋄ hc | πi = o ∆ ⇓ D sj | ∅E = o’ ∆ ;  g := ⊤STRICT, Ψ ⋄ D t | ⊤NO1 · · · ⊤NOj-1, ⊤o’, ⊤NO1 · · · ⊤NOk-jE = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht1 | renforce1(c), πi = o1 · · · ∆ ;Ψ ⋄ htn | renforcen(c), πi = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o Figure 6.5 – Calcul de la spécication de sous terme d’un terme 836 Etablir qu’un point xe ne produit pas de calcul inni Cette description donne une seconde règle pour le point xe an de réaliser la ϕ réduction en protant de la même machinerie. 6.4.2 Retrouver la réduction forte Vérier que la forme normale du corps d’un point xe vérie la condition de garde est insusant à assurer la normalisation forte. Prenons l’exemple Fixpoint aie (n : nat) : nat := (λ(x : nat) ⇒ O) (aie O)., la forme normale du corps : λ(n : nat) ⇒ O est bien évidemment gardée. Son évaluation en appel par valeur, par contre, rentre dans une boucle innie ! Il faut donc vérier quand même les arguments des applications avant de les mettre dans la pile. La vérication à faire est un peu plus faible. Les arguments sont systématiquement évalués dans un contexte vide lors d’un calcul en appel par valeur. De ce fait, des variables libres en position d’argument récursif ne peuvent jamais déclencher de ϕ-réductions. La règle qui vérie une application est donc ∆ ;Ψ i f hu | ∅i ∆ ;Ψ # i f ht | WEAK(Ψ,u), πi ∆ ;Ψ # i f ht u | πi Une nouvelle valeur de sous terme NEUTRAL est ajoutée qui stipule qu’une variable est une variable libre. Les fonctions sur les valeurs de sous-terme sont enrichies par renforcei (NEUTRAL) = NEUTRAL1 · · · NEUTRALs et la table du produit des valeurs de sous-terme est complétée par rapport à la gure 6.2 par × CONSTRi (c1 · · · cs ) NEUTRAL NO NO NO DEAD CONSTRi (c1 · · · cs ) NEUTRAL ARG NO* ARG but WEAK STRICT NO* NEUTRAL NEUTRAL CONSTRi (c1 · · · cs ) but WEAK NEUTRAL CONSTRj (c’1 · · · c’s ) CONSTRi (c1 × c’1 · · · cs × c’s ) Nous appelons garde faible le jugement ∆ ;Ψ i f hu | πi. Il assure que t en position d’argument est gardé. Il est déni par les règles : Vérier faiblement les arguments des valeurs (constructeurs, inductifs, variables libres) n’est pas susant. Les jugements correspondants doivent contrôler "normalement" les corps des arguments qui ont été mis dans la pile. 6.4.3 estions d’eicacité Les règles de déduction du jugement de vérication de la garde présenté gure 6.6 ne sont pas dirigées par la syntaxe puisque les constantes globales et les applications apparaissent toutes deux dans deux jugements diérents. L’introduction des éléments de pile 84 Ing´enierie des applications Web : r´eduire la complexit´e sans diminuer le contrˆole Julien Richard-Foy To cite this version: Julien Richard-Foy. Ing´enierie des applications Web : r´eduire la complexit´e sans diminuer le contrˆole. Software Engineering. Universit´e de Rennes 1, France, 2014. French. HAL Id: tel-01087372 https://hal.inria.fr/tel-01087372 Submitted on 5 Jan 2015 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.N o d’ordre : 00000 ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : Informatique École doctorale Matisse présentée par Julien RICHARD-FOY préparée à l’unité de recherche IRISA – UMR6074 Institut de Recherche en Informatique et Système Aléatoires ISTIC Ingénierie des applications Web : ré- duire la complexité sans diminuer le contrôle Thèse soutenue à Rennes le 9 décembre 2014 devant le jury composé de : Lionel SEINTURIER Professeur à l’université de Lille 1 / Rapporteur Manuel SERRANO Directeur de recherche à Sophia Antipolis / Rapporteur Erwan LOISANT Consultant à Zengularity / Examinateur François BODIN Professeur à l’IRISA / Examinateur Jean-Marc JÉZÉQUEL Directeur de l’IRISA / Directeur de thèse Olivier BARAIS Maître de conférence à l’IRISA / Co-directeur de thèse■❧ s❡♠❜❧❡ q✉❡ ❧❛ ♣❡r❢❡❝t✐♦♥ s♦✐t ❛tt❡✐♥t❡✱ ♥♦♥ q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à ❛❥♦✉t❡r ♠❛✐s q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à r❡tr❛♥❝❤❡r par Antoine de Saint-Exupéry ❊❛❝❤ s✐❣♥✐✜❝❛♥t ♣✐❡❝❡ ♦❢ ❢✉♥❝t✐♦♥❛❧✐t② ✐♥ ❛ ♣r♦❣r❛♠ s❤♦✉❧❞ ❜❡ ✐♠♣❧❡♠❡♥t❡❞ ✐♥ ❥✉st ♦♥❡ ♣❧❛❝❡ ✐♥ t❤❡ s♦✉r❝❡ ❝♦❞❡✳ ❲❤❡r❡ s✐♠✐❧❛r ❢✉♥❝t✐♦♥s ❛r❡ ❝❛rr✐❡❞ ♦✉t ❜② ❞✐st✐♥❝t ♣✐❡❝❡s ♦❢ ❝♦❞❡✱ ✐t ✐s ❣❡♥❡r❛❧❧② ❜❡♥❡✜❝✐❛❧ t♦ ❝♦♠❜✐♥❡ t❤❡♠ ✐♥t♦ ♦♥❡ ❜② ❛❜str❛❝t✐♥❣ ♦✉t t❤❡ ✈❛r②✐♥❣ ♣❛rts✳ par Benjamin PierceRemerciements Je remercie Lionel ❙❡✐♥t✉r✐❡r, Professeur à l’université de Lille 1, et Manuel ❙❡r✲ r❛♥♦, Directeur de recherche à Sophia Antipolis, d’avoir bien voulu accepter la charge de rapporteur. Je remercie Erwan ▲♦✐s❛♥t, Consultant à Zengularity, et François ❇♦❞✐♥, Professeur à l’IRISA, d’avoir bien voulu juger ce travail. Je remercie enfin Olivier ❇❛r❛✐s et Jean-Marc ❏é③éq✉❡❧, qui ont dirigé ma thèse.Table des matières ❚❛❜❧❡ ❞❡s ♠❛t✐èr❡s ✶ ■♥tr♦❞✉❝t✐♦♥ ✺ ■ ❈♦♥t❡①t❡ ❡t ét❛t ❞❡ ❧✬❛rt ✾ ✶ ❈♦♥t❡①t❡ ❡t ♣♦rté❡ ❞❡ ❧❛ t❤ès❡ ✶✶ 1.1 Architecture des applications Web . . . . . . . . . . . . . . . . . . . . . 11 1.2 Partage de code entre les parties client et serveur d’une application Web 13 1.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4 Portée de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ✷ ➱t❛t ❞❡ ❧✬❛rt ✶✾ 2.1 Styles d’architecture pour les applications Web résilientes . . . . . . . . 19 2.1.1 Architecture des applications Web interactives . . . . . . . . . . 20 2.1.2 Prise en charge du mode déconnecté . . . . . . . . . . . . . . . . 23 2.1.3 Travail coopératif assisté par ordinateur . . . . . . . . . . . . . . 24 2.1.4 ❊✈❡♥t s♦✉r❝✐♥❣ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2 Partage de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Langages dédiés implémentés comme une bibliothèque . . . . . 27 2.2.2 Langages lourds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.3 Ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . 30 2.2.4 Pouvoir d’expression des langages dédiés externes . . . . . . . . 31 2.2.5 Langages dédiés compilés et implémentés comme une bibliothèque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.6 Méta-programmation et évaluation partielle . . . . . . . . . . . . 35 2.2.7 ▲✐❣❤t✇❡✐❣❤t ▼♦❞✉❧❛r ❙t❛❣✐♥❣ et ❥s✲s❝❛❧❛ . . . . . . . . . . . . . . . 35 2.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 ■■ ❈♦♥tr✐❜✉t✐♦♥s ✹✶ ✸ P❛rt❛❣❡ ❞❡ ❝♦❞❡ ✹✸ 12 Table des matières 3.1 API des sélécteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2 Manipulation de valeurs optionnelles . . . . . . . . . . . . . . . . . . . . 46 3.3 Définition de fragments de HTML . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1 Représentation statiquement typée de chaînes de caractères contenant des expressions JavaScript . . . . . . . . . . . . . . . . . . . 50 3.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 ✹ ❙ûr❡té ❞✉ t②♣❛❣❡ ✻✶ 4.1 Inventaire des fonctions problématiques . . . . . . . . . . . . . . . . . . 61 4.1.1 createElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.2 getElementsByTagName . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.3 addEventListener . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Solutions bien typés et conservant le même pouvoir d’expression . . . . 65 4.2.1 Généralisation des solutions existantes . . . . . . . . . . . . . . . 65 4.2.2 Utilisation des types paramétrés . . . . . . . . . . . . . . . . . . 66 4.2.3 Utilisation des types dépendants . . . . . . . . . . . . . . . . . . 67 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ✺ ❯♥ st②❧❡ ❞✬❛r❝❤✐t❡❝t✉r❡ ♣♦✉r ❧❡s ❛♣♣❧✐❝❛t✐♦♥s ❲❡❜ rés✐❧✐❡♥t❡s ✼✸ 5.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Fonctionnement du système de synchronisation . . . . . . . . . . . . . . 74 5.2.1 Scénario mono-utilisateur . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2 Scénario multi-utilisateur . . . . . . . . . . . . . . . . . . . . . . 76 5.3 Généralisation du composant de synchronisation . . . . . . . . . . . . . 77 5.4 Évolution : fonctionnement complètement hors-ligne . . . . . . . . . . . 77 5.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 ■■■ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✸ ✻ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✺ 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table des matières 3 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 ❇✐❜❧✐♦❣r❛♣❤✐❡ ✾✹ ❚❛❜❧❡ ❞❡s ✜❣✉r❡s ✾✺4 Table des matièresIntroduction En automatisant certaines tâches et traitements d’informations, les technologies de l’information et de la communication (TIC) permettent de réaliser des économies considérables sur nos activités. Elles sont une importante source d’activités économiques, parfois qualifiée de « troisième révolution industrielle »[Rif08]. Illustrons ce propos par un exemple concret : le co-voiturage. Ce système vise à diminuer le nombre de véhicules sur les routes, et, par voie de conséquence, leurs émissions de gaz à effet de serre, en maximisant leur taux d’occupation par la mutualisation des voyages de différentes personnes. Le co-voiturage nécessite la collecte d’informations sur les trajets proposés par les conducteurs et les passagers, leur mise en relation ainsi qu’un processus de paiement. Les outils numériques, en automatisant ces tâches et traitements d’informations, facilitent considérablement la pratique du co-voiturage. En effet, utiliser, par exemple, des petites annonces dans la presse pour informer les passagers potentiels des trajets proposés par un conducteur, puis utiliser des courriers postaux pour organiser le voyage entre les personnes intéressées serait beaucoup plus contraignant (par exemple, chercher un trajet nécessiterait de parcourir manuellement l’intégralité des annonces, et les délais de mise en relation entre les personnes leur imposeraient de s’organiser très en avance). L’essor des TIC a permis au leader français du co-voiturage, BlaBlaCar, de rendre service à plus de 6 millions d’usagers. Ces outils numériques sont utilisés depuis des machines telles qu’un ordinateur, un téléphone ou une tablette. Les échanges d’information entre ces machines nécessitent qu’elles soient reliées en réseau. Dans ce contexte, le Web offre un environnement propice à la mise en place d’outils numériques : ceux-ci sont hébergés par des s❡r✈❡✉rs, qui centralisent les informations et coordonnent les utilisateurs. Ces derniers accèdent aux outils depuis leurs terminaux ❝❧✐❡♥ts, quels qu’ils soient (ordinateur, té- léphone ou tablette), en utilisant un navigateur Web, sans aucune étape d’installation. Lorsqu’un utilisateur interagit avec un tel outil, les actions qu’il effectue depuis sa machine sont éventuellement transmises au serveur. Par exemple, lorsqu’un passager décrit, depuis son ordinateur personnel, le voyage qu’il souhaite effectuer, cette information est transmise au serveur hébergeant l’application de co-voiturage qui lui indique, en retour, quels conducteurs prévoient de faire un voyage similaire. Toutefois, la réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la ❞✐st❛♥❝❡ entre les postes client et serveur. 56 Introduction D’une part, la distance physique (ou distance ♠❛tér✐❡❧❧❡) entre les machines nécessite qu’une connexion réseau soit toujours établie entre elles pour que l’application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les effets de latence lors des échanges d’information entre machines ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le serveur ? Des travaux ont proposé de prendre en charge le mode déconnecté en s’appuyant sur un système de persistence des données, côté client, capable de se synchroniser automatiquement lorsque la connexion réseau le permet [KLYY12, MGPW13]. Cependant, cette approche n’offre aucun moyen de régler les conflits dus à des modi- fications concurrentes des données. La gestion de ces conflits, quant à elle, a fait l’objet de nombreuses recherches, et un algorithme adapté aux spécificités du Web a été proposé en 2011 [SLLG11]. Bien que ces technologies apportent isolément des éléments de solutions, elles ne fournissent pas aux développeurs un cadre architectural pour que leurs applications soient, par construction, résilientes aux pannes de réseau. D’autre part, l’environnement d’exécution est différent entre les clients et serveurs, produisant une distance ❧♦❣✐❝✐❡❧❧❡. En effet, côté client c’est un navigateur Web qui exécute le code du programme, lequel est généralement écrit en JavaScript. De l’autre côté, c’est un serveur Web, éventuellement implémenté avec un autre langage que JavaScript, qui traite les requêtes des clients. Certains aspects d’une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation des données saisies dans un formulaire ou certains calculs métier. En effet, construire les pages Web depuis le serveur facilite le référencement de leur contenu par les moteurs de recherche, mais les construire depuis le client produit une meilleure expérience utilisateur. De même, effectuer la validation des données des formulaires depuis le client offre une meilleure expérience utilisateur mais cette validation doit être effectuée de nouveau sur le serveur pour des raisons de sécurité. Cependant les langages de programmation et, surtout, les interfaces de programmation (API) étant différentes entre les deux parties, cela entrave les possibilités de réutilisation de code entre elles. Par conséquent, les développeurs dupliquent des concepts entre les parties client et serveur, bien que cela soit plus coû- teux à maintenir. Certaines technologies permettent le partage de code entre clients et serveurs [JW07, Can08], mais ce code partagé n’est pas capable de tirer parti des spécificités des environnements client et serveur, il nécessite une couche d’adaptation coûteuse en performance. En intégrant directement dans le langage les aspects communs aux parties client et serveur [RT10], le compilateur peut produire du code exécutable tirant parti des spécifités des plateformes cibles, mais cette approche demande un effort d’implémentation beaucoup plus important. Pour faciliter le processus d’ingénierie des applications Web, un challenge consiste à raccourcir cette distance, tant matérielle que logicielle. Cela signifie offrir un modèle de développement permettant aux développeurs de ne pas avoir à gérer ces difficultés sans pour autant masquer l’aspect distribué des architectures Web ni les spécificités de chaque environnement d’exécution. En effet, masquer complètement l’aspect distribué d’un système diminuerait la capacité à bénéficier des avantages de cette ar-Introduction 7 chitecture [GF99] (e.g. ubiquité des données). De même, masquer les spécificités des environnements client et serveur diminuerait les performances d’exécution [RFBJ13a]. Les travaux de cette thèse cherchent à raccourcir cette distance entre les parties client et serveur des applications Web, tout en préservant la capacité à tirer parti de cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs. Le premier axe de travail est la réduction de la distance matérielle : comment concevoir une application Web de telle sorte qu’elle fonctionne aussi bien, quelle que soit la latence due à la distance entre les machines reliées en réseau, voire quand la connexion est rompue ? Nous répondons à cette question en proposant un modèle d’architecture découpant le code de l’application de façon à isoler la préoccupation de communication client-serveur et la logique métier. Grâce à ce modèle d’architecture nous avons été capables de capitaliser la logique de synchronisation entre clients et serveurs sous forme d’une bibliothèque réutilisable. Le deuxième axe de travail complète le premier. En effet, notre modèle d’architecture conduit à partager certains concepts côtés client et serveur. En particulier, les types de données décrivant les actions du système existent des deux côtés. Le besoin de partager des concepts entre clients et serveurs n’est, cependant, pas caractéristique de notre modèle d’architecture, et l’on observe plusieurs initiatives visant à faciliter la réutilisation de code entre clients et serveurs. Notre solution réutilise la bibliothèque js-scala, qui fournit un mécanisme d’évaluation retardée permettant à un même programme d’être évalué dans un navigateur Web ou dans l’environnement d’exécution du serveur (une JVM) [KARO12]. Notre contribution consiste en un ensemble de bibliothèques bâties sur js-scala, fournissant des API de haut niveau pour traiter certains aspects des applications Web, et produisant du code tirant parti des spécificités des environnements client et serveur. En particulier, ❉♦♠❖♣s pour la manipulation du DOM d’une page Web et ❢♦r❡st pour la définition de fragments de pages Web. En pratique, nous avons observé que la taille du code écrit avec nos outils est du même ordre de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et 35% à 50% plus petite que celle d’un code bas-niveau, mais que les performances d’exécution du programme obtenu sont du même ordre de grandeur que celles d’un code bas-niveau et 39% à 972% meilleures qu’un code haut-niveau. Nos travaux sont basés sur le langage Scala, qui est statiquement typé. Bien que le typage dynamique apporte aussi des avantages, des travaux ont rapporté que le typage statique peut jouer un rôle important pour faciliter la gestion de la complexité d’un programme [KHR+12, MHR+ ]. Cependant, l’utilisation d’un langage statiquement typé pour écrire du code s’exécutant sur les navigateurs Web a soulevé un nouveau problème : ce code fait appel aux API du navigateur, dont les fonctions sont destinées à être utilisées depuis le langage dynamiquement typé JavaScript, et auxquelles il peut être difficile de faire correspondre une signature typée sans perte d’information. En effet, certaines fonctions fondamentales de l’API du navigateur exposent des types de données trop généraux, contraignant le développeur à écrire des conversions descendantes de type (❞♦✇♥❝❛st✐♥❣), contournant ainsi le système de vérification de types, donc le conduisant éventuellement à écrire du code incorrect. En nous appuyant sur les mécanismes de paramètres de type ou de types membres des langages de pro-8 Introduction grammation, notre troisième contribution est une façon d’exposer des signatures de type pour ces fonctions, de telle sorte qu’elles fournissent suffisamment d’information pour éviter aux développeurs de réaliser des conversions de types, tout en conservant le même pouvoir d’expression. Comparée aux autres approches utilisées pour exposer l’API du navigateur dans un langage statiquement typé, notre approche permet de réduire le nombre de fonctions tout en préservant le même pouvoir d’expression. Ainsi, nos trois contributions permettent de diminuer la complexité du développement d’applications Web tout en donnant autant de contrôle aux développeurs.Première partie Contexte et état de l’art 9Chapitre 1 Contexte et portée de la thèse Ce chapitre détaille les problèmes d’ingénierie des applications Web dus aux distances matérielle et logicielle entre les postes client et serveur. Nous présentons d’abord les enjeux architecturaux découlant de la distance maté- rielle entre clients et serveurs, puis les obstacles au partage de code entre les environnements client et serveur à cause de leur distance logicielle. Ensuite, nous soulignons les difficultés à exposer l’interface de programmation des navigateurs Web dans un langage de programmation statiquement typé. Enfin, nous terminons ce chapitre en exposant les questions de recherche adressées par nos travaux. 1.1 Architecture des applications Web L’architecture d’un système peut supprimer certains problèmes techniques ou isoler certaines préoccupations, rendant le système moins complexe, donc plus facile à comprendre et faire évoluer. Dans le cas des applications Web, nous distinguons deux niveaux d’architecture : matériel et logiciel. L’architecture matérielle correspond à la disposition matérielle des machines reliées entre elles. Dans le cas des applications Web, il s’agit d’une architecture centralisée : plusieurs clients se connecte à un même serveur pour accéder à ses services. L’architecture logicielle correspond à l’organisation du code d’une application donnée, elle décrit la façon dont les différentes parties du code s’assemblent et leur responsabilités respectives. L’architecture matérielle du Web a pour avantage de permettre un accès ubiquitaire aux données : celles-ci étant stockées sur un serveur distant, l’utilisateur peut les consulter depuis plusieurs postes clients (par exemple depuis son ordinateur de bureau et son téléphone). En outre, si plusieurs utilisateurs accèdent à un même document, ils peuvent collaborer bien plus facilement que s’ils devaient s’envoyer, à tour de rôle, une copie modifiée d’un même document. Enfin, un dernier avantage est que le stockage des données est mutualisé : les postes clients n’ont pas besoin de disposer d’une grande quantité de mémoire pour utiliser une application. Toutefois, les architectures Web ont également certains désavantages. Par exemple, 1112 Contexte et portée de la thèse les utilisateurs peuvent percevoir de la latence due aux échanges d’information entre les postes clients et serveurs. De plus, la nature centralisée des architectures Web peut poser des problèmes de gestion de montée en charge pour les serveurs, si le trafic est irrégulier et intense. Enfin, une application Web ne peut être utilisée que si une connexion réseau est établie entre les postes client et serveur, or certains appareils (par exemple les téléphones mobiles) ne disposent que d’une connexion intermittente. L’objectif de cette thèse est de proposer des moyens logiciels pour construire des applications Web bénéficiant des avantages présentés précédemment sans souffrir des inconvénients dus à la distance matérielle entre clients et serveurs. En particulier, un aspect qui nous préoccupe est la rés✐❧✐❡♥❝❡ aux aléas du réseau : comment faire pour que la qualité de l’expérience utilisateur soit le moins possible affectée par une coupure de la connexion réseau ? Une telle coupure rend impossibles les échanges d’information entre le client et le serveur. Par conséquent, la préservation de l’expérience utilisateur n’est possible que si le client a déjà téléchargé suffisamment d’information pour pourvoir les fonctionnalités utilisées. Illustrons cela par un cas pratique. Imaginons une application permettant de gérer une liste de tâches à effectuer : les utilisateurs peuvent ajouter des tâches et indiquer quand elles sont réalisées. Le fonctionnement traditionnel des applications Web est le suivant : lorsqu’un utilisateur crée une nouvelle tâche ou indique qu’une tâche est réalisée, cette demande est transmise au serveur, celui-ci met à jour l’état du système en lui ajoutant la tâche créée, puis il envoie au client les informations lui permettant de mettre à jour l’interface utilisateur de façon à montrer à l’utilisateur qu’une tâche a été ajoutée. Maintenir les fonctionnalités de cette application lorsque le client est dé- connecté du serveur nécessite de faire évoluer et afficher l’état du système localement, sur le poste client, sans solliciter le serveur. Cependant, le fait de permettre à l’utilisateur d’utiliser le système en étant déconnecté induit un nouveau problème : l’état du système sur son poste client diverge de l’état du système sur le serveur, il devient alors nécessaire de synchroniser l’état du système du client vers le serveur, lorsque la connexion est de nouveau établie. Dans le cas d’un système permettant le travail collaboratif, la synchronisation doit prendre en compte le fait que deux utilisateurs peuvent effectuer des modifications concurrentes et parfois conflictuelles sur une même ressource. Reprenons notre exemple d’application de gestion de tâches. Lorsque la connexion est de nouveau établie, le client doit transmettre au serveur le nouvel état du système, tel qu’il a évolué suite à son utilisation. Cependant, si deux utilisateurs, Alice et Bob, utilisent le système en étant déconnecté, ils partent du même état et le font chacun évoluer différemment. Par exemple, Alice peut créer une nouvelle tâche, et Bob indiquer qu’une autre tâche a été réalisée. Quand ils se reconnectent, le processus de synchronisation doit faire converger les trois états (celui du serveur et ceux des clients d’Alice et Bob). En outre, si, en mode déconnecté, Alice supprime une tâche et Bob indique que cette même tâche a été réalisée, puis qu’Alice se reconnecte et se synchronise avec le serveur avant Bob, quand Bob se synchronise avec le serveur, celui-ci doit gérer le fait que la tâche que Bob a indiqué être réalisée a entretemps été supprimée par Alice.Partage de code entre les parties client et serveur d’une application Web 13 Plusieurs approches sont possibles dans ce cas. La plus simple pour les développeurs est aussi la moins satisfaisante pour les utilisateurs, elle consiste à ne rien faire de particulier sur le serveur en cas de modifications conflictuelles. Dans notre cas, cela peut se traduire par la levée d’une erreur lors de la synchronisation de Bob, car il demande au serveur de modifier une tâche qui n’existe pas. Cette approche conduit, dans le meilleur des cas, à l’affichage d’erreurs chez les clients, mais elle peut également ne pas détecter les conflits et faire converger le système vers un état qui ne reflète pas l’intention initiale des utilisateurs. Par exemple, si, en mode déconnecté, Alice demande de supprimer toutes les tâches réalisées pendant que Bob indique qu’une nouvelle tâche a été réalisée. Si Bob se synchronise avant Alice, la synchronisation de cette dernière peut conduire à ne pas supprimer la tâche nouvellement indiquée comme étant réalisée, alors qu’Alice avait initialement l’intention de supprimer toutes les tâches réalisées. Nous ne souhaitons par remettre en cause l’architecture matérielle des applications Web, car elle fournit de nombreux avantages. Notre objectif est de trouver une solution au niveau logiciel. Un style d’architecture pour construire des applications Web résilientes est un style d’architecture qui isole la préoccupation de résilience ou réduit le travail à effectuer par les développeurs pour parvenir à construire des applications résilientes. Une conséquence du fait que les côtés client et serveur soient tous les deux amenés à exécuter les traitements métiers (côté client, pour obtenir la propriété de résilience, côté serveur pour maintenir l’état de référence du système) est que la logique métier risque de se trouver dupliquée dans le code des programmes client et serveur. Cette duplication n’est pas souhaitable par l’ingénieur logiciel qui doit alors maintenir deux bases de code cohérentes entre elles. Un moyen d’éviter la duplication consiste à partager le même code. Cette idée est détaillée dans la section suivante. 1.2 Partage de code entre les parties client et serveur d’une application Web En fait, plusieurs aspects d’une application Web gagnent à être partagés entre clients et serveurs. Par exemple, vérifier, côté client, que les données saisies dans un formulaire sont valides contribue à améliorer l’expérience utilisateur car celui-ci n’a pas besoin d’attendre de soumettre l’intégralité d’un formulaire pour voir apparaître les erreurs. Cependant, ces règles de validation doivent également être appliquées côté serveur, au cas où un utilisateur mal intentionné contournerait la validation côté client. De même, la construction des pages HTML a intérêt à être réalisée côté serveur, pour obtenir un meilleur référencement du contenu par les moteurs de recherche, mais elle a aussi intérêt à être réalisée côté client, là encore, pour améliorer l’expé- rience utilisateur, en n’actualisant qu’une partie du document plutôt qu’en rechargeant la page entière. En outre, il est intéressant de gérer la navigation (la relation entre une URL et le contenu de la page correspondante) côté serveur, toujours pour des raisons de référencement par les moteurs de recherche, mais également côté client,14 Contexte et portée de la thèse encore pour des raisons d’exérience utilisateur. Enfin, certains calculs effectués sur le domaine métier d’un système peuvent également être exécutés côtés client et serveur. Tous ces exemples illustrent un besoin général, dans les applications Web, d’être capable de partager des concepts entre clients et serveurs. Cependant, ce besoin est difficile à satisfaire car les environnements d’exécution des programmes client et serveur ne sont pas les mêmes. Premièrement, les langages de programmation peuvent être différents : côté client le langage supporté par tous les navigateurs est JavaScript, tandis que côté serveur le choix du langage peut être déterminé par des raisons techniques (inter-opérabilité avec l’existant, compétences des collaborateurs, etc.). Mais surtout, le contexte d’exécution n’est pas le même. Côté client, le programme s’exé- cute dans un navigateur et est associé à un contexte local au client (document HTML, stockage local, etc.). Côté serveur, le programme s’exécute derrière un serveur HTTP et est associé à l’état global du système. Illustrons ces différences par un exemple concret : la construction de fragments HTML. Côté client, celle-ci aboutit à la construction d’un fragment de DOM, c’est-à- dire un arbre d’éléments HTML sur lequel il est possible d’effectuer des manipulations (e.g. ajout, suppression, déplacement de nœuds) ou de réagir à des événements produits par l’utilisateur sur certains nœuds (e.g. clic de souris). Côté serveur, elle aboutit à un un texte représentant la structure des éléments HTML. Ces différences sont illustrés figure 1.1. Le listing 1.1 donne le code JavaScript qui permet de construire cet arbre, côté client, et le listing 1.2 donne le code Scala qui permet de construire le fragment de HTML, côté serveur. Ces deux exemples illustrent le fait que construire un même fragment de HTML, côté client ou côté serveur, ne se fait pas de la même façon. 1.3 Sûreté du typage Nous avons réalisé nos travaux en nous appuyant sur le langage Scala, qui a la particularité d’être statiquement typé. Bien que le typage dynamique ait également ses avantages, nous observons que l’utilisation d’un langage à typage statique pour écrire la partie client d’une application Web n’est pas marginale : GWT [JW07], Dart [WL12], TypeScript [Fen12] 1 , Kotlin [Kot], Opa [RT10], SharpKit [Sha], HaXe [Can08], Ocsigen [Bal06], Elm [Cza12], Idris [Bra13] ou PureScript [Pur] sont autant d’exemples de langages à typage statique utilisés pour écrire la partie client d’applications Web. La partie client d’une application Web a pour rôle de réagir aux actions de l’utilisateur et de mettre à jour le document affiché. Cela s’effectue en utilisant des fonctions fournies par l’interface de programmation (API) du navigateur Web. Or, cette API a été conçue pour être utilisée depuis le langage JavaScript, qui est dynamiquement typé, et il est parfois difficile de définir une signature de type correcte pour certaines fonctions. 1. Soulignons toutefois que, dans le cas de Dart et TypeScript, le système de types n’est pas aussi contraignant que les systèmes de types statiques habituels. En effet, les erreurs de typage produisent seulement des avertissements plutôt que des erreurs de compilation. Ce comportement est voulu et a vocation à faciliter une migration d’une base de code non typée vers du code typé [BAT14, EMSS].Sûreté du typage 15 Figure 1.1 – Un formulaire tel qu’il est perçu par l’utilisateur (en haut), est représenté par un arbre d’éléments HTML côté client, et par un texte côté serveur. var ui = function (emailValue) { var email = document.createElement(’input’); email.name = ’email’; email.placeholder = ’Email’; email.value = emailValue; var pwd = document.createElement(’input’); pwd.name = ’pwd’; pwd.placeholder = ’Password ’; var button = document.createElement(’button ’); button.appendChild(document.createTextNode(’Sign in’)); var form = document.createElement(’form’); form.action = ’/authenticate ’; form.method = ’POST’; form.appendChild(email); form.appendChild(pwd); form.appendChild(button ); return form } Listing 1.1 – Définition du fragment de HTML représentant le formulaire montré dans la figure 1.1, côté client, en JavaScript : un arbre est construit progressivement, par ajout successif de nœuds.16 Contexte et portée de la thèse def ui(email: String ): Html = html"""

""" Listing 1.2 – Définition du fragment de HTML représentant le formulaire montré dans la figure 1.1, côté serveur, en Scala : une chaîne de caractères utilise une représentation textuelle du fragment de HTML. Le préfixe html permet une interpolation sûre de la valeur email var img = createElement("img"); img.src = "/icon.png"; var input = createElement("input"); input.value = "foo"; Listing 1.3 – Utilisation de la fonction createElement en JavaScript Par exemple, la fonction createElement a la signature de type suivante, d’après sa spécification standard [HTM] : Element createElement(String name); Notons que le type de retour indiqué est Element. Néanmoins, l’appel createElement(’input’) retourne plus précisément un nœud de type InputElement représentant un champ de formulaire. De même, l’appel createElement(’img’) retourne plus précisément un nœud de type ImageElement représentant une image. Ces deux types, InputElement et ImageElement, n’ont pas les mêmes propriétés. Par exemple, le type InputElement possède une propriété value contenant la valeur du champ du formulaire. De même, le type ImageElement possède une propriété src contenant l’URL de l’image. Ce détail n’a aucune importance pour les développeurs utilisant le langage JavaScript mais est problématique dans un langage statiquement typé. En effet, considérons le listing 1.3, écrit en JavaScript et créant une image et un champ de formulaire. Dans cet exemple, nous accédons à la propriété src de l’image et à la propriété value du champ de formulaire. Dans un monde statiquement typé, ce listing, bien que correct, produirait une erreur de typage car les propriétés src et value ne sont pas définies pour le type général Element. Ainsi, la signature de type standard de la fonction createElement ne convient pas, telle quelle, aux langages statiquement typés. Notons enfin, que le langage JavaScript permet d’écrire le listing 1.3 mais il permet également d’écrire des programmes incorrects. Par exemple, il est possible, en JavaScript, d’écrire un programme accédant à une propriété src d’un objet de typePortée de la thèse 17 InputElement bien que ce type ne possède pas de telle propriété. Idéalement, on aimerait avoir une signature de type telle que le listing suivant, en Scala, compile sans problème, sauf la dernière ligne : val img = createElement("img") img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie De même, le listing suivant doit compiler, sauf la dernière ligne : val input = createElement("input") input.value = "foo" // Ok input.src = "/icon.png" // Erreur: propriete ’src’ non definie Autrement dit, après avoir créé un élément, il doit être possible d’utiliser toutes ses propriétés. Par contre, l’utilisation d’une propriété non définie pour ce type d’élément doit provoquer une erreur de typage. Dès lors, quelle signature de type définir pour la fonction createElement ? Plus généralement, y a-t-il d’autres fonctions qui souffrent d’un problème similaire, et comment le résoudre ? 1.4 Portée de la thèse Les sections précédentes ont soulevé plusieurs problèmes. Nos travaux s’intéressent en particulier aux questions de recherche suivantes : RQ1 Quel style d’architecture logicielle adopter pour isoler les problèmes dus à la distance matérielle entre clients et serveurs (latence, indisponibilité de l’application en mode déconnecté) ? RQ2 Comment partager du code entre les parties client et serveur malgré leurs différences ? RQ3 Comment interfacer le monde dynamiquement typé des navigateurs avec un langage statiquement typé en préservant la sûreté du typage et sans perdre de pouvoir d’expression ? Le reste de ce document est organisé comme suit. Le prochain chapitre détaille l’état de l’art relatif aux trois questions de recherches formulées. Le chapitre 3 montre comment nous avons défini des abstractions qui, bien qu’elles soient utilisables côtés client et serveur, ne souffrent pas de problèmes de performance (RQ2). Dans le chapitre 4 nous montrons qu’il est possible de définir, pour certaines fonctions de l’API du navigateur, des signatures de type garantissant une sûreté du typage et préservant le même pouvoir d’expression que l’API native (RQ3). Le chapitre 5 présente un sytle d’architecture ainsi que l’implémentation d’un composant logiciel réutilisable pour construire des applications Web résilientes (RQ1). Enfin, le chapitre 6 présente une synthèse des contributions ainsi que des perspectives de recherche.18 Contexte et portée de la thèseChapitre 2 État de l’art Ce chapitre présente les réponses que des travaux antérieurs apportent aux questions de recherche traitées par cette thèse. La préoccupation de résilience étant une préoccupation technique transverse, la section 2.1 s’intéresse aux styles d’architecture logicielle permettant d’isoler cette pré- occupation. La section 2.2 compare les méthodes existantes pour partager du code entre les parties client et serveur. Enfin, la section 2.3 recense les travaux visant à interfacer les langages statiquement typés et dynamiquement typés. 2.1 Styles d’architecture pour les applications Web résilientes L’ingénierie des applications Web a fait l’objet de nombreuses recherches. En 2002, Roy T. Fielding ❡t✳ ❛❧✳ ont proposé le style d’architecture ❘❊♣r❡s❡♥t❛t✐♦♥❛❧ ❙t❛t❡ ❚r❛♥s✲ ❢❡r (REST) [FT02]. Ce style d’architecture définit un ensemble de contraintes sur le fonctionnement et l’interaction des services Web, de façon à minimiser les problèmes de latence tout en minimisant le couplage des services Web. Cependant, REST se limite au côté serveur des applications Web : il ne donne aucune préconisation sur la façon d’intégrer les parties client et serveur des applications Web. En effet, les applications Web ont, entretemps, évolué. Notamment, la partie client est devenue beaucoup plus riche : elle ne se contente plus simplement d’afficher le contenu des pages et de naviguer entre les liens hypertextes, mais elle permet des interactions riches (déroulement de menus, etc.) et, surtout, une navigation asynchrone (quand l’utilisateur clique sur un lien hypertexte, le client ne remplace pas la page actuelle par la nouvelle, mais met à jour une partie du document actuel). Cette évolution se traduit par une plus grande quantité de code et de nouvelles responsabilités pour la partie client d’une application Web [Mar09]. Ainsi, une application Web comporte désormais deux applications : une application côté serveur, chargée de traiter les actions des clients et d’exposer les données du système, et une application côté client, chargée de répondre aux interactions de l’uti- 1920 État de l’art Figure 2.1 – Les modèles MVC (à gauche) et PAC (à droite) lisateur, éventuellement en transmettant ses actions à l’application côté serveur, et en actualisant l’affichage en fonction de l’évolution de l’état du système. L’utilisateur final utilise l’application côté client, qui elle-même utilise l’application côté serveur. 2.1.1 Architecture des applications Web interactives Cette section présente les styles d’architectures utilisés dans les applications interactives et leurs évolutions conduisant aux applications Web interactives. 2.1.1.1 Architecture des applications interactives Les deux principaux styles d’architcture pour les applications interactives sont ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r [KP88] et Pr❡s❡♥t❛t✐♦♥✲❆❜str❛❝t✐♦♥✲❈♦♥tr♦❧ [Cou87]. Dans les deux cas, les préoccupations identifiées sont la logique métier (▼♦❞❡❧ ou ❆❜str❛❝t✐♦♥), l’interface utilisateur (❱✐❡✇ ou Pr❡s❡♥t❛t✐♦♥) et le lien entre les deux (❈♦♥tr♦❧❧❡r ou ❈♦♥tr♦❧). La principale différence entre les deux modèle, illustrée figure 2.1, est que, dans le cas du modèle PAC, la responsabilité de l’❆❜str❛❝t✐♦♥ s’arrête à la logique métier : elle ne communique pas avec l’interface utilisateur, contrairement au modèle MVC, et elle ne fait même pas l’hypothèse qu’une interface utilisateur existe. Notons également que la littérature mentionne aussi l’architecture ▼♦❞❡❧✲❱✐❡✇✲Pr❡s❡♥t❡r (MVP), qui est en réalité complètement équivalente au modèle PAC. Ainsi, le modèle PAC isole mieux les différents aspects des applications interactives : la partie ❆❜str❛❝t✐♦♥ contient la logique métier et est réutilisable dans une application non interactive. La partie Pr❡s❡♥t❛t✐♦♥ contient tout ce qui est spécifique à la technologie d’affichage choisie. Elle n’est pas liée à une application en particulier. Enfin, la partie ❈♦♥tr♦❧ rend l’❆❜str❛❝t✐♦♥ interactive en l’affichant à l’aide d’une Pr❡✲ s❡♥t❛t✐♦♥ et en interprétant les actions de l’utilisateur en termes d’actions métier. 2.1.1.2 Architecture des applications collaboratives interactives Les modèles PAC et MVC sont adaptés aux applications mono-utilisateur. Dans le cas où plusieurs utilisateurs manipulent en même temps une même ressource, de nouveaux problèmes se posent, notamment de gestion de la cohérence de l’information entre les différents utilisateurs. Duval ❡t✳ ❛❧✳ ont montré comment adapter le modèle PAC aux applications collaboratives. Ils proposent de dupliquer des instances de modèle PAC sur chaque clientStyles d’architecture pour les applications Web résilientes 21 Figure 2.2 – Le modèle PAC-C3D et de les faire communiquer entre elles au niveau des composants ❈♦♥tr♦❧. Ces composants se voient infliger une nouvelle responsabilité : gérer la cohérence des données entre les différents clients. Cette responsabilité est coordonnée par un serveur, maintenant l’état de référence du système. La figure 2.2 illustre le modèle PAC-C3D dans le cas d’un serveur et un client. Le serveur n’a pas de composant de Pr❡s❡♥t❛t✐♦♥ puisque son rôle se limite à de la synchronisation d’information : il reçoit les modifications effectuées par un client et les transmet aux autres clients. Le modèle PAC-C3D a l’avantage d’être simple et bien découpé : chaque composant n’a que peu de responsabilités. Cependant, il fait l’hypothèse d’une connexion réseau fiable et ne gère pas les conflits dues à des modifications concurrentes par des utilisateurs distants. 2.1.1.3 Architecture des applications Web interactives En 2007, Morales-Chaparro ❡t✳❛❧✳ ont proposé un ensemble de modèles d’architecture pour les applications Web. Ces modèles sont tous des variations du modèle ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r (MVC), couramment utilisé pour la conception d’applications interactives. Les variantes proposées par ces auteurs s’adaptent à l’importance de l’application côté client. Dans une première variante, ils suggèrent d’utiliser MVC côté serveur seulement. C’est-à-dire que c’est le serveur qui est responsable de la construction de la page HTML affichée par le serveur (partie ❱✐❡✇), d’interpréter les requêtes HTTP en termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ) et de mettre à jour l’état du système en fonction des actions métier (partie ▼♦❞❡❧). Dans cette variante, il n’y a pas d’application côté client, cela correspond donc au cas des applications Web d’antan. Une autre variante consiste à utiliser MVC côté client seulement. C’est-à-dire que c’est le client qui est responsable de la construction de la page HTML qu’il affiche (partie ❱✐❡✇), d’interpréter les interactions de l’utilisateur (e.g. clics sur des boutons) en termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ), et de mettre à jour l’état du système en fonction des actions métier (partie ▼♦❞❡❧). Dans leur modèle, cette dernière partie est également responsable de transmettre l’évolution de l’état du système à un ▼♦❞❡❧ analogue, côté serveur. Dans cette variante, l’application est plus maigre sur le serveur que sur le client. Néanmoins, la partie ▼♦❞❡❧ existe des deux côtés, client et serveur. Enfin, les auteurs ont également proposé des modèles hybrides, où les trois parties22 État de l’art a) b) c) Figure 2.3 – Trois variantes d’architectures dérivées du modèle Model-View-Controller. a) MVC côté serveur ; b) MVC côté client ; et c) MVC hybride côtés client et serveur. (▼♦❞❡❧, ❱✐❡✇ et ❈♦♥tr♦❧❧❡r ) existent côtés client ❡t serveur. La figure 2.3 illustre ces variantes. Notons que dans tous les cas les applications client et serveur sont reliées entre elles par leur composant ▼♦❞❡❧, contrairement au modèle PAC-C3D présenté dans la section précédente, où les applications client et serveur sont reliées par leur composant ❈♦♥tr♦❧. Ces modèles d’architecture permettent de découper le code d’une application complète en parties correspondant à différents aspects (l’interface utilisateur, la logique métier et le lien entre les deux). Ce découpage a des avantages pour le développeur, qui peut plus facilement raisonner sur chaque aspect indépendamment des autres, mais il a également des avantages structurels : par exemple, la logique métier peut être utilisée indépendamment de l’interface utilisateur, elle est donc plus facilement testable. Par ailleurs, ces modèles d’architecture ont chacun des caractéristiques techniques qui les rendent plus ou moins appropriés selon les usages attendus de l’application. Le premier modèle est le plus simple à mettre en œuvre car il comporte peu de composants. Il comporte également un aspect technique intéressant : les pages étant construites sur le serveur, leur contenu est mieux référencé par les moteurs de recherche. Son inconvénient est qu’une application bâtie sur ce modèle n’offre pas une expérience utilisateur agréable (navigation synchrone). Le modèle où l’essentiel du code de l’application est côté client permet d’offrir une meilleur expérience utilisateur, mais il nécessite de dupliquer la partie ▼♦❞❡❧ côtés client et serveur. Ce modèle, contrairement au précédent, ne permet pas au contenu des pages d’être bien référencé par les moteurs de recherche. Les modèles hybrides permettent d’avoir à la fois une bonne expérience utilisateur et un bon référencement du contenu par les moteurs de recherche, au prix d’une duplication des parties ▼♦❞❡❧ et ❱✐❡✇ côtés client et serveur.Styles d’architecture pour les applications Web résilientes 23 Ce panel de modèles d’architecture témoigne surtout d’un aspect caractéristique des applications Web : le code de l’application doit être réparti entre le client et le serveur. Selon le type d’application on peut choisir de mettre plus de code sur le serveur que sur le client, ou inversement. Roberto Rodríguez-Echeverría a d’ailleurs identi- fié que cet aspect est, avec le processus de synchronisation client-serveur, une source majeure de complexité dans l’ingénierie des applications Web [RE09]. Il a également souligné que les méthodes d’ingénierie des applications Web devraient prendre en compte le fait que la connexion réseau peut être intermittente. À ce jour, personne n’a encore proposé de style d’architecture permettant le travail en mode déconnecté et automatisant la synchronisation au retour de la connexion. Intégrer la préoccupation de résilience nécessite de surveiller les échanges d’information entre clients et serveurs afin de choisir une stratégie de secours au cas où une requête échouerait. Les modèles d’architecture présentés précédemment font tous l’hypothèse d’une connexion réseau fiable. Si une interruption survient, l’effet d’une action de l’utilisateur sur l’état du système ne peut plus être transmis au serveur. Il est alors nécessaire de détecter le problème, d’en avertir l’utilisateur par une notification et, si possible, d’essayer d’envoyer à nouveau, un peu plus tard, la requête ayant échoué. De telles modifications impacteraient tant la partie interface utilisateur que la partie métier. En particulier, l’ensemble de la couche métier serait affectée car toutes les modifications des données doivent être transmises au serveur. Nous voyons ainsi que la préoccupation de résilience est une préoccupation transverse. 2.1.2 Prise en charge du mode déconnecté Dès 2000, Yun Yang a formulé l’essentiels des besoins auxquels doivent répondre les applications Web pour permettre le travail collaboratif en mode déconnecté : notamment le fait que la partie client doit contenir suffisamment d’information pour pourvoir les fonctionnalités de l’application, et la nécessité de synchroniser l’état du système avec le serveur au retour de la connexion [Yan00]. Plus récemment, Marco ❡t✳ ❛❧✳ ont proposé un modèle de description de site Web prenant en charge le mode déconnecté [MGPW13]. Leur modèle permet de définir comment l’utilisateur peut naviguer à travers les pages d’un site contenant de l’information et leur système génère un site Web utilisable en mode déconnecté. Cependant leur modèle se limite aux systèmes dont l’état n’évolue pas, il n’est donc pas approprié pour représenter une application dont l’état évolue suite aux actions de l’utilisateur. Kao ❡t✳ ❛❧✳ [KLYY12] ont implémenté une plateforme d’exécution d’applications Web prenant en charge le mode déconnecté et capable d’adapter le contenu des pages aux appareils mobiles (✐✳❡✳ téléphones). Leur plateforme fournit des bibliothèques pour stocker des données sur les postes clients et les synchroniser avec le serveur. Cependant, leur contribution se limite à une infrastructure logicielle : ils n’indiquent pas comment concevoir une application bénéficiant de cette infrastructure. Cet effort de conception reste donc à faire par les développeurs. En outre, leur solution de synchronisation ne gère pas les conflits.24 État de l’art 2.1.3 Travail coopératif assisté par ordinateur Indépendamment des recherches sur les architectures des applications Web, dans le domaine du travail coopératif assisté par ordinateur des travaux se sont intéressés spécifiquement aux méthodes de synchronisation de l’état d’un système distribué. Une méthode de synchronisation a pour but de faire converger les multiples répliques du système qui existent sur chaque client, après qu’elles ont évolué indépendamment les unes des autres. 2.1.3.1 Synchronisation basée sur les données Une première approche consiste à observer la façon dont les données évoluent sur les différentes répliques et à transmettre les changements aux autres répliques. Ainsi, Brett Cannon ❡t✳ ❛❧✳ ont rendu résilient un système de persistence en le dotant d’un mécanisme de synchronisation qui observe les modifications et les synchronise dès que possible avec le serveur [CW10]. L’intégration d’une telle technologie de persistence avec les modèles d’architectures présentés précédemment devrait permettre de traiter la préoccupation de résilience de façon transparente et isolée : la couche métier s’appuierait sur cette technologie de persistence résiliente, les autres parties du code n’auraient pas besoin d’être modifiées. Les ❈♦♥✢✐❝t✲❢r❡❡ ❘❡♣❧✐❝❛t❡❞ ❉❛t❛ ❚②♣❡s (CRDT) sont une approche similaire [SPBZ11]. L’idée est de modéliser le domaine du système à l’aide de types de données dont les opérations sont toutes commutatives, par construction. Ainsi, les effets de deux opé- rations concurrentes convergent toujours, sans générer de conflit. L’inconvénient de cette approche c’est que l’utilisation d’un tel type de données est contraignant, pour les développeurs, pour modéliser le domaine du système. L’inconvénient des approches basées sur les données est leur mauvaise gestion de la résolution des conflits. Illustrons cela à l’aide de l’exemple d’application de gestion de tâches donné en section 1.1. Prenons une situation où Alice supprime une tâche donnée, et Bob, de façon concurrente, fait passer l’état de cette même tâche de l’état réalisée à non réalisée. Un système de synchronisation placé sur le serveur et basé sur les données recevrait les modifications du système dues aux clients l’une après l’autre. S’il reçoit d’abord la modification de Bob, puis la suppression d’Alice, il applique les mêmes modifications sur son système, dans cet ordre, et termine dans un état où la tâche est supprimée. S’il reçoit d’abord la suppression d’Alice, puis la modification de Bob, il se retrouve dans une situation où il doit appliquer une modification sur une donnée qui a été supprimée. Dans ce cas, une solution simple consiste à ignorer la modification, et l’état d’arrivée est le même que précédemment : la tâche est supprimée. Prenons maintenant une situation où Alice supprime toutes les tâche réalisées et Bob fait passer une tâche de l’état réalisée à non réalisée. Si l’algorithme de synchronisation reçoit d’abord la modification de Bob puis la suppression d’Alice, il modifie la tâche puis la supprime car elle faisait partie des tâches réalisées dans la réplique d’Alice. En revanche, s’il reçoit d’abord la suppression d’Alice puis la modificationStyles d’architecture pour les applications Web résilientes 25 de Bob, il se retrouve dans une situation similaire à celle du pragraphe précédent : il doit appliquer une modification sur une tâche qui a été supprimée. S’il applique la stratégie décrite au paragraphe précédent, qui consiste à ignorer la modification sur la tâche supprimée, celle-ci est supprimée. Dans les deux cas il n’est pas certain que l’état du système corresponde vraiment à ce qu’attendent Alice et Bob. En effet, au final l’action d’Alice supprime une tâche dans l’état non réalisée alors que son action initiale consistait justement à supprimer les tâches réalisées. Le problème vient du fait que généralement il n’est pas possible de déduire l’intention initiale d’un utilisateur en fonction de l’évolution des données de sa réplique du système. En effet, différentes actions, correspondant à différentes intentions, peuvent conduire à des modifications de données similaires. Dans notre exemple, une tâche peut être supprimée parce qu’un utilisateur veut supprimer cette tâche en particulier, ou parce qu’elle fait partie des tâches réalisées et que son intention est de supprimer toutes les tâches réalisées. 2.1.3.2 Synchronisation basée sur les actions En fait, dès 1992 Ernst Lippe ❡t✳ ❛❧✳ distinguaient l’approche précédente, basée sur les données, d’une approche basée sur les actions [LV92]. La seconde approche consiste à comparer les suites d’actions qui ont été effectuées par les différents clients. Les auteurs notent que cette approche donne plus d’opportunités pour résoudre les éventuels conflits car elle permet de préserver l’intention de l’utilisateur. Dans le domaine des systèmes distribués, des algorithmes de convergence basés sur les actions existent depuis plus de 25 ans [EG89, SE98]. Ceux-ci sont en général conçus pour des architectures décentralisées et ont un coût important en espace, né- cessitant généralement des horloges vectorielles (ou quelque chose d’équivalent), ne permettant pas de passage à l’échelle. Un algorithme centralisé, Jupiter OT, a été proposé en 1995 par David Nichols [NCDL95]. Cet algorithme tire parti des spécificités des architectures client-serveur pour réduire sa complexité en espace : il n’est plus nécessaire, pour un client, de connaître les horloges de tous les autres clients, l’horloge du serveur suffit. Un autre avantage de cet algorithme est qu’il permet d’exécuter l’application d’opérations concurrentes de fa- çon optimiste : il n’est pas nécessaire d’attendre une réponse du serveur pour exécuter une opération sur un client. En effet, celui-ci peut exécuter l’opération directement sur sa machine, modifiant ainsi sa réplique de l’état du système. Si d’autres clients effectuent une modification de façon concurrente, l’algorithme crée une nouvelle opé- ration permettant de compenser les changements de façon à ce que les états de toutes les répliques convergent. Cependant l’algorithme de résolution de conflits n’est pas dé- terministe : l’état final du système obtenu côté serveur dépend de l’ordre dans lequel il reçoit les mises à jour des clients. Autrement dit, les actions concurrentes effectuées par plusieurs utilisateurs ne conduisent pas toujours à une convergence de l’état du système entre clients et serveurs. En outre, l’algorithme fait l’hypothèse d’un canal de communication fiable et ordonné, ce qui n’est pas le cas du protocole HTTP. Cette limitation a été résolue par Bin Shao ❡t✳ ❛❧✳ avec TIPS, un autre algorithme26 État de l’art de synchronisation basée sur une architecture centralisée [SLLG11]. Les auteurs introduisent une notion de relation d’effets rendant déterministe l’évolution de l’état du système, quel que soit l’ordre dans lequel les opérations sont reçues par le serveur. En outre, leur algorithme est conçu pour être particulièrement adapté aux architectures Web : de nouveaux clients peuvent joindre ou quitter la session de travail collaboratif à n’importe quel moment, les clients peuvent décider indépendamment les uns des autres quand se synchroniser auprès du serveur et le serveur peut décider quand traiter les opérations transmises par les clients. Un point commun à tous les algorithmes de synchronisation optimistes basés sur les actions est qu’ils s’appuient sur une fonction de transformation des actions, propre à chaque application. Dans le cas de Jupiter OT cette fonction a la forme suivante : f(c, s) = (c’, s’) Son implémentation doit satisfaire la propriété suivante : si c est une commande issue d’un client et s une commande issue du serveur, alors l’application des commandes s puis c’ par le serveur et c puis s’ par le client doivent produire le même effet. C’est cette fonction, spécifique à chaque application, qui permet de compenser les effets relatifs des commandes appliquées de façon concurrente. C’est cette fonction de transformation des actions qui permet de propager l’intention initiale des utilisateurs. Ainsi, dans le cas de notre exemple d’application de gestion de tâches, l’implémentation de cette fonction peut être différente pour traiter la suppression d’une tâche en particulier ou la suppression de toutes les tâches réalisées. Par conséquent, dans les situations données dans la section précédente, le système conserverait effectivement la suppression d’Alice dans le premier cas mais pas dans le second, correspondant à une intention de suppression de toutes les tâches réalisées. 2.1.4 Event sourcing Enfin, terminons cette section de l’état de l’art en reliant les approches de synchronisation basées sur les actions et l’❡✈❡♥t s♦✉r❝✐♥❣. L’❡✈❡♥t s♦✉r❝✐♥❣ décrit un style d’architecture dans lequel l’état d’un système est représenté par une succession d’évé- nements plutôt qu’à l’aide de types de données [Fow05]. Ainsi, dans notre exemple de logiciel de gestion de tâches, les événements permettant de représenter le système pourraient être : Created(id, content, isCompleted) « une tâche a été créée, elle a pour identi- fiant id, pour contenu content et comme état de complétion isCompleted » ; Removed(id) « la tâche identifiée par id a été supprimée » ; Edited(id, content, isCompleted) « la tâche identifiée par id a été modifiée ». Un système contenant une tâche dont l’état a été modifié une fois pourrait être représenté par la séquence d’événements suivante : Created(42, "Rédiger une thèse", false), Edited(42, "Rédiger une thèse", true).Partage de code 27 def ui(email: String ): Html = form(action := "/authenticate", method := "POST", input(name := "email", placeholder := "Email", value := email), input(name := "pwd", placeholder := "Password"), button("Sign in") ) Listing 2.1 – Définition de fragments de HTML à l’aide d’un langage dédié interne, en Scala. L’❡✈❡♥t s♦✉r❝✐♥❣ est surtout utilisé pour améliorer la montée en charge d’applications comportant beaucoup d’utilisateurs en consultation mais peu d’utilisateurs effectuant des modifications [BDM+13]. Notons que les algorithmes de synchronisation basés sur les actions correspondent à une approche ❡✈❡♥t s♦✉r❝❡❞ : une action est l’équivalent d’un événement. L’algorithme de synchronisation calcule l’état du système en fonction de l’application des actions effectuées par les divers utilisateurs. 2.2 Partage de code Cette section compare les différentes approches permettant de partager du code entre les parties client et serveur d’une application Web. 2.2.1 Langages dédiés implémentés comme une bibliothèque Une première approche consiste à utiliser un langage généraliste (p. ex. Scala), et à le rendre exécutable côté client en implémentant un ❜❛❝❦❡♥❞ du compilateur générant du JavaScript. Il devient alors possible d’écrire du code partagé entre les côtés client et serveur. Par exemple, il devient envisageable de définir une abstraction pour représenter les fragments de HTML. L’utilisation d’une telle bibliothèque, pour définir un fragment de HTML correspondant à la figure 1.1, pourrait ressembler à ce qui est donné dans le listing 2.1. L’ensemble des fonctions de l’API de cette bibliothèque forme un vocabulaire dédié à la construction de fragments de HTML. Comme le langage hôte sur lequel il s’appuie (ici, Scala), est utilisable côtés client et serveur, ce langage dédié est également utilisable côtés client et serveur. Cette approche a été décrite par Paul Hudak [Hud96]. Son principal intérêt réside dans son faible coût d’implémentation : une fois que le langage hôte peut être exécuté côtés client et serveur, l’introduction de nouveaux éléments de langages dédiés à un aspect particulier ne nécessite que l’implémentation d’une bibliothèque. GWT est un projet populaire suivant cette approche : il compile du code Java vers du JavaScript. Ainsi, il est possible d’écrire les parties client et serveur d’une application Web en Java, et de partager du code commun aux deux parties. HaXe, Kotlin, SharpKit, Ocsigen et ScalaJs [Doe13] sont d’autres projets similaires.28 État de l’art Figure 2.4 – Exécution du programme indiqué dans le listing 2.1. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation abstraite d’un fragment HTML. Celle-ci est ensuite convertie vers une représentation spécifique à chaque plateforme. En général, les outils suivant cette approche fournissent un mécanisme permettant d’interfacer les API du langage hôte (✐✳❡✳ Java, dans dans le cas de GWT) avec l’environnement du navigateur Web. Un tel mécanisme, appelé ❢♦r❡✐❣♥ ❢✉♥❝t✐♦♥ ✐♥t❡r✲ ❢❛❝❡ (FFI), permet d’utiliser les bibliothèques JavaScript existantes ou l’API native du navigateur directement depuis le langage hôte. Cependant, toutes les API utilisant ce mécanisme ne sont plus utilisables côté serveur. Par conséquent, il n’est pas possible de définir une bibliothèque partagée par les côtés client et serveur, pour, par exemple, construire des fragments de HTML, tout en exploitant directement les API natives des deux côtés, client et serveur. Plus généralement, le système de génération de code du compilateur n’a aucun moyen de produire du code tirant parti des spécificités de chaque plateforme (client ou serveur) pour une bibliothèque donnée. En effet, le compilateur n’a connaissance que des concepts du langage hôte, dans lequel sont implémentées les bibliothèques. En pratique, cela signifie qu’il n’est pas possible de faire en sorte que le listing 2.1 produise le code du listing 1.1 côté client et du listing 1.2 côté serveur. En effet, tout ce que la fonction form, par exemple, peut retourner, c’est une description abstraite d’un élément HTML
. Pour relier ce type de données abstrait à la représentation spécifique lui correspondant, côtés client et serveur, il est nécessaire d’introduire une couche d’interprétation, à l’exécution, comme indiqué en figure 2.4. Cette couche d’exécution peut diminuer les performances du programme.Partage de code 29 Figure 2.5 – Langages lourds. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation efficace du fragment HTML, en tirant parti des spécificités de chaque plateforme. 2.2.2 Langages lourds Pour produire du code plus spécifique à chaque plateforme pour une abstraction donnée, le compilateur doit avoir connaissance de cette abstraction. Un moyen d’y parvenir consiste à intégrer les concepts spécifiques au Web dans le langage lui-même, plutôt que de les définir sous forme de bibliothèques. Ainsi, si nous poursuivons l’exemple des fragments de HTML, un tel langage incluerait le concept de fragment de HTML, permettant aux développeurs de définir des fragments de HTML directement depuis le langage, avec une syntaxe dédiée et bien intégrée au reste du langage. Le compilateur du langage traduirait, dès la compilation, cette fois, les définitions de fragments de HTML en code natif correspondant, côtés client et serveur. Ce processus est illustré par la figure 2.5. Le fait que le concept de fragment de HTML fasse partie du langage permet au compilateur de le traiter de façon particulière, et de générer du code spécifique pour chaque plateforme, tirant parti des API natives. Opa et Links [CLWY07] sont des exemples de tels langages. Ils visent à couvrir, dans un unique langage, l’ensemble des aspects des applications Web. Par exemple, en Opa, les fragments de HTML peuvent être définis en utilisant la syntaxe textuelle de HTML, littéralement, comme le montre le listing 2.2. Cette approche a deux intérêts par rapport à la précédente : — La syntaxe du langage peut être adaptée aux aspects à intégrer (cf l’utilisation de littéraux HTML), offrant une meilleur expérience pour le développeur ; — Les aspects supportés par le langages peuvent être compilés de façon à tirer parti des environnements des plateformes cibles.30 État de l’art function ui(email) {
} Listing 2.2 – Définition d’un fragment de HTML avec Opa. La syntaxe du langage permet d’intégrer directement des littéraux HTML. Malgré ces avantages, les outils suivant cette approche n’ont pas connu de grand succès. Cela vient probablement du fait que, d’une part, le développement de la chaîne de compilation d’un langage et de l’outillage à destination des développeurs demande un important effort, par conséquent peu de projets ont atteint un niveau de maturité suffisant et sont capables de s’adapter aussi vite que les besoins et infrastructures évoluent. Et, d’autre part, apprendre un nouveau langage demande également un effort pour les développeurs, par conséquent il est souvent plus rentable de valoriser les compétences d’un développeur sur plusieurs projets plutôt que de le former à un nouvel outil à chaque nouveau projet. 2.2.3 Ingénierie dirigée par les modèles Une solution, pour limiter les deux inconvénients de l’approche précédente, consiste à utiliser plusieurs langages, chacun dédié à un aspect du développement d’applications Web. Ainsi, chaque développeur peut réutiliser ses compétences d’un projet à un autre, tant que certains aspects se recouvrent, et l’outillage propre à chaque langage peut également être réutilisé. La figure 2.6 illustre le fonctionnement de cette approche. Une fois que le mécanisme de combinaison des langages et le système de géné- ration de code sont définis, pour un ensemble de langages donnés, cette approche permet de produire les applications côtés client et serveur à partir de leurs aspects décrits dans différents langages dédiés. Les langages dédiés fournissent un vocabulaire permettant de décrire le système à un niveau de détail très abstrait. Cela rend le code du système plus facile à lire et faire évoluer, car il ne contient pas d’information purement technique ou bas niveau. WebDSL est un exemple de langage de programmation dédié au développement d’applications Web, construit selon une approche dirigée par les modèles[Vis08]. Le principal inconvénient de cette approche est qu’il est difficile de coordonner les différents aspects du programme. En effet, le processus de compilation nécessite, au préalable, de combiner les différents aspects ensemble, tant au niveau syntaxique que sémantique. Or, les technologies basées sur les modèles ne sont pas capables, aujourd’hui, d’automatiser cette phase de composition de langages bien que cela fasse l’objet de nombreuses recherches [VV10, VP12, JCB+13]. Autrement dit, cette approche re-Partage de code 31 Figure 2.6 – Ingénierie dirigée par les modèles. Chaque aspect du programme est dé- crit dans un langage dédié. La combinaison de ces aspects constitue le programme global, qui est transformé en une application côté client et une application côté serveur. quiert un effort d’implémentation important. De même, en réalité les possibilités de réutilisation de l’outillage spécifique à une unité de langage sont minces quand il s’agit de composer ces langages entre eux : seule la partie chargée de l’analyse syntaxique peut éventuellement être réutilisée. La plupart des fonctionnalités des outils, telles que la gestion des références interlangages, doivent être adaptées à chaque combinaison de langages. Enfin, un autre inconvénient de cette approche est qu’il est difficile de définir pré- cisément les bornes de chaque langage. L’argument principal de l’approche dirigée par les modèles est qu’on peut associer à chaque aspect du programme un langage simple à maîtriser. En réalité, un langage simple peut très vite devenir limitant en termes de pouvoir d’expression. Ce problème n’est pas spécifique à l’ingénierie dirigée par les modèles, il survient plus généralement lorsque l’on utilise des langages dédiés dits « externes » [Gho10]. 2.2.4 Pouvoir d’expression des langages dédiés externes Prenons un exemple pour illustrer ce problème. Le langage CSS [CSS] permet de décrire l’aspect visuel des éléments d’une page HTML : la couleur de l’arrière-plan de la page, la couleur du texte, la taille et l’espacement des éléments, etc. Le principal intérêt de CSS est qu’il permet de séparer l’aspect visuel du contenu HTML : le contenu peut être modifié indépendamment de son aspect visuel et réciproquement. CSS est un langage facile à apprendre car il contient peu de concepts : un document CSS est constitué d’un ensemble de règles définissant les valeurs de certaines proprié- tés visuelles (couleur, espacement, etc.) d’un ensemble d’éléments. D’un autre côté, cette simplicité est pénalisante pour le développeur. Par exemple, il n’est pas pos-32 État de l’art sible de définir la couleur d’un élément en fonction de la couleur d’un autre élément. Il n’est pas non plus possible de définir une règle en réutilisant une règle existante. En d’autres termes, il est difficile d’écrire du code modulaire et réutilisable. Ces problèmes pourraient être résolus si le langage supportait des mécanismes de nommage, de composition et d’abstraction. Il deviendrait alors possible, par exemple, de définir un style abstrait, réutilisable et spécialisable. Cette limitation n’est pas propre au langage CSS, on la retrouve souvent dans les langages dédiés externes (p. ex. HTML ou SQL). En 1966, Peter J. Landin a idientifé qu’un langage de programmation comportait en général deux facettes : un système linguistique général et un ensemble de concepts dédiés à un problème donné [Lan66]. Les concepts dédiés sont, comme leur nom l’indique, dédiés à un problème ou un aspect donné, et le système linguistique permet de construire des programmes en combinant les éléments de programmes entre eux (en s’appuyant sur des concepts généraux tels que le nommage, la composition et l’abstraction). Les langages de programmation généralistes se focalisent surtout sur la première facette : ils fournissent des mécanismes généraux permettant de construire des programmes. Tandis que les langages dédiés externes se focalisent surtout sur la seconde facette : ils fournissent des concepts dédiés à un problème donné. Or, les deux facettes sont utiles pour construire des programmes. Notons que l’on pourrait être tenté d’enrichir un langage externe trop pauvre avec des concepts supplémentaires fournissant des moyens de généralisation ou de composition. Mais, d’une part, cela rendrait le langage plus complexe, ce qui irait à l’encontre du but initial, et, d’autre part, cela conduirait à ré-inventer les mêmes choses dans chaque nouveau langage car les systèmes actuels d’ingénierie des langages ne savent pas produire des langages à partir d’unités de langages réutilisables. 2.2.5 Langages dédiés compilés et implémentés comme une bibliothèque Ainsi, toutes les solutions aux limitations des langages dédiés implémentés sous forme de bibliothèques présentent de nouvelles limitations diminuant leur applicabilité. En fait, le principal inconvénient des bibliothèques – l’impossibilité de spécialiser le code à exécuter pour une abstraction et une plateforme données – est exacerbé dans notre situation (le développement d’applications Web) mais n’en est pas l’apanage. En effet, ce problème peut être généralisé à la plupart des abstractions logicielles. La plupart des composants logiciels sont écrits pour être paramétrables ou confi- gurables. Ainsi, un même composant peut être utilisé différement selon qu’il est intégré dans un environnement de test ou de production. Un exemple typique est la connexion à une base de données : des URL différentes sont utilisées selon l’environnement (test ou production). Cela signifie que le code du programme qui se connecte à la base de données est paramétré par la connexion effective à la base de données. Pourtant, une fois lancé, le programme se connecte toujours à la même base de données.Partage de code 33 On observe donc une situation similaire à celle rencontrée dans l’exemple du langage dédié à la définition de fragments de HTML : un composant logiciel est souvent plus général que l’utilisation qui en est faite à l’exécution, et cela se paie à l’exécution par un niveau d’indirection supplémentaire. L’idéal serait que le code finalement exécuté ne souffre pas de ce niveau d’indirection : une fois la connexion à la base de données connue, on aimerait pouvoir construire un programme directement relié à celle-ci. Les systèmes de compilation à la volée (❏■❚) sont capables de faire certaines de ces optimisations, au prix d’une analyse du comportement du programme à l’exécution. Cependant des travaux ont montré que les JITs ne détectent pas autant d’opportunités d’optimisations qu’ils pourraient [RSB+14]. En fait, un autre système effectuant ce genre d’optimisations existe déjà et est utilisé par de nombreuses personnes sans le savoir. En effet, les outils de construction de projets remplissent exactement ce rôle. Ces outils permettent de compiler le code d’un projet et de gérer son cycle de vie (exécution des tests, déploiement, etc.). La plupart des ces outils de construction de projets sont capables de générer une partie du code source à compiler. Par exemple, dans maven, cela correspond à la phase ❣❡♥❡r❛t❡✲ s♦✉r❝❡s. Dans sbt, cela correspond à la tâche s♦✉r❝❡●❡♥❡r❛t♦rs. Dans les deux cas, les outils génèrent une partie du code source du programme à construire. Le code source du programme final est donc le produit de l’exécution d’un premier programme. Ce programme est un générateur de programmes. Ainsi, on observe qu’il est très fréquent qu’un programme soit généré par un autre programme. Dans le cas des outils de construction de projet, la distinction est claire car il y a effectivement deux phases d’exécution : une première pour générer du code, et une seconde pour exécuter ce code. Dans le cas des composants logiciels généraux, bien qu’il n’y ait qu’un seul code source et qu’une seule phase d’exécution, on est dans une situation où un programme est obtenu à partir d’un autre programme : en effet, une partie de l’exécution du programme correspond à l’interprétation des paramètres et la seconde partie à l’exécution effective du programme. Notons que cette observation a déjà été à l’origine de travaux en 1986 [JS86] : les auteurs introduisent le concept de st❛❣✐♥❣ visant à évaluer certaines parties d’un programme avant les autres selon leur fréquence d’exécution ou la disponibilité des données utilisées. Les deux approches (outils de construction de programmes et composants géné- raux) ont leurs avantages et inconvénients. Les outils de construction de programme, grâce à leur première phase d’exécution sont capables de générer du code plus spécialisé, et donc bénéficient de meilleures performances lors de la seconde phase d’exécution. Les composants généraux sont des citoyens de première classe dans tout le reste du programme : ils peuvent être passés en paramètre d’une fonction ou retournés comme résultat, ou être combinés entre eux, ce qui donne une plus grande flexibilité pour le programmeur, au détriment d’une perte de performances à l’exécution. Les langages dédiés compilés et implémentés sous forme de bibliothèque visent à bénéficier des avantages des deux approches en minimisant leurs inconvénients. L’idée essentielle est la suivante : les unités de langage sont fournies sous forme de bi-34 État de l’art Figure 2.7 – Langages dédiés compilés et implémentés par des bibliothèques. Un langage dédié est fourni par une bibliothèque dont l’implémentation produit une repré- sentation abstraite du programme à générer. Un générateur de code peut dériver, à partir de cette représentation abstraite, les programmes correspondant, côtés client et serveur. bliothèques dont l’implémentation retourne le code source d’un programme optimisé. Des travaux ont introduit cette idée en 1996 [K+96, Hud96]. Une amélioration consiste à utiliser une représentation abstraite du programme à générer plutôt que directement son code source [EFDM00]. Cela permet de réaliser de nombreuses réécritures de code ou optimisations telles que l’élimination de sous-expressions communes ou du code mort. La figure 2.7 illustre cette approche sur l’exemple des définitions de fragments de HTML. Avec cette approche, le développeur bénéficie du système linguistique du langage hôte pour définir et combiner entre elles des représentations abstraites de programmes obtenues avec le langage dédié à son problème. La figure 2.8 illustre les différences entre les langages dédiés implémentés par des bibliothèques, intérprétés ou compilés. Dans le premier cas, les concepts dédiés à un problème sont implémentés par des bibliothèques qui sont traduites, par le compilateur du langage hôte, vers du code pour les environnements client et serveur. Ce code, trop général, est adapté à l’exécution vers les spécificités des environnements client et serveur. Dans le second cas, les concepts dédiés à un problème sont également implé- mentés par des bibliothèques, mais cette fois-ci c’est leur exécution qui produit le code pour les environnements client et serveur. Ce code, produit par les bibliothèques plutôt que par le compilateur du langage, traduit chaque concept vers une représentation spécifique dans chaque environnement cible.Partage de code 35 Figure 2.8 – Différence entre les langages dédiés implémentés par des bibliothèques, interprétés (à gauche) ou compilés (à droite). 2.2.6 Méta-programmation et évaluation partielle Par ailleurs, il est notable que le programme écrit par le développeur est en réalité un générateur de programmes car c’est son exécution qui produit le programme final. Le fait que le programme bénéficie au total de deux phases d’exécution relie cette approche aux systèmes d’évaluation partielle [JGS93] : la première exécution peut déjà évaluer certaines parties du programme qui deviendront alors des constantes dans le programme final. Autrement dit, l’évaluation du programme final est ❞é❧❛②é❡ par rapport au programe initial. Une idée similaire a déjà été explorée par Manuel Serrano, dans le cas des applications Web, avec le langage Hop [SGL06]. Un programme écrit avec Hop contient en fait deux programmes : celui évalué côté serveur et celui évalué côté client. Le programme évalué côté client peut être construit à partir du résultat d’une évaluation côté serveur, de façon similaire à de l’évaluation partielle. Notons que, dans le cas de Hop, seul le programme côté client bénéficie du mécanisme d’évaluation partielle. Enfin, une autre manière d’effectuer de l’évaluation partielle est l’utilisation de macros. Les macros permettent d’évaluer des parties du code source au moment de la compilation. Cependant, les macros ne sont pas des entités de première classe au sein d’un langage : leur expansion ne peut avoir lieu qu’au moment de la compilation, elles ne peuvent donc pas être retournées comme résultat d’une fonction ou passées en paramètre. Cette caractéristique limite leurs possibilités d’utilisation. Par exemple, il n’est pas facile d’implémenter une macro extensible ou paramétrable. 2.2.7 Lightweight Modular Staging et js-scala Récemment, Tiark Rompf a implémenté ❧✐❣❤t✇❡✐❣❤t ♠♦❞✉❧❛r st❛❣✐♥❣ (LMS), une infrastructure logicielle, en Scala, pour définir des langages dédiés compilés et implé- mentés sous forme de bibliothèques [Rom12]. S’appuyant sur LMS, Kossakowski ❡t✳ ❛❧✳ ont implémenté ❥s✲s❝❛❧❛, un générateur de code JavaScript [KARO12]. Leurs travaux36 État de l’art ont montré le gain en confort obtenu par les développeurs utilisant le langage Scala plutôt que JavaScript pour écrire la partie client des applications Web, notamment grâce au typage statique. Ils ont également montré comment utiliser les bibliothèques JavaScript existantes depuis le langage Scala, à moindre effort, avec un système de typage graduel. Cependant, leur travail ne permet pas de produire, pour une abstraction donnée, du code tirant parti des spécificités des plateformes client et serveur. Nos travaux se sont basés sur js-scala : nous avons défini des unités de langage produisant du code optimisé, spécifique aux plateformes client et serveur. La suite de cette section détaille le fonctionnement de LMS. 2.2.7.1 Unités de langages composables Un programme LMS construit une représentation abstraite du programme à géné- rer. De la même façon qu’un programme complexe s’obtient en combinant plusieurs morceaux de programmes plus simples, une représentation abstraite d’un programme complexe s’obtient en combinant entre elles des représentations abstraites de programmes simples. Un exemple de programme simple est le programme constant : il retourne une valeur, toujours la même. On peut représenter un tel programme, avec LMS, à l’aide de la fonction const : val un = const (1) Le terme un a pour type Rep[Int] et a pour valeur une représentation abstraite d’un programme retournant le nombre 1. Pour l’utilisateur, il n’est pas nécessaire de connaître les détails de cette représentation abstraite. On peut ensuite représenter un programme plus complexe en combinant plusieurs programmes simples. Par exemple, la fonction plus combine deux programmes retournant un nombre et produit un nouveau programme retournant un nombre : val un = const (1) val deux = const (2) val trois = plus(un, deux) La fonction plus ne calcule pas une somme mais retourne une représentation abstraite d’un programme calculant la somme des résultats des programmes un et deux. Soulignons que les fonctions const et plus ne sont pas des mots-clé du langage Scala, mais bien des noms de fonctions implémentées dans une bibliothèque. Ces fonctions constituent le vocabulaire d’une ✉♥✐té ❞❡ ❧❛♥❣❛❣❡, NumericOps, permettant de représenter des programmes effectuant des sommes d’entiers. Les unités de langage forment des modules que l’utilisateur combine pour enrichir son vocabulaire. Des exemples d’unités de langage sont ArrayOps, pour manipuler des tableaux, et FunctionOps, pour définir des fonctions. Enfin, le développeur peut étendre ce vocabulaire en implémentant ses propres bibliothèques.Partage de code 37 Figure 2.9 – Diagramme d’objets correspondant au terme trois. 2.2.7.2 Représentation abstraite des programmes Du point de vue de l’utilisateur, les trois programmes, un, deux et trois ont tous le même type : Rep[Int]. Cela, bien que le programme trois soit un programme composite, contrairement aux programmes un et deux, qui sont des programmes constants. Pour l’utilisateur, ce qui compte c’est seulement de savoir qu’il manipule un programme retournant un entier, et c’est tout ce que le type Rep[Int] indique. En pratique, la représentation abstraite des programmes est implémentée à l’aide d’un graphe dont chaque nœud représente une instruction. Dans le cas du programme un, ce graphe ne comporte qu’un seul nœud, représentant la valeur constante 1. Ainsi, la fonction const retourne un nœud de type Const, et la fonction plus retourne un nœud de type Plus. La figure 2.9 montre le diagramme d’objets correspondant au terme trois. Le code suivant montre l’implémentation de la fonction plus : def plus(lhs: Rep[Int], rhs: Rep[Int]): Rep[Int] = Plus(lhs , rhs) 2.2.7.3 Génération de code L’objectif final est d’exécuter les programmes ainsi construits. On utilise pour cela des générateurs de code qui prennent en paramètre une représentation abstraite de programme et produisent un fichier texte contenant le code du programme. Le niveau de granularité de la génération de code est définie par les nœuds du graphe représentant le programme. Les nœuds du graphe sont parcourus et le générateur de code écrit le code correspondant à chacun. Par exemple le générateur de code JavaScript pour le nœud Plus est défini comme suit : case Plus(lhs , rhs) => gen"var $sym = $lhs + $rhs;" Le code produit une variable contenant le résultat de la somme des deux opé- randes. Au final, la sortie du générateur de code JavaScript appliqué au programme trois est la suivante : var x0 = 1 + 2;38 État de l’art 2.2.7.4 Optimisations En fait, comme les termes un et deux représentent des programmes constants, leur valeur est connue dès l’exécution du générateur de programmes, et cela constitue une opportunité d’optimisation : la somme des deux constantes pourrait être déjà évaluée dans le générateur de programmes et produire la constante 3 dans le programme final. Ainsi, une implémentation plus optimisée de la fonction plus est la suivante : def plus(lhs: Rep[Int], rhs: Rep[Int]): Rep[Int] = (lhs , rhs) match { case (Const(lhs), Const(rhs)) => const(lhs + rhs) case (lhs , Const (0)) => lhs case (Const(0), rhs) => rhs case _ => Plus(lhs , rhs) } Cette implémentation teste si les valeurs à additionner sont des représentations de programmes constants ou non. La somme de deux programmes constants est évaluée directement et produit un nouveau programme constant. Les cas particuliers d’addition d’un programme non constant avec la constante zéro sont également traités en éliminant l’addition. Enfin, le cas plus général, correspondant à deux programmes non constants, produit un nœud de type Plus. 2.2.7.5 Flexibilité syntaxique Voici un exemple plus complexe de code décrivant un programme manipulant un intervalle de nombres : val ns = range(1, 4) val inc = fun { (n: Rep[Int]) => plus(n, const (1)) } val prog = range_map(ns, inc) Le terme prog représente un programme qui applique une fonction à tous les élé- ments d’un intervalle de nombres. La fonction appliquée, représentée par le terme inc, retourne la valeur n, qui lui est passée en paramètre, majorée de 1. L’intervalle de nombres, représenté par le terme inc, contient les nombres de 1 à 4. À titre de comparaison, un programme équivalent en Scala pur 1 s’écrirait comme suit : for (n <- 1 to 4) yield n + 1 La comparaison des deux listings peut conduire le lecteur à estimer que la version écrite avec LMS est nettement plus verbeuse, donc plus difficile à lire. Par exemple, le corps de la fonction effectuant l’incrémentation s’écrit plus(n, const(1)) dans la version LMS, tandis qu’il s’écrit simplement n + 1 en Scala pur. Heureusement, le 1. Dans ce document, nous considérons les unités de langages définies au-dessus de LMS comme un langage différent de Scala bien que ce ne soit pas le cas puisque LMS est simplement une bibliothèque Scala.Sûreté du typage 39 langage Scala fournit un mécanisme de conversion implicite permettant à LMS de définir une conversion implicite de toute constante en un programme constant. Cela permet à l’utilisateur d’omettre le terme const : il peut simplement écrire plus(n, 1). De plus, le langage Scala fournit également un mécanisme permettant de définir ❛ ♣♦st❡r✐♦r✐ des opérateurs pour des types de données. LMS utilise ce mécanisme pour définir un opérateur + ayant pour opérandes des valeurs de type Rep[Int]. Cela permet à l’utilisateur d’écrire simplement n + 1, comme en Scala pur. Au final, grâce à ces facilités syntaxiques, l’utilisateur peut écrire son programme comme suit : val prog: Rep[List[Int]] = for (n <- 1 to 4) yield n + 1 C’est-à-dire, exactement comme il l’aurait écrit en Scala pur ! L’idée essentielle est que LMS ne nécessite pas le recours à une syntaxe particulière pour distinguer les termes représentant des valeurs des termes représentant des programmes. La distinction se fait uniquement par les types : le type Int représente un nombre entier, tandis que le type Rep[Int] représente un programme retournant un nombre entier. 2.2.7.6 Synthèse En résumé, définir une unité de langage avec LMS, consiste à : — définir une API fournissant le vocabulaire du langage (section 2.2.7.1) ; — écrire une implémentation de cette API produisant une représentation abstraite de chaque concept du langage (section 2.2.7.2) ; — définir un générateur de code (ou plusieurs, si différentes plateformes d’exécution sont ciblées) produisant le code correspondant à chaque nœud représentant un concept du langage (section 2.2.7.3). 2.3 Sûreté du typage Dans la section 2.2.7 nous avons mentionné le fait que js-scala permet d’utiliser les bibliothèques JavaScript existantes en utilisant un système de typage graduel. Ainsi, il n’est pas nécessaire de donner une signature de type aux fonctions de l’API JavaScript utilisée, mais, en contrepartie, aucune vérification du typage n’est effectuée. Cela peut donc conduire l’utilisateur à écrire des programmes incorrects sans que le compilateur ne l’en avertisse. Des travaux ont été réalisés pour vérifier que des appels de fonctions depuis un langage vers un autre, utilisant des systèmes de type différents, soient bien typés [FF05]. Cependant, notre problème est un peu différent : la difficulté réside dans le fait qu’à l’utilisation les signatures de type des fonctions standard du navigateur ne se révèlent pas « pratiques » pour le développeur. En effet, elles l’obligent ensuite à effectuer une opération de transtypage. L’enjeu consiste à trouver une autre signature de type contenant plus d’informations afin d’éviter à l’utilisateur d’effectuer des opérations de transtypage.40 État de l’art var createTwoElements = function (fst , snd) { return [ createElement(fst), createElement(snd) ] }; Listing 2.3 – Fonction faisant appel à createElement Le langage TypeScript permet de surcharger des opérations selon la valeur de certains paramètres. Ainsi, le compilateur attribue à l’expression createElement("div") le type DivElement car la valeur du paramètre passé à la fonction, "div", est connue en temps de compilation (c’est une constante). Cette solution donne autant de pouvoir d’expression aux utilisateurs et est bien typée à condition qu’elle soit utilisée avec des valeurs connues en temps de compilation. Cette contrainte limite son applicabilité car une fonction prenant en paramètre un nom d’élément name et créant un élément en appelant createElement(name) ne peut pas bénéficier du bon typage : le type de retour inféré de l’appel à createElement n’est pas plus précis que Element. Cette limitation est illustrée par le listing 2.3. Dans ce programme, la fonction createTwoElements prend en paramètre deux noms d’éléments et retourne un tuple contenant les deux éléments créés correspondant. Tout ce que le système de type du langage TypeScript peut infé- rer comme type de retour pour cette fonction est un tuple d’Elements. Une autre solution consiste à définir plusieurs fonctions spécialisées plutôt qu’une seule fonction générale. Ainsi, GWT propose une fonction createInputElement() ayant pour type de retour InputElement, une fonction createImageElement() ayant pour type de retour ImageElement, etc. Le développeur, en appelant createInputElement() plutôt que createElement("input") obtient alors une valeur du type le plus précis possible (InputElement plutôt que Element). L’inconvénient de cette solution, outre le fait qu’elle augmente significativement le nombre de fonctions de l’API, est qu’elle diminue le pouvoir d’expression de l’utilisateur. En effet, comme le paramètre repré- sentant le nom de l’élément à créer n’existe plus, il n’est plus possible d’écrire du code lui-même paramétré par un nom d’élément et faisant appel à createElement. Autrement dit, avec cette approche il n’est pas possible d’implémenter la fonction createTwoElements du listing 2.3. Une approche complètement différente a été suivie par Chugh ❡t✳ ❛❧✳ [CHJ12]. Ils ont montré comment typer du code JavaScript à l’aide d’un système de typage à types dépendants. Leurs travaux visent à bien typer un sous-ensemble du langage JavaScript. Cependant, la complexité des annotations de type nécessaires rend leur approche difficile à maîtriser par les utilisateurs.Deuxième partie Contributions 41Chapitre 3 Partage de code Ce chapitre présente un moyen de partager de code entre les environnements client et serveur. En nous appyant sur LMS et js-scala, nous avons pu définir des unités de langage fournissant des APIs de haut niveau, parfois utilisables des deux côtés, client et serveur, et générant du code efficace. Ce chapitre présente ces abstractions et leurs détails d’implémentation. Le contenu de ce chapitre a fait l’objet d’une publication [RFBJ13b]. 3.1 API des sélécteurs L’API des sélécteurs est une API du navigateur permettant de rechercher des élé- ments HTML dans une page. Elle contient plusieurs fonctions, résumées dans la fi- gure 3.1. Les fonctions querySelector et querySelectorAll sont les plus générales : les autres correspondent seulement à des cas particuliers de ces fonctions. Par exemple, la fonction getElementById peut être implémentée comme ceci : var getElementById = function (id) { return querySelector(’#’ + id) }; De façon similaire, les fonctions getElementsByClassName et getElementsByTagName peuvent être implémentée avec querySelectorAll. Fonction Élément(s) recherché(s) querySelector(s) Premier élément correspondant au sélecteur CSS s getElementById(i) Élément dont l’attribut id vaut i querySelectorAll(s) Tous les éléments correspondant au sélecteur CSS s getElementsByTagName(n) Tous les éléments ayant pour nom n getElementsByClassName(c) Tous les éléments dont l’attribut class contient c Figure 3.1 – L’API standard des sélecteurs. 4344 Partage de code function getWords () { var form = document.getElementById(’add -user’); var sections = form.getElementsByTagName(’fieldset ’); var results = []; for (var i = 0 ; i < sections.length ; i++) { var words = sections[i] .getElementsByClassName(’word’); results[i] = words; } return results } Listing 3.1 – Utilisation de l’API native pour rechercher des éléments dans une page HTML function getWords () { var form = $(’#add -user’); var sections = $(’fieldset ’, form); return sections.map(function () { return $(’.word’, this) }) } Listing 3.2 – Utilisation de jQuery pour rechercher des éléments dans une page HTML Ces fonctions plus spécifiques ont l’avantage d’avoir une implémentation plus performante par le navigateur, comparées aux fonctions générales querySelector et querySelectorAll. D’un autre côté, elles ajoutent de la complexité au code en augmentant le nombre de fonctions à connaître pour manipuler l’API et en poussant l’utilisateur à penser à un bas niveau d’abstraction. Le listing 3.1 illustre l’utilisation de cette API pour récupérer une liste de champs de formulaires. La fonction getWords commence par rechercher l’élément ayant pour id add-user, puis collecte tous les sous-éléments de type fieldset, et, pour chacun, retourne la liste de ses sous-éléments dont l’attribut class contient word. Notons que le code utilise uniquement les trois fonctions bas niveau de l’API du navigateur. À titre de comparaison, la bibliothèque jQuery [BK08], largement utilisée par les sites Web [jQu], ne propose qu’une seule fonction pour rechercher des éléments dans une page HTML. Une version du programme getWords avec jQuery est donnée dans le listing 3.2. Le code est à la fois plus court et plus simple, notamment grâce au fait que jQuery propose une API plus haut niveau que l’API du navigateur. Cependant, ce confort d’utilisation se paie par des performances d’exécution moindres (les benchmarks pré- sentés en section 3.4 montrent des temps d’exécution de l’ordre de 10 à 30 fois plus longs avec jQuery).API des sélécteurs 45 def getWords () = { val form = document.find("#add -user") val sections = form.findAll("fieldset") sections map (_.findAll(".word")) } Listing 3.3 – Utilisation de DomOps pour rechercher des éléments dans une page HTML def find(selector: Rep[String ]) = selector match { case ConstIdCss(id) if receiver == document => DocumentGetElementById(Const(id)) case _ => SelectorFind(receiver , selector) } Listing 3.4 – Optimisation de find En nous appuyant sur le mécanisme d’évaluation partielle de LMS, notre idée consiste à définir une API de haut niveau, fournissant un confort d’utilisation similaire à jQuery, mais dont l’évaluation produit un programme utilisant les APIs bas niveau du navigateur, bénéficiant des bonnes performances d’exécution. Ainsi, nous proposons une API de haut niveau, ❉♦♠❖♣s, comprenant deux fonctions : find et findAll, permettant de chercher un élément ou plusieurs éléments, respectivement. Ces fonctions sont directement équivalentes aux fonctions querySelector et querySelectorAll de l’API native. Elles prennent en paramètre un sélecteur CSS et retournent le premier élément ou tous les éléments correspondant. Le listing 3.3 montre code de la fonction getWords avec notre API. Ce code est, lui aussi, simple et concis, comparé au listing 3.1 utilisant l’API native du navigateur. L’implémentation des fonctions find et findAll analyse les sélecteurs qui leur sont passés en paramètre pour détecter une opportunité d’utilisation d’une fonction spé- cialisée plutôt que de toujours utiliser querySelector et querySelectorAll, respectivement. L’analyse consiste à détecter un motif particulier dans la chaîne de caractères représentant le sélecteur. Ainsi, l’implémentation de find vérifie si le sélecteur correspond à un sélecteur d’id et si l’objet sur lequel est appelée la méthode est document, et, le cas échéant, retourne un nœud de type DocumentGetElementById. Sinon, elle retourne un nœud de type SelectorFind. Ces nœud sont traduits, par le générateur de code JavaScript, en code utilisant getElementById et querySelector, respectivement. Le listing 3.4 montre l’implémentation de la fonction find. Du point de vue de l’utilisateur, la fonction s’utilise toujours de la même façon mais elle produit un code différent en fonction de la valeur des paramètres qui lui sont passés. Par exemple, l’évaluation de l’expression document.find("#add-user button") retourne un nœud de type SelectorFind, car le sélecteur ne correspond pas à un sélec-46 Partage de code Figure 3.2 – Représentations abstraites de code retournées par l’évaluation des expressions (a) document.find("#add-user button") et (b) document.find("#add-user") def findAll(selector: Rep[String ]) = selector match { case ConstClassName(name) => GetElementsByClassName(receiver , name) case ConstTagName(name) => GetElementsByTagName(receiver , name) case _ => SelectorFindAll(receiver , selector) } Listing 3.5 – Optimisation de findAll teur d’id (c’est un sélecteur composite sélectionnant les éléments de type button à l’intérieur de l’élément ayant pour id add-user). D’un autre côté, l’expression document.find("#add-user") retourne un nœud de type DocumentGetElementById. La figure 3.2 L’implémentation de la fonction findAll, donnée dans le listing 3.5, est similaire : le sélecteur passé en paramètre est analysé pour détecter s’il s’agit d’un sélecteur de classe ou de nom d’élément, et, le cas échéant, retourne un nœud de type GetElementsByClassName ou GetElementsByTagName, respectivement. Sinon, elle retourne un nœud de type SelectorFindAll. Notre solution offre donc à l’utilisateur une API de haut niveau dont le surcoût n’existe que lors de la première évaluation du programme : le programme final généré s’appuie, lorsque cela est possible, directement sur les APIs bas niveau performantes. En fait, le listing 3.3 produit exactement le code bas niveau du listing 3.1. 3.2 Manipulation de valeurs optionnelles Certaines fonctions du navigateur peuvent, dans certains cas, ne pas retourner de résultat : typiquement, les fonctions de recherche d’éléments HTML peuvent échouer (dans le cas où l’élément recherché n’est pas trouvé dans la page) et, dans ce cas, la valeur retournée doit représenter l’absence de résultat. La majorité des API JavaScript utilisent l’objet null pour représenter l’absence de valeur. Cependant, cette solution est connue pour être une importante source de fragilité dans le code des programmes [NS09, Hoa09]. Pour s’en protéger, les programmeurs peuvent faire de la programmation dite « défensive », en vérifiant toujours qu’une valeur ne vaut pas null avant de l’utiliser. À titre d’exemple, le listing 3.6 montre unManipulation de valeurs optionnelles 47 var loginWidget = document.querySelector("div.login"); var loginButton = loginWidget.querySelector("button.submit"); loginButton.addEventListener("click", handler ); Listing 3.6 – Code non sûr manipulant des valeurs optionnelles var loginWidget = document.querySelector("div.login"); if (loginWidget !== null) { var loginButton = loginWidget.querySelector("button.submit"); if (loginButton !== null) { loginButton.addEventListener("click", handler ); } } Listing 3.7 – Style défensif pour se protéger du déréférencement de valeurs null programme JavaScript recherchant un composant dans la page, puis recherchant un bouton à l’intérieur de ce composant. Le code de ce listing n’est pas sûr car les termes loginWidget et loginButton sont utilisés sans vérifier qu’ils ne valent pas null. Par conséquent, l’exécution de ce programme sur une page ne contenant pas les éléments recherchés lèvera une exception au moment où le terme loginWidget sera déréférencé. Une version sûre du même programme est donnée dans le listing 3.7. Ce style de code, très verbeux, n’est pas pratique à l’utilisation, et, surtout, nécessite une grande rigueur de la part de l’utilisateur car rien ne le force à effectuer ces tests pour diffé- rencier l’absence de valeur des cas où une valeur est bien présente. Une amélioration possible consiste à utiliser un type de données spécifique pour représenter l’absence éventuelle de valeur. Cela permet à l’utilisateur de distinguer les cas où il doit se protéger de l’absence de valeur des cas où il peut faire l’hypothèse que la valeur est présente. Cela réduit l’effort intellectuel à fournir par l’utilisateur mais pas la verbosité du code car les tests vérifiant que la valeur est présente sont toujours nécessaires. Une seconde amélioration consiste donc à bénéficier d’une syntaxe allégée pour déréférencer les valeurs optionnelles, de façon à diminuer la verbosité du code. En Scala, la notation for permet de séquencer l’évaluation d’expressions de façon concise. En nous appuyant sur ces améliorations, notre solution, ❖♣t✐♦♥❖♣s, fournit une syntaxe concise pour manipuler les valeurs optionnelles de façon sûre. Le listing 3.8 for { loginWidget <- document.find("div.login") loginButton <- loginWidget.find("submit.button") } loginButton.on(Click)( handler) Listing 3.8 – Manipulation de valeurs optionnelles avec OptionOps48 Partage de code montre l’implémentation du programme précédent avec OptionOps. La fonction find retourne maintenant une valeur de type Rep[Option[Element]] au lieu de Rep[Element] et l’implémentation du séquencement, dans les expressions for vérifie que la valeur est bien présente. Encore une fois, cette abstraction a un coût : l’utilisation d’un type de données spé- cifique pour représenter l’absence éventuelle de valeur nécessite une allocation d’objet supplémentaire, et les fonctions d’ordre supérieur utilisées pour le séquencement, par la notation for, sont moins efficaces que des instructions if. Heureusement, comme précédemment, notre abstraction et ses surcoûts n’existent que dans le programme initial. En effet, le séquencement d’expressions représentant des programmes contenant des valeurs optionnelles retourne une représentation de programme effectuant ce séquencement. Finalement, le générateur traduit cette représentation abstraite de séquencement en véritable séquencement en générant du code vérifiant qu’une valeur n’est pas absente en la comparant avec null. Le listing 3.9 montre l’implémentation de la génération de code pour le séquencement. case OptionForeach(option , block) => gen"""if ($option !== null) { $block }""" Listing 3.9 – Générateur de code JavaScript pour le langage de manipulation de valeurs optionnelles Le programme haut niveau du listing 3.8 produit un programme JavaScript identique au listing bas niveau 3.7. Enfin, comme l’implémentation de l’unité de langage retourne une représentation abstraite des opérations, celle-ci est indépendante de la plateforme d’exécution, et il est facile d’implémenter, en plus du générateur de code JavaScript, un générateur de code Scala. Ainsi, la même abstraction – l’unité de langage pour manipuler des valeurs optionnelles – est utilisable côtés client et serveur, et le code généré est efficace des deux côtés (il n’utilise pas d’objet supplémentaire pour représenter l’éventuelle absence de valeur). 3.3 Définition de fragments de HTML Nous avons montré en introduction à quel point les plateformes client et serveur représentent différemment l’interface utilisateur (listings 1.1 et 1.2, page 15). Côté client, l’interface utilisateur de l’application est représenté par un arbre organisant de façon hiérarchique les composants, le ❉♦❝✉♠❡♥t ❖❜❥❡❝t ▼♦❞❡❧ (DOM). L’utilisation d’un arbre permet facilement de remplacer un nœud par un autre, d’introduire un nouveau nœud ou de retirer un nœud, dynamiquement, pour mettre à jour l’interface utilisateur.Définition de fragments de HTML 49 def ui(email: Rep[String ]): Rep[Element] = el(’form , ’action -> "/authenticate", ’method -> "POST ")( el(’input , ’name -> "email", ’placeholder -> "Email", ’value -> email)(), el(’input , ’name -> "pwd", ’placeholder -> "Password")(), el(’button )(" Sign in") ) Listing 3.10 – Définition d’un fragment de DOM avec Forest Côté serveur, l’interface utilisateur est généralement représentée par du texte contenant du code HTML. Cette représentation permet au contenu d’une page Web d’être facilement transmis dans le corps d’une réponse HTTP. Construire le contenu HTML depuis les côtés client et serveur ont tous les deux des avantages. Côté client, cela permet de faire évoluer l’interface utilisateur dynamiquement, sans rechargement complet de la page, ce qui procure une meilleur expé- rience utilisateur. Côté serveur, cela permet au contenu d’être mieux référencé par les moteurs de recherche (le référencement du contenu produit côté client ajoute beaucoup de complexité aux systèmes de référencement) et permet de gagner du temps sur l’affichage initial du contenu. Ces préoccupations techniques conduisent les développeurs à dupliquer, côtés client et serveur, le code définissant le contenu HTML de leurs applications. En plus de ces considérations techniques, notons que l’API du navigateur pour la construction de fragments de DOM est particulièrement verbeuse : en effet, le listing JavaScript 1.1 est plus de deux fois plus long que son équivalent Scala, le listing 1.2. En outre, le style impératif de l’API du navigateur ne permet pas facilement de visualiser la structure hiérarchique des différents éléments d’un fragment de DOM, contrairement à la notation HTML. En résumé, pour atteindre notre objectif de réduction de la complexité de la défi- nition de contenus Web, nous devons proposer un seul langage, concis, permettant de générer les contenus côtés client et serveur. Malgré les différences de représentation côtés client et serveur, les contenus Web sont, dans les deux cas, constitués d’éléments HTML et de texte. Ainsi, nous proposons un langage, appelé ❋♦r❡st, centré sur des deux concepts. L’implémentation de notre langage produit une représentation abstraite de contenu Web. Nos générateurs de code parcourent cette représentation abstraite et génèrent, pour chaque plateforme, du code bas niveau utilisant les API natives. Le listing 3.10 montre comment construire le contenu Web présenté en figure 1.1. La fonction el construit un élément HTML, lequel peut contenir des attributs et des sous-éléments. Ceux-ci peuvent être des éléments HTML ou du texte, comme dans le cas du bouton. Le type de retour de la fonction ui, Rep[Element], désigne une repré- sentation abstraite de programme produisant un élément HTML. Il est notable que notre unité de langage, bien que minimaliste (elle ne comporte qu’une fonction, el), n’a pas un pouvoir d’expression limité. En effet, comme elle est50 Partage de code def usersUi(users: Rep[Seq[User ]]) = el(’ul)( for (user <- users) yield el(’li)( userUi(user)) ) Listing 3.11 – Utilisation de boucles et composition de fragments Web avec Forest définie sous forme de bibliothèque, elle s’intègre directement dans le langage Scala dont elle peut bénéficier de tous les concepts : fonction, boucles, tests, etc. Les représentations abstraites de programmes produisant du contenu Web (les valeurs de type Rep[Element]) sont des entités de première classes, elles peuvent être passées en paramètre à des fonctions, utilisées dans des boucles, etc. de telle sorte qu’au final, l’utilisateur bénéficie d’un système puissant de génération de contenus Web, similaire aux moteurs de gabarits (t❡♠♣❧❛t❡ ❡♥❣✐♥❡s, en anglais) généralement fournis par les solutions de construction d’applications Web. Le listing 3.11 montre, ainsi, comment construire un contenu Web affichant une liste d’utilisateurs. La fonction usersUi crée un élément HTML ul, dont les sous- éléments sont obtenus en transformant une collections d’utilisateurs en une collection de fragments Web. Cette transformation utilise une unité de langage de manipulation de collections. Enfin, le fragment Web décrivant chaque utilisateur est obtenu en appelant la fonction userUi, dont le code n’est pas montré dans le listing. Le point important du listing étant de montrer qu’il est possible de découper la définition de contenus Web en fragments réutilisables. Les listings 3.12 et 3.13 montrent les implémentations des générateurs de code JavaScript et Scala pour le langage Forest. Dans les deux cas, le fonctionnement est similaire. Il y a deux types de nœuds à traiter, les éléments HTML (Tag) et le texte (Text). La version JavaScript construit un arbre en utilisant l’API native du DOM. La version Scala génère du texte (le code du générateur est difficile à lire du fait que le code généré, représenté par des chaînes de caractères, contient lui-même des chaînes de caractères). Les deux générateurs de code gèrent le fait que les sous-éléments d’un élément Web peuvent être connus au moment de l’évaluation du programme initial et, le cas échéant, déroulent la boucle insérant chaque sous-élément dans son élément parent. Dans le cas contraire, ils génèrent une boucle dans le langage cible. Au final, l’exécution du listing 3.10 produit le code bas niveau du listing 1.1 côté client et du listing 1.2 côté serveur. 3.3.1 Représentation statiquement typée de chaînes de caractères contenant des expressions JavaScript Il est possible de définir, dans un document HTML, le code JavaScript à exécuter lorsqu’un événement se produit sur un élément HTML donné. Ainsi, le listing HTML 3.14 définit un élément exécutant le code JavaScript alert(’clicked’) lorsque l’utilisateur clique dessus.Définition de fragments de HTML 51 case Tag(name , children , attrs) => emitValDef(sym , src"document.createElement(’$name ’)") for ((n, v) <- attrs) { gen"$sym.setAttribute(’$n’, $v);" } children match { case Left(children) => for (child <- children) { gen"$sym.appendChild($child );" } case Right(children) => val x = fresh[Int] gen"""for (var $x = 0; $x < $children.length; $x++) { $sym.appendChild($children[$x]); }""" } case Text(content) => emitValDef(sym , src"document.createTextNode($content)") Listing 3.12 – Générateur de code JavaScript pour l’unité de langage de définition de contenus Web case Tag(name , children , attrs) => val attrsFormatted = (for ((name , value) <- attrs) yield src" $name=$${$value}"). mkString children match { case Left(children) => if (children.isEmpty) { emitValDef(sym , src"html \"\"\" < $name$attrsFormatted / >\"\"\"") } else { val qc = children.map(quote) emitValDef(sym , src"html \"\"\" < $name$attrsFormatted >$${$qc}\"\"\"" ) } case Right(children) => emitValDef(sym , src"html \"\"\" < $name$attrsFormatted >$${$children}\"\"\"" ) } case Text(content) => emitValDef(sym , src"html \"\"\" $${$content }\"\"\"") Listing 3.13 – Générateur de code Scala pour l’unité de langage de définition de contenus Web52 Partage de code
click me
Listing 3.14 – Code JavaScript inclus dans une chaîne de caractères el(’div , ’onclick -> "println (\" clicked \")")("click me") Listing 3.15 – Code Scala inclus dans une chaîne de caractères Il n’est pas possible de représenter de telles constructions avec Forest car nous n’avons pas de moyen d’obtenir, à l’intérieur d’un programme js-scala, la représentation textuelle d’un programme JavaScript à partir de sa représentation abstraite. Si nous écrivions du code Scala directement dans une chaîne de caractères, cela serait fragile car notre code Scala ne bénéficierait pas des vérifications de type apportées par le compilateur Scala, mais cela serait surtout incorrect car les navigateurs Web ne sauraient pas interpréter le code Scala. Le listing 3.15 illustre ce non-sens. Ce que nous voulons, c’est désigner une expression Scala et obtenir la représentation textuelle du code JavaScript correspondant. Nous pouvons résoudre ce problème en introduisant un nouveau mécanisme : une fonction quote qui prendrait en paramètre, sans l’évaluer, une expression Scala représentant un programme JavaScript, et retournerait une représentation textuelle de cette expression. La signature de cette fonction est donnée dans le listing 3.16. Le listing 3.17 montre comment s’appuyer sur cette fonction pour implémenter l’équivalent du listing 3.14 avec Forest, de façon statiquement typée. La fonction quote crée d’abord une fonction sans paramètre qui se contente d’évaluer l’expression donnée, puis retourne un nœud pour lequel le générateur de code JavaScript produit une chaîne de caractères contenant l’appel de la fonction produite à la première étape. Le code JavaScript généré par le listing 3.17 est donné dans le listing 3.18. 3.4 Validation 3.4.1 Objectifs Les objectifs des travaux rapportés dans ce chapitre sont, d’une part, de proposer des abstractions de haut niveau, éventuellement utilisables côtés client et serveur, produisant du code efficace. Et, d’autre part, de proposer une méthode générale pour construire, à moindre effort, de telles abstractions efficaces et dédiées au développement d’applications Web. def quote[A](a: => Rep[A]): Rep[String] Listing 3.16 – Signature de la fonction quoteValidation 53 el(’div , ’onclick -> quote { println("clicked") })("click me") Listing 3.17 – Génération d’une chaîne de caractères contenant du code JavaScript var x1 = function () { alert(’clicked ’); }; var x0 = document.createElement(’div’); x0.setAttribute(’onclick ’, ’x1()’); x0.textContent = ’click me’; Listing 3.18 – Code généré par le listing 3.17 3.4.2 Expérience Pour évaluer si notre premier objectif est atteint, nous nous appuyons sur une validation empirique. Mesures Nous utilisons, comme approximation inverse du niveau d’abstraction, le nombre de lignes de code que l’utilisateur doit écrire (plus un code est concis, plus il est haut niveau). Nous mesurons l’efficacité d’un programme par sa vitesse d’exécution (plus un programme s’exécute vite, plus il est efficace). Nous évaluons le niveau d’abstraction et l’efficacité de notre solution, que nous comparons aux autres approches actuelles permettant de partager du code entre les côtés client et serveur. Hypothèses Les hypothèses testées sont les suivantes : H1 l’utilisation de nos unités de langage montre de meilleures performances par rapport au nombre de lignes de code que les approches alternatives ; H2 nos unités de langage sont utilisables côtés client et serveur. Méthode Nous avons écrit plusieurs tests de performance sur des programmes ciblant l’utilisation d’unités de langages en particulier, et sur une application réelle. À chaque fois, nous avons écrit différentes implémentations du programme, en JavaScript, Java/GWT, HaXe et js-scala (avec nos unités de langages). Nous avons fait un effort pour respecter le style de programmation de chaque langage. Les tests de performance ont été effectués sur un ordinateur portable DELL Latitude E6430 avec 8 Go de mémoire RAM, dans le navigateur Google Chrome version 27. Les graphiques reflètent les types de mesures qui ont été effectuées : le premier groupe de mesures est la vitesse d’exécution du code JavaScript (plus l’indice est élevé, mieux c’est), le deuxième groupe mesure le nombre de lignes de code (plus l’indice est54 Partage de code Figure 3.3 – Tests de performance sur un programme utilisant l’API des sélecteurs bas, mieux c’est), et le troisième groupe montre le rapport entre la vitesse d’exécution et le nombre de lignes de code (plus l’indice est haut, mieux c’est). Les valeurs ont été normalisées de façon à ce que les graphiques puissent être affichés côte à côte sans problème d’échelle verticale. 3.4.2.1 Programmes ciblant des unités de langages Nous avons écrit des petits programmes utilisant spécifiquement l’API des sélécteurs et de manipulation de valeurs optionnelles 1 . Sélécteurs Cette abstraction ne pouvant pas être implémentée avec GWT ou HaXe puisque ces langages ne fournissent pas de mécanisme d’évaluation partielle, nous avons comparé les temps d’exécution du code JavaScript généré par le listing 3.3 avec le temps d’exécution d’un programme similaire au listing 3.1, mais utilisant seulement les fonctions haut niveau querySelector et querySelectorAll. Le programme a été exécuté dans une page Web contenant les éléments suivants : quatre éléments fieldset, chacun contenant jusqu’à deux éléments ayant pour classe word. La figure 3.3 montre les résultats du test de performance. La version JavaScriptopt correspond au listing 3.1 (qui utilise les fonctions bas niveau getElementById, getElementsByTagName et getElementsByClassName), la version JavaScript correspond au programme équivalent utilisant seulement l’API native haut niveau (c’est-à-dire 1. Le code des programmes utilisés pour réaliser les tests de performance est disponible à l’adresse suivante : https://github.com/js-scala/js-scala/tree/master/papers/gpce2013/benchmarks.Validation 55 val maybe = fun { (x: Rep[Int]) => some(x + 1) } def benchmark = for { a <- maybe (0) b <- maybe(a) c <- maybe(b) d <- maybe(c) } yield d Listing 3.19 – Programme manipulant des valeurs optionnelles les fonctions querySelector et querySelectorAll) et la version jQuery correspond au listing 3.2. La version js-scala est légèrement plus lente que la version JavaScript-opt (d’environ 14%), mais est 2.88 fois plus rapide que la version JavaScript, et 28.6 fois plus rapide que la version jQuery. Enfin, la version js-scala a un rapport performance sur nombre de lignes de code plus de 1.72 fois meilleur que les autres versions. Valeurs optionnelles Nous avons implémenté l’abstraction de manipulation de valeurs optionnelles en JavaScript pur, Java et HaXe, et avons écrit un programme manipulant des valeurs optionnelles. Le listing 3.19 montre la version js-scala du programme. La fonction maybe est une fonction partiellement définie sur les valeurs de type Int. La figure 3.4 montre les résultats du test de performance. La version js-scala est 3 à 10 fois plus rapide que les autres versions. Cette version est également la plus concise (cela provient essentiellement de la syntaxe for, qui n’a pas d’équivalent dans les autres langages). Finalement, la version js-scala a un rapport performance sur lignes de code plus de 4 fois supérieur aux autres versions. 3.4.2.2 Application réelle Chooze 2 est une application complète pour effectuer des sondages en ligne. L’application permet aux utilisateurs de créer des sondages, de définir les différents choix possibles pour une question, de partager un sondage avec d’autres personnes, de voter et de consulter les résultats. L’application contient du code JavaScript pour gérer le comportement dynamique de l’application : interdiction d’une double soumission d’un vote, mise à jour du formulaire de création de sondage, interactions avec l’interface utilisateur, etc. La taille totale de l’application (incluant les côtés client et serveur) est de l’ordre du millier de lignes de code. 2. Le code source est disponible à l’adresse http://github.com/julienrf/chooze, dans les branches vanilla, jquery, gwt, haxe and js-scala.56 Partage de code Figure 3.4 – Tests de performance sur un programme manipulant des valeurs optionnelles L’application a été initialement écrite avec jQuery. Nous l’avons réécrite en JavaScript pur (version « vanilla », bas niveau et optimisé, sans utilisation de bibliothèque tierce), js-scala, GWT et HaXe. Tests de performance Le test de performance a mesuré le temps d’exécution d’un scénario d’utilisation : 2000 clics sur un bouton ajoutant un champ de formulaire. Le code impliqué utilise les API de manipulation de valeurs optionnelles, de sélécteurs et de définition de contenus Web. La figure 3.5 montre les résultats du test. Les performances d’exécution des versions vanilla, HaXe et js-scala sont similaires (bien que la version js-scala soit légèrement moins rapide, de 6%). Il est notable que les versions vanilla et HaXe utilisent toutes les deux du code bas niveau comparé à la version js-scala, comme le souligne la partie au milieu de la figure : la version js-scala tient en 74 lignes de code, tandis que la version vanilla tient en 116 lignes de code (57% plus longue) et la version HaXe tient en 148 lignes de code (100% plus longue). La version jQuery, dont le code est haut niveau (54 lignes de code, 27% plus concise que la version js-scala) est 10 fois plus lente que la version js-scala. La dernière partie de la figure montre que la version js-scala dispose du meilleur rapport performances sur nombre de lignes de code. Ce rapport est 1.48 fois meilleur que pour la version vanilla, 1.88 fois meilleur que pour la version HaXe, 3.45 fois meilleur que pour la version GWT et 7.82 fois meilleur que pour la version jQuery.Validation 57 Figure 3.5 – Tests de performance sur une application réelle Réutilisation de code La version js-scala du programme nous a permis de réutiliser quelques définitions de contenus Web entre les côtés client et serveur. Avec GWT nous n’avons pas le choix : le contenu des pages est forcément construit côté client. Dans les autres versions, le code définissant le contenu des pages est dupliqué entre les côtés client et serveur. Cela représente 20 lignes de code JavaScript (17% du total) et 15 lignes de HTML (5% du total) dans la version vanilla, 19 lignes de HaXe (13% du total) et 15 lignes de HTML (5% du total) dans la version HaXe. Dans la version js-scala, les définitions de fragments Web partagées entre les côtés client et serveur représentent 22 lignes de Scala (30% du total) et ont permis d’économiser 15 lignes de HTML (5% du total). 3.4.3 Discussion 3.4.3.1 Analyse des résultats Nos résultats montrent que le code haut niveau écrit avec js-scala génère du code JavaScript bas niveau dont les performances d’exécution sont du même ordre de grandeur que du code JavaScript optimisé à la main. Les tests ciblant l’utilisation d’une abstraction en particulier montrent de bons résultats, comme attendu. Les gains sur le rapport entre les performances d’exécution et le nombre de lignes de code varient d’un facteur 1.72 à 30 selon les technologies comparées. Le test sur une application réelle permet de tenir compte de la place relative, dans une application complète, des gains individuels décrits au paragraphe précédent. Ce58 Partage de code test affiche tout de même un gain sur le rapport entre les performances d’exécution et le nombre de lignes de code variant d’un facteur 1.48 à 7.82. Ces résultats valident l’hypothèse H1 : le rapport entre les performances et le nombre de lignes de code est meilleur avec nos unités de langage qu’avec les approches alternatives. Nos tests montrent également qu’une partie du code d’une application réelle peut être partagée entre les parties client et serveur, ce qui valide l’hypothèse H2. 3.4.3.2 Limites de notre validation Mesure du niveau d’abstraction Notre objectif est de mettre en perspective les performances d’exécution par rapport au niveau d’abstraction. Nous avons choisi le nombre de lignes de code comme indicateur de l’inverse du niveau d’abstraction. Or, ce choix n’est pas sientifiquement établi. Cependant, aucune autre métrique n’a été proposée par la communauté scientifique pour mesurer le niveau d’abstraction. Différences de concision propres aux langages Nous comparons la concision du code dans plusieurs langages. Or, la syntaxe propre à chaque langage peut introduire des différences inter-langages indépendantes du niveau d’abstraction. Par exemple, la taille du programme Java utilisant le langage de manipulation de valeurs optionnelles pourrait être quasiment divisée par deux en utilisant les ❧❛♠❜❞❛ ❡①♣r❡ss✐♦♥s [Jav]. Cependant, il n’existe aucun travail scientifique fournissant un facteur de correction pour gommer ces différences. Représentativité des tests effectués Il n’est pas correct d’extrapoler les résultats des tests de performance, obtenus sur l’application réelle, à toutes les applications Web. Cependant, l’application que nous avons utilisée était de taille modeste et contenait peu de code côté client. Nous pensons donc que sur des applications de taille plus grosses et implémentant plus de fonctionnalités côté client, les tests pencheraient encore plus en faveur de js-scala. Respect du style idiomatique des technologies comparées Pour gérer l’interface utilisateur, la version GWT n’utilise pas la bibliothèque de composants fournie par GWT. Au lieu de cela, nous interceptons les événements directement au niveau du DOM, comme nous le ferions en JavaScript pur. Cependant, cette façon d’utiliser GWT n’a pas d’impact sur les performances et a seulement un impact marginal sur la concision du code. 3.5 Conclusion Les abstractions de haut niveau permettent à la fois de réduire la complexité du code et, dans le cas des applications Web, de masquer les différences entre les environnements client et serveur. Cependant, outre le coût en performance des abstractions,Conclusion 59 en masquant les différences d’environnements client et serveur l’utilisateur perd l’opportunité d’exploiter leurs spécificités. En implémentant nos abstractions sous forme de bibliothèques générant du code, nous conservons les avantages apportés par les abstractions concernant le confort d’ingénierie. Mais nous avons également la possibilité de générer du code efficace, capable de tirer parti des spécificités des environnements client et serveur. Bien que le coût initial de cette approche soit non négligeable (il faut implémenter des générateurs de code pour un langage généraliste), l’ajout d’abstractions dédiés à un problème donné nécessite peu d’efforts pour l’utilisateur : la définition d’une API, une implémentation retournant une représentation abstraite de programme, et un générateur de code pour cette représentation abstraite, pour chaque plateforme ciblée. Tous ces composants peuvent être définis de façon indépendante, sans qu’il ne soit nécessaire de modifier le code d’un compilateur existant. Ainsi, nous avons implémenté des unités de langage pour rechercher des éléments dans une page Web, manipuler des valeurs optionnelles, et représenter des contenus Web. Le code écrit avec les deux dernières unités de langage peut être partagé côtés client et serveur. Ces abstractions produisent du code exploitant les spécificités des environnements client et serveur. Enfin, les performances d’exécution sont du même ordre de grandeur que du code bas niveau optimisé à la main.60 Partage de codeChapitre 4 Sûreté du typage Ce chapitre présente une solution au problème de l’exposition des interfaces de programmation du navigateur Web dans un langage statiquement typé. Nous commençons par détailler les limites des solutions actuelles puis nous présentons deux solutions préservant un maximum d’informations dans les types tout en donnant autant de pouvoir d’expression aux utilisateurs. La seconde solution est plus pratique pour l’utilisateur mais s’appuie sur le concept de t②♣❡s ❞é♣❡♥❞❛♥ts, peu répandu dans les systèmes de type des langages généralistes. Le contenu de ce chapitre a fait l’objet d’une publication [RFBJ14]. 4.1 Inventaire des fonctions problématiques Illustrons les difficultés à définir des signatures de type pour des APIs dynamiquement typées en prenant comme exemples quelques-unes des principales 1 fonctions de l’API du navigateur : createElement, getElementsByTagName et addEventListener 2 . 4.1.1 createElement Cette fonction, ainsi que les difficultés pour lui donner une signature de type dans un langage statiquement typé, ont été présentées dans les chapitres 1 et 2. La suite de cette section détaille les différentes signatures de type proposées pour cette fonction par les langages de programmation statiquement typés courants. 4.1.1.1 Signatures de type proposées par les langages actuels API trop générale La première solution consiste simplement à conserver la même signature de type et à imposer au programmeur d’effectuer une opération de trans- 1. D’après le Mozilla Developer Network (https://developer.mozilla.org/en-US/docs/DOM/DOM Reference/Introduction). 2. Nous présentons seulement les fonctions pour lesquelles il est difficile de définir une signature de type. 6162 Sûreté du typage typage (t②♣❡ ❝❛st) pour obtenir une valeur d’un type plus précis. Une telle solution ressemblerait, à l’utilisation, en Scala, au listing suivant : val img = createElement("img"). asInstanceOf[ImageElement] img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie Évidemment, l’utilisation d’opérations de transtypage introduit une fragilité allant à l’encontre de l’utilisation même d’un langage statiquement typé. API trop spécifique Une autre solution consiste à définir des fonctions distinctes, retournant chacune un type d’élément spécifique, plutôt qu’une seule fonction avec pour type de retour Element. Ainsi, au lieu d’avoir une seule fonction, createElement, il s’agit d’exposer autant de fonctions qu’il y a de types d’éléments possibles, par exemple createImgElement, createInputElement, etc : def createImgElement (): ImageElement def createInputElement (): InputElement etc. L’utilisation d’une telle solution est illustrée par le listing suivant : val img = createImgElement () img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie L’inconvénient de cette solution, évoqué dans la section 2.3 est qu’elle réduit le pouvoir d’expression de l’API. En effet, cette solution utilise des fonctions plus spé- cifiques que la fonction initiale ce qui rend impossible l’implémentation de certains programmes, qu’il est pourtant possible d’implémenter avec la fonction initiale, plus générale. 4.1.2 getElementsByTagName 4.1.2.1 Description La fonction getElementsByTagName prend en paramètre un nom d’élément HTML et retourne l’ensemble des éléments de ce type dans le document. Sa signature est la suivante : HTMLCollection getElementsByTagName(String name); Le type HTMLCollection représente un tableau d’Elements HTML. Le problème rencontré avec cette fonction est similaire à celui posé par la fonction createElement : les éléments retournés ont un type trop général. En effet, l’expression getElementsByTagName(’input’) retourne un tableau de InputElement mais la signature de type n’expose que le type général Element.Inventaire des fonctions problématiques 63 4.1.2.2 Signatures de type proposées par les langages actuels Les langages statiquement typés conservent la signature de type standard pour cette fonction. Ils exposent donc un type de retour trop général, obligeant les utilisateurs à effectuer des opérations de transtypage sur le résultat. 4.1.3 addEventListener 4.1.3.1 Description La fonction addEventListener permet de réagir aux événements produits par l’utilisateur d’une application Web. Elle prend en paramètre un type d’événement et une fonction à appeler lorsqu’un tel événement se produit : void addEventListener(String type, Function callback ); Le type Function est peu précis, il représente une fonction prenant un nombre arbitraire de paramètres dont les types sont également arbitraires. Le listing suivant montre comment l’utiliser, en JavaScript, pour réagir aux clics et appuis de touches de l’utilisateur : document.addEventListener(’click’, function (event) { console.log(event.button ); }); document.addEventListener(’keydown ’, function (event) { console.log(event.key); }) Ce listing affiche les valeurs de la propriété button de l’événement représentant chaque clic et de la propriété key de l’événement représentant chaque appui de touche. Ici encore, dans un monde statiquement typé, le code ci-dessus produirait une erreur de typage car le type de l’objet event est indéfini, donc il ne possède pas de propriétés button ou key. Notons que la propriété button est définie par le type MouseEvent et la propriété key est définie par le type KeyboardEvent. Ainsi, on aimerait, idéalement, trouver une signature de type pour la fonction addEventListener telle que le listing suivant, en Scala, compile sans erreur, sauf l’avant-dernière ligne : document.addEventListener("click", event => { println(event.button) println(event.key) // Erreur: propriete ’key’ non definie }) De même, le listing suivant doit compiler, sauf l’avant-dernière ligne : document.addEventListener("keydown", event => { println(event.key) println(event.button) // Erreur: propriete ’button ’ non definie })64 Sûreté du typage Autrement dit, le type de l’objet event doit être MouseEvent lorsque l’utilisateur ré- agit à l’événement "click", et KeyboardEvent lorsque l’utilisateur réagit à l’événement "keydown". 4.1.3.2 Signatures de type proposées par les langages actuels API trop générale Comme précédemment, la première solution consiste à conserver une signature de type trop générale et donc à imposer à l’utilisateur d’effectuer une opération de transtypage pour obtenir une valeur d’un type plus précis. Une telle signature de type serait la suivante, en Scala : def addEventListener(event: String , callback: Event => Unit): Unit Cette solution souffre des même inconvénients que ceux décrits précédemment. API trop spécifique Une autre solution consiste à définir des fonctions distinctes pour réagir aux différents types d’événements plutôt qu’une seule fonction trop géné- rale : def addClickEventListener(callback: MouseEvent => Unit): Unit def addKeyDownEventListener(callback: KeyboardEvent => Unit): Unit etc. L’inconvénient de cette solution est qu’elle réduit le pouvoir d’expression de l’API. En effet, cette solution utilise des fonctions plus spécifiques que la fonction initiale, rendant impossible l’implémentation de certains programmes, qu’il est pourtant possible d’implémenter avec la fonction initiale, plus générale. Par exemple, le programme JavaScript suivant ne peut pas être implémenté : var observe = function (type) { return function (callback) { document.addEventListener(type, callback ); } }; Ce programme définit une fonction observe réalisant une application partielle des paramètres de la fonction addEventListener 3 . Une variante rencontrée consiste à définir un type abstrait EventListener, ne comportant aucune opération, et autant de sous-types qu’il y a de genres d’événements possibles, chacun comportant une seule opération abstraite correspondant au callback. Il est ensuite possible de définir une seule opération, addEventListener, prenant en paramètre un EventListener : sealed trait EventListener abstract class ClickListener(callback: MouseEvent => Unit) extends EventListener abstract class KeyDownListener(callback: KeyboardEvent => Unit) extends EventListener etc. 3. Le code de cette fonction est inspiré des bibliothèques JavaScript existantes de programmation fonctionnelle réactive : Rx.js [LB11] et Bacon.js [Bac]Solutions bien typés et conservant le même pouvoir d’expression 65 def addEventListener(listener: EventListener ): Unit Cette solution souffre du même problème de réduction du pouvoir d’expression de l’API initiale du navigateur. 4.1.4 Discussion Les solutions actuellement implémentées par les langages de programmation statiquement typés produisant du JavaScript soit réduisent le pouvoir d’expression soit ne sont pas bien typées. 4.2 Solutions bien typés et conservant le même pouvoir d’expression 4.2.1 Généralisation des solutions existantes Les solutions bien typées existantes réduisent toutes le pouvoir d’expression de l’utilisateur. Elles ont toutes un point commun : elles réduisent le nombre de paramètres passés par l’utilisateur. Par exemple, au lieu d’écrire : addEventListener("click", callback) l’utisateur écrit : addEventListener(new ClickListener(callback )) ou : addClickEventListener(callback) Dans les deux cas, le paramètre correspondant au nom de l’événement, "click", disparaît. De même, au lieu d’écrire : createElement("img") l’utilisateur écrit : createImgElement () Le paramètre correspondant au nom de l’élément n’est plus présent. Cette solution permet de distinguer entre les différents noms d’événements ou d’éléments HTML en utilisant des noms de fonction différents. Chaque nom correspond à une fonction dont la signature expose des types plus précis que la fonction, plus générale, de l’API native du navigateur. Plus précisément, cette solution remplace un paramètre, dont la signature de type de la fonction dépend, par un nom constant. C’est parce que cette solution élimine un paramètre de la fonction initiale qu’elle est moins expressive. Notons que cette solution ne fonctionne que parce que la plage de valeurs possibles pour ces paramètres est connue à l’avance et fixée : la fonction createElement ne prend en paramètre que des noms d’éléments HTML. De même, la fonction addEventListener ne prend en paramètre que des noms d’événements.66 Sûreté du typage 4.2.2 Utilisation des types paramétrés Notre but est de trouver, pour les fonctions présentées précédemment, une signature de type qui ne réduise pas le pouvoir d’expression et qui soit bien typée (ou qui ne contraigne pas l’utilisateur à écrire du code mal typé). Il est possible de représenter la relation de dépendence entre un type T et un paramètre p impliqués dans une fonction en procédant comme suit : — définir un type paramétré P[U], — affecter le type P[U] au paramètre p, — remplacer les occurrences de T par U, — définir autant de valeurs de type P[U] qu’il y a de valeurs possibles pour p, chacune fixant le paramètre de type U à un type plus précis. L’application de cette solution aux fonctions createElement et getElementsByTagName est illustrée par le code suivant : class ElementName[E] def createElement[E](name: ElementName[E]): E def getElementsByTagName[E](name: ElementName[E]): Array[E] val Img = new ElementName[ImageElement] val Input = new ElementName[InputElement] // etc. pour chaque nom d’element possible Les deux fonctions, createElement et getElementsByTagName, ont leur type de retour (Element ou Array[Element] dans l’API initiale) qui dépend de la valeur d’un paramètre name. Nous introduisons un type ElementName[E], et attribuons ce type, plutôt que String, au paramètre name. Nous attribuons également le type E plutôt qu’Element au type de retour de la fonction (ou Array[E] plutôt que Array[Element], dans le cas de getElementsByTagName). Enfin, nous définissons autant de valeurs, Img, Input, etc. qu’il y a de types d’éléments HTML possibles. L’idée essentielle de notre solution consiste à utiliser des types différents pour représenter les différents noms d’éléments HTML (✐✳❡✳ le type ElementName[ImageElement] pour l’élément img, le type ElementName[InputElement] pour l’élément input, etc.), et à s’appuyer sur un mécanisme (les types paramétrés) permettant de retrouver le type d’un élément à partir du type du nom de l’élément : le type ElementName[E] définit la relation entre un nom d’élément HTML et son type. Le paramètre de type E est parfois appelé t②♣❡ ❢❛♥tô♠❡ car les valeurs de type ElementName[E] ne contiennent jamais de valeur de type E [LM99]. Le listing suivant montre l’utilisation de notre solution : val img = createElement(Img) img.src = "/icon.png" // Ok img.value = "foo" // Erreur L’utilisation de la valeur Img fixe le type du paramètre name à ElementName[ImageElement], et, par conséquent, fixe le type de retour de l’appel à la fonction createElement à ImageElement.Solutions bien typés et conservant le même pouvoir d’expression 67 Ainsi, notre solution est bien typée. En outre, notre solution ne réduit pas le pouvoir d’expression de l’utilisateur car elle ne réduit pas le nombre de paramètres de la fonction. Il est donc possible d’implémenter la fonction createTwoElements comme suit : createTwoElements[A, B](fst: ElementName[A], snd: ElementName[B]): (A, B) = (createElement(fst), createElement(snd)) La même solution est applicable à la fonction addEventListener : class EventName[E] def addEventListener[E](name: EventName[E])( callback: E => Unit): Unit val Click = new EventName[MouseEvent] val KeyDown = new EventName[KeyboardEvent] // etc. pour chaque nom d’evenement possible L’utilisation est la suivante : addEventListener(Click) { event => println(event.button) } Comme précédemment, notre solution est bien typée et donne autant de pouvoir d’expression à l’utilisateur. Nous sommes ainsi capable d’implémenter la fonction observe : def observe(name: EventName[A]): (A => Unit) => Unit = callback => addEventListener(name)( callback) Notre solution comporte cependant un inconvénient à l’utilisation : toute fonction prenant en paramètre un nom d’élément HTML ou un nom d’événement doit également prendre un paramètre de type (un type fantôme), correspondant au type de l’élément HTML ou de l’événement désigné. En effet, la fonction createTwoElements prend deux paramètres de type, A et B, et la fonction observe prend un paramètre de type, A. 4.2.3 Utilisation des types dépendants Cette section montre comment nous pouvons nous débarrasser des type fantômes introduits dans la section précédente en utilisant des types ❝❤❡♠✐♥✲❞é♣❡♥❞❛♥ts [OCRZ03]. Plus précisément nous représentons les paramètres de type en utilisant des types ♠❡♠❜r❡s, comme cela a été décrit dans [OZ05]. 4.2.3.1 Types membres Les types membres étant peu présents dans les langages de programmation géné- ralistes, commençons par rappeler ce concept. Les langages de programmation gèrent en général deux mécanismes généraux d’abstraction : les paramètres et les membres abstraits. Par exemple, le langage Java gère68 Sûreté du typage la paramétrisation des valeurs (paramètres de méthodes) et des types (❣❡♥❡r✐❝s) et les membres abstraits pour les valeurs (méthodes abstraites). Illustrons la différence entre les paramètres et les membres par un exemple. Supposons que l’on veuille écrire une classe réalisant une addition entre deux nombres. Nous souhaitons que notre classe soit capable d’additionner deux nombres quels qu’ils soient. Autrement dit, nous souhaitons que les nombres à additionner soit abstraits pour la classe. Nous pouvons réaliser cela en écrivant une méthode paramétrée par les nombres à additionner, comme suit : class Plus { public int apply(int a, int b) { return a + b; } } Une autre façon de faire, tout à fait équivalente, consiste à utiliser des membres abstraits pour représenter les nombres à additionner : abstract class Plus { abstract int a(); abstract int b(); public int apply() { return a() + b(); } } Ainsi, les paramètres et les membres sont deux moyens de généralisation équivalents. Dans le cas de Java, le langage gère à la fois les paramètres et les membres pour généraliser au niveau valeur, mais il ne gère que les paramètres pour généraliser au niveau type (les ❣❡♥❡r✐❝s). Le langage Scala, quant à lui, gère à la fois les paramètres et les membres pour gé- néraliser au niveau type [CGLO06, OCRZ03]. Illustrons ce concept avec, par exemple, un type représentant une collection d’objets, générique, contenant des objets ayant tous le même type. Nous pouvons représenter une telle collection avec le type suivant : trait Collection[A] { def get(i: Int): A } Le paramètre de type A représente le type des éléments contenus dans une collection donnée. Par exemple, le type Collection[Int] représente une collection spéci- fique, contenant uniquement des nombres entiers. Nous pouvons représenter la même collection générique en utilisant un type membre à la place du paramètre de type A : trait Collection { type A def get(i: Int): A }Solutions bien typés et conservant le même pouvoir d’expression 69 Nous pouvons spécialiser le type Collection pour ne contenir que des nombres entiers en instanciant le type membre A comme suit : trait IntCollection extends Collection { type A = Int } L’instanciation d’un type membre est l’équivalent au niveau type de l’implémentation d’une méthode abstraite au niveau valeur. Enfin, il est possible de faire référence au type membre A depuis l’extérieur du trait Collection comme suit : def head(collection: Collection ): collection.A = collection.get(0) La méthode head récupère le premier élément d’une collection donnée. Son type de retour, collection.A, correspond à l’instance du type membre A de la collection passée en paramètre. Plus généralement, un type membre abstrait d’une classe est un type interne qui peut être utilisé pour qualifier des valeurs et qui peut être instancié par des sousclasses. Depuis l’extérieur de la classe, on peut désigner un type membre en effectuant une sélection de type sur une instance de la classe : l’expression p.C désigne le type membre C d’une valeur p, et correspond à l’instance de C du type singleton de la valeur p. 4.2.3.2 Utilisation des types membres Le type ElementName[E] peut être réécrit à l’aide d’un type membre comme suit : abstract class ElementName { type Element } val Img = new ElementName { type Element = ImageElement } val Input = new ElementName { type Element = InputElement } // etc. def createElement(name: ElementName ): name.Element Nous avons remplacé le paramètre de type E par un type membre Element. Les valeurs Img, Input, etc. instancient ce membre en lui donnant le type d’élément HTML correspondant. Enfin, la fonction createElement retourne une valeur de type name.Element, correspondant à l’instance du membre Element pour leur paramètre name. Utilisation : val img = createElement(Img) img.src = "/icon.png" // Ok img.value = "foo" // Erreur70 Sûreté du typage Cette représentation conserve autant de pouvoir d’expression que la précédente, comme en atteste l’implémentation suivante de la fonction createTwoElements : def createTwoElements(fst: ElementName , snd: ElementName ): (fst.Element , snd.Element) = (createElement(fst), createElement(snd)) Enfin, le même procédé s’applique au type EventName : trait EventName { type Event } object Click extends EventName { type Event = MouseEvent } // etc. pour chaque nom d’evenement possible def addEventListener(name: EventName) (callback: name.Event = > Unit): Unit def observe(name: EventName ): (name.Event => Unit) => Unit = callback => document.addEventListener(name)( callback) Notons que les fonctions createTwoElements et observe ne comportent plus de types fantômes. 4.3 Discussion 4.3.1 Analyse Implémentation dans js-scala Nous avons implémenté, au sein du projet js-scala, une API basée sur la solution utilisant les types chemin-dépendants. Nous avons également implémenté plusieurs applications utilisant cette API, notamment une application de discussion instantanée et une application de sondages. La taille de ces applications est de l’ordre de plusieurs centaines de lignes de code. Du fait que notre API est bien typée, le code est exempt d’opérations de transtypage. Clarté de l’API Notre solution offre une correspondance un pour un avec l’API native du navigateur. À titre de comparaison, les solutions existantes bien typées font souvent correspondre une seule fonction de l’API native à plus de 30 fonctions. Ainsi, GWT fait correspondre 31 fonctions spécialisées pour la fonction createElement, et Dart en fait correspondre 62. De même, GWT fait correspondre 32 fonctions spécialisées pour la fonction addEventListener, et Dart en fait correspondre 49. Notre solution a l’avantage d’être bien typée sans multiplier le nombre de fonctions ayant un rôle similaire. Commodité syntaxique Les annotations de type des langages à typage statique peuvent être perçues par le développeur comme une complexité indésirable. Dans notre cas,Conclusion 71 la solution s’appuyant sur des types paramétrés est utilisable avec de nombreux langages généralistes tels que Java, Dart, TypeScript, Kotlin, HaXe, Opa, Idris ou Elm. Cependant cette solution nécessite d’inclure des types fantômes, indésirables, dans les signatures des fonctions prenant en paramètre des noms d’événements ou d’éléments HTML. La seconde solution, en revanche, conduit à des signatures de fonctions d’une verbosité équivalente à celle de la spécification standard des API HTML et DOM. Nous estimons qu’il n’y a, dans ce cas, pas de prix syntaxique à payer. Cependant, cette solution n’est utilisable qu’avec des langages supportant les types dépendants, tels que Scala, Idris ou Agda. 4.3.2 Limitations Nos solutions remplacent un paramètre de type String par un paramètre d’un type plus précis permettant de déduire le type de l’élément ou événement correspondant. Ce faisant, nos solutions diminuent légèrement le pouvoir d’expression par rapport à l’API native : il n’est plus possible, par exemple, de passer en paramètre une valeur résultant de la concaténation de deux chaînes de caractères ou d’une quelconque autre opération de manipulation de chaîne de caractères. Nos solutions s’appliquent seulement aux fonctions dont la signature comporte des types qui dépendent de la valeur d’un des paramètres. Si ce genre de fonctions est commun dans les API JavaScript, ce n’est pas le cas de toutes les fonctions. Par exemple, la fonction getElementById ne peut pas bénéficier de notre solution. Cette fonction récupère un élément du document à partir de la valeur de son attribut id, or le type de l’élément ne peut pas être déduit depuis la valeur de cet attribut. 4.4 Conclusion S’appuyer sur un langage statiquement typé produisant du JavaScript n’est pas suffisant pour profiter du typage statique pour le développement de la partie client d’une application Web. En effet, l’API du navigateur Web doit également être exposée dans ce langage et son système de type. Or, cela n’est pas facile à réaliser pour certaines fonctions et conduit généralement soit à perdre en sûreté de typage, soit à perdre en pouvoir d’expression. Dans ce chapitre, nous avons présenté deux méthodes pour exposer les fonctions problématiques de cette API. La première méthode s’appuie sur les types paramétrés et est utilisable avec la plupart des langages de programmation courants (❡✳❣✳ Java ou C#). La seconde méthode apporte un confort syntaxique supplémentaire et nécessite que le langage gère les types dépendants (❡✳❣✳ Scala). Nos deux méthodes évitent aux développeurs d’avoir recours à des opérations de transtypage non sûres et conservent le même pouvoir d’expression que les fonctions natives. Nos résultats suggèrent que la prise en charge des types dépendants peut être un atout pour les langages à typage statique ciblant la programmation Web.72 Sûreté du typageChapitre 5 Un style d’architecture pour les applications Web résilientes Ce chapitre présente une approche pour développer des applications Web résilientes par construction. Nous nous appuyons, pour cela, sur un style d’architecture découpant le code de l’application de telle sorte qu’il soit à la fois facile pour les dé- veloppeurs de raisonner dessus, et facile techniquement d’implémenter les différents aspects de façon réutilisable et indépendamment les uns des autres. La suite de ce chapitre donne une vision générale du style d’architecture puis montre progressivement, en détaillant certaines parties, comment il répond à nos objectifs. 5.1 Présentation générale La figure 5.1 donne une vue d’ensemble des différents composants impliqués dans notre style d’architecture. Nous nous appuyons sur plusieurs concepts présentés dans l’état de l’art. Les client et serveur contiennent tous les deux des composants simiFigure 5.1 – Vue d’ensemble de notre style d’architecture pour applications Web résilientes 7374 Un style d’architecture pour les applications Web résilientes laires : Model Données représentant l’état du système ; View Affichage d’informations destiné aux utilisateurs ; Control Interprétation des actions de l’utilisateur en termes d’actions métier (p. ex. un clic de l’utilisateur est traduit en une action de suppression de tâche), actualisation du ▼♦❞❡❧ et de la ❱✐❡✇ ; Sync Synchronisation de l’état du système entre clients et serveurs. Les spécificités de cette architecture sont les suivantes : — La communication client-serveur se situe au niveau ❈♦♥tr♦❧ (tout comme dans le modèle PAC-C3D) plutôt que ▼♦❞❡❧ (comme c’est le cas dans les modèles dérivées de MVC présentés dans l’état de l’art) ; — Le composant de synchronisation côté client est intercalé entre les composants de contrôle client et serveur. Il joue un rôle de tampon en stockant localement toutes les actions réalisées par l’utlisateur avant de les synchroniser quand le contexte le permet (✐✳❡✳ quand la connexion est établie) ; — L’état du système est représenté par la succession des actions effectuées par les utilisateurs, selon le principe d’❡✈❡♥t s♦✉r❝✐♥❣ ; — La synchronisation est basée sur les actions, afin de profiter des algorithmes sophistiqués de résolution de conflits tels que TIPS ; — Différentes stratégies de synchronisation basées sur les actions peuvent être employées (p. ex. Jupiter OT, TIPS, etc.) ; — Chaque utilisateur fait évoluer sa propre réplique du système de façon optimiste (c’est-à-dire sans attendre l’aval du serveur après chaque action), et toutes les répliques convergent éventuellement ; — Les composants ▼♦❞❡❧ et ❱✐❡✇ sont optionnels côté serveur. En effet, comme l’état du système peut être représenté par une suite d’actions effectuées par les utilisateurs, un journal suffit pour le stocker. La partie ▼♦❞❡❧ permet, en plus, de maintenir une représentation en mémoire de l’état du système, utilisable pour transmettre aux clients un s♥❛♣s❤♦t représentant le système. Cela permet de réduire le temps de reconstruction de la réplique de chaque client. La partie ❱✐❡✇, sur le serveur, permet d’exposer le contenu du système aux moteurs de recherche. 5.2 Fonctionnement du système de synchronisation L’objectif du système de synchronisation est de permettre à l’utilisateur de continuer à utiliser l’application même lorsque la connexion réseau est interrompue, et de synchroniser automatiquement ses modifications lorsque la connexion est de nouveau établie. Cette section décrit son fonctionnement en allant du scénario le plus simple au plus complexe.Fonctionnement du système de synchronisation 75 Figure 5.2 – Diagramme des classes impliquées dans la synchronisation 5.2.1 Scénario mono-utilisateur La figure 5.2 montre le découpage, sous forme de diagramme de classes, d’une application basée sur notre architecture. Le diagramme montre seulement les classes impliquées dans le processus de synchronisation. La classe abstraite Event représente une action métier. Elle est spécialisée en autant de sous-classes que l’application gère d’actions métier (ici, Event1 et Event2). Ces actions métier sont partagées par les côtés client et serveur. Côté serveur, un journal stocke les actions transmises par les diffé- rents utilisateurs. Dans le cas d’une application de gestion de tâches, les Events possibles pourraient être les suivants : Added (une tâche est ajoutée), Removed (une tâche est supprimée) et Toggled (l’état d’une tâche passe de « non réalisée » à « réalisée », ou inversement). Les Models seraient Task(content, isCompleted) et TaskList(tasks). Côté client, à chaque Model serait associé un Control, utilisant des Views pour l’affichage. La figure 5.3 décrit le fonctionnement dynamique de l’application, dans un scé- nario mono-utilisateur, lorsque celui-ci effectue une action. Les interactions entre les différents composants sont les suivantes : 1. L’utilisateur interagit avec l’interface utilisateur (p. ex. il clique sur un bouton) ; 2. Le composant de contrôle traduit cet événement en action métier (ici, Event1) ; 3. Cette action métier est transmise au composant de synchronisation ; 4. Le composant de synchronisation, d’une part, execute la logique métier correspondant à cette action ; 5. La logique métier impacte le ▼♦❞❡❧ et la ❱✐❡✇ est mise à jour ; 6. Le composant de synchronisation, d’autre part, transmet l’action au serveur, si la connexion réseau le permet. Autrement, l’action est stockée dans une file d’attente jusqu’à ce que la connexion réseau permette de la transmettre au serveur ; 7. Le serveur ajoute l’action à son journal ; 8. Le serveur indique au client que son action a bien été enregistrée. Le client supprime alors l’action de sa file d’attente.76 Un style d’architecture pour les applications Web résilientes Figure 5.3 – Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario mono-utilisateur Cette architecture permet à l’utilisateur de modifier l’état du système sans avoir à attendre l’aval du serveur à chaque action : toutes ses actions sont enregistrées et transmises au serveur si la connexion réseau le permet. 5.2.2 Scénario multi-utilisateur La prise en compte de plusieurs utilisateurs simultanés nécessite d’effectuer deux modifications : i) les clients doivent être notifiés lorsqu’un autre utilisateur a effectué une action, et ii) le système de synchronisation doit résoudre les éventuels conflits de modifications concurrentes. La figure 5.4 illustre ces modifications. Jusqu’à l’étape 6 les interactions sont les mêmes que précédemment. Puis, lorsque le serveur reçoit l’action e d’un utilisateur, il la transforme éventuellement en une action e’ (étape 7), selon l’algorithme de convergence utilisé. De même, il notifie les clients (étape 8) en transformant éventuellement l’action en une action e’’, spécifique à chaque client, afin que l’état de tous les clients converge. Notons que pour certains algorithmes, la transformation de l’action a lieu côté serveur (p. ex. TIPS), et, dans d’autres cas, côté client (p. ex. Jupiter OT). La logique métier correspondant à l’action est ensuite exécutée sur les clients notifiés (étapes 9 et 10).Généralisation du composant de synchronisation 77 Figure 5.4 – Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario multi-utilisateur 5.3 Généralisation du composant de synchronisation La dernière étape de notre contribution consiste à généraliser le système de synchronisation de façon à isoler la stratégie de synchronisation du reste de l’application (afin de réutiliser une stratégie dans différentes applications). La figure 5.5 montre cette évolution. Les classes en gris sont spécifiques à une application donnée, les classes en blanc sont plus générales, donc réutilisables. Le composant de synchronisation implémente une stratégie de synchronisation en particulier. Sa méthode abstraite interprete est implémentée par chaque application. Cette méthode définit la logique métier correspondant à la réalisation d’une action donnée. Ainsi, lorsqu’une action est traitée par un composant de contrôle, celui-ci la transmet au composant de synchronisation ✈✐❛ la méthode apply, lequel appelle ensuite sa méthode interprete pour invoquer la logique métier associée (il s’agit du patron de conception ❚❡♠♣❧❛t❡ ▼❡t❤♦❞). Les classes en pointillés représentent des composants qui ne sont pas couplés au composant de synchronisation. 5.4 Évolution : fonctionnement complètement hors-ligne L’architecture décrite précédemment gère les interruptions de réseau mais elle ne stocke pas les données du système de façon persistante. La connexion est donc nécessaire pour le chargement initial de l’application. Une fois l’application chargée dans le navigateur, si l’utilisateur actualise la page il a besoin de la connexion réseau. Autrement dit, le support du mode hors-ligne, tel que décrit précédemment, n’est effectif que si l’utilisateur a déjà chargé l’application dans son navigateur et qu’il ne ferme78 Un style d’architecture pour les applications Web résilientes Figure 5.5 – Généralisation de la synchronisation pas son onglet. Il est techniquement possible de pallier ce problème en stockant de façon persistante le journal d’actions pour pouvoir reconstruire l’état de l’application et en utilisant le cache du navigateur pour que la connexion réseau ne soit pas nécessaire pour le chargement de l’application. Le journal des actions est déjà stocké de façon persistante sur le serveur. Des solutions récentes de stockage persistant côté client telles que IndexedDB [Ind] permettent de stocker le journal côté client également. L’❆♣♣❧✐❝❛t✐♦♥ ❈❛❝❤❡ [App] permet de stocker le code client de l’application dans le cache du navigateur, et donc permet de lancer l’application sans connexion réseau. En utilisant ces deux systèmes de stockage, il est possible de gérer le fonctionnement complètement hors-ligne (une connexion réseau reste toutefois nécessaire pour télécharger l’application la toute première fois). 5.5 Validation 5.5.1 Objectifs Le premier objectif de ce chapitre est de proposer un style d’architecture pour contsruire des applications Web résilientes. C’est-à-dire un style d’architecture qui encourage la séparation des différentes préoccupations impliquées dans ce type d’applications : l’interaction avec l’utilisateur, la synchronisation avec le serveur et les traitements métier. Cette séparation des préoccupation a elle-même un double objectif : permettre au développeur de se focaliser sur une seule préoccupation à la fois et rendre l’architecture plus modulaire (il doit être possible de modifier un aspectValidation 79 indépendamment des autres). 5.5.2 Expérience Hypothèses Les hypothèses que nous cherchons à valider sont les suivantes : H1 la logique métier est effectivement isolée ; H2 la préoccupation de résilience est effectivement isolée. Méthode Nous avons écrit plusieurs applications suivant le style d’architecture dé- crit précédemment, notamment une application de gestion de tâches et un éditeur de texte. Ces deux applications fonctionnent en mode complètement hors-ligne et se synchronisent avec le serveur lorsque la connexion réseau est active. L’application d’édition de texte est l’exemple type d’applications illustrant le travail collaboratif assisté par ordinateur. Au total (côtés client et serveur, sans les commentaires), le code de l’application fait 566 lignes. L’application de gestion de tâches est une implémentation du projet TodoMVC [Tod]. Ce projet vise à comparer les différents outils de construction d’applications Web interactives. Au total, le code de l’application fait 1344 lignes. Le code prenant en charge la préoccupation de résilience et la stratégie de synchronisation est partagé entre les deux applications. Il est implémenté sous forme de deux bibliothèques réutilisables (une pour le côté client et une pour le côté serveur), et s’appuie sur les WebSockets pour la communication client-serveur. Le code de la bibliothèque côté client fait 334 lignes de JavaScript, CoffeeScript et Less. Le code de la bibliothèque côté serveur fait 178 lignes de Scala. La logique métier est implémentée uniquement dans la partie ▼♦❞❡❧ : l’ajout ou la modification d’une fonctionnalité n’impacte que cette couche. Cependant, pour rendre la fonctionnalité accessible à l’utilisateur, il est nécessaire d’effectuer des modifications dans plusieurs parties du code. Il faut : — réifier la fonctionalité en une action métier (c’est-à-dire ajouter un cas particulier d’❊✈❡♥t) ; — définir l’implémentation de cette action au niveau de la couche ❈♦♥tr♦❧, laquelle s’appuie sur la couche ▼♦❞❡❧ ; — définir les éléments d’interface utilisateur permettant d’utiliser la fonctionnalité, au niveau ❱✐❡✇. 5.5.3 Discussion 5.5.3.1 Analyse des résultats Le découpage du code induit par notre style d’architecture conduit à séparer les préoccupations de la façon suivante :80 Un style d’architecture pour les applications Web résilientes Figure 5.6 – Préoccupations des applications Web resilientes et responsabilités des différents composants de notre architecture — La partie ▼♦❞❡❧ contient les données et fonctionnalités métier. Elle est complètement ignorante des préoccupations d’interaction ou de résilience, ce qui valide l’hypothèse H1 ; — La partie ❈♦♥tr♦❧ rend le ▼♦❞❡❧ interactif. Cette partie est ignorante de la pré- occupation de résilience ; — La partie ❙②♥❝ rend l’application résiliente. Elle est ignorante de la logique métier ; — La partie ❱✐❡✇ affiche de l’information à l’utilisateur. Elle est ignorante de la logique métier et de la préoccupation de résilience. Autrement dit, notre architecture permet de développer l’application sans se soucier de la préoccupation de résilience, laquelle est prise en charge par une bibliothèque réutilisable, ce qui valide l’hypothèse H2. La figure 5.6 illustre les différentes préoccupations et les responsabilités des composants. Notons que le fait que l’ajout d’une fonctionnalité ait un impact à plusieurs endroits dans le code n’est pas en contradiction avec nos objectif. Cela est simplement une conséquence normale du fait qu’une fonctionnalité a plusieurs facettes : logique métier, affichage et interaction avec l’utilisateur. 5.5.3.2 Limites de notre validation Notre architecture n’est appropriée que dans les situations où la logique d’une action peut être entièrement pourvue par le client. Or, dans certains cas (p. ex. la recherche d’information) la logique métier nécessite d’utiliser des informations qui ne sont disponibles que sur le serveur (les transférer côté client coûterait trop cher). Néanmoins, dans tous les cas où l’application sert à manipuler un document ou deDiscussion 81 l’information (p. ex. un agenda, une liste de tâche, un éditeur de texte, de présentation, etc.), notre architecture est appropriée. Comme indiqué en section 5.1, la construction de l’état de l’application en « rejouant » son histoire, c’est-à-dire en exécutant toutes les actions qui ont été enregistrées, peut être coûteuse et conduire à l’utilisation de s♥❛♣s❤♦ts pour accélérer le processus. En effet, les clients ont besoin de construire une représentation en mémoire de l’état de l’application (ou d’un partie de l’application), et avec le temps l’historique d’une application peut être particulièrement important. La solution consiste à envoyer aux clients un s♥❛♣s❤♦t représentant l’état actuel du système. Ainsi, les clients peuvent directement partir de ce snapshot plutôt que de tout recalculer. Cependant, il n’existe pas, à ce jour, de système automatisant la sérialisation d’un tel s♥❛♣s❤♦t de façon à ce que le système puisse être reconstruit côté client. Notons également que, pour construire ces s♥❛♣s❤♦ts, la totalité du modèle de données doit tenir en mémoire côté serveur. Il est cependant possible de sectoriser le modèle de données de façon à ne traiter qu’une partie des données à la fois. 5.6 Discussion Les applications Web s’appuient sur une connexion réseau pour fonctionner. Lorsque la connexion est intermittente, ou lente, comme cela peut notamment être le cas sur les appareils mobiles, la qualité de l’expérience utilisateur s’amoindrit, à moins de rendre l’application résiliente aux aléas du réseau. La préoccupation de résilience étant transversale, sa prise en charge pourrait augmenter la complexité du code des applications Web. Nous avons défini un style d’architecture isolant cette préoccupation et permettant donc de construire des applications Web collaboratives résilientes. Les applications adhérant à cette architecture peuvent être utilisées en mode hors-ligne et leur expérience utilisateur n’est pas affectée par la latence du réseau. L’architecture que nous proposons réduit la complexité de développement en défi- nissant clairement les limites des responsabilités de chaque composant. La couche mé- tier est ainsi ignorante des préoccupations d’interactivité ou de résilience. La couche gérant l’interactivité est ignorante de la préoccupation de résilience. Cette dernière est ignorante de la logique métier. Ce faible couplage entre les différents composants de notre architecture nous a permis d’implémenter la gestion de la résilience sous forme d’une bibliothèque géné- rique. En réutilisant cette bibliothèque, qui s’intègre facilement dans notre architecture, le développement d’une application Web résiliente demande peu d’efforts. Enfin, notons que notre style d’architecture conduit à partager certains concepts entre les applications client et serveur : les actions métier et, dans le cas où le serveur maintient l’état du système en mémoire, la partie ▼♦❞❡❧. Le chapitre 3 a présenté un moyen de partager du code entre clients et serveurs, pouvons-nous utiliser cet outil pour mutualiser les concepts partagés ? Dans le cas des actions métier, c’est effectivement possible, bien que le gain soit82 Un style d’architecture pour les applications Web résilientes assez faible car les actions métier ne sont définies que par des données sans opération. Le code partagé n’est alors constitué que des constructeurs de types de données. Dans le cas de la partie ▼♦❞❡❧, le modèle de données et l’implémentation des transitions de l’état du système en fonction des actions métier sont partagés. Cependant, nous avons observé que, en pratique, nos implémentations utilisent des idiomes différents côtés client et serveur. Côté serveur, l’état du système est implémenté à l’aide de types de données immuables, ce qui permet d’implémenter les transitions de façon atomique (cela est nécessaire sur le serveur qui peut être accédé par plusieurs clients de façon concurrente). Côté client, le style est impératif car cela est plus idiomatique dans le langage JavaScript et que nous n’avons pas les mêmes contraintes de concurrence que sur le serveur. Nous aurions pu, cependant, définir un langage commun pour décrire notre modèle de données et les transitions d’état, et définir comment générer le code correspondant côtés client et serveur, afin de mutualiser cet aspect de notre application. Cela aurait eu l’avantage de maintenir les applications client et serveur cohérentes entre elles, mais aurait demandé un effort d’implémentation relativement important pour un résultat non réutilisable (puisque propre au domaine d’une application donnée). Un bon compromis aurait pu être de définir un langage commun plus général de dé- finition et manipulation de types de données. Un tel langage aurait pu être réutilisé pour modéliser le domaine métier et les transitions d’état de chaque application. Nous avons exploré cette voie sans toutefois atteindre un niveau de maturité suffisant. Cependant, même en terminant ce travail le problème n’aurait été que partiellement résolu, une autre facette du problème est l’intégration du code généré dans le programme final. Le système de génération de code sur lequel nous nous sommes appuyé est conçu pour produire des programmes avec un seul point d’entrée, c’est-à-dire des fonctions. Or dans certains cas, il est plus commode d’intégrer des modules exposant plusieurs fonctions et comportant des dépendances vers d’autres composants. La différence n’est pas grande, et il est possible d’émuler les modules avec les fonctions ou de rendre le système de génération de code paramétrable. Néanmoins l’intégration, dans chaque variante de l’application, du code généré à partir du code mutualisé comporte une part de friction diminuant l’intérêt du processus de génération de code. Finalement, nous pensons que, à part pour certains aspects comme la navigation et le contenu HTML, il n’est pas certain que les avantages de la mutualisation du code contrebalancent toujours les inconvénients de l’intégration du code généré.Troisième partie Conclusion et perspectives 83Chapitre 6 Conclusion et perspectives Ce chapitre présente une synthèse des contributions de cette thèse et discute les perspectives qu’elles ouvrent. 6.1 Conclusion La distance, tant matérielle que logicielle, entre les postes ou environnements client et serveur est une source de complexité pour le développement d’applications Web. La distance matérielle crée une préoccupation technique transverse : la résilience aux aléas du réseau. D’un côté, pour simplifier le processus d’ingénierie des applications Web, on souhaite que cette préoccupation soit gérée automatiquement, sans intervention du développeur. D’un autre côté, il n’est pas souhaitable de masquer l’aspect distribué des architectures Web : le développeur doit pouvoir préciser les modalités de synchronisation ou décider au cas par cas de la stratégie à suivre lorsque la connexion réseau est rompue. La distance logicielle empêche le développeur de réutiliser du code entre les client et serveur et l’oblige à décider très tôt où exécuter le code de l’application. Ici encore, d’un côté, pour simplifier le processus d’ingénierie des applications Web, on souhaite que les développeurs puissent écrire le code de l’application et décider ❛ ♣♦st❡r✐♦r✐ d’exécuter ce code côté client ou serveur, voire partager ce code des deux côtés. D’un autre côté, il n’est pas souhaitable de masquer les spécificités des environnements client et serveur : le développeur doit pouvoir tirer parti des environnements natifs (notamment pour des raisons de performances). Les travaux de cette thèse proposent des solutions pour réduire la complexité de développement des applications Web, sans pour autant diminuer le contrôle donné aux développeurs. Concernant la distance logicielle, nous proposons un ensemble de bibliothèques Scala fournissant des abstractions dédiées à la programmation Web et produisant des programmes optimisés pour les environnements client et serveur. Cela permet aux développeurs de réutiliser du code entre les côtés client et serveur tout en tirant parti 8586 Conclusion et perspectives des spécificités de ces environnements. Notre deuxième contribution permet d’utiliser l’interface de programmation du navigateur depuis les langages de programmation statiquement typés sans diminution du pouvoir d’expression et de manière plus sûre que les autres approches. Enfin, concernant la distance matérielle, nous proposons un modèle d’architecture isolant la préoccupation de résilience. Cela permet aux développeurs d’écrire les traitements métier de leur application sans avoir à gérer les aléas du réseau, ainsi que de réutiliser des implémentations de stratégies de synchronisation. Mentionnons également que, en parallèle de ses travaux académiques, l’auteur de cette thèse a publié un livre sur l’ingénierie des applications Web avec le framework Play [RF14]. 6.2 Perspectives Nos trois contributions réduisent la complexité de développement des applications Web sans pour autant diminuer le contrôle donné aux développeurs. Nous pensons qu’il est possible, et souhaitable, de prolonger notre effort afin de réduire encore d’autres sources de complexité. La suite de cette section présente les sources de complexité que nous avons identifiées et qui pourraient faire l’objet de travaux ultérieurs. Navigations synchrone et asynchrone Nous avons mentionné le fait que les navigations synchrone et asynchrone ont toutes les deux des avantages. La navigation synchrone (le fait de recharger complètement la page en suivant un lien hypertexte) permet un meilleur référencement du contenu par les moteurs de recherche et diminue le temps d’affichage initial des pages. La navigation asynchrone (le fait de ne mettre à jour qu’une partie de la page en suivant un lien hypertexte) diminue le temps de transition d’une page à une autre. Cependant, la gestion des deux types de navigation pose plusieurs problèmes. D’une part, les deux navigations doivent être cohérentes entre elles (elles doivent gé- rer les mêmes URLs désignant les mêmes ressources). Ce problème devrait toutefois être facilement être résolu avec un outil comme LMS. D’autre part, le code côté client ou le modèle de données peuvent varier selon les pages. Par exemple, une page affichant une liste d’articles dans une boutique en ligne peut nécessiter du code pour gérer la pagination, et peut s’appuyer sur un modèle de données définissant une liste d’articles. Tandis qu’une page affichant un article seul n’a pas besoin du code gérant la pagination, et le modèle de données peut se limiter à la définition d’un seul article. Avec une navigation synchrone, chaque page contient le code nécessaire à son affichage. Mais avec une navigation asynchrone, le code et le modèle de données doivent pouvoir être mis à jour selon les besoins : le passage de l’affichage d’un article à une liste d’articles doit télécharger le morceau de code manquant et enrichir le modèle de données.Perspectives 87 Éditeurs de données Malgré les bénéfices apportés par nos travaux, le développement de certaines classes d’applications Web reste très laborieux. C’est le cas des applications de gestion de données. Développer une interface Web pour gérer la saisie et l’affichage de données nécessite beaucoup d’étapes : l’affichage d’une interface utilisateur, la sérialisation des données pour leur transfert entre clients et serveurs et le retour d’informations à l’utilisateur. Automatiser ces étapes est difficile car chacune requiert des informations qui lui sont spécifiques (bien que toutes soient dédiées au même type de données) : libellés d’affichage, règles de validation, protocole de sérialisation, etc. Toujours en respectant notre philosophie visant à automatiser sans diminuer le contrôle, il faudrait pouvoir générer un éditeur de données à partir d’un simple modèle de données, tout en conservant la possibilité d’affiner chaque aspect de l’éditeur (libellés, règles de validation, etc.) et de faire évoluer le modèle de données. Des travaux préliminaires ont déjà été réalisés dans cette direction [edi]. Générer des variantes d’applications natives pour téléphones Enfin, si le Web permet de définir du contenu visualisable sur des plateformes très variées, allant de l’ordinateur de bureau au téléphone, il comporte également quelques inconvénients. En effet, les applications Web manifestent généralement un surcoût en performances d’exécution par rapport aux applications natives. En outre, l’environnement du Web ne permet pas toujours d’accéder à toutes les fonctionnalités des terminaux clients. Pour ces raisons, ceux-là même qui naguère vantaient le Web (❡✳❣✳ Google, Facebook) s’en détournent aujourd’hui, au moins dans le cas des téléphones mobiles, et investissent leurs efforts de développement dans des applications natives. Or, le développement d’applications natives pour les téléphones mobiles conduit à une importante duplication d’efforts, car les environnements de ces terminaux peuvent être très différents (p. ex. il existe trois systèmes d’exploitation majeurs — iOS, Android et Windows Phone – qui ne gèrent pas tous les mêmes langages de programmation – Swift, Java et C#). Des outils tels que Xamarin [Xam] permettent déjà de générer des applications natives pour les différentes plateformes mobiles du marché. Cependant, ces outils s’appuient sur les mêmes solutions techniques que GWT, et souffrent donc des mêmes limitations (en particulier l’impossibilité de définir des abstractions tirant parti des spécificités de l’environnement cible sans surcoût à l’exécution). De façon analogue à notre travail permettant de mutualiser le code des applications client et serveur, nous pourrions définir un langage pour le développement d’applications sur téléphones mobiles, et générer des applications natives performantes, pour chaque plateforme.88 Conclusion et perspectivesBibliographie [App] Application cache. http://web.archive.org/web/20140816085956/ http://www.whatwg.org/specs/web-apps/current-work/multipage/ /browsers.html. Accédé le 11 septembre 2014. [Bac] Bacon.js. http://web.archive.org/web/20140802222641/http:// baconjs.github.io/. Accédé le 18 août 2014. [Bal06] Vincent Balat. Ocsigen : typing web interaction with objective caml. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✷✵✵✻ ✇♦r❦s❤♦♣ ♦♥ ▼▲, pages 84–94. ACM, 2006. [BAT14] Gavin Bierman, Martín Abadi, and Mads Torgersen. Understanding typescript. In ❊❈❖❖P ✷✵✶✹✕❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦❣r❛♠♠✐♥❣, pages 257–281. Springer, 2014. [BDM+13] Dominic Betts, Julian Dominguez, Grigori Melnik, Fernando Simonazzi, and Mani Subramanian. ❊①♣❧♦r✐♥❣ ❈◗❘❙ ❛♥❞ ❊✈❡♥t ❙♦✉r❝✐♥❣ ✿ ❆ ❏♦✉r✲ ♥❡② ✐♥t♦ ❍✐❣❤ ❙❝❛❧❛❜✐❧✐t②✱ ❆✈❛✐❧❛❜✐❧✐t②✱ ❛♥❞ ▼❛✐♥t❛✐♥❛❜✐❧✐t② ✇✐t❤ ❲✐♥❞♦✇s ❆③✉r❡. Microsoft patterns & ; practices, 1st edition, 2013. [BK08] B. Bibeault and Y. Kats. ❥◗✉❡r② ✐♥ ❆❝t✐♦♥. Dreamtech Press, 2008. [Bra13] Edwin Brady. Idris, a general-purpose dependently typed programming language : Design and implementation. ❏♦✉r♥❛❧ ♦❢ ❋✉♥❝t✐♦♥❛❧ Pr♦❣r❛♠✲ ♠✐♥❣, 23(05) :552–593, 2013. [Can08] Nicolas Cannasse. Using haxe. In ❚❤❡ ❊ss❡♥t✐❛❧ ●✉✐❞❡ t♦ ❖♣❡♥ ❙♦✉r❝❡ ❋❧❛s❤ ❉❡✈❡❧♦♣♠❡♥t, pages 227–244. Springer, 2008. [CGLO06] Vincent Cremet, François Garillot, Sergueï Lenglet, and Martin Odersky. A core calculus for scala type checking. In ▼❛t❤❡♠❛t✐❝❛❧ ❋♦✉♥❞❛t✐♦♥s ♦❢ ❈♦♠♣✉t❡r ❙❝✐❡♥❝❡ ✷✵✵✻, pages 1–23. Springer, 2006. [CHJ12] Ravi Chugh, David Herman, and Ranjit Jhala. Dependent types for javascript. ❙■●P▲❆◆ ◆♦t✳, 47(10) :587–606, October 2012. [CLWY07] Ezra Cooper, Sam Lindley, Philip Wadler, and Jeremy Yallop. Links : Web programming without tiers. In ❋♦r♠❛❧ ▼❡t❤♦❞s ❢♦r ❈♦♠♣♦♥❡♥ts ❛♥❞ ❖❜✲ ❥❡❝ts, pages 266–296. Springer, 2007. [Cou87] Joëlle Coutaz. Pac : An object oriented model for implementing user interfaces. ❆❈▼ ❙■●❈❍■ ❇✉❧❧❡t✐♥, 19(2) :37–41, 1987. 8990 Bibliographie [CSS] Css. http://web.archive.org/web/20140823082659/http://www.w3. org/Style/CSS/. Accédé le 27 août 2014. [CW10] Brett Cannon and Eric Wohlstadter. Automated Object Persistence for JavaScript. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✾t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲♦r❧❞ ❲✐❞❡ ❲❡❜, WWW ’10, pages 191–200, New York, NY, USA, 2010. ACM. [Cza12] Evan Czaplicki. Elm : Concurrent frp for functional guis, 2012. [Doe13] Sébastien Doeraene. Scala. js : Type-directed interoperability with dynamically typed languages. Technical report, 2013. [edi] editors. https://github.com/julienrf/editors. Accédé le 30 septembre 2014. [EFDM00] Conal Elliott, Sigbjørn Finne, and Oege De Moor. Compiling embedded languages. In ❙❡♠❛♥t✐❝s✱ ❆♣♣❧✐❝❛t✐♦♥s✱ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥ ♦❢ Pr♦❣r❛♠ ●❡♥❡r❛t✐♦♥, pages 9–26. Springer, 2000. [EG89] C. A. Ellis and S. J. Gibbs. Concurrency Control in Groupware Systems. ❙■●▼❖❉ ❘❡❝✳, 18(2) :399–407, June 1989. [EMSS] Erik Ernst, Anders Møller, Mathias Schwarz, and Fabio Strocco. Managing gradual typing with message-safety in dart. [Fen12] Steve Fenton. Typescript for javascript programmers. 2012. [FF05] Michael Furr and Jeffrey S. Foster. Checking type safety of foreign function calls. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✷✵✵✺ ❆❈▼ ❙■●P▲❆◆ ❈♦♥❢❡r❡♥❝❡ ♦♥ Pr♦✲ ❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡ ❉❡s✐❣♥ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥, PLDI ’05, pages 62–72, New York, NY, USA, 2005. ACM. [Fow05] Martin Fowler. Event sourcing. ❖♥❧✐♥❡✱ ❉❡❝, 2005. [FT02] Roy T. Fielding and Richard N. Taylor. Principled design of the modern Web architecture. ❆❈▼ ❚r❛♥s✳ ■♥t❡r♥❡t ❚❡❝❤♥♦❧✳, 2 :115–150, May 2002. [GF99] Rachid Guerraoui and Mohamed E Fayad. Oo distributed programming is not distributed oo programming. ❈♦♠♠✉♥✐❝❛t✐♦♥s ♦❢ t❤❡ ❆❈▼, 42(4) :101–104, 1999. [Gho10] Debasish Ghosh. ❉❙▲s ✐♥ ❆❝t✐♦♥. Manning Publications Co., Greenwich, CT, USA, 1st edition, 2010. [Hoa09] T. Hoare. Null references : The billion dollar mistake. Pr❡s❡♥t❛t✐♦♥ ❛t ◗❈♦♥ ▲♦♥❞♦♥, 2009. [HTM] Html. http://web.archive.org/web/20140702124213/http://www. w3.org/TR/domcore/. Accédé le 31 juillet 2014. [Hud96] Paul Hudak. Building domain-specific embedded languages. ❆❈▼ ❈♦♠✲ ♣✉t✳ ❙✉r✈✳, 28(4es), December 1996. [Ind] Indexed database api. http://web.archive.org/web/20140906110326/ http://www.w3.org/TR/IndexedDB/. Accédé le 11 septembre 2014.Bibliographie 91 [Jav] Lambda expressions. http://web.archive.org/web/20140625121030/ http://docs.oracle.com/javase/tutorial/java/javaOO/ lambdaexpressions.html. Accédé le 4 septembre 2014. [JCB+13] Jean-Marc Jézéquel, Benoit Combemale, Olivier Barais, Martin Monperrus, and François Fouquet. Mashup of metalanguages and its implementation in the kermeta language workbench. ❙♦❢t✇❛r❡ ✫ ❙②st❡♠s ▼♦❞❡❧✐♥❣, pages 1–16, 2013. [JGS93] Neil D Jones, Carsten K Gomard, and Peter Sestoft. P❛rt✐❛❧ ❡✈❛❧✉❛t✐♦♥ ❛♥❞ ❛✉t♦♠❛t✐❝ ♣r♦❣r❛♠ ❣❡♥❡r❛t✐♦♥. Peter Sestoft, 1993. [jQu] Utilisation de jquery. http://web.archive.org/web/20140704091353/ https://trends.builtwith.com/javascript. Accédé le 2 septembre 2014. [JS86] Ulrik Jørring and William L. Scherlis. Compilers and staging transformations. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✸t❤ ❆❈▼ ❙■●❆❈❚✲❙■●P▲❆◆ ❙②♠♣♦s✐✉♠ ♦♥ Pr✐♥❝✐♣❧❡s ♦❢ Pr♦❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡s, POPL ’86, pages 86–96, New York, NY, USA, 1986. ACM. [JW07] Bruce Johnson and Joel Webber. ●♦♦❣❧❡ ✇❡❜ t♦♦❧❦✐t. Addison-Wesley, 2007. [K+96] Samuel Kamin et al. Standard ml as a meta-programming language. Technical report, 1996. [KARO12] Grzegorz Kossakowski, Nada Amin, Tiark Rompf, and Martin Odersky. Javascript as an embedded dsl. In ❊❈❖❖P ✷✵✶✷✕❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦✲ ❣r❛♠♠✐♥❣, pages 409–434. Springer, 2012. [KHR+12] Sebastian Kleinschmager, Stefan Hanenberg, Romain Robbes, É Tanter, and Andreas Stefik. Do static type systems improve the maintainability of software systems ? an empirical study. In Pr♦❣r❛♠ ❈♦♠♣r❡❤❡♥s✐♦♥ ✭■❈P❈✮✱ ✷✵✶✷ ■❊❊❊ ✷✵t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 153–162. IEEE, 2012. [KLYY12] Yung-Wei Kao, ChiaFeng Lin, Kuei-An Yang, and Shyan-Ming Yuan. A Web-based, Offline-able, and Personalized Runtime Environment for executing applications on mobile devices. ❈♦♠♣✉t❡r ❙t❛♥❞❛r❞s ✫ ■♥t❡r❢❛❝❡s, 34(1) :212–224, 2012. [Kot] Kotlin. http://web.archive.org/web/20140712061248/http: //kotlin.jetbrains.org/. Accédé le 18 juillet 2014. [KP88] G Krasner and S Pope. A cookbook for using the model-view controller user interface paradigm in smalltalk-80 j. object oriented program., 1, 26- 49, 1988. [Lan66] Peter J Landin. The next 700 programming languages. ❈♦♠♠✉♥✐❝❛t✐♦♥s ♦❢ t❤❡ ❆❈▼, 9(3) :157–166, 1966. [LB11] Jesse Liberty and Paul Betts. Reactive extensions for javascript. In Pr♦✲ ❣r❛♠♠✐♥❣ ❘❡❛❝t✐✈❡ ❊①t❡♥s✐♦♥s ❛♥❞ ▲■◆◗, pages 111–124. Springer, 2011.92 Bibliographie [LM99] Daan Leijen and Erik Meijer. Domain specific embedded compilers. In ❆❈▼ ❙✐❣♣❧❛♥ ◆♦t✐❝❡s, volume 35, pages 109–122. ACM, 1999. [LV92] Ernst Lippe and Norbert Van Oosterom. Operation-based merging. In ❆❈▼ ❙■●❙❖❋❚ ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣ ◆♦t❡s, volume 17, pages 78–87. ACM, 1992. [Mar09] Nora Koch Marianne Busch. Rich Internet Applications. State-of-the-Art. Technical Report 0902, Ludwig-Maximilians-Universität München, 2009. [MGPW13] Félix Albertos Marco, José A. Gallud, Victor M. Ruiz Penichet, and Marco Winckler. A model-based approach for supporting offline interaction with web sites resilient to interruptions. In ■❈❲❊ ❲♦r❦s❤♦♣s, pages 156– 171, 2013. [MHR+ ] Clemens Mayer, Stefan Hanenberg, Romain Robbes, Éric Tanter, and Andreas Stefik. Static type systems (sometimes) have a positive impact on the usability of undocumented software : An empirical evaluation. s❡❧❢, 18 :5. [NCDL95] David A. Nichols, Pavel Curtis, Michael Dixon, and John Lamping. Highlatency, Low-bandwidth Windowing in the Jupiter Collaboration System. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✽t❤ ❆♥♥✉❛❧ ❆❈▼ ❙②♠♣♦s✐✉♠ ♦♥ ❯s❡r ■♥t❡r❢❛❝❡ ❛♥❞ ❙♦❢t✇❛r❡ ❚❡❝❤♥♦❧♦❣②, UIST ’95, pages 111–120, New York, NY, USA, 1995. ACM. [NS09] M.G. Nanda and S. Sinha. Accurate interprocedural null-dereference analysis for java. In ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣✱ ✷✵✵✾✳ ■❈❙❊ ✷✵✵✾✳ ■❊❊❊ ✸✶st ■♥✲ t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 133–143. IEEE, 2009. [OCRZ03] Martin Odersky, Vincent Cremet, Christine Röckl, and Matthias Zenger. A nominal theory of objects with dependent types. In ❊❈❖❖P ✷✵✵✸✕ ❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦❣r❛♠♠✐♥❣, pages 201–224. Springer, 2003. [OZ05] Martin Odersky and Matthias Zenger. Scalable component abstractions. ❆❈▼ ❙✐❣♣❧❛♥ ◆♦t✐❝❡s, 40(10) :41–57, 2005. [Pur] Purescript. http://web.archive.org/web/20140731132649/http:// www.purescript.org/. Accédé le 31 juillet 2014. [RE09] Roberto Rodríguez-Echeverría. RIA : more than a Nice Face. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ❉♦❝t♦❧r❛❧ ❈♦♥s♦rt✐✉♠ ♦❢ t❤❡ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲❡❜ ❊♥❣✐♥❡❡r✐♥❣, volume 484. CEUR-WS.org, 2009. [RF14] Julien Richard-Foy. P❧❛② ❋r❛♠❡✇♦r❦ ❊ss❡♥t✐❛❧s. Packt Publishing Limited, Birmingham, UK, 1st edition, 2014. [RFBJ13a] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Efficient highlevel abstractions for web programming. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✷t❤ ✐♥t❡r✲ ♥❛t✐♦♥❛❧ ❝♦♥❢❡r❡♥❝❡ ♦♥ ●❡♥❡r❛t✐✈❡ ♣r♦❣r❛♠♠✐♥❣ ✿ ❝♦♥❝❡♣ts ✫ ❡①♣❡r✐❡♥❝❡s, pages 53–60. ACM, 2013. [RFBJ13b] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Efficient highlevel abstractions for web programming. In Jaakko Jarvi and ChristianBibliographie 93 Kastner, editors, ●❡♥❡r❛t✐✈❡ Pr♦❣r❛♠♠✐♥❣ ✿ ❈♦♥❝❡♣ts ❛♥❞ ❊①♣❡r✐❡♥❝❡s✱ ●P❈❊✬✶✸, pages 53–60, Indianapolis, États-Unis, 2013. ACM. [RFBJ14] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Using PathDependent Types to Build Type Safe JavaScript Foreign Function Interfaces. In ■❈❲❊ ✲ ✶✹t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲❡❜ ❊♥❣✐♥❡❡r✐♥❣, Toulouse, France, July 2014. [Rif08] Jeremy Rifkin. The third industrial revolution. ❊♥❣✐♥❡❡r✐♥❣ ✫ ❚❡❝❤♥♦❧♦❣②, 3(7) :26–27, 2008. [Rom12] Tiark Rompf. ▲✐❣❤t✇❡✐❣❤t ▼♦❞✉❧❛r ❙t❛❣✐♥❣ ❛♥❞ ❊♠❜❡❞❞❡❞ ❈♦♠♣✐❧❡rs ✿ ❆❜str❛❝t✐♦♥ ✇✐t❤♦✉t ❘❡❣r❡t ❢♦r ❍✐❣❤✲▲❡✈❡❧ ❍✐❣❤✲P❡r❢♦r♠❛♥❝❡ Pr♦❣r❛♠♠✐♥❣. PhD thesis, 2012. [RSB+14] Tiark Rompf, Arvind K Sujeeth, Kevin J Brown, HyoukJoong Lee, Hassan Chafi, and Kunle Olukotun. Surgical precision jit compilers. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ✸✺t❤ ❆❈▼ ❙■●P▲❆◆ ❈♦♥❢❡r❡♥❝❡ ♦♥ Pr♦❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡ ❉❡s✐❣♥ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥, page 8. ACM, 2014. [RT10] David Rajchenbach-Teller. Opa : Language support for a sane, safe and secure web. Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❖❲❆❙P ❆♣♣❙❡❝ ❘❡s❡❛r❝❤ ✷✵✶✵, 2010. [SE98] Chengzheng Sun and Clarence Ellis. Operational Transformation in Realtime Group Editors : Issues, Algorithms, and Achievements. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ✶✾✾✽ ❆❈▼ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❈♦♠♣✉t❡r ❙✉♣♣♦rt❡❞ ❈♦♦♣❡r❛t✐✈❡ ❲♦r❦, CSCW ’98, pages 59–68, New York, NY, USA, 1998. ACM. [SGL06] Manuel Serrano, Erick Gallesio, and Florian Loitsch. Hop : a language for programming the web 2. 0. In ❖❖P❙▲❆ ❈♦♠♣❛♥✐♦♥, pages 975–985, 2006. [Sha] Sharpkit. http://web.archive.org/web/20140716013416/http:// sharpkit.net/. Accédé le 18 juillet 2014. [SLLG11] Bin Shao, Du Li, Tun Lu, and Ning Gu. An operational transformation based synchronization protocol for web 2.0 applications. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❆❈▼ ✷✵✶✶ ❝♦♥❢❡r❡♥❝❡ ♦♥ ❈♦♠♣✉t❡r s✉♣♣♦rt❡❞ ❝♦♦♣❡r❛t✐✈❡ ✇♦r❦, pages 563–572. ACM, 2011. [SPBZ11] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. In ❙t❛❜✐❧✐③❛t✐♦♥✱ ❙❛❢❡t②✱ ❛♥❞ ❙❡❝✉r✐t② ♦❢ ❉✐str✐❜✉t❡❞ ❙②st❡♠s, pages 386–400. Springer, 2011. [Tod] Todomvc. http://web.archive.org/web/20140903120512/http:// todomvc.com/. Accédé le 11 septembre 2014. [Vis08] Eelco Visser. Webdsl : A case study in domain-specific language engineering. In ●❡♥❡r❛t✐✈❡ ❛♥❞ ❚r❛♥s❢♦r♠❛t✐♦♥❛❧ ❚❡❝❤♥✐q✉❡s ✐♥ ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡✲ r✐♥❣ ■■, pages 291–373. Springer, 2008. [VP12] Markus Voelter and Vaclav Pech. Language modularity with the mps language workbench. In ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣ ✭■❈❙❊✮✱ ✷✵✶✷ ✸✹t❤ ■♥t❡r♥❛t✐♦✲ ♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 1449–1450. IEEE, 2012.94 Bibliographie [VV10] Markus Völter and Eelco Visser. Language extension and composition with language workbenches. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❆❈▼ ✐♥t❡r♥❛t✐♦♥❛❧ ❝♦♥❢❡r❡♥❝❡ ❝♦♠♣❛♥✐♦♥ ♦♥ ❖❜❥❡❝t ♦r✐❡♥t❡❞ ♣r♦❣r❛♠♠✐♥❣ s②st❡♠s ❧❛♥❣✉❛❣❡s ❛♥❞ ❛♣♣❧✐❝❛t✐♦♥s ❝♦♠♣❛♥✐♦♥, pages 301–304. ACM, 2010. [WL12] Kathy Walrath and Seth Ladd. ❲❤❛t ✐s ❉❛rt ❄ " O’Reilly Media, Inc.", 2012. [Xam] Xamarin. http://web.archive.org/web/20140912234132/http:// xamarin.com/. Accédé le 30 septembre 2014. [Yan00] Yun Yang. Supporting online Web-based teamwork in offline mobile mode too. In ❲❡❜ ■♥❢♦r♠❛t✐♦♥ ❙②st❡♠s ❊♥❣✐♥❡❡r✐♥❣✱ ✷✵✵✵✳ Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❋✐rst ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, volume 1, pages 486–490. IEEE, 2000.Table des figures 1.1 Un formulaire tel qu’il est perçu par l’utilisateur (en haut), est repré- senté par un arbre d’éléments HTML côté client, et par un texte côté serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Les modèles MVC (à gauche) et PAC (à droite) . . . . . . . . . . . . . . . 20 2.2 Le modèle PAC-C3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 Trois variantes d’architectures dérivées du modèle ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r. a) MVC côté serveur ; b) MVC côté client ; et c) MVC hybride côtés client et serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Exécution du programme indiqué dans le listing 2.1. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation abstraite d’un fragment HTML. Celle-ci est ensuite convertie vers une représentation spécifique à chaque plateforme. . . . . . . . . . . . . . . . . . . . . . . . 28 2.5 Langages lourds. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation efficace du fragment HTML, en tirant parti des spé- cificités de chaque plateforme. . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Ingénierie dirigée par les modèles. Chaque aspect du programme est décrit dans un langage dédié. La combinaison de ces aspects constitue le programme global, qui est transformé en une application côté client et une application côté serveur. . . . . . . . . . . . . . . . . . . . . . . . 31 2.7 Langages dédiés compilés et implémentés par des bibliothèques. Un langage dédié est fourni par une bibliothèque dont l’implémentation produit une représentation abstraite du programme à générer. Un gé- nérateur de code peut dériver, à partir de cette représentation abstraite, les programmes correspondant, côtés client et serveur. . . . . . . . . . . 34 2.8 Différence entre les langages dédiés implémentés par des bibliothèques, interprétés (à gauche) ou compilés (à droite). . . . . . . . . . . . . . . . 35 2.9 Diagramme d’objets correspondant au terme trois. . . . . . . . . . . . . 37 3.1 L’API standard des sélecteurs. . . . . . . . . . . . . . . . . . . . . . . . . 43 9596 Table des figures 3.2 Représentations abstraites de code retournées par l’évaluation des expressions (a) document.find("#add-user button") et (b) document.find("#add-user") 46 3.3 Tests de performance sur un programme utilisant l’API des sélecteurs . 54 3.4 Tests de performance sur un programme manipulant des valeurs optionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5 Tests de performance sur une application réelle . . . . . . . . . . . . . . 57 5.1 Vue d’ensemble de notre style d’architecture pour applications Web ré- silientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Diagramme des classes impliquées dans la synchronisation . . . . . . . 75 5.3 Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario mono-utilisateur . . . . . . . . . . . . . . . . 76 5.4 Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario multi-utilisateur . . . . . . . . . . . . . . . . 77 5.5 Généralisation de la synchronisation . . . . . . . . . . . . . . . . . . . . 78 5.6 Préoccupations des applications Web resilientes et responsabilités des différents composants de notre architecture . . . . . . . . . . . . . . . . 80Résumé L’automatisation de certaines tâches et traitements d’information grâce aux outils numériques permet de réaliser des économies considérables sur nos activités. Le Web est une plateforme propice à la mise en place de tels outils : ceux-ci sont hébergés par des serveurs, qui centralisent les informations et coordonnent les utilisateurs, et ces derniers accèdent aux outils depuis leurs terminaux clients (ordinateur, téléphone, tablette, etc.) en utilisant un navigateur Web, sans étape d’installation. La réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la ❞✐st❛♥❝❡ entre les postes client et serveur. D’une part, la distance physique (ou distance ♠❛tér✐❡❧❧❡) entre les machines né- cessite qu’une connexion réseau soit toujours établie entre elles pour que l’application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les problèmes de latence lors des échanges d’information ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le serveur ? Comment éviter aux développeurs d’avoir à résoudre ces problèmes sans pour autant masquer la nature distribuée des applications Web et au risque de perdre les avantages de ces architectures ? D’autre part, l’environnement d’exécution est différent entre les clients et serveurs, produisant une distance ❧♦❣✐❝✐❡❧❧❡. En effet, côté client, le programme s’exécute dans un navigateur Web dont l’interface de programmation (API) permet de réagir aux actions de l’utilisateur et de mettre à jour le document affiché. De l’autre côté, c’est un serveur Web qui traite les requêtes des clients selon le protocole HTTP. Certains aspects d’une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation de données saisies dans les formulaires, la navigation ou même certains calculs métier. Cependant, comme les API des environnements client et serveur sont différentes, comment mutualiser ces aspects tout en bénéficiant des mêmes performances d’exécution qu’en utilisant les API natives ? De même, comment conserver la possibilité de tirer parti des spécificités de chaque environnement ? Les travaux de cette thèse ont pour but de raccourcir cette distance, tant logicielle que matérielle, tout en préservant la capacité à tirer parti de cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs. La première contribution concerne la distance matérielle. Nous proposons un modèle d’architecture pour les applications interactives et collaboratives fonctionnant en mode connecté et déconnecté. Notre modèle isole la préoccupation de synchronisation client-serveur, offrant ainsi un modèle de développement plus simple pour les développeurs. La seconde contribution concerne la distance logicielle. Nous nous appuyons sur un mécanisme d’évaluation retardée, permettant à un même programme d’être exé- cuté côté client ou serveur, pour bâtir des abstractions, offrant un modèle de programmation homogène et haut-niveau, produisant du code tirant parti des spécificités des environnements client et serveur. Nous avons observé que la taille du codeécrit avec nos outils est du même ordre de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et 35% à 50% plus petite que celle d’un code bas-niveau, mais les performances d’exécution sont du même ordre de grandeur que celles d’un code bas-niveau et 39% à 972% meilleurs qu’un code haut-niveau. Une troisième contribution s’adresse aux adeptes du typage statique. En effet l’API du navigateur est conçue pour un langage dynamiquement typé, JavaScript, et certaines de ses fonctions peuvent être difficiles à exposer dans un langage statiquement typé. En effet, les solutions actuelles perdent en général de l’information, contraignant les développeurs à effectuer des conversions de type contournant le système de typage, ou proposent des fonctions avec un pouvoir d’expression réduit. Nous proposons deux façons d’exposer ces fonctions dans des langages statiquement typés, en nous appuyant respectivement sur les types paramétrés ou les types dépendants. Notre approche, tout en étant bien typée, permet de réduire le nombre de fonctions exposées aux développeurs tout en conservant le même pouvoir d’expression que l’API native. Abstract Thanks to information technologies, some tasks or information process can be automated, thus saving a significant amount of money. The web platform brings numerous of such digital tools. These are hosted on web servers that centralize information and coordinate users, which can use the tools from several kinds of devices (desktop computer, laptop, smartphone, etc.), by using a web browser, without installing anything. Nevertheless, developing such web applications is challenging. The difficulty mainly comes from the ❞✐st❛♥❝❡ between client and server devices. First, the physical distance between these machines requires them to be networked. This raises several issues. How to manage latency ? How to provide a good quality of service even when the network is down ? How to choose on which side (client or server) to execute a computation ? How to free developers from addressing these problems without yet hiding the distributed nature of web application so that they can still benefit from their advantages ? Second, the execution environment is different between clients and servers. Indeed, on client-side the program is executed within a web browser whose API provides means of reacting to user actions and of updating the page. On server-side, the program is executed on a web server that processes HTTP requests. Some aspects of web applications can be shared between client and server sides (❡✳❣✳ content display, form validation, navigation, or even some business computations). However, the APIs and environments are different between clients and servers, so how to share the same code while keeping the same execution performance as with native APIs ? How to keep the opportunity to leverage the specificities of a given platform ? This work aims at shortening this distance while keeping the opportunity to leverage it, that is while giving developers as much expressive power. Our first contribution consists of an architecture pattern to build interactive andcollaborative web applications handling on-line and off-line modes. Our pattern captures the client-server synchronization concern, thus giving developers a simpler programming model. Our second contribution shows how to use a delayed evaluation mechanism to build high-level abstractions that can be shared between client and server sides and that generate efficient code leveraging the specificities of each platform. We observed that the size of the code written using our abstractions is similar to code that uses high-level libraries, and 35% to 50% smaller than low-level code, while execution performance are similar to low-level code and 39% to 972% faster than high-level code. Our third contribution makes it easier to use the web browser’s API from a statically typed language. Indeed, this API is designed to be used with the dynamically typed language JavaScript, and some functions are hard to encode in a static type system. Current solutions either loose type information, requiring users to perform unsafe typecasts or reduce the expressive power. We show two ways to encode challenging web browser’s functions in a static type system by leveraging parameterized types and dependent types. Our approach is typesafe and keeps the same expressive power as the native API. Analyse de vuln´erabilit´es de syst`emes avioniques embarqu´es : classification et exp´erimentation Anthony Dessiatnikoff To cite this version: Anthony Dessiatnikoff. Analyse de vuln´erabilit´es de syst`emes avioniques embarqu´es : classi- fication et exp´erimentation. Embedded Systems. Institut d’Optique Graduate School, 2014. French. . HAL Id: tel-01077930 https://tel.archives-ouvertes.fr/tel-01077930 Submitted on 27 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE Délivré par : l’Institut National des Sciences Appliquées de Toulouse (INSA de Toulouse) Présentée et soutenue le 17/07/2014 par : Anthony DESSIATNIKOFF Analyse de vulnérabilités de systèmes avioniques embarqués : classification et expérimentation JURY Jean-Louis LANET Université de Limoges Rapporteur Olivier FESTOR Télécom Nancy Rapporteur Bertrand LECONTE Ingénieur Airbus Examinateur Colas LE GUERNIC Ingénieur DGA Examinateur Vincent NICOMETTE INSA de Toulouse Examinateur Eric ALATA INSA de Toulouse Directeur de thèse École doctorale et spécialité : MITT : Domaine STIC : Réseaux, Télécoms, Systèmes et Architecture Unité de Recherche : Laboratoire d’Analyse et d’Architecture des Systèmes (UPR 8001) Directeur de Thèse : Eric ALATA Rapporteurs : Jean-Louis LANET et Olivier FESTORiiRemerciements Les travaux présentés dans ce mémoire ont été effectués au Laboratoire d’Analyse et d’Architecture des Systèmes (LAAS) du Centre National de la Recherche Scientifique (CNRS). Je remercie Raja Chatila, Jean-Louis Sanchez et Jean Arlat qui ont assuré la direction du LAAS depuis mon entrée. Je remercie également Karama Kanoun et Mohamed Kaâniche, responsables successifs de l’équipe de recherche Tolérance aux fautes et Sûreté de Fonctionnement informatique (TSF), pour m’avoir permis de réaliser mes travaux au sein du groupe. Je remercie la Direction Générale de l’Armement (DGA) et le CNRS pour m’avoir financé pendant 3 années puis l’Agence Nationale de la Recherche avec le projet SOBAS pendant les derniers mois. Je tiens à exprimer ma profonde reconnaissance et un grand respect à Yves Deswarte, Directeur de Recherche au CNRS, pour m’avoir accueilli en stage au LAAS en 2009 et m’avoir fait confiance pour la réalisation de ces travaux de thèse en 2010 et pour avoir été mon directeur de thèse pendant 3 années. Sa disparition le 27 janvier 2014 a été une profonde douleur. J’exprime ma gratitude et remercie Éric Alata et Vincent Nicomette pour m’avoir encadré avec Yves Deswarte pendant ma thèse. Ils étaient toujours disponibles pour discuter et corriger mes erreurs, malgré leurs emplois du temps très chargés. J’adresse également mes sincères remerciements aux membres du jury qui ont accepté de juger mon travail. Je leur suis très reconnaissant pour l’intérêt qu’ils ont porté à mes travaux : – Jean-Louis Lanet, Professeur des Universités, laboratoire XLIM de Limoges – Olivier Festor, Professeur des Universités, Télécom Nancy – Vincent Nicomette, Professeur des Universités, INSA de Toulouse – Bertrand Leconte, Ingénieur de recherche, Airbus, Toulouse – Colas Le Guernic, Ingénieur de recherche, DGA, Rennes Je remercie particulièrement Messieurs Jean-Louis Lanet et Olivier Festor qui ont accepté la charge d’être rapporteurs. Je remercie les nombreuses personnes ayant participé, depuis le début ou en partie, au projet SOBAS de l’ANR : Bertrand Leconte (Airbus), Benoît Triquet (Airbus), Alain Combes (Airbus), Cristina Simache (Altran), Julien Iguchi-Cartigny (XLIM), Jean-Paul Blanquart (ASTRIUM), Stéphane Duverger (EADS), les membres de l’ANSSI ainsi que les autres personnes que j’ai pû oublier. iiiUne mention particulière est donnée à Benoît Triquet (Airbus) et Fabrice Thorignac (Atos Origin) pour m’avoir accueilli dans les locaux d’Airbus plusieurs jours pendant ces 3 années et qui m’ont énormément aidé pour la compréhension du code noyau, des applications avioniques et du P4080. Je remercie également Stéphane Duverger pour son enthousiasme permanent et sa grande expertise sur les systèmes d’exploitation. De plus, je remercie Cristina Simache ainsi que les autres personnes qui ont relu et corrigé le manuscrit. Je remercie également tous les doctorants, docteurs, post-doctorants et stagiaires de l’équipe TSF que j’ai pû rencontrer, je ne peux pas tous les citer mais je vais essayer : Miruna, Carla, Fernand, Miguel, Camille, Jesus, Pierre, Thibaut, Amira, Quynh Anh, Moussa, Hélène, Ludovic, Olivier, Benoît, Ivan, Yann, Joris, Roberto, Mathilde, Kalou, Julien, Guthemberg, Fanny, Robert, Hongli, Roxana, Irina, Kossi, Jimmy, Amina, Rim, Damien, Éric, Géraldine, etc. dont je me suis lié d’amitié avec une grande partie. Je remercie tous les permanents TSF car ils contribuent pour beaucoup à la bonne entente générale dans l’équipe TSF. J’ai eu la chance de rencontrer au LAAS beaucoup de monde très intéressant, j’ai une pensée pour Jean-Claude Laprie (qui était un grand monsieur, dans tous les sens du terme). De plus, je remercie Sonia De Sousa pour sa gestion parfaite du secrétariat du thème Informatique Critique du laboratoire, elle a toujours été disponible et très efficace pour m’aider dans les différentes tâches administratives. Je pense également à mes autres amis que je vois trop peu à cause de la distance et qui m’ont soutenu : Richard, Antoine et Mellie, Damien et Caroline, Steven et Lucie, et les autres. Je tiens à remercier particulièrement ma famille qui m’a toujours soutenu depuis le début, même s’ils n’ont pas toujours compris ce que je faisais exactement, ils ont le mérite de m’avoir encouragé dans les moments difficiles. iv« La vraie faute est celle qu’on ne corrige pas. » Confucius (551 – 479 avant J.C.) vviSommaire Table des figures xi Introduction générale 1 Chapitre 1 État de l’art de la sécurité des systèmes avioniques 5 1.1 Systèmes avioniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1 Architecture fédérée . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.2 Architecture IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Sûreté de fonctionnement et le développement logiciel . . . . . . . . . . . 12 1.2.1 Quelques définitions de la sûreté de fonctionnement . . . . . . . . 12 1.2.2 Tolérance aux fautes dans le domaine avionique . . . . . . . . . . . 15 1.2.3 Développement de logiciels critiques sûrs . . . . . . . . . . . . . . . 16 1.2.4 Sécurité-immunité dans les standards avioniques . . . . . . . . . . 20 1.3 Problématique de la sécurité-immunité dans les systèmes avioniques . . . 23 1.3.1 Connectivité accrue entre les applications . . . . . . . . . . . . . . 24 1.3.2 Partage de ressource entre applications . . . . . . . . . . . . . . . . 25 1.3.3 Utilisation de composants COTS . . . . . . . . . . . . . . . . . . . 26 1.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.4 Différentes approches pour améliorer la sécurité-immunité . . . . . . . . . 26 1.4.1 Intégration de mécanismes de sécurité adaptés . . . . . . . . . . . 27 1.4.2 Utilisation de méthodes formelles . . . . . . . . . . . . . . . . . . . 27 1.4.3 Analyse de vulnérabilités dans le processus de développement . . . 29 1.5 Analyse de vulnérabilités dans les systèmes critiques embarqués . . . . . . 29 1.5.1 Approche par boîte blanche . . . . . . . . . . . . . . . . . . . . . . 30 1.5.2 Approche par boîte noire . . . . . . . . . . . . . . . . . . . . . . . 31 1.6 Contribution de cette thèse . . . . . . . . . . . . . . . . . . . . . . . . . . 32 viiChapitre 2 Caractérisation des attaques des systèmes embarqués 35 2.1 Attaques visant les fonctionnalités de base . . . . . . . . . . . . . . . . . . 36 2.1.1 Attaques ciblant le processeur . . . . . . . . . . . . . . . . . . . . . 36 2.1.2 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . 38 2.1.3 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 41 2.1.4 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 43 2.1.5 Attaques ciblant la gestion des processus . . . . . . . . . . . . . . 44 2.1.6 Attaques ciblant l’ordonnancement . . . . . . . . . . . . . . . . . . 45 2.1.7 Attaques ciblant les mécanismes cryptographiques . . . . . . . . . 45 2.1.8 Attaques ciblant les fonctions ancillaires . . . . . . . . . . . . . . . 46 2.1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.2 Les attaques ciblant les mécanismes de tolérance aux fautes . . . . . . . . 46 2.2.1 Détection d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.2.2 Recouvrement d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . 50 2.2.3 Traitement de fautes . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.3 Contexte et hypothèses d’attaques . . . . . . . . . . . . . . . . . . . . . . 52 2.3.1 Attaquants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.2 Hypothèse d’attaque : une application non critique malveillante . . 54 Chapitre 3 Mise en œuvre de la méthodologie 57 3.1 Système expérimental d’Airbus : noyau et partitions . . . . . . . . . . . . 57 3.1.1 Hypothèses concernant la partition malveillante . . . . . . . . . . . 59 3.1.2 Phases d’exécution d’une partition . . . . . . . . . . . . . . . . . . 60 3.2 Architecture du P4080 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.2.1 Structure des cœurs e500mc . . . . . . . . . . . . . . . . . . . . . . 63 3.2.2 Contrôleur d’interruption . . . . . . . . . . . . . . . . . . . . . . . 63 3.2.3 DataPath Acceleration Architecture (DPAA) . . . . . . . . . . . . . 64 3.2.4 Démarrage sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3 Présentation de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3.1 Observation du noyau et des applications . . . . . . . . . . . . . . 66 3.3.2 Configuration de la plateforme d’expérimentation . . . . . . . . . . 67 3.4 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . . . . . 70 3.4.1 Attaques ciblant le Security Engine . . . . . . . . . . . . . . . . . . 70 3.4.2 Attaques ciblant le Run Control/Power Management . . . . . . . . 72 viii3.5 Attaques ciblant les communications . . . . . . . . . . . . . . . . . . . . . 72 3.5.1 Attaques ciblant les communications AFDX . . . . . . . . . . . . . 72 3.5.2 Attaques ciblant les IPC . . . . . . . . . . . . . . . . . . . . . . . . 75 3.6 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . . . . . 78 3.6.1 Première attaque : utilisation des interruptions . . . . . . . . . . . 78 3.6.2 Seconde attaque : modification de la configuration d’une partition 81 3.6.3 Utilisation conjointe des deux attaques . . . . . . . . . . . . . . . . 82 3.7 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . . . . . 82 3.7.1 Réalisation du programme Crashme . . . . . . . . . . . . . . . . . 82 3.7.2 Instrumentation du noyau . . . . . . . . . . . . . . . . . . . . . . . 83 3.7.3 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Chapitre 4 Protections des systèmes avioniques contre les malveillances 87 4.1 Contre-mesures spécifiques à notre plateforme d’expérimentation . . . . . 88 4.1.1 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . 88 4.1.2 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 89 4.1.3 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 91 4.1.4 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . 92 4.2 Contre-mesures génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.2.1 Attaques ciblant le processeur . . . . . . . . . . . . . . . . . . . . . 94 4.2.2 Attaques ciblant la mémoire . . . . . . . . . . . . . . . . . . . . . . 96 4.2.3 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 97 4.2.4 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 98 4.2.5 Attaques ciblant la cryptographie . . . . . . . . . . . . . . . . . . . 98 4.2.6 Attaques ciblant les fonctions ancillaires . . . . . . . . . . . . . . . 98 4.2.7 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . 99 4.2.8 Recommandation aux développeurs . . . . . . . . . . . . . . . . . . 100 4.2.9 Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2.10 Analyse dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.3 Architecture sécurisée pour la gestion d’un périphérique partagé . . . . . 102 4.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.3.2 Virtualisation matérielle d’un périphérique . . . . . . . . . . . . . 103 4.3.3 Utilisation de SR-IOV dans un contexte avionique embarqué . . . 105 ixConclusion générale 107 Bibliographie 111 xTable des figures 1.1 Architecture fédérée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Architecture IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Exemple de Module IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 L’arbre de la sûreté de fonctionnement . . . . . . . . . . . . . . . . . . . . 12 1.5 Guide de conception et techniques de certification (ARP 4754A, [arp10]) . 18 1.6 Les domaines de réseaux dans un avion (ARINC 811). . . . . . . . . . . . 22 1.7 Les domaines de réseaux dans un avion (extrait de [ari05]). . . . . . . . . 24 1.8 Partage simple entre 2 applications d’un module. . . . . . . . . . . . . . . 25 1.9 Visualisation des hypothèses de bas niveau. . . . . . . . . . . . . . . . . . 28 2.1 Hiérarchie des caches (architecture Harvard). . . . . . . . . . . . . . . . . 37 2.2 Les différents types de communications. . . . . . . . . . . . . . . . . . . . 42 2.3 Exemple d’une partition de 300 microsecondes. . . . . . . . . . . . . . . . 44 2.4 Schéma des différents traitements de la tolérance aux fautes. . . . . . . . . 47 3.1 Exemple d’ordonnancement avec 5 partitions. . . . . . . . . . . . . . . . . 58 3.2 Exemple d’entrées dans la TLB avec deux partitions et un noyau. . . . . . 60 3.3 Les deux phases de trois partitions. . . . . . . . . . . . . . . . . . . . . . . 60 3.4 Fonctionnement d’un Global Timer. . . . . . . . . . . . . . . . . . . . . . 61 3.5 Architecture du P4080 (extrait de [Fre11]). . . . . . . . . . . . . . . . . . 62 3.6 QorIQ DataPath Acceleration Architecture. . . . . . . . . . . . . . . . . . 64 3.7 La plateforme d’expérimentation. . . . . . . . . . . . . . . . . . . . . . . . 66 3.8 Sonde JTAG de Freescale. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.9 Capture d’écran du logiciel IDE Codewarrior de Freescale. . . . . . . . . . 68 3.10 Diagramme des états du SEC [Fre11]. . . . . . . . . . . . . . . . . . . . . 71 3.11 Chaîne de compilation pour une partition utilisant AFDX. . . . . . . . . . 73 3.12 Exemple de communication IPC . . . . . . . . . . . . . . . . . . . . . . . 75 3.13 Appel-système depuis l’Application 0 . . . . . . . . . . . . . . . . . . . . . 76 3.14 Boucle infinie l’Application 0 . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.15 Mesures des temps sur un cycle (5 ms). . . . . . . . . . . . . . . . . . . . 79 3.16 Comportement normal des deux partitions. . . . . . . . . . . . . . . . . . 80 3.17 Dépassement de P6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.18 Dépassement de la phase de préparation de P7. . . . . . . . . . . . . . . . 81 xi3.19 Dépassement de la phase de préparation et de la phase opérationnelle de P7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.1 Exemple d’accès entre 2 partitions et une partition I/O. . . . . . . . . . . 89 4.2 Proposition de contre-mesure sur le mécanisme IPC. . . . . . . . . . . . . 91 4.3 Proposition de contre-mesure prenant en compte les durées d’exécution d’interruption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.4 Architecture de virtualisation Single Root I/O [sri]. . . . . . . . . . . . . . 104 xiiIntroduction générale Contexte et problématique La sécurité des systèmes embarqués avioniques, au sens safety (ou sécurité-innocuité) est depuis toujours une préoccupation majeure des concepteurs et des exploitants de ces systèmes et plus largement du grand public. Historiquement, les sources de défaillance de ces systèmes étaient essentiellement liées à l’occurrence de fautes accidentelles, affectant les composants matériels ou logiciels, ou bien à des interactions humaines inappropriées. Cependant, le rôle de plus en plus prépondérant joué par les systèmes informatiques au sein des systèmes avioniques et également l’impact de leurs communications avec d’autres systèmes de l’environnement avionique posent de nouvelles problématiques relatives à la sécurité (au sens security ou sécurité-immunité) et aux risques d’attaques informatiques qui viennent s’ajouter aux contraintes de safety (ou sécurité-innocuité). Cette importance de la notion de sécurité-immunité est liée à l’évolution des systèmes d’information qui vise à réduire les coûts de production et d’opération. Cette évolution repose principalement sur trois approches. Tout d’abord, l’industrie aéronautique propose des systèmes d’information de plus en plus ouverts aux passagers et aux compagnies aériennes. Cette approche entraîne un élargissement de la surface d’attaque. Ensuite, l’industrie aéronautique utilise de plus en plus de composants sur étagère (ou COTS pour Commercial Off-The-Shelf) pour des applications plus ou moins critiques. Ces composants, étant conçus pour être génériques, sont souvent d’une plus grande complexité que ceux destinés à un système particulier. Cette complexité les fragilise vis-à-vis de la sécurité. En effet, il est pratiquement impossible de les vérifier parfaitement, c’est-à- dire de garantir, d’une part, l’absence de bogues, et, d’autre part, l’absence de fonctions cachées. Pour finir, le partage des ressources est de plus en plus employé pour héberger, au sein d’un même système, différentes applications ayant potentiellement différentes exigences de sécurité. Pour améliorer le niveau de sécurité des systèmes embarqués avioniques critiques, des techniques rigoureuses de développement, s’appuyant de plus en plus sur des méthodes formelles, sont utilisées pour accompagner les phases de spécification, de conception, de vérification et de certification, dans le but de contrôler si les propriétés de sécurité sont assurées. Cependant ces méthodes ne peuvent pas prendre en compte toutes les malveillances, notamment celles qui visent à exploiter certaines vulnérabilités invisibles par les méthodes formelles. Ces vulnérabilités exploitables se trouvent à l’interface entre 1logiciel et matériel, en particulier dans l’implémentation par le matériel de fonctions exploitées par le logiciel (gestion de l’adressage, gestion des interruptions, mécanismes de tolérance aux fautes, etc.) mais aussi sur des fonctions annexes de gestion du matériel (contrôle de fréquence d’horloge, de la consommation, de la température, de l’alimentation, etc.). Ces aspects ne sont généralement pas considérés par des modèles formels. En effet, il est difficile pour ce type de modèles de prendre en compte à la fois des propriétés de sécurité de haut niveau (par exemple l’intégrité des données critiques) et une représentation fine d’une implémentation matérielle. L’approche formelle doit donc être complétée par des analyses de vulnérabilités. Traditionnellement, ces analyses ne sont réalisées que lorsque le système est complètement intégré, donc très tard dans le cycle de développement, ce qui ne permet que de corriger ponctuellement des fautes de conception ou d’implémentation. L’approche développée dans cette thèse vise donc à compléter les méthodes formelles de conception et de développement par une analyse de vulnérabilités de façon à identifier au plus tôt des classes génériques de vulnérabilités, soit pour modifier la conception, soit pour développer des contre-mesures génériques, capables d’empêcher l’exploitation des vulnérabilités identifiées, mais aussi d’autres vulnérabilités similaires non encore connues. Ces travaux ont été effectuées dans le cadre du projet ANR SOBAS (Securing OnBoard Aerospace Systems). Présentation de nos travaux Nous débutons ce manuscrit par un chapitre dédié à la présentation des architectures des systèmes avioniques ainsi que leur évolution, étroitement liée aux avancées signifi- catives du domaine du logiciel. Ensuite, nous présentons les approches employées pour améliorer la sécurité-immunité dans ces systèmes et nous nous focalisons sur l’analyse de vulnérabilités, qui est l’objet de ce manuscrit. Nous concluons ce chapitre par la proposition d’une démarche en trois étapes pour l’application de l’analyse de vulnérabilités. Chacune de ces étapes fait ensuite l’objet d’un chapitre. La première étape, présentée dans le second chapitre, est dédiée à la caractérisation des attaques des systèmes embarqués. Les systèmes étant composés de différents composants matériels et logiciels, ces composants sont passés en revue pour identifier les attaques qui peuvent les concerner. Les composants passés en revue sont les composants matériels, les composants logiciels du système d’exploitation et les mécanismes de tolé- rance aux fautes. L’objectif de ce chapitre est de proposer une approche pour recenser l’ensemble des risques possibles, qui doivent faire l’objet d’une étude plus approfondie. La seconde étape se focalise sur la mise en œuvre des attaques sur une plateforme d’expérimentation. Ce travail est présenté dans le troisième chapitre. Tout d’abord, nous détaillons les différents éléments constituant notre plateforme d’expérimentation. Ensuite, quatre classes d’attaques correspondant aux attaques les plus importantes sont présentées, et les résultats sont discutés. Le quatrième chapitre présente la dernière étape de notre approche. Cette étape passe à nouveau en revue les classes d’attaques identifiées lors de la caractérisation, et identifie, 2pour chacune de ces classes d’attaques, un ensemble de contre-mesures adaptées. Ce chapitre est structuré en trois parties. Les contre-mesures spécifiques aux vulnérabilités identifiées dans le troisième chapitre sont dans un premier temps discutées. Ensuite, ces contre-mesures sont généralisées pour être adaptées à tout système embarqué. Pour finir, une architecture matérielle et logicielle, permettant le partage d’un périphérique entre plusieurs applications, est présentée et illustrée avec une carte réseau. Nous concluons ce manuscrit par une synthèse de nos contributions et présentons quelques perspectives de notre travail. 34Chapitre 1 État de l’art de la sécurité des systèmes avioniques Introduction Selon le US-CERT1 , le nombre d’attaques informatiques est en forte augmentation depuis 2006 [usc12]. Cette augmentation peut s’expliquer par deux raisons : la première est la complexité des systèmes actuels qui est de plus en plus élevée et donc plus difficile à gérer [Lab12] ; la deuxième raison est la simplicité d’utilisation d’outils automatiques d’attaque, maintenant accessibles aux débutants. Ces outils peuvent par exemple être utilisés pour réaliser des attaques de type Distributed-Denial-of-Service2 . A titre d’exemple, le groupe de pirates Anonymous a lancé une série d’attaques en janvier 2012 après la fermeture du site de partage Megaupload, ce qui a rendu indisponible de nombreux sites Internet [Can12]. Un autre exemple d’attaque de plus grande envergure est celle d’août 2013 qui a touché la Chine en bloquant les accès à une grande partie des sites Internet Chinois [01N13]. Avec la même facilité, les attaques contre des applications Web sont aussi possibles avec des outils tels que WebScarab [OWA13]. Ces outils en libre circulation sont performants et permettent de lancer des attaques contre n’importe quel système distant. Il s’agit de programmes malveillants qui peuvent endommager de façon catastrophique les systèmes ciblés : accès, modification de données confidentielles ; espionnage du système (keylogger) ; interruption de services (Denial-of-Service) ; exécution de virus ou rootkit ; attaque par force brute pour obtenir des mots de passe ; etc. Les systèmes embarqués avioniques peuvent également être ciblés par ces attaques. Il est donc important de les protéger efficacement contre ces malveillances. Une attaque informatique visant un système avionique peut avoir de graves conséquences comme des pertes matérielles voire des pertes humaines. Afin d’éviter l’occurrence de défaillances dans les systèmes avioniques, des mécanismes de tolérance aux fautes sont utilisés (redondance, votes majoritaires, etc.). Cependant, ces mécanismes sont efficaces pour des défaillances d’origine accidentelle mais ils ne sont pas forcément efficaces face à des at- 1United States Computer Emergency Readiness Team. 2Technique distribuée pour rendre hors service un serveur par inondation de requêtes. 5taques (autrement dit, face à des fautes d’origine intentionnelle). Il est donc nécessaire de considérer aussi d’autres moyens de protection, spécifiquement développés pour faire face aux fautes intentionnelles que sont les attaques informatiques. Et même si de tels moyens sont déjà utilisés dans les avions aujourd’hui, ils ne sont pas dans la même état de maturité que les mécanismes de tolérance aux fautes accidentelles. De plus, les architectures des systèmes embarqués avioniques évoluant, les menaces considérées évoluant également, il est donc fondamental d’améliorer ces mécanismes et de les adapter aux nouvelles architectures. Dans ce chapitre, nous décrivons une architecture utilisée pour la conception de système avionique. Ensuite, nous présentons les normes avioniques qui permettent de s’assurer que le code utilisé est conforme à sa spécification et ne contient pas de faute. Ensuite, nous détaillons comment ces systèmes sont protégés vis-à-vis des fautes accidentelles (sécurité-innocuité ou safety) et vis-à-vis des malveillances (sécurité-immunité ou security). Nous concluons ce chapitre en présentant une méthodologie d’analyse de vulnérabilités permettant d’identifier les vulnérabilités lors du développement afin d’intégrer au système les mécanismes de protection les plus adaptés, avant la finalisation du développement du système. 1.1 Systèmes avioniques Le terme architecture avionique représente l’ensemble des matériels et logiciels embarqués à bord de l’avion, qui assurent diverses fonctions telles que le traitement des informations provenant des capteurs, le pilotage automatique, la gestion du niveau de carburant, les échanges de messages avec l’opérateur au sol, pendant le vol, etc. Les architectures avioniques occupent une place non négligeable dans le coût des avions modernes (de l’ordre de 33% du coût total [pip09]). 1.1.1 Architecture fédérée Historiquement, dans les systèmes avioniques, chaque fonction de contrôle disposait de ses propres ressources matérielles (représentées par une machine ou un calculateur) pour son exécution, comme le montre la figure 1.1. Ces dispositifs dédiés sont très souvent répliqués pour la tolérance aux fautes et peuvent varier d’une fonction à l’autre. Il en résulte ainsi une architecture hétérogène et faiblement couplée, où chaque fonction peut opérer de manière quasi indépendante vis-à-vis des autres fonctions. Une telle architecture est qualifiée de fédérée. Par exemple, la construction des Airbus A330 et A340 repose sur ce type d’architecture. Les équipements numériques mettant en œuvre certaines des fonctions à bord sont reliés par des bus mono-émetteur. Un avantage majeur des architectures fédérées, en plus de leur simplicité, est la minimisation des risques de propagation d’erreurs qui peuvent survenir lors de l’exécution d’une fonction au sein du système. Cela assure une meilleure disponibilité du système global dans la mesure où une fonction défaillante peut éventuellement être isolée sans avoir recours à un arrêt complet du système. Cette caractéristique inhérente aux ar- 6Fig. 1.1 – Architecture fédérée chitectures fédérées est primordiale dans des systèmes critiques comme ceux qui sont embarqués dans les avions. Un autre avantage des architectures fédérées est leur hétérogénéité. En effet, les types de machines utilisées peuvent varier d’une fonction à l’autre au sein du même système. Cela permet l’utilisation de machines ayant des puissances variables. Cependant, cette vision classique de systèmes fédérés présente des inconvénients liés à une forte dépendance entre le logiciel et le matériel que nous résumons dans les points suivants : • La communication entre systèmes dépend des applications et également du maté- riel d’exécution. Toute mise à jour d’une entité logicielle implique une modification importante dans le mécanisme de communication, entraînant souvent la modification des autres entités logicielles pour maintenir une bonne interopérabilité. • Le matériel utilisé dans les applications avioniques est très hétérogène. En effet, chaque application possède ses propres contraintes fonctionnelles, et est exécutée sur un matériel qui lui est dédié. Assurer la maintenance matérielle dans ces conditions est une tâche fort coûteuse, d’un point de vue économique. • La durée de vie d’un avion est de l’ordre de plusieurs dizaines d’années (25-30 ans, voire plus). Cette durée de vie est longue relativement à la durée de vie d’un maté- riel. En effet, vu les avancées technologiques actuelles, un matériel devient obsolète au bout de quelques années seulement. Dans de nombreux cas, le matériel planifié durant la conception peut même devenir obsolète au moment de la construction de l’appareil. De plus, même si ce matériel est mis à jour, il faut bien s’assurer de la portabilité du logiciel qui n’a pas été originellement développé pour ce nouveau matériel. Cette tâche s’avère particulièrement coûteuse en raison du lien étroit qui existe entre le logiciel et le matériel dans un système fédéré. 71.1.2 Architecture IMA Dans les années 1990, sous l’impulsion de la commission européenne, des projets européens de recherche tel que PAMELA, NEVADA et VICTORIA [PAM01, NEV01, VIC01], ont permis l’émergence d’une autre vision dans la conception des systèmes avioniques ; celle-ci a pour but de pallier les insuffisances des architectures fédérées en proposant de dissocier les composants logiciels des composants matériels (dans les systèmes fédérés). Ce type d’architecture est qualifié de modulaire intégré, plus communément appelé IMA (Integrated Modular Avionics) [ARI08]. Le principe de l’architecture IMA [Mor91] est de répartir dans tout le volume de l’appareil un ensemble de ressources (calcul, mémoire, communication), qui pourront être partagées par plusieurs applications, qui accompliront les différentes fonctions du système avionique. Des exemples d’avions adoptant la solution intégrée sont l’Airbus A380 ou le Boeing B777. L’approche IMA présente trois principaux avantages : • Réduction du poids grâce à un plus petit nombre de composants matériels et un câblage réduit, ce qui augmente l’efficacité énergétique ; • Coût de maintenance réduit par l’utilisation de modules génériques ; • Réduction des coûts de développement par l’utilisation de systèmes standardisés et de COTS (Commercial-Off-The-Shelf). Cette organisation du système présente une plateforme unique (cf. Figure 1.2) pour plusieurs applications logicielles avioniques qui permet d’économiser les ressources, contrairement aux architectures fédérées. Par la même occasion, le coût de réalisation peut être limité de façon raisonnable. La plateforme consiste en un réseau temps-réel distribué, permettant à différentes applications de s’exécuter en parallèle. Cependant, elle introduit un risque de propagation d’erreur. Par exemple, une fonction en dysfonctionnement peut monopoliser le système de communication ou envoyer des commandes inappropriées, et pour chacune des fonctions il est difficile de se mettre à l’abri d’un tel comportement. Il est donc indispensable qu’une telle architecture assure un partage de ressource sûr entre les applications : le mécanisme dit de partitionnement [ARI08]. Par ce moyen, une ou plusieurs applications regroupées au sein d’un même module peuvent s’exécuter de manière sûre en parallèle (deux fonctions quelconques prévues pour s’exécuter dans un même module ne peuvent en aucun cas interagir l’une avec l’autre). De manière pratique, l’architecture physique est décrite par la norme ARINC 651. Les ressources sont regroupées dans des modules génériques appelés LRM (Line Replaceable Module), qui sont à leur tour regroupés dans des étagères, la communication au sein de ces étagères étant réalisée avec des bus spéciaux, généralement de type ARINC 659. Les modules peuvent être de trois types : • des modules cœurs qui sont ceux qui se chargent de l’exécution des applications ; • des modules d’entrée/sortie permettant la communication avec des éléments ne respectant pas l’architecture IMA ; • des modules passerelles servant à la communication entre étagères (l’architecture 8IMA n’impose pas de moyen de communication spécifique entre ses différents composants). Fig. 1.2 – Architecture IMA Ce partitionnement est classé en partitionnement spatial (par exemple, la gestion de la mémoire) et temporel (la gestion des ressources temporelles par le CPU) [Rus99]. Le partitionnement spatial des applications repose sur l’utilisation de composants matériels chargés de gérer la mémoire pour empêcher toute corruption de zones mémoires adjacentes à une zone en cours de modification. Le partitionnement temporel dépend des fonctionnalités attendues de l’ensemble (par exemple, on aura besoin d’exécuter plus souvent des fonctions qui s’occupent du rafraî- chissement de paramètres critiques). Avec ce partitionnement, des tranches de temps pour l’exécution des applications et l’exécution du noyau du système sont allouées statiquement. Afin de déterminer la durée des tranches de temps, des études d’estimation du pire cas du temps d’exécution (WCET3 ) sont réalisées de façon dynamique (sur le maté- riel ou sur simulateur) ou de façon statique (sans exécution) [Pua11]. Les méthodes d’estimation du WCET ne sont définies dans aucune norme avionique, il faut donc choisir la méthode appropriée en fonction de ses besoins. Il faut également prendre en compte l’utilisation de plusieurs cœurs dans les processeurs aujourd’hui car les multi-cœurs tendent à remplacer les mono-cœurs [Gen13, ZY09] ce qui change considérablement les calculs des durées d’exécution. La méthode dynamique d’évaluation du WCET s’appuie sur l’exécution de l’application sur le matériel ou sur simulateur et la mesure du temps d’exécution entre le début et la fin d’exécution. Le comportement de l’application peut dépendre des entrées/sorties. Il est donc nécessaire de générer ces informations. Une couverture 3Worst Case Execution Time. 9exhaustive du domaine des entrées serait bien sûr souhaitable mais le risque d’explosion combinatoire est élevé. En général, il s’agit donc de trouver un compromis entre la couverture des entrées générées et la précision du WCET que l’on souhaite obtenir. Un outil peut être utilisé pour mesurer le WCET automatiquement. Par exemple, RapiTime4 permet de créer des traces d’exécution et supporte la norme DO-178B (norme avionique sur laquelle nous reviendrons dans la suite de ce chapitre). La méthode statique d’évaluation du WCET calcule la durée d’exécution en analysant la structure du programme. Différentes techniques d’analyse existent : analyse des flux (Flow analysis), calcul avec arbre (Tree-based computation), énumeration des chemins, (IPET, Implicit Path Enumeration Technique), analyse de bas niveau (Low-level analysis). Mais en pratique, ces durées d’exécution seront forcément dépendantes du matériel et des exécutions passées. Elles doivent être calculées dans toute la chaîne d’exécution, c’est-à-dire qu’il faut être capable de connaître le chemin d’exécution exact ainsi que chaque type de données à traiter (entier, chaînes de caractères, etc.). De plus, les durées doivent être calculées pour tous les chemins d’exécution. Des outils sont également disponibles pour une méthode d’estimation statique, nous pouvons citer Bound-T5 , AbsInT6 (notamment utilisé pour l’A380). De manière générale, le partitionnement spatial et temporel désigne un mécanisme mis en place pour assurer une gestion des ressources qui ne met pas en péril le fonctionnement des applications qui l’utilise. Une architecture IMA peut donc être perçue comme un gestionnaire de ressources matérielles pour des applications avioniques embarquées. Ces applications sont implantées dans des modules pouvant avoir des niveaux de criticité différents. L’architecture IMA se doit d’être sûre afin de permettre un tel partitionnement entre applications à criticités multiples. Dans [ARI08], le partitionnement est défini comme devant assurer une isolation totale. L’isolation est réalisée en introduisant des partitions qui sont des espaces d’exécution logiques attribués à chaque fonction avionique. L’accès aux ressources (CPU, mémoire, etc) est ensuite contrôlé pour qu’il n’y ait aucune altération du fonctionnement des entités les plus critiques (des entités du niveau DAL-A ou DAL-B, par exemple). Une telle architecture est similaire à l’architecture d’un système d’exploitation classique. En effet, un système d’exploitation offre aux différentes applications qui y sont installées de s’exécuter en parallèle, indépendamment de la couche matérielle. Une architecture IMA (Figure 1.2), tout comme un système d’exploitation, offre des services (par exemple service de communication) aux applications qui y sont installées. Ces services sont accessibles via une interface de programmation des applications (Application Programming Interface : API) unique pour toutes les fonctions avioniques. Ainsi, une plateforme IMA est constituée d’un certain nombre de modules distribués dans l’avion. Ces modules sont connectés entre eux et également avec des périphériques de l’avion (typiquement des périphériques d’entrée/sortie comme des capteurs ou des interfaces homme machine). La Figure 1.3 présente l’aspect en couche d’un module IMA. Le module est constitué 4 http://www.rapitasystems.com/products/rapitime 5 http://www.bound-t.com/ 6 http://www.absint.com/ait/ 10Matériel Système d'exploitation API Application 1 Application 2 Application 3 Fig. 1.3 – Exemple de Module IMA d’un système d’exploitation en charge d’exécuter plusieurs partitions. La communication entre les partitions et le système d’exploitation du module se fait via l’API. Cette interface de programmation est la seule couche visible pour une application dans une partition donnée. Cette abstraction présente les avantages suivants : • Du fait de la transparence du matériel vis-à-vis des fonctions avioniques, il est possible d’utiliser du matériel distinct afin d’assurer une diversification matérielle (cf. 1.2.2), sans conséquence pour le fonctionnement de l’application. • La robustesse du partitionnement fait qu’une application peut être développée et testée d’une façon incrémentale, sans que cela n’altère le fonctionnement des autres partitions. • Grâce à l’interopérabilité des modules, en cas de défaillance d’un module, il est possible de reconfigurer une application logicielle pour qu’elle s’exécute sur un second module, ce qui présente une propriété fort intéressante en terme de disponibilité de l’application. Les architectures IMA sont déjà utilisées pour des fonctionnalités spécifiques sur certains appareils. Par exemple, le système d’exploitation PikeOS [KW07] est utilisé pour son niveau de certification afin de construire une architecture facile à certifier. Les équipements ainsi produits pourront être déployés sur le prochain A350 XWB. Cependant, la certification des systèmes avioniques utilise toujours la vision des systèmes fédérés. Des projets de recherche tel que SCARLETT [SCA11] définissent les évolutions de l’architecture IMA afin d’améliorer entre autre, le processus de certification. Comme nous avons pu le constater, la sécurité, au sens innocuité, est l’une des premières exigences qui a guidé le développement des fonctions avioniques (aussi bien au niveau matériel que logiciel). Cependant, la composante sécurité-immunité est devenue 11de plus en plus présente dans le monde avionique. Ces deux propriétés sont plus précisément définies dans le cadre de la sûreté de fonctionnement. 1.2 Sûreté de fonctionnement et le développement logiciel Dans cette section, nous donnons des définitions de la sûreté de fonctionnement et de ses composantes pour comprendre quelle utilité elle peut avoir dans un contexte avionique. Nous détaillons également comment s’effectue le développement de logiciels critiques en utilisant des normes et techniques de la sûreté de fonctionnement. Les défi- nitions de cette section proviennent de [L+96, ALRL04, A+06]. 1.2.1 Quelques définitions de la sûreté de fonctionnement La sûreté de fonctionnement d’un système informatique est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre. Le service délivré par un système est son comportement tel qu’il est perçu par son, ou ses utilisateurs, l’utilisateur étant un autre système, humain ou physique qui interagit avec le système considéré. La sûreté de fonctionnement peut être représentée par l’arbre suivant : Sûreté de fonctionnement Attributs Entraves Moyens Disponibilité Fiabilité Sécurité-innocuité Confidentialité Intégrité Maintenabilité Fautes Erreurs Défaillances Prévention des fautes Tolérance aux fautes Elimination des fautes Prévision des fautes Sécurité-immunité Fig. 1.4 – L’arbre de la sûreté de fonctionnement Cet arbre permet de définir les termes importants de la sûreté de fonctionnement : les attributs, les entraves et les moyens. 121.2.1.1 Attributs La sûreté de fonctionnement peut être perçue selon différentes propriétés appelées attributs : • la disponibilité est l’aptitude du système à être prêt à l’utilisation ; • la fiabilité est la continuité de service ; • la sécurité-innocuité est l’absence de conséquences catastrophiques pour l’environnement ; • la confidentialité est l’absence de divulgations non autorisées de l’information ; • l’intégrité est l’absence d’altérations inappropriées de l’information ; • la maintenabilité est l’aptitude aux réparations et aux évolutions. Ces attributs sont à considérer suivant le système que l’on souhaite étudier. Cela permet également de différencier sans ambiguïté les termes de safety et security. Le terme safety correspond à la sécurité-innocuité, qui définit les propriétés selon lesquelles un système est dit “sûr” (sans défaillance catastrophique pouvant conduire à des pertes de vies humaines ou des conséquences économiques importantes). Le terme security correspond à la sécurité-immunité7 , qui définit les propriétés selon lesquelles un système est dit “sécurisé”. Cet attribut est une combinaison de trois autres attributs : la confidentialité, l’intégrité et la disponibilité. La sécurité-immunité permet de prendre en compte les menaces informatiques tels que les virus, vers, bombes logiques, etc. 1.2.1.2 Entraves Les entraves sont les circonstances indésirables mais non inattendues, causes ou ré- sultats de la non sûreté de fonctionnement, car la confiance n’est plus assurée dans le système. Les entraves à la sûreté de fonctionnement sont les suivantes : fautes, erreurs et défaillances. La relation entre les entraves de la sûreté de fonctionnement peut être exprimée ainsi : ... → Défaillance → Faute → Erreur → Défaillance → Faute → ... Une faute est active (après avoir été dormante) lorsqu’elle produit une erreur. L’ensemble des fautes peuvent être réparties en huit catégories, selon : la phase de création (fautes de développement ou fautes opérationnelles), les frontières du système (internes ou externes), les causes phénoménologiques (naturelles ou humaines), les objectifs (fautes malicieuses ou non), la dimension (fautes matérielles ou fautes logicielles), les intentions (fautes délibérées ou non), la capacité (fautes accidentelles ou non) ou la persistance (fautes permanentes ou éphémères). Ces fautes peuvent être combinées pour former trois grandes classes de fautes : les fautes de développement, les fautes physiques et les fautes d’interaction. Les fautes de développement constituent toutes les fautes qui surviennent pendant le développement du logiciel. Les fautes physiques incluent les fautes qui affectent le matériel. Les fautes d’interaction incluent les fautes externes. Une erreur est définie comme susceptible de provoquer une défaillance. Elle peut être latente ou détectée. Une erreur est latente tant qu’elle n’a pas été reconnue en tant 7Aussi appelée sécurité-confidentialité dans [L+96]. 13que telle ; elle est détectée par un algorithme ou un mécanisme de détection qui permet de la reconnaître comme telle. Une erreur peut disparaître avant d’être détectée. Par propagation, une erreur crée de nouvelles erreurs. Une défaillance survient lorsque, par propagation, elle affecte le service délivré par le système, donc lorsqu’elle est perçue par le ou les utilisateurs. Une défaillance est définie comme un événement qui survient quand le service délivré dévie du service correct. Les défaillances ne se manifestent pas toujours de la même manière, ce qui signifie que l’on peut parler de modes de défaillances. On peut distinguer différentes dimensions pour caractériser les défaillances : le domaine de défaillance, la détectabilité de défaillances, la cohérence des défaillances, et les conséquences des défaillances. Le domaine des défaillances permet de distinguer les défaillances en valeur (la valeur du service délivré dévie de l’accomplissement de la fonction du système) et les défaillances temporelles (la temporisation du service dévie de l’accomplissement de la fonction du système). La détectabilité des défaillances permet de distinguer les défaillances signalées (le service délivré est détecté comme incorrect) et non signalées (la délivrance d’un service incorrect n’est pas détectée). La cohérence des défaillances permet de distinguer les défaillances cohérentes et les défaillances incohérentes ou byzantines (le service incorrect peut être perçu différemment suivant les cas). Les conséquences des défaillances permettent de distinguer les défaillances bénignes (les conséquences sont du même ordre de grandeur que le bénéfice procuré par le service délivré en l’absence de défaillance) des défaillances catastrophiques (les conséquences sont incommensurablement différentes du bénéfice procuré par le service délivré en l’absence de défaillance). 1.2.1.3 Moyens Quatre grandes catégories sont utilisées comme moyens pour satisfaire les attributs de la sûreté de fonctionnement : • La prévention des fautes permet d’empêcher l’occurrence ou de l’introduction d’une faute. • La tolérance aux fautes permet de fournir un service qui remplit la fonction du système en dépit de fautes. • L’élimination des fautes permet de réduire le nombre et la sévérité des fautes. • La prévision des fautes permet d’estimer la présence, la création et les consé- quences des fautes. La volonté d’empêcher l’occurrence de fautes paraît évidente pour des développeurs et notamment pour le développement de logiciels et la conception de matériels sûrs. Plusieurs techniques peuvent être utilisées : méthodes formelles, utilisation de langages fortement typés, règles de conception rigoureuses, etc. Un système tolérant aux fautes doit pouvoir remplir ses fonctions en dépit de fautes pouvant affecter ses composants, sa conception ou ses interactions avec des hommes ou d’autres systèmes. Pour mettre en œuvre la tolérance aux fautes, des techniques de traitement d’erreurs et de traitement de fautes sont utilisées. Parmi les différentes techniques de traitement d’erreurs, on peut citer la compensation, la reprise (rollback) ou la poursuite d’erreurs (rollforward). Parmi les différentes techniques de traitement de 14fautes, on peut citer le diagnostic, l’isolation, la reconfiguration ou la réinitialisation. L’élimination des fautes peut être faite pendant la phase de développement ou pendant la phase d’exécution. Pendant la phase de développement, l’élimination des fautes est réalisée en trois étapes : la vérification, le diagnostic et la correction. La vérifi- cation permet de vérifier que le système est exempt de fautes. Si une faute est détectée, le système de diagnostic a pour objectif d’en connaître la raison puis le système de correction permet de corriger cette faute. Pendant l’exécution, l’élimination des fautes consiste en de la maintenance corrective (après avoir détecté une faute) ou préventive (avant d’avoir détecté une faute). La prévision des fautes est conduite en réalisant une évaluation du comportement du système en prenant en compte les occurrences et les activations de fautes. L’évaluation peut être qualitative (pour identifier, classifier et ranger les modes de défaillances) ou quantitative (pour évaluer en terme de probabilités l’étendue pour laquelle des attributs sont satisfaits). 1.2.2 Tolérance aux fautes dans le domaine avionique Les systèmes avioniques tels que décrits dans la section 1.1 sont dotés de mécanismes de tolérance aux fautes pour réduire au minimum les risques de défaillances qui pourraient causer de nombreux dégâts pouvant aller jusqu’à des pertes humaines. Nous détaillerons ici deux mécanismes importants (mais d’autres existent) de tolérance aux fautes utilisés dans des avions : la redondance et la diversification fonctionnelle (les deux mécanismes utilisent le vote majoritaire pour prendre des décisions). 1.2.2.1 Utilisation de la redondance La redondance est souvent utilisée comme mécanisme principal de la tolérance aux fautes pour améliorer la fiabilité en utilisant des ressources alternatives. La redondance peut être logicielle, matérielle ou temporelle. Nous allons détailler trois types de redondance : statique, dynamique et hybride. La redondance statique utilise le masquage de fautes en réalisant un vote majoritaire entre les différentes répliques. Ainsi, si la majorité des répliques fonctionne correctement, une faute dans une minorité des répliques n’affectera pas le fonctionnement du système global. Cela suppose que les défaillances sont statistiquement indépendantes. La redondance dynamique utilise la reconfiguration du système (action de modifier la structure d’un système qui a défailli, de telle sorte que les composants nondéfaillants permettent de délivrer un service acceptable, bien que dégradé [L+96]). C’est la majorité des répliques qui décident de désactiver ou non une réplique défaillante. Mais avant, le système doit déterminer si la défaillance est permanente ou temporaire. Ensuite, il établit quelles fonctions sont nécessaires pour poursuivre l’exécution du programme, il détermine si une évaluation des dommages est nécessaire et si une isolation de fautes ou une reconfiguration sont nécessaires. La redondance hybride est la combinaison de la redondance statique et la redondance dynamique. C’est-à-dire que le masquage de fautes est appliqué en plus d’une 15reconfiguration du système. 1.2.2.2 Diversification fonctionnelle La diversification fonctionnelle est une technique qui utilise des variantes (les variantes correspondent à des répliques) et un décideur. C’est le décideur qui va commander l’ordre de désactiver ou non une variante. Cette technique est destinée à tolérer des fautes de conception logicielles. Il existe trois approches pour la diversification fonctionnelle : les blocs de recouvrement, la programmation en N-versions et la programmation N-autotestable [L+96]. Avec les blocs de recouvrement [Ran75], le décideur teste les variantes de façon séquentielle. La variante primaire est exécutée en premier lieu. Si une défaillance est constatée, une autre variante (secondaire) est exécutée à la place de la primaire. Il est alors nécessaire de restaurer l’état de la première exécution pour l’exécution de la variante secondaire. Une défaillance peut être provoquée par une faute logicielle telle que : division par zéro, excès de limite de temps, buffer overflow, etc. Avec la programmation en N-versions [Avi85], les variantes (ici appelées versions) et le décideur effectuent un vote majoritaire sur les résultats de toutes les versions. Par exemple, ce type de diversification fonctionnelle a été implémenté par Boeing pour le 777 en utilisant trois versions conçues par trois constructeurs différents (Intel, Motorola et AMD) ou en 4 versions pour les A330/A340 de Airbus. Pour Airbus, cette technique est utilisée depuis les premiers A300 (années 1970) avec des exécutions parallèles de deux variantes qui s’arrêtent quand une comparaison des résultats indique une différence [LABK90]. La programmation N-autotestable [LABK90] utilise des variantes en parallèle avec des mécanismes de détection d’erreurs. Un composant autotestable est un composant qui contient un mécanisme capable de contrôler si les propriétés entre ses entrées et ses sorties sont vérifiées. Si cela n’est pas le cas, un signal d’erreur est alors délivré au composant pour qu’il soit capable de se suspendre de lui-même et pour qu’une autre variante puisse continuer l’exécution. Après avoir présenté les différents mécanismes de tolérance aux fautes, nous donnons dans la suite de ce chapitre, un aperçu les différentes normes utilisées dans les logiciels et matériels critiques. 1.2.3 Développement de logiciels critiques sûrs Le développement logiciel des applications avioniques est réalisé en respectant un ensemble de normes et recommandations qui permettent de développer des systèmes critiques (logiciels et matériels) et de fournir des moyens de certifications. Le processus d’évaluation de la sécurité d’un système avionique a pour but de vérifier la conformité de la conception avec les exigences de navigabilité spécifiées par les autorités. Ces autorités sont l’EASA (European Aviation Safety Agency) pour l’Europe et la FAA (Federal Aviation Administration) pour les Etats-Unis. Les organismes suivants sont responsables de la rédaction des recommandations et normes : SAE (Society of Automotive Engineers), 16RTCA (Radio Technical Commission for Aeronautics) pour les Etats-Unis et EUROCAE (European Organisation for Civil Aviation Equipment) pour l’Europe. La SAE8 fournit les documents de type ARP (Aerospace Recommended Practice) ; la RTCA Inc.9 fournit les documents de type DO et l’EUROCAE10 fournit les documents de type ED. Nous pouvons également citer l’ARINC11 (Aeronautical Radio INCorporated qui est une entreprise créée en 1929 par plusieurs compagnies aériennes et constructeurs aéronautiques américains et rachetée en août 2013 par Rockwell Collins. Elle définit de nombreuses recommandations pour huit types d’industries : l’aviation, les aéroports, la défense, le gouvernement, les services de santé, les réseaux, la sécurité ainsi que les transports. L’ARINC a notamment conçu dès 1978, le système ACARS (Aircraft Communications Addressing and Reporting System) qui permet d’effectuer encore aujourd’hui des communications entre les stations au sol et les avions en utilisant la radio (communication VHF12 ou HF13) ou le satellite. Les organismes européens et américains travaillent en collaboration pour réaliser des documents équivalents, c’est pour cette raison que les noms des recommandations contiennent deux références différentes (DO et ED). Ces recommandations ARP, DO et ED sont devenues des normes avioniques au fil des années. Quatre principales normes sont utilisées pour le développement logiciel critique. L’ARP 4754A/ED-79 (Guidelines for Development of Civil Aircraft and Systems) décrit un processus de développement des systèmes avioniques et inclut des études pour permettre leur certification. L’ARP 4761/ED-135 (Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment), quant à elle, décrit un ensemble de méthodes d’analyse et d’évaluation de la sécurité-innocuité des systèmes avioniques à des fins de certification. Ces deux normes sont en général utilisée conjointement. Le DO-178B/ED-12C (Software Considerations in Airborne Systems and Equipment Certification) définit les contraintes de développement liées à l’obtention de la certification de logiciel avionique et le DO-254/ED-80 (Design Assurance Guidance for Airborne Electronic Hardware) est son pendant pour le développement d’équipement matériel électronique. La figure 1.5 présente les liens entre ces différentes normes et recommandations. 1.2.3.1 Guide de développement pour l’aviation civile – ARP 4754A La recommandation ARP 4754A (datant de décembre 2010) définit les processus de développement des avions civils et des systèmes critiques. Elle intègre notamment : la détermination et validation des exigences, le processus de certification, la gestion de la configuration, et la vérification de l’implémentation. Elle est utilisée conjointement avec l’ARP 4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment” qui définit les méthodes d’évaluation de la 8 http://www.sae.org 9 http://www.rtca.org 10http://www.eurocae.org 11http://www.arinc.com 12Very High Frequency. 13High Frequency. 17Cycle de vie du développement matériel (DO-254 / ED-80) Cycle de vie du développement logiciel (DO-178B / ED-12B) Conception du système Fonctions & exigences Implémentation Processus de développement du système Processus du cycle de vie matériel Processus du cycle de vie logiciel Fonction avionique prévue Fonction, défaillance & information de sûreté Fig. 1.5 – Guide de conception et techniques de certification (ARP 4754A, [arp10]) sécurité-innocuité des systèmes critiques et permet d’assigner les niveaux d’assurance de conception. La recommandation ARP 4754A permet de valider que les exigences sont correctes et complètes avec des méthodes de haut niveau sans faire de différences entre le logiciel et le matériel (qui est faite par ailleurs dans les recommandations DO-178C pour le logiciel et DO-254 pour le matériel). 1.2.3.2 Méthodes d’évaluation de la sûreté pour l’aviation civile – ARP 4761 Cette recommandation ARP 4761 définit plusieurs méthodes et techniques d’analyse de sûreté de fonctionnement sur le système, dont : Functional Hazard Analysis (FHA), Preliminary System Safety Analysis (PSSA), System Safety Analysis (SSA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA). Les systèmes avioniques peuvent avoir des niveaux de criticité différents suivant leurs applications et donc leurs 18développements imposent plus ou moins de vérifications/recommandations. L’analyse de risques fonctionnels (FHA) permet d’identifier les défaillances potentielles du système et les conséquences de ces défaillances en attribuant un niveau de DAL (Design Assurance Level) auquel est associé une probabilité par heure qu’une défaillance ne survienne. Les cinq niveaux de DAL sont les suivants : • Niveau A : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème catastrophique, la sécurité du vol ou de l’atterrissage est compromis et le crash de l’avion possible. • Niveau B : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème majeur entraînant des dégâts sérieux voire la mort de quelques occupants. • Niveau C : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sérieux entraînant par exemple une réduction significative des marges de sécurité ou des capacités fonctionnelles de l’avion. • Niveau D : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème ayant des conséquences mineures sur la sécurité du vol. • Niveau E : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sans effet sur la sécurité du vol. Pour le niveau DAL A (niveau catastrophique), il est considéré comme atteint si la probabilité d’activation est inférieur à 1× 10−9 par heure, alors que pour le niveau DAL D (niveau mineur), le seuil maximum est de 1 × 10−3 par heure, et pour le niveau E, aucun seuil n’est imposé. L’analyse PSSA quant à elle, examine les conditions de défaillance de la FHA et décrit comment la conception du système devra respecter les engagements définis. Plusieurs techniques peuvent être utilisées pour le PSSA comme des arbres des fautes (FTA), des chaînes de Markov, etc. 1.2.3.3 Conception et certification de logiciels – RTCA DO-178C La norme DO-178C qui est disponible depuis janvier 2012 est une mise à jour du DO-178B (qui datait de 1992). Elle décrit les objectifs pour les processus de cycle de vie des logiciels, les activités et les études de conception pour accomplir les objectifs et prouver que les objectifs ont été satisfaits. C’est en fait un modèle pour développer des logiciels de haute fiabilité. Il est donc important d’utiliser ces méthodes pour obtenir du code de confiance. Le nombre d’objectifs à atteindre dépend du DAL (voir 1.2.3.2) défini pour le logiciel analysé. Parmi les modifications apportées dans la version C, il y a notamment la volonté d’implémenter des approches qui peuvent changer avec la technologie, ce qui permet d’être compatible avec la modularité de l’architecture IMA. De même, quatre suppléments à ce standard ont été ajoutés : le DO-330 intitulé “Software Tool Qualification Considerations” pour la qualification d’outils avioniques, le DO-331 intitulé “Model-Based Development and Verification Supplement to DO-178C and DO- 278” pour utiliser le développement basé sur les modèles [SPHP02], le DO-332 intitulé “Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO- 19278A” pour les conseils sur les technologies orientées objets, le DO-333 intitulé “Formal Methods Supplement to DO-178C and DO-278A” pour utiliser les méthodes formelles si nécessaire. 1.2.3.4 Conception et développement matériel – RTCA DO-254 Ce standard, qui date d’avril 2000, permet de concevoir et développer des équipements matériels complexes fiables pour des systèmes avioniques. Il est composé de plusieurs sections : cycle de vie de la conception matérielle, processus de planification, validation et vérification, gestion de la configuration, certification, etc. Les objectifs de ce standard sont identiques à ceux vus précédemment dans DO-178C, la seule différence étant qu’ici, il cible le matériel et non le logiciel. 1.2.4 Sécurité-immunité dans les standards avioniques Les standards précédents décrivent les développements de systèmes critiques sûrs, pour empêcher que des fautes physiques et non des fautes d’interaction (voir sous-section 1.2.1.2) causent de graves conséquences. Ces standards sont donc plutôt orientés sécurité- innocuité. Cependant, il est intéressant de se pencher également sur la sécurité-immunité pour contrer d’éventuelles attaques informatiques car comme nous l’avons montré en dé- but de ce chapitre, le nombre d’attaques informatiques augmente. Les pirates informatiques ont notamment aujourd’hui une plus grande surface d’attaques avec les systèmes avioniques plus récents car ils offrent plus de connectivité (plus d’interactions entre les systèmes et ressources) et ils utilisent moins d’équipements spécifiques et davantage de COTS (donc potentiellement moins protégés). Dans cette sous-section, nous nous inté- ressons à la sécurité-immunité et aux standards qui abordent ce sujet. Des recommandations ont été rédigées par la FAA (§129.25 Airplane Security, §128.28 Flight Deck Security et §25.795 Security Considerations) mais elles n’adressent spécifi- quement ni la sécurité des réseaux ni la sécurité des données. Nous détaillons ici trois standards, dont deux concernent plus particulièrement le domaine avionique (ARINC 811 et RTCA DO-326), qui abordent la sécurité au sens de sécurité-immunité (pour faire face aux malveillances). On peut noter qu’il existe également des travaux qui s’intéressent aux interactions entre sécurité-innocuité et sécurité-immunité en proposant par exemple des approches développées harmonisées. On peut citer par exemple [DKCG99, B+12a, B+12b]. 1.2.4.1 Common Criteria for Information Technology Security Evaluation – ISO/IEC 15408 Les critères communs correspondent à une norme internationale ISO/IEC 15408 qui permet de certifier des systèmes de sécurité. Cette norme n’est pas spécifique aux systèmes avioniques mais elle peut être appliquée à certains systèmes avioniques si besoin. Elle permet notamment d’assigner un niveau de certification Evaluation Assurance Level (EAL) entre 1 et 7 (du moins exigeant au plus exigeant en terme de conception, tests et 20vérifications). Les produits certifiés ne garantissent pas l’absence de vulnérabilités mais seulement que des objectifs de tests et de vérifications ont été atteints. Par exemple, les produits tels que Microsoft Windows Server 2003 et Windows XP ont été certifiés en 2005 et sont évalués EAL4+, alors que nombreuses vulnérabilités ont été détectées depuis cette date : 629 vulnérabilités pour Windows XP et 532 vulnérabilités pour Windows Server 2003 [You]. 1.2.4.2 Sécurité des systèmes d’information des systèmes commerciaux – ARINC 811 Le document ARINC 811 a été publié en 2005 par l’ARINC pour faciliter la compréhension de la sécurité de l’information et pour développer des concepts de sécurité opérationnelle des avions [ari05]. Même s’il a pour but de protéger les informations sensibles, ce document n’est pas directement utile pour se protéger contre une attaque informatique, ou pour éviter l’exploitation de vulnérabilités présentes dans des applications (critiques ou non). Il définit le cycle de vie de la configuration de l’avion, les modes des systèmes (opérationnel normal, opérationnel non-normal et maintenance), les rôles de sécurité (Ground Security Administrator, Ground User, Onboard Cockpit User, Maintenance User, etc.) qui permettent de définir des groupes de personnes auprès des compagnies aériennes, les objectifs de sécurité de l’information, etc. La figure 1.6 présente les différents domaines de réseaux dans un avion. • Le domaine de commande de l’appareil (Aircraft Control Domain) est le domaine le plus critique dans le monde avionique. Il contient les applications de contrôle et de commande de l’appareil. Ces applications sont généralement installées sur des calculateurs qui récupèrent les commandes du pilote, les transforment (en fonction des lois de pilotage et des données environnementales, par exemple) en données numériques, et les communiquent (via un réseau dédié) aux différents actionneurs de l’appareil. • Le domaine de services d’information de la compagnie (Airline Information Services Domain) contient les différents supports relatifs au vol, la cabine, la maintenance). Ce domaine est moins critique que le précédent, mais il reste tout de même d’un niveau de criticité élevé. En effet, les informations contenues dans ce domaine sont critiques pour l’exploitation de l’appareil (surtout par rapport à la maintenance) par les compagnies aériennes. • Le domaine de services d’information et de divertissement des passagers (Passenger Information and Entertainment Services Domain) est en charge de la communication avec les passagers. Il comprend la gestion des écrans de divertissement (In Flight Entertainment : IFE) ainsi que l’interface de connexion des périphériques du passager. Ce domaine est fortement lié à l’image de marque de la compagnie aérienne auprès des passagers. Aussi, les compagnies accordent une grande importance aux équipements de divertissement des passagers, certaines allant même jusqu’à refuser l’autorisation de décollage d’un appareil si un terminal de divertissement (IFE) est défaillant. • Le domaine des équipements des passagers (Passenger-owned Devices) est réservé 21à tous les équipements électroniques des passagers (ordinateurs portables, smartphone, consoles de jeu). Dans certains avions récents, ces équipements sont connectables, via des interfaces spécifiques (présentes dans le domaine précédent), à un réseau que la compagnie aérienne peut configurer en fonction de sa stratégie commerciale (par exemple proposer une connexion Internet aux passagers). Fig. 1.6 – Les domaines de réseaux dans un avion (ARINC 811). 221.2.4.3 Processus de sécurité de la navigabilité – RTCA DO-326 La recommandation RTCA DO-326 intitulée “Airworthiness Security Process Speci- fication” publiée en décembre 2010 [do310] permet d’améliorer la sécurité (au sens de sécurité-immunité) à bord. Ce standard a pour objectif de sécuriser les quatre éléments suivants : • les connexions externes aux fournisseurs de services non-gouvernementaux (services de l’équipage de vol, services de maintenance) ; • les nouveaux services de divertissement (isolation entre les systèmes de contrôle de l’avion, partage de ressources) ; • les interfaces pour les média portables (incluant les ordinateurs portables) ; • l’insertion des équipements externes. Deux autres documents sont en cours de préparation pour compléter cette recommandation DO-326 : DO-YY3/ED-203 (Security Methods and Considerations) et DOYY4/ED-204 (Security Guidance for continuing airworthiness). Le document ED-203 permet d’assurer par des méthodes et des recommandations, que les évaluations de risques de sécurité sont rigoureux, équilibrés et justes. Il permettra également de s’assurer par des pratiques d’assurance de développement que les contre-mesures sur l’avion sont implémentées correctement. Le document ED-204 permet de s’assurer que les contremesures sont fonctionnelles et qu’elles sont maintenues correctement. Une mise à jour de cette recommandation sera publiée courant 2014 (sous le nom de DO-326A) pour améliorer celle existante. La DO-326 était à l’origine conçue pour être un supplément de l’ARP 4754 orienté sécurité, mais la publication de ARP 4754A en 2010 impliquait trop de changements pour être seulement un supplément, donc un nouveau document est nécessaire. Ce standard DO-326 est actuellement en cours de révision pour être plus en phase avec les évolutions actuelles. Malgré une volonté évidente de sécuriser les infrastructures avioniques, il est possible que des vulnérabilités subsistent et puissent être exploitées si des mécanismes de sécurité supplémentaires ne sont pas utilisés. Nous évoquons ce point dans la section suivante. 1.3 Problématique de la sécurité-immunité dans les systèmes avioniques Comme nous l’avons vu précédemment (voir sous-section 1.1.2), les systèmes IMA permettent d’offrir une connectivité accrue, un partage des ressources entre les applications (potentiellement de criticité différente) d’un même calculateur, et favorisent l’utilisation de COTS. Ces évolutions sont des atouts (réduction des coûts de développement, des coûts de maintenance, du poids) mais du point de vue de la sécurité, la surface d’attaque pour un programme malveillant en est décuplée. En effet, si par exemple, le partage de ressources n’est pas suffisamment protégé, une partition malveillante peut lire des données d’une autre partition voire même les modifier et ainsi potentiellement provoquer de graves conséquences. Nous présentons dans les sous-sections suivantes les problèmes de sécurité liées à chacune de ces évolutions. 231.3.1 Connectivité accrue entre les applications La connectivité à bord d’un avion peut prendre diverses formes. Elle concerne à la fois les communications entre différentes applications distantes, à travers un support de communication, qu’il soit filaire (ARINC 429, AFDX) ou non (VHF, satellite et Wifi). Elle concerne également les communications entre applications d’un même calculateur (partitions sur un même module). Par exemple, l’utilisation d’iPADs a été autorisée par la FAA depuis 2011 [DO11]. Ces iPADs peuvent être utilisés comme des EFB (Electronic Flight Bag) portables. A terme, la documentation avion papier anciennement nécessaire (représentant une masse de 15 kg environ) pourra donc être supprimée. Un autre exemple est l’utilisation d’appareils électroniques en fonctionnement pendant le décollage et l’atterrissage des avions, qui est possible depuis 2014 [lem13]. Cette évolution peut comporter des risques si la sécurité n’est pas maîtrisée. La figure 1.7 représente les domaines de réseaux présents dans un avion décrits dans le standard ARINC 811. Fig. 1.7 – Les domaines de réseaux dans un avion (extrait de [ari05]). Cette norme propose de décomposer les communications et équipements en trois catégories : publique, privée et fermée. La catégorie publique correspond aux appareils des passagers, comme les téléphones, ordinateurs portables, tablettes, etc. La catégorie privée correspond aux équipements de la compagnie aérienne comme les calculateurs fournissant l’accès à Internet, au Wifi, les systèmes de divertissement (IFE14). La caté- 14In-Flight Entertainment. 24gorie fermée correspond au domaine où les informations sensibles circulent et ne doivent pas être accessibles par un tiers. Cela concerne notamment la communication par satellite (SATCOM) et par radio (VHF). Des règles précises de filtrage des communications entre chaque catégorie doivent être définies. Les équipements des passagers étant totalement imprévisibles, il faut être capable de limiter leurs accès pour éviter les risques de perturbations. A l’heure actuelle, nous savons déjà qu’il est possible de perturber avec des ondes électromagnétiques de l’avion [Bro13]. Une étude de la IATA (International Air Transport Association) réalisée entre 2003 et 2009 sur 125 opérateurs a révélé que 75 cas de perturbations ont été détectés dont : des problèmes de communication, problèmes dans les contrôles de vol, des affichages défaillants, etc. La maîtrise des communications entre différentes applications sur un système avionique est donc fondamentale du point de vue de la sécurité. 1.3.2 Partage de ressource entre applications de différents niveaux de criticité Un autre avantage de l’architecture IMA est le partage facilité de ressources entre applications avec différents niveaux de criticité. Ce principe réduit les coûts de matériels mais la proximité physique des informations entre les applications entraîne un risque de compromission élevé. Pour cette raison, le partitionnement est utilisé. Il permet de restreindre les accès mémoire puisque chaque partition utilise une zone de la mémoire définie statiquement pendant la configuration. La figure 1.8 illustre un exemple simple de partage d’informations entre applications. Application 1 Application 2 Noyau temps-réel Fig. 1.8 – Partage simple entre 2 applications d’un module. Dans la figure 1.8, nous avons deux applications sur le même module qui communiquent entre elles, le partitionnement permettant de contrôler les accès aux informations. Ce partage sur un système temps-réel doit être opéré de façon à ce que les données soient accédées de façon périodique ou apériodique mais elles ne doivent jamais être accessibles à deux applications en même temps pour éviter des accès concurrents à la même ressource. Il est donc nécessaire de s’assurer que ce mécanisme de partitionnement soit effi- cace de manière à empêcher une application disposant d’un niveau de criticité faible de perturber le comportement d’une application de niveau de criticité élevé. 251.3.3 Utilisation de composants COTS Aujourd’hui, l’utilisation de composants COTS (Commercial-Off-The-Shelf) repré- sente plus de 95% de tous les composants de l’avion [Ska13] et ces composants n’ont pas forcément les mêmes exigences de conception et de développement que les composants avioniques spécifiques. Les fournisseurs de logiciels et matériels COTS sont susceptibles à tout moment de faire des modifications dans leurs logiciels et composants sans pour autant qu’elles soient validées à nouveau pour être embarquées dans l’avion. L’adoption d’une mise à jour d’un COTS pour utilisation dans un avion nécessite donc systématiquement un processus de validation complet. Les composants COTS sont cependant acceptés à bord car d’une part, ils sont conçus par des fournisseurs choisis et approuvés par les constructeurs d’avions, et d’autre part, parce que ces composants ont été évalués et acceptés vis-à-vis d’un cahier des charges précis. Ces démarches réduisent considérablement a priori le risque que ces composants soient intentionnellement corrompus. Cependant, les composants de faible criticité sont évalués à un niveau inférieur à celui des composants de forte criticité ; il est donc toujours possible que des vulnérabilités subsistent. 1.3.4 Conclusion Les évolutions de l’architecture des systèmes avioniques que nous venons de présenter (connectivité, partage des ressources et utilisation des COTS), augmentent la surface d’attaques possible et par conséquent, le risque potentiel de malveillance. Améliorer la sécurité des systèmes embarqués dans les avions est donc un problème important pour l’industrie aéronautique et il est fondamental aujourd’hui d’adapter les mécanismes de protection à l’évolution des architectures de leurs systèmes d’information. Des cyber-attaques contre ces systèmes ont déjà été réalisées. En octobre 2011, des virus ont été détectés dans une flotte de drones américains Predator et Reaper [Mun11]. En avril 2013, des compagnies aériennes et constructeurs d’avion se sont intéressés de près à Hugo Teso, après des révélations sur la faible sécurité des communications dans les protocoles avioniques ADS-B15 à ACARS16. Lors d’une démonstration sur un logiciel d’entraînement non avionable, il a voulu montrer qu’il était possible d’obtenir un accès au Flight Management System (FMS) [Tes13]. Même si sa démonstration n’était pas concluante, le fait qu’il l’ait présenté publiquement a été pris très au sérieux par l’ensemble de la communauté aéronautique, autorités et constructeurs. Nous allons maintenant décrire dans la prochaine section les différentes approches existantes pour protéger les systèmes avioniques efficacement face à des malveillances. 1.4 Différentes approches pour améliorer la sécurité-immunité Pour assurer la sécurité-immunité des systèmes avioniques, il est nécessaire d’appliquer ou d’adapter des méthodes et techniques qui ont prouvé leur efficacité pour la 15Automatic Dependent Surveillance-Broadcast. 16Aircraft Communication Addressing and Reporting System. 26protection de systèmes informatiques “classiques” : • les outils et mécanismes de sécurité (pare-feux, contrôle d’accès, système de détection d’intrusion, etc.) ; • les méthodes formelles pour la spécification, le développement, la vérification et la certification ; • l’analyse de vulnérabilités avec les contre-mesures associées, appliquées au plus tôt dans le cycle de développement. Nous allons présenter maintenant ces trois approches dans les prochaines sous-sections. 1.4.1 Intégration de mécanismes de sécurité adaptés Assurer la sécurité-immunité des systèmes peut en partie être réalisé en utilisant des outils et mécanismes de sécurité classiques. Plusieurs types d’outils existent : les firewalls, le contrôle d’accès, les systèmes de détection d’intrusion (Intrusion Detection System ou IDS), l’authentification, le chiffrement, etc. Ces outils ont montré leur efficacité pour la protection face aux attaquants sur les systèmes classiques. En revanche, ils doivent être adaptés pour satisfaire les contraintes des systèmes avioniques. Les deux contraintes principales sont le respect des délais d’exécution et le partitionnement spatial et temporel des partitions. A titre d’exemple, dans un système classique, un IDS peut être déployé sur une machine de manière à observer à la fois les communications concernant les applications de la machine et les communications entre deux autres machines. Un IDS peut ainsi se baser sur ces observations pour remonter des alertes correspondant à l’identification d’une tentative d’attaque. Il doit donc pouvoir avoir accès à l’ensemble des communications. Par contre, sur un système avionique, une application peut observer uniquement les communications la concernant. Ce dispositif serait donc dans l’incapacité de détecter des tentatives d’intrusion concernant les autres applications. Donc, les IDS employés dans les réseaux d’entreprises ne peuvent pas être déployés en l’état sur les systèmes embarqués. Il est relativement simple de mettre en place les mécanismes de chiffrement dans les systèmes avioniques. Par contre, un inconvénient majeur pour ces mécanismes concerne le temps de chiffrement qui peut être relativement long (surtout pour des calculs concernant certains chiffres assymétriques tels que le RSA). De la même manière, pour les mécanismes de contrôles d’accès et d’authentification, des vérifications doivent être réalisées à chaque accès aux ressources, ce qui peut s’avérer également particulièrement coûteux. 1.4.2 Utilisation de méthodes formelles Les méthodes formelles sont utilisées par les avionneurs pour vérifier le fonctionnement des applications et des systèmes [S+09b]. Par exemple, Airbus utilise ces méthodes depuis 2001 pour l’A380. La norme RTCA DO 178C propose notamment une annexe concernant l’utilisation de ces méthodes. 27Les méthodes formelles fournissent une structure mathématique avec laquelle il est possible de s’assurer que le modèle d’un système satisfait bien un cahier des charges formel. Mais les méthodes formelles ont aussi des limitations [LA95], les spécifications formelles peuvent ne pas être efficaces car il n’y a pas de principe général sur la façon d’acquérir les exigences de l’utilisateur et comment les enregistrer en utilisant un langage formel de spécification. Le raffinement qui consiste à passer de l’abstraction d’une spécification à l’implémentation est une opération sensible qui peut engendrer de nouveaux problèmes si cette opération est mal réalisée. Les preuves formelles sont elles aussi sujettes à des problèmes suivant le raffinement qui est réalisé. De la même façon, la spéci- fication peut ne pas être suffisamment détaillée pour le développeur ou alors les exigences de l’utilisateur peuvent être mal comprises par le concepteur/développeur. D’autres problèmes potentiels plus spécifiques aux systèmes sécurisés sont cités dans [JH08] : spé- cifications invalides ou partielles, définitions de propriétés trop vagues, implémentation trop “libre” pour le développeur qui amène à des interprétations personnelles. Nous pouvons ajouter à cela que les méthodes formelles doivent se baser sur des hypothèses sur l’environnement d’exécution, soit parce que l’environnement d’exécution n’est pas encore disponible, soit parce que sa complexité nécessite de le modéliser de manière plus simple. La figure 1.9 illustre ce problème. Fig. 1.9 – Visualisation des hypothèses de bas niveau. La partie gauche de la figure représente les étapes nécessaires pour une conception ascendante et une vérification de l’application (“Conception top-down”) et la partie droite représente l’exécution de ce même système. Pendant la vérification de la conception, 28certaines hypothèses doivent être faites sur l’environnement dans lequel il sera exécuté. C’est à ce niveau que des problèmes peuvent subsister car ces hypothèses peuvent ne pas correspondre ou être légèrement différentes de la réalité dû à des changements nonprévus après la conception, des reconfigurations, etc. Ceci est en particulier vrai pour le matériel dont il est très difficile à priori de connaître parfaitement le fonctionnement. Si certaines hypothèses de bas niveau sont effectivement vérifiées, il est possible que d’autres ne le soient pas, ce qui peut conduire à la présence de vulnérabilités. 1.4.3 Analyse de vulnérabilités dans le processus de développement La troisième approche consiste à analyser un composant (matériel, noyau temps-réel et applications) en vue de détecter la présence de vulnérabilités. Une vulnérabilité est une faute qui peut être exploitée pour corrompre une partie ou la totalité du système. Il est donc important de détecter ces vulnérabilités pour éviter des conséquences graves sur la sécurité du système. Les analyses de vulnérabilités permettent de détecter les vulnérabilités mais elles sont généralement réalisées lorsque les systèmes sont en production pour étudier s’ils sont vulnérables à des attaques informatiques. L’inconvénient de cette démarche est que, lors de l’identification d’une vulnérabilité, la contre-mesure se limitera à une “rustine” locale appliquée au système. Cette contre-mesure ne pourra donc pas être intégrée directement dans l’architecture de ce système. Or, il est également possible et intéressant de réaliser une analyse de vulnérabilités au plus tôt dans le développement du noyau et des applications pour les détecter avant que le système soit en production. Ces analyses de vulnérabilités peuvent également être intéressantes pour identifier l’architecture logicielle la plus adaptée pour éviter l’introduction des vulnérabilités. Nous avons décidé de développer cette approche pour la suite car c’est une approche innovante pour les systèmes critiques et elle peut donner de bons résultats. L’analyse de vulnérabilités réalisée tôt dans le processus de développement permettra de corriger ces vulnérabilités pour améliorer la protection globale du système embarqué. Dans la prochaine section, nous détaillons l’analyse de vulnérabilités dans les systèmes critiques embarqués. 1.5 Analyse de vulnérabilités dans les systèmes critiques embarqués Nous nous intéressons dans cette section à l’analyse de vulnérabilités sur des systèmes classiques, pouvant être adaptée à des systèmes temps-réel. Pour les systèmes non tempsréel, les analyses de vulnérabilités sont souvent utilisées pour détecter si des maliciels sont présents, si des données peuvent être volées ou si le système peut être corrompu. Une fois détectée, il est nécessaire de trouver des moyens pour se protéger efficacement et ainsi éviter que cette vulnérabilité ne soit exploitée. Les analyses de vulnérabilités peuvent être réalisées de manière automatique ou de manière manuelle. Elles peuvent être également réalisées par des approches boîte noire ou par des approches boîte blanche. 29Une analyse de vulnérabilités manuelle a l’avantage d’être plus approfondie mais cette analyse requiert en général des compétences très spécifiques que seul un expert humain est capable de mettre en pratique. De plus, le temps nécessaire pour faire cette analyse est long car il est très difficile de prendre en compte toutes les subtilités d’un système, étant donné sa complexité. Une analyse automatique permet en revanche une analyse plus rapide mais plus superficielle car les outils ne font pas de recherche approfondie contrairement à l’analyse manuelle. En effet, il est très difficile de développer des outils d’analyse automatique en leur permettant de traiter un large éventail de vulnérabilités. Cette difficulté est en partie due à la complexité des cibles des analyses. De nombreux travaux ont été réalisés pour évaluer la présence de vulnérabilités dans des systèmes, par différents moyens [IW08]. Les approches boîte blanche et les approches boîte noire se distinguent par les conditions dans lesquelles ces analyses sont réalisées. L’approche par boîte blanche consiste à avoir accès à toutes les informations du système allant du code source à la documentation et permet ainsi de comprendre exactement comment il fonctionne. L’approche par boîte noire consiste à ne pas avoir ces informations et donc à travailler sans aucune connaissance particulière sur le système. Nous allons décrire ces deux types d’analyses dans les prochaines sous-sections 1.5.1 et 1.5.2 pour en comprendre le fonctionnement. L’approche que nous proposons sera ensuite décrite dans la sous-section 1.6. 1.5.1 Approche par boîte blanche L’approche par boîte blanche consiste à avoir accès à des informations du système (code source, binaire et documentation éventuelle) pour réaliser l’analyse de vulnérabilités. Deux techniques différentes sont possibles pour réaliser cette analyse. L’une “statique” consiste à analyser le code source ou le fichier binaire mais sans exécuter le programme ciblé. L’autre technique est dite “dynamique”, elle consiste à faire l’analyse pendant l’exécution du programme ciblé en observant les flux de données (entrées et sorties) soit en instrumentant le code (i.e. modifier le code avec des informations de debug) soit en le laissant tel quel. Cependant, si le programme a été modifié pour réaliser l’instrumentation, il se peut que son comportement soit différent du comportement dans l’environnement réel d’exécution. En général, des outils d’analyse de code sont utilisés pour détecter les vulnérabilités, ils analysent le code source pour détecter les erreurs courantes de débordement de buffers (buffer overflows), débordement d’entiers (integer overflows) ou encore de divisions par zéro. Plusieurs outils d’analyse statique sont utilisés dans l’industrie, nous en présentons 4 : • Caveat [B+02] est un outil de vérification formelle qu’utilise Airbus depuis 2002. Il permet d’analyser des programmes en C et propose deux fonctionnalités : les analyses de flux de contrôle et de données (automatique pour l’outil) et la preuve des propriétés spécifiées par l’utilisateur. 30• Frama-C17 permet d’analyser des programmes C et de s’assurer que le code source est conforme à une spécification formelle définie. Il est possible d’ajouter des plugins pour y ajouter des fonctionnalités. Ces plug-ins peuvent ensuite communiquer entre eux grâce à un langage de spécification commun appelé ACSL. • Astrée18, également utilisé par Airbus, permet de prouver l’absence de Run-Time Error (RTE) [C+07] en utilisant la théorie de l’interprétation abstraite [CC77]. • Ait19 analyse un programme dans sa forme binaire pour calculer une borne supé- rieure du WCET des tâches du programme. Il permet de vérifier que les WCET calculés correspondent à ceux mesurés. Ces outils sont utiles pour vérifier que le code (ou le fichier binaire) fait ce qu’il doit faire sans faute de développement mais des vulnérabilités peuvent encore subsister. Les analyses menées par ces outils peuvent donc être complétées par des analyses dites “approches par boîte noire”. 1.5.2 Approche par boîte noire L’approche par boîte noire consiste à réaliser l’analyse de vulnérabilités sans avoir une connaissance particulière du système. Elle repose généralement sur l’observation des interactions du composant analysé avec son environnement. Les techniques statiques et dynamiques pourraient être appliquées dans ces approches. Cependant, les techniques statiques ne sont pas pertinentes car elles imposent d’avoir accès soit au code source soit au binaire, avant l’exécution et elles ne permettent donc pas d’être dans un contexte d’approche par boîte noire. En revanche, les techniques dynamiques sont pertinentes car, pendant l’exécution, l’analyse de vulnérabilités peut être réalisée en analysant les flux d’entrées et de sorties (par exemple, vérification des limites d’un tableau en mémoire, etc.) sans avoir d’informations particulières sur le programme exécuté. Les différentes étapes nécessaires sont les suivantes : • identifier les composants de l’environnement ; • sélectionner des attaques susceptibles de fonctionner ; • tester les attaques sélectionnées ; • observer le comportement du système. L’identification des composants de l’environnement permet de connaître l’ensemble des composants avec lesquels le composant à analyser peut interagir. Ces interactions sont réalisées par des entrées et des sorties. Souvent, les outils d’analyse dynamique adoptant une approche boîte noire se basent sur ces entrées et sorties pour tester les composants. La seconde étape correspond à un croisement entre les informations collectées dans la première étape avec une base de connaissance sur des classes d’attaques. En général, la connaissance de l’environnement est nécessaire pour tester des situations extrêmes. Ces classes d’attaques sont utilisées pour atteindre ces situations extrêmes. Pour 17http://frama-c.cea.fr/ 18http://www.astree.ens.fr/ 19http://www.absint.com/ait/ 31pouvoir être testées, ces classes d’attaques doivent être instanciées. Une classe d’attaque souvent employée est la génération de données aléatoires (fuzzing). Les attaques obtenues sont ensuite testées sur le composant, dans la troisième étape. Pour finir, le comportement du composant est analysé dans la dernière étape. Si, lors de l’exécution de l’attaque, une défaillance est identifiée (par exemple, le composant ne délivre plus de service), alors l’attaque est considérée comme réussie. Il faut aussi prendre en compte l’impact des mécanismes de tolérance aux fautes du composant sur le déroulement du processus de tests (par exemple un redémarrage du système conduira à l’arrêt du test). Les méthodes d’analyse dynamique ont deux défauts principaux [C+07] : • elles peuvent prouver la présence d’erreurs mais pas leurs absences ; • elles ne peuvent pas vérifier toutes les propriétés d’un programme (présence de code mort ou non terminaison). 1.6 Contribution de cette thèse : une méthodologie d’analyse de vulnérabilités pour des systèmes embarqués avioniques Les sections précédentes décrivent les systèmes avioniques et les techniques de sûreté de fonctionnement utilisées dans ces systèmes pour éviter des conséquences graves sur les systèmes avioniques. Les normes et techniques permettant d’améliorer la sécurité- innocuité et la sécurité-immunité à bord de l’avion sont également présentées dans ces sections. Un focus particulier est réalisé sur l’analyse de vulnérabilités, qui constitue une de ces techniques. Habituellement, les analyses de vulnérabilités sont réalisées à la fin du développement et en phase d’exploitation et, en cas d’identification de vulnérabilités, ce sont des “rustines” qui sont appliquées localement, la plupart du temps sans essayer de repenser l’architecture globale de l’application. Effectivement, le temps restant pour produire le système ne permet pas de revenir sur les phases de conception et de modélisation du système. Réaliser les tests et découvrir des vulnérabilités pendant le développement à partir du moment où l’on dispose d’un premier prototype du système permet une toute autre approche. La découverte de certaines vulnérabilités, jugées critiques, peut amener à une modification de l’architecture globale de l’application, parce qu’il est encore temps de le faire sans que ce soit trop coûteux. On peut ainsi obtenir une architecture construite pour “intrinsèquement” éviter l’introduction des vulnérabilités identifiées, dès les premières phases de son développement. Cette analyse de vulnérabilités et la proposition de contre-mesures adaptées au plus tôt dans le cycle de développement logiciel est au cœur de la contribution de cette thèse. Nous allons pour cela proposer une méthodologie d’analyse de vulnérabilités, basée sur trois grandes étapes : • Dans un premier temps, il est fondamental de classifier l’ensemble des menaces qui peuvent peser sur les systèmes embarqués avioniques. C’est la contribution proposée par le chapitre 2. Dans ce chapitre, nous proposons de définir une classification la plus exhaustive possible des différentes attaques qui peuvent cibler les systèmes 32embarqués avioniques. Bien sûr, certaines attaques sont similaires à des attaques que l’on peut rencontrer sur des systèmes informatiques usuels “du bureau”, mais certaines sont spécifiques aux systèmes avioniques car elles peuvent tirer partie de certaines caractéristiques spécifiques de ces systèmes pour arriver à leur fin. Nous détaillons donc ces deux familles d’attaques dans notre classification. • Une fois cette classification établie, une phase d’expérimentation sur le système cible doit avoir lieu. Ces expérimentations doivent faire en sorte de tester aussi exhaustivement que possible les attaques décrites dans la classification précédente. Bien évidemment, elles doivent être précédées d’une analyse précise du système cible et de son fonctionnement interne de façon à pouvoir parfaitement mener des attaques adaptées à ce système. Cela signifie que l’analyse doit tenir compte à la fois du logiciel mais aussi du matériel sur lequel le système s’exécute. C’est la raison pour laquelle il est fondamental que les expérimentations se déroulent sur une plateforme matérielle identique à la plateforme sur laquelle le système avionique doit réellement s’exécuter en opération. Le chapitre 3 présente un exemple de mise en œuvre de telles expérimentations sur un système avionique expérimental fourni par Airbus France. Ce chapitre commence donc par présenter en détail l’implé- mentation de ce système, ainsi que la plateforme sur laquelle il s’exécute. Ensuite, il présente l’ensemble des attaques qui ont été envisagées sur cette plateforme et décrit en détail celles qui ont été les plus pertinentes en terme de découvertes de vulnérabilités. • Enfin, la dernière phase de notre méthodologie consiste à concevoir et implémenter des contre-mesures efficaces face aux vulnérabilités découvertes. C’est l’objet du chapitre 4. Les contre-mesures proposées dans ce chapitre sont de deux types. Nous y décrivons dans un premier temps les contre-mesures spécifiques aux vulnérabilités découvertes sur le système présenté dans le chapitre 3. Ensuite, nous essayons de généraliser ces contre-mesures, de façon à proposer des recommandations, aussi gé- nériques que possible, à appliquer durant le développement de systèmes embarqués avioniques. 3334Chapitre 2 Caractérisation des attaques des systèmes embarqués Introduction Dans le chapitre précédent, nous avons justifié la nécessité d’améliorer et de réaliser systématiquement des analyses de vulnérabilités dans le processus de développement des systèmes embarqués avioniques de future génération. En effet, l’évolution des systèmes (ouverture, partage, utilisation de COTS) facilitent l’introduction de vulnérabilités et il est donc fondamental d’accompagner leur développement d’une analyse de vulnérabilités approfondie, au plus tôt, pour renforcer leur sécurité. Il est nécessaire d’adopter une démarche rigoureuse pour mener cette analyse de vulnérabilités. Pour cela, une connaissance précise des attaques qui peuvent menacer ces systèmes est requise. C’est la raison pour laquelle ce chapitre propose une classification des différentes attaques qui peuvent cibler des systèmes embarqués critiques avioniques. Cette classification a fait l’objet d’une publication dans [DADN12]. Nous avons établi cette classification en faisant le raisonnement suivant. Un système embarqué critique a de multiples points communs avec un système informatique “classique” utilisé dans le cadre professionnel ou privé. Nous allons donc établir une première classification d’attaques inspirée des classifications connues des attaques sur les fonctionnalités de base des systèmes informatiques classiques, en les adaptant toutefois aux spécificités et aux contraintes du monde avionique. Nous appellerons cette catégorie attaques ciblant les fonctionnalités de base. Cependant, un système avionique embarqué possède des caractéristiques spécifiques très particulières pour des raisons de sûreté de fonctionnement (safety). Il inclut en particulier un ensemble de mécanismes de tolérance aux fautes. Or, ces mécanismes eux-mêmes peuvent être potentiellement la cible d’attaques et leur corruption peut s’avérer particulièrement intéressante pour un attaquant. Nous le montrerons dans la suite de ce chapitre. Nous avons donc défini une seconde catégorie d’attaques appelée attaques ciblant les mécanismes de tolérance aux fautes. Ce chapitre est principalement consacré à la présentation de ces deux catégories d’attaques. A la fin de ce chapitre, nous présentons également le contexte et les hypothèses 35d’attaques que nous avons considérés pour notre étude. 2.1 Attaques visant les fonctionnalités de base Un système avionique embarqué, comme tout système informatique, utilise un processeur, de la mémoire, des périphériques, un système d’exploitation et des applications, et les mécanismes de gestion qui leurs sont associés. Nous avons ainsi classifié les attaques visant les fonctionnalités de base en huit catégories. • le processeur ; • la gestion de la mémoire ; • les communications ; • la gestion du temps ; • la gestion des processus ; • l’ordonnancement ; • la cryptographie ; • les fonctions ancillaires. Les sous-sections suivantes présentent ces différentes catégories. Pour chaque catégorie, nous décrivons rapidement le fonctionnement du composant ciblé ou de la fonctionnalité ciblée et nous donnons le principe général des attaques que nous estimons possibles sur ce composant ou cette fonctionnalité. Nous nous inspirons des attaques connues dans le monde des PCs de bureau et de l’architecture x86, qui sont des architectures bien plus éprouvées par les attaquants que les architectures avioniques, du point de vue de la sé- curité. Nous pouvons ainsi proposer un riche panorama d’attaques possibles, même si aujourd’hui, de telles attaques n’ont encore pas toutes vu le jour sur des architectures de type avionique. L’important, est d’être aussi exhaustif que possible afin de pouvoir anticiper au mieux l’occurrence de nouvelles attaques. 2.1.1 Attaques ciblant le processeur Le processeur est le composant matériel principal d’un calculateur. Il exécute les différentes instructions. De nombreuses caractéristiques et améliorations sont incluses dans les processeurs modernes : multiples cœurs, multiples niveaux de mémoires caches, unité de gestion de la mémoire, unité de prédiction de branchement, interruptions, etc. En particulier, les caches des processeurs sont utilisés pour réduire le temps moyen d’accès mémoire (car la mémoire SRAM (Static Random Access Memory) utilisée est beaucoup plus rapide que la DRAM (Dynamic Random Access Memory). En revanche, la SRAM ne peut contenir que très peu de données. Les systèmes actuels ont généralement trois niveaux de caches (L1, L2 et L3) placés de façon à optimiser les accès mémoire. Le premier niveau de cache (par exemple de 64 Ko) est au plus proche des cœurs du processeur. Il peut être partagé en deux caches, un pour les instructions et un autre pour les données (architecture Harvard) ou non (architecture von Neumann). Le second niveau de cache (par exemple de 128 Ko) est partagé entre les cœurs et est en général unifié (aucune séparation entre instructions et données). Le troisième niveau de cache se 36situe après le cache L2. Il est donc plus lent mais contient plus de données (par exemple 8 Mo). Lorsque ces caches sont utilisés, les données de la mémoire y sont copiées pour être réutilisées plus tard. Des mécanismes de cohérence des caches sont mis en œuvre pour que les caches contiennent les valeurs correctes aux mêmes moments. Des problèmes de sécurité liés à la gestion des caches dans les systèmes temps-réel ont déjà été mis en évidence [ZBR07] et des protections ont été proposées notamment en authentifiant et chiffrant les données [LAEJ11]. Des faiblesses concernant la confidentialité ont aussi été découvertes. Par exemple, des études montrent qu’il est possible de retrouver des clés secrètes cryptographiques en utilisant les caches [Aci07a, OST06, Aci06, Bon06, Aci07b, Per05, Ber05] ou le mécanisme de prédiction de branches BTB [ASK07]. La figure 2.1 illustre la hiérarchie des caches présents dans un système utilisant 4 cœurs. Cœur 1 Cœur 2 Cœur 3 Cœur 4 Cache Instruct. Cache Données Cache Instruct. Cache Données Cache Instruct. Cache Données Cache Instruct. Cache Données Cache unifié Cache Cache DRAM DRAM L1 L2 L3 Fig. 2.1 – Hiérarchie des caches (architecture Harvard). Des attaques peuvent aussi essayer de provoquer un arrêt inopiné du processeur, en le faisant exécuter des instructions non-définies ou non-documentées. Si un code malveillant est capable d’envoyer des instructions non-documentées au processeur, le comportement de ce dernier devient imprévisible. Cela peut provoquer, par exemple, le basculement du processeur dans un mode spécial (tel que un mode de maintenance) dont bénéficie automatiquement le code malveillant qui s’exécute. Il peut ainsi acquérir de nouveaux privilèges associés à ce mode. Une telle attaque peut provoquer un Déni-de-Service20 (DoS). Par exemple, comme décrit dans [SPL95], les processeurs x86 peuvent avoir des comportements imprévisibles : les auteurs ont identifié 102 vulnérabilités potentielles affectant des versions différentes des processeurs 80x86. Il a d’ailleurs été montré que certains processeurs de la famille x86 disposaient d’instructions non documentés, c’est- 20Denial-Of-Service. 37à-dire pour lesquels on ne connaît pas le comportement du processeur [Duf07]. Tenter d’exécuter ces instructions peut donc provoquer des comportements totalement imprévus et peut mener à la défaillance du système reposant sur ce processeur. Ainsi, des programmes tels que Crashme21 générant un flot d’instructions aléatoires, ont déjà montré leur efficacité sur différents types d’architecture. 2.1.2 Attaques ciblant la gestion de la mémoire Les attaques ciblant la mémoire correspondent à des attaques qui visent à modifier certaines régions de mémoire du calculateur. Le terme “mémoire” est à considérer au sens large : il inclut la mémoire centrale (RAM), mais aussi l’environnement d’exécution du processeur (tels que les registres par exemple) et les régions de mémoires incluses dans les contrôleurs d’entrées/sorties. Ces attaques peuvent être perpétrées depuis un programme s’exécutant sur le processeur en exploitant une vulnérabilité logicielle, mais aussi depuis un périphérique malveillant, abusant les mécanismes d’entrées/sorties tels que les accès directs à la mémoire (DMA ou Direct Memory Access). 2.1.2.1 Accès à la mémoire depuis le processeur La façon la plus directe d’accéder à la mémoire consiste à utiliser le processeur. Normalement, ces accès sont limités à la mémoire attribuée au processus en cours d’exé- cution. Ces privilèges peuvent être étendus grâce à certaines fonctionnalités des systèmes d’exploitation. Par exemple, sous Linux, il est possible d’accéder à la mémoire du système d’exploitation au travers de l’utilisation des fichiers /dev/mem ou /dev/kmem ou au travers de certaines fonctionnalités matérielles. Ainsi Joanna Rutkowska, dans [RW09], a montré que le mode SMM (System Management Mode) des processeurs Intel peut être détourné pour obtenir un accès direct à toute la mémoire. L’accès à la mémoire depuis le processeur peut être également réalisé en exploitant des vulnérabilités (telles que les débordements de tampons, les chaînes de formats, etc.), qui peuvent affecter tout type de composant logiciel (applications, système d’exploitation, gestionnaire de machines virtuelles). Des exemples de telles vulnérabilités ont déjà été recensés sur des systèmes tels que Windows [CC13], Mac [Art14] et Linux [Aed12], en particulier pour les plateformes x86. Ces vulnérabilités sont dûes à un manque de rigueur dans le codage des applications, en particulier l’absence de tests aux valeurs limites et l’absence de vérification lors d’allocation ou libération de mémoire. Les conséquences de l’exploitation de ces vulnérabilités peuvent être sérieuses puisqu’elles peuvent permettre à l’attaquant d’exécuter du code sur la machine cible, avec différents niveaux de privilège, en fonction du logiciel vulnérable exploité. En particulier, si une vulnérabilité de ce genre est présente non seulement dans les couches applicatives mais au sein du noyau du système lui-même (ce qui reste possible malgré le niveau de criticité du noyau), son exploitation permet alors à un attaquant d’exécuter du logiciel malveillant avec les privilèges du noyau, ce qui rend ces attaques particulièrement graves. 21http://people.delphiforums.com/gjc/crashme.html 382.1.2.2 Accès à la mémoire par les entrées/sorties L’accès à la mémoire peut être réalisé par le mécanisme d’accès direct à la mémoire (DMA) piloté par des contrôleurs d’entrées/sorties. Ceux-ci permettent d’accéder à la mémoire centrale en lecture et en écriture mais aussi aux mémoires internes et registres d’autres contrôleurs (ces attaques sont appelées attaques peer-to-peer). Ces dernières attaques sont particulièrement difficiles à détecter dans la mesure où elles ne nécessitent aucun transfert de données dans la mémoire principale. Cependant, ce type d’attaque n’est pas réalisable sur tous les chipsets22 actuels [LSLND10]. Les accès DMA peuvent être divisés en deux catégories, selon que le processeur intervient ou pas dans la réalisation de l’accès. Si l’accès est initié par le périphérique lui-même, on parle de périphérique disposant d’un accès bus master. Ces périphériques, par exemple les périphériques FireWire, peuvent alors prendre le contrôle du bus et réaliser des transferts de données sans aucune intervention du processeur. Ces attaques sont donc particulièrement difficiles à détecter. A l’opposé, si l’accès à la mémoire est contrôlé par le processeur, le logiciel malveillant qui réalise cet accès doit nécessairement s’exécuter sur le processeur, ou au moins doit posséder un programme complice s’exécutant sur le processeur. Les attaques DMA ont montré leur efficacité pour contourner les mécanismes de protection mémoire implémentés par un système d’exploitation. Loïc Duflot a montré par exemple qu’un code malveillant avec des privilèges réduits peut initier des transferts DMA dans les contrôleurs USB UCI [Duf07] de façon à obtenir les mêmes privilèges que ceux du noyau. M. Dornseif [Dor04] a ainsi montré comment un périphérique FireWire peut accéder à la totalité de la mémoire par l’intermédiaire du contrôleur FireWire connecté sur une machine Linux, Mac ou BSD. A. Boileau [Boi06] a poursuivi ces travaux sur les systèmes Windows et a montré qu’il pouvait contourner le mécanisme d’identification de connexion grâce à un tranfert DMA depuis un périphérique FireWire simplement connecté à la machine. D’après D. Maynor [May05], les contrôleurs USB On-The-Go présenteraient les mêmes caractéristiques et pourraient être abusés par des périphériques malveillants tentant d’exécuter ce même type de transfert DMA. Enfin, L. Duflot [DLM09] a montré qu’en exploitant à distance une vulnérabilité dans le firmware d’un contrôleur réseau, il est possible de lui faire réaliser des accès DMA de façon à obtenir un accès administrateur à distance. Les attaques visant la mémoire, qu’elles soient menées depuis le processeur ou depuis des contrôleurs d’entrées/sorties malveillants, peuvent être classifiées, selon leur cible : les composants logiciels (applications, système d’exploitation, hyperviseur), le processeur lui-même et son environnement d’exécution (par exemple ses registres) ou même les mémoires ou registres internes des contrôleurs d’entrées/sorties. Nous présentons briè- vement chacune de ces classes dans les sous-sections suivantes. 22Le chipset est un ensemble de puces électroniques chargé d’interconnecter les processeurs à d’autres composants matériels tels que les mémoires, les cartes graphiques, les cartes réseau, les contrôleurs de disque, etc. 392.1.2.3 Attaques ciblant les applications Un attaquant peut corrompre la mémoire d’une application particulière s’exécutant sur la machine cible. Cibler la mémoire d’une seule application peut avoir l’avantage d’être relativement difficile à détecter et éradiquer. De telles attaques sont en général le résultat d’un débordement de tampon. Dans le contexte avionique, on peut par exemple penser à une tâche de faible criticité qui veut provoquer la défaillance d’une application critique s’exécutant sur la même plateforme, à l’aide de ce type de corruption mémoire. Elle peut aussi modifier le comportement de l’application critique, pour la faire entrer dans une boucle infinie par exemple. De telles attaques peuvent permettre aussi de contourner des mécanismes de protection comme des systèmes d’authentification : l’application non critique peut essayer de désactiver les contrôles réalisés par l’application critique en modifiant son espace mémoire. 2.1.2.4 Attaques ciblant le système d’exploitation Les attaques en mémoire peuvent cibler l’espace mémoire du noyau du système d’exploitation. Corrompre un noyau de système d’exploitation est bien sûr particulièrement intéressant pour un attaquant puisque cela signifie potentiellement corrompre toutes les applications s’exécutant sur ce noyau. Certains maliciels se spécialisent dans ce type de corruption. Ce sont les rootkits noyau. Ils tentent d’exploiter des vulnérabilités dans le code des noyaux de systèmes d’exploitation de façon à pouvoir y injecter du code malveillant. La corruption d’un noyau ayant de très graves conséquences, il est très important de le protéger efficacement. Cependant, la complexité des noyaux de système d’aujourd’hui fait que cette tâche est particulièrement ardue. De plus, les mécanismes de protection du noyau sont en général implémentés dans le noyau lui-même (qui correspond souvent au mode le plus privilégié du processeur), et peuvent donc être rapidement desactivés par un attaquant ayant réussi à injecter du code dans le noyau. Les attaques visant les noyaux de système sont donc particulièrement redoutables, quels que soient le contexte et le domaine d’application. 2.1.2.5 Attaques ciblant l’hyperviseur Les machines virtuelles sont de plus en plus utilisées aujourd’hui, en particulier depuis l’émergence du Cloud Computing. Les machines virtuelles sont gérées par un gestionnaire de machines virtuelles (ou hyperviseur). Si la virtualisation a des atouts certains, elle peut aussi être la source potentielle de nouveaux problèmes de sécurité. Différents types d’attaques ont déjà été recensées [xen14, vir14, vmw14]. En effet, les machines virtuelles partagent la même architecture physique, puisqu’elles s’exécutent sur la même machine, et l’allocation des ressources qu’elles utilisent est gérée et contrôlée par l’hyperviseur. Une machine virtuelle peut donc profiter de ce partage pour essayer d’accéder ou modifier des données d’une machine virtuelle s’exécutant sur la même machine physique. Plus grave, encore, une machine virtuelle peut tenter de corrompre l’hyperviseur lui-même. La corruption de l’hyperviseur peut entraîner des conséquences graves puisque c’est lui qui 40assure l’isolation spatiale et temporelle des machines virtuelles. On peut donc imaginer des attaques qui pourraient essayer de rompre cette isolation ou qui pourraient corrompre l’hyperviseur de façon à modifier directement la mémoire de certaines machines virtuelles. Des vulnérabilités de ce type ont déjà été identifiées dans certains hyperviseurs [Cou13]. 2.1.2.6 Attaques ciblant l’environnement du processeur L’environnement du processeur peut également être la cible d’attaques. En particulier, il peut être intéressant de modifier les registres d’un processeur et même son micro-code. Certains registres sont très importants, par exemple le registre idtr sur l’architecture x86, qui contient l’adresse de la table des interruptions. Les registres cr0, cr3, cr4 ont aussi des rôles très importants et la corruption de certains bits de ces registres peut totalement changer le fonctionnement de la machine. Loïc Duflot a par exemple montré [DLM09] qu’il est possible d’exécuter du code malveillant dans les gestionnaires des interruptions SMI23 (gestionnaires d’interruptions qui sont exécutés dans le mode SMM24 du processeur). Cette corruption repose sur la modification d’un registre interne particulier du processeur. L’architecture PowerPC de type RISC contient un nombre élevé de registres. Parmi ces registres, le MSR (Machine Status Register) permet de définir le mode de privilège du processeur : utilisateur (non-privilégié) ou superviseur (privilégié). Il convient donc de ne pas le laisser accessible à n’importe quel processus. D’autres registres peuvent aussi être intéressants pour un attaquant : IVOR0-4125 (registres contenant les vecteurs d’interruption), L2CSR0-126 (registres contenant la confi- guration du cache de niveau L2) ou encore MAS0-727 (registres contenant la configuration de la MMU). Toutes les attaques en mémoire sont bien sûr envisageables sur tout type d’architecture, qu’elles soient grand public ou avionique et il faut donc les considérer avec attention. 2.1.3 Attaques ciblant les communications Les communications concernent tous les échanges de données entre deux ou plusieurs entités. Elles peuvent concerner des échanges d’informations entre plusieurs tâches, à l’aide de mécanismes tels que les IPC (Inter Process Communication) par exemple. Elles peuvent aussi représenter les échanges entre différentes machines (ou modules dans le contexte avionique) reliées par un bus de communication (tel que le classique réseau Ethernet dans le cas des PCs grand public ou un bus spécifique tel que le réseau AFDX [ari09] dans le cas des systèmes avioniques). Nous envisageons dans cette section les attaques liées à ces différentes communications. De façon générale, les attaques ciblant les communications peuvent permettre à une tâche de faible criticité de modifier les données 23System Management Interrupt. 24System Management Mode. 25Interrupt Vector Offset Register 0 à 41. 26L2 Configuration Status Register 0 et 1. 27MMU Assist Register 0 à 7. 41d’une tâche plus critique via ces mécanismes de communications. Les attaques peuvent aussi être du type man-in-the-middle. Elles consistent alors à capturer ou modifier des données transmises entre deux entités et elles supposent que l’attaquant ait un accès physique au medium de communication. Si l’on considère plus spécifiquement le cas d’un système embarqué avionique, trois types de communications sont en général utilisés : les communications inter-modules, les communications intra-partition et les communications inter-partitions. La figure 2.2 représente ces communications. Deux partitions sont représentées (P0 et P1), chacun contenant quatre tâches (T0 à T3). inter-partitions T0 T1 T2 T3 P0 T0 T1 T2 T3 P1 Noyau intra-partition inter-modules Fig. 2.2 – Les différents types de communications. Dans l’architecture avionique de type IMA, la communication inter-modules est le plus souvent réalisée aujourd’hui en utilisant le réseau AFDX. Ce réseau est déterministe et garantit l’absence de perte de paquets. Tous les événements d’émission et réception de paquets AFDX sont préparés et configurés statiquement avant la compilation. Il n’est donc a priori pas possible de les modifier après avoir démarré les applications. En revanche, chaque partition qui émet des données, construit pendant l’exécution la payload correspondant à chaque émission. Une application malveillante peut donc tenter de fabriquer une payload d’une taille bien supérieure à la taille qu’elle indique au driver AFDX, de façon à provoquer un débordement de buffer dans la zone où cette payload est recopiée, par exemple. Par ailleurs, une partition malveillante peut aussi tenter de se faire passer pour une autre lors d’émission de paquets. Si les méta-données associées à une communication AFDX sont accessibles en écriture à chaque application, une application malveillante peut intentionnellement modifier l’identité de l’émetteur pour se faire passer pour une autre partition. Enfin, un attaquant peut également essayer d’intercepter les communications (attaque de type man-in-the-middle) afin de capturer ou modifier les données. Cette attaque est très difficile à réaliser car elle suppose que l’attaquant ait un accès physique au bus AFDX ou qu’il puisse modifier la configuration des switchs AFDX, ce qui est très peu probable et qui ne constitue donc pas une hypothèse que nous considérons dans le cadre de notre étude. 42La communication inter-partitions est réalisée, toujours selon l’ARINC 653, en utilisant des messages entre partitions. Un message est un bloc de données avec une longueur finie et il est envoyé de façon périodique ou apériodique. Une partition malveillante peut tenter d’envoyer des valeurs erronées dans un message bien formé dans le but de modi- fier le comportement de la partition qui va recevoir ces valeurs. Cette attaque est plus intéressante si la partition qui reçoit ces messages est une partition critique. Elle peut également tenter d’envoyer des données malformées, par exemple en positionnant une fausse taille de message et en espérant provoquer un débordement de tampon dans la partition qui reçoit ce message. Enfin, la communication intra-partition est utilisée par les processus pour qu’ils communiquent entre eux, au sein d’une même partition. Un processus est une tâche exécutée dans une partition. Deux mécanismes sont décrits dans l’API ARINC 653 pour ces communications intra-partition : les buffers et les blackboards. Un buffer permet de créer une file de messages en ordre FIFO (First In First Out). Une tâche malveillante pourrait abuser de ce mécanisme en envoyant un grand nombre de messages pour saturer la mé- moire avec une file de messages trop grande ou alors en envoyant des messages de taille très importante, et ainsi perturber le fonctionnement correct des autres processus de la partition. Le blackboard est lui utilisé pour garder les messages jusqu’à ce qu’ils soient supprimés ou réécrits par d’autres messages. Une tâche malveillante peut facilement modifier ou supprimer les messages qui n’ont pas été écrits par elle car la zone de mémoire allouée doit être accessible à toutes les tâches de la partition qui communiquent par ce moyen. Ce mécanisme ne fonctionne que si toutes les tâches se font confiance. Ce type de corruption est cependant très limité pour un attaquant car il ne peut provoquer la défaillance que de la partition dans laquelle il a inséré une tâche malveillante. L’intérêt de l’attaquant est bien sûr plutôt de corrompre une tâche d’une autre partition ou le noyau du système lui-même. 2.1.4 Attaques ciblant la gestion du temps Pour cadencer les différentes opérations exécutées sur un calculateur, plusieurs horloges sont disponibles. On peut citer notamment dans les architectures récentes : la Real Time Clock (RTC), les Programmable Interval Timers (PIT), les Time Stamp Counters (TSC), les High Precision Event Timer (HPET). Pour satisfaire la demande des développeurs de logiciels en ce qui concerne la précision dans la mesure du temps, ces horloges sont de plus en plus performantes. Par exemple, la puce PIT défini en 1981, manipule un compteur 16 bits à une fréquence de 1.2 MHz tandis que les nouvelles versions des puces HPET manipulent un compteur de 64 bits à une fréquence de 10 MHz. Ces puces peuvent être configurées en deux modes différents : le mode one-shot ou le mode périodique. Dans le mode one-shot, la puce exécute une interruption une seule fois quand son compteur principal atteint une valeur spécifique stockée dans un registre. Dans le mode périodique, la puce exécute une interruption à des intervalles spécifiés. Un attaquant peut donc tenter de corrompre ces horloges en modifiant les valeurs de registres de configuration associés. La corruption de ces horloges peut avoir un impact direct sur l’exécution de tâches critiques qui alors ne sont plus en mesure de respecter 43leurs contraintes temps-réels, ce qui peut avoir de graves conséquences. La configuration des horloges et des interruptions est généralement modifiable uniquement par une entité avec des privilèges élevés (comme le noyau) donc seule une élévation de privilèges depuis une partition utilisateur quelconque peut donner la possibilité de corrompre les registres des horloges. Cependant, un autre facteur peut venir perturber les échéances temps réel d’une application. Il s’agit de la génération d’interruption. Lorsqu’une interruption est générée pendant l’exécution d’une application, le noyau prend la main et exécute la routine de traitement associée à cette interruption. Par exemple, la figure 2.3 représente la conséquence d’une interruption sur une partition. Noyau Partition Compteur horloge interruption noyau générée par une instruction t t t t1 t2 compteur = 300µs partie de la partition non-exécutée Fig. 2.3 – Exemple d’une partition de 300 microsecondes. Dans cette figure, une partition doit s’exécuter en 300 microsecondes. Une interruption survient avant la fin et le noyau prend le relais pour la traiter. A la fin du traitement de l’interruption, la main est redonnée à la partition. Si le noyau met trop de temps à traiter l’interruption, alors la partition n’aura pas le temps de s’exécuter entièrement. Le compteur de l’horloge décrémentera jusqu’à atteindre zéro pour changer de partition, même si la partition courante n’a pas terminé son exécution. La conséquence est la suivante : une partie de la partition n’est pas exécutée (représentée par la partie foncée sur le schéma). Il est donc important d’inclure parmi les attaques qui ciblent la gestion du temps, celles qui peuvent tirer profit de la gestion des interruptions. Nous y reviendrons plus en détails dans le prochain chapitre. 2.1.5 Attaques ciblant la gestion des processus Nous appelons “gestion des processus” la création, la modification et la suppression des processus et des threads. Pour créer un processus, des privilèges sont requis puisque des appels-systèmes sont nécessaires. Si un programme malveillant a la possibilité de créer des processus, il peut consommer des ressources CPU non-nécessaires menant à un déni-de-service (DoS). Une telle attaque peut être réalisée en inondant le système 44d’exploitation avec des requêtes pour ralentir, voire stopper le système (en créant un nombre important de processus à l’aide d’une fork bomb 28 par exemple). Générer un deadlock est aussi un bon moyen pour un attaquant de causer un DoS. Un programme malveillant peut abuser les mécanismes de synchronisation des processus pour provoquer un blocage (deadlock) en monopolisant une ressource (typiquement, gardée par un sémaphore) requise par un processus légitime. 2.1.6 Attaques ciblant l’ordonnancement Les systèmes d’exploitation modernes ont la capacité d’exécuter des processus multiples en même temps sur le même processeur. Ces systèmes d’exploitation sont appelés “systèmes d’exploitation multi-tâches”. L’ordonnanceur qui organise l’exécution des processus en fonctionnement décide quand le processeur doit exécuter le processus et pour combien de temps. Quand le slot de temps dédié à l’exécution d’un processus expire, l’ordonnanceur donne automatiquement la main au prochain processus. Typiquement, pendant le démarrage du système, le noyau met en place une horloge pour activer pé- riodiquement l’ordonnanceur. La gestion efficace des ressources par l’ordonnanceur est cruciale dans ce contexte. Si un processus est interrompu alors qu’il utilise une ressource, l’ordonnanceur ne doit pas donner la main à un autre processus qui pourrait utiliser la même ressource. Cette situation doit être évitée pour empêcher les deadlocks. Dans ce cadre, un attaquant peut tenter de corrompre l’ordonnancement en modifiant la configuration de l’horloge dans la zone de mémoire correspondante. Le résultat d’une telle attaque serait catastrophique car les contraintes temps-réel ne seraient alors pas respectées. 2.1.7 Attaques ciblant les mécanismes cryptographiques Les mécanismes cryptographiques peuvent aussi être vulnérables à des attaques. Des algorithmes peuvent ainsi contenir des défauts découverts plusieurs années après leur développement, qui peuvent être exploités grâce à l’amélioration de la puissance de calcul disponible (par exemple, les collisions MD5 ont été découvertes en 2004 [WFLH04] alors que l’algorithme existe depuis 1991) et même si les algorithmes cryptographiques sont prouvés pour être corrects, leurs implémentations peuvent contenir des bugs ou des contournements qui pourraient être exploités par des attaquants. L’analyse par canauxcachés est un exemple d’une telle exploitation [KJJ99]. La consommation de courant, les analyses des temps [Koc96] ou même l’écoute des composants [GST13] peuvent permettre de retrouver des clés secrètes RSA ou AES. Cependant, ces attaques ne sont réalisables qu’avec un accès physique au système et avec un matériel important pour réaliser toutes les mesures nécessaires. Par exemple, une clé RSA peut être reconstruite en utilisant seulement 27% de ces bits en mémoire [HS09]. Les attaques sur les mécanismes de cryptographie dépendent grandement de la gestion de la mémoire (voir sous-section 2.1.2) car si une “fuite” de mémoire est présente, des informations sur la clé secrète peuvent être divulguées, et ainsi compromettre la sécurité du système complet. 28Processus créés dans une boucle infinie, menant à l’épuisement des ressources du système. 452.1.8 Attaques ciblant les fonctions ancillaires Les fonctions ancillaires correspondent à la gestion de l’alimentation, de l’overclocking, du contrôle de température, etc. Dans les processeurs x86, ces fonctions sont supportées par le SMM (System Management Mode). Ces dernières années, des vulnérabilités ont été découvertes dans ce mode. Un attaquant peut exploiter ces vulnérabilités pour exécuter du code arbitraire dans un mode privilégié [ESZ08, DLM09]. Le mode SMM est un mode 16 bits utilisé pour le contrôle de la carte mère et la gestion de l’alimentation. Seule une SMI (System Management Interrupt) peut faire entrer le processeur dans le mode SMM, ces SMIs sont générés par le chipset. Mais n’importe quel contrôleur avec les privilèges d’entrées/sorties peut générer ces SMIs. A partir de cette zone SMM, il est possible d’obtenir des privilèges élevés, d’utiliser un rootkit ou encore de contourner des restrictions de démarrage sûrs (late launch restrictions) [DLM09]. 2.1.9 Conclusion Nous avons, dans cette section, essayé de lister exhaustivement les attaques pouvant cibler les fonctionnalités de base d’un calculateur avionique. Comme nous l’avons explicité au début de ce chapitre, cette classification concernant les fonctionnalités de base est tirée en grande partie des attaques que l’on peut rencontrer sur les systèmes informatiques “grand public”. La section suivante concerne des attaques ciblant des mécanismes spécifiques qui sont présents dans la plupart des calculateurs embarqués exécutant des systèmes critiques, pour des raisons de sûreté de fonctionnement : les mécanismes de tolérance aux fautes. 2.2 Les attaques ciblant les mécanismes de tolérance aux fautes Les systèmes avioniques, comme bon nombre de systèmes embarqués critiques, intègrent des mécanismes de tolérance aux fautes pour être capables de continuer à fonctionner correctement même si des défaillances surviennent. La figure 2.4 représente ces différents mécanismes de tolérance aux fautes. Ces principes font références aux concepts de bases présentés dans [ALRL04]. La chaîne fondamentale des entraves à la sûreté de fonctionnement est la suivante : ... ⇒ Faute ⇒ Erreur ⇒ Défaillance ⇒ ... La tolérance aux fautes vise à éviter l’occurence de défaillances. Elle est mise en œuvre par la détection des erreurs et le rétablissement du système. Le rétablissement du système est lui-même mis en œuvre par le traitement d’erreurs et le traitement de fautes. Le traitement d’erreurs a pour but l’élimination des erreurs de l’état du système avant l’occurrence de défaillance. Le traitement de fautes a pour but d’empêcher une 46Traitement d'erreurs Traitement de fautes Détection d'erreurs Diagnostic Recouvrement Isolation Reconfiguration Reprise Poursuite Compensation Mécanismes de tolérance aux fautes Diagnostic Réinitialisation Fig. 2.4 – Schéma des différents traitements de la tolérance aux fautes. nouvelle activation de faute dans le système. Le traitement d’erreurs est en général la première étape du rétablissement du système, le traitement des fautes en est la seconde. Le traitement d’erreurs peut être mis en œuvre par : • la détection d’erreur, qui permet à un état erroné d’être identifié comme tel ; • le diagnostic d’erreur, qui permet l’évaluation des dommages par une erreur dé- tectée ou par des erreurs propagées avant la détection ; • le recouvrement d’erreur, où un état sans erreur est substitué à un état erroné. Les techniques de détections d’erreur peuvent être classifiées en détections concomitantes, si elles sont réalisées pendant l’exécution du service normal, et en détections préemptives, si elles sont effectuées lors de la suspension du service (par exemple, en phase d’initialisation). La détection préemptive vise à révéler l’éventuelle présence d’erreurs latentes ou des fautes dormantes. Concernant le recouvrement d’erreurs, trois techniques sont classiquement utilisées : • la reprise, où la transformation de l’état erroné consiste à ramener le système à un état antérieur sain avant l’occurrence d’erreur ; ceci implique la sauvegarde de points de reprise, qui sont des sauvegardes régulières dans le temps, de l’état du système, dans lequel le système peut ensuite être restauré ; • la poursuite, où la transformation de l’état erroné consiste à trouver un nouvel état dans lequel le système peut continuer à opérer (éventuellement en mode dégradé) ; • la compensation, où l’état erroné contient suffisamment de redondances pour permettre sa transformation en un état sans erreur. La reprise est en général inapplicable à un système avionique puisqu’il est impossible de ramener le système complet (incluant notamment certaines données réelles comme la position ou la vitesse de l’appareil, le niveau de carburant disponible, etc.) dans un 47état sain précédent. En revanche, les systèmes avioniques appliquent en général une combinaison de techniques de poursuite et de compensation. La seconde étape de rétablissement de système est le traitement de fautes. Il vise à empêcher de nouvelles activations de fautes. Le traitement de fautes comprend plusieurs étapes : le diagnostic, l’isolation, la reconfiguration et la réinitialisation. Le diagnostic identifie et enregistre les causes des erreurs de façon à en préciser le type et la localisation précise. L’isolation consiste à exclure de façon logicielle ou matérielle, les composants fautifs de la délivrance du service (en cela, cette étape rend les fautes dormantes). La reconfiguration peut soit provoquer l’exécution du service sur un composant supplé- mentaire à disposition, soit répartir les tâches sur l’ensemble des composants disponibles non fautifs. La réinitialisation vérifie et met à jour la nouvelle configuration, et enregistre cette nouvelle configuration dans des tables du système. Tous ces mécanismes de tolérance aux fautes peuvent être des cibles pour un attaquant. Par exemple, si l’attaquant est capable d’empêcher la détection d’erreurs, il peut en conséquence empêcher le recouvrement du système en cas d’erreur et ainsi mener le système à défaillance. S’il peut corrompre le diagnostic d’erreur, il peut également empêcher la reconfiguration du système. La corruption d’un recouvrement d’erreur peut provoquer la substitution d’un état d’erreur bien choisi à l’état courant. De la même façon, le diagnostic de fautes peut être compromis pour identifier un composant correct comme défaillant ou un composant fautif comme correct. Une passivation de fautes corrompue peut désactiver un composant correct à la place du composant défaillant, et une reconfiguration défaillante peut modifier la structure du système afin que les tâches critiques ne soient plus exécutées. Dans les sections suivantes, nous envisageons plus en détail les attaques pouvant cibler le traitement des erreurs (en particulier, les étapes de détection des erreurs et recouvrement des erreurs) et le traitement des fautes. 2.2.1 Détection d’erreurs Du point de vue d’un attaquant, les mécanismes de détection d’erreur peuvent être une cible intéressante. En effet, si un attaquant est capable d’empêcher la détection d’erreur, alors aucun recouvrement ne peut être effectué, ce qui peut causer une dé- faillance du système. Inversement, si un attaquant provoque la détection d’erreur trop fréquemment, il peut déclencher une procédure de recouvrement incorrecte, ce qui peut provoquer l’épuisement des unités de rechange et ainsi rendre inefficace les mécanismes de tolérance aux fautes. Les moyens utilisés pour la détection d’erreurs peuvent varier en fonction du niveau où la vérification est effectuée et le compromis coût/efficacité sélectionné. Les formes les plus populaires sont les suivantes : • Les codes détecteur d’erreur ; • La duplication et comparaison ; • Les contrôles temporels et d’exécution ; • Les contrôles de vraisemblance ; • Les contrôles de données structurées. 48Nous décrivons dans la suite trois d’entre elles : les contrôles de vraisemblance, la duplication et comparaison et les contrôles temporels et d’exécution car ils sont largement utilisés dans l’industrie. 2.2.1.1 Contrôle de vraisemblance L’implémentation de mécanismes de contrôle de vraisemblance nécessite peu de coûts additionnels, en comparaison au coût des éléments fonctionnels du système. Beaucoup de contrôles peuvent être implémentés pour détecter si les erreurs surviennent depuis une large sélection de fautes, mais leur couverture est généralement limitée. Ce mécanisme peut être utilisé par exemple pour détecter les erreurs de valeurs, les violations des mé- canismes de protection de la mémoire ou pour vérifier la conformité des entrées/sorties. Ces contrôles sont relativement faciles à faire échouer sous réserve de connaître la façon dont le système se comporte avec des données non conformes. Envoyer des données aléatoires (technique de fuzzing) permet de tester si les contrôles de vraisemblance peuvent résister à tout type de données d’entrée. Si des erreurs ne sont pas détectées alors le système peut continuer son exécution en engendrant de possibles défaillances. 2.2.1.2 Duplication et comparaison La duplication et comparaison est un mécanisme de détection d’erreurs largement utilisé, malgré un coût matériel important, car il est simple à mettre en place. La mise en œuvre repose sur l’utilisation d’au moins deux unités redondantes qui sont indépendantes du point de vue de la création et de l’activation des fautes : il est nécessaire de s’assurer que soit les fautes sont crées ou activées indépendamment dans les unités redondantes, soit que, si une même faute provoque des erreurs dans chaque unité, ces erreurs sont différentes. Si on considère les fautes physiques internes, les unités peuvent être identiques dans la mesure où l’on peut supposer que les compsants matériels défaillent de manière différente dans chaque unité. Dans le cas de fautes physiques externes, il faut éviter des fautes de mode commun en isolant physiquement les deux unités ou décalant dans le temps le traitement sur les deux unités. Face à la duplication et comparaison, un attaquant peut tenter de corrompre chaque unité de façon à ce que la détection soit inefficace. L’éloigement géographiquement des unités peut résoudre en partie le problème lorsqu’il s’agit d’attaques physiques mais si l’on considère les attaques logicielles (et donc les fautes de conception du logiciel), il est nécessaire d’avoir recours à la diversification des logiciels et de matériels. En effet, des logiciels et matériels de conception et de mise en œuvre différentes ne sont pas vulnérables aux mêmes attaques par construction. 2.2.1.3 Contrôles temporels et d’exécution Dû à ses coûts très limités, les contrôles temporels par des “chiens de garde” (watchdog timers) sont les plus largement utilisés pour la détection d’erreurs durant l’exécution. Un watchdog peut être utilisé dans différentes situations telles que la détection de la 49défaillance d’un périphérique en contrôlant son temps de réponse (suite à l’envoi d’un signal) qui ne doit pas dépasser une valeur maximale ou la surveillance de l’activité des processeurs. Dans ce dernier cas, le watchdog doit être périodiquement rafraîchi par le processeur. Ainsi, si le comportement du processeur est altéré de sorte que le watchdog n’est plus rafraîchi avant qu’il n’expire, une exception sera levée. Une telle approche peut être utilisée, pour sortir d’une situation de blocage ou d’une boucle infinie, ou pour détecter l’arrêt d’un processeur distant. Une attaque simple sur cet élément consiste à empêcher le signal de revenir à l’émetteur et donc de faire passer un programme ou un périphérique comme défaillant alors qu’il ne l’est pas. Cette technique peut être mise en œuvre par un déni-de-service du programme visé (par exemple, par saturation de requêtes d’appels-systèmes) ce qui engendrera une augmentation du temps processeur ralentissant ainsi fortement le traitement des requêtes et donc le temps de réponse associé. 2.2.2 Recouvrement d’erreurs En concordance avec la détection d’erreurs, le recouvrement d’erreurs est utilisé pour continuer à délivrer le service du système. Trois types de recouvrements peuvent être effectués : la reprise, la poursuite et la compensation. La reprise est le moyen le plus utilisé ; il consiste en la sauvegarde régulière de l’état du système pour permettre de le restaurer si une erreur est détectée. Le système est sauvegardé avec des points de restauration, lesquels peuvent être possiblement corrompus par un attaquant. La corruption de tout ou partie d’un seul point de restauration suffit à mettre en danger le système. Il est donc important de vérifier les privilèges nécessaires à la création et la modification des régions de mémoire dans lesquelles ces points de restauration sont créés. La poursuite constitue une alternative ou une approche complémentaire à la reprise. La poursuite consiste à chercher un nouvel état acceptable pour le système, à partir duquel il sera possible de poursuivre l’exécution du système (éventuellement dans un mode dégradé). Dans le cas où la poursuite est la technique de tolérance aux fautes adoptée par le système, l’attaquant peut faire en sorte de forcer l’utilisation du mode dégradé, en provoquant le plus souvent possible des erreurs. La compensation d’erreur nécessite que l’état du système comporte suffisamment de redondance pour permettre en dépit des erreurs pouvant l’affecter, sa transformation en un état exempt d’erreur. Un exemple typique est celui des architectures à base de vote majoritaire où la présence d’erreurs n’aura aucune conséquence pour le système. Un exemple typique de la détection et compensation d’erreur est l’utilisation des composants autotestables exécutant en redondance active le même traitement ; en cas de défaillance de l’un d’entre eux, il est déconnecté et le traitement se poursuit sans interruption sur les autres. La compensation, dans ce cas, se limite à une commutation éventuelle de composants. C’est sur ce principe que fonctionne le système de gestion de commandes de vol des Airbus 320/330/340. Lorque la compensation d’erreurs est utilisée, et donc de la redondance, un attaquant peut faire en sorte de provoquer des erreurs dans chacune des unités redondantes, de façon à faire en sorte que la compensation ne soit plus possible 50puisqu’il ne subsiste plus d’unité considérée correcte dans le système. 2.2.3 Traitement de fautes Le traitement de fautes a pour but d’empêcher les fautes d’être activées une nouvelle fois. Le traitement de fautes consiste en : diagnostic, isolation, reconfiguration et réinitialisation. Toutes ces techniques peuvent être la cible d’attaques. Par exemple, des attaques peuvent faire en sorte de faire échouer le diagnostic de façon à diagnostiquer à tort un composant non-défectueux comme défectueux. Un attaquant peut de même tenter de provoquer l’isolation d’un composant non-défectueux ou provoquer la poursuite du système avec un composant défectueux. Il peut également provoquer à tort la mise à jour d’une nouvelle configuration du système. Toutes ces attaques peuvent amener le système à défaillance. En effet, le diagnostic à tort d’un composant non-défectueux comme défectueux permet d’éliminer des composants valides du système et donc à terme de forcer le système à passer dans un mode dégradé. De même, si l’attaquant parvient à provoquer l’isolation de tous les composants non défectueux, alors il peut provoquer une exécution totalement erronée du système. Enfin, l’attaquant peut également cibler le mécanisme de mise à jour de la configuration. S’il parvient à mettre à jour la configuration de façon à activer une nouvelle configuration erronée, il peut amener le système à défaillir. 2.2.3.1 Isolation de fautes Pour isoler une faute, le composant concerné est supprimé mais dans un scénario malveillant, l’attaquant peut essayer de provoquer volontairement une faute pour isoler un composant sain. Il peut ainsi provoquer la passivation de toutes les unités du système et provoquer son arrêt. L’attaquant peut aussi directement cibler le mécanisme d’isolation de fautes de façon à ne pas isoler un composant lorsqu’il est défectueux. Ces attaques peuvent mener le système à se comporter d’une façon totalement arbitraire et ainsi provoquer sa défaillance. Une autre attaque possible consiste à modifier le mécanisme d’isolation de fautes pour faire en sorte que le mécanisme détecte tous les composants comme défectueux (ce qui aura comme conséquence de forcer l’isolation pour tous les composants) ou de faire en sorte que ce mécanisme ne détecte aucun composant défectueux (ce qui aura pour conséquence de laisser les défaillances se produire suite à un état incohérent du système). 2.2.3.2 Reconfiguration La reconfiguration consiste à modifier la configuration du système (éventuellement dans un mode dégradé) pour le réactiver dans un état sans faute. Un attaquant peut tirer avantage de cette reconfiguration en modifiant le processus qui effectue la reconfiguration pour établir sa propre reconfiguration. Une reconfiguration peut impliquer l’abandon de certaines tâches ou la ré-allocation de certaines tâches aux composants restants pour délivrer un service acceptable. Cependant, le service délivré après reconfiguration peut 51être en mode dégradé, si la reconfiguration est compromise. La configuration peut être modifiée si par exemple, les accès en écriture à la mémoire où est stockée cette configuration sont trop permissifs. L’attaquant peut alors provoquer l’arrêt de toutes les tâches ou empêcher la ré-allocation de certaines tâches. 2.3 Contexte et hypothèses d’attaques Dans la section précédente, nous avons classifié les différentes attaques possibles en deux catégories : mécanismes de base et mécanismes de tolérance aux fautes. Dans cette section, nous proposons d’exposer l’ensemble des hypothèses et contraintes qui caractérisent l’environnement dans lequel nous effectuons nos expérimentations d’attaques. En particulier, nous allons exposer les hypothèses d’attaques mais aussi les conditions particulières dans lesquelles nous allons étudier la faisabilité de ces attaques. Un système critique avionique répond à un certain nombre de contraintes particulières et nous devons en tenir compte pour établir les hypothèses. Dans la première sous-section, nous détaillons les types d’attaquants et les hypothèses d’attaques que nous considérons dans cette étude. Dans la sous-section suivante, nous détaillons le type d’application malveillante que nous avons utilisé pour cette étude, sa configuration et la façon dont nous l’avons modifiée. 2.3.1 Attaquants Notre étude se focalise sur les attaques logicielles. En effet, nous considérons que des personnes malveillantes n’ont pas d’accès physique au système. Si un tel accès physique est donné, il est plus simple, pour provoquer des défaillances, de débrancher des cartes ou des câbles plutôt qu’avoir recours à des applications malveillantes. Par exemple, le débranchement des câbles AFDX interrompt les communications entre modules, ce qui provoque des erreurs à répétition pour finalement probablement mettre en fonctionnement les unités redondantes si elles existent ou simplement arrêter les modules qui ne peuvent plus communiquer. Nous considérons donc les trois hypothèses suivantes : • L’attaquant n’a pas d’accès physique au système en exécution ; • Les pilotes et l’équipage sont considérés comme des personnes de confiance, ainsi que tout le personnel de maintenance ; • Les passagers, les utilisateurs de réseaux publics et les développeurs COTS sont considérés comme des personnes potentiellement malveillantes ; Nous donnons dans la suite quelques informations sur cette classification des personnes potentiellement malveillantes ou non ainsi que sur leur liberté d’actions s’ils sont malveillants. Précisons que ces hypothèses d’attaques peuvent sembler peu probables, mais, dans le cas des analyses de sécurité et en accord avec Airbus, nous avons volontairement opté pour des hypothèses relativement pessimistes. Les passagers sont considérés comme potentiellement malveillants. En effet, les passagers ont la possibilité d’embarquer à bord de l’avion leur ordinateur portable, leur 52tablette, leur smartphone, etc. Ils peuvent ainsi, à l’aide de ces matériels connectés, tenter de se connecter au réseau de l’avion et tenter ensuite de progresser dans ce réseau de façon à accroître leurs privilèges et ainsi essayer d’atteindre des calculateurs connectés de façon plus ou moins directe au système de vol. Par ailleurs, les passagers, même bienveillants, peuvent posséder des logiciels infectés sur leur machine personnelle, qui peuvent réaliser ce type d’attaque à leur insu. Il est même possible que cette injection survienne directement lorsque le passager est dans l’avion. En effet, juste avant la phase de décollage, lorsque l’accès au réseau Internet est encore autorisé pour les passagers, on peut imaginer qu’un internaute malveillant puisse exploiter une vulnérabilité d’un PC portable ou d’une tablette d’un passager, qu’il puisse installer à cet instant précis un logiciel malveillant grâce à cette vulnérabilité et qu’il puisse tenter ensuite de mener une attaque à partir de cet équipement corrompu. Enfin, on peut même imaginer ce type d’attaque pendant le vol, puisque certaines compagnies autorisent d’ores et déjà l’utilisation du réseau Internet en vol. Certaines personnes ont des accès privilégiés à l’avion en dehors des périodes de vol pour la maintenance de l’avion par exemple, le ravitaillement, mais aussi pour l’installation d’équipements dans l’appareil, notamment dans la cabine. Ces opérateurs sont considérés comme des personnes de confiance et ne sont donc pas susceptibles d’installer volontairement des applications malveillantes lors de leur accès privilégié à l’avion. Cependant, il est envisagé dans un futur proche d’équiper les opérateurs de maintenance de PC portables personnels qui seront utilisés pour effectuer cette maintenance (qui aujourd’hui est réalisée avec du matériel spécifique). Si ce PC portable peut être par ailleurs utilisé en dehors des phases de maintenance de l’avion, pour un usage personnel (connexion au réseau Internet par exemple), il est alors tout à fait possible qu’il puisse être infecté par un logiciel malveillant. Lorsque ce PC est ensuite connecté au réseau de l’avion lors de la phase de maintenance, le logiciel malveillant peut tenter d’exploiter une vulnérabilité, pour ensuite tenter de se propager sur ce réseau. Même si aujourd’hui, ce type de menace n’est pas envisageable, il peut le devenir dans un futur proche (Airbus a d’ailleurs d’ores et déjà lancé des études sur le sujet pour y faire face [Laa09]). Comme nous l’avons indiqué dans le premier chapitre, l’introduction de logiciels COTS dans les systèmes critiques est de plus en plus envisagé. Sans envisager la malveillance des développeurs de COTS, on peut cependant supposer que ces derniers dé- veloppent leurs applications en ne respectant pas de strictes règles de codage et que par conséquent, leurs logiciels sont susceptibles de contenir des vulnérabilités, qui peuvent être exploitées pour exécuter des attaques. Dans le cas le plus favorable, ces COTS sont utilisés uniquement pour l’implémentation de partitions non critiques (c’est le cas que nous supposons dans cette thèse) mais on peut également imaginer que des COTS puissent être également utilisés dans le développement de logiciels critiques. Par ailleurs, les logiciels COTS ne sont en général pas développés pour le monde embarqué (par exemple vlc29 pour le streaming) et sont donc susceptibles de ne pas correspondre entiè- rement aux besoins des systèmes avioniques. Ces logiciels sont bien sûr testés et évalués du point de vue de la sécurité avant d’être insérés dans l’avion mais il est possible que 29http://www.videolan.org/vlc/ 53malgré tout, étant donné leur complexité, un certain nombre de vulnérabilités subsistent, en particulier dans les couches les plus proches du matériel, et que ces vulnérabilités puissent être exploitées. On peut aussi envisager l’hypothèse qu’un logiciel ou matériel COTS puisse contenir intentionnellement des fonctions malveillantes (une porte dérobée par exemple). 2.3.2 Hypothèse d’attaque : une application non critique malveillante Dans le cadre des expérimentations d’attaques que nous avons menées dans cette thèse et qui font l’objet du chapitre suivant, nous avons fait le choix d’utiliser une application malveillante compatible ARINC 653 déjà installée parmi les autres applications sur un calculateur qui exécute un noyau temps-réel critique. Cette application est non critique et l’objectif est de vérifier si elle peut avoir un impact sur la sécurité d’une application critique ou du noyau système lui-même. La façon dont a pu être installé cette application malveillante n’est pas l’objet de cette thèse mais elle peut faire intervenir les personnes potentiellement malveillantes que nous avons présentées dans la section précédente. L’installation de ce type d’application malveillante, même non critique, est bien sûr très improbable aujourd’hui, compte tenu des mécanismes de protection (physiques et logiques) déjà mis en place dans les avions. Cependant, dans le cadre de cette étude, nous nous plaçons volontairement dans un cadre très pessimiste, où nous supposons qu’elle a pu être installée, et nous nous focalisons sur l’étude des effets potentiels de cette application, afin de mieux s’en protéger. Dans le cadre de nos expérimentations, nous disposons d’un exécutif temps réel expé- rimental, en cours de développement, fourni par Airbus. La configuration du noyau et des applications est réalisée avant la compilation grâce à des fichiers textes qui permettent de générer le code approprié pour le noyau. Cette configuration comprend majoritairement les accès à la mémoire pour chaque partition et le noyau mais également les durées de chaque partition et la durée totale d’un cycle (l’exécution séquentielle de toutes les partitions), les communications inter-partitions si elles existent, le comportement du Health Monitor (HM) pour chaque partition, les appels-système, etc. Pour créer notre application malveillante, nous avons copié le code source en langage C d’une application avionique basique. Nous avons ensuite modifié l’application en langage assembleur pour ne pas dépendre des limitations du langage C par rapport à un langage de bas niveau. Effectivement, un langage de bas niveau peut directement avoir accès à la mémoire et à tous les registres (du mode utilisateur). En ce qui concerne le fonctionnement de l’application malveillante, elle peut réaliser toutes les actions disponibles depuis un mode utilisateur, qui peuvent éventuellement provoquer des erreurs, notamment : • exécuter des instructions privilégiées ; • accéder à des registres spéciaux ; • accéder à des données dans une zone mémoire interdite ; • exécuter des instructions dans une zone mémoire interdite. Le but est d’observer le comportement du noyau lorsque ces tests sont effectués. Si le mécanisme de gestion des erreurs est correctement réalisé alors aucune conséquence ne 54sera constatée. Comme nous le verrons dans le prochain chapitre, nous avons dû instrumenter le noyau pour observer son comportement et celui des applications, notamment pour mesurer les durées d’exécution ainsi que pour contrôler les erreurs provoquées. Conclusion Nous avons détaillé dans ce chapitre une classification de différentes attaques possibles sur les systèmes embarqués, qu’elles ciblent les mécanismes de base (processeur, gestion de la mémoire, communications, gestion du temps, gestion des processus, ordonnancement, cryptographie, fonctions ancillaires) ou qu’elles ciblent les mécanismes de la tolérance aux fautes (mécanismes de traitement d’erreur et mécanismes de traitement de fautes). Nous avons également précisé le contexte de nos expérimentations en listant les hypothèses d’attaques ainsi que le contexte d’exécution de ces attaques. Nous avons ainsi indiqué comment l’application malveillante, que nous utilisons pour lancer des attaques, a été configurée et installée parmi les autres applications. Dans le chapitre suivant, nous décrivons la plateforme d’expérimentation utilisée pour la réalisation de nos attaques, le noyau expérimental, les partitions ainsi que l’environnement de développement. Nous développerons également différentes attaques que nous avons pu mettre en œuvre. 5556Chapitre 3 Mise en œuvre de la méthodologie sur une plateforme IMA expérimentale Introduction Ce chapitre décrit 1) la méthodologie employée pour mettre en œuvre notre plateforme IMA d’expérimentations ainsi que 2) nos expérimentations et leurs résultats. Cette plateforme est composée d’un calculateur, d’une sonde JTAG, de l’IDE Codewarrior et d’un noyau temps-réel expérimental conçu par Airbus. Le noyau est développé selon le standard avionique ARINC-653 ("Avionics Application Software Standard Interface"). Ce standard est une interface pour le partitionnement temporel et spatial des ressources des systèmes embarqués. Les éléments constituant cette plateforme sont détaillés dans la suite de ce chapitre. Dans la section 3.1, nous décrivons le noyau temps-réel expérimental d’Airbus, son fonctionnement et sa configuration. Ensuite, nous détaillons l’architecture de la plateforme matérielle que nous avons utilisée, le P4080, et les fonctionnalités utilisées par le noyau (section 3.2). Dans la section 3.3, nous présentons les composants de la plateforme IMA utilisés. Puis, nous présentons les attaques (ainsi que leurs résultats) ciblant les mécanismes de base, notamment en ce qui concerne la gestion de la mémoire (section 3.4), les communications (section 3.5) et la gestion du temps (section 3.6). Enfin, nous décrivons les attaques (ainsi que leurs résultats) ciblant les mécanismes de tolérance aux fautes (section 3.7). Ces différents travaux ont fait l’objet de publications dans [DADN13] et [DDAN13]. 3.1 Système expérimental d’Airbus : noyau et partitions Le noyau temps-réel expérimental d’Airbus permet d’exécuter des applications en respectant le principe de partitionnement (ARINC 653). Le partitionnement spatial est 57opéré par la MMU et le partitionnement temporel par le MPIC. Les partitions sont exécutées dans l’ordre prévu par la configuration des fichiers comme vu précédemment. Le noyau s’initialise en réalisant les opérations suivantes : • l’activation des permissions de la zone de mémoire (MMU) ; • l’activation du compteur de temps (Time Base) ; • l’initialisation des interruptions (MPIC) ; • l’initialisation des caches. Lorsque l’initialisation du noyau et des partitions est terminée, la première partition est exécutée suivant l’ordre défini précédemment. Cette partition exécute son code pendant quelques microsecondes. Puis, à la fin de sa tranche de temps, la partition suivante prend le relais et ainsi de suite jusqu’à l’arrêt du système. Nous pouvons représenter de façon très simple l’ordonnancement des partitions comme suit : Initialisation du noyau et des partitions Partition 0 Partition 1 Partition 2 Partition 3 Partition 4 Fig. 3.1 – Exemple d’ordonnancement avec 5 partitions. Ensuite, la première partition s’exécute et lorsque sa tranche de temps (time slot) est terminée, le noyau opère un changement de partition qui consiste à sauvegarder le contexte de la partition courante. Pour cela, un changement de contexte (context switching) est réalisé. Nous décrivons cette opération dans la sous-section 3.1.2. Le contexte d’une partition correspond au contenu de plusieurs registres : • GPR (General Purpose Register) : les 32 registres généraux (de 32 bits chacun) ; • FPR (Floating-Point Register) : les 32 registres à virgule flottante (de 64 bits chacun) ; • PC (Program Counter) : l’adresse de la prochaine instruction (32 bits) ; • MSR (Machine State Register) : l’état du processeur (dont les privilèges) (32 bits) ; • LR (Link Register) : l’adresse de destination d’une branche30 (32 bits) ; 30Á noter qu’en langage PowerPC, une “branche” ou un “branchement” correspond à un saut d’une instruction à une autre. 58• CTR (Count Register) : ce compteur est décrémenté et testé pendant l’exécution des instructions de branchement (32 bits) ; • XER (Integer Exception Register) : ce registre permet de connaître des informations sur les opérations d’entiers (retenu, débordement) ainsi que le nombre d’octets transmits par une instruction sur les chaînes de caractères (32 bits) ; • CR (Condition Register) : ce registre contient 8 registres de 4 bits permettant d’utiliser jusqu’à 8 comparaisons d’entiers simultanées (32 bits) ; • FPSCR (Floating-Point Status and Control Register) : ce registre contient des informations d’erreurs sur les nombres à virgules flottantes (64 bits). Un contexte de partition contient donc 416 octets qui sont sauvegardés dans la mé- moire utilisateur de la partition (accessible en lecture/écriture) à chaque fin d’exécution de la tranche de temps de la partition puis restaurés à chaque début de tranche de temps. Á noter que le registre MSR qui permet, en autre, de passer du mode superviseur au mode utilisateur n’est pas restauré depuis la mémoire comme les autres mais défini statiquement (afin d’interdire à la partition ayant un accès sur cette zone de modifier ses privilèges lors de la prochaine restauration de contexte). 3.1.1 Hypothèses concernant la partition malveillante Comme pour les autres applications, les règles de partitionnement spatial et temporel sont appliquées. La partition non critique depuis laquelle nous allons mener nos attaques s’exécute donc périodiquement comme toutes les autres applications, pendant 1.5 millisecondes sur les 5 millisecondes disponibles (durée correspondant à un cycle d’exécution de toutes les partitions). Elle est exécutée en dernière position (7ème position). Pour le partitionnement spatial, nous avons configuré la partition pour utiliser une zone de 1Mo de données en lecture/écriture et 1Mo d’instructions en lecture/exécution et aucun autre accès à la mémoire. Ces zones ne sont pas en conflit avec d’autres zones (les zones ne se chevauchent pas) pour éviter de donner des accès à d’autres applications. Pour notre application non critique malveillante, nous utilisons les mêmes privilèges que les autres applications, à savoir un mode utilisateur qui est restreint sur certaines instructions privilégiées (contrairement au mode superviseur). En ce qui concerne la protection mémoire, elle est assurée par la MMU (Memory Management Unit). Ce composant est situé dans le processeur pour contrôler les accès à la mémoire. Une entrée dans la MMU correspond à une entrée dans une TLB (Translation Lookaside Buffer) qui est une table contenant tous les accès aux zones mémoires configurées. Deux entrées sont créées au minimum, une pour les données et une autre pour les instructions. D’autres entrées sont également utilisées pour les accès du noyau. Comme pour les autres applications, l’application malveillante ne peut accéder ni aux périphé- riques ni au noyau en dehors des mécanismes prévus tel que les appels système. La figure 3.2 représente un exemple d’entrées dans la TLB lorsque les partitions 5 et 6 sont exécutées. Dans cet exemple, la partition 6 a un accès de l’adresse 0x0070_0000 à 0x0080_0000 en lecture et écriture pour la modification des données et un autre accès de 0x0080_0000 à 0x0090_0000 en lecture et exécution pour exécuter les instructions. La partition 5 a un 59Memory Management Unit (TLB) Partition5 de 0x0050_0000 à 0x0060_0000 en rw Partition5 de 0x0060_0000 à 0x0070_0000 en rx Partition6 de 0x0070_0000 à 0x0080_0000 en rw Partition6 de 0x0080_0000 à 0x0090_0000 en rx Noyau de 0x0000_0000 à 0x0030_0000 en rx Noyau de 0x0030_0000 à 0x0050_0000 en rw Fig. 3.2 – Exemple d’entrées dans la TLB avec deux partitions et un noyau. accès de 0x0050_0000 à 0x0060_0000 en lecture et écriture pour les données et un autre accès de 0x0060_0000 à 0x0070_0000 en lecture et exécution pour les instructions. Le noyau a lui aussi un accès pour ses données de 0x0030_0000 à 0x0050_0000 en lecture et écriture et de 0x0000_0000 à 0x0030_0000 en lecture et exécution pour ses instructions. Les accès entre le noyau et les applications peuvent paraître similaires dans la TLB mais le noyau s’exécute lui en mode superviseur alors que les applications s’exécutent en mode utilisateur. Si un accès non autorisé est effectué tel qu’un accès en dehors des limites prévues par ces entrées dans la TLB alors une réaction adaptée doit être mise en œuvre, comme par exemple l’arrêt ou le redémarrage de la partition. 3.1.2 Phases d’exécution d’une partition Une partition comprend deux phases lors de son exécution, la première phase est appelée “phase de préparation”, la seconde est la “phase opérationnelle”. La figure 3.3 représente ces deux phases pour trois partitions P0, P1 et P2. PREPARATION P1 OPERATION P1 90µs (t-90)µs P1 (partition en cours d’exécution) PREPARATION P2 P0 P2 OPERATION P0 OPERATION P2 90µs (t-90)µs PREPARATION P1 90µs (t-90)µs Fig. 3.3 – Les deux phases de trois partitions. La phase de préparation dure 90 microsecondes pour chaque partition et est utilisée par le noyau pour exécuter certaines opérations afin que la prochaine partition fonctionne correctement : 1) sauvegarde du contexte de la partition précédente (celle qui a été exécutée avant P1, il s’agit de P0) ; 2) configuration de la MMU en ajoutant de 60nouvelles entrées dans la TLB pour la prochaine partition (P1) et en supprimant les anciennes ; 3) configuration du prochain Global Timer à la durée de la phase opérationnelle (90 - durée totale d’exécution de la partition) microsecondes (ici, il s’agit de la phase opérationnelle de P1). Cette phase se termine par une mise en attente31. Cette attente permet de s’assurer que la durée d’exécution de la phase de préparation est bien 90µs. Lorsque cette phase est terminée, la seconde phase (la phase opérationnelle) débute par la configuration du Global Timer pour la prochaine tranche de temps (ici, celle de la phase de préparation de P2) puis la restauration du contexte de la nouvelle partition courante (ici, P1). Enfin, la première instruction exécutée de la partition est à l’adresse du registre PC (Program Counter) qui vient d’être restauré. Pour mieux comprendre comment l’interruption est émise lors des changements de partition, la suite de cette sous-section traite des interruptions GT (Global Timer). Lorsqu’une interruption de type Global Timer survient, une fonction du noyau est exécutée pour traiter l’interruption. CCR=BCR non CCR == 0 ? CCR-- Générer interruption GT oui Fig. 3.4 – Fonctionnement d’un Global Timer. Sur le schéma 3.4, deux registres sont utilisés pour les interruptions de type Global Timer : CCR pour le Current Counter Register et BCR pour le Base Counter Register. Le premier contient la valeur actuelle du compteur et le second contient la valeur maximale depuis laquelle le compteur sera décrémenté. Un troisième registre est utilisé, le VPR (Vector/ Priority Register) qui permet de définir la fonction qui sera invoquée lorsque 31Cette mise en attente est, en fait, une boucle infinie en mode utilisateur. 61l’interruption surviendra. L’interruption est donc générée une fois que le compteur atteint la valeur zéro, ce qui conduit à exécuter une fonction du noyau (nk_int_vector()). Cette fonction invoque ensuite une autre fonction pour aller configurer le Global Timer pour les partitions suivantes. 3.2 Architecture du P4080 Le P4080 est un calculateur conçu pour être intégré dans des équipements de télé- communications. Il permet d’accélérer le traitement et le filtrage des paquets. Le P4080 respecte l’architecture QorIQ de Freescale. Il contient un processeur PowerPC de type RISC avec 8 cœurs e500mc pouvant atteindre une fréquence de 1.5GHz indépendamment les uns des autres, avec 3 niveaux de caches. Ils peuvent être exécutés de façon symétrique ou asymétrique. Le processeur peut fonctionner dans trois modes de privilèges différents : utilisateur, invité privilégié et hyperviseur. Le mode “utilisateur” (user) est le mode le plus restreint. Il est utilisé pour les applications qui ne doivent pas avoir d’accès privilégiés. Le mode “invité privilégié” (supervisor) est utilisé lorsqu’un moniteur de machines virtuelles est présent. Le mode “hyperviseur” (hypervisor) est le niveau le plus privilégié des trois et permet de gérer l’ensemble du matériel du calculateur grâce à des accès et des instructions non-restreints. La figure 3.5 représente l’architecture du P4080. Fig. 3.5 – Architecture du P4080 (extrait de [Fre11]). 62Sur le haut de la figure 3.5 sont représentés les 8 cœurs avec les 3 niveaux de caches. Ceux-ci sont connectés au bus CoreNet qui permet de relier simplement les périphé- riques avec la mémoire, le processeur et les différentes autres fonctions du P4080. Sur la gauche de la figure sont représentés les périphériques d’entrées/sorties : Security Monitor, SD/MMC, SPI, DUART, I2C, USB, etc. Le P4080 intègre également des PAMUs (Peripheral Access Management Unit) assimilables à des I/OMMUs (pour architecture Intel) pour se protéger contre des accès malveillants depuis un périphérique. La plateforme offre la possibilité d’utiliser un démarrage sécurisé (secure boot). Il est possible de signer numériquement le code qui est exécuté par le processeur pour s’assurer que celui-ci n’a pas été altéré. Un autre composant important est le DPAA (DataPath Acceleration Architecture), qui permet d’accélérer le traitement des paquets Ethernet. D’autres contrôleurs tels que le PCI Express ou le RapidIO sont également utilisables. 3.2.1 Structure des cœurs e500mc Un cœur e500mc exécute des instructions 32 bits et implémente 32 registres généraux ainsi que 32 registres en virgules flottantes 64 bits. Le jeu d’instructions du e500mc est Power ISA version 2.0632 (Performance Optimization With Enhanced RISC Instruction Set Architecture). Le cœur contient un cache L1 de 32 Ko pour les données et 32 Ko pour les instructions. Le cache L2 a une capacité de 128 Ko, il peut contenir à la fois des données et des instructions. Les deux caches sont protégés avec des codes correcteurs d’erreurs. Le e500mc contient une MMU dont l’objectif est de définir des droits d’accès à certaines portions de mémoire. Le e500mc permet également de surveiller et compter des événements tels que les périodes des horloges de processeur, les omissions du cache d’instructions ou du cache de données ou encore les branches mal prédites (mispredicted branches). Les registres de surveillance de performance (Performance Monitor Registers) sont utilisés pour configurer et traquer les opérations de surveillance de performance. La gestion de l’alimentation permet de réduire la consommation d’énergie grâce à trois modes différents d’arrêts pour le cœur, sommeil léger, sommeil profond ou arrêt. 3.2.2 Contrôleur d’interruption Le MPIC (Multicore Programmable Interrupt Controller) est l’unité permettant de contrôler les interruptions sur des architectures multi-cœurs. Elle est également responsable de recevoir les interruptions générées par le matériel depuis différentes sources internes et externes, les classer par priorité et livrer les signaux à la destination appropriée. Le MPIC peut recevoir des interruptions de plusieurs sources : • les signaux externes IRQ ; • les sources d’interruptions internes (jusqu’à 112) ; • les messages partagés entre programmes ; 32https://www.power.org/wp-content/uploads/2012/07/PowerISA_V2.06B_V2_PUBLIC.pdf 63• interruptions générées dans le MPIC (Global Timer, InterProcessor Interrupt). Les interruptions peuvent être routées vers n’importe lequel des 8 cœurs. Il est également possible de faire du multicast pour une diffusion simultanée sur plusieurs cœurs. Le MPIC gère également des compteurs : les Global Timers. Ces compteurs permettent de générer une interruption lorsqu’un compteur décrémental (horloge) atteint la valeur zéro. Il suffit pour cela de lui donner une valeur correspondant à la durée souhaitée à attendre (registre GTBCRB0) puis de préciser quelle fonction appeler (registre GTVPRB0) lorsque la valeur atteint zéro. 3.2.3 DataPath Acceleration Architecture (DPAA) Le DPAA permet de réduire les surcharges logicielles et d’accélérer le traitement des paquets Ethernet. Il est composé de cinq éléments : le Security and Encryption Engine (SEC), Queue Manager (QMan), Pattern-Matching Engine (PME), Buffer Manager (BMan) et le Frame Manager (FMan). Ces éléments sont représentés dans la figure 3.6. Frame Manager Fig. 3.6 – QorIQ DataPath Acceleration Architecture. Le QMan est le composant qui permet le partage simplifié des interfaces réseau et des accélérateurs matériel par les cœurs. Il fournit aussi les moyens de partager des données entre cœurs pour être capable de paralléliser certaines tâches. La première fonction du BMan est de réduire la surcharge de traitement par le logiciel grâce à l’utilisation de groupes de tampons (pools of buffers). Ces groupes de tampons sont mis à disposition des autres composants matériels et sont alloués et libérés par le BMan. Le FMan permet de réaliser des analyses et classification configurables de trames entrantes avec pour but de sélectionner la file de trames d’entrée appropriée pour expédier le traitement vers un CPU ou un groupe de CPU. 64Le SEC est un moteur d’accélération cryptographique. Il implémente les algorithmes de chiffrement par bloc, par flux, de hachage, asymétriques, générateur de nombres aléatoires et vérificateur d’intégrité d’exécution. Le PME est une fonctionnalité de correspondance de modèles (pattern-matching) haute-performance permettant de rechercher des modèles dans des paquets réseau. 3.2.4 Démarrage sécurisé Le P4080 intègre plusieurs mécanismes de sécurité : le bit de non-exécution (X bit de la MMU), l’hyperviseur, les PAMUs, le Security Engine, le contrôleur de débogage sécurisé, la détection d’un appareil de sécurité défaillant, le Pre Boot Loader (PBL), le fusible de sécurité (FSP), le moniteur de sécurité. Le démarrage sécurisé utilise une clé publique RSA pour déchiffrer une empreinte SHA-256 signée et la comparer à une empreinte calculée sur la même portion de code. Ce code est en fait une image qui contient des instructions exécutables, des informations de configuration et une entête du fichier de séquence de commande. Il peut être en clair ou chiffré dans la mémoire. C’est le développeur qui décide du chiffrement ou non et du lieu où la clé privée RSA est stockée en mémoire. Elle ne doit en aucun cas être disponible à un tiers pour éviter la possibilité de générer une image alternative, ce qui rendrait inutile le démarrage sécurisé. 3.3 Présentation de la plateforme Notre plateforme expérimentale comprend des éléments logiciels (le noyau temps-réel et l’IDE Codewarrior) et matériels (le P4080 et la sonde JTAG). Le calculateur QorIQ P4080 de Freescale a été choisi par Airbus car son processeur de type PowerPC et ses performances élevées permettent d’assurer une forte compatibilité avec les autres logiciels développés dans l’entreprise. Il permet également de proposer de nouvelles technologies (démarrage sécurisé, utilisation de plusieurs cœurs, etc.). Le noyau temps-réel est confi- guré statiquement (allocation de la mémoire pendant la compilation) ce qui permet de satisfaire la contrainte du déterminisme, et il n’y a aucune allocation de la mémoire pendant l’exécution du noyau. Cette configuration est réalisée via des fichiers dédiés. Un outil de génération automatique de code est utilisé pour générer le code du noyau et des interfaces entre le noyau et les applications à partir de la configuration. Cette section est consacrée à la présentation détaillée de cette plateforme, en particulier, des mécanismes que nous avons utilisés pour pouvoir observer le comportement du noyau et des applications ainsi que la configuration de ces mécanismes. Cette observation est principalement basée sur l’utilisation d’une sonde JTAG et d’un logiciel approprié. La figure 3.7 propose une vue globale de notre plateforme d’expérimentation. 65Freescale QorIQ P4080 Sonde JTAG USB Codewarrior Ordinateur de pilotage d'expérimentations Fig. 3.7 – La plateforme d’expérimentation. 3.3.1 Observation du noyau et des applications Pour notre étude, nous avons utilisé une version datant de 2010 du noyau expérimental d’Airbus. Cette version est actuellement en cours de développement mais elle permet néanmoins d’utiliser des fonctions du P4080 (notamment le MPIC et la MMU) avec le noyau et les partitions (séparation de la mémoire et décomposition en slots de temps). Pour être capable de tester efficacement le noyau et les applications, nous avons utilisé le logiciel Codewarrior (version 10.1.1). Il permet en effet de charger des applications sur une cible, de configurer du matériel, de contrôler et d’observer cette cible grâce à une sonde JTAG. La sonde JTAG (voir figure 3.8) est l’interface entre le P4080 et le PC exécutant Codewarrior, elle permet de convertir les signaux de la carte en information compré- hensible par le logiciel. Elle peut être connectée par le développeur à un ordinateur sur un port USB 2.0 ou un port Gigabit (disponibles par Freescale). Le second est bien sûr beaucoup plus rapide (de 100Mbits/s à 1Gbits/s) que le premier (quelques dizaines de Mbits/s) mais requiert une connexion au réseau local ce qui peut être une contrainte car cela signifie que la sonde est directement accessible à n’importe quel personne (honnête ou non) qui connaît l’adresse IP de la sonde33. Pour nos expérimentations, nous avons utilisé la sonde JTAG avec un port USB. Le port JTAG se situe sur la carte mère du P4080. La sonde JTAG est connectée à ce port et à un ordinateur disposant de Codewarrior à l’autre extrémité. Comme pour tout programme de débogage, l’exécution peut se faire en mode pas-à-pas ou en mode continu jusqu’à ce que le programme rencontre un point d’arrêt. Cette sonde permet par exemple de débugger le code en cache, ROM, RAM et dans la mémoire flash, d’afficher et de modifier la mémoire sur la cible ou encore d’examiner 33Cette méthode est donc plutôt utilisée pour un ensemble de développeur ayant accès à la même plateforme. 66Fig. 3.8 – Sonde JTAG de Freescale. et de modifier n’importe quel registre du processeur. Il supporte également toutes les vitesses des cœurs du processeur. L’avantage avec le port USB est qu’il ne nécessite aucune configuration de la sonde contrairement à l’interface réseau Gigabit qui nécessite forcément l’attribution d’une adresse IP pour être accessible sur le réseau. Codewarrior détecte automatiquement le branchement de la sonde USB. Il est aussi possible de brancher plusieurs sondes USB sur le même ordinateur et d’en spécifier une seule à utiliser dans Codewarrior (grâce à son numéro de série). 3.3.2 Configuration de la plateforme d’expérimentation La configuration de la plateforme d’expérimentation est basée sur le paramétrage du P4080 lui-même, sur l’installation et la paramétrage des composants logiciels du système avionique (le noyau et les applications), ainsi que sur le paramétrage des outils de contrôle et d’observation (la sonde JTAG et l’application Codewarrior). Nous présentons ces différentes configurations dans les sous-sections suivantes. 3.3.2.1 Configuration de Codewarrior et de la sonde JTAG USB L’interface graphique de Codewarrior offre plusieurs vues : le code source (C ou assembleur), la mémoire désassemblée, les breakpoints et les commandes de debug (pour continuer l’exécution jusqu’au prochain point d’arrêt ou faire une pause). La figure suivante 3.9 est une capture d’écran de Codewarrior version 10.1.1. De nombreuses fonctionnalités sont offertes par ce logiciel. La plus intéressante est probablement le debugger shell qui nous permet de lire des registres et de la mémoire, de gérer les points d’arrêts et de créer des scripts. Codewarrior offre la possibilité de configurer un ou plusieurs cœurs du processeur. 67Fig. 3.9 – Capture d’écran du logiciel IDE Codewarrior de Freescale. Nous n’utilisons qu’un seul cœur pour exécuter notre code pour nous placer dans les mêmes conditions que celles d’Airbus. Ensuite, la configuration du cœur lui-même s’effectue au démarrage du noyau. Cette initialisation est réalisée via un fichier de configuration. Ce fichier contient la configuration de plusieurs éléments importants du P4080 : les fenêtres d’accès local (Local Access Window ou LAW), la DDR et ajoute une entrée dans la MMU. Un ensemble de 32 LAWs34 peut être configuré. Un LAW permet d’assigner une zone d’adresses à un périphérique. Pour notre plateforme, cinq de ces LAWs sont configurés pour Codewarrior : pour l’utilisation de la DDR1 et DDR2, PCI Express 3, et deux eLBC (ex : SRAM, ZBT RAM ou EEPROM). La taille de ces zones, l’adresse de base, la cible de la transaction sont précisées dans ce fichier de configuration. La sonde JTAG USB ne nécessite aucune configuration particulière. Il suffit de la brancher à l’ordinateur pour qu’elle soit directement reconnue. 3.3.2.2 Configuration du P4080 Avant d’utiliser la plateforme, une configuration logicielle et matérielle s’impose. La configuration matérielle est réalisée grâce à des cavaliers (les SW35) présents sur la carte mère du P4080. Ils sont au nombre de 80. Nous pouvons modifier les paramètres sui- 34Une zone peut être définie sur 4Ko au minimum ou 64Go au maximum. 35SWitches. 68vants : la vitesse de l’horloge interne (de 66.666 MHz à 133.333 MHz), le voltage des cœurs et de la plateforme ou encore les protections en écriture des configurations RCW. La configuration logicielle du P4080 s’effectue en deux temps. Tout d’abord, un fichier (le PBL36) est chargé depuis la mémoire flash pendant le démarrage notamment pour configurer la fréquence du processeur. Ensuite, le noyau configure plusieurs éléments : • les permissions de la zone de mémoire (MMU) ; • le compteur de temps (Time Base) ; • les interruptions, qui sont initialisées (MPIC) ; • les caches, qui sont initialisés. Dans les premières instructions de l’exécution du code noyau, quatre nouvelles zones de mémoire sont ajoutées dans la MMU : le CCSR37 sur 16 Mo (nous y reviendrons en détail plus tard), le code noyau sur 1 Mo, les données du noyau sur 1 Mo puis les données d’instrumentation du noyau sur 1 Mo. Le compteur de temps est aussi activé (car il est désactivé par défaut) dans les premières instructions pour être capable de mesurer les durées des exécutions ce qui nous est nécessaire pour nos expérimentations. Les interruptions sont également utilisées pour permettre de gérer efficacement les évé- nements et les erreurs sur la plateforme. Les IVORs (Interrupt Vector Offset Registers) permettent par exemple de définir les actions à entreprendre (adresse des instructions à exécuter) lorsqu’un événement survient (erreur de données, erreur d’alignement, erreur de données TLB, appel-système, etc.). Les caches sont utilisés pour accélérer la vitesse de transmission des données et des instructions entre le processeur et la mémoire principale. 3.3.2.3 Configuration du noyau La configuration du noyau est réalisée par l’intermédiaire de plusieurs fichiers textes. Ces fichiers sont utilisés lors de la génération du noyau. Dans ces fichiers de configuration, nous retrouvons notamment la durée d’un cycle d’exécution, le nombre d’applications qui sont exécutées par le noyau, la durée maximale d’un appel d’une fonction distante (IPC) ou encore les actions à entreprendre (arrêt, redémarrage ou arrêt après trois redémarrages) lorsqu’une erreur survient. 3.3.2.4 Configuration des applications La configuration des applications se fait également par des fichiers modifiables avant la compilation. Une application est composée d’une ou plusieurs partitions (voir le chapitre 1 sur les systèmes avioniques pour plus de détails). Chaque partition a donc une tranche de temps qui lui est réservée ainsi qu’un espace mémoire limité. Ces paramètres sont différents de ceux du noyau car celui-ci n’a pas de tranches de temps allouées. Il y a nécessairement la durée d’exécution de la partition ainsi que les zones de mémoire accessibles depuis la partition. Il est aussi nécessaire de préciser à quel moment (décalage en microsecondes) la partition doit commencer. 36Pre-Boot Loader 37Configuration, Control and Status Registers. 69Après la présentation des différents composants de notre plateforme d’expérimentation, la section suivante est consacrée à la présentation détaillée de plusieurs attaques que nous avons pu réaliser sur notre plate-forme, cela concerne les attaques : • ciblant la gestion de la mémoire, • ciblant les communications, • ciblant la gestion du temps, • ciblant les mécanismes de tolérance aux fautes. 3.4 Attaques ciblant la gestion de la mémoire Une corruption de la gestion de la mémoire peut permettre à une partition malveillante d’accéder à des données sensibles utilisées par le noyau ou par d’autres partitions. Nous décrivons dans l’exemple suivant comment provoquer une attaque par dénide-service en abusant la gestion de la mémoire. Comme nous l’avons déjà indiqué, la plateforme P4080 est configurée en partie grâce à la zone Configuration, Control, and Status Registers (CCSR). Cette zone de 16 Mo contient la configuration de tous les composants matériels (MPIC, périphériques, contrôleurs réseau, alimentation, etc.). Or, nous avons découvert, en analysant le code source, que dans la version actuelle du système en notre possession, les accès en lecture et écriture à cette zone sont positionnés pour le noyau mais également pour les partitions. Cette configuration a été choisie délibérément pour que les différentes partitions puissent utiliser le contrôleur réseau AFDX sans utiliser de pilote partagé. Cette configuration est particulièrement risquée car cela implique que les partitions peuvent modifier la configuration de tous les composants matériels de la plateforme. Par exemple, avec cette configuration, une partition malveillante est parfaitement capable de remplir les registres de la zone CCSR avec des données aléatoires. Pour nos expé- rimentations, nous avons choisi d’injecter, depuis la partition malveillante, des valeurs particulières dans cette zone afin de provoquer un déni-de-service. A titre d’illustration, un exemple de déni-de-service est présenté dans la prochaine sous-section, en utilisant des registres du CCSR et visant plus spécialement le Security Engine (SEC du DPAA) du P4080. 3.4.1 Attaques ciblant le Security Engine Comme nous l’avons déjà vu précédemment, le SEC permet d’utiliser des mécanismes de chiffrement tels que AES, DES, RSA, etc., au sein du P4080, que ce soit pour le traitement des paquets Ethernet ou pour un autre usage. Il est géré par le Security Monitor qui est en charge de vérifier les erreurs du système et contrôler les clés cryptographiques utilisées pour le démarrage sécurisé. Par défaut, le gestionnaire de sécurité (security monitor) est dans un état non-secure, c’est-à-dire que les clés cryptographiques ne sont pas initialisées. La figure 3.10 montre les différents états possibles du gestionnaire de sécurité et les relations entre eux. 70Fig. 3.10 – Diagramme des états du SEC [Fre11]. Le choix du démarrage sécurisé ou non se fait grâce au bit ITS (Intent To Secure) du registre SFP_OSPR (OEM Security Policy Register) des registres Security Fuse Processor (SFP). Pendant le démarrage du système, l’état du gestionnaire de sécurité passe successivement de init à check puis à non-secure si le bit ITS n’est pas positionné, ou secure si ce bit est positionné. Si une erreur logicielle est détectée lors du démarrage du système, le gestionnaire de sécurité entre dans un état “failed” ce qui bloque l’utilisation des clés cryptographiques et les positionne à zéro. Ce type d’erreur se manifeste par le positionnement à 1 du bit SW_FSV du registre SM_HP (adresse 0xFE314004). Si, à partir de cet état, une erreur matérielle est détectée, le système redémarre. Cette erreur se ma- 71nifeste par le positionnement à 1 du bit HAC_EN du même registre SM_HP (tel qu’indiqué dans la spécification du P4080 [Fre11]). Ce registre est positionné dans le CCSR, zone mémoire dont les accès en lecture et écriture sont autorisés pour toutes les partitions, comme nous l’avons vu précédemment. En conséquence, si une partition malveillante modifie intentionnellement ces deux bits et les positionne à 1, la plateforme redémarre. Nous avons ainsi provoqué ce déni de service en modifiant ces 2 bits. Un exemple similaire peut être réalisé en utilisant le Run Control/Power Management (RCPM). Nous le présentons dans la sous-section suivante. 3.4.2 Attaques ciblant le Run Control/Power Management Le RCPM (Run Control/Power Management) est une autre zone du CCSR. Le RCPM gère l’alimentation des cœurs et des périphériques. Deux modes de faible alimentation sont possibles pour un cœur. Il s’agit des modes : assoupi (dozing) et endormi (napping). Le mode assoupi permet de suspendre l’exécution d’instructions, sans arrê- ter le fonctionnement des caches L1 et L2. Dans le mode endormi, toutes les horloges internes sont arrêtées et les caches L1/L2 ne sont plus fonctionnels. Deux registres sont utilisés pour passer dans ces modes. Le registre RCPM_CDOZCR (Core Doze Control Register) permet de passer en mode core dozing et le registre RCPM_CNAPCR (Core Nap Control Register) permet de passer en mode core napping. Dans la mesure où l’accès en écriture est autorisé pour toutes les partitions dans le CCSR (et donc dans la zone RCPM), il est donc possible pour une partition malveillante de modifier ces registres et donc de configurer les modes d’alimentation des cœurs, et ainsi de provoquer un déni-de-service en les positionnant en mode assoupi ou endormi. 3.5 Attaques ciblant les communications Le noyau expérimental fourni par Airbus autorise plusieurs types de communications : une communication entre modules via le réseau AFDX (Avionics Full DupleX) et une communication entre partitions d’un même module via les IPC. 3.5.1 Attaques ciblant les communications AFDX Pour communiquer entre les modules et échanger des informations, les systèmes avioniques utilisent principalement le réseau AFDX. Celui-ci est déterministe et basé sur Ethernet. Ses principaux avantages sont sa rapidité et sa simplicité (pour l’accès au ré- seau et l’évolution de l’architecture). Pour cela, le réseau utilise des liens virtuels (Virtual Links). Un Virtual Link (VL) caractérise un flot de données entre un émetteur et un ou plusieurs destinataires ; ce flot de données doit respecter une bande passante défi- nie par configuration. L’identifiant du VL est contenu dans l’adresse MAC destination. D’autres informations comme le numéro de partition, le numéro de l’hôte et du réseau sont eux contenus dans l’adresse IP source, qui, même si elle est codée sur la même taille qu’une adresse IP usuelle, contient des informations légèrement différentes (le numéro de partition). Deux types de ports AFDX sont utilisés : 72• Service Access Points (SAP) : les ports SAP ont été créés pour répondre à un besoin Ethernet “classique” pour les applications du monde ouvert (TFTP notamment). • AFDX communication : chaque port implémente un service d’envoi de données et deux services de réception (en mode sampling et queuing) • mode Sampling : seule la dernière valeur est présentée à l’application par le driver. • mode Queuing : toutes les valeurs sont présentées à l’application par le driver. La configuration de AFDX se fait avant la compilation des partitions car elle est statique et tous les paramètres doivent être définis avant exécution. Nous allons détailler comment réaliser cette configuration AFDX. 3.5.1.1 Configuration des tables AFDX La configuration des tables AFDX se fait grâce à deux fichiers contenant deux tableaux avec tous les paramètres nécessaires : VL, BAG38 , Max frame size, redondance, numéro de réseau, etc. Un outil codé en Perl appelé Matrix (produit et mis à notre disposition par Airbus) utilise ces fichiers pour générer du code C qui est ensuite compilé pour obtenir le fichier ELF exécutable correspondant au pilote AFDX pour la partition. La figure 3.11 représente la chaîne de compilation pour une partition utilisant l’AFDX. Il est nécessaire d’utiliser l’outil Matrix pour générer des fichiers C, ensuite, nous utilisons le compilateur GCC pour les compiler avec le programme principal. Matrix Fichiers ".c" générés qui contiennent la configuration du driver Compilation du driver (application 0) fichiers ".c" *_extrait_isdb.csv *_ports_partition.csv *_conf_tc.c *_ports_emission.c *_ports_reception.c *_partition_0_ports_reception.c *_partition_0_ports_emission.c *_partition_1_ports_reception.c *_partition_1_ports_emission.c *_partition_2_ports_reception.c *_partition_2_ports_emission.c *_vl_reception.c GCC Exécution de Matrix Configuration des tables test0_0.elf partition0.c end_system_controller.c ... Fig. 3.11 – Chaîne de compilation pour une partition utilisant AFDX. Pour réaliser nos tests AFDX, nous avons utilisé une carte AFDX d’Airbus, connectée en PCI avec un pont PCI vers PCI Express. Cette carte est par défaut “ouverte” car elle est destinée à réaliser des tests. C’est la raison pour laquelle nous avons détecté certains problèmes évidents de sécurité comme la gestion des accès DMA par exemple. Cependant nous avons également identifié d’autres vulnérabilités qui ne sont pas uniquement liées à 38Le Bandwidth Allocation Gap (BAG) représente le délai minimum entre 2 trames consécutives d’un VL (de 1ms à 128ms par valeurs multiples de 2). 73cette configuration en mode test. Nous présentons l’ensemble de ces vulnérabilités dans la suite. 3.5.1.2 Vulnérabilités détectées La première vulnérabilité découverte est liée à la configuration des accès DMA, puisqu’ils sont autorisés en lecture et écriture de façon illimitée à toute la mémoire (l’envoi et la réception de données nécessite en effet de réaliser des accès DMA, comme il est coutume avec une carte Ethernet classique). Cette configuration est réalisée dans le CCSR, et comme nous l’avons vu précédemment, la gestion des droits d’accès au CCSR fait que toute partition peut modifier tous les registres présents dans cette zone. Une partition malveillante peut donc tout à fait modifier la gestion des accès DMA en accédant en écriture au CCSR. Il lui est donc tout à fait possible d’envoyer des commandes à la carte AFDX sans aucun contrôle préalable, et de faire n’importe quelle lecture ou écriture sur toute la mémoire du système. Une seconde vulnérabilité concerne l’accès à certaines variables globales utilisées pour les communications AFDX. Ces variables sont créées dans une zone de mémoire partagée entre les applications qui effectuent des communications AFDX, et donc modifiables par n’importe laquelle de ces partitions. En conséquence, une partition malveillante qui utilise le réseau AFDX a donc accès à cette zone de mémoire et peut donc modifier ces variables. Nous avons ainsi pu montrer qu’il est possible de bloquer depuis une partition malveillante les envois AFDX d’autres partitions. La troisième vulnérabilité concerne une variable appelée AFDX_PARTITION_ID qui permet d’identifier une partition lors de l’envoi et la réception de paquets. Cette variable est locale à chaque partition et est stockée dans son espace mémoire dédié. Mais on peut imaginer qu’une partition malveillante modifie cette variable dans le but de recevoir des données qui ne lui sont pas destinées ou de se faire passer pour une autre partition lorsqu’elle envoie des données. Si une partition malveillante modifie cette variable en lui affectant un numéro de partition invalide, cela provoque une erreur. Si elle utilise un numéro valide d’une autre partition, alors le paquet émis par la partition malveillante sera considéré émis par cette autre partition. Lors de la réception de paquet, il est également possible à une application malveillante de modifier cette variable pour tenter de recevoir des paquets destinées à une autre partition mais la propriété de déterminisme du réseau AFDX fait qu’en pratique, il est impossible que des données soient reçues à un instant t pour une partition i alors que c’est la partition j qui est en cours d’exécution. Nous considérons donc que cette vulnérabilité est beaucoup plus difficile à exploiter en réception. Dans le cadre de nos expérimentations, nous avons effectivement réussi à modifier cette variable au moment de l’envoi et donc à créer une partition qui émet des paquets en se faisant passer pour une autre partition. La quatrième vulnérabilité concerne les partitions Data Loader et Flash Manager qui permettent de télécharger et de recopier des données (en particulier de mises à jour). Dans la version actuelle de ces partitions, la Data Loader ne fait aucune vérification sur les données envoyées au Flash Manager. Si par conséquent, ces données contiennent des informations erronées concernant des données de configuration des partitions ou 74des coeurs du processeur par exemple, celles-ci seront mises à jour et pourront considérablement modifier le comportement global du système jusqu’à le rendre totalement inopérant. Cette dernière vulnérabilité a été découverte grâce à l’analyse de code source des applications mais elle n’a pas donné lieu à des expérimentations. 3.5.2 Attaques ciblant les IPC Notre noyau temps-réel expérimental implémente les IPC (Inter-Process Communications) qui permettent à une partition (dite locale dans la terminologie IPC) d’appeler une fonction fournie par une autre partition (dite distante). Pour cela, (1) la partition locale exécute un appel-système pour que le noyau exécute une commutation de contexte ; (2) le noyau change le contexte de la partition locale pour le contexte de la partition distante ; (3) la fonction distante est exécutée pendant 27 microsecondes puis exécute un appel-système pour que le noyau exécute une commutation de contexte ; (4) le noyau recharge le contexte de la partition locale et (5) la partition locale continue à être exécutée. La figure 3.12 représente un exemple de communication IPC. Application0 (code user) 1) image_app6_part0_u_call_EP() { r10 = 0 r9 = 7 syscall() } 9) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() r9 = 7 syscall() } 13) image_app6_part0_return_from_ipc() { rfi } 5) image_app0_enter_ipc() { if (r10 != 0): goto bad_ipc } 6) image_app0_enter_ipc_part_part0() 7) image_app0_part0_enter_part_ipc() 8) image_app0_part0_perform_enter_ipc() { address_ipc_return <- 0xB4740 rfi } 10) nk_sc_vector() 11) image_app0_part0_syscall() 12) image_app0_part0_syscall_ipc_return() { goto address_ipc_return } Kernel (code noyau) 2) nk_sc_vector() 3) image_app6_part0_syscall() 4) image_app6_part0_syscall_ipc_enter_aapp0() Application6 (code user) Fig. 3.12 – Exemple de communication IPC 75Deux appels système sont créés pour la gestion des IPC : un appel-système est créé dans la partition locale pour appeler la fonction distante et un autre dans la partition distante pour revenir dans la partition locale. Ces appels système permettent de donner la main au noyau car c’est lui seul qui a les privilèges suffisants pour passer d’une partition à une autre (modification de contexte). Deux registres généraux (GPR9 et GPR10) sont initialisés avant l’appel-système pour appeler la fonction distante. GPR9 permet de préciser le numéro de l’appel-système et GPR10 est utilisé par le noyau pour une action non-définie car toujours en cours de développement. L’application 6 correspond à la partition locale et l’application 0 correspond à la partition distante. Nous allons détailler maintenant trois problèmes d’implémentations du noyau qui peuvent conduire à des vulnérabilités (en particulier des dénis-de-service) si la partition locale ou distante n’agit pas exactement comme elle est supposée le faire. 3.5.2.1 Modification de l’ordre des appels-système Une première tentative d’attaque consiste pour la partition distance à exécuter l’appel-système lui permettant de revenir dans la partition locale alors que la partition locale n’a pas encore effectué d’IPC en invoquant elle-même son propre appel système. La figure 3.13 représente cet exemple. Application0 (code user) 1) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() r9 = 7 syscall() } x) image_app6_part0_return_from_ipc() { rfi } 2) nk_sc_vector() 3) image_app0_part0_syscall() 4) image_app0_part0_syscall_ipc_return() { blr address_ipc_return (0x00000000) } Kernel (code noyau) Application6 (code user) Fig. 3.13 – Appel-système depuis l’Application 0 Dans ce cas, le code noyau qui vérifie la source de l’appel-système va provoquer une erreur de type ITLB (Instruction Translation Lookaside Buffer) en exécutant l’instruction à l’adresse 0x00000000 qui se situe dans un espace mémoire privilégié (et qui provoque un déni-de-service). Là encore, c’est l’implémentation qui n’est pas complète et qui ne devrait pas pointer vers cette adresse. 763.5.2.2 Interruption dans la fonction distante Dans cette seconde attaque, nous avons voulu observer le comportement du noyau lorsque la durée accordée à l’exécution de l’IPC (27 microsecondes) se termine avant que toute la fonction n’ait été exécutée. Pour cela, nous avons défini une boucle infinie dans la fonction distante pour qu’une interruption de type Global Timer puisse provoquer le retour dans le noyau au lieu de l’appel-système. Dans ce cas, l’exécution continue dans une boucle infinie (figure 3.14), l’implémentation actuelle ne l’a pas pris en compte. Application0 (code user) 1) image_app6_part0_u_call_EP() { r10 = 0 r9 = 7 syscall() } 9) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() { while(1) {} } r9 = 7 syscall() } 5) image_app0_enter_ipc() { if (r10 != 0): goto bad_ipc } 6) image_app0_enter_ipc_part_part0() 7) image_app0_part0_enter_part_ipc() 8) image_app0_part0_perform_enter_ipc() { address_ipc_return <- 0xB4740 rfi } Kernel (code noyau) 2) nk_sc_vector() 3) image_app6_part0_syscall() 4) image_app6_part0_syscall_ipc_enter_aapp0() Application6 (code user) 10) nk_int_vector() 11) nk_slice_end() 12) image_app0_part0_leave() { if address_ipc_return != 0: image_app0_part0_spurious() } 13) image_app0_part0_spurious() { b . } Fig. 3.14 – Boucle infinie l’Application 0 3.5.2.3 Modification du registre GPR10 Cette dernière attaque concerne la modification intentionnelle du registre GPR10 dans le but de rendre le système indisponible. En effet, ce registre GPR10 est initialisé à la valeur 0 dans le code de la partition (et donc en mode utilisateur) avant de réaliser l’appel-système pour appeler la fonction distante. Il est ensuite comparé à 0 dans le code 77noyau. Si une valeur différente est présente, alors une boucle infinie est exécutée sinon le code poursuit son exécution. Si la partition locale est malveillante alors elle peut positionner ce registre GPR10 à une valeur différente de 0 pour que le noyau rentre dans la boucle infinie. Dès qu’une boucle infinie dans le noyau est exécutée, il n’est plus possible de sortir de cette boucle par un autre moyen que le redémarrage ou une interruption NMI car le noyau ne peut pas être interrompu par une interruption “classique”. La présence de cette boucle à cet endroit ne devrait pas être possible, il s’agissait en fait d’une implémentation incomplète car le noyau est en cours de développement. Même si globalement ces résultats d’expérimentations sont principalement dues au fait que le noyau est en cours de développement, elles ont permis de mettre en évidence des comportements qui n’avaient pas été considérés comme possibles tant que l’on envisage pas des actes malveillants. Modifier volontairement le séquencement d’un IPC ou inclure une boucle infinie dans son propre code sont des comportements malveillants qu’il est donc important de prendre en compte lors du développement, sous réserve de provoquer des dénis-de-service du système. 3.6 Attaques ciblant la gestion du temps Cette section est consacrée à la présentation des expérimentations que nous avons menées pour perturber la durée d’exécution d’une partition, tout d’abord en utilisant les interruptions, ensuite en modifiant la configuration d’une partition. 3.6.1 Première attaque : utilisation des interruptions La durée d’exécution des tranches de temps pour chaque partition est basée sur le calcul du WCET (Worst Case Execution Time) qui est stocké dans les fichiers de confi- guration de chaque partition. Le MPIC fournit la gestion des interruptions multiprocesseurs et est responsable d’envoyer des interruptions générées par le matériel (internes et externes), leur associer des priorités, et les envoyer aux cœurs appropriés. Le principe de l’attaque à laquelle nous avons pensé consiste à essayer de faire en sorte que l’exécution d’une partition malveillante déborde de sa tranche de temps allouée, de façon à réduire le temps d’exécution de la partition suivante. Si cette partition est une partition critique, cela peut donc avoir un impact sérieux. Cette attaque nécessite l’utilisation d’une interruption, ainsi que nous le présentons dans la sous-section suivante. 3.6.1.1 Réalisation du programme Pour réaliser le programme de notre propre partition malveillante, nous avons créé une boucle et ajusté une valeur de sortie de boucle pour provoquer une interruption au plus proche de la fin de la durée d’exécution. Cette interruption est une instruction 78illégale (instruction rfi39 dans notre cas) qui provoque un retour dans le noyau pour être traité. Notre objectif est ainsi de pouvoir consommer du temps CPU dans le noyau (qui est non interruptible) grâce à cette interruption déclenchée au dernier moment dans notre partition malveillante, et ainsi voler du temps CPU à la partition suivante. 3.6.1.2 Instrumentation du noyau Nous avons modifié le noyau pour être capable de sauvegarder en mémoire les durées d’exécution des partitions P6 et P7 (phase de préparation de P7 et phases opérationnelles de P6 et P7) : les temps T0, T1, T2 et T3. La figure 3.15 représente ces durées pour chaque partition (la phase de préparation est notée W et la phase opérationnelle est notée P suivi du numéro de la partition) : P3 P4 P1 P5 P2 P0 P6 P7 T0 T1 T2 T3 Fig. 3.15 – Mesures des temps sur un cycle (5 ms). Nous sauvegardons ces 4 temps40 pendant 1024 cycles puis nous analysons les résultats. A noter que ces temps correspondent aux réelles durées d’exécution des différentes phases et non au compteur du Global Timer qui déclenchent les interruptions une fois qu’il vaut zéro. Pour cela, nous avons réalisé un programme en Python qui, à partir de ce tableau de 1024 cycles, permet de calculer toutes les durées d’exécution de la partition P6 et P7 ainsi que celle de la phase de préparation de la partition P7. 3.6.1.3 Résultats obtenus Nous prenons comme exemple deux partitions P6 (malicieuse) et P7 (non-malicieuse) avec leurs phases de préparation associées W6 et W7. Les durées des phases de préparation sont fixées à 90 microsecondes pour toutes les partitions et les durées des phases opérationnelles sont fixées à 1410 microsecondes (soit un total de 1500 microsecondes pour chacune des deux partitions). La figure 3.16 représente les durées d’exécutions des différentes phases de ces deux partitions ainsi que les compteurs CCR (Current Count Register) du MPIC dont la valeur décrémente jusqu’à la valeur 0. 39L’instruction return from interrupt (rfi) permet de retourner en mode utilisateur lorsque l’on est dans le noyau et doit donc être seulement utilisé dans le noyau. 40Utilisation des registres TB (Time Base) et TBL (Time Base Lower). 79P6 P7 T0 T1 T2 T3 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.16 – Comportement normal des deux partitions. Une attaque sur la gestion du temps consiste pour une partition non-critique malveillante, à être capable de réduire la durée d’exécution d’une partition critique. Comme nous l’avons expliqué auparavant, le principe consiste donc, pour une partition malveillante, à augmenter sa tranche de temps grâce au déclenchement volontaire, à la fin de sa tranche de temps, d’interruptions qui sont gérées par le noyau (qui ne peut être interrompu) (voir figure 3.17). P6 P7 T0 T1 T2 T3 W7 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.17 – Dépassement de P6. Lorsque la partition P6 enclenche une exception à la fin de sa tranche de temps, nous avons été capable d’augmenter sa durée de 6 microsecondes et donc de réduire la durée de la partition P7 de 6 microsecondes. Pour cette expérience, les conséquences n’ont pas été significatives car la marge de sécurité prise par le noyau est suffisante mais dans d’autres contextes, il est tout à fait possible d’imaginer que cette réduction puisse conduire à défaillance. 803.6.2 Seconde attaque : modification de la configuration d’une partition Un autre type d’attaque a été envisagé, même s’il est beaucoup plus difficile à réaliser en pratique. Il consiste à essayer de faire en sorte que la partition P7 nécessite un temps de préparation supérieur à la durée de 90µs prévu statiquement. Pour cela, nous avons considéré une partition P7 qui utilise énormément de mémoire et donc d’entrées dans la MMU. Dans ce cas, la phase de préparation, durant laquelle notamment ces entrées MMU sont préparées, peut durer plus de 90µs. Nous avons ainsi ajouté volontairement plusieurs dizaines d’entrées dans la MMU de P7, ce qui allonge donc la durée de la phase de préparation, car il s’agit de code en mode noyau non interruptible. A titre d’illustration, nous avons réalisé l’expérimentation de la figure 3.18. Nous avons augmenté la durée d’exécution de la phase de préparation de la partition P7 en ajoutant 452 entrées dans la MMU ce qui a prolongé de 15 microsecondes la durée de cette phase (105 microsecondes au lieu des 90 requises). P6 P7 T0 T1 T2 T3 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.18 – Dépassement de la phase de préparation de P7. Cette expérimentation a juste pour but de montrer que l’on peut déborder de ces 90µs mais elle ne peut directement être exploitée par une partition malveillante. Si une partition malveillante utilise volontairement énormément d’entrées dans la MMU, elle va simplement se pénaliser elle-même puisque son cycle de préparation va dépasser 90µs, et par conséquent, son temps d’exécution va en être réduit d’autant. En revanche, si on imagine qu’une partition malveillante ait la possibilité de modifier la configuration d’une partition critique de façon à lui faire utiliser énormément de mémoire, il est possible qu’elle puisse donc réduire son temps d’exécution. Cependant, cette configuration étant réalisée de façon statique à priori, il semble particulièrement difficile de réaliser une telle attaque. Si l’on suppose cependant que cette configuration puisse être modifiée, alors cela peut notamment être intéressant si on le combine à l’attaque présentée dans la section précédente. C’est ce que nous montrons dans la sous-section suivante. 813.6.3 Utilisation conjointe des deux attaques Dans ce dernier exemple (figure 3.19), nous avons cumulé les deux cas précédents. Nous considérons une partition malveillante P6 qui tente d’allonger son temps d’exécution pour voler du temps d’exécution de la partition P7, qui est non-malveillante. Par ailleurs, la partition P7 utilise énormément d’entrées dans la MMU et voit son temps de préparation déborder des 90ms. Dans ce cas très particulier, la partition P7 perd une partie conséquente de sa tranche de temps. P6 P7 T0 T1 T2 T3 90 1410 90 1410 Durée d'exécution Compteur (CCR) Fig. 3.19 – Dépassement de la phase de préparation et de la phase opérationnelle de P7. 3.7 Attaques ciblant les mécanismes de tolérance aux fautes Un composant typique de tolérance aux fautes est le gestionnaire d’erreurs du noyau, utilisé comme système de détection d’erreur et système de recouvrement. Ces mécanismes peuvent provoquer un redémarrage du module quand des erreurs sont considérées comme non-récupérables. Nous avons réalisé une expérience pour tester la robustesse de ce mécanisme de gestion des erreurs en utilisant un programme Crashme : la partition malicieuse génère une centaine d’instructions aléatoires puis les exécute. 3.7.1 Réalisation du programme Crashme Un programme Crashme consiste à générer des instructions aléatoires puis à les exécuter. Pour réaliser cela depuis une application, deux solutions sont possibles. Elles consistent à : • modifier le code source de l’application et utiliser une zone de mémoire avec les privilèges d’écriture et d’exécution : • modifier le fichier binaire de l’application pour exécuter les instructions aléatoires dans une zone de mémoire avec les privilèges d’exécution (donc comme n’importe quelle autre instruction de l’application). 82La première solution est plus simple à réaliser que la deuxième solution mais elle né- cessite des privilèges d’écriture et d’exécution sur une zone de la mémoire, ce qui qui ne devrait pas être possible justement pour éviter des exécutions de code arbitraire depuis une partition. Nous avons cependant décidé d’utiliser la première solution, puisqu’elle évite notamment de recharger l’application sur le P4080 à chaque test, même si nous considérons qu’un attaquant utiliserait plutôt la deuxième solution, qui évite de créer une zone de mémoire particulière avec des privilèges élevés (écriture et exécution). Pour notre preuve de concept, la première solution est suffisante. La création d’un générateur de nombres pseudo-aléatoires est complexe et difficile à prouver mais notre intérêt, ici, est de générer des instructions différentes à chaque exécution de notre partition et non de générer des nombres sans aucun biais. Nous avons utilisé une formule simple et rapide, le standard minimal de Park et Miller [PM88] : Xn+1 = (16807 ∗ Xn) mod (231 − 1) La première valeur X0 est initialisée à la valeur du registre TBL (Time Base Lower) qui est une mesure du temps de la plateforme variant très fortement car basé sur les nanosecondes. Cette formule permet donc de générer jusqu’à 2 147 483 647 (231 − 1) valeurs différentes, mais sur cet intervalle, nous utiliserons seulement 216 valeurs (2 octets) pour générer plus simplement les 4 octets (2 fois 2 octets) composant une instruction (4 octets). Une boucle dans notre programme nous permet de générer des centaines de valeurs de 2 octets et donc des centaines d’instructions. 3.7.2 Instrumentation du noyau Pour identifier et comparer les résultats, nous avons modifié légèrement le noyau et enregistré les erreurs générées. Nous avons également empêché le noyau de s’arrêter ou de redémarrer lorsque certaines erreurs étaient présentes. Le noyau gère 22 erreurs différentes, identifiées dans le P4080 comme des IVOR (Interrupt Vector Offset Register) : SRESET, Machine Check, DSI (Data Storage Interrupt), ISI (Instruction Storage Interrupt), ALG (Alignment), FPUNAV (Floating-Point Unavailable), DEC (Decrementor), PMC (Performance Monitor Controller), ITLB (Instruction TLB), DTLB (Data TLB), TIMER, Watchdog, Debug, Processor Doorbell, Processor doorbell critical, Guest Processor Doorbell, Guest Processor Doorbell Critical, Hypersyscall, Hypervisor Privilege, Program, trace et Non-Maskable Interrupt. A chacune de ces erreurs, nous avons ajouté quelques lignes de code pour incrémenter un compteur. Nous utilisons une zone de la mémoire accessible en lecture et écriture pour stocker ces valeurs de compteurs. Nous avons également ajouté un compteur pour compter le nombre de cycle (un cycle = 5ms) exécutés. De cette manière, nous avons exécuté plus d’un million de cycles (environ 1h30 d’exécution) puis nous avons comparé les résultats. 833.7.3 Résultats obtenus Ce programme Crashme a été exécuté pendant 1 043 806 cycles, ce qui nous permet de donner des statistiques fiables sur les comportements observés. Cette expérience nous a montré que parmi les 22 erreurs possibles, plus de 99,9% des erreurs sont des Program Exceptions. Le pourcentage restant est composé de 7 autres erreurs (Data TLB, Instruction TLB, DSI, ISI, Alignment, Hypervisor syscall et syscall) et il représente moins d’1% des erreurs. Les 14 autres erreurs ne sont jamais levées. Le tableau suivant indique comment le Health Monitor (HM) réagit lorsqu’une erreur apparaît et montre que beaucoup d’entre elles provoquent un redémarrage ou un arrêt du module. Même si le pourcentage d’apparition de ces erreurs est très faible comparé au pourcentage de l’erreur Program, qui elle provoque un simple redémarrage de la partition, leur nombre est elevé. Quasiment toutes les erreurs, autres que l’erreur Program provoquent un redémarrage ou un arrêt du module et donc un déni de service. Cette expérience est donc intéressante au sens où elle a montré que le mécanisme de traitement des erreurs devait clairement être amélioré de façon à mieux identifier la source de l’erreur et d’agir de façon adaptée. Ces problèmes ont ainsi été présentés à Airbus et ont été pris en compte de façon à corriger les mécanismes de traitement des erreurs. Type d’erreur % Red. partition Red. Mod. Arrêt module Program 99,92 v - - Data TLB 0,0475 v - - DSI 0,0252 - v v ITLB 0,0038 - v - ISI 0,00086 - - v Align 0,00134 - v - Hypervisor syscall 0,00067 - v - Syscall 0,00063 - - - Conclusion Nous avons vu dans ce chapitre de quoi était constitué la plate-forme d’expérimentation que nous avons utilisée. Nous avons également décrit plusieurs attaques réalisées sur ce système en utilisant différents canaux (gestion de la mémoire, communication, gestion du temps, mécanisme de tolérance aux fautes). Comme nous l’avons vu, plusieurs problèmes ont été identifiés, et ont été corrigés par Airbus après leurs découvertes. Ce cercle vertueux s’est ainsi montré très efficace pour améliorer la sécurité de ce noyau temps réel, d’autant plus que ces vulnérabilités, en général incluses dans du logiciel très bas niveau et liées à des mécanismes matériels propres de la plateforme, ne peuvent être détectées que grâce à ce type d’expérimentations et corrections. Dans le prochain chapitre, nous allons aborder les mécanismes de protection que l’on peut imaginer mettre en place pour faire face à ce genre d’attaques. Nous présenterons les contre-mesures spécifiques aux vulnérabilités que nous avons découvertes sur notre noyau particulier avec nos expérimentations adaptées à ce noyau. Elles seront présentées 84par type d’attaque. Ensuite, nous proposerons des contre-mesures les plus générique possibles, qui peuvent donc servir de recommandations de sécurité lors de l’implémentation d’un exécutif temps-réel désirant implémenter du partitionnement spatial et temporel. Enfin, nous présenterons une architecture sécurisée possible pour l’utilisation d’un périphérique réseau. 8586Chapitre 4 Protections des systèmes avioniques contre les malveillances Introduction Après avoir présenté dans les chapitres précédents, la classification des attaques possibles ciblant les couches basses logicielles des systèmes embarqués et après avoir mené des expérimentations mettant en œuvre de telles attaques, il est fondamental d’aborder pour terminer ce manuscrit, les mécanismes permettant de se protéger de ce type d’attaques. Nous allons donc détailler dans ce chapitre les différents mécanismes de protection que nous envisageons face à ces menaces. Nous commençons par proposer des contre-mesures spécifiques, qui permettent de nous protéger contre les attaques que nous avons mises en œuvre sur notre plateforme d’expérimentation. Ces contre-mesures spécifiques sont abordées dans la section 4.1 et elles sont présentées par type d’attaque (suivant notre classification des attaques du chapitre 2). Nous proposons ensuite, à partir de ces contre-mesures spécifiques, de dégager des grandes familles de mesures génériques, qui peuvent être appliquées de façon générale aux systèmes embarqués. Ces contre-mesures génériques sont abordées dans la section 4.2. Nous listons également des recommandations générales pour les développeurs de façon à éviter l’introduction de vulnérabilités lors de la phase de développement. Enfin, nous détaillons dans la section 4.3, une proposition d’architecture sécurisée pour une carte réseau AFDX afin de se protéger au mieux contre d’éventuelles attaques logicielles. Même si cette architecture est présentée à l’aide d’un exemple précis, elle a pour but de poser les bases d’une architecture générique sécurisée de pilote de périphé- rique pour systèmes embarqués. 874.1 Contre-mesures spécifiques à notre plateforme d’expé- rimentation Dans cette section, nous détaillons les contre-mesures adaptées à notre plateforme d’expérimentation P4080 qui permettent de se protéger contre les attaques suivantes : • les attaques ciblant la gestion de la mémoire ; • les attaques ciblant les communications ; • les attaques ciblant la gestion du temps ; • les attaques ciblant les mécanismes de tolérance aux fautes. 4.1.1 Attaques ciblant la gestion de la mémoire Dans la section 3.4, nous avons montré qu’un accès non limité au CCSR par les partitions peut avoir de graves conséquences sur le système. Rappelons que cette zone de 16Mo permet de configurer les composants du P4080. Elle contient entre autres la configuration de certains composants, comme le Security Engine ou encore le Run Control/Power Management. Ces composants peuvent redémarrer ou stopper le système si certaines valeurs dans les registres de cette zone sont positionnées. Ce choix d’implémentation concernant les droits d’accès au CCSR s’explique de la façon suivante. Dans l’implémentation actuelle du noyau, l’accès au CCSR est autorisé à toutes les partitions pour leur permettre d’envoyer/recevoir des messages via le réseau AFDX. Plus précisément, les communications AFDX sont effectuées via un transfert DMA initialisé en configurant certains registres du CCSR. Cette solution est en fait un moyen rapide pour fournir un accès AFDX aux partitions qui en ont besoin. La protection la plus évidente qu’il convient de préconiser consiste à apporter une modification sur les entrées de la MMU pour limiter les accès privilégiés de chaque partition au CCSR, mais cela empêche toute partition d’effectuer directement une communication AFDX. Cette solution doit donc s’accompagner de la création d’une partition dédiée aux communications AFDX. Cette partition est la seule partition (appelée “partition I/O”) permettant de communiquer directement sur le réseau AFDX. Les autres partitions né- cessitant des accès AFDX pourront alors avoir recours à cette partition en utilisant des mécanismes IPC (Inter Processus Communication). Ce choix d’architecture limite fortement les risques dûs aux malveillances concernant l’écriture dans la zone CCSR. La figure 4.1 illustre une telle implémentation. Sur ce schéma, les partitions P0 et P1 communiquent avec la partition I/O afin d’accéder à la carte AFDX. Le noyau gère toutes les autorisations. Il contrôle l’ensemble des données échangées et autorise ou non les partitions à établir des communications via l’AFDX. En revanche, la partition I/O doit être associée à un niveau de criticité élevé. De plus, cette partition est un passage obligé pour toute requête d’entrées/sorties sur le bus AFDX et cela a un impact en terme de performance temporelle. Nous ferons une autre proposition tout aussi sécurisée mais plus performante dans la section 4.3. Protéger efficacement la mémoire signifie aussi la protéger des accès DMA malveillants réalisés par les périphériques. Le P4080 dispose de plusieurs PAMUs (Platform 88Partitions Hyperviseur Matériel Carte réseau MMU - I/O MMU Partition I/O Partition 0 Partition 1 Partition 2 IPC DMA IPC Fig. 4.1 – Exemple d’accès entre 2 partitions et une partition I/O. Memory Management Units) qui sont identiques aux I/O MMUs (Input/Output Memory Management Units) présents sur les architectures Intel. Ces PAMUs permettent d’autoriser ou non les accès à la mémoire depuis les périphériques vers la mémoire mais aussi les accès de périphérique à périphérique. Cette protection se base sur l’affectation à chaque périphérique d’identifiants LIODN (Logical I/O Device Number) qui sont vérifiés par les PAMUs lors des accès à la mémoire. Chaque PAMU est configuré grâce à des tables, qui permettent de virtualiser la mémoire mais aussi d’attribuer des droits d’accès aux différentes zones de mémoire, de façon similaire aux tables de la MMU. 4.1.2 Attaques ciblant les communications Plusieurs attaques ciblant les communications sont détaillées dans la section 3.5. Les contre-mesures associées sont présentées en deux parties. La première partie est consacrée aux contre-mesures pour les attaques ciblant les communications AFDX et la deuxième partie est consacrée aux contre-mesures pour les attaques ciblant les IPC. 4.1.2.1 Communications AFDX Les communications AFDX permettent d’échanger des données entre modules via le réseau AFDX. Cependant, les mécanismes utilisés à l’heure actuelle possèdent un certain nombre de faiblesses et peuvent être corrompus (voir sous-section 3.5.1). Nous avons ainsi montré qu’il était possible depuis une partition qui utilise AFDX, de réaliser des accès DMA généralisés, de modifier des variables globales partagées entre partitions, ou encore de modifier le contenu des données de configuration qui sont envoyées au Flash Manager. La première contre-mesure que nous proposons, concernant les accès DMA, consiste à protéger l’accès au CCSR. Elle nécessite l’utilisation d’une partition I/O et elle a été explicitée dans la section précédente. La deuxième contre-mesure que nous proposons 89concerne l’accès à certaines variables globales depuis une partition qui utilise l’AFDX (partage qui est à l’origine d’une des attaques présentée dans le chapitre 3). Dans ce cas, nous préconisons de limiter l’accès de ces variables à la lecture uniquement. La modification de ces variables ne doit être effectuée que par le noyau, voire par la partition I/O. La troisième contre-mesure concerne la reprogrammation de la zone EEPROM par le Flash Manager. Il est nécessaire d’intégrer au Flash Manager un mécanisme de véri- fication d’intégrité des données utilisées pour la reprogramation. Cependant, l’absence de ce mécanisme aujourd’hui peut se justifier par la présence en amont de la vérification de ces données avant l’envoi au Data Loader. En effet, les données de reprogrammation sont particulièrement critiques puisqu’elle sont utilisées pour la reconfiguration complète du calculateur. Toutefois, ajouter un mécanisme supplémentaire de contrôle d’intégrité au moment de la reprogrammation nous semble pertinent, vu la criticité des données manipulées. 4.1.2.2 Communication IPC Nous avons également présenté des vulnérabilités dans l’implémentation des IPC, permettant à une partition d’invoquer des fonctions d’une autre partition. Il est possible de mettre en défaut ce mécanisme de différentes façons : (1) en invoquant l’appel-système de retour de la partition distante avant celui de la partition locale ; (2) en forçant le timer courant à s’arrêter pendant l’exécution de la fonction distante ; et (3) en modifiant le registre GPR 10 avant le premier appel-système. La première contre-mesure consiste à empêcher la partition distante d’invoquer l’appelsystème si l’appel-système de la partition locale n’a encore été invoqué. Pour cela, il est nécessaire de mémoriser et contrôler l’ordre des appel-système dans le noyau, en ajoutant des variables d’états contrôlées par le noyau. La figure 4.2 représente une implémentation possible des IPCs en utilisant un bit de vérification (noté b) et les mêmes appel-système que dans l’implémentation précédente (notés sc). Le noyau débute son initialisation en positionnant à 0 un bit par invocation possible entre une partition locale et une partition distante. Dans un comportement normal, l’appel-système de la partition locale est exécuté avant l’appel-système de la partition distante. Aussi, lors de l’appel-système, le noyau passe à 1 le bit correspondant. Lorsque l’appel-système de retour de la partition distante est exécuté, le noyau vérifie si le bit correspondant est à 1. Si tel est le cas, le retour dans la partition locale est autorisé. En revanche, dans le cas d’un comportement abusif, l’appel-système de retour de la partition distante est exécuté en premier. Au moment de la vérification par le noyau, le bit correspondant étant à 0, le retour dans la partition locale n’est pas autorisé. Ce mécanisme de vérification nécessite donc 1 bit par appel système entre chaque partition locale et chaque partition distante. L’occupation mémoire engendré est donc raisonnable et l’exécution des routines de vérification peut être réalisée en temps borné. Par conséquent, le coût de ce mécanisme de protection nous semble donc léger, bien adapté à un système temps réel et constitue donc une contre-mesure appropriée selon nous. En revanche, ce mécanisme ne prend pas en compte la possibilité d’avoir des 90Partition distante Partition locale Noyau Partition distante Partition locale Noyau Comportement normal : appel-système distant autorisé Comportement abusif : appel-système distant bloqué b = 0 b = 1 si b == 1 b = 0 si b == 1 sc sc sc Fig. 4.2 – Proposition de contre-mesure sur le mécanisme IPC. systèmes réentrants puisqu’un seul bit est considéré par appel-système. La deuxième contre-mesure que nous proposons vise à éviter un blocage dans le noyau lorsque le Global Timer expire pendant l’exécution de la fonction distante, qui a intentionnellement exécuté une boucle infinie. Cette contre-mesure consiste à améliorer la gestion des erreurs par le Health Monitor du noyau. Ce dernier peut par exemple détecter que dans le cas d’une IPC, l’instruction venant d’être exécutée provient de la partition distante (en fonction de l’adresse de cette instruction) et non de la partition locale. Il convient donc, soit de revenir dans la partition locale après l’appel à la fonction distante, avec un code d’erreur, soit d’arrêter la partition locale pour ne plus réaliser d’appel à la fonction. La troisième contre-mesure concerne le registre GPR10 qui est utilisé dans le code de la partition locale avant l’appel-système et qui est ensuite vérifié par le noyau. Ce registre étant un registre général sans privilège particulier, la partition peut modifier cette valeur. Ce registre devrait donc être un registre privilégié modifiable seulement par le noyau. 4.1.3 Attaques ciblant la gestion du temps Nous avons présenté dans la section 3.6 des attaques ciblant la gestion du temps. Celles-ci peuvent permettre à une partition malveillante d’allonger sa durée d’exécution, ce qui peut avoir pour conséquence de limiter la durée d’exécution de la partition suivante (en particulier lors de la phase de préparation de la partition suivante). Pour réaliser ce débordement, il suffit de provoquer une interruption à la fin de la tranche de temps de la partition malveillante. Cette interruption est traitée par le noyau, qui est non-interruptible. Par conséquent, l’ordonnancement des partitions est retardé. Il semble particulièrement difficile d’imaginer une contre-mesure technique à cette attaque. En revanche, on peut imaginer une contre-mesure concernant le calcul des WCET : il convient 91de prendre en compte la durée d’exécution de l’interruption la plus longue dans le calcul des différents WCET. Nous avons également montré qu’il est possible d’allonger la phase de préparation en utilisant un nombre très élevé d’entrées dans la MMU (pour utiliser un grand nombre de zones de mémoire différentes). La configuration de la MMU étant réalisée par le noyau, ce code est encore une fois non-interruptible, ce qui signifie qu’il est susceptible de poursuivre son exécution alors qu’un timer est en attente et que ce timer ne pourra déclencher une interruption que lorsque le processeur reprendra l’exécution de la boucle infinie en mode utilisateur. La contre-mesure que nous proposons ici est de limiter le nombre d’entrées dans la MMU directement par le générateur de code. Ceci empêche la création de trop nombreuses entrées sachant qu’il est très peu probable que toutes ces entrées soient réellement nécessaires. Il faut également que le temps de préparation de la partition prenne en compte le temps nécessaire à la configuration de toutes les entrées de la MMU. La figure 4.3 illustre les durées d’exécutions des partitions en prenant en compte les durées d’exécution des interruptions. 90 1410 1410 90 Durée d'exécution Compteur (CCR) Durée d'exécution réelle en comportement normal Durée d'exécution supplémentaire prévue en cas de comportement abusif Durée d'exécution de la plus longue interruption t (µs) Fig. 4.3 – Proposition de contre-mesure prenant en compte les durées d’exécution d’interruption. Sur la figure 4.3, nous présentons 2 partitions P6 et P7 avec leurs phases de pré- paration respectives W6 et W7. Les durées P6 et P7 sont constituées chacune de trois durées d’exécution : la durée d’exécution de la partition elle-même, la durée d’exécution de l’interruption la plus longue et enfin la marge de sûreté habituelle (de l’ordre de 20%). Pour les durées W6 et W7, il suffit de limiter le nombre d’entrées dans la MMU à une cinquantaine au maximum au lieu de 512 permises par défaut par la MMU. 4.1.4 Attaques ciblant les mécanismes de tolérance aux fautes Nous avons présenté dans la sous-section 3.7.1 la réalisation d’un programme Crashme qui nous a permis de détecter plusieurs dysfonctionnements dans le mécanisme de gestion des erreurs. Il est ainsi possible de redémarrer ou arrêter le module complet depuis une partition. Nous proposons de modifier le comportement du gestionnaire d’erreur pour 92ne pas autoriser de redémarrages intempestifs ou d’arrêt du module. Lorsqu’une erreur survient, le noyau doit sanctionner la partition à l’origine de l’erreur uniquement et non le module. Il doit donc établir un diagnostic de fautes très précis. La contre-mesure consiste à mieux identifier l’origine de l’erreur, ce qui est possible puisque le type de l’erreur est connu par le noyau ainsi que la partition concernée (le contexte d’exécution au moment du déclenchement de l’erreur). De cette façon, il a été possible de prendre des sanctions précises concernant uniquement l’origine de l’erreur et non plus des sanctions trop larges appliquées souvent à tout le module. Cette modification a été implémentée dans le noyau après nos expérimentations. Plus précisément, voici quelques éléments techniques qui ont été utilisés pour améliorer cette gestion des erreurs. Pour ce qui concerne l’origine de l’erreur, le cœur e500mc du P4080 comporte un mécanisme commun aux processeurs PowerPC : lorsqu’une interruption survient, le registre SRR0 contient la valeur de l’adresse qui a été interrompue41 et le registre SRR1 contient la valeur du registre MSR (Machine Status Register) qui contient le niveau de privilège actuel. Ces deux registres permettent notamment de se “repositionner” à l’instruction suivante avec les mêmes privilèges. Si une partition est la source de l’erreur, alors il est nécessaire d’arrêter le fonctionnement de cette partition. Si c’est le noyau qui en est la source, alors il est préférable de redémarrer ou d’arrêter le module complet car des défaillances à répétitions peuvent se produire. En ce qui concerne la nature de l’erreur, le registre ESR (Exception Syndrome Register) permet d’informer le noyau de la cause exacte de l’erreur (instruction illégale, instruction privilégiée, opération store, etc.). Le tableau 4.1 présente les résultats avec le nouveau gestionnaire d’erreurs. Type d’erreur % Redémarrage de Redémarrage Arrêt du la partition du module module Program 99,92 v - - Data TLB 0,0475 v - - Data Storage Int. 0,0252 v - - Instruction TLB 0,0038 v - - Instruction Storage Int. 0,00086 v - - Alignment 0,00134 v - - Hypervisor syscall 0,00067 - - - Syscall 0,00063 - - - Tab. 4.1 – Répartition des actions en fonction des types d’erreurs. Les taux d’erreurs sont identiques à l’ancienne version mais il n’est désormais plus possible de faire redémarrer ou arrêter le module depuis un code utilisateur d’une partition car la sanction se fait uniquement au niveau de la partition. En ce qui concerne 41Sauf en cas d’erreur imprécise. 93l’appel-système hyperviseur (hypervisor syscall), il ne fait pas redémarrer la partition, mais simplement passer à l’instruction suivante. Ce choix a été fait car cet appel système n’est pas une erreur en tant que tel, puisqu’il s’agit d’une instruction parfaitement légitime. Cependant, il est a priori improbable qu’elle soit invoquée dans notre système expérimental puisqu’aucun système d’exploitation invité n’y est présent. Dans cette section, nous nous sommes focalisés sur les contre-mesures spécifiques à notre plateforme d’expérimentation et aux attaques que nous avons pu mener. Il est possible de généraliser certaines de ces contre-mesures de façon à proposer des mécanismes de protection génériques, adaptés à différents types de systèmes embarqués. C’est l’objet de la section suivante. 4.2 Contre-mesures génériques Dans cette section, nous commençons par proposer des contre-mesures génériques adaptables à différents systèmes embarqués, face aux attaques suivantes : • les attaques ciblant le processeur ; • les attaques ciblant la gestion de la mémoire ; • les attaques ciblant les communications ; • les attaques ciblant la cryptographie ; • les attaques ciblant les fonctions ancillaires ; • les attaques ciblant les mécanismes de tolérance aux fautes. Ensuite, nous proposons de compléter ces contre-mesures par des recommandations aux développeurs (voir section 4.2.8). En particulier, nous présentons brièvement les techniques d’analyse statique (voir sous-section 4.2.9), qui permettent de vérifier le code source de l’applications et des techniques d’analyse dynamique (voir sous-section 4.2.10) qui permettent d’analyser l’exécution en temps-réel de l’application. 4.2.1 Attaques ciblant le processeur Le rôle central du processeur dans le système en fait un composant souvent ciblé par les attaques. Effectivement, la compromission du processeur permet soit d’exécuter un code malveillant, soit de porter atteinte à l’intégrité des périphériques. La plupart des contre-mesures présentées dans cette sous-section visent à consolider les configurations des différents éléments qui composent le processeur (cache, mécanisme de synchronisation, gestionnaire des interruptions, etc.). Les accès aux périphériques et à la mémoire centrale étant plus lents que la vitesse de fonctionnement du processeur, des mémoires caches avec des vitesses de fonctionnement intermédiaires sont utilisées comme espace de stockage temporaire. Ces espaces de stockage sont partagés entre les différents processus 42 qui s’exécutent sur le processeur. Il est important que, lors du changement de contexte, le contenu de ces caches soit complètement vidé. Cette contre-mesure assure qu’un processus malveillant ne puisse pas 42Le terme processus est utilisé au sens large et fait référence à une tâche, une partition, etc. 94stocker dans une des mémoires caches des instructions machines en espérant que le processeur les exécutera en pensant qu’elles correspondent aux instructions machines d’un autre processus. De plus, si la propriété de confidentialité est importante à assurer dans le système, le vidage du contenu des mémoires caches doit être réalisé indépendamment du contenu de ces mémoires. Les processeurs modernes sont également structurés en plusieurs cœurs pour l’exécution en parallèle des instructions. Sur la plupart des architectures, chaque cœur dispose de son propre gestionnaire d’interruptions (nommé Local APIC sur les architectures Intel). La synchronisation entre ces cœurs est également assurée via ces gestionnaires d’interruptions. La configuration de ces gestionnaires doit être réalisée lors de l’initialisation du noyau du système et elle doit être accessible uniquement par ce noyau. De la sorte, un processus ne peut pas envoyer des interruptions pour, par exemple, arrêter un des autres cœurs. Tous les cœurs du processeur doivent être initialisés. Cette initialisation peut être mise en place par une chaîne de confiance au démarrage. A titre d’exemple, pour la mise en place d’une chaîne de confiance, le processeur P4080 peut utiliser le composant Security Monitor et les processeurs Intel peuvent utiliser le composant TPM. Le processeur doit pouvoir exécuter des instructions machines privilégiées (telles que les instructions de manipulation des registres de configuration) uniquement si le niveau de privilège du processeur est lui-même élevé. Pour assurer ce contrôle, deux principaux mécanismes de protection doivent être configurés : les anneaux de protection (ring) avec la segmentation et les droits d’accès à la mémoire avec la pagination. L’anneau le plus privilégié doit correspondre aux instructions du noyau et toutes les instructions du noyau doivent être associées à cet anneau. Quant à la pagination, elle permet de protéger ces instructions de manière à empêcher un processus malveillant de les modifier dans le but de faire exécuter une séquence d’instructions malveillante au processeur. Les processeurs modernes disposent de plusieurs modes de fonctionnement (par exemple, pour la gestion des ressources, pour la virtualisation, etc.). Les processeurs du grand public intègrent également des modes historiques pour des raisons de rétrocompatibilités pour les logiciels. Il est important que le noyau configure tous ces modes. Les modes qui ne sont pas utilisés par le système doivent aussi être configurés et figés. Cette contre-mesure empêche des attaques de profiter des modes du processeur qui ont été ignorés par le noyau pour exécuter des actions en contournant les mécanismes de protection des modes effectivement configurés. Plus généralement, une contre-mesure importante est l’analyse du point de vue de la sécurité de la spécification du processeur, lorsque cette spécification est connue du développeur du système. Cette spécification peut correspondre au code VHDL utilisé pour la conception. Par exemple, le code VHDL du processeur Leon3 est disponible pour permettre aux développeurs d’y intégrer des modifications. Avoir à disposition la spécification d’un processeur permet d’identifier des vulnérabilités (généralement des instructions qui ne sont pas – ou mal – documentées). Par la suite, l’idéal est de modifier la spécification du processeur pour éliminer ces vulnérabilités. Si cette option n’est pas envisageable, ces vulnérabilités doivent alors être contenues par des mécanismes de pro- 95tection adaptés et intégrés dans le noyau du système. Lorsque cette spécification n’est pas connue du développeur du système, une analyse de vulnérabilités doit tout de même être réalisée en utilisant des outils de fuzzing. Le programme Crashme en est un bon exemple. Les vulnérabilités identifiées par ces outils doivent être également contenues par des contre-mesures à intégrer dans le noyau du système. 4.2.2 Attaques ciblant la mémoire La mémoire d’un système correspond à l’ensemble des mémoires accessibles depuis le processeur. Il s’agit de la mémoire centrale (habituellement nommée RAM) et de la mémoire des périphériques (par exemple, les registres des périphériques PCI-Express). Ces mémoires peuvent être directement manipulées par le processeur mais elles peuvent aussi être manipulées via des transferts DMA (Direct Memory Access). Par exemple, dans le cas d’un transfert DMA, un périphérique peut recopier le contenu d’un tableau en mémoire centrale sans passer par le processeur. Ces mémoires sont donc manipulées par différents processus et périphériques de différents niveaux de criticité. Dans la suite, le terme composant fait référence à un processus ou un périphérique. Une zone mémoire peut être attribuée de manière exclusive à un composant ou peut être partagée par plusieurs composants. Pour empêcher un composant d’interférer avec l’espace mémoire attribué et manipulé par un autre composant, il est nécessaire de mettre en place des contre-mesures. Le premier accès réalisé à une zone de la RAM attribuée de manière exclusive à un processus doit toujours être une écriture. Autrement dit, l’initialisation d’un processus doit toujours débuter par une écriture dans la zone mémoire pour placer l’environnement d’exécution du processus dans un état déterministe. De la même manière, dans le cas de l’allocation dynamique ou de l’attribution temporaire d’une zone mémoire par le noyau, le processus doit avant toute manipulation de ces nouvelles zones mémoires, placer leur contenu dans un état déterministe. Ces bonnes pratiques empêche un processus de copier un contenu dans une zone mémoire de manière à interférer avec un autre processus qui récupèrera un accès à cette zone mémoire. Les mécanismes de pagination et de segmentation de la MMU (Memory Management Unit) doivent être mis en place par le noyau pour assurer le partitionnement spatial de la mémoire des processus. Ces mécanismes permettent tout d’abord de virtualiser la mémoire et ensuite d’indiquer quels sont les droits d’accès à la mémoire (lecture, écriture ou exécution). La mise en place de la mémoire virtuelle consiste à construire une fonction de traduction entre une adresse virtuelle (manipulée par le processus) et une adresse physique. La granularité de cette fonction est la page mémoire (il s’agit d’une unité correspondant à 4ko). Il existe donc les pages mémoires virtuelles et les pages mé- moires physiques. Les droits d’accès aux pages mémoires sont indiqués directement dans la fonction de traduction. Il est important de noter qu’il est possible de construire des fonctions différentes pour les différents processus. Lors de la construction de chaque fonction, seules les pages mémoires physiques contenant des données d’un processus doivent avoir une page mémoire virtuelle comme image. Aussi, pour faciliter la mise en place de ces fonctions, le noyau doit charger les processus de manière à ne pas partager une page 96mémoire physique entre plusieurs processus. Dans le cas de la mémoire partagée, une page mémoire contenant uniquement les données partagées entre les processus doit être créée. Ce mécanisme de protection met en place le partitionnement spatial pour les accès mémoire depuis le processeur. Il doit s’accompagner d’un mécanisme complémentaire pour les accès réalisés avec les périphériques. De la même manière que précédemment, une fonction de traduction peut être mise en place pour les accès entre les périphériques et la mémoire centrale. Ces fonctions sont construites en configurant une MMU pour les entrées-sorties (I/O MMU sur les architectures Intel et PAMU sur le P4080). Si un périphérique est partagé entre plusieurs processus et que la virtualisation du matériel n’est pas disponible (cf. section 4.3), il est alors plus pertinent de construire un processus dédié aux communications avec le périphérique : un pilote de périphérique. Les autres processus peuvent alors invoquer les services de ce pilote de périphérique. Tout comme pour la configuration de la MMU précédente, les fonctions doivent uniquement permettre à un périphérique d’accéder aux pages de la mémoire physique qui le concerne. De la sorte, le système est prémuni des attaques via les transferts DMA. 4.2.3 Attaques ciblant les communications Les mécanismes de communications permettent à différents processus d’échanger de l’information. Ces échanges doivent être contrôlés de manière à s’assurer qu’un processus peut toujours envoyer ses données et qu’un processus peut recevoir des données. Autrement dit, il ne faut pas qu’un processus puisse empêcher un autre processus d’envoyer des données ou qu’un processus puisse recevoir les données destinées à un autre processus. Des mécanismes de protection doivent être mis en place pour garantir que ces propriétés sont bien assurées. Pour permettre aux mécanismes de protection de contrôler les messages échangés, il est nécessaire que les mécanismes de communication associent aux messages les identités de la source et de la destination. Ces informations ne doivent pas être fixées par la source elle-même. Elles doivent être fixées par un composant associé au plus haut niveau de confiance et incontournable pour l’échange de messages. Ce composant peut être le noyau qui peut être sollicité par des appels-système pour permettre les échanges. Le verdict associé à la tentative d’envoi d’un message doit se baser sur une liste de contrôle des accès, idéalement construite statiquement lors de la phase de conception et de compilation des différents composants du système. Quel que soit le type de communication mis en place entre les processus (communication asynchrone ou synchrone), un processus ne doit pas pouvoir submerger le récepteur au point de l’empêcher d’échanger à son tour des informations avec d’autres processus. Pour éviter cette situation, chaque processus doit disposer d’autant de boîtes aux lettres que de processus avec lesquels il peut communiquer. Le noyau peut alors poster le message dans la boîte aux lettres du destinataire correspondant au processus source. Ainsi, un débordement d’une boîte aux lettres issu d’une activité malveillante nuit uniquement au processus source. Le message échangé entre les processus doit pouvoir être analysé entièrement par le 97noyau. Le processus ne doit pas pouvoir utiliser un pointeur vers sa mémoire virtuelle pour indiquer au noyau le contenu du message. De plus, il est préférable que le message à échanger entre deux processus soit contenu dans une page mémoire dédiée. Ainsi, si le noyau associe cette page mémoire à la mémoire virtuelle du processus destinataire (à la manière des blackboards), ce dernier n’aura accès qu’au message. 4.2.4 Attaques ciblant la gestion du temps Les contre-mesures aux attaques ciblant la gestion du temps correspondent aux mé- canismes permettant de protéger la politique d’ordonnancement. Ces contre-mesures doivent donc être directement intégrées dans le noyau et elles entraînent nécessairement l’exécution de routines supplémentaires. La première contre-mesure correspond à la gestion de la sauvegarde du contexte d’un processus. L’espace mémoire associé doit être entièrement géré par le noyau et ne doit pas être accessible au processus. Par exemple sur les architectures Intel, en adoptant ce principe, un processus ne peut pas modifier le contenu du registre cr3 (il s’agit d’un registre permettant de contrôler la traduction entre une adresse virtuelle et une adresse physique). La seconde contre-mesure concerne le calcul du temps d’exécution d’un processus durant un cycle de l’ordonnanceur. Ce temps (le WCET) doit prendre en compte non seulement la durée d’exécution des instructions du processus mais également la durée d’exécution des routines permettant de configurer le matériel. Plus précisément, il est nécessaire de considérer la durée nécessaire pour re-configurer les composants matériels (MMU, périphériques, caches) et la durée d’exécution de l’interruption la plus longue. 4.2.5 Attaques ciblant la cryptographie Les attaques ciblant la cryptographie visent généralement à obtenir les clés privées incluses dans les fonctions cryptographiques voire à interférer avec les méthodes permettant de générer des nombres aléatoires. Pour empêcher un processus d’obtenir ces clés, il est nécessaire d’éviter les fuites d’information en vidant systématiquement les caches du processeur lors des changements de contexte. De cette manière, un processus malveillant ne peut pas se baser sur le contenu du cache pour déduire des informations sur les clés manipulées par le processeur. Un processus ne doit pas pouvoir deviner (totalement ou partiellement) la valeur d’un nombre aléatoire obtenu par un autre processus. Le service permettant de délivrer ces valeurs doit donc être implémenté dans un espace de confiance qui peut être un processus dédié ou le noyau. Ce service doit également, dans la mesure du possible, se baser sur un générateur aléatoire matériel pour empêcher les autres processus de surcharger le système dans le but de restreindre l’intervalle des valeurs que le service peut retourner. 4.2.6 Attaques ciblant les fonctions ancillaires Rappelons que les fonctions ancillaires correspondent à la gestion de l’alimentation, de l’over-clocking, du contrôle de température, etc. Sur les architectures x86, ces fonc- 98tions sont assurées dans un mode dédié du processeur : le mode SMM. Ce mode dispose d’un accès privilégié au système (dans la limite des quatre premiers giga-octets de mé- moire). Il a été la cible de plusieurs attaques. Pour éviter ces attaques, les fondeurs de processeurs x86 proposent un mécanisme permettant de verrouiller la mémoire contenant les instructions exécutées par ce mode. Il est important que ce mode soit configuré et verrouillé. 4.2.7 Attaques ciblant les mécanismes de tolérance aux fautes Comme nous l’avons montré dans la section 2.2, les attaques ciblant les mécanismes de tolérance aux fautes peuvent cibler le traitement d’erreur et le traitement des fautes. Nous allons proposer quelques contre-mesures génériques permettant de se défendre d’attaques ciblant ces mécanismes. Nous ne serons pas exhaustifs dans cette partie, puisque ce sont les attaques que nous avons pu le moins expérimenter, étant donné que le système expérimental dont nous disposions, contenait peu de mécanismes de tolérance aux fautes (il aurait fallu que nous disposions de plusieurs versions du calculateur pour utiliser la redondance par exemple, ce qui n’a pas été possible dans notre plateforme). 4.2.7.1 Traitement des fautes Concernant le traitement de fautes, on peut généraliser la contre-mesure mise en place dans le cas spécifique de notre expérimentation. Il est fondamental que le diagnostic de fautes soit le plus précis possible, de façon à identifier avec certitude l’origine des erreurs et donc le composant fautif. Cette contre-mesure, qui a été mis en place dans notre expérimentation et qui a permis d’améliorer la gestion des erreurs, a pour vocation d’empêcher une application malveillante de déclencher volontairement de multiples erreurs dans l’espoir de provoquer un redémarrage complet du système. La reconfiguration fait également partie du traitement de fautes. Cette reconfiguration intervient en général après identification et passivation d’un ou plusieurs composants fautifs et consiste à modifier la configuration du système pour qu’il puisse continuer à fonctionner (éventuellement en mode dégradé) sans faute. Elle est suivie d’une phase de réinitialisation dans laquelle la nouvelle configuration est enregistrée dans le système. Un attaquant ciblant la reconfiguration et réinitialisation peut tenter d’accéder à la zone mémoire où se situe cette configuration de façon à faire redémarrer le système dans une configuration incorrecte. Une contre-mesure face à ce type d’attaques est de choisir avec précaution la zone de mémoire dans le système où est stockée cette configuration. Cela fait intervenir une nouvelle fois la configuration précise de la MMU. 4.2.7.2 Traitement d’erreurs En ce qui concerne les différents mécanismes de traitement d’erreurs, on peut tout d’abord envisager des contre-mesures visant à se protéger d’attaques ciblant la détection d’erreurs. Par exemple, la duplication et la comparaison est un mécanisme efficace de tolérance aux fautes accidentelles mais il est relativement facile à contourner par une 99application malveillante. En revanche, la diversification fonctionnelle est un mécanisme efficace de détection d’erreur, même vis-à-vis des fautes intentionnelles. Il est donc à privilégier lorsque l’on s’intéresse aux malveillances. Il est en effet très difficile pour un attaquant, d’imaginer une attaque efficace qui puisse avoir les mêmes effets sur des matériels et logiciels diversifiés. Cette diversification a d’ailleurs déjà fait ses preuves vis-à-vis des malveillances dans d’autres contextes, comme dans le cadre d’opérations de maintenance des futurs architectures avions [Laa09], ou dans le cadre d’applications Web par exemple [Sai05]. En ce qui concerne les mécanismes de recouvrement d’erreurs et plus précisément la reprise, il nécessite, comme nous l’avons vu dans les précédents chapitres, l’existence de points de reprise (aussi appelés points de restauration). De façon à éviter qu’un attaquant puisse modifier ces points de reprise, une contre-mesure consiste à utiliser une zone de mémoire protégée pour stocker les points de reprise, de façon à que cette zone ne soit pas modifiable par les différentes partitions. Cela signifie qu’ils devront probablement être stockés dans l’espace du noyau. En ce qui concerne la corruption potentielle des mécanismes de poursuite, qui provoquerait volontairement le passage en mode dégradé du système, une contre-mesure possible consiste à disposer d’un mécanisme de diagnostic de fautes très précis. Si le diagnostic de fautes évalue avec certitude l’origine d’erreurs à répétition (provoquées dans le but de passer le système en mode dégradé), il peut alors sanctionner l’application (en l’occurrence malveillante) et non le système complet. 4.2.8 Recommandation aux développeurs Les contre-mesures proposées dans les sous-sections précédentes visent à intégrer des mécanismes de protection architecturaux. Il est bien sûr nécessaire de compléter ces mé- canismes par des bonnes pratiques de développement, permettant d’éviter l’introduction de vulnérabilités dans le logiciel ou de détecter leur présence. Ces bonnes pratiques sont déjà bien sûr préconisées pour détecter les fautes accidentelles (bugs) mais elles sont également fondamentales pour détecter les fautes intentionnelles. Notre objectif dans cette section est simplement de lister les bonnes pratiques de développement qui nous semblent les plus importantes vis-à-vis de l’identification de vulnérabilités. Deux d’entre elles sont notamment l’analyse statique et l’analyse dynamique de code. Elles sont l’objet de cette sous-section. Cette sous-section ne prétend pas faire une étude exhaustive de ces analyses (ce qui nécessiterait un chapitre complet) mais plutôt de souligner l’importance de leur utilisation lors du développement de systèmes embarqués. 4.2.9 Analyse statique L’analyse statique vise à détecter dans le code source du programme cible d’éventuelles fautes. L’identification de ces fautes est utile à la fois du point de vue de la tolérance aux fautes mais aussi du point de vue de la sécurité. En effet, leur identification durant la phase de développement permet de réduire de façon considérable les fautes 100de conception et ainsi de réduire les vulnérabilités exploitables dans le code source. Plusieurs classes de défaut sont identifiées par les outils d’analyse statiques [CE09]. Parmi celles-ci, nous pouvons citer les divisions par zéro, les fuites de mémoire, les déré- férencement de pointeur nul, les variables non-initialisées, les débordements de tampons, et les typages (cast) inappropriés. Elles correspondent aux fautes les plus couramment rencontrées dans les codes. Certains outils d’analyse statique de code sont capables de détecter la majorité de ces classes de défaut mais ils sont aussi capables de vérifier la conformité du code vis-à- vis de certains standards de développement. A titre d’exemple, Prevent43, Polyspace44 ou Astrée45, peuvent effectuer ces vérifications avec des langages comme C, C++, Java ou Ada. MALPAS Software Static Analysis Toolset46 effectue des vérifications similaires pour le code assembleur PowerPC. En particulier, pour notre étude, l’analyse statique peut être réalisée sur le code source du noyau ainsi que sur les codes source des partitions, qu’ils soient écrits en C ou en assembleur PowerPC. Nous pouvons également vérifier et analyser les fichiers de configuration utilisés pour paramétrer le noyau. En effet, ces fichiers de configuration contiennent des informations sur les zones de mémoires utilisées, les tranches de temps allouées aux partitions ou encore la gestion des erreurs (Health Monitor). Nous avons d’ailleurs régulièrement utilisé l’analyse statique de code dans le cadre de nos expérimentations sur la plateforme P4080 et le noyau expérimental d’Airbus dont le code source nous a été fourni (ce qui nous a donc permis de réaliser ce type d’analyse). Même si nous n’avons pas systématiquement utilisé d’outils automatiques, ce type d’analyse nous a permis d’identifier des vulnérabilités intéressantes, en ce qui concerne la gestion des IPC par exemple et s’est donc révélé particulièrement efficace. 4.2.10 Analyse dynamique L’analyse statique peut être complétée par l’analyse dynamique dont l’objectif est également l’identification de vulnérabilités mais en se basant sur l’observation du comportement du programme durant son exécution. Des outils comme Valgrind47 et mpatrol48 sont des exemples de logiciels permettant de détecter des fuites de mémoire en se basant par exemple sur l’observation des invocations à des bibliothèques standards telle que la libc. Une technique courante consiste à analyser le comportement d’un programme en l’exécutant en premier lieu dans un environnement restreint, dans lequel chaque accès à la mémoire et chaque entrée/sortie est contrôlé. Cet environnement peut prendre différentes formes, par exemple les sandbox Java ou les Jails des systèmes BSD. Cela peut aller jusqu’à l’utilisation des machines virtuelles complètes. Ceci est notamment couramment 43http://www.coverity.com 44http://www.mathworks.fr/products/polyspace/ 45http://astree.ens.fr 46http://www.malpas-global.com 47http://valgrind.org 48http://mpatrol.sourceforge.net/ 101utilisé par les éditeurs d’anti-virus, qui analysent en détail toute nouvelle génération de code malveillant (en particulier auto-reproducteurs) dans des machines virtuelles dédiées, de façon à confiner l’exécution de ce type de maliciels. Dans le cadre de nos expérimentations sur la plateforme P4080, nous avons réguliè- rement utilisé l’analyse dynamique, notamment pour vérifier s’il était possible de rompre l’isolation temporelle des partitions et pour analyser le comportement du noyau ou des différentes partitions critiques en présence d’une partition malveillante qui tente d’injecter des erreurs. L’analyse dynamique nous a permis d’identifier de nombreux problèmes de déni-de-service notamment. 4.3 Proposition d’une architecture sécurisée pour la gestion d’un périphérique partagé Comme nous l’avons vu dans cette thèse, plusieurs attaques sont liées à la volonté de partager un périphérique, en l’occurrence la carte AFDX dans notre plateforme d’expérimentations, entre partitions de différents niveaux de criticité. Ce partage est réalisé par deux mécanismes : échange d’informations avec le périphérique via des accès DMA et partage du pilote logiciel du périphérique entre les partitions. En particulier, dans la version préliminaire du noyau d’Airbus, le partage du pilote logiciel est réalisé via la création d’une mémoire partagée entre les différentes partitions et le pilote. Il s’agit d’une solution temporaire pour laquelle nous proposons une amélioration dans cette section. Cette solution permet d’implémenter des mécanismes de protection efficaces vis-à-vis des accès aux périphériques partagés entre partitions et est basée sur une architecture matérielle particulière. Cette proposition d’architecture n’a pas été expérimentée dans le cadre de cette thèse mais elle a toutefois été discutée en collaboration avec des ingénieurs d’Airbus. Nous présentons tout d’abord le principe général de cette solution, basée sur des technologies matérielles de virtualisation. Cette technologie est aujourd’hui implémentée dans un certain nombre de cartes réseaux (de type Ethernet) mais pas à notre connaissance pour des cartes AFDX. Nous présentons cette technologie, baptisée Single Root I/O (technologie qui n’a donc pas été spécifiquement développée pour des applications embarquées), dans la première partie de cette section. Nous présentons ensuite son utilisation dans un système avionique embarqué, utilisant le principe du partitionnement spatial et temporel. 4.3.1 Principe L’architecture sécurisée que nous proposons est basée sur des technologies maté- rielles d’assistance à la virtualisation. Ces technologies sont déjà relativement matures et utilisées sur les processeurs récents, et favorisent grandement le développement de gestionnaires de machines virtuelles (aussi appelés hyperviseurs). Elles portent respectivement le nom d’Intel-VTx ou AMD-V pour les processeurs des familles Intel et AMD. Elles sont par ailleurs déjà mises à profit dans plusieurs études au service de la sécurité 102des systèmes informatiques. Plusieurs hyperviseurs de sécurité ont ainsi été proposés dans différents travaux [M+10, LD11, S+09a] et ont souvent pour but d’assurer une protection efficace vis-à-vis de corruptions des couches basses du logiciel. Ainsi, souvent, les hyperviseurs de sécurité visent à protéger le noyau du système d’exploitation luimême, qui en principe, est le logiciel le plus privilégié, mais aussi le plus sensible d’un système informatique. L’idée principale derrière ces travaux réside dans le fait qu’il est très difficile de corrompre un hyperviseur utilisant des technologies d’assistance maté- rielle à la virtualisation puisque ces technologies sont considérées comme très difficiles à contourner, contrairement à des mécanismes de protection logiciels. L’architecture que nous proposons ici utilise également des techniques de virtualisation, mais au niveau des périphériques cette fois-ci. Ces mécanismes de virtualisation fonctionnent en coopération avec les mécanismes de virtualisation du processeur principal de la machine sur laquelle est connectée le périphérique. Ces mécanismes matériels incontournables et cette coopération sont selon nous une base solide pour assurer la sé- curité d’un périphérique. Elle est encore très peu déployée aujourd’hui et nous semble un atout important qu’il est utile de considérer dès aujourd’hui pour l’amélioration de la sécurisation des systèmes embarqués avioniques. 4.3.2 Virtualisation matérielle d’un périphérique : Single Root-I/O Virtualization Un certain nombre de périphériques réseau implémentent aujourd’hui une technologie de virtualisation matérielle baptisée Single Root-I/O Virtualization (SR-IOV). La carte Intel 82599EB 10Gb 49, qui peut être connectée sur un port PCIe, en est un exemple. La virtualisation SR-IOV permet, à partir d’une unique carte physique, d’exposer de multiple cartes virtuelles, pouvant être mises à disposition de différentes machines virtuelles. La virtualisation SR-IOV est plus précisément une extension de la spécification du protocole PCIe qui permet à différentes machines virtuelles de partager les mêmes ressources physiques PCIe. La figure 4.4 représente cette architecture. Les accès à ces ressources physiques sont donc virtualisés au travers de l’invocation de différentes fonctions PCIe : • Une fonction physique (PF) correspond à l’exposition sur le bus PCI-Express du périphérique réel ainsi que la totalité de ses ressources ; cette fonction est destinée à être accessible uniquement par du logiciel privilégié (typiquement l’hyperviseur s’exécutant sur le processeur principal ou à une machine virtuelle privilégiée de type Dom0 de Xen par exemple) mais non accessible aux machines virtuelles ; • Une ou plusieurs fonctions virtuelles (VF) exposent à une machine virtuelle une carte virtuelle qui correspond à un sous-ensemble de ressources de la carte physique. A chaque PF et VF, est associé un identifiant Express Request ID ou RID unique, 49http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ 82599-10-gbe-controller-datasheet.pdf 103Fig. 4.4 – Architecture de virtualisation Single Root I/O [sri]. qui permet à l’unité de traitement de entrées/sorties (comme l’I/O MMU sur Intel ou les PAMU sur le P4080) de distinguer les différents flux d’informations et d’appliquer des translations aux accès mémoires et aux interruptions concernant la PF et les VFs. L’intérêt de cette technologie est surtout un gain en performance. Effectivement, les requêtes PCIe sont directement acheminées entre les machines virtuelles et les VFs associées, par DMA, sans nécessiter une émulation logicielle par l’hyperviseur (cette émulation induit un surcoût en performance). Cela permet également de limiter la taille de l’hyperviseur ainsi que sa complexité. Pour pouvoir exploiter pleinement la technologie SR-IOV, il y a un certain nombres de contraintes que l’architecture matérielle, en particulier la MMU et l’I/O MMU, doivent respecter. Tout d’abord, il est nécessaire que l’I/O MMU soit capable de distinguer les opérations réalisées par les différentes cartes virtuelles (associées à des machines virtuelles différentes). Pour cela, il est nécessaire que l’I/O MMU implémente ses contrôles d’accès à la granularité de la fonction PCIe pour que les différentes machines virtuelles n’aient accès qu’à leur carte virtuelle dédiée (caractérisée par leur VF). Ceci permet d’autoriser très précisément les accès DMA notamment, en fonction de l’identifiant de VF inclus dans la requête PCIe. Il est également nécessaire que la gestion des interruptions par l’I/O MMU soit effectuée finement : elle doit être capable de distinguer les interruptions provenant des cartes virtuelles (c’est-à-dire des différentes VFs) de façon à les rediriger correctement vers la machine virtuelle associée (on parle d’IRQ remapping). Ensuite, 104l’utilisation correcte de SR-IOV impose aussi des contraintes sur la gestion des ressources au niveau de la MMU. En effet, la configuration des différentes VFs est projetée en mémoire en utilisant la technologie MMIO (Memory Mapped IO). Or, il est fondamental que chaque machine virtuelle puisse accéder à la configuration de sa VF mais surtout qu’elle ne puisse pas accéder à la configuration des VFs des autres machines virtuelles. Aussi, dans la mesure où la granularité des protections de la mémoire gérées par la MMU est la page (de taille 4ko), il est fondamental que les différentes VFs puissent être mappées sur des pages mémoires différentes de façon à bénéficier des protections dédiées par la MMU. Ces exigences, ainsi que quelques autres, que nous ne citons pas ici pour ne pas entrer dans trop de détails d’implémentations, sont bien détaillées dans un article de 2013 de Münch et al. ([MIM+13]). 4.3.3 Utilisation de SR-IOV dans un contexte avionique embarqué Dans un contexte avionique utilisant le partitionnement, l’adoption d’un périphérique de type SR-IOV doit s’adapter à l’architecture logicielle utilisée. Ainsi, dans ce contexte, chaque machine virtuelle correspond à une partition différente. Ces différentes partitions non privilégiées, appelées partitions “enfants”, ont accès chacune à une carte virtuelle différente représentée par sa VF. L’association de ces VFs aux partitions est réalisée par un logiciel privilégié, typiquement le noyau du système embarqué lui même, ou une partition de contrôle privilégiée, ainsi que le propose par exemple Münch et al. dans [MIM+13]. Cette partition de contrôle est associée à la fonction physique PF et peut ainsi avoir accès à l’ensemble des ressources de la carte ainsi qu’à sa configuration. Le partitionnement spatial est réalisé en utilisant la MMU et l’I/O MMU. Dans une architecture SR-IOV, nous avons listé ci-dessus un certain nombre de contraintes techniques qui doivent être respectés pour que leur utilisation soit efficace. Ces contraintes permettent en fait de séparer les contextes des partitions, car une partition ne doit pas être capable d’avoir accès au contexte (ensemble de registres) d’une autre partition. De son côté, l’hyperviseur ou la partition de contrôle doit gérer ses propres variables mais aussi des variables globales pour les autres partitions. Si les contraintes listées ci-dessus concernant la MMU et l’I/O MMU sont respectées, l’isolation spatiale est assurée efficacement entre partitions. Si l’on prend l’exemple de la plateforme d’expérimentation utilisée dans cette thèse, basée sur le P4080, ces contraintes ne sont pas respectées puisqu’elle inclut bien une MMU et un certain nombre de PAMUs mais ces PAMUs ne sont pas capables d’établir des contrôles d’accès basés sur des identifiants de fonctions PCIe. Les PAMUs sont capables de faire des vérifications uniquement en fonction de l’identité PCIe du périphérique lui-même. Ainsi, dans le cadre de l’utilisation du P4080, il est nécessaire d’enrichir le noyau du système embarqué de façon à pallier ce problème. De même, en ce qui concerne les interruptions, il est nécessaire, comme nous l’avons invoqué précédemment, que l’architectrure offre la possibilité de gérer l’IRQ Remapping de façon fine, basée sur l’identification de fonctions PCIe, ce qui encore une fois n’est pas le cas de la plateforme basé sur le P4080 utilisée dans cette thèse et qui implique 105donc une prise en charge supplémentaire du noyau de système embarqué. Enfin, le partitionnement temporel doit s’effectuer avec la prise en compte des durées d’exécution de la carte réseau elle-même pour traiter les paquets. Cette durée d’exécution doit avoir un impact minimal sur la durée d’exécution des partitions. En effet, en l’absence de périphérique SR-IOV, habituellement les entrées/sorties sont gérées par une partition I/O qui doit donc traiter les problèmes d’accès concurrents des différentes partitions au périphérique, et qui doit donc assurer l’isolation spatiale et temporelle. Dans le cas d’un périphérique SR-IOV, les différentes partitions accèdent directement à leur périphérique virtuel et c’est donc au périphérique de gérer l’isolation temporelle directement. Il est donc fondamental d’éviter qu’une partition ayant un accès légitime à sa carte virtuelle (via la VF associée) puisse empêcher une autre partition de pouvoir émettre ou recevoir dans son quantum de temps imparti, de façon à assurer le partitionnement temporel. Cela nécessite en particulier que le périphérique offre la possibilité au noyau du système embarqué (ou à la partition de contrôle en fonction du choix d’architecture effectué) d’annuler ou de suspendre une commande (opération d’envoi ou de réception demandée à la carte) mais aussi de gérer l’accès simultané de plusieurs partitions. En conclusion de cette section, on peut affirmer que si l’ensemble des contraintes relatives à la MMU et l’I/O MMU sont bien respectés sur la plateforme matérielle, l’utilisation d’un composant de type SR-IOV, en particulier pour les communications AFDX des systèmes embarqués avioniques, s’avère être une solution efficace (à la fois en termes de performance et en termes de complexité du logiciel privilégié) et sécurisée (car matériellement isolée en espace et en temps). Nous estimons donc que son utilisation dans les systèmes avioniques du futur est à considérer avec soin. Conclusion En conclusion, nous avons proposé dans ce chapitre différents moyens pour se protéger de tentatives de corruptions réalisées par une partition malveillante s’exécutant sur un calculateur avionique. Nous avons présenté des contre-mesures spécifiques pour les attaques expérimentées dans le chapitre 3. Nous avons ensuite proposé, pour certaines de ces attaques, des contre-mesures génériques applicables à différents types de systèmes embarqués. Nous avons également justifié l’intérêt de complémenter systématiquement ces contre-mesures par des techniques d’analyse statique de code et par des techniques d’analyse dynamique. Enfin, nous avons proposé une architecture sécurisée de péripérique partagé entre différentes partitions de criticités différentes. Cette architecture est basée sur les technologies matérielles de virtualisation Single Root-I/O. Nous avons présenté son utilisation dans un contexte avionique embarqué. L’ensemble de ces contre-mesures nous paraît être une bonne base pour améliorer la conception et le développement sécurisés de systèmes embarqués avioniques du futur. 106Conclusion générale La sécurité des systèmes informatiques est une préoccupation grandissante depuis déjà de nombreuses années. De nouveaux programmes malveillants sont sans cesse dé- couverts, ces programmes étant par ailleurs de plus en plus complexes et de plus en plus difficiles à éradiquer. En même temps, les systèmes informatiques sont de plus en plus connectés à de multiples réseaux, filaires ou non, qui constituent autant de “portes d’entrées” possibles pour les attaquants. Si la sécurité des systèmes informatiques “de bureau” fait l’objet de nombreux travaux depuis de nombreuses années, il n’en est pas de même pour les systèmes embarqués. Ces systèmes, embarqués dans tous nos appareils connectés à Internet à la maison par exemple, mais aussi embarqués dans les voitures, dans les avions, sont eux aussi et de plus en plus aujourd’hui, la cible potentielle d’attaques. Les travaux que nous avons menés dans le cadre de cette thèse visent à apporter une contribution à l’amélioration de la sécurité des systèmes embarqués, en particulier des systèmes avioniques. En effet, l’évolution récente de ces systèmes, notamment avec l’adoption par les avionieurs de l’architecture IMA Integrated Modular Avionics, vise à réduire les coûts de développement et de maintenance, mais elle accroît potentiellement la surface d’attaques possible. Les travaux présentés dans ce manuscrit ont donc eu pour but d’analyser et d’améliorer les mécanismes de sécurité existants sur des systèmes embarqués avioniques. Même si la sécurité de ces systèmes est déjà prise en compte par les avioneurs, les mécanismes de sécurité utilisés aujourd’hui sont davantage basés sur des méthodes d’analyse statique de code et sur l’utilisation de méthodes formelles pour la conception des applications avioniques. Ces méthodes sont évidemment essentielles et très pertinentes mais elles né- cessitent, selon nous, d’être complétées par des analyses de vulnérabilités, en particulier, visant les couches basses du logiciel. C’est dans cet objectif que se sont situés les travaux de cette thèse. Nous avons proposé dans le premier chapitre de ce manuscrit, après avoir justifié l’intérêt des nos travaux, une méthodologie pour mener à bien cette analyse de vulnérabilités. Elle a été réalisée en fonction d’une classification des attaques sur les systèmes embarqués, et c’est une première contribution de cette thèse. Cette classification, pré- sentée en détails dans le second chapitre, comprend deux catégories : les attaques ciblant les fonctionnalités de base et les attaques ciblant les mécanismes de tolérance aux fautes. Les attaques ciblant les fonctionnalités de base sont similaires aux attaques visant les systèmes informatiques grand public et concernent les attaques ciblant le processeur, la 107gestion de la mémoire, les communications, la gestion du temps, la gestion et l’ordonnancement des processus, les mécanismes cryptographiques et les fonctions ancillaires. Les attaques ciblant les mécanismes de tolérance aux fautes mettent l’accent sur des attaques qui visent à exploiter les mécanismes habituels de tolérance aux fautes présents dans la majorité des systèmes embarqués critiques et en particulier dans les systèmes avioniques. Ces attaques ciblent particulièrement les mécanismes que sont le traitement d’erreurs et le traitement de fautes. Dans le troisième chapitre, nous avons mené des expérimentations concernant un certain nombre des attaques identifiées dans la classification du second chapitre, sur un système embarqué expérimental développé par Airbus. Ce système nous a été fourni avec ses sources, ce qui nous a permis notamment de réaliser une analyse de code afin d’identifier d’eventuelles vulnérabilités. Nous avons considéré un système avionique composé de différentes partitions de criticités différentes et nous avons fait l’hypothèse qu’une partition non critique peut être malveillante et tenter de corrompre une partition critique s’exécutant sur le même calculateur (comme il est permis dans le contexte de l’architecture IMA). Ces attaques ont été réalisées sur une plateforme QorIQ P4080 de Freescale. Nous avons réalisé des attaques ciblant la gestion de la mémoire, la gestion du temps, les communications et les mécanismes de tolérance aux fautes. Ces attaques ont donné des résultats intéressants pour la plupart et ont permis de corriger certaines vulnérabilités présentes dans le système, ce qui a contribué à améliorer la sécurité du système. Ce cercle vertueux nous a paru fondamental car il a été réalisé durant la phase de développement. Il constitue pour nous la seconde contribution de cette thèse. Enfin, nous avons proposé, dans le quatrième chapitre de ce manuscrit, des contremesures spécifiques à nos attaques réalisées et des contre-mesures génériques adaptables à d’autres types de systèmes embarqués. Nous avons également donné des recommandations générales pour les développeurs d’applications embarquées et proposé une architecture sécurisée de périphérique partagé entre applications de différentes criticités. Bilan et perspectives Nous voudrions, avant d’aborder les perspectives, établir un petit retour d’expérience concernant les expérimentations et la collaboration avec Airbus dans le cadre de ces travaux. Nous avons eu la grande chance de disposer d’un exécutif temps-réel expérimental avec ses sources, développé par Airbus. Les échanges que nous avons effectués ont été très fructueux et ont permis d’introduire des modifications de cet exécutif pendant la phase de développement, en vue d’améliorer sa sécurité. De ce point de vue, nous estimons que cette étude a été particulièrement intéressante et fructueuse. En revanche, il nous a été assez difficile de nous procurer la plateforme d’expérimentation comprenant le P4080, les sondes JTAG et CodeWarrior, ce qui nous a un peu limité dans la quantité des expérimentations que nous avons pu réaliser ensuite. La découverte de vulnérabilités dans le noyau a été un exercice très intéressant, même si, le noyau étant particulièrement minimaliste et statique (Airbus le qualifie de “nano-noyau”), il était probable qu’il serait difficile de trouver des vulnérabilités très sérieuses. Il ne contient en effet que les fonctions 108vitales, pour ordonnancer les partitions et gérer les interruptions, et toute sa configuration est statique. La surface d’attaque était donc très limitée depuis une partition utilisateur. Cependant, il a été intéressant de comprendre comment le noyau temps-réel et les partitions ont été développés ainsi que le fonctionnement du P4080 de Freescale et ses nombreuses caractéristiques. Nous avons pu réaliser quelques expérimentations avec succès sur les communications, la gestion du temps et les mécanismes de tolérance aux fautes, et nous avons pu éliminer ces vulnérabilités avec la collaboration d’Airbus, ce qui était un des objectifs de cette thèse. L’important est que ces expérimentations et cette plateforme nous ont permis de valider, dans un contexte spécifique, notre méthodologie de recherche de vulnérabilités. En ce qui concerne les perspectives à ces travaux, on peut envisager des perspectives de deux ordres. Les premières perspectives, à court terme et sur un plan technique, concernent les expérimentations que nous avons menées. En effet, faute de temps et faute de matériel adéquat, nous n’avons pu toutes les réaliser. A titre d’exemple, d’autres attaques ciblant la gestion de la mémoire pourraient être mises en œuvre, notamment visant les caches du processeur. Ces attaques, que nous n’avons pu mener par faute de temps nous semblent particulièrement pertinentes dans un contexte avionique. D’autres attaques peuvent être envisagées si l’on dispose du matériel adéquat pour réellement mettre à l’épreuve certains mécanismes de tolérance aux fautes, en particulier basés sur la redondance. Nous ne disposions pas, pour cette étude, de multiples exemplaires du même calculateur et nous n’avions donc pas la possibilité de mettre en œuvre certaines techniques de tolérance aux fautes basées sur la redondance. A plus long terme et sur un plan méthodologique, nous pouvons envisager des perspectives concernant la méthodologie d’analyse de vulnérabilités pour des systèmes embarqués avioniques que nous avons présenté dans le chapitre 1.6. Il serait intéressant d’étudier l’adéquation de cette méthodologie à d’autres domaines d’applications. Le domaine automobile par exemple en est un bon exemple car de nombreux systèmes embarqués sont présents dans les voitures d’aujourd’hui. De même que pour les avions, la connectivité des véhicules automobiles devient de plus en plus étendue (connectivité Wifi, BlueTooth, GSM, etc.) et toutes ces sources de connectivité sont autant de sources d’attaques possibles. L’adoption de COTS dans ces véhicules peut également introduire les mêmes types de risques que leur adoption dans les systèmes avioniques. Il est donc pertinent de vouloir améliorer les mécanismes de sécurité existants sur les automobiles. Il est probable que la classification que nous avons proposée doive être adaptée aux mé- canismes de tolérance aux fautes des véhicules, qui sont différentes des mécanismes des systèmes avioniques. On peut bien sûr envisager ce même genre d’études sur d’autres systèmes embarqués très différentes, comme les systèmes embarqués qui envahissent notre quotidien professionnel et personnel aujourd’hui, car il est probable que beaucoup de ces équipements n’ont pas été développé avec un réel souci de sécurité. Enfin, une des perspectives de cette thèse concerne les contre-mesures. En particulier, nous avons proposé une première réflexion concernant une architecture sécurisée de périphérique partagé entre différentes partitions. Cette architecture, utilisant des mé- canismes matériels incontournables, est selon nous, une contribution intéressante à la 109conception d’architectures sécurisées de systèmes avioniques critiques. Cette réflexion demande à être poursuivie, en ayant toujours le souci d’envisager des mécanismes de sécurité à la fois logiciels et matériels pour pouvoir concevoir des mécanismes de défense efficaces contre des attaques visant les couches les plus basses du logiciel. 110Bibliographie [01N13] 01Net. Une attaque informatique bloque l’Internet chinois pendant des heures. http://www.01net.com/editorial/601826/ une-attaque-informatique-bloque-linternet-chinois-pendant-des-heures/, août 2013. [A+06] J. Akoka et al. Encyclopédie de l’informatique et des systèmes d’information. Vuibert, décembre 2006. [Aci06] Kaya Koç C. Aciiçmez, O. Trace-Driven Cache Attack on AES. In ICICS’06 Proceedings of the 8th international conference on Information and Communications Security, pages 112–121, 2006. [Aci07a] O. Aciiçmez. Yet Another MicroArchitectural Attack : Exploiting I-Cache. In Workshop on Computer Security Architecture (CSAW’07), pages 11–18, New-York City (NY, USA), 2007. ACM. [Aci07b] Schindler W. Kaya Koç C. Aciiçmez, O. Cache Based Remote Timing Attack on the AES. In CT-RSA 2007, The Cryptographers’ Track at the RSA Conference 2007, pages 271–286. Springer-Verlag, 2007. [Aed12] J. Aedla. Linux Kernel CVE-2012-0056 Local Privilege Escalation Vulnerability. Technical report, Janvier 2012. [ALRL04] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. Transactions On Dependable and Secure Computing, 1 :11–33, janvier/mars 2004. [ari05] ARINC 811 : Commercial Aircraft Information Security Concepts of Operation and Process Framework. Technical report, ARINC Corp., décembre 2005. [ARI08] ARINC 653 : Avionics Application Software Standard Interface Part 2 Extended Services. Technical report, ARINC Corp., décembre 2008. [ari09] ARINC 664 : Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network. Technical report, ARINC Corp., septembre 2009. [arp10] ARP 4754A : Guidelines For Development Of Civil Aircraft and Systems. Technical report, SAE International, décembre 2010. [Art14] C. Arthur. Apple’s SSL iPhone vulnerability : how did it happen, and what next ? Technical report, Février 2014. 111[ASK07] O. Aciiçmez, J.-P. Seifert, and C. K. Koç. Predicting Secret Keys via Branch Prediction. In The 7th Cryptographers’ Track at the RSA Conference on Topics in Cryptlogy (CT-RSA’07), pages 225–242, San Francisco (CA, USA), 2007. Springer-Verlag. [Avi85] A. Avizienis. The N-Version Approach to Fault-Tolerant Software. Transactions On Software Engineering, 11 :1491–1501, décembre 1985. [B+02] P. Baudin et al. Caveat : a tool for software validation. In Dependable Systems and Networks (DSN), page 537, Juin 2002. [B+12a] P. Bieber et al. Security and Safety Assurance for Aerospace Embedded Systems. 2012. [B+12b] J.-P. Blanquart et al. Similarities and Dissimilarities between Safety Levels and Security Levels. 2012. [Ber05] D. J. Bernstein. Cache-timing attacks on AES. Technical report, 2005. [Boi06] A. Boileau. Hit by a Bus : Physical Access Attacks with FireWire. In RUXCON, Melbourne (Australia), septembre 2006. [Bon06] Mironov I. Bonneau, J. Cache-Collision Timing Attacks Against AES. In Cryptographic Hardware and Embedded Systems (CHES), pages 201–215, 2006. [Bro13] M. Brodbeck. Potential EMI from Portable Electronic Devices (PED) on aircraft. http://www.serec.ethz.ch/EVENTS%20WEF%202011/ AVIATION+SPACE_28JUN13/8_PED%20EMC%20in%20Aviation_V3_ BRODBECK.pdf, juin 2013. [C+07] P. Cousot et al. Varieties of Static Analyzers : A Comparison with ASTREE. In First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE’07), pages 3–20, Shangai, juin 2007. [Can12] Radio Canada. Fermeture de Megaupload : Anonymous riposte par une série d’attaques. http://www.radio-canada.ca/nouvelles/International/ 2012/01/19/013-anonymous-attaque-sites-megaupload.shtml, janvier 2012. [CC77] P. Cousot and R. Cousot. Abstract Interpretation : A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints. In 4th ACM Symposium Principles Of Programming Languages (POPL’77), pages 238–252, Los Angeles (California, Etats-Unis), 1977. [CC13] X. Chen and D. Caselden. MS Windows Local Privilege Escalation Zero-Day in The Wild. Technical report, Novembre 2013. [CE09] B. Chelf and C. Ebert. Ensuring the Integrity of Embedded Software with Static Code Analysis. volume 26, pages 96–99, mai/juin 2009. [Cou13] J. Couzins. Attacking the Hypervisor. Technical report, Novembre 2013. [DADN12] A. Dessiatnikoff, É. Alata, Y. Deswarte, and V. Nicomette. Potential Attacks on Onboard Aerospace Systems. In IEEE Security and Privacy vol. 10 N. 4, Juillet/Août 2012. 112[DADN13] A. Dessiatnikoff, É. Alata, Y. Deswarte, and V. Nicomette. Low-level Attacks on Avionics Embedded Systems. In The 32nd International Conference on Computer Safety, Reliability and Security (SAFECOMP), Toulouse, France, 24-27 septembre 2013. [DDAN13] A. Dessiatnikoff, Y. Deswarte, É. Alata, and V. Nicomette. Securing Integrated Modular Avionics Computers. In The 32nd Digital Avionics Systems Conference (DASC), Syracuse (NY, USA), 5-10 octobre 2013. [DKCG99] Y. Deswarte, M. Kaâniche, P. Corneillie, and J. Goodson. SQUALE Dependability Assessment Criteria. pages 27–38. Springer, 1999. [DLM09] L. Duflot, O. Levillain, and B. Morin. Getting into the SMRAM : SMM Reloaded. In CanSecWest 2009, Vancouver (BC, Canada), 2009. [DO11] J. D. O’Grady, ZDNet. FAA approves iPads in the cockpit ; American Airlines to start Friday. http://www.zdnet.com/blog/apple/ faa-approves-ipads-in-the-cockpit-american-airlines-to-start-friday/ 11865, décembre 2011. [do310] DO-326 Airworthiness Security Process Specification. Technical report, RTCA Inc., décembre 2010. [Dor04] M. Dornseif. 0wned by an iPod - hacking by Firewire. In PacSec/core04, Tokyo (Japan), novembre 2004. [Duf07] L. Duflot. Contribution à la sécurité des systèmes d’exploitation et des microprocesseurs. , Thèse de doctorat de l’université de Paris XI, octobre 2007. [ESZ08] S. Embleton, S. Sparks, and C. Zhou. SMM Rootkits : A New Breed of OS Independant Malware. In 4th International Conference on Security and Privacy in Communication Networks (SecureComm’08). ACM, 2008. [Fre11] Freescale. P4080 QorIQ Integrated Multicore Communication Processor Family Reference Manual. Technical report, avril 2011. [Gen13] S. Genevès. Améliorations de performances des systèmes multi-coeur : environnement d’exécution événementiel efficace et étude comparative de modèles de programmation. , Thèse de doctorat de l’université de Grenoble, avril 2013. [GST13] D. Genkin, A. Shamir, and E. Tromer. RSA Key Extraction via LowBandwidth Acoustic Cryptanalysis. Technical report, décembre 2013. [HS09] N. Henninger and H. Shacham. Reconstructing RSA Private Keys from Random Key Bits. In 29th Annual International Cryptology Conference (Crypto 2009, volume 5677, pages 1–17, Santa Barbara (CA, USA), 2009. Springer-Verlag. [IW08] V. Igure and R. Williams. Taxonomies of Attacks and vulnerabilities in Computer Systems. volume 10, pages 6–19, 1st quarter 2008. 113[JH08] E. Jaeger and T. Hardin. A few remarks about formal development of secure systems. In : HASE, IEEE Computer Society, pages 165–174, 2008. [KJJ99] P. Kocher, J. Jaffe, and B. Jun. Differential Power Analysis. volume 1666, pages 388–397. Springer, 1999. [Koc96] P. Kocher. Timing Attacks on Implementations of Diffe-Hellman, RSA, DSS,and Other Systems. Technical report, 1996. [KW07] R. Kaiser and S. Wagner. The PikeOS Concept - History and Design. , 2007. [L+96] J.-C. Laprie et al. Guide de la sûreté de fonctionnement, 2ème édition. Cépaduès-éditions, 1996. [LA95] S. Liu and R. Adams. Limitations of Formal Methods and An Approach to Improvement. In Software Engineering Conference, pages 498–507, Brisbane, Qld., Australie, décembre 1995. [Laa09] Y. Laarouchi. Sécurités (immunité et innocuité) des architectures ouvertes à niveaux de criticité multiples : application en avionique. , Thèse de doctorat de l’université de Toulouse, novembre 2009. [Lab12] Kaspersky Lab. Pourquoi la complexité est le pire ennemi de la sécurité informatique. Technical report, Kaspersky, 2012. [LABK90] J.-C. Laprie, J. Arlat, C. Béounes, and K. Kanoun. Definition and Analysis of Hardware-and-Software Fault-Tolerant Architectures. IEEE Computer, 23 :39–51, juillet 1990. [LAEJ11] M. Lee, M. Ahn, and K. Eun Jung. Fast Secure Communications in Shared Memory Multiprocessor Systems. volume 22, pages 1714–1721, juillet 2011. [LD11] Nicomette V. Lacombe, E. and Y. Deswarte. Enforcing kernel constraints by hardware-assisted virtualization. volume 7, pages 1–21, Février 2011. [lem13] AFP. Il sera bientôt possible de laisser son téléphone allumé dans l’avion. http://www.lemonde.fr/technologies/article/2013/12/09/ il-sera-bientot-possible-de-laisser-son-telephone-allume-dans-l-avion_ 3527966_651865.html, décembre 2013. [LSLND10] F. Lone-Sang, E. Lacombe, V. Nicomette, and Y. Deswarte. Exploiting an I/OMMU Vulnerability. In 5th International Conference on Malicious and Unwanted Software (MalWare 2010), pages 9–16, Nancy (France), 2010. [M+10] J. McCune et al. TrustVisor : Efficient TCB Reduction and Attestation. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, pages 143–158, Washington, DC, USA, 2010. IEEE Computer Society. [May05] D. Maynor. 0wn3d by everything else - USB/PCMCIA Issues. In CanSecWest/core05, Vancouver (Canada), mai 2005. [MIM+13] D. Münch, O. Isfort, K. Muller, M. Paulitsch, and A. Herkersdorf. HardwareBased I/O Virtualization for Mixed Criticality Real-Time Systems Using PCIe SR-IOV. pages 706–713, Sydney (NSW), décembre 2013. 114[Mor91] M. J. Morgan. Integrated Modular Avionics for next generation commercial airplanes. volume 1, pages 43–49, mai 1991. [Mun11] C. Munoz. Computer Virus Infects Predator Ground Stations. http://breakingdefense.com/2011/10/ computer-virus-infects-predator-ground-stations/, octobre 2011. [NEV01] http://ec.europa.eu/research/growth/aeronautics-days/pdf/ posters/nevada.pdf, 2001. [OST06] D. A. Osvik, A. Shamir, and E. Tromer. Cache Attacks and Countermeasures : the Case of AES. In The 6th Cryptographers’ Track at the RSA Conference on Topics in Cryptlogy (CT-RSA’06), pages 1–20, San Jose (CA, USA), 2006. Springer-Verlag. [OWA13] OWASP. OWASP WebScarab Project. https://www.owasp.org/index. php/Category:OWASP_WebScarab_Project, 2013. [PAM01] http://www.airbus.com/innovation/eco-efficiency/ aircraft-end-of-life/pamela/, 2001. [Per05] C. Percival. Cache missing for fun and profit. In Proc. of BSDCan 2005, 2005. [pip09] PIPAME, La chaîne de valeur dans l’industrie aéronautique. Technical report, septembre 2009. [PM88] S. K. Park and K. W. Miller. Random number generators : good ones are hard to find. volume 31, pages 1192–1201. ACM, octobre 1988. [Pua11] I. Puaut. Worst-Case Execution Time (WCET) estimation : from monocore to multi-core architectures. http://www.ensta-paristech. fr/~chapoutot/seminaire/supports/isabelle_puaut_110517.pdf, mai 2011. [Ran75] B. Randell. System structure for software fault tolerance. IEEE Transactions on Software Engineering, SE-1 :220–232, juin 1975. [Rus99] J. Rushby. Partitioning in Avionics Architectures : Requirements, Mechanisms, and Assurance. , 1999. [RW09] J. Rutkowska and R. Wojtczuk. Attacking SMM Memory via IntelR CPU Cache Poisoning. Technical report, mars 2009. [S+09a] T. Shinagawa et al. BitVisor : A Thin Hypervisor for Enforcing I/O Device Security. In Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE 2009), pages 121–130. ACM, 2009. [S+09b] J. Souyris et al. Formal Verification of Avionics Software Products. In A. Cavalcanti and D. Dams (Eds), editors, FM ’09 Proceedings of the 2nd World Congress on Formal Methods, pages 532–546, Eindhoven, Pays-Bas, novembre 2009. Springer-Verlag Berlin Heidelberg. 115[Sai05] A. Saidane. Conception et réalisation d’une architecture tolérant les intrusions pour les serveurs Internet. , Thèse de doctorat de l’université de Toulouse, janvier 2005. [SCA11] http://www.scarlettproject.eu/partnership/default.asp, 2011. [Ska13] P. Skaves. Information for Cyber Security Issues Related to Aircraft Systems rev-A. In 32nd Digital Avionics Systems Conference, octobre 2013. [SPHP02] B. Schätz, A. Pretschner, F. Huber, and J. Philipps. Model-Based Development of Embedded Systems. In In Advances in Object-Oriented Information Systems, Lecture, pages 298–312. Springer-Verlag, 2002. [SPL95] O. Sibert, P. A. Porras, and R. Lindell. The Intel 80x86 processor architecture : pitfalls for secure systems. In IEEE Symposium on Security and Privacy, pages 211–222, Oakland (CA, USA), 1995. [sri] SR-IOV Architecture. http://msdn.microsoft.com/en-us/library/ windows/hardware/hh440238%28v=vs.85%29.aspx. [Tes13] H. Teso. Aircraft Hacking : Practical Aero Series. In Hack In The Box, avril 2013. [usc12] Government Accountability Office. Cybersecurity : Threats Impacting the Nation. http://www.gao.gov/assets/600/590367.pdf, avril 2012. [VIC01] http://www1.fsr.tu-darmstadt.de/research/projects/en_victoria. html, 2001. [vir14] Multiples vulnérabilités dans Oracle VirtualBox et Apache Tomcat. Technical report, Février 2014. [vmw14] Multiples vulnérabilités dans les produits VMware. Technical report, janvier 2014. [WFLH04] X. Wang, D. Feng, X. Lai, and Yu H. Collisions for hash functions MD4, MD5, HAVAL-128 and RIPEMD. 2004. [xen14] Multiples vulnérabilités dans Xen. Technical report, Février 2014. [You] Y. Younan. 25 years of Vulnerabilities : 1988-2012. Technical report. [ZBR07] K. Zhou, B. Breinhauer, and T. Rausch. Violations of Real Time Communication Constraints caused by Memory Transfers exceeding CPU Cache Limits in RTAI and Rtnet. In 5th International Conference on Industrial Informatics, volume 1, pages 267–272, Vienne (Autriche), juin 2007. IEEE. [ZY09] W. Zhang and J. Yan. Accurately Estimating Worst-Case Execution Time for Multi-Core Processors with Shared Direct-Mapped Instruction Caches. In 15th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, pages 455–463, Beijing, Chine, août 2009. 116Résumé L’évolution actuelle des systèmes embarqués à bord des systèmes complexes (avions, satellites, navires, automobiles, etc.) les rend de plus en plus vulnérables à des attaques, en raison de : (1) la complexité croissante des applications; (2) l’ouverture des systèmes vers des réseaux et systèmes qui ne sont pas totalement contrôlés ; (3) l’utilisation de composants sur étagère qui ne sont pas développés selon les méthodes exigées pour les systèmes embarqués critiques ; (4) le partage de ressources informatiques entre applications, qui va de pair avec l’accroissement de puissance des processeurs. Pour faire face aux risques de malveillances ciblant les systèmes embarqués, il est nécessaire d’appliquer ou d’adapter les méthodes et techniques de sécurité qui ont fait leurs preuves dans d’autres contextes : Méthodes formelles de spécification, développement et vérification ; Mécanismes et outils de sécurité (pare-feux, VPNs, etc.) ; Analyse de vulnérabilités et contre-mesures. C’est sur ce dernier point que portent nos travaux de thèse. En effet, cet aspect de la sécurité a peu fait l’objet de recherche, contrairement aux méthodes formelles. Cependant, il n’existe pas actuellement de modèle formel capable de couvrir à la fois des niveaux d’abstraction suffisamment élevés pour permettre d’exprimer les propriétés de sécurité désirées, et les détails d’implémentation où se situent la plupart des vulnérabilités susceptibles d’être exploitées par des attaquants : fonctions des noyaux d’OS dédiées à la protection des espaces d’adressage, à la gestion des interruptions et au changement de contextes, etc. ; implémentation matérielle des mécanismes de protection et d’autres fonctions ancillaires. C’est sur ces vulnérabilités de bas niveau que se focalise notre étude. Nos contributions sont résumées par la suite. Nous avons proposé une classification des attaques possibles sur un système temps-réel. En nous basant sur cette classification, nous avons effectué une analyse de vulnérabilité sur un système réaliste : une plateforme avionique expérimentale fournie par Airbus. Il s’agit d’un noyau temps-réel critique ordonnancé avec plusieurs autres applications, le tout exécuté sur une plateforme Freescale QorIQ P4080. C’est à travers une application dite « malveillante », présente parmi l’ensemble des applications, que nous essayons de modifier le comportement des autres applications ou du système global pour détecter des vulnérabilités. Cette méthode d’analyse de vulnérabilités a permis de détecter plusieurs problèmes concernant les accès mémoire, la communication entre applications, la gestion du temps et la gestion des erreurs qui pouvaient conduire à la défaillance du système global. Enfin, nous avons proposé des contre-mesures spécifiques à certaines attaques et des contre-mesures génériques pour le noyau temps-réel qui permet d’empêcher une application d’obtenir des accès privilégiés ou encore de perturber le comportement du système. Mots-clés: systèmes embarqués, sécurité informatique, contre-mesure, système avionique, analyse de vulnérabilité. 117Abstract Security is becoming a major concern for embedded computing systems in various critical industrial sectors (aerospace, satellites, automotive, etc.). Indeed, recent trends in the development and operation of such systems, have made them more and more vulnerable to potential attacks, for the following reasons : 1) increasing complexity of the applications ; 2) openness to applications and networks that are note completely under control ; 3) Use Commercial-Off-The-Shelf (COTS) hardware and software components ; 4) Resource sharing among different applications, driven by the increase of processors capabilities. To improve the security of such systems, it is necessary to apply or adapt methods and techniques that have proven their efficiency in other contexts : Formal methods for specification, development and verification ; Security mechanisms and tools (firewalls, VPNs, etc.) ; Vulnerability assessment and countermeasure provision. The research carried out in this thesis adresses the latter technique. This aspect of security analysis cannot be easily covered by current formal methods, since no existing model is able to cover both high-level abstractions, where security properties can be defined, and low-level implementation details, where most vulnerabilities that could be exploited by attackers lie : OS kernel implementation of address space protection, interrupt management, context switching, etc. ; hardware implementation of protection mechanisms and other ancillary functions. Very few research projects are addressing this aspect of security, which is the main objective of this thesis. In particular, our research focuses on low-level vulnerabilities, but contrarily with common practice, we aim to discover and analyze them during the development process. Our contributions are summarized as follows. We elaborated a classification of lowlevel vulnerabilities for different implementations of real-time embedded systems. Based on this classification, we carried out a vulnerability analysis study on a realistic system : An experimental avionic platform provided by Airbus. It consists of a critical real-time kernel scheduling the execution of different applications on a freescale QorIQ P4080 platform. The identification and analysis of vulnerabilities is carried out based on a “malicious” application hosted on the platform that attempts to corrupt the behavior of the other applications or the global system considering different types of low level attacks. Such experiments allowed us to identify some problems related to the management of memory accesses, the communication between applications, time management and error handling that could lead to the global system failure.We have also proposed generic counter measures to protect the real-time kernel against specific attacks, and to prevent a given application from escalating its privileges or trying to compromise the system behavior. Keywords: embedded systems, computer security, countermeasure, avionic system, vulnerability assessment. 118 Localisation d’une flotte de v´ehicules communicants par approche de type SLAM visuel d´ecentralis´e Guillaume Bresson To cite this version: Guillaume Bresson. Localisation d’une flotte de v´ehicules communicants par approche de type SLAM visuel d´ecentralis´e. Automatic. Universit´e Blaise Pascal - Clermont-Ferrand II, 2014. French. . HAL Id: tel-00973894 https://tel.archives-ouvertes.fr/tel-00973894v2 Submitted on 7 Jul 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.N d’ordre : D.U 2439 EDSPIC : 645 Université Blaise Pascal - Clermont II École doctorale des Sciences Pour l’Ingénieur THÈSE en vue de l’obtention du grade de Docteur d’Université Spécialité : Vision pour la Robotique Présentée et soutenue par Guillaume Bresson Localisation d’une flotte de véhicules communicants par approche de type SLAM visuel décentralisé Thèse dirigée par Roland Chapuis préparée à l’Institut Pascal soutenue le 21 février 2014 Jury : Président : François Charpillet - Directeur de recherche INRIA Rapporteurs : Fawzi Nashashibi - Directeur de recherche INRIA Juan D. Tardós - Professeur Université de Saragosse Directeur : Roland Chapuis - Professeur Université B. Pascal Examinateurs : Javier Ibañez-Guzmán - Ingénieur de recherche Renault Romuald Aufrère - Maître de conférences Université B. PascalAbstract The localization of a vehicle with the use of SLAM techniques (Simultaneous Localization And Mapping) has been extensively studied during the last 20 years. However, only a few approaches have tried to extend these algorithms to a fleet of vehicles despite the many potential applications. It is the objective of this thesis. First of all, a monocular SLAM for a single vehicle has been developed. This one proposes to pair an Extended Kalman Filter with a Cartesian representation for landmarks so as to produce accurate low density maps. Indeed, the extension of SLAM to several vehicles requires permanent communications inside the fleet. With only a few landmarks mapped, our approach scales nicely with the number of vehicles. Cheap sensors have been favored (a single camera and an odometer) in order to spread more easily the use of multi-vehicle applications. Correctives have been proposed in order to avoid the divergence problems induced by such a scheme. The experiments showed that our SLAM is able to furnish good localization results while being light and fast. The drift affecting every SLAM algorithm has also been studied. Its integration inside the SLAM process, thanks to a dedicated architecture and a dynamic model, allows to ensure consistency even without an estimation of it. Loop closures or the integration of geo-referenced information becomes straightforward. They naturally correct all the past positions while still maintaining consistency. In a multi-vehicle scenario, it is a key aspect as each vehicle drifts differently from one another. It is consequently important to take it into account. Our SLAM algorithm has then been extended to several vehicles. A generic structure has been used so as to allow any SLAM algorithm to replace our monocular SLAM. The multi-vehicle architecture avoids data incest (double-counting information) and handles network failures, be they communication breakdowns or latencies when receiving data. The static part of the drift model allows to take into account the fact that the initial positions of the different vehicles composing the fleet might be unknown. Consistency is thus permanently preserved. Our approach has been successfully tested using simulations and real experiments with various settings (row or column convoy with 2 or 3 vehicles) in a fully decentralized way. Keywords : SLAM, decentralized, monocular, drift, EKF, multi-vehicle, localization, linearization, divergence.Résumé La localisation d’un véhicule via les techniques de SLAM (Simultaneous Localization And Mapping pour cartographie et localisation simultanées) a connu un essor important durant les 20 dernières années. Pourtant, peu d’approches ont tenté d’étendre ces algorithmes à une flotte de véhicules malgré les nombreuses applications potentielles. C’est ici l’objectif de cette thèse. Pour ce faire, une approche de SLAM monoculaire pour un seul véhicule a d’abord été développée. Celle-ci propose de coupler un filtre de Kalman étendu avec une représentation cartésienne des amers afin de produire des cartes de faible densité mais de qualité. En effet, l’extension à plusieurs véhicules nécessite des échanges permanents par l’intermédiaire de communications sans fil. Avec peu d’amers dans les cartes, notre approche s’accommode bien du nombre de véhicules de la flotte. Des capteurs peu onéreux ont aussi été privilégiés (une unique caméra et un odomètre) afin de réduire le coût d’une extension multivéhicule. Des correctifs ont été proposés afin d’éviter les problèmes de divergence induits par les choix précédents. Des expérimentations ont montré que la solution de SLAM produite était légère et rapide tout en fournissant une localisation de qualité. La dérive, inhérente à tout algorithme de SLAM, a également fait l’objet d’une analyse. Celle-ci a été intégrée au SLAM par l’intermédiaire d’une architecture dé- diée et d’un modèle dynamique. Le but est de pouvoir rendre consistante la localisation fournie par le SLAM, même en l’absence d’estimation de la dérive. Cela permet d’effectuer des fermetures de boucle ou encore d’intégrer des informations géo-référencées de manière naturelle tout en conservant l’intégrité de la solution. En multivéhicule, cet aspect est un point clef puisque chaque véhicule dérive différemment des autres. Il est donc important de le prendre en compte. Enfin, le SLAM a été étendu à plusieurs véhicules. Une structure générique a été prévue afin que notre approche monoculaire puisse être remplacée par n’importe quel algorithme de SLAM. Notre architecture décentralisée évite la consanguinité des données (le fait de compter deux fois une même information) et gère les défaillances réseau, que cela soit des ruptures de communication ou encore des latences dans la réception des données. La partie statique du modèle de dérive permet également de prendre en compte le fait que les positions initiales des véhicules d’une flotte puissent être inconnues. L’intégrité est ainsi maintenue en permanence. Enfin, notre approche étant entièrement décentralisée, elle a pu être testée et validée en simulation et avec des expérimentations réelles dans diverses configurations (convoi en colonne ou en ligne, avec 2 ou 3 véhicules). Mots clefs : SLAM, décentralisé, monoculaire, dérive, EKF, multivéhicule, localisation, linéarisation, divergence.Remerciements Avant de rentrer dans des considérations techniques, je souhaite remercier toutes les personnes qui m’ont accompagné durant ces 3 années de thèse. Tout d’abord, je remercie mes encadrants, Romulus Rémus Rémoulade Aufrère et Roland Chapuis, pour leurs conseils avisés et leur bonne humeur (presque) permanente. J’en pro- fite également pour remercier tous les gens de l’Institut Pascal ayant permis mon intégration dans leurs locaux. Je fais de même pour le personnel du département informatique de l’IUT de Clermont-Ferrand. Je tiens à remercier plus particulièrement Guénal, Sylvie et François pour m’avoir amené à cette thèse ainsi qu’à l’enseignement dans leurs locaux. Je félicite mes collègues de bureau, passés et présents, pour avoir contribué au succès de cette thèse. Un remerciement spécial va au Dr Thomas Féraud avec qui j’ai travaillé en (très) étroite collaboration durant presque 3 ans. Je remercie également Florent et Pierre pour le support technique du simulateur et les passages réguliers dans le bureau. D’un point de vue plus personnel, je fais des bisous à mes potos du midi qui m’ont permis de relâcher la pression. Je cite, par ordre de préférence (ça va faire des jaloux) : Clément, Nicolas, Nathalie, Pierre, Romain, Thomas (mais je l’avais déjà cité avant donc ça compte pas) et tous les autres. En vrac, j’en profite pour citer tous les gens qui m’ont aidé, directement ou indirectement, à mener à bien cette thèse : Damien, Clément, Maxime, Paul, Christophe, Thierry, Vanessa, Corinne, Françoise, Guddy, Nicolas, Beberth, Fanny, Fanny, Marine, Pierre, Antoine, Romain, François, Christine, Florian, Jean-Baptiste, Sébastien et tous les autres que j’oublie certainement. Évidemment, je termine par remercier ma famille pour l’accompagnement et le soutien psychologique. Merci à mes parents, beaux-parents, frères, belles-soeurs, beau-frère et tous les autres. Sur ces 3 années la personne la plus importante est sans l’ombre d’un doute Audrey à qui je dois d’en être arrivé là aujourd’hui. C’est grâce à son soutien et à ses encouragements que vous avez la chance ( !) de lire ce bel ouvrage, alors merci à elle ! Puisqu’il me reste un petit peu de place, je me remercie d’être aller au bout de la thèse aussi, parce que dans le fond il n’y a pas de raisons de ne pas le faire. Je remercie également les arbres de me fournir les jolies feuilles utilisées pour ce mémoire. J’aimerais terminer par une citation de Winston Churchill qui prend tout son sens dans le cadre d’une thèse : « Réussir, c’est aller d’échec en échec sans perdre l’enthousiasme. »Table des matières 1 Introduction et contexte 1 1.1 Robotique et mobilité .......................... 2 1.2 Perception pour la robotique mobile .................. 5 1.2.1 Place de la perception ...................... 5 1.2.2 Système de localisation ..................... 6 1.2.3 Extension au multivéhicule ................... 7 1.3 Organisation du mémoire ........................ 8 2 Localisation d’un véhicule 11 2.1 Analyse des capteurs pour la localisation . . . . . . . . . . . . . . . . 13 2.1.1 Capteurs proprioceptifs . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Capteurs extéroceptifs . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3 Bilan des capteurs . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Méthodes de localisation pour le SLAM . . . . . . . . . . . . . . . . 20 2.2.1 Minimisation globale par ajustement de faisceaux . . . . . . . 21 2.2.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.3 Bilan des méthodes de localisation . . . . . . . . . . . . . . . 30 2.3 SLAM pour l’EKF dans un contexte de robotique mobile . . . . . . . 31 2.3.1 Prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mise à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.3 Spécificité de la vision . . . . . . . . . . . . . . . . . . . . . . 40 3 Gestion de la non linéarité dans le SLAM monoculaire 43 3.1 Erreurs de linéarisation . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.1 Constatation du problème . . . . . . . . . . . . . . . . . . . . 44 3.1.2 Étude de la littérature . . . . . . . . . . . . . . . . . . . . . . 52 3.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.1 Suivi des amers . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.2 Mise à jour via le filtre de Kalman . . . . . . . . . . . . . . . 65 3.3 Expérimentations réelles et simulées . . . . . . . . . . . . . . . . . . 70 3.3.1 Trajectoires à faible cadence caméra . . . . . . . . . . . . . . 70 3.3.2 Utilisation d’une carte préalablement construite . . . . . . . . 75 3.3.3 Comparaison avec une approche existante . . . . . . . . . . . 78 3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4 Dérive naturelle du SLAM et inconsistance 85 4.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.1.1 Constatation et origine . . . . . . . . . . . . . . . . . . . . . . 86 4.1.2 Solutions pour éviter l’inconsistance . . . . . . . . . . . . . . 88 4.2 Intégration de la dérive dans le SLAM . . . . . . . . . . . . . . . . . 90viii Table des matières 4.2.1 Modèle de dérive . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.2 Architecture dédiée . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.3 Intégration de la dérive . . . . . . . . . . . . . . . . . . . . . 111 4.3 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.1 Fermeture de boucle . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.2 Intégration d’amers géo-référencés . . . . . . . . . . . . . . . 118 4.4 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5 Extension du SLAM à une flotte de véhicules 125 5.1 État de l’art du SLAM multivéhicule . . . . . . . . . . . . . . . . . . 127 5.1.1 Centralisé ou décentralisé . . . . . . . . . . . . . . . . . . . . 127 5.1.2 Consanguinité des données . . . . . . . . . . . . . . . . . . . 129 5.1.3 Problèmes de communication . . . . . . . . . . . . . . . . . . 133 5.1.4 Association de données . . . . . . . . . . . . . . . . . . . . . . 134 5.2 Conception d’un algorithme de SLAM décentralisé . . . . . . . . . . 136 5.2.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . 137 5.2.2 Positions initiales inconnues . . . . . . . . . . . . . . . . . . . 143 5.2.3 Résultats préliminaires . . . . . . . . . . . . . . . . . . . . . . 145 5.3 Association de données pour le multivéhicule . . . . . . . . . . . . . 150 5.3.1 Choix de la méthode . . . . . . . . . . . . . . . . . . . . . . . 150 5.3.2 Premiers résultats . . . . . . . . . . . . . . . . . . . . . . . . 153 6 Expérimentations et résultats pour le multivéhicule 157 6.1 Résultats avec simulateur . . . . . . . . . . . . . . . . . . . . . . . . 158 6.1.1 Convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.1.2 Changement de l’ordre du convoi . . . . . . . . . . . . . . . . 165 6.2 Résultats avec données réelles . . . . . . . . . . . . . . . . . . . . . . 173 6.2.1 Convoi colonne à deux véhicules . . . . . . . . . . . . . . . . 173 6.2.2 Convoi ligne à deux véhicules . . . . . . . . . . . . . . . . . . 176 6.2.3 Convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . 182 6.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7 Conclusion et perpespectives 193 7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Bibliographie 201Table des figures 1.1 Évolution des robots industriels en plus de 40 ans . .......... 2 1.2 Robotique domestique et médicale ................... 3 1.3 Des exemples de robots mobiles . . . .................. 4 1.4 Des robots terrestres avec des systèmes de mobilité différents .... 5 1.5 Schéma général d’un système robotique ................ 6 1.6 Coopération dans le cadre d’un système multivéhicule ........ 8 2.1 Fonctionnement d’un GPS RTK avec la correction par la station . . 15 2.2 Problèmes affectant les GPS . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Schématisation des effets de la distorsion . . . . . . . . . . . . . . . . 17 2.4 Schéma de fonctionnement simplifié d’un télémètre laser . . . . . . . 18 2.5 Laser 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6 Résultats de l’ajustement de faisceaux de [Royer et al. 2005] (approximativement 15 cm d’erreur) . . . . . . . . . . . . . . . . . . . . 22 2.7 Résultats de l’EKF de [Féraud 2011] (moins de 8 cm d’erreur) . . . . 27 2.8 Présentation d’un SLAM dans le contexte de l’EKF . . . . . . . . . . 32 2.9 Représentation des repères monde et véhicule et passage de l’un à l’autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.10 Gestion des deux états en fonction des données fournies par les capteurs 36 2.11 Représentation des repères caméra et image et passage de l’un à l’autre 38 3.1 Initialisation de l’incertitude par une mise à jour de l’EKF . . . . . . 46 3.2 Initialisation de l’incertitude par les jacobiennes . . . . . . . . . . . . 48 3.3 Exemple de simulation d’une projection d’un ellipsoïde dans l’image 49 3.4 Zone de recherche et suivi par les jacobiennes . . . . . . . . . . . . . 50 3.5 Mise à jour avec erreur de linéarisation . . . . . . . . . . . . . . . . . 52 3.6 Paramétrisation inverse et représentation de [Montiel et al. 2006] . . 54 3.7 Exemple 2D pour le calcul de la fenêtre englobante . . . . . . . . . . 58 3.8 Exemples de plans intersectant l’image . . . . . . . . . . . . . . . . . 59 3.9 Zone de recherche et suivi par l’approche géométrique . . . . . . . . 63 3.10 Trajectoire utilisée pour la validation du suivi . . . . . . . . . . . . . 64 3.11 Mise à jour d’un amer suivant différentes observations . . . . . . . . 66 3.12 Les différentes possibilités de mise à jour . . . . . . . . . . . . . . . . 67 3.13 Mise à jour avec application du facteur correctif . . . . . . . . . . . . 68 3.14 Trajectoire suivie avec application ou non du correctif . . . . . . . . 69 3.15 Plate-forme expérimentale PAVIN . . . . . . . . . . . . . . . . . . . 71 3.16 Aperçu de quelques images de l’environnement PAVIN . . . . . . . . 72 3.17 Véhicule électrique VIPALab . . . . . . . . . . . . . . . . . . . . . . 72 3.18 Trajectoires accomplies avec une caméra à 3,75 Hz . . . . . . . . . . 73 3.19 Trajectoires accomplies avec une caméra à moins de 2 Hz . . . . . . 75x Table des figures 3.20 Environnement place de Jaude sous le simulateur . . . . . . . . . . . 76 3.21 Quelques exemples d’images issues de la caméra virtuelle . . . . . . . 77 3.22 Trajectoires suivies par les deux véhicules . . . . . . . . . . . . . . . 78 3.23 Erreur de localisation du second véhicule dans la carte du premier . 78 3.24 Robot utilisé dans cette expérimentation . . . . . . . . . . . . . . . . 79 3.25 Quelques images tirées du jeu de données de Milan . . . . . . . . . . 80 3.26 Odométrie et GPS de la trajectoire de Milan . . . . . . . . . . . . . 81 3.27 Résultats de localisation avec le SLAM monoculaire . . . . . . . . . . 81 3.28 Écart entre la position calculée et la vérité terrain . . . . . . . . . . . 82 3.29 Temps de calcul pris par image pour chaque algorithme . . . . . . . 82 4.1 Exemple de dérive en fonction de la distance parcourue . . . . . . . . 87 4.2 Exemple de différentes réalisations d’un biais unidimensionnel . . . . 96 4.3 Exemple de localisation 1D d’un véhicule avec intégration du biais . 97 4.4 Exemple d’évolution de l’incertitude d’un biais 1D . . . . . . . . . . 97 4.5 Exemple de localisation 1D d’un véhicule avec correction du biais . . 98 4.6 Exemple d’évolution et de correction de l’incertitude d’un biais 1D . 98 4.7 Trajectoire de simulation . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.8 Différentes réalisations de trajectoires . . . . . . . . . . . . . . . . . . 100 4.9 Trajectoire de simulation utilisée . . . . . . . . . . . . . . . . . . . . 101 4.10 Trajectoire calculée sans translation à l’origine . . . . . . . . . . . . 102 4.11 Trajectoire calculée avec translation à l’origine . . . . . . . . . . . . 103 4.12 Trajectoires sans associations de données . . . . . . . . . . . . . . . . 104 4.13 Trajectoires après la première boucle . . . . . . . . . . . . . . . . . . 104 4.14 Trajectoires complètes après la première boucle . . . . . . . . . . . . 105 4.15 Trajectoires estimées après les deux boucles . . . . . . . . . . . . . . 106 4.16 Organisation globale du système . . . . . . . . . . . . . . . . . . . . 107 4.17 Interactions entre les deux niveaux de l’architecture . . . . . . . . . . 108 4.18 État du système après une nouvelle convergence . . . . . . . . . . . . 109 4.19 Fonctionnement de l’algorithme haut niveau . . . . . . . . . . . . . . 110 4.20 Inconsistance et dérive du SLAM bas niveau . . . . . . . . . . . . . . 116 4.21 Prise en compte de la dérive sans fermeture de boucle . . . . . . . . 116 4.22 Prise en compte de la dérive avec fermeture de boucle . . . . . . . . 117 4.23 Écart de position entre le GPS RTK et le SLAM dans le cadre d’une fermeture de boucle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.24 Localisation obtenue sans intégrer les amers géo-référencés . . . . . . 120 4.25 Localisation obtenue avec intégration d’amers géo-référencés . . . . . 121 4.26 Écart de position entre le GPS RTK et le SLAM lors de l’intégration d’amers géo-référencés . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.1 Schéma simplifié d’un système centralisé . . . . . . . . . . . . . . . . 127 5.2 Schéma simplifié d’un système décentralisé . . . . . . . . . . . . . . . 128 5.3 Consanguinité dans le SLAM . . . . . . . . . . . . . . . . . . . . . . 131 5.4 Algorithme GCBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Table des figures xi 5.5 Séparation en sous-cartes afin d’éviter la consanguinité . . . . . . . . 139 5.6 Architecture de SLAM décentralisée pour un exemple à 2 véhicules . 140 5.7 Exemple d’inclusion d’un a priori dans le biais . . . . . . . . . . . . . 144 5.8 Initialisations possibles pour le biais . . . . . . . . . . . . . . . . . . 145 5.9 Trajectoire en convoi colonne . . . . . . . . . . . . . . . . . . . . . . 146 5.10 Temps de calcul requis par le processus décentralisé . . . . . . . . . . 147 5.11 Bande passante utilisée lors de la trajectoire . . . . . . . . . . . . . . 148 5.12 Trajectoire en convoi ligne . . . . . . . . . . . . . . . . . . . . . . . . 149 5.13 Exemple d’utilisation de l’algorithme GCBB . . . . . . . . . . . . . . 152 5.14 Associations trouvées entre deux passages . . . . . . . . . . . . . . . 154 6.1 Environnement PAVIN sous le simulateur . . . . . . . . . . . . . . . 159 6.2 Quelques exemples d’images issues de la caméra virtuelle sur PAVIN 159 6.3 Aperçu des trajectoires du scénario convoi colonne simulé . . . . . . 160 6.4 Trajectoires obtenues par le SLAM bas niveau pour le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 6.5 Intégration du biais pour le véhicule de tête dans le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.6 Intégration du biais pour le véhicule de queue dans le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.7 Localisation avec association de données pour le convoi colonne simulé163 6.8 Distance entre les véhicules en fonction du temps pour le convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.9 Quantité de données envoyées en fonction du temps pour le convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.10 Aperçu des trajectoires du scénario d’inversion de convoi . . . . . . . 166 6.11 Trajectoires obtenues par le SLAM bas niveau pour le scénario d’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6.12 Intégration du biais dans le scénario d’inversion de convoi (1/2) . . . 168 6.13 Intégration du biais dans le scénario d’inversion de convoi (2/2) . . . 168 6.14 Localisation avec association de données pour l’inversion de convoi . 170 6.15 Amers cartographiés pour le scénario d’inversion de convoi . . . . . . 171 6.16 Distance entre les véhicules en fonction du temps pour le scénario d’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.17 Quantité de données envoyées en fonction du temps pour l’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.18 Aperçu des trajectoires du scénario convoi colonne . . . . . . . . . . 174 6.19 Trajectoires obtenues par le SLAM bas niveau pour le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.20 Intégration du biais pour le véhicule de tête dans le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 6.21 Intégration du biais pour le véhicule de queue dans le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 6.22 Localisation avec association de données pour le convoi colonne réel . 177xii Table des figures 6.23 Distance entre les véhicules en fonction du temps pour le convoi colonne178 6.24 Quantité de données envoyées en fonction du temps pour le convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 6.25 Aperçu des trajectoires du scénario convoi ligne . . . . . . . . . . . . 179 6.26 Trajectoires obtenues par le bas niveau pour le scénario convoi ligne 179 6.27 Intégration du biais pour le véhicule de droite dans le convoi ligne . . 180 6.28 Intégration du biais pour le véhicule de gauche dans le convoi ligne . 180 6.29 Localisation avec association de données pour le convoi ligne . . . . . 181 6.30 Distance entre les véhicules en fonction du temps pour le convoi ligne 182 6.31 Quantité de données envoyées en fonction du temps pour le convoi ligne183 6.32 Aperçu des trajectoires du scénario à 3 véhicules . . . . . . . . . . . 183 6.33 Trajectoires obtenues par le bas niveau pour le convoi à trois véhicules184 6.34 Intégration du biais pour le véhicule de queue dans le scénario convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 6.35 Localisation avec associations pour le convoi à trois véhicules . . . . 186 6.36 Localisation avec association de données pour le véhicule de queue dans le convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . 187 6.37 Profil de distance en fonction du temps pour le convoi à trois véhicules189 6.38 Quantité de données envoyées au cours du temps pour le convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Liste des tableaux 3.1 Comparatif des deux méthodes de suivi . . . . . . . . . . . . . . . . 64 3.2 Comparatif des deux méthodes pour les mises à jour . . . . . . . . . 70 3.3 Amers utilisés sur une trajectoire réelle avec une caméra à 3,75 Hz . 74 4.1 Estimation du biais au point de bouclage (sans translation à l’origine) 101 4.2 Estimation du biais au point de bouclage (avec translation à l’origine) 103 5.1 Erreur quadratique moyenne du biais pour le convoi colonne . . . . . 147 5.2 Erreur quadratique moyenne du biais pour le convoi ligne . . . . . . 149Chapitre 1 Introduction et contexte Sommaire 1.1 Robotique et mobilité ....................... 2 1.2 Perception pour la robotique mobile .............. 5 1.2.1 Place de la perception ...................... 5 1.2.2 Système de localisation ..................... 6 1.2.3 Extension au multivéhicule ................... 7 1.3 Organisation du mémoire ..................... 82 Chapitre 1. Introduction et contexte 1.1 Robotique et mobilité La robotique est un domaine dont le nombre d’applications est en augmentation constante depuis son invention. Cet essor découle essentiellement du besoin d’automatiser des tâches répétitives et difficiles. En plus d’épargner des travaux physiquement épuisants à l’Homme, la robotique permet également d’effectuer de substantielles économies dans un monde de plus en plus compétitif et ouvert. Au fur et à mesure que des progrès ont été faits, la diversité des situations où la robotique était applicable a créé de nouvelles branches plus spécialisées, chacune avec ses objectifs et contraintes bien particuliers. Le travail à la chaîne a, en grande partie, été supplanté par la robotique industrielle. Des bras manipulateurs sont maintenant utilisés afin de tordre, percer, peindre, assembler ou encore déplacer les matériaux nécessaires à l’élaboration d’un produit commercialisable (voir figure 1.1). La miniaturisation des composants ainsi que la croissante fiabilité des technologies employées ont largement contribué à la diffusion de ces robots, tout comme à leur acceptation auprès des professionnels puis du grand public. (a) Robot Unimate, commercialisé en 1961 (b) Robot Adapt Quattro, conçu en 2007 Figure 1.1 – Évolution des robots industriels en plus de 40 ans Des machines intelligentes ont peu à peu été intégrées un peu partout. Le pan de la robotique domestique en est un bon exemple avec l’arrivée et la diffusion récente d’aspirateurs capables de nettoyer plusieurs pièces quotidiennement sans aucune intervention humaine (figure 1.2). Il s’agit certainement du type de robot le plus populaire actuellement. Il est aussi l’un des rares robots ménagers à exister. En effet, la limite de ces machines est souvent liée à la notion d’autonomie : elles doivent être suffisamment intelligentes pour ne pas nécessiter de présence humaine pour fonctionner. Cela est souvent difficile à accomplir avec des machines de petite taille qui ont des ressources limitées. À l’inverse, les robots à visée médicale sont majoritairement conçus pour être1.1. Robotique et mobilité 3 utilisés par des médecins et non en complète autonomie. Le but est souvent de faciliter le travail du chirurgien en fournissant des nouveaux moyens d’interagir avec les patients (figure 1.2). (a) Roomba, vendu à plus de 5 millions d’exemplaires en 2009 (b) Da Vinci, 1750 exemplaires utilisés en 2011 Figure 1.2 – Robotique domestique et médicale Globalement, il est possible de construire deux grandes catégories pour regrouper les robots : ceux mobiles, dont fait partie le Roomba par exemple, et ceux fixes (bras manipulateurs, machines médicales...). La mobilité peut être gérée de deux manières différentes : soit en téléopérant le robot, soit en le dotant d’une autonomie suffisante de manière à ce qu’il puisse se déplacer seul dans un environnement donné. Ce dernier cas implique que la machine soit suffisamment “intelligente” pour comprendre l’environnement qui l’entoure. De manière réductrice, un aspirateur autonome doit être capable d’éviter tous les objets d’une pièce, qu’ils soient fixes ou mobiles, de parcourir l’intégralité de la surface à nettoyer et de revenir à sa station de recharge. Chacune de ces actions nécessite de prendre des décisions par rapport aux informations disponibles à un moment donné. Une grande variété est à noter dans la forme et la façon de se mouvoir de ces robots. Cela est fortement conditionné par l’environnement applicatif visé. De fait, la communauté scientifique sépare souvent les robots mobiles en trois grandes branches : les robots terrestres (d’intérieur ou d’extérieur), les robots aériens et enfin les robots sous-marins (voir figure 1.3). Cette catégorisation vient aussi du fait qu’il est extrêmement difficile de concevoir une intelligence qui puisse s’adapter à plusieurs milieux. Souvent, les équipes de recherche travaillant sur des environnements différents sont bien distinctes. La catégorie “terrestre”, dont ce manuscrit va traiter, se divise encore en fonction du moyen de déplacement du robot. Des chenilles, des pattes ou même des jambes peuvent être utilisées comme le montre la figure 1.4, même si le plus courant reste encore les roues. Le type de sol sur lequel le robot est amené à évoluer influe grande-4 Chapitre 1. Introduction et contexte (a) Cybercar de l’INRIA (b) Aeryon Scout de Aeryon Labs (c) SeaExplorer par ACSA Figure 1.3 – Des exemples de robots mobiles ment sur la motorisation de celui-ci. Par ailleurs, les besoins sont très différents dans un milieu urbain et dans un contexte désertique par exemple. Les environnements ruraux sont également différenciés des autres puisque le manque de structure du sol poussent généralement à développer des véhicules bien plus volumineux que dans les autres milieux. Les objectifs attribués à ces robots terrestres peuvent être variés. On peut noter le transport de marchandises, une visée éducative ou encore tout simplement le divertissement. Bien évidemment, ce sont loin d’être les seuls domaines où ils sont utilisés. Les systèmes de surveillance en font un usage croissant, tout comme le milieu agricole. De même, le transport de personnes (Intelligent Transportation Systems ou ITS en anglais) est souvent au coeur des problématiques associées à la robotique mobile. La mobilité est un aspect essentiel de cette thèse. En effet, le but est ici de faire collaborer des véhicules afin qu’ils soient à même de savoir où ils se situent les uns par rapport aux autres. Le cadre est bien ici les robots terrestres. De manière plus précise, ces derniers peuvent être assimilés à des véhicules puisque l’on s’oriente vers des robots capables de transporter des personnes ou des marchandises. Cela implique des robots faisant une certaine taille mais ne définit pas pour autant la vitesse de ceux-ci. Dans le cadre du transport de personnes par exemple, la vitesse d’un véhicule peut facilement varier de quelques kilomètres par heure pour une1.2. Perception pour la robotique mobile 5 (a) NAO, petit robot humanoïde (b) BigDog, robot quadrupède pour le transport de matériel (c) Morph, robot à chenilles de LEGO Mindstorms Figure 1.4 – Des robots terrestres avec des systèmes de mobilité différents voiturette de golf à plus de 130 km/h pour une voiture plus classique. Cet écart a une grande influence sur la façon dont le système est conçu, tout comme sur le design de l’algorithmie destinée à l’animer. Dans tous les cas, le système de perception du véhicule doit être capable de fournir des informations suffisamment détaillées pour permettre des actions complexes en toute sécurité. 1.2 Perception pour la robotique mobile 1.2.1 Place de la perception Tout système de robotique mobile, voire de robotique, s’inscrit dans une logique perception - contrôle - action. Le schéma de la figure 1.5 montre les interactions entre ces différents modules. Son fonctionnement est simple : l’analyse de l’environnement ainsi que du véhicule lui-même constitue la partie perception. Ces informations vont6 Chapitre 1. Introduction et contexte permettre au module de contrôle de décider de l’action à accomplir. Celle-ci sera, bien entendu, réalisée par la partie éponyme. Le retour de la dite action pourra ou non être communiqué à la perception afin d’orienter l’analyse. De manière similaire, le contrôle et la perception peuvent être amenés à échanger de l’information afin de valider ou de rejeter une première décision prise. L’ajout d’informations du côté de la perception peut en effet complètement changer le résultat de l’algorithme de contrôle. Figure 1.5 – Schéma général d’un système robotique Considérons une application dont l’objectif est de rejoindre un point précis, tout en évitant d’écraser des piétons (ce qui est tout à fait louable). Le module de perception aura, dans ce cas, pour but principal de détecter les piétons à l’aide de capteurs (une caméra par exemple) tout en se localisant dans l’environnement. La partie contrôle quant à elle, devra décider du chemin à emprunter afin d’éviter les passants dont la détection aura été fournie par la perception. Enfin, la trajectoire validée sera effectuée au sein de la brique action qui devra traduire en commandes pour le véhicule le parcours donné par le module de contrôle. Le déplacement réellement effectué pourra être transféré à la perception afin de calculer la position des piétons précédemment détectés et ainsi vérifier leur présence pour la nouvelle position du robot. Le schéma général itérera jusqu’au point d’arrivée. 1.2.2 Système de localisation Dans ce manuscrit, nous nous concentrerons majoritairement sur le module de perception. L’objectif étant de pouvoir localiser précisément les membres d’une flotte de véhicules, la fusion des données issues des capteurs est un point central. La partie guidage automatique ainsi que la prise de décision relative à des événements (évitement d’obstacles, détection de dangers...) sont des aspects qui ne seront pas abordés ici. Le système de perception qui sera présenté tout au long de ce mémoire peut1.2. Perception pour la robotique mobile 7 être assimilé à un système de localisation, l’objectif étant de savoir où se situe chacun des véhicules d’une flotte. Pour ce faire, il est nécessaire d’équiper ces robots avec des capteurs de manière à ce qu’ils se repèrent dans l’environnement. Il en existe différentes sortes, à des prix très variables, chacun ayant ses avantages et ses défauts. Deux catégories sont généralement utilisées pour les regrouper : les capteurs dits proprioceptifs et extéroceptifs. Les premiers donnent des informations sur l’état même du véhicule. On retrouve, entre autres, les odomètres qui renseignent sur le déplacement effectué entre deux moments successifs (mesure relative) et les centrales inertielles qui elles permettent d’obtenir les vitesses linéaires et angulaires d’un robot mobile. La seconde catégorie regroupe tous les capteurs permettant d’avoir des informations à l’aide de l’environnement. Les GPS en sont un bon exemple puisqu’ils utilisent des satellites afin d’obtenir une position absolue à un instant donné. Dans le cadre de la localisation d’un véhicule, les capteurs extéroceptifs (hormis les GPS) sont souvent utilisés pour reconnaître des portions de l’environnement déjà vues auparavant. La mesure du décalage d’une entité dans plusieurs données issues du capteur va permettre de déduire le déplacement du robot. Il est également possible d’identifier directement un véhicule distant et ainsi d’en inférer sa position relativement au capteur ayant servi à le détecter. Les plus communément employés sont les caméras, les télémètres et les radars. Les intérêts de chacun de ces capteurs seront développés ultérieurement dans ce manuscrit et ce relativement à l’algorithme de localisation que l’on cherche à construire. 1.2.3 Extension au multivéhicule Au cours des dernières décennies, la communauté autour de la robotique mobile s’est essentiellement concentrée sur la localisation d’un unique véhicule. L’extension de ces algorithmes vers des applications nécessitant plusieurs véhicules n’a été envisagée que très récemment. Pourtant, de nombreuses situations nécessitent, ou peuvent tirer avantage, d’un ensemble de robots fonctionnant de manière coopérative via des communications sans fil (voir figure 1.6). Parmi les applications citées précédemment, les ITS tirent naturellement parti d’une extension à plusieurs véhicules. Un système de localisation efficace pourrait à terme conduire à des voitures entièrement autonomes. Le milieu agricole est également concerné par l’utilisation d’une flotte de robots. En effet, plutôt que d’utiliser une seule grosse machine, il est envisageable de se tourner vers une multitude de plus petits robots, chacun s’occupant, par exemple, d’un unique sillon. L’intérêt ici serait surtout d’éviter la compaction des sols causée par les machines volumineuses. De nombreuses autres possibilités pourraient être citées puisque le fait d’avoir plusieurs véhicules permet à la fois d’être plus rapide pour couvrir une zone et d’être plus précis dès lors qu’au moins deux véhicules passent au même endroit. Néanmoins, le fait que l’émergence de ces systèmes soit très récente n’est pas anodin. D’importantes contraintes rendent la tâche beaucoup plus compliquée qu’avec8 Chapitre 1. Introduction et contexte Figure 1.6 – Coopération dans le cadre d’un système multivéhicule un seul véhicule. La présence d’une couche réseau est un premier point. Il faut concevoir l’application de telle sorte qu’elle soit capable de gérer les ruptures de communication qui peuvent intervenir. De même, les latences ainsi que les désynchronisations doivent être prises en compte. Il faut aussi décider de quelles informations envoyer et quand. En effet, la bande passante nécessaire à l’envoi et à la réception de données n’est pas infinie et dépend fortement du nombre de véhicules impliqués dans les échanges. La sélection des informations à envoyer joue également un rôle crucial dans la façon dont vont pouvoir être calculées les positions des robots. Sans a priori initial, un véhicule devra également être capable de situer chaque robot par rapport à lui-même, ce qui requiert des algorithmes robustes. De manière similaire à la bande passante, le coût calculatoire doit être au centre de la conception de l’application multivéhicule, la gestion des localisations des membres de la flotte induisant un surcoût non négligeable. Enfin, il faut aussi garder en tête le coût financier afin de rendre l’application commercialement viable. Chaque véhicule étant amené à embarquer des capteurs, il faudra être prudent lors du choix de ceux-ci car la solution globale verra son prix multiplié par le nombre de robots de la flotte. L’ensemble de ces points sera traité dans ce mémoire. 1.3 Organisation du mémoire Avant même de développer un système multivéhicule, il est nécessaire de construire un algorithme où chaque robot est capable d’estimer sa propre position. Cela sera l’objet du chapitre 2. Bien évidemment, le design d’un tel processus sera fait en fonction des contraintes fixées par l’application multivéhicule (coût fi- nancier, temps de calcul, quantité d’informations à traiter...). Pour ce faire, nous présenterons d’abord les capteurs utilisés puis l’algorithme de localisation employé. Les problématiques amenées par les choix faits seront étudiées lors du chapitre 3. Dans celui-ci, les améliorations apportées au système monovéhicule seront détaillées.1.3. Organisation du mémoire 9 L’algorithme construit sera ensuite testé dans des situations variées afin de valider les différentes innovations présentées au fur et à mesure du chapitre. Le chapitre suivant (chap. 4) se concentrera sur la dérive naturelle de ces algorithmes de localisation. Ce point est crucial car la divergence de ces systèmes se retrouve exacerbée lors de l’extension au multivéhicule. Un état de l’art sera dressé et une solution ainsi que son intégration seront proposées. L’extension au cas multivéhicule sera décrite durant le chapitre 5. Après une analyse de la littérature dans le domaine, une architecture résolvant les différentes problématiques citées précédemment sera présentée. L’estimation de la localisation des robots d’une même flotte sera également largement abordée. Bien que chaque contribution soit validée au fur et à mesure du mémoire (via simulation ou avec des expérimentations réelles) le chapitre 6 présentera les résultats globaux de l’algorithme multivéhicule développé. Divers exemples de trajectoires dans des situations variées seront exposés afin de démontrer l’efficacité de notre application. Enfin, le chapitre 7 proposera une synthèse des résultats obtenus ainsi que des limites de l’application conçue. Les perspectives d’évolution de l’algorithme seront également abordées.Chapitre 2 Localisation d’un véhicule Sommaire 2.1 Analyse des capteurs pour la localisation . . . . . . . . . . . 13 2.1.1 Capteurs proprioceptifs . . . . . . . . . . . . . . . . . . . . . 13 2.1.1.1 Capteurs inertiels . . . . . . . . . . . . . . . . . . . 13 2.1.1.2 Odomètre et angle volant . . . . . . . . . . . . . . . 13 2.1.2 Capteurs extéroceptifs . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2.2 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2.3 Télémètre laser . . . . . . . . . . . . . . . . . . . . . 17 2.1.2.4 Radar . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.3 Bilan des capteurs . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Méthodes de localisation pour le SLAM . . . . . . . . . . . . 20 2.2.1 Minimisation globale par ajustement de faisceaux . . . . . . . 21 2.2.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2.1 Filtre de Kalman . . . . . . . . . . . . . . . . . . . . 23 2.2.2.2 Filtre de Kalman étendu . . . . . . . . . . . . . . . 25 2.2.2.3 Filtre de Kalman sans parfum . . . . . . . . . . . . 28 2.2.2.4 Filtre d’information . . . . . . . . . . . . . . . . . . 29 2.2.2.5 Filtre particulaire . . . . . . . . . . . . . . . . . . . 30 2.2.3 Bilan des méthodes de localisation . . . . . . . . . . . . . . . 30 2.3 SLAM pour l’EKF dans un contexte de robotique mobile . 31 2.3.1 Prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mise à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.3 Spécificité de la vision . . . . . . . . . . . . . . . . . . . . . . 4012 Chapitre 2. Localisation d’un véhicule Construire un algorithme de localisation multirobot nécessite avant toute chose que chaque véhicule soit capable de se localiser. En effet, cette information de position sera partagée avec les autres membres de la flotte et devra être la plus juste possible. Au-delà même de ces considérations, façonner la partie monovéhicule pour qu’elle soit en adéquation avec son extension à plusieurs robots est essentiel. Chacun des choix concernant les aspects plus bas niveau va régir les performances globales de l’application multivéhicule. Afin de prendre une décision éclairée, il convient de définir le cadre applicatif de nos développements. En effet, celui-ci va permettre de fixer les contraintes gé- nérales de notre système multivéhicule et donc orienter le choix des capteurs et de la méthode de localisation monovéhicule. L’objectif est de construire un système de localisation suffisamment général pour qu’il puisse ensuite être adapté à des applications bien précises. Cela implique que le nombre de véhicules peut être élevé et qu’il est donc important de limiter la quantité de données à échanger. Dans un contexte agricole par exemple, plus d’une dizaine de robots pourraient être utilisés en parallèle. On peut aussi imaginer un système de transport de personnes, dédié à une zone géographique précis, qui nécessiterait un volume de véhicules similaire. Ces deux exemples sont intéressants puisqu’ils permettent aussi de constater que l’environnement peut être varié. Dans le contexte urbain, beaucoup d’informations peuvent être exploitées afin d’aider la localisation. Cela sera un peu moins le cas dans des environnements plus ouverts. Il faudra donc être vigilant à ce que la méthode et les capteurs choisis puissent opérer dans des contextes différents. Au niveau de la vitesse des véhicules, celle-ci sera peu élevée (autour de 2 mètres par seconde) afin de permettre une première validation dans des conditions maîtrisées. Enfin du point de vue de la justesse de localisation souhaitée, il est difficile de définir un ordre de grandeur car celui-ci dépend de la tâche visée. Néanmoins, il est essentiel que le système développé puisse être spécialisé pour atteindre des précisions autorisant la conduite automatique (autour de la vingtaine de centimètres) lorsque cela est possible car de nombreuses applications en découlent. Ce chapitre sera entièrement consacré à la conception de l’algorithme de localisation monovéhicule. Les différents choix technologiques seront toujours étudiés par rapport à la littérature ainsi qu’en relation avec l’impact qu’ils auront sur le multivéhicule. La section 2.1 présentera les différents capteurs disponibles pour la localisation. La section qui suit (section 2.2) se concentrera quant à elle sur les mé- thodes pour la localisation. La section 2.3 exposera ensuite le fonctionnement de la solution envisagée, tout d’abord de façon générale dans les sous-sections 2.3.1 et 2.3.2, puis par rapport aux capteurs sélectionnés (sous-section 2.3.3).2.1. Analyse des capteurs pour la localisation 13 2.1 Analyse des capteurs pour la localisation La localisation d’un unique véhicule est donc un domaine qui est aujourd’hui devenu un point central de la robotique mobile. De nombreux chercheurs travaillent sur cette thématique, que cela soit du côté de la conception des capteurs ou encore dans l’élaboration de méthodes pour la localisation. Afin de faciliter la compréhension, ces deux parties seront séparées mais traitées en relation l’une avec l’autre dans la suite de cette section. Comme énoncé précédemment, on distingue généralement les capteurs proprioceptifs, renseignant sur l’état même du robot, de ceux dits extéroceptifs qui donnent des informations sur l’environnement. Nous allons commencer par étudier la première catégorie. 2.1.1 Capteurs proprioceptifs 2.1.1.1 Capteurs inertiels Les capteurs inertiels exploitent des propriétés physiques pour extraire les accé- lérations (accéléromètres) ou les rotations (gyroscopes, gyromètres). Les centrales inertielles peuvent être considérées comme des capteurs, quand bien même il s’agit plus d’un regroupement de capteurs. En effet, celles-ci embarquent 3 gyromètres ainsi que 3 accéléromètres. Cela permet d’estimer les vitesses (linéaire et angulaire) ainsi que la pose complète d’un mobile, c’est-à-dire la position 3D et les 3 angles associés (roulis, tangage, lacet). L’intégration au cours du temps des mesures fournies par la centrale inertielle donne des résultats généralement satisfaisants. Bien évidemment, la qualité des capteurs qui la compose va fortement influencer la précision. Le prix est donc un aspect important lors du choix d’une centrale inertielle. Il est également possible d’utiliser uniquement des gyromètres sans centrale inertielle ce qui permet souvent d’avoir de meilleurs résultats avec un coût similaire. Hormis le prix, les capteurs inertiels sont affectés par des erreurs cumulatives. Ceux-ci ne fournissent pas de valeurs absolues mais quantifient des mouvements. Ainsi, si une erreur de mesure est faite à un instant donné, elle sera conservée dans toutes les estimations suivantes. Afin de compenser ce problème, les capteurs inertiels sont souvent couplés avec d’autres informations. 2.1.1.2 Odomètre et angle volant La mesure odométrique est à rapprocher des informations obtenues en sortie d’une centrale inertielle. Des capteurs, équipés sur les roues d’un véhicule, permettent de quantifier le déplacement accompli. Le principal avantage d’un odomètre est son coût ainsi que le fait qu’il est maintenant équipé en standard sur les véhicules. Il est généralement associé au capteur d’angle volant qui comme son nom l’indique renseigne sur l’angle de braquage des roues. Ces deux informations, couplées à un modèle d’évolution du robot, permettent d’obtenir des résultats de localisation convenable.14 Chapitre 2. Localisation d’un véhicule Néanmoins, tout comme les capteurs inertiels, les informations odométriques correspondent à des déplacements successifs rendant les erreurs cumulatives au fil du temps. Sur de longues distances, les écarts entre ce qui est estimé par odométrie et ce qui est réellement parcouru deviennent considérables. Les données odométriques (déplacement et angle de braquage) seront ainsi très souvent utilisées pour une première estimation qui sera ensuite affinée via un autre capteur. Contrairement à la centrale inertielle en revanche, uniquement le cap du robot (lacet) et la distance parcourue peuvent être estimés via l’odométrie. 2.1.2 Capteurs extéroceptifs Les différents capteurs présentés jusqu’ici sont ceux principalement utilisés pour renseigner l’état du véhicule. Les suivants rentrent, quant à eux, dans la catégorie des extéroceptifs. Les utiliser induit bien souvent de suivre des objets de l’environnement afin d’obtenir une information de déplacement. Généralement, ces données sont stockées dans ce qui est appelé une carte. Celle-ci peut être construite et utilisée en temps réel ou être fournie au véhicule et exploitée par l’algorithme de localisation. Parmi ceux présentés, le GPS fait figure d’exception puisqu’il fournit des informations absolues et non relatives. 2.1.2.1 GPS Le GPS (Global Positioning System) est très certainement le capteur de positionnement le plus populaire. Ce système de localisation par satellites permet d’obtenir une position absolue dont la précision varie en fonction du nombre de satellites disponibles. Le principe de fonctionnement est le suivant : des satellites parfaitement localisés transmettent en permanence leur position ainsi que la date associée à celleci. Un récepteur décode les signaux reçus et peut ainsi estimer, par triangulation, sa position sur la planète. Créé à des fins militaires, le système GPS s’est ensuite ouvert aux civils avec des précisions volontairement dégradées. En 2000, cette contrainte a été levée permettant ainsi d’atteindre une précision d’une dizaine de mètres. Cela s’avère généralement suffisant comme aide à la navigation, d’autant plus que la position est généralement corrigée par la mise en correspondance avec la route. La dénomination de GPS est quelque peu trompeuse puisque plusieurs systèmes du même acabit existent. On peut citer GLONASS, Beidou et Galileo (qui n’est pas encore opérationnel) qui sont les équivalents russe, chinois et européen du système GPS américain. Ceux-ci offrent une précision similaire au GPS, voire même légèrement meilleure sous certaines conditions dans le cas de Galileo. Quelque soit le système de positionnement utilisé, il est important de noter que la qualité de la localisation fournie dépend du nombre de satellites disponibles. Pour des applications visant à la conduite de manière autonome, cette précision est loin d’être suffisante. Des solutions, toujours basées sur les GPS, permettent d’améliorer ce point. Les GPS RTK (Real Time Kinematic) utilisent une station2.1. Analyse des capteurs pour la localisation 15 terrestre dont la position est parfaitement connue. Celle-ci envoie les correctifs à appliquer au récepteur GPS afin d’améliorer la précision (voir figure 2.1). Cela permet d’obtenir des positions justes au centimètre près. Néanmoins, ces systèmes sont extrêmement onéreux. Ces capteurs sont souvent utilisés comme vérité terrain afin de quantifier la justesse de résultats de localisation. Figure 2.1 – Fonctionnement d’un GPS RTK avec la correction par la station La localisation absolue fournie par des GPS bas coûts, bien qu’imprécise rend beaucoup plus facile le travail coopératif puisque toutes les positions sont données dans un même référentiel. Néanmoins, les GPS souffrent d’autres désavantages. Les deux principaux sont les multitrajets et les pertes du signal dans des environnements cloisonnés. Dans le premier cas, les signaux émis par les satellites sont réfléchis par des bâtiments au lieu d’être reçus directement par le GPS. Ainsi, le temps de vol est allongé et l’estimation de la position est biaisée. Ce phénomène est dangereux car le récepteur n’est pas conscient de cette erreur de positionnement : il y a perte de l’intégrité (la position réelle du véhicule n’est pas située dans l’incertitude de mesure). Des solutions palliatives existent néanmoins afin de contrer ce problème comme la technologie RAIM (Receiver Autonomous Integrity Monitoring) qui utilise la redondance d’information pour lever l’ambiguïté. Le deuxième cas est différent. Il correspond à la perte du signal GPS à cause d’un environnement qui masque les satellites. Cela apparaît souvent en milieu urbain à cause des bâtiments. On parle de canyon urbain. Une vue schématique de ces deux problèmes est donnée en figure 2.2.16 Chapitre 2. Localisation d’un véhicule (a) Erreur de positionnement à cause de multitrajets (ligne réfléchie en pointillés) (b) Perte du positionnement à cause d’un canyon urbain Figure 2.2 – Problèmes affectant les GPS 2.1.2.2 Caméra Les caméras commencent à occuper l’habitacle de nos voitures depuis quelques années maintenant. Elles ont un faible coût et fournissent beaucoup de données. L’information visuelle étant celle sur laquelle l’humain se base le plus, il est naturel de s’orienter vers ces capteurs pour des applications de localisation. Le principe est souvent le suivant : extraire des objets statiques dans l’image qui soient facilement reconnaissables et les suivre. En mesurant les écarts dans l’image entre les positions successives des objets, il est possible de déduire le déplacement du véhicule. L’intérêt majeur des caméras est de fournir beaucoup d’informations qui, regroupées en sousensembles de pixels, sont assez facilement différentiables. Parmi les contraintes de ces capteurs, il faut tout de même noter une phase d’étalonnage. Celle-ci permet de passer les informations de l’image, exprimées en pixels, dans un repère métrique plus classique. Cette étape est essentielle pour pouvoir mesurer les déplacements du véhicule. Les paramètres permettant d’inférer ce changement de repère sont appelés paramètres intrinsèques de la caméra. En plus de ceux-ci, on mesure généralement la position de la caméra par rapport au véhicule afin de pouvoir coupler les informations visuelles avec des données provenant d’un autre capteur. Ce nouveau changement de repère est régi par les paramètres extrinsèques de la caméra. Ceux-ci sont aussi estimés durant la phase d’étalonnage. Cette dernière sert aussi à estimer la distorsion qui affecte l’image (voir figure 2.3). Ce défaut optique, s’il n’est pas pris en compte, peut conduire à des problèmes de suivi. Les caméras sont grandement affectées par les conditions météorologiques. En effet, une forte pluie, un soleil éclatant ou encore des chutes de neige rendent le suivi d’objets plus difficile. Ce ne sont pas les seuls aspects ayant un impact sur la qualité2.1. Analyse des capteurs pour la localisation 17 (a) Distorsion de type barillet (b) Distorsion de type croissant Figure 2.3 – Schématisation des effets de la distorsion de l’image. On peut par exemple citer : le flou, la résolution du capteur, le temps de prise de vue et de saturation, etc. Les algorithmes construits doivent être robustes afin de résister à de telles conditions. L’utilisation d’une unique caméra pose le problème de l’estimation de la distance des objets. À partir d’une seule image, la profondeur ne peut être déterminée. C’est pourquoi une paire stéréoscopique (deux caméras) est souvent utilisée. Celle-ci permet de trianguler la position d’un objet dès lors qu’il apparaît dans le champ de vue des deux caméras. Un compromis doit être fait sur l’écart entre les caméras : plus elles sont éloignées, plus l’estimation sera précise (parallaxe suffisante) et à l’inverse plus elles sont proches et plus le champ recouvrant nécessaire à l’estimation de la profondeur sera important. L’étalonnage joue un rôle clef pour une paire stéréoscopique car il permet de synchroniser les deux caméras afin qu’elles délivrent des images sur la même base de temps. Grâce à ce procédé, les informations extraites dans chaque caméra peuvent être comparées. 2.1.2.3 Télémètre laser Les télémètres laser, souvent abrégés LRF pour Laser RangeFinders, sont une alternative intéressante aux caméras puisqu’ils fournissent directement la distance des objets par rapport au capteur. Le principe est simple : un faisceau laser est émis sur un miroir rotatif permettant ainsi de balayer l’environnement de 90 à 270˚en fonction du télémètre. Le faisceau laser est réfléchi dès lors qu’un obstacle est percuté. Au retour, le temps de vol est mesuré et ainsi, la distance de l’obstacle peut être connue. La figure 2.4 propose un schéma de fonctionnement simplifié d’un LRF. Le télémètre laser généralement employé dans la robotique mobile fournie une seule nappe et permet ainsi de n’avoir des informations que sur un seul plan. Ce capteur reste cependant assez cher même si la précision des données est très bonne. La résolution du télémètre laser peut également être problématique. Celle-ci est généralement de l’ordre de quelques points par degré. Reconnaître des objets préalablement18 Chapitre 2. Localisation d’un véhicule (a) (b) Figure 2.4 – Schéma de fonctionnement simplifié d’un télémètre laser détectés devient alors plus difficile puisqu’ils seront uniquement identifiables grâce à faible nombre de points. Des télémètres laser à plusieurs nappes existent, permettant ainsi d’avoir une information de hauteur, tout en augmenter la quantité de données. Plus récemment, de nouveaux LRF ont fait leur apparition. Leur intérêt réside dans la possibilité d’avoir des informations 3D sur 360˚. Toutefois, la quantité de données à traiter est telle qu’il est difficile d’utiliser ce capteur en temps réel. Son prix est aussi très élevé limitant de fait les applications dans lesquelles il est employé. Enfin, la construction d’une carte nécessite que l’on puisse reconnaître des endroits déjà cartographiés. Avec les données fournies par ces capteurs, des plans et des droites 3D sont généralement utilisées, ce qui rend la tâche compliquée. 2.1.2.4 Radar Le radar est très peu employé dans le domaine de la localisation. Pourtant, celuici n’est que très peu affecté par les conditions météorologiques ou les conditions de luminosité, ce qui est un avantage majeur par rapport à la caméra ou au télémètre laser.2.1. Analyse des capteurs pour la localisation 19 (a) Laser 3D Velodyne (b) Exemple d’image laser 3D Figure 2.5 – Laser 3D Comme le télémètre laser, il s’agit d’un capteur de distance. Son principe est simple : une onde de haute énergie est émise et est réfléchie par les surfaces percutées. Le retour de l’écho va permettre de mesurer la distance à la surface et ainsi de cartographier l’environnement. Dans certains cas, ce capteur peut offrir une vue à 360˚des alentours. En revanche, sa rotation est souvent lente, entraînant ainsi un important phénomène de distorsion dans les images radar [Vivet 2011]. Par ailleurs, le type de surface sur laquelle est réfléchie l’onde influe sur les résultats obtenus et peut ainsi créer des décalages importants avec la réalité. Il s’agit du speckle. Ce dernier peut générer des obstacles inexistants ou, au contraire, en faire disparaître. Ces capteurs demeurent assez coûteux, au même titre que les télémètres laser. Enfin, le même problème de reconnaissance dans la carte évoqué pour les capteurs télémétriques se pose ici aussi. En effet, le speckle et les effets de flou dans la réponse complexifient la tâche de mise en correspondance des informations. 2.1.3 Bilan des capteurs Les capteurs présentés dans cette section sont à mettre en relation avec les contraintes établies par rapport au contexte de l’application. Il faut donc une solution peu onéreuse et qui à la fois fournisse suffisamment d’informations pour que différents véhicules puissent reconnaître un même endroit. Pour ces raisons, nous n’avons pas souhaité nous orienter vers des capteurs de distance qui, bien que commodes, sont à la fois chers et complexes à mettre en oeuvre pour la construction de cartes amenées à être utilisées par plusieurs véhicules. Pour ces mêmes raisons de coût, nous avons décidé de privilégier le duo odomètre et angle volant plutôt qu’une centrale inertielle. L’avantage est que ces capteurs sont maintenant intégrés en standard sur la majorité des véhicules et offrent une première estimation satisfaisante même si elle est de moindre précision qu’avec une centrale inertielle plus coûteuse. Bien entendu, les informations odométriques seules ne sont pas suffisantes. Ainsi,20 Chapitre 2. Localisation d’un véhicule nous avons décidé d’adjoindre une caméra. Ce choix n’est pas anodin. La caméra est devenue un standard dans le milieu automobile grâce à son faible prix et la quantité d’informations fournie. De plus, ce capteur est souvent utilisé quand il s’agit de reconnaître des endroits déjà traversés, ce qui correspond tout à fait à une approche multivéhicule. L’avantage de l’associer à l’odomètre est de pouvoir contraindre le facteur d’échelle. En effet, lorsqu’une caméra est utilisée pour de la localisation, tout est mesuré à un facteur d’échelle près qui ne peut être quantifié que dans certaines conditions. Cela ne serait pas gênant si celui-ci ne dérivait pas au fil du temps [Strasdat et al. 2010b], rendant ainsi la localisation délicate. Les données odométriques vont pouvoir prévenir ce comportement en imposant la position du véhicule dans un repère métrique. L’ajout d’un GPS permettrait de lever bon nombre de contraintes pour l’extension à plusieurs véhicules. La localisation dans un repère absolu serait un avantage majeur puisque cela permettrait de connaître la position approximative de chaque membre de la flotte. Néanmoins, les problèmes de disponibilité évoqués ci-avant font qu’il est risqué de choisir un tel capteur pour résoudre le positionnement relatif des véhicules. Nous avons choisi de développer une solution basée sur le couple odomètre et caméra. Ainsi, nous avons décidé de ne pas intégrer de GPS. Cependant, son utilisation pourrait être bénéfique. Il faudra donc que l’algorithme de localisation permette d’ajouter ce capteur facilement si l’on souhaite étendre notre application. La solution de localisation de chaque véhicule sera donc locale, et non absolue, et basée sur l’utilisation conjointe d’une caméra avec des informations odométriques (déplacement et angle volant). Les différentes contraintes fixées en début de chapitre sont respectées par ce choix. Il faudra toutefois être vigilant aux faiblesses de ce duo. En effet, l’odométrie a tendance à accumuler les erreurs et une unique caméra ne permet pas une estimation immédiate de la distance. Ces points devront être pris en considération lors de la construction d’un algorithme de localisation. Ces inconvénients seront d’ailleurs largement évoqués dans le chapitre 3. 2.2 Méthodes de localisation pour le SLAM Le choix de la méthode de localisation est primordial. C’est d’ailleurs une dé- cision à prendre en adéquation avec les capteurs sélectionnés, à savoir dans notre cas une caméra, un odomètre et un capteur d’angle de braquage. Durant cette première partie du manuscrit, il a souvent été question de suivre des objets grâce aux capteurs afin de pouvoir estimer les déplacements d’un véhicule. Ces objets forment ce que l’on a défini comme étant une carte. Les applications visées par ces travaux de thèse ne prennent pas comme pré-requis l’existence d’une quelconque carte. Il est donc nécessaire que chaque véhicule construise la sienne au fur et à mesure, tout en se localisant dans celle-ci. Ce procédé est connu sous le nom de Simultaneous Localization And Mapping (SLAM), ou localisation et cartographie simultanées. Initié dès le début des années 90 [Smith et al. 1990][Leonard & Durrant-Whyte 1991],2.2. Méthodes de localisation pour le SLAM 21 voire même quelques années auparavant [Smith & Cheeseman 1986], le SLAM est un cadre regroupant toutes les méthodes de localisation basées sur des cartes construites de manière incrémentale. Les lecteurs intéressés pourront d’ailleurs se tourner vers [Durrant-Whyte & Bailey 2006] et [Bailey & Durrant-Whyte 2006] pour une introduction au domaine. Bien évidemment, toutes les approches de localisation ne se basent pas sur du SLAM. Néanmoins, ces méthodes reposent essentiellement sur des capteurs fournissant une localisation absolue (souvent des GPS RTK), ce qui n’est pas notre cas. Quelques approches de localisation par caméra arrivent à s’extraire du cadre du SLAM. On peut par exemple citer [Lovregrove et al. 2011] qui travaille à partir des gradients de l’image ou [Aires et al. 2008] qui présente une odométrie via flot optique basée sur les couleurs. Ces méthodes sont en nombre restreint et peu adaptées au contexte multivéhicule. En effet, des informations sur l’environnement doivent être transmises entre les robots afin que ceux-ci puissent savoir où ils se situent les uns par rapport aux autres. Ainsi, toutes les techniques de localisation présentées ci-après s’inscrivent dans la thématique du SLAM en environnement statique appliqué à la vision. Des techniques spécifiques (SLAMMOT) existent néanmoins pour les environnements dynamiques mais ne seront pas abordées ici. La littérature étant très vaste à ce sujet, cette section sera découpée en deux parties. Nous commencerons par une rapide analyse des méthodes de minimisation globale (sous-section 2.2.1) avant de détailler les différents filtres qui existent (sous-section 2.2.2). Ces deux courants s’opposent dans le principe : la minimisation globale est proche d’un estimateur de maximum de vraisemblance alors que les filtres s’orientent davantage vers la minimisation des erreurs quadratiques. Les techniques de localisation nécessitant la position exacte des amers observés pour fonctionner (triangulation, géométrie épipolaire) ne seront pas abordées ici puisque généralement difficiles à mettre en oeuvre sur des applications réelles. De plus, l’utilisation d’une unique caméra nécessite d’avoir une solution de localisation robuste aux approximations, éliminant de ce fait ces méthodes. 2.2.1 Minimisation globale par ajustement de faisceaux L’ajustement de faisceaux est une méthode très répandue dans la communauté SLAM. Elle permet d’estimer la pose d’un véhicule compte tenu d’observations faites par les capteurs. La majorité du temps, cette approche repose sur l’utilisation de caméras puisqu’il est nécessaire d’avoir une quantité importante de points à suivre afin d’assurer la bonne estimation de la pose du véhicule. L’idée est simple : des points caractéristiques sont extraits dans l’image et forment la carte. Ils sont ensuite re-projetés dans les images suivantes et des correspondances sont cherchées. Une fois les associations entre les points de la carte et l’image courante trouvées, le but est d’estimer le déplacement ayant affecté le véhicule entre ces images afin de pouvoir minimiser les erreurs de projection des amers (points de la carte) par rapport aux associations trouvées. Les lecteurs intéressés pourront se référer à [Triggs et al. 2000] pour une revue détaillée des méthodes basées sur l’ajustement de faisceaux.22 Chapitre 2. Localisation d’un véhicule L’étape de minimisation globale est effectuée via un algorithme robuste, souvent de type Levenberg-Marquardt [Press et al. 1992]. L’inconvénient majeur des techniques d’ajustement de faisceaux est la lourdeur de cette minimisation. Une organisation hiérarchique des traitements a été proposée par [Hartley & Zisserman 2000] et ensuite appliquée à de la navigation autonome par [Royer et al. 2005] avec d’excellents résultats de localisation (voir figure 2.6). (a) Reconstruction 3D (les points bleus sont ceux cartographiés par l’algorithme) (b) Résultats de localisation (le trait épais est la vérité terrain et le trait fin ce qui est estimé par l’algorithme) Figure 2.6 – Résultats de l’ajustement de faisceaux de [Royer et al. 2005] (approximativement 15 cm d’erreur)2.2. Méthodes de localisation pour le SLAM 23 Malheureusement, la construction de la carte et la localisation dans celle-ci doivent être séparées car trop coûteuses en temps. Nistér et al. [Nistér et al. 2006] se sont tournés vers une estimation de pose différente, faite sur des triplets d’images à chaque fois. L’algorithme repose sur la sélection de la meilleure solution de localisation via RANSAC [Fischler & Bolles 1981]. Néanmoins, bien que temps réel (autour de 13 Hz), l’approche fournie des résultats de localisation moins précis que [Royer et al. 2005], les erreurs s’accumulant au fil de la trajectoire. Enfin, Mouragon et al. ont proposé un algorithme d’ajustement de faisceaux local [Mouragnon et al. 2006] permettant une localisation temps réel autour de 7,5 Hz avec de très bons résultats. Ces méthodes de minimisation globale sont donc tout à fait adaptées à la localisation temps réel. Néanmoins, 8000 points 3D ainsi que 240 images clefs doivent être conservés pour l’étape de localisation et ce pour une trajectoire d’environ 200 mètres. Cela constitue une importante masse de données. De plus, au moins 400 points doivent être associés par image pour que l’étape de minimisation se déroule bien. Cela signifie que l’environnement doit être suffisamment texturé pour pouvoir extraire assez de points caractéristiques et les reconnaître. En- fin, les incertitudes associées aux amers ainsi qu’à la pose du véhicule ne sont pas directement disponibles et doivent être calculées. 2.2.2 Filtrage Les techniques de filtrage sont souvent opposées à celles d’ajustement de faisceaux. Les filtres ont longtemps été considérés comme meilleurs puisque plus facilement utilisables dans des applications temps réel. La sous-section précédente a montré que ce n’est maintenant plus vrai, des améliorations ayant permis d’accélérer les temps de calcul des approches par minimisation globale. Une grande partie de la communauté SLAM a d’ailleurs migré vers celles-ci. Néanmoins, les filtres sont toujours employés, certains cas étant encore propices à leur utilisation. La suite de cette sous-section va détailler les plus populaires dans le cadre du SLAM. 2.2.2.1 Filtre de Kalman Le filtre de Kalman est l’estimateur le plus populaire encore à ce jour [Kalman 1960]. Celui-ci permet, à partir de mesures bruitées, d’estimer l’état d’un système comme par exemple la pose d’un véhicule ou la position d’amers (points de la carte). Le filtre de Kalman fournit, conjointement à l’estimation de l’état, l’incertitude de celui-ci sous la forme d’une matrice de variance-covariance. Il s’agit d’un estimateur récursif markovien d’ordre 1. Ainsi, uniquement l’état précédent du filtre et les nouvelles mesures sont nécessaires pour produire une nouvelle estimation de celui-ci. Le filtre de Kalman suppose néanmoins que toutes les mesures soient décorrélées et suivent une distribution gaussienne ce qui n’est pas forcément toujours le cas. Sa notoriété est également liée au fait qu’il est optimal dans le cas de fonctions linéaires et qu’il est très peu coûteux. Son fonctionnement se découpe en 2 étapes : la prédiction et la mise à jour.24 Chapitre 2. Localisation d’un véhicule La phase de prédiction se charge de faire évoluer l’état depuis l’instant précédent jusqu’à l’instant courant. Les observations fournies par les capteurs viennent ensuite corriger l’état prédit : il s’agit de l’étape de mise à jour. À chaque fois, les incertitudes associées aux mesures, ainsi que celles affectant les différentes variables du vecteur d’état, sont prises en compte dans les calculs. Dans le cadre de la robotique mobile, la phase de prédiction consiste généralement à faire évoluer le véhicule suivant un modèle physique de celui-ci en fonction des données odométriques acquises. Pour l’étape de mise à jour, il s’agit d’observer les amers précédemment cartographiés. La différence entre ce qui est attendu et ce qui est observé va ainsi pouvoir corriger l’état prédit. Ces 2 étapes sont généralement formalisées comme suit. L’estimation de l’état du système représentée par 2 variables : xk|k qui est l’estimation de l’état à l’instant k considérant toutes les observations jusqu’à l’instant k, et Pk|k qui est la matrice de covariance (incertitude) associée à l’état xk|k . Soit Fk la forme matricielle du modèle linéaire d’évolution de l’état et uk les commandes effectuées par le robot entre k − 1 et k, l’étape de prédiction est alors : xk|k−1 = Fkxk−1|k−1 + Bkuk (2.1) où Bk est le modèle liant les commandes reçues à l’état (cela est surtout valable dans un contexte de robotique mobile). La prédiction de la matrice de covariance se fait comme suit : Pk|k−1 = FkPk−1|k−1F T k + Qk (2.2) où Qk est le bruit du processus d’évolution. Enfin, pour la mise à jour, soit zk la variable regroupant les observations faites à l’instant k et Hk la forme matricielle du modèle d’observation liant zk à l’état. On peut ainsi calculer l’innovation associée à la mise à jour de Kalman : Δk = zk − Hkxk|k−1 (2.3) Le gain de Kalman est ensuite donné par : Kk = Pk|k−1HT k (HkPk|k−1HT k + Rk) −1 (2.4) où Rk est l’incertitude associée aux observations zk. Une fois le gain de Kalman obtenu, la mise à jour peut être calculée et l’état (tout comme l’incertitude) corrigé : xk|k = xk|k−1 + KkΔk (2.5) Pk|k = Pk|k−1 − KkHkPk|k−1 (2.6) L’application du filtre de Kalman au SLAM propose d’excellentes propriétés en terme de convergence des données [Dissanayake et al. 2000][Dissanayake et al. 2001]. Malheureusement, sous cette2.2. Méthodes de localisation pour le SLAM 25 forme, ce filtre est rarement employé puisqu’il requiert des modèles linéaires ce qui est rarement le cas dans des applications de robotique mobile. Ainsi, une formulation adaptée aux systèmes non linéaires a été élaborée. 2.2.2.2 Filtre de Kalman étendu Présenté dans [Kalman & Bucy 1961], le filtre de Kalman étendu ou EKF (Extended Kalman Filter) a pour but d’estimer l’état de systèmes régis par des modèles non linéaires. Son fonctionnement est très similaire au filtre de Kalman classique si ce n’est qu’une étape de linéarisation est nécessaire. Celle-ci est faite autour du point de fonctionnement, à savoir l’estimée courante. Pour la prédiction, la linéarisation du modèle d’évolution sera faite autour de xk−1|k−1 . Pour l’étape de mise à jour, la linéarisation sera accomplie autour de xk|k−1 . Dans les 2 cas, ces phases de linéarisation correspondent au développement de Taylor d’ordre 1, à savoir le calcul des matrices jacobiennes (matrices aux dérivées partielles) associées aux modèles. Plus de détails concernant l’EKF dans le cadre du SLAM seront donnés en section 2.3. L’optimalité de l’EKF a été démontrée dès lors que la linéarisation se fait autour de la vraie valeur du vecteur d’état. Dans les faits, il s’agit de ce que l’on veut estimer et cette valeur n’est pas disponible. Plus l’estimée sera correcte, plus l’étape de linéarisation sera juste. En revanche, l’éloignement de la vraie valeur peut causer des problèmes d’inconsistance : la vérité ne serait alors plus comprise dans l’incertitude associée à l’estimation. Dans le cadre d’un SLAM, la divergence du vecteur d’état peut être conséquente [Julier & Uhlmann 2001b][Bar-Shalom et al. 2001]. Néanmoins, beaucoup d’approches se basent tout de même sur l’EKF. En effet, les estimées sont souvent suffisamment proches de la vérité pour éviter ces problèmes. On peut par exemple citer l’approche de Leonard et al. dans [Leonard & Feder 2000] qui utilise avec succès un EKF SLAM dans de grands environnements. L’utilisation d’un EKF pour le SLAM est souvent associée à l’emploi de capteurs de profondeur. Par exemple, dans [Guivant et al. 2000], un télémètre laser est utilisé. Cette approche a ensuite été étendue dans [Guivant & Nebot 2001] pour couvrir de grandes distances. Toujours avec des capteurs de distance, nous pouvons citer l’approche de [Newman & Leonard 2003] où un sonar permet une application sousmarine de l’EKF SLAM. Ces résultats suivent des travaux précédemment entrepris sur l’exploration, toujours par filtre de Kalman étendu [Newman et al. 2002]. Enfin, d’autres approches, couplant laser et vision avec un EKF, ont été expérimentées [Newman et al. 2006]. Bien que moins populaires, les processus utilisant une unique caméra pour l’EKF SLAM ont tout de même été largement étudiés [Davison 2003][Clemente et al. 2007]. Concernant les performances de l’EKF, celles-ci sont liées au nombre d’amers qui sont dans le vecteur d’état. Dans le cas de figure où la taille de la carte ne fait que croître (pas de suppression des anciens amers), cette charge ne fait qu’augmenter. En effet, la taille du vecteur d’état et de la matrice de covariance associée ont un gros impact sur le temps de calcul de la mise à jour. Il a été montré dans [Malartre 2011]26 Chapitre 2. Localisation d’un véhicule que traiter les observations une par une (c’est-à-dire que chaque observation entraîne une mise à jour) concède un gain de temps considérable. À l’inverse, prendre en compte toutes les observations d’un coup rend la mise à jour du filtre plus longue mais moins sensible aux fausses associations. Dans le premier cas (mise à jour itérative), si une observation est mauvaise, elle pourrait faire complètement diverger le filtre, empêchant ainsi le processus d’estimation de se dérouler correctement. Dans le second cas, celle-ci serait lissée et pondérée par le reste des observations qui tireront la mise à jour de l’état dans une autre direction. Ces quelques remarques sont valables pour l’ensemble des techniques de filtrage présenté ici. Afin de conserver une mise à jour à temps presque constant, il est toujours possible de supprimer des amers dès lors qu’ils ne sont plus visibles. Le SLAM s’apparente dès lors davantage à de l’odométrie visuelle. En fonction des applications (pas de boucle dans la trajectoire par exemple), cela peut s’avérer intéressant. De plus, il est toujours possible d’extraire les amers qui ne sont plus visibles pour les stocker en dehors du vecteur d’état et ainsi alléger la charge calculatoire. Dans tous les cas, il a été constaté que les filtres de Kalman ne requièrent que peu d’amers pour atteindre une bonne précision [Strasdat et al. 2010a]. Bien sûr, cela est à nuancer en fonction de la qualité des capteurs et donc des amers. À titre d’exemple, nous pouvons citer [Féraud 2011] qui présente des résultats de localisation par EKF en se basant sur une carte de référence préalablement construite. Il s’agit du même contexte que dans [Royer et al. 2005]. Les résultats sont exposés sur la figure 2.7. On peut constater que la précision atteinte est similaire à celle obtenue par Royer et al. dans [Royer et al. 2005]. Néanmoins, ici pour une trajectoire d’environ 170 mètres, uniquement 319 amers ont été cartographiés. Il est également possible de réduire le temps des mises à jour sans avoir à supprimer d’amers. Il faut pour cela utiliser les méthodes de sous-cartes (submapping). Le principe est assez simple : à chaque fois qu’une carte devient trop lourde à compléter (d’autres critères sont également possibles), celle-ci est fermée et une nouvelle entièrement vide est ouverte. Une carte de plus haut niveau garde les liens entre les sous-cartes afin de ne pas perdre d’information. En plus d’alléger les temps de traitement, cela permet aussi de diminuer les erreurs de linéarisation de l’EKF. En effet, dans une nouvelle sous-carte, toutes les informations précédentes sont oubliées ce qui permet d’avoir une incertitude nulle au départ de celle-ci. En revanche, les erreurs de linéarisation perdurent dans la carte haut niveau. Parmi les premières approches basées sous-cartes apparues, nous pouvons citer [Williams et al. 2002a] et le Constrained Relative Submap Filter où les sous-cartes sont décorrélées les unes des autres. Néanmoins, la structure de plus haut niveau en arbre rend l’intégration de fermetures de boucle (second passage à un endroit déjà exploré) difficile. Les approches de Leonard et al. dans [Leonard & Newman 2003] pour le SLAM à temps constant et de Bailey dans [Bailey 2002] avec les Network Coupled Features Maps sont assez similaires. Les amers communs entre les souscartes sont utilisés afin de garder les informations disponibles quand il y a une transition dans les sous-cartes. Malheureusement, ces approches ne prennent pas en compte le fait que les données soient corrélées créant ainsi des problèmes d’in-2.2. Méthodes de localisation pour le SLAM 27 (a) Reconstruction et trajectoire (les croix rouges sont les amers cartographiés par l’algorithme) (b) Résultats de localisation (le trait bleu est la vérité terrain et le trait rouge ce qui est estimé par l’algorithme) Figure 2.7 – Résultats de l’EKF de [Féraud 2011] (moins de 8 cm d’erreur) consistance. Dans l’approche Atlas décrite dans [Bosse et al. 2003], un graphe est utilisé comme carte de haut niveau. Les noeuds représentent la position globale des sous-cartes et les arêtes, les transformations de l’une vers l’autre. La cohérence de l’ensemble est malheureusement sacrifiée puisque les mises à jour globales ne sont faites qu’avec un processus hors-ligne. Estrada et al. proposent une approche similaire [Estrada et al. 2005] où deux cartes globales sont maintenues : une intégrant les informations corrigeant l’emplacement des sous-cartes et l’autre non. Les corrections ne sont néanmoins pas appliquées aux sous-cartes rendant ainsi impossible de28 Chapitre 2. Localisation d’un véhicule se servir de ces informations dans la navigation locale. La représentation est également sous-optimale puisqu’un même amer peut être dans plusieurs sous-cartes. Une utilisation de sous-cartes conditionnellement indépendantes est proposée dans [Piniés & Tardós 2008]. Celle-ci permet de conserver les informations d’une souscarte à l’autre et ainsi d’éviter de démarrer en perdant l’a priori disponible. Cela force cependant à faire attention aux données à marginaliser pour éviter de devenir inconsistant. L’approche décrite dans [Paz et al. 2008] propose de reconstituer la carte globale sans approximation. Pour ce faire, l’algorithme joint les sous-cartes deux à deux jusqu’à ce qu’il n’y ait plus qu’une carte globale. Le coût de la jointure est ainsi en partie lissé même si les dernières fusions restent coûteuses. Enfin, quelques séparations légèrement différentes ont été proposées. Dans [Blanco et al. 2009], les sous-cartes sont créées en fonction des amers qui sont observables simultanément. Le problème majeur est qu’uniquement les capteurs fournissant immédiatement la distance des amers sont utilisables. Enfin, un critère similaire pour trier les souscartes a été présenté dans [Chli & Davison 2009]. Celui-ci groupe ensemble les amers ayant de fortes corrélations. Cela n’empêche pas néanmoins les sous-cartes de ne pas intégrer toutes les corrections disponibles dans la carte haut niveau. L’utilisation des sous-cartes pose d’autres problèmes que ceux évoqués ci-dessus. En effet, chaque sous-carte est construite avec un facteur d’échelle différent puisque les informations menant d’une sous-carte à une autre ne sont pas utilisées lors de leur construction. Les traitements hors-ligne, souvent obligatoires pour obtenir une carte optimale, sont aussi un point qui nuit à l’emploi de ces méthodes. Cependant, cela reste un bon moyen pour qu’un EKF SLAM cartographie de très longues distances. Hormis le temps de calcul, il est toujours intéressant de regarder l’empreinte mémoire laissée par un algorithme. Dans le cas de l’EKF (et de ses dérivées), elle est faible car peu d’amers sont nécessaires pour couvrir de grandes distances. Néanmoins, pour atteindre une bonne précision de localisation, il faut veiller à avoir une bonne répartition des amers dans la carte (des points proches et éloignés) [Paz et al. 2008]. Dans les résultats présentés en figure 2.7, 319 points ont été utilisés pour une trajectoire de 170 mètres. Uniquement 20 points devaient être observables par image. Ces chiffres traduisent bien, dans ce cas précis, une faible occupation mémoire pour le filtre de Kalman étendu. 2.2.2.3 Filtre de Kalman sans parfum Le filtre de Kalman sans parfum, ou Unscented Kalman Filter (UKF), a été introduit dès 1997 [Julier & Uhlmann 1997]. Son objectif est de compenser les faibles performances de l’EKF dans le cadre de systèmes hautement non linéaires. L’idée principale est d’éviter le calcul des jacobiennes qui tend à rendre les estimées inconsistantes. Pour cela, une méthode d’échantillonnage est introduite. Celle-ci sélectionne un nombre minimum de particules (appelées points sigma) qui sont ensuite pondérées autour de l’espérance via une fonction de vraisemblance. Ces points sigma passent ensuite par les fonctions non linéaires. Il est alors possible de ré-estimer l’état du système ainsi que sa covariance. Les différentes particules sont ré-échantillonnées2.2. Méthodes de localisation pour le SLAM 29 au fur et à mesure afin d’affiner les résultats. Les UKF sont plus précis que les EKF puisque l’étape de linéarisation est évitée. Néanmoins, un important temps de calcul est requis par cette méthode, la rendant ainsi difficilement transposable à des applications réelles. L’UKF est donc logiquement très peu utilisé pour le SLAM. Les principaux travaux remontant au début des années 2000 [Wan & Merwe 2000][Julier & Uhlmann 2004]. Une application temps réel de l’UKF à un contexte monoculaire a tout de même été démontrée dans [Checklov et al. 2006]. 2.2.2.4 Filtre d’information Le filtre d’information [Maybeck 1982] est également souvent appelé la forme inverse du filtre de Kalman. En effet, sa particularité est de définir la matrice d’information comme étant l’inverse de la matrice de covariance : Yk|k = P −1 k|k (2.7) Cela se traduit comme suit pour la définition du vecteur d’information : yk|k = P −1 k|k xk|k (2.8) L’avantage de cette représentation est visible lors de l’étape de mise à jour. Cette dernière devient en effet additive et à l’intérêt de ne pas être dépendante de l’ordre dans lequel les observations sont intégrées [Liu & Thrun 2003]. Les mesures ainsi que les covariances associées sont exprimées sous forme linéaire de la façon suivante : ik = HT k R−1 k zk (2.9) Ik = HT k R−1 k Hk (2.10) La mise à jour s’écrit alors comme ceci : yk|k = yk|k−1 + ik (2.11) Yk|k = Yk|k−1 + Ik (2.12) Il est également possible de rendre la matrice d’information plus éparse en cassant les liens faibles entre les données [Thrun et al. 2004]. L’avantage majeur est que la mise à jour s’effectue alors quasiment en temps constant [Eustice et al. 2005]. Cependant, uniquement quelques approches utilisent ce filtre dans le cadre du SLAM monovéhicule [Mahon et al. 2008][Walter et al. 2007][Gutmann et al. 2010]. Cela est principalement dû au fait qu’il est nécessaire de convertir chaque mesure, tout comme l’état, sous cette forme inverse. Cette étape peut être coûteuse car elle fait intervenir une inversion de matrice de complexité cubique.30 Chapitre 2. Localisation d’un véhicule 2.2.2.5 Filtre particulaire Les filtres particulaires ou Particle Filters (PF) sont souvent utilisés quand l’état du système que l’on cherche à estimer ne suit pas une distribution gaussienne ou quand le caractère gaussien est cassé par la non linéarité des fonctions. Son principe est simple : l’état est échantillonné en un ensemble de particules suivant sa densité de probabilité. Ensuite, à l’instar du filtre de Kalman, une étape de prédiction est accomplie. Celle-ci applique à chaque particule le modèle d’évolution. De même, une phase de mise à jour suit. Dans celle-ci les particules sont pondérées suivant leur vraisemblance par rapport aux mesures. Les particules les plus probables sont conservées. Les autres sont éliminées et de nouvelles particules sont générées [Dellaert et al. 1999]. Cependant, l’application directe de cette méthode au SLAM est délicate. Cela nécessiterait d’avoir un ensemble de particules par amer de la carte, ce qui est, d’un point de vue calculatoire, extrêmement coûteux. Généralement, des hybrides EKF et PF sont utilisés pour le SLAM. L’algorithme le plus connu est le FastSLAM [Montemerlo et al. 2002] qui a lui-même été influencé par [Murphy 1999] et [Thrun et al. 2000]. Dans celui-ci, la carte est estimée via un EKF pendant que la localisation suit une approche particulaire. La qualité des résultats dépend fortement du nombre de particules utilisées. Ce choix est difficile à quantifier et une augmentation trop conséquente du nombre de particules pose le problème de la complexité calculatoire. Néanmoins, l’algorithme de FastSLAM a pu être appliqué en temps réel à un contexte monoculaire sur de petites distances (intérieur d’un bureau) dans [Eade & Drummond 2006]. Malgré le fait qu’il puisse représenter des distributions non gaussiennes, le FastSLAM souffre aussi d’inconsistance à long terme [Bailey et al. 2006b]. Pour éviter ce problème, cet algorithme a été combiné à un filtre d’information dans [Mohan & Madhava 2010]. Le problème majeur porte alors sur les complexités des deux méthodes qui se cumulent. 2.2.3 Bilan des méthodes de localisation L’aperçu donné sur les méthodes de localisation dans le cadre d’un SLAM local permet de dresser un bilan et de faire un choix en ayant connaissance des forces et faiblesses de chacune. Les plus intéressantes, du point de vue du temps de calcul, semblent être l’ajustement de faisceaux et le filtre de Kalman étendu. Cet aspect est très important puisqu’une utilisation multivéhicule va forcément entraîner un surcoût calculatoire. Un comparatif entre ces 2 approches a été dressé dans [Strasdat et al. 2010a] puis étendu dans [Strasdat et al. 2012] dans le cadre de l’utilisation de caméras. Il en ressort que les ajustements de faisceaux semblent plus précis que les EKF. Il est tout de même précisé qu’avec peu de ressources, il est plus intéressant de s’orienter vers un EKF puisqu’une minimisation globale est vite lourde. Un des problèmes de l’EKF reste l’augmentation constante du vecteur d’état mais des méthodes (citées2.3. SLAM pour l’EKF dans un contexte de robotique mobile 31 en 2.2.2.2) peuvent éviter cela. Un point important est le fait que l’EKF soit plus à même de traiter les données hautement incertaines ce qui est souvent le cas en utilisant une seule caméra (la profondeur des points étant plus qu’approximative lors des premières observations). La revue de l’état de l’art faite dans cette section semble confirmer la tendance évoquée dans ces articles. La quantité d’informations utilisée dans l’ajustement de faisceaux indique que ces approches sont difficiles à adapter à un contexte multivé- hicule. De son côté, l’EKF ne requiert que peu de points ce qui le désigne davantage pour des applications impliquant plusieurs véhicules. Pour privilégier l’économie des ressources (processeur et mémoire), nous nous sommes naturellement tournés vers l’utilisation d’un filtre de Kalman étendu. L’emploi de sa version itérative nous permet en plus d’accomplir les mises à jour plus rapidement même s’il faudra être prudent sur la phase d’association des données. Au delà du temps de calcul et de la consommation mémoire, l’EKF fournit un accès immédiat à la covariance, ce qui est justement important pour l’association de données. Enfin, il offre la possibilité de fusionner d’autres capteurs très facilement. Cela permet de garder notre solution évolutive si d’aventure il s’avérait que l’on souhaitait ajouter un GPS par exemple. La méthode de localisation ainsi que les capteurs étant décidés, la section suivante va maintenant présenter l’utilisation que nous allons faire de l’ensemble en décrivant les différents modèles utilisés. 2.3 SLAM pour l’EKF dans un contexte de robotique mobile Avant de débuter la description des modèles utilisés, nous allons en premier lieu présenter le SLAM dans le cadre de l’utilisation d’un EKF. Pour ce faire, nous allons nous appuyer sur l’exemple présenté en figure 2.8. Considérons l’initialisation d’un processus SLAM. Il convient tout d’abord de définir la position du véhicule en fonction d’un repère qui sera ensuite utilisé pour la navigation. Habituellement, et en l’absence d’informations absolues, le véhicule est très souvent initialisé à la position (0, 0) d’un repère situé sur le point de dé- part de la trajectoire (figure 2.8(a)). En suivant son modèle d’évolution, qui peut être basé ou non sur des informations odométriques, la position du véhicule après déplacement est estimée. Le modèle ainsi que les données issues des capteurs étant imprécises, une incertitude sera affectée à la position via sa matrice de covariance. C’est l’étape de prédiction. Lors de celle-ci, l’incertitude associée à la position du véhicule augmente obligatoirement. La matrice de covariance se traduit graphiquement par une ellipse (quadrique en 3D) dans laquelle la vraie position du véhicule est située (figure 2.8(b)). Puisque le véhicule vient seulement de commencer à bouger, il ne dispose pas encore d’une carte par rapport à laquelle il peut se localiser : il doit alors la construire. Pour cela, des points caractéristiques de l’environnement sont sélectionnés grâce à32 Chapitre 2. Localisation d’un véhicule (a) Initialisation du véhicule (en gris) (b) Déplacement du véhicule (incertitude en rouge) (c) Création d’un amer et de son incertitude (losange gris) (d) Nouveau déplacement du véhicule (e) Observation avec son incertitude (verte) du point de la carte (f) Mise à jour via l’observation et amélioration des positions et incertitudes (bleues) Figure 2.8 – Présentation d’un SLAM dans le contexte de l’EKF la caméra (ou tout autre capteur extéroceptif). Ils servent de base pour initialiser des amers complets qui seront ensuite intégrés dans la carte. Chaque amer construit prend en compte l’incertitude associée au véhicule au moment de l’initialisation ainsi que l’incertitude quant à la mesure faite par la caméra. Cela permet d’obtenir un point statique de l’environnement avec sa propre incertitude (figure 2.8(c)). Une2.3. SLAM pour l’EKF dans un contexte de robotique mobile 33 fois la cartographie faite, le véhicule continue de se déplacer. L’intégration de son déplacement fait gonfler son incertitude. En revanche, l’amer n’est pas affecté car il est statique et ne dépend donc pas de la position du véhicule (figure 2.8(d)). Maintenant qu’une carte est constituée (avec un seul amer), celle-ci va être utilisée afin d’améliorer la position du véhicule. Il y a deux façons de faire : la première consiste à utiliser le même détecteur de points caractéristiques que précédemment et d’essayer de trouver des correspondances avec la carte. Il est aussi possible de projeter les points de la carte dans l’espace capteur et de trouver une association à proximité. C’est généralement cette seconde méthode qui est employée. Ici, afin de faciliter la compréhension via les schémas, la première est illustrée. Un nouvel amer est construit avec sa propre incertitude (voir figure 2.8(e)). Grâce à un processus d’association de données, l’algorithme est capable de déterminer que ce nouvel amer correspond bien à celui déjà présent dans sa carte. Ce nouvel amer est alors considéré comme une observation de celui de la carte. Le modèle utilisé pour observer les points de la carte permet ensuite de calculer la mise à jour adéquate. L’utilisation du filtre de Kalman fait que non seulement l’amer sera précisé mais également la position du véhicule (figure 2.8(f)). Ce processus se répète ainsi jusqu’à la fin de la trajectoire. La suite de cette section va détailler chaque étape en donnant les équations des différents modèles. La première sous-section traitera de la prédiction. Puis, la sous-section 2.3.2 exposera l’étape de mise à jour ainsi que le modèle d’observation utilisé. Enfin, la sous-section 2.3.3 détaillera les différents points sur lesquels l’aspect monoculaire de l’algorithme a une forte influence. 2.3.1 Prédiction Soit vk la pose du véhicule à l’instant k. Le contexte de vision nous permet de la définir suivant 6 degrés de liberté, à savoir la position 3D et les 3 angles associés : vk = ⎛ ⎜⎜⎜⎜⎜⎜⎜⎝ xk yk zk Ψk Φk Θk ⎞ ⎟⎟⎟⎟⎟⎟⎟⎠ (2.13) où  xk yk zk est la position 3D du véhicule et  Ψk Φk Θk sont respectivement les angles de roulis, tangage et lacet. Ces paramètres nous permettent de passer du repère monde ℜm au repère vé- hicule ℜv et inversement. En l’absence de référence absolue, le (0, 0, 0) du repère monde sera fixé sur le début de la trajectoire. La figure 2.9 montre l’orientation de ces 2 repères. Dans cette figure, tvm est la translation, issue de la position du véhicule  xk yk zk , permettant de passer du repère monde au repère véhicule (ou inversement). De manière similaire, Rvm est la rotation, calculée à partir des34 Chapitre 2. Localisation d’un véhicule angles Ψk, Φk et Θk, qui complète le passage de ℜm à ℜv (ou encore une fois dans l’autre sens). Figure 2.9 – Représentation des repères monde et véhicule et passage de l’un à l’autre Dans le cadre du filtre de Kalman étendu, la prédiction de l’état du véhicule vk 1|k 1 de covariance Pvk 1|k 1 s’exprime comme suit : vk|k 1 = f(vk 1|k 1 , uk) (2.14) Pvk|k 1 = Fvk 1|k 1Pvk 1|k 1F T vk 1|k 1 + FukQkF T uk (2.15) où f est une fonction non linéaire, Fvk 1|k 1 est la jacobienne de f suivant vk 1|k 1 et Fuk la jacobienne de f suivant le vecteur de commande uk affecté du bruit Qk . Compte tenu du fait que le capteur odométrique nous fournit une distance de déplacement ds entre les instants k 1 et k et l’angle volant δ entre les mêmes instants, nous pouvons définir le vecteur de commande uk comme indiqué ci-après : uk = ds δ (2.16) La fonction non linéaire f se traduit par un modèle d’évolution prenant en compte l’état du véhicule vk 1|k 1 et les données odométriques uk.2.3. SLAM pour l’EKF dans un contexte de robotique mobile 35 Il s’agit d’un modèle bicyclette simplifié qui s’exprime de la manière suivante : ⎧ ⎪⎪⎪⎪⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎪⎪⎪⎪⎩ xk|k−1 = xk−1|k−1 + ds cos(Θk−1|k−1 + δ) yk|k−1 = yk−1|k−1 + ds sin(Θk−1|k−1 + δ) zk|k−1 = zk−1|k−1 + ds sin(Φk−1|k−1 ) Ψk|k−1 = Ψk−1|k−1 Φk|k−1 = Φk−1|k−1 Θk|k−1 = Θk−1|k−1 + ds sin(δ) L (2.17) où L est l’entre-axe du véhicule. La jacobienne Fvk−1|k−1 peut ensuite être calculée : Fvk−1|k−1 = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1000 0 −ds sin(Θk−1|k−1 + δ) 0100 0 ds cos(Θk−1|k−1 + δ) 0010 ds cos(Φk−1|k−1 ) 0 0001 0 0 0000 1 0 0000 0 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ (2.18) Il en va de même pour Fuk : Fuk = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ cos(Θk−1|k−1 + δ) −ds sin(Θk−1|k−1 + δ) sin(Θk−1|k−1 + δ) ds cos(Θk−1|k−1 + δ) sin(Φk−1|k−1 ) 0 0 0 0 0 sin(δ) L ds cos(δ) L ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ (2.19) La matrice Qk est généralement définie expérimentalement en fonction de la qualité des données odométriques. Cette phase de prédiction n’est pas obligatoirement suivie par une étape de mise à jour. En effet, les capteurs fonctionnent à des fréquences différentes et il est courant que l’odomètre soit plus rapide que la caméra. Bien évidemment, rien n’empêche de faire plusieurs prédictions avant de faire une mise à jour. Seulement, il n’y a aucune garantie de l’ordre d’arrivée des mesures. Ainsi, dès qu’une image arrive, l’état du véhicule est extrapolé jusqu’à la date de l’image avec un modèle qui n’est pas basé sur l’odométrie (modèle à vitesse constante, etc.). Les états issus de l’odométrie et de la caméra sont ensuite fusionnés dès qu’une nouvelle donnée proprioceptive est disponible. Ce comportement est exposé dans la figure 2.10 au travers d’un exemple. Les lecteurs intéressés pourront se tourner vers [Tessier et al. 2006] pour plus de détails sur la gestion des données désynchronisées.36 Chapitre 2. Localisation d’un véhicule Figure 2.10 – Gestion des deux états en fonction des données fournies par les capteurs Sur la figure 2.10, on peut voir qu’une donnée odométrique est reçue à la date t1. Celle-ci permet, à l’aide du modèle du robot d’obtenir l’état t1. Une image arrive à une date t2 ultérieure à t1. Il est donc nécessaire d’extrapoler l’état t1 jusqu’à la date t2 afin de pouvoir prendre en compte cette information. Pour ce faire, un modèle à vitesse constante est utilisé, ce qui génère l’état t2. La réception d’une nouvelle donnée odométrique à t3 va créer l’état prédit t3 parallèlement à t2. Ceux-ci sont ensuite fusionnés pour obtenir l’état t3 qui intègre toutes les informations reçues jusqu’à la date t3. 2.3.2 Mise à jour La gestion des mises à jour est un peu plus compliquée puisqu’elle fait intervenir la carte. Les observations se faisant dans le repère image, il convient de bien définir les différents changements de repère qui peuvent intervenir. En plus des repères monde et véhicule préalablement définis, le repère caméra ℜc ainsi que le plan image ℜi doivent être pris en considération pour pouvoir passer d’amers 3D dans le monde à un point 2D dans le plan image. Le passage de ℜv à ℜc est similaire à celui défini pour aller de ℜm à ℜv. Une translation tcv ainsi qu’une rotation Rcv sont nécessaires à sa réalisation. Les 6 paramètres de ce changement de repère sont donnés par les paramètres extrinsèques de la caméra qui correspondent à la mesure de la position de la caméra par rapport au repère véhicule. Considérons un point 3D pm exprimé dans le repère monde. Son équivalent pc dans ℜc peut être calculé de la façon suivante : pc = RT cv(RT vm(pm tvm) tcv) (2.20) Rvm et tvm sont calculés à partir de l’état du véhicule vk comme suit : tvm = ⎡ ⎣ xk yk zk ⎤ ⎦ (2.21)2.3. SLAM pour l’EKF dans un contexte de robotique mobile 37 Rvm = Rz(Θk)Ry(Φk)Rx(Ψk) = ⎡ ⎣ cos(Θk) − sin(Θk) 0 sin(Θk) cos(Θk) 0 0 01 ⎤ ⎦ ⎡ ⎣ cos(Φk) 0 sin(Φk) 0 10 − sin(Φk 0 cos(Φk) ⎤ ⎦ ⎡ ⎣ 10 0 0 cos(Ψk) − sin(Ψk) 0 sin(Ψk) cos(Ψk) ⎤ ⎦ (2.22) Le calcul est similaire pour Rcv et tcv mais à partir des paramètres extrinsèques mesurés. Le passage de ℜc à ℜi est différent puisqu’il fait passer d’un point 3D à son équivalent 2D dans l’image. Pour effectuer cette opération, un modèle de la caméra est nécessaire. Le modèle sténopé est généralement utilisé de par sa simplicité. Celui-ci ne nécessite que quelques paramètres concernant la caméra qui peuvent être déterminés par un calibrage. Il s’agit des paramètres intrinsèques de la caméra. Ils peuvent être organisés sous forme matricielle afin de faciliter le changement de repère : F = ⎡ ⎣ cu fu 0 cv 0 fv 100 ⎤ ⎦ (2.23) où  cu cv est le point principal de l’image (projection du centre optique) et  fu fv correspond à la distance focale suivant les 2 axes. Le modèle sténopé nous donne ainsi la projection d’un point  xyz T dans l’image : ⎡ ⎣ su sv s ⎤ ⎦ = F ⎡ ⎣ x y z ⎤ ⎦ (2.24) Cela nous donne le point  u v T dans l’image : ⎧ ⎪⎪⎪⎨ ⎪⎪⎪⎩ u = cux + fuy x v = cvx + fvz x (2.25) Nous pouvons maintenant compléter la figure 2.9 avec les nouveaux repères. Le résultat est visible en figure 2.11. Les étapes présentées ici sont utilisées afin de projeter un point de la carte depuis le repère monde vers le repère image. Il s’agit de l’étape de prédiction des observations. Comme nous nous sommes placés dans le cadre d’un EKF itératif, nous définissions h comme la fonction non linéaire permettant de projeter un amer aik−1 depuis le repère monde dans le plan image. Il est ainsi possible de définir une observation zk comme étant le point de l’image correspondant à la prédiction de aik−1 dans ℜi . Ainsi, du point de vue de l’EKF, le calcul de l’innovation se traduit de la façon suivante : Δk = zk − h(vk|k−1 , aik−1 ) (2.26)38 Chapitre 2. Localisation d’un véhicule Figure 2.11 – Représentation des repères caméra et image et passage de l’un à l’autre La fonction h correspond en fait à l’enchaînement des équations (2.20) et (2.25) pour l’amer aik 1 défini dans le repère ℜm. Elle se traduit par le système suivant : ⎧ ⎪⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎪⎩ uik 1 = F1RT cv(RT vm(pm tvm) tcv) F3RT cv(RT vm(pm tvm) tcv) vik 1 = F2RT cv(RT vm(pm tvm) tcv) F3RT cv(RT vm(pm tvm) tcv) (2.27) où Fi représente la i ème ligne de la matrice de paramètres intrinsèques F. Nous pouvons maintenant calculer le gain de Kalman de manière similaire à l’équation (2.4). Ici, Rk caractérise le bruit dans l’image (matrice de taille 2 × 2) et Hk représente le calcul de la jacobienne de h suivant l’état xk|k 1 qui est ici limité à la pose du véhicule vk|k 1 et l’amer qui est couramment traité aik 1 . Cela signifie que le reste des amers de la carte n’intervient pas dans h et par conséquent : ∂h(vk|k 1 , aik 1 ) ∂aj=ik 1 = 0 (2.28) Ainsi, la jacobienne Hk sera nulle, hormis sur les lignes correspondant à la pose du véhicule et à l’amer observé. Pour une carte comportant n amers numérotés de 0 à n 1, Hk est de la forme suivante : Hk =  ∂h ∂vk|k 1 02×3i ∂h ∂aik 1 02×3n 3 3i  (2.29) Classification d’images et localisation d’objets par des m´ethodes de type noyau de Fisher Ramazan Gokberk Cinbis To cite this version: Ramazan Gokberk Cinbis. Classification d’images et localisation d’objets par des m´ethodes de type noyau de Fisher. Other. Universit´e de Grenoble, 2014. French. . HAL Id: tel-01071581 https://tel.archives-ouvertes.fr/tel-01071581 Submitted on 6 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Mathématiques, Sciences et Technologies de l’Information Arrêté ministériel : 7 août 2006 Présentée par Ramazan Gokberk Cinbis Thèse dirigée par Cordelia Schmid et codirigée par Jakob Verbeek préparée au sein Inria Grenoble et de l’école doctorale MSTII : Mathématiques, Sciences et Technologies de l’Information, Informatique Classification d’images et localisation d’objets par des méthodes de type noyau de Fisher Fisher kernel based models for image classification and object localization Thèse soutenue publiquement le 22 juillet 2014, devant le jury composé de : Dr. Florent Perronnin Xerox Research Centre Europe, Meylan, France, Président Pr. Martial Hebert Carnegie Mellon University, Pittsburgh, PA, USA, Rapporteur Pr. Andrew Zisserman University of Oxford, Oxford, UK, Rapporteur Pr. Deva Ramanan University of California at Irvine, Irvine, CA, USA, Examinateur Dr. Cordelia Schmid Inria Grenoble, Montbonnot, France, Directeur de thèse Dr. Jakob Verbeek Inria Grenoble, Montbonnot, France, Co-Directeur de thèseii The research that lead to this thesis was carried out at the LEAR team of INRIA Grenoble. This work was supported by the QUAERO project (funded by OSEO, French State agency for innovation), the European integrated project AXES and the ERC advanced grant ALLEGRO.Abstract In this dissertation, we propose models and methods targeting image understanding tasks. In particular, we focus on Fisher kernel based approaches for the image classification and object localization problems. We group our studies into the following three main chapters. First, we propose novel image descriptors based on non-i.i.d. image models. Our starting point is the observation that local image regions are implicitly assumed to be identically and independently distributed (i.i.d.) in the bag-of-words (BoW) model. We introduce non-i.i.d. models by treating the parameters of the BoW model as latent variables, which renders all local regions dependent. Using the Fisher kernel framework we encode an image by the gradient of the data loglikelihood with respect to model hyper-parameters. Our representation naturally involves discounting transformations, providing an explanation of why such transformations have proven successful. Using variational inference we extend the basic model to include Gaussian mixtures over local descriptors, and latent topic models to capture the co-occurrence structure of visual words. Second, we present an object detection system based on the high-dimensional Fisher vectors image representation. For computational and storage efficiency, we use a recent segmentation-based method to generate class-independent object detection hypotheses, in combination with data compression techniques. Our main contribution is a method to produce tentative object segmentation masks to suppress background clutter in the features. We show that re-weighting the local image features based on these masks improve object detection performance significantly. Third, we propose a weakly supervised object localization approach. Standard supervised training of object detectors requires bounding box annotations of object instances. This time-consuming annotation process is sidestepped in weakly supervised learning, which requires only binary class labels that indicate the absence/presence of object instances. We follow a multiple-instance learning approach that iteratively trains the detector and infers the object locations. Our main contribution is a multi-fold multiple instance learning procedure, which prevents training from prematurely locking onto erroneous object locations. We show that this procedure is particularly important when high-dimensional representations, such as the Fisher vectors, are used. Finally, in the appendix of the thesis, we present our work on person identification in uncontrolled TV videos. We show that cast-specific distance metrics can be learned without labeling any training examples by utilizing face pairs within tracks and across temporally-overlapping tracks. We show that the obtained metrics improve face-track identification, recognition and clustering performances. iiiiv Keywords Image classification, object detection, weakly supervised training, computer vision, machine learning.Résumé Dans cette thèse, nous proposons des modèles et des méthodes dédiés à des taches de compréhension de l’image. En particulier, nous nous penchons sur des approches de type noyau de Fisher pour la classification d’images et la localisation d’objets. Nos études se répartissent en trois chapitres. En premier lieu, nous proposons de nouveaux descripteurs d’images construits sur des modèles non-iid de l’image. Notre point de départ est l’observation que les régions locales d’une image sont souvent supposées indépendentes et identiquement distribuées (iid) dans les modèles de type sacs-de-mots (SdM). Nous introduisons des modèles non-iid en traitant les paramètres du SdM comme des variables latentes, ce qui rend interdépendantes toutes les régions locales. En utilisant le noyau de Fisher, nous encodons une image par le gradient de sa log-vraisemblance par rapport aux hyperparamètres du modèle. Notre représentation implique naturellement une invariance à certaines transformations, ce qui explique pourquoi de telles approches ont été courronnées de succès. En utilisant l’inférence variationnelle, nous étendons le modèle de base pour inclure un mélange de gaussiennes sur les descripteurs locaux, et un modèle latent de sujets pour capturer la structure co-occurente des mots visuels. Dans un second temps, nous présentons un système de détection d’objet reposant sur la représentation haute-dimension d’images par le vecteur de Fisher. Pour des raisons de complexité en temps et en espace, nous utilisons une méthode récente à base de segmentation pour engendrer des hypothèses de détection indépendantes des classes, ainsi que des techniques de compression. Notre principale contribution est une méthode pour produire des masques de segmentation potentiels, afin de supprimer le bruit du descripteur dû à l’arrière plan. Nous montrons que repondérer les descripteurs locaux de l’image en fonction de ces masques améliore significativement la performance en détection. Troisièmement, nous proposons une approche semi-supervisée pour la localisation d’objets. L’entrainement supervisé usuel de détecteurs d’objets nécessite l’annotation de boites englobantes des instances de ces objets. Ce processus coû- teux est évité en apprentissage semi-supervisé, lequel ne nécessite que des étiquettes binaires indiquant la présence ou l’absence des objets. Nous suivons une approche d’apprentissage à instance multiple en alterne itérativement entre entrainer un détecteur et inférer les positions des objets. Notre contribution principale est une procédure multi-état d’apprentissage à instance multiple, qui évite à l’apprentissage de se focaliser prématurément sur des positions d’objets erronnées. Nous montrons que cette procédure est particulièrement importante lorsque des représentations haute-dimensions comme le vecteur de Fisher sont utilisées. vvi Pour finir, nous présentons dans l’appendice de cette thèse notre travail sur l’identification de personnes dans des vidéos télévision non-contrôlées. Nous montrons qu’une distance adaptée au casting peut être apprise sans étiqueter d’exemple d’apprentissage, mais en utilisant des paires de visages au sein d’un même chemin et sur plusieurs chemins se chevauchant temporellement. Nous montrons que la métrique apprise améliore l’identification de chemins de visages, la reconnaissance et les performances en regroupement. Mots clés Classification d’image, détection d’objet, apprentissage faiblement supervisé, vision par ordinateur, apprentis-sage statistique.Acknowledgments I consider myself extremely lucky to have had the opportunity to work with my advisors Jakob Verbeek and Cordelia Schmid during my PhD. Their kind help and guidance in every bit of the PhD process, from choosing research directions to writing papers, have been invaluable. Jakob and Cordelia are my role models for being a scientist and an advisor. I would like to thank Andrew Zisserman, Martial Hebert, Deva Ramanan, and Florent Perronnin for kindly accepting to evaluate my work. I am grateful for having such an exceptional group of jury members. LEAR team has been a great working environment with its friendly culture. I would like to thank Zaid Harchaoui, Matthijs Douze, Karteek Alahari, and Julien Mairal for the informative and interesting discussions. I would like to also acknowledge the tremendous help by Matthijs while releasing the source code of our object detector. Special thanks to Dan Oneata for being a great roommate (and helping me in a lot of ways!), Adrien Gaidon for being a great officemate, Thomas Mensink for hosting me multiple times as a guest flatmate, and Mattis Paulin for kindly translating the thesis abstract. I would like to thank Albert Gordo, Alessandro Prest, Anoop Cherian, Arnau Ramisa, Danila Potapov, Federico Pierucci, Gaurav Sharma, Guillaume Fortier, Heng Wang, Jerome Revaud, Josip Krapac, Matthieu Guillaumin, Mohamed Ayari, Philippe Weinzaepfel, Piotr Koniusz, Shreyas Saxena, Yang Hua, Zeynep Akata, and many others for their friendship over the years. I would like to thank Nathalie Gillot for her help in administrative tasks and beyond. I am eternally grateful to my family, my parents, and my parents-in-law for their understanding and the sacrifices they have made on behalf of this thesis. This work would simply not have been possible without them. My wife Nazlı and my son Çınar Kagan, who experienced the most my frequent travels away from home ˘ and my constant busyness even when I am at home, have always been hugely supportive. This thesis is dedicated to my dear wife and my dear son. viiContents Abstract iii Résumé v Acknowledgments vii 1 Introduction 1 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Related Work 9 2.1 Image representations . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Patch-based descriptors . . . . . . . . . . . . . . . . . . . 10 2.1.2 Incorporating spatial structure . . . . . . . . . . . . . . . 19 2.1.3 Other recent descriptors . . . . . . . . . . . . . . . . . . 21 2.2 Image classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 Support Vector Machines . . . . . . . . . . . . . . . . . . 26 2.2.3 Kernel functions and descriptor transformations . . . . . . 29 2.3 Object detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.1 Localization strategies . . . . . . . . . . . . . . . . . . . 32 2.3.2 Window descriptors and classifiers . . . . . . . . . . . . . 35 2.3.3 Contextual relationships . . . . . . . . . . . . . . . . . . 37 2.4 Weakly supervised object localization . . . . . . . . . . . . . . . 38 2.4.1 Initialization methods . . . . . . . . . . . . . . . . . . . 39 2.4.2 Iterative learning methods . . . . . . . . . . . . . . . . . 40 3 Image Categorization using Fisher Kernels of Non-iid Image Models 43 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2 Fisher vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3 Non-iid image representations . . . . . . . . . . . . . . . . . . . 49 3.3.1 Bag-of-words and the multivariate Pólya model . . . . . . 49 3.3.2 Modeling descriptors using latent MoG models . . . . . . 51 3.3.3 Capturing co-occurrence with topic models . . . . . . . . 56 3.4 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 57 3.4.1 Experimental setup . . . . . . . . . . . . . . . . . . . . . 58 3.4.2 Evaluating latent BoW and MoG models . . . . . . . . . 58 3.4.3 Evaluating topic model representations . . . . . . . . . . 60 ixx CONTENTS 3.4.4 Relationship between model likelihood and categorization performance . . . . . . . . . . . . . . . . . . . . . . . . 61 3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4 Segmentation Driven Object Detection with Fisher Vectors 65 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Segmentation driven object detection . . . . . . . . . . . . . . . . 68 4.2.1 Segmentation mask generation . . . . . . . . . . . . . . . 68 4.2.2 Feature extraction . . . . . . . . . . . . . . . . . . . . . . 69 4.2.3 Feature compression . . . . . . . . . . . . . . . . . . . . 71 4.2.4 Training the detector . . . . . . . . . . . . . . . . . . . . 72 4.2.5 Contextual rescoring . . . . . . . . . . . . . . . . . . . . 73 4.3 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 74 4.3.1 Parameter evaluation on the development set . . . . . . . 74 4.3.2 Evaluation on the full PASCAL VOC 2007 . . . . . . . . 76 4.3.3 Comparison to existing work . . . . . . . . . . . . . . . . 80 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5 Multi-fold MIL Training for Weakly Supervised Object Localization 87 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Weakly supervised object localization . . . . . . . . . . . . . . . 90 5.2.1 Features and detection window representation . . . . . . . 90 5.2.2 Weakly supervised object detector training . . . . . . . . 91 5.3 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 94 5.3.1 Dataset and evaluation criteria . . . . . . . . . . . . . . . 94 5.3.2 Multi-fold MIL training and context features . . . . . . . 95 5.3.3 Comparison to state-of-the-art WSL detection . . . . . . . 99 5.3.4 Discussion and analysis . . . . . . . . . . . . . . . . . . 102 5.3.5 Training with mixed supervision . . . . . . . . . . . . . . 105 5.3.6 VOC 2010 evaluation . . . . . . . . . . . . . . . . . . . . 106 5.3.7 Application to image classification . . . . . . . . . . . . . 108 5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6 Conclusion 113 6.1 Summary of contributions . . . . . . . . . . . . . . . . . . . . . 113 6.2 Future research perspectives . . . . . . . . . . . . . . . . . . . . 115 A Unsupervised Metric Learning for Face Verification in TV Video 119 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 A.3 Unsupervised face metric learning . . . . . . . . . . . . . . . . . 123CONTENTS xi A.3.1 Face detection, tracking, and features . . . . . . . . . . . 123 A.3.2 Metric learning from face tracks . . . . . . . . . . . . . . 125 A.3.3 Metrics for verification and recognition . . . . . . . . . . 127 A.4 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 128 A.4.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A.4.2 Experimental results . . . . . . . . . . . . . . . . . . . . 128 A.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Publications 137 Bibliography 139List of Figures 1.1 Example images from several datasets. . . . . . . . . . . . . . . . 3 1.2 Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. . . . . . . . . . 5 1.3 Estimated foregroud masks for example images. The masks are used to suppress background clutter for object detection. . . . . . 6 1.4 Examples of the iterative re-localization process for the chair and bottle classes from initialization (left) to the final localization (right). Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . . . . . . . . . . . . 7 3.1 Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. . . . . . . . . . 44 3.2 The score of a linear ‘cow’ classifier will increase similarly from images (a) through (d) due to the increasing number of cow patches. This is undesirable: the score should sharply increase from (a) to (b), and remain stable among (b), (c), and (d). . . . . 46 3.3 Comparison of (left to right) `2, Hellinger, and chi-square distances for x and y values ranging from 0 to 1. Both the Hellinger and chisquare distance discount the effect of small changes in large values unlike the `2 distance. . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4 Graphical representation of the models in Section 3.3.1: (a) multinomial BoW model, (b) Pólya model. The outer plate in (b) refer to images. The index i runs over the N patches in an image, and index k over visual words. Nodes of observed variables are shaded, and those of (hyper-)parameters are marked with a central dot in the node. 50 3.5 Digamma functions ψ(α +n) for various α, and √ n as a function of n; functions have been rescaled to the range [0,1]. . . . . . . . 51 3.6 Graphical representation of the models in Section 3.3.2: (a) MoG model, (b) latent MoG model. The outer plate in (b) refer to images. The index i runs over the N patches in an image, and index k over visual words. Nodes of observed variables are shaded, and those of (hyper-)parameters are marked with a central dot in the node. 52 3.7 Graphical representation of LDA. The outer plate refers to images. The index i runs over patches, and index t over topics. . . . . . . . 56 xiiixiv LIST OF FIGURES 3.8 Comparison of BoW representations: square-root BoW (green) and Pólya latent BoW model (blue), (a) without SPM and (b) with SPM. Relative mAP is defined as the difference between a given mAP score and the mAP score of the corresponding baseline plain BoW representation. . . . . . . . . . . . . . . . . . . . . . . . . 59 3.9 Comparison of MoG representations: square-root MoG (green) and latent MoG (blue), (a) without SPM and (b) with SPM. Relative mAP is defined as the difference between a given mAP score and the mAP score of the corresponding baseline plain MoG representation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.10 Topic models (T = 2, solid) compared with BoW models (dashed): BoW/PLSA (red), square-root BoW/PLSA (green), and Pólya/LDA (blue). SPM included in all experiments. . . . . . . . . . . . . . . 61 3.11 Performance when varying the number of topics: PLSA (red), square-root PLSA (green), and LDA (blue). BoW/Pólya model performance included as the left-most data point on each curve. All experiments use SPM, and K = 1024 visual words. . . . . . . 62 3.12 Evaluation of the model log-likelihood and the classification performance in terms of mAP scores as a function of the number of PCA dimensions (D) and the vocabulary size (K). The x-axis of each plot shows the number of PCA dimensions. Each curve represents a set of (D,K) values such that D×K stays constant. . . . 64 4.1 Illustration of the segmentation-driven process for estimating feature-weighting masks. For each candidate window, we estimate a foreground mask using multiple superpixel segmentations that are originally computed for generating the candidate windows of Uijlings et al. [2013] . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2 Segmentation masks for two correct (top) and two incorrect (bottom) candidate windows. The first four columns show the window, the merged segment that produced that window, our weighted mask, and the masked window. The eight images on the right show the binary masks of superpixels lying fully inside the window, for each of the eight segmentations. . . . . . . . . . . . . . . . . . . 69 4.3 Example images where the top scoring detection improves (top three rows) or degrades (bottom row) with inclusion of the masked window descriptors. Correct detections are shown in yellow, incorrect ones in magenta. See text for details. . . . . . . . . . . . . . 78LIST OF FIGURES xv 5.1 Distribution of the window scores in the positive training images following the fifth iteration of standard MIL training on VOC 2007. The right-most curve in terms of the mean scores correspond to the windows chosen in the latest re-localization step and utilized for training the detector. The curve in the middle correspond to the other windows that overlap more than 50% with the training windows. Similarly, the left-most curve correspond to the windows that overlap less than 50%. Each curve is obtained by averaging all per-class score distributions. Filled regions denote the standard deviation at each point. . . . . . . . . . . . . . . . . . . . . . . . 92 5.2 Distribution of inner products, scaled to the unit interval, of pairs of 50,000 windows sampled from 500 images using our highdimensional FV (top), and a low-dimensional FV (bottom). (a) uses all window pairs and (b) uses only within-image pairs, which are more likely to be similar. . . . . . . . . . . . . . . . . . . . . 93 5.3 Example failure cases on the bird, cat and dog images. Each row shows the re-localization process from initialization (left) to the fi- nal localization (right) and three intermediate iterations using standard MIL or multi-fold MIL. In these cases, whereas standard MIL finds full-object windows, multi-fold training localizes down to sub-regions of the objects. Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . 97 5.4 Correct localization (CorLoc) performance on training images averaged across classes over the MIL iterations starting from the first iteration after initialization. We show results for standard MIL training, and our multi-fold training algorithm. We also show results for both when using the 516 dimensional descriptors. CorLoc of the initial windows is 17.4%. . . . . . . . . . . . . . . . . . . 98 5.5 Correct localization (CorLoc) performance on training images averaged across classes over the MIL iterations starting from the first iteration after initialization. We compare results for standard MIL training using a number of different SVM cost parameters (C) vs. the multi-fold MIL training. We use C = 1000 for multi-fold MIL training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6 Examples of the re-localization process using multi-fold training for images of nine classes from initialization (left) to the final localization (right) and three intermediate iterations. Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . . . . . . . . . . . . . . . . . . . . . . . 100 5.7 AP vs. CorLoc for multi-fold MIL (left), and ratio of WSL over supervised AP as a function of CorLoc (right). . . . . . . . . . . . 104xvi LIST OF FIGURES 5.8 Distribution of localization error types for each class, and averaged across all 20 VOC’07 classes using 10-fold MIL and standard MIL training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.9 Object detection results for training with mixed supervision. Each curve shows the detection AP as a function of the number of fullysupervised training images up to the point where all positive training images are fully-supervised. The first eight plots show per-class curves for the 20 classes and the last one shows the detection AP values averaged over all classes. The mixed supervision results are shown with solid lines and the fully-supervised baseline results are shown with dotted lines using the same color and edge markers as in the corresponding mixed supervised curves . . . . . . . . . . . 107 A.1 An overview of our processing pipeline. (a) A face detector is applied to each video frame. (b) Face tracks are created by associating face detections. (c) Facial points are localized. (d) Locally SIFT appearance descriptors are extracted on the facial features, and concatenated to form the final face descriptor. . . . . . . . . . 123 A.2 Example tracks. Each track is subsampled to 10 frames. . . . . . . 124 A.3 Equal error rate (EER) as a function of the number of training examples when using metrics learned from only supervised tracks (S, cyan) and using semi-supervised learning that also exploits unlabeled tracks to learn the metric (S+U, magenta). The performance of the L2 distance (green) and a metric learned on the LFW set (blue) are also shown for reference. . . . . . . . . . . . . . . . . . 129 A.4 2D projections of all face descriptors in the test set using LDML metrics trained on (a) all images in the LFW dataset, (b) the 227 supervised training tracks, and (c) using unsupervised training on the test tracks. The faces of the different people are color coded. . 130 A.5 Normalized histogram of distances of face pairs sampled from positive (left) and negative (right) track pairs. . . . . . . . . . . . . . 131 A.6 Nearest neighbor classification results. . . . . . . . . . . . . . . . 132 A.7 Multi-class logistic discriminant classification results. . . . . . . . 132 A.8 Evaluation of hierarchical clustering error based on different distance metrics, the true number of characters is eight. . . . . . . . . 134 A.9 Clustering results using an unsupervised metric (top), and a supervised metric (bottom). Each face image corresponds to unique track. The number of incorrect tracks shown (red) are proportional to the cluster purity. Figure is best viewed in color. . . . . . . . . 135List of Tables 3.1 Comparison of BoW representations: plain BoW, square-root BoW and Pólya. The data is the same as in Figure 3.8. . . . . . . . . . . 59 3.2 Comparison of MoG representations: plain MoG, square-root MoG and latent MoG. The data is the same as in Figure 3.9. . . . 60 4.1 The list of window descriptor components. The final descriptor is obtained by concatenating all components. . . . . . . . . . . . . . 71 4.2 Performance on the development set with different descriptors (S: SIFT, C: color), regions (W: window, G: generating segment, M: mask), and with / without SPM. . . . . . . . . . . . . . . . . . . 75 4.3 Performance on VOC’07 with different descriptors (S: SIFT, C: color), regions (W: window, M: mask, F: full image, X: contextual rescoring) using K = 64 Gaussians. . . . . . . . . . . . . . . . . 76 4.4 Performance on VOC’07 with varying number of Gaussians using SIFT local descriptors and window regions only. . . . . . . . . . . 77 4.5 Comparison of our detector using the candidate windows generated by Selective Search (SS) [Uijlings et al. 2013] vs. Randomized Prim (RP) [Manen et al. 2013a]. K = 64 Gaussians are used in the experiments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.6 The abbreviation list for Table 4.7 and Table 4.8. . . . . . . . . . 81 4.7 Comparison of our detector with and without context with the stateof-the-art object detectors on VOC 2007. Each method is shown with an abbreviation, see Table 4.6 for the corresponding citations. 81 4.8 Comparison of our detector with and without context with the stateof-the-art object detectors on VOC 2010. Each method is shown with an abbreviation, see Table 4.6 for the corresponding citations. 83 5.1 Evaluations on the PASCAL VOC 2007 dataset, in terms of correct localization (CorLoc) measure. . . . . . . . . . . . . . . . . . . . 95 5.2 Evaluations on the PASCAL VOC 2007 dataset, in terms of average precision (AP) measure. . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 The abbreviation list for Table 5.4 and Table 5.5. . . . . . . . . . 99 xviixviii LIST OF TABLES 5.4 Comparison of our multi-fold MIL method based on foreground+contrastive descriptors against state-of-the-art weakly-supervised detectors on PASCAL VOC 2007 in terms of correct localization on positive training images (CorLoc). Each method is shown with an abbreviation, see Table 5.3 for the corresponding citations. The results for PL’11 were obtained through personal communication and those for ATH’02 and NTTR’09 are taken from Siva and Xiang [2011]. . 101 5.5 Comparison of weakly-supervised object detectors on PASCAL VOC 2007 in terms of test-set detection AP. Our detector is trained using the proposed multi-fold MIL over foreground+contrastive descriptors. Each method is shown with an abbreviation, see Table 5.3 for the corresponding citations. The results of Prest et al. [2012] are based on external video data for training. The results for PL’11 are taken from Prest et al. [2012]. . . . . . . . . . . . . . . 101 5.6 Performance on VOC 2007 with varying degrees of supervision. All results use window+contrastive descriptor. . . . . . . . . . . . 102 5.7 Comparison of standard MIL training vs our 10-fold MIL on VOC 2010 in terms of training set localization accuracy (CorLoc) using foreground+contrastive descriptors. . . . . . . . . . . . . . . . . 108 5.8 Comparison of standard MIL training vs our 10-fold MIL on VOC 2010 in terms of test set AP using foreground+contrastive descriptors.108 5.9 Image classification results on VOC 2007. RLYF’12 and SPC’12 are the abbreviations for Russakovsky et al. [2012] and Sánchez et al. [2012], respectively. “Cls-by-det” stands for classificationby-detection and “Det-driven” stands for detection-driven. See text for more details. . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.1 Comparison of supervised (S) and semi-supervised (S+U) training using average (avg) and min-min track distances. The EER is shown for several numbers of supervised training tracks. . . . . . 130 A.2 Comparison of labeling cost using different metrics for eight clusters (equals the number of characters). . . . . . . . . . . . . . . . 133CHAPTER 1 Introduction Contents 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 One of the main topics in computer vision research is image understanding, which refers to a set of inter-related tasks. These tasks include, but are not limited to detection of objects, recognition of scenes and inference of the relationships across objects in images. Image understanding tasks have received increasingly wider research interest due to their short-term and long-term importance. In the short-term, these tasks have numerous real-world applications without requiring a complete image understanding system. Some of the most popular applications include content-based querying of web-scale image databases (i.e. image retrieval), autonomous robot navigation in uncontrolled environments, video surveillance for security and safety purposes. In the long-term, these tasks are crucial for building up artificial systems that aim to match the human visual cognitive capabilities. In this dissertation, we focus on two main image understanding tasks. The first one is image categorization, where the problem is to classify images into predefined categories. The second one is object detection, where the the problem is to localize and recognize objects in images. 1.1 Context Modern research on image understanding is considered to have started in 1960s [Andreopoulos and Tsotsos 2013]. The focus of the first studies was mostly character recognition and simple template matching [Hu 1962, Mundy 2006, Roberts 1960]. The Builder project started at MIT in 1965 is probably the earliest project that is aiming to build a comprehensive image understanding system. The main goal of the project was to build a robot for manipulating wooden blocks, and therefore a program to recognize wooden blocks and their poses was necessary [Minsky 2007]. The difficulty of the object recognition problem was 12 CHAPTER 1. INTRODUCTION initially under-estimated and it was planned to complete the perception within a summer. Instead it took several years to implement a working system, and the final architecture ended up being much more complex than what was initially planned. Since 1960s, there has been significant progress in image understanding technology, despite the fact that it is still far from reaching human vision capabilities. Two external factors have been particularly important for the progress made in the past decade. The first important factor is the improvements in the computational resources. As summarized by the Moore’s law, number of transistors on processor chips has been doubling approximately every two years. As a result of this exponential growth, even an average contemporary desktop machine provides computational power that hardly any researcher could have accessed twenty years ago. The second factor is the dramatic increase in the availability of visual content. For example, each minute, tens of thousands of images are uploaded to Flickr and 100 hours of video are uploaded to YouTube according to the statistics released by these websites. Proliferation of the computational resources and the visual content have significantly impacted the computer vision research. In the following paragraphs, we list three outcomes that are of particular interest for this dissertation. The first outcome is the adoption of larger and more realistic datasets by the research community. The UIUC [Agarwal and Roth 2002] and Caltech 101 [FeiFei et al. 2004] datasets are among the first examples of the benchmark datasets developed for image categorization and object detection research. Although these datasets used to be popular testbeds, they are now considered outdated by the community due to the lack of real-world challenges in them [Ponce et al. 2006]. For example, UIUC contains side-view cars with few occlusions (See Figure 1.1a for example images) and Caltech101 contains little background clutter and little object scale variation (See Figure 1.1b). Newer benchmark datasets like PASCAL VOC [Everingham et al. 2010] and ImageNet [Deng et al. 2009] are improved in these respects and they provide a more realistic testbed (See Figure 1.1c and Figure 1.1d). In addition, newer datasets are typically much larger in terms of the dataset scale: While Caltech101 contains ∼5,000 images and one object instance per image, PASCAL VOC 2012 contains ∼20,000 images and 2.7 instances per image and ImageNet 2013 contains ∼500,000 images and 2.8 instances per image. Such large-scale benchmark dataset are now easier to collect thanks to the abundant amount of images and videos available online and now easier to process thanks to the advancements in computational resources. The transition to well-designed benchmark datasets not only allows a more objective comparison of approaches across publications, but also provides more training data for fitting models. This reduces overfitting issues, i.e. allows building models with likely higher performance in uncontrolled environments. However, even the largest benchmark datasets of today still contain dataset-specific biases [Torralba and Efros 2011]. Therefore,1.1. CONTEXT 3 (a) UIUC Car Dataset (b) Caltech101 Dataset (c) PASCAL VOC Dataset (d) ImageNet Dataset Figure 1.1 – Example images from several datasets.4 CHAPTER 1. INTRODUCTION strategies to enable exploitation of larger and more realistic training datasets is an important research direction towards building real-world image understanding systems. The second outcome is the rising importance given to rich object representations. A mainstream idea in early object detection research was to model objects using geometric primitives like generalized cylinders [Binford 1971, Brooks 1981], generalized cones called geons [Biederman 1987] or geometric invariants [Rothwell et al. 1993]. A major problem with these approaches is the fact that localization of geometric primitives has been very unreliable. Therefore, research interest progressively shifted to local and global appearance descriptor-based methods [Mundy 2006], a change pioneered by the works of Murase and Nayar [1993], Schmid and Mohr [1997], Schmid et al. [1996]. This shift is further accelerated as the importance of having rich descriptors is observed on the benchmark datasets and relatively costly feature extraction pipelines become feasible. Today, development of strong representations is continuing to be one of most important research directions. The third outcome is the development of the learning based recognition methods, rather than ad-hoc models that are hand-tuned. Aforementioned works based on geometric primitives mostly used manually tuned object models with few parameters. However, manual optimization is not feasible anymore for the contemporary object models. For example, bag-of-words [Csurka et al. 2004b] and Mixture of Gaussian Fisher vector [Sánchez et al. 2013] descriptors have dimensionalities varying from a few thousand to a few hundred thousand depending on the hyperparameters. Furthermore, recently emerging deep learning-based representations like Krizhevsky et al. [2012] are parameterized by millions of variables. As a result, usage and development of machine learning algorithms is now a central topic in the image understanding research. 1.2 Contributions Despite the significant progress made in the past decade, we are still far from solving the image understanding problems. The following paragraphs explain the problems that we focus on and our corresponding contributions. What are the limitations of the contemporary image representations and how can we improve them? We focus on the bag-of-words (BoW) and mixture of Gaussian Fisher vector representations, which rely on image models that treat an image as an unordered set of local regions. Implicitly, regions are assumed to be identically and independently distributed (iid). However, the iid assumption is a very poor one from a modeling perspective, which we illustrate in Figure 1.2. We1.2. CONTRIBUTIONS 5 Figure 1.2 – Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. introduce a non-iid BoW model by treating the parameters of BoW model as latent variables which are integrated out, rendering all local regions dependent. Using variational inference we extend the basic model to include mixture of Gaussian (MoG) models over local descriptors, and latent topic models to capture the cooccurrence structure of visual words. Using the Fisher kernel we encode an image by the gradient of the data log-likelihood w.r.t. hyper-parameters that control priors on the model parameters. Our representations naturally involves discounting transformations similar to square-rooting and provides an explanation of why such transformations have proven successful for BoW and MoG Fisher vector representations. We obtain state-of-the-art categorization performance using linear classifiers; without using discounting transformations or using (approximate) explicit embeddings of non-linear kernels. This work is published in Cinbis et al. [2012] and presented in Chapter 3. Can we benefit from rich object representations and weak segmentation cues in object detection? State-of-the-art representations for image categorization are much higher dimensional and arguably much richer compared to typically used representations for object detection, like Histogram of Oriented Gradients [Dalal and Triggs 2005]. We present an object detection system based on the Fisher vector image representation computed over SIFT and color descriptors. For computational and storage efficiency, we use a recent selective search method [van de Sande et al. 2011] to generate class-independent object detection hypotheses, in combination with data compression techniques. Our main contribution is a method to produce tentative object segmentation masks to suppress background clutter in the features which are obtained using superpixel-based weak segmentation cues. We provide example segmentation masks in Figure 1.3. Re-weighting the local image features based on these masks is shown to improve object detection performance signif-6 CHAPTER 1. INTRODUCTION Figure 1.3 – Estimated foregroud masks for example images. The masks are used to suppress background clutter for object detection. icantly. We also exploit contextual features in the form of a full-image Fisher vector descriptor, and an inter-category rescoring mechanism. We obtain state-ofthe-art detection results on the PASCAL VOC 2007 and 2010 datasets. This work is published in Cinbis et al. [2013] and presented in Chapter 4. Can we train object detectors using weak supervision towards enabling the use of larger training datasets? Standard supervised training for object detection requires bounding box annotations of object instances. Whereas precise object locations simplify the training process, the time-consuming manual annotation process practically limits the size of the training datasets. Using weakly supervised learning, the necessary supervision for object detector training can be restricted to binary labels that indicate the absence/presence of object instances in the image, without their locations. We follow a multiple-instance learning approach that iteratively trains the detector and infers the object locations in the positive training images. Based on the results we obtain in Chapter 4, we represent detection windows using the powerful Fisher vector representation and restrict the search space using the selective search [van de Sande et al. 2011]. Our main contribution is a multi-fold multiple instance learning procedure, which prevents training from prematurely locking onto erroneous object locations. This procedure is particularly important when high-dimensional representations, such as Fisher vectors, are used. We present a detailed experimental evaluation using the PASCAL VOC 2007 dataset, for which we show example localizations in Figure 1.4. Compared to state-of-the-art weakly supervised detectors, our approach better localizes objects in the training images, which translates into improved detection performance. Finally, we also show that our weakly supervised localization can be used for extracting object-focused image representation, which provides significant gains in image categorization performance. This work is published in Cinbis et al. [2014] and presented in Chapter 5. Finally, we note that Appendix A contains our work on verification of face tracks that are automatically collected from uncontrolled TV video data. The goal of face verification is to decide whether two faces depict the same person or not.1.2. CONTRIBUTIONS 7 Figure 1.4 – Examples of the iterative re-localization process for the chair and bottle classes from initialization (left) to the final localization (right). Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. Face-track verification is an important component in systems that automatically label characters in TV series or movies based on subtitles and/or scripts: it enables effective transfer of the sparse text-based supervision to other faces. We show that, without manually labeling any examples, metric learning can be effectively used to address this problem. This is possible by using pairs of faces within a track as positive examples, while negative training examples can be generated from pairs of face tracks of different people that appear together in a video frame. In this manner we can learn a cast-specific metric, adapted to the people appearing in a particular video, without using any supervision. Verification performance can be further improved using semi-supervised learning where we also include labels for some of the face tracks. We show that our cast-specific metrics not only improve verification, but also recognition and clustering. This study was carried out as part of the thesis research and published in Cinbis et al. [2011]. Since this material is only loosely related to the other contributions, we include it as an appendix. The structure of the thesis is as follows: Before presenting our technical contributions in Chapters 3, 4 and 5, we give an overview of the related work in Chapter 2. We conclude the thesis with a summary and perspectives in Chapter 6.CHAPTER 2 Related Work Contents 2.1 Image representations . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Patch-based descriptors . . . . . . . . . . . . . . . . . . . . 10 2.1.2 Incorporating spatial structure . . . . . . . . . . . . . . . . 19 2.1.3 Other recent descriptors . . . . . . . . . . . . . . . . . . . 21 2.2 Image classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 Support Vector Machines . . . . . . . . . . . . . . . . . . . 26 2.2.3 Kernel functions and descriptor transformations . . . . . . . 29 2.3 Object detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.1 Localization strategies . . . . . . . . . . . . . . . . . . . . 32 2.3.2 Window descriptors and classifiers . . . . . . . . . . . . . . 35 2.3.3 Contextual relationships . . . . . . . . . . . . . . . . . . . 37 2.4 Weakly supervised object localization . . . . . . . . . . . . . . . 38 2.4.1 Initialization methods . . . . . . . . . . . . . . . . . . . . 39 2.4.2 Iterative learning methods . . . . . . . . . . . . . . . . . . 40 In this chapter, we first provide a review of image representations in Section 2.1, which provides an overview of the methods for feature extraction over images and image regions. In Section 2.2, we overview the classification methods for image categorization tasks, where the purpose is to automatically assign a subset of the predefined labels to novel images. In Section 2.3, we overview the object detection approaches, where the task is to learn object localization models based on training images with bounding box annotations. Finally, in Section 2.4, we overview weakly supervised object localization methods, where the task is to learn object localization models using image-level binary object category labels only. In our overview, we focus only on the most relevant approaches for the thesis. A broader overview on image understanding can be found in the recent survey paper by Andreopoulos and Tsotsos [2013]. 910 CHAPTER 2. RELATED WORK 2.1 Image representations In this section, we overview image representation methods. We first overview patch-based descriptors, which are defined over the decomposition of images into a bag of image fragments. Then, we overview approaches for encoding the spatial structure across the image patches, which is typically ignored by the patch-based image descriptors. Finally, we shortly overview several other recent image representations. 2.1.1 Patch-based descriptors Patch-based image descriptors are built upon the notion of the extracting image descriptors by first decomposing an image into small patches. In this section, we first present the bag of words (BoW) descriptor as a concrete example to introduce the fundamentals of the patch-based descriptors. Then, we break down patch-based descriptors into four generic steps and overview the approaches proposed for each one of the four steps. Bag of words (also known as bag of visual words, bag of features or bag of keypoints) has been one of the most popular image representations of the past decade. BoW is originally developed as a text representation [Salton and McGill 1983] where a document is represented by a vector of word counts, i.e. a word histogram. In the works by Sivic and Zisserman [2003] and Csurka et al. [2004a], BoW is adapted to the image domain for image retrieval and image categorization tasks, respectively. The main idea is to obtain visual words by quantizing local descriptors of image patches (i.e. image regions) with respect to a visual vocabulary. In these works, the vocabulary is constructed by clustering a large set of local descriptors using the k-means algorithm [Duda et al. 2001]. Since the introduction of the BoW representation for images, there has been significant interest on improving particular steps of the BoW feature extraction pipeline. In addition, a number of other works proposed image representations – like mixture of Gaussian Fisher Vectors [Sánchez et al. 2013] – that diverge considerably from the original BoW approach, even though they use the local descriptors as the basis of the image descriptors. We can accommodate a great number of such approaches, as well as the BoW variants, within the following generalized feature extraction pipeline: 1. Sample image patches. 2. Extract local descriptors from the image patches. 3. Encode local descriptors. 4. Aggregate the encoded local descriptors to obtain the final image descriptor.2.1. IMAGE REPRESENTATIONS 11 We refer to the image descriptor extraction approaches that can naturally be decomposed into these four steps as the patch-based descriptors. Below we overview the alternatives proposed in the literature for each one of these four steps. Step I: Patch sampling For object recognition tasks, the main responsibility of a patch sampling method is to obtain a representative set of image patches covering the essential information in a given image. There are two mainstream approaches for this purpose. The first one is to use an interest point detector and the second one is the dense sampling of patches on a regular grid at multiple scales. Interest point detectors aim to find a (sparse) set of distinctive regions based on low-level image cues. These algorithms are typically designed in order to find a similar set of locations of a particular object (or scene) from different viewpoints and varying light sources. There are a number of algorithms that are proposed for this purpose, the most important of these include: • Harris-affine detector [Mikolajczyk and Schmid 2004], which adds affine invariance to the Harris corner detector [Harris and Stephens 1988]. • Lowe [2004] proposes to detect interest points by finding local extrema in a Difference of Gaussian pyramid and then suppressing the interest points that have low-contrast or that are on the edges. • Maximally stable extremal regions (MSER) detector [Matas et al. 2004], which finds affine invariant regions by selecting regions that are relatively uniform in illumination and have a distinct appearance from their surroundings. Although interest point algorithms are particularly effective in object instance recognition, where the task is to recognize a particular object instance across different images, dense sampling of the patches have been observed to perform better for object recognition purposes [Nowak et al. 2006]. One possible explanation for this phenomenon is that patches needed for the object recognition task may not be located at interest points. Dense sampling avoids missing important information by sampling uniformly over the whole image. Dense sampling also has disadvantages. One issue is that sampling frequency needs to be high in order to ensure obtaining similar patches across the images. In fact, the categorization accuracy typically increases as the sampling frequency increases [Chatfield et al. 2011, Nowak et al. 2006]. However, increasing the sampling frequency may significant increase the cost feature extraction pipeline. One potential remedy is to use the combination of interest points and densely sampled12 CHAPTER 2. RELATED WORK patches. Another alternative scheme proposed by Tuytelaars [2010] is to find interest points within a dense grid. Step II: Local descriptors In the second step of the feature extraction pipeline, feature vectors, which are called the local descriptors, are extracted at image patches that are sampled in the first step. Just like interest point detectors, most local descriptors are developed for object instance recognition or image matching (i.e. viewpoint invariant point matching) and then some of them are utilized for the image categorization task. SIFT [Lowe 2004] is probably the single most popular local descriptor. The main idea is to use gradient orientation histograms as the local descriptor. More precisely, a SIFT descriptor for a given patch is computed using the following algorithm: 1. Compute gradient orientations and magnitudes at each pixel. 2. Divide the patch into a spatial grid (4×4). 3. Within each spatial cell, compute a gradient orientation histogram, where each pixel is weighted by its gradient magnitude times the weight given by a 2D Gaussian aligned with the patch. 4. Concatenate the per-cell histograms and `2-normalize the descriptor. 5. Truncate values above a threshold (0.2) and `2-normalize again. Probably its most distinctive property is to rely on gradient orientation histograms. While using gradients capture local shape information, histogramming reduces the effect of small spatial shifts. The first `2 normalization step provides invariance to multiplicative and additive illumination changes. Descriptor truncation is designed in order to reduce the effect of non-linear illumination changes, which may undesirably boost the magnitudes of a certain subset of gradients. There are several other popular local descriptors. For example, SURF [Bay et al. 2008] descriptor consists of basic statistics of the vertical and horizontal gradient responses from different sub-regions of a given patch, which is computationally very efficient. DAISY [Winder et al. 2009] can be considered as a variant of the SIFT descriptor, where circular spatial cells are used instead of rectangular spatial cells as in SIFT. Local Self-Similarity (LSS) [Shechtman and Irani 2007] depicts self-similarities within image patches by measuring and storing similarities of the sub-region pairs inside the patches. Aforementioned local descriptors are originally defined over monochrome images. One possible way to include color information is to concatenate features2.1. IMAGE REPRESENTATIONS 13 computed over color channels. For example, OpponentSIFT [van de Sande et al. 2010], which has been shown to be one of the best color-extensions for the SIFT descriptor, is obtained by computing SIFT descriptors within channels of the opponent color space. There are also other approaches that aim primarily to encode color information. For example, the color statistics descriptor proposed by Clinchant et al. [2007] splits each image patch into a 4×4 grid and computes the mean and variance per color channel within each spatial cell. Applying an unsupervised dimension reduction technique on the local descriptors as a preprocessing step can be beneficial. For instance, Principle Component Analysis (PCA) is now widely used [e.g. Chatfield et al. 2011, Farquhar et al. 2005, Sánchez et al. 2013], since not only it speeds up the feature extraction pipeline but also it can improve the encoding quality by decorellating the local descriptor dimensions. PCA can also be interpreted as an efficient approximation to using Mahalanobis distance with a globally estimated covariance matrix over the local descriptors [e.g. Sivic and Zisserman 2009]. Other dimension reduction techniques, like Partial Least Squares [e.g. Farquhar et al. 2005], may also be beneficial. There are a few studies on optimizing local descriptors for a particular task. For example, Philbin et al. [2010] propose discriminative dimension reduction methods for enhancing local descriptors towards improving image retrieval accuracy and Brown et al. [2011] propose a method to automatically tune parameters of a DAISY-like descriptor. A limitation of these approaches is their susceptibility to getting stuck in local optima due to non-convex formulations. Simonyan et al. [2012] instead formulate the spatial pooling region tuning and discriminative dimension reduction as a convex optimization problem. Step III: Encoding Encoding transforms the local descriptors obtained in the second step into a form that is more suitable than the raw local descriptors for constructing an image descriptor. The majority of the encoding methods require a visual vocabulary (also known as dictionary or codebook), which typically provides a reference partitioning of the descriptor space. Previously, we have defined the standard BoW representation [Csurka et al. 2004a, Sivic and Zisserman 2003] as a histogram of visual words. Equivalently, BoW can be defined more formally in terms of an explicit encoding function as follows: Let vq(x) be the vector quantization (VQ, also known as hard assignment) function that maps a given local descriptor x to a unique id in 1,...,K by finding the closest vocabulary center. Then, the BoW encoding of a given x is a binary vector of length K such that its vq(x)-th dimension is 1 and the rest is 0: φ(x) = [1{vq(x)} (k)]k=1:K (2.1)14 CHAPTER 2. RELATED WORK where φ(x) is the encoding function and 1A is the indicator function for any given set A. Then, the summation ∑x φ(x) over all local descriptors is equivalent to the BoW histogram.