A Big Data Platform for Large Scale Event Processing

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