HAL Id: tel-01141766
https://tel.archives-ouvertes.fr/tel-01141766
Submitted on 13 Apr 2015
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished 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ée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
d’acteurs matériels : flot de données pour une
plateforme hétérogène et reconfigurable dynamiquement
Amel Khiar
To cite this version:
Amel Khiar. Virtualisation des communications et déploiement d’acteurs matériels : flot de données pour une plateforme hétérogène et reconfigurable dynamiquement. Traitement du signal et de l’image [eess.SP]. Université de Cergy Pontoise, 2014. Français. �NNT : 2014CERG0716�. �tel-01141766�
Manuscrit de th` ese
Virtualisation des communications et d´ eploiement d’acteurs mat´ eriels flot de donn´ ees pour une plateforme
h´ et´ erog` ene et reconfigurable dynamiquement
Equipes Traitement de l’Information et Syst` emes
Architectures, Syst`emes, Technologies pour les unit´es Reconfigurables Embarqu´ees
KHIAR Amel
le 28 janvier 2015
Rapporteur : Guy Gogniat Rapporteur : Daniel Chillet Examinateur : Samy Meftali Examinateur : Bertrand Granado
Encadrant : Benoˆıt Miramond Directeur : Fran¸cois Verdier
3
A la m´emoire de mon grand-p`ere, que Dieu ait son ˆ` ame, qu’il repose en paix.
5
R´ esum´ e
Les applications embarqu´ees ont besoin de plus en plus de puissance de calcul et doivent ˆetre d´eploy´ees sur des architectures sp´ecifiques pour assurer les contraintes non-fonctionnelles du syst`eme. Ces architectures peuvent ˆetre compos´ees d’unit´es de calcul h´et´erog`enes, comme des processeurs ou des acc´el´erateurs mat´eriels. Cette h´et´erog´en´eit´e rend le d´eploiement d’applications de plus en plus complexe, notam- ment avec l’apparition de circuits reconfigurables dynamiquement. Un des verrous majeurs `a ce d´eploiement r´eside dans la gestion des communications entre les par- ties statiques et dynamiques des applications. Le verrou adress´e dans cette th`ese concerne la gestion des communications entre les blocs fonctionnels de l’applica- tion r´epartis de mani`ere statique en logiciel et de mani`ere dynamique en mat´eriel.
Pour faciliter le d´eploiement des applications existantes et `a venir, notre approche s’appuie sur deux contributions compl´ementaires : une m´ethodologie de conception bas´ee sur le raffinement progressif d’acteurs flot-de-donn´ees, et un middleware dis- tribu´e assurant les communications entre les acteurs une fois ceux-ci d´eploy´es sur la plateforme. Nous avons valid´e ces concepts sur une application dynamique de suivi de cible en traitement d’images. Dans ce contexte, nous nous sommes int´eress´es `a la virtualisation des communications au sein de la plateforme pour faire communiquer les parties mat´erielles et logicielles de l’application de mani`ere transparente. Nos contributions ont permis d’aboutir `a un d´emonstrateur op´erationnel dans le cadre du projet FOSFOR.
Abstract
Applications require more computing power and need to be implemented on spe- cific architectures to ensure the non-functioning constraints of the system. These architectures can be composed of heterogeneous processing units, such as processors or hardware accelerators. This heterogeneity makes the deployment of applications on such architectures increasingly complex, especially with the emergence of dyna- mically reconfigurable devices. One of the hardest obstacles to this deployment is to manage the communication between the static parts and the dynamic ones of the applications. This thesis deals with the communication management issue between the application functional blocks, ones being statically implemented in software, and the others dynamically in hardware. In order to facilitate the deployment of existing applications and those to come, our approach relies on two complementary contributions : a methodology of conception based on the progressive refinement of data-flow actors, and a distributed middleware ensuring the communication bet- ween the actors deployed on the platform. These concepts have been validated on a dynamic tracking target application relying on image processing. In this context, we were interested in the virtualization of the communication within the platform in order to allow the communications between the software and the hardware parts of the application in a transparent way. Our contributions permits us to achieve an operational demonstrator in the frame of the FOSFOR project.
7
R´ esum´ e long
Les applications embarqu´ees ont besoin de plus en plus de puissance de calcul et doivent ˆetre d´eploy´ees sur des architectures sp´ecifiques pour assurer les contraintes non-fonctionnelles du syst`eme. Ces architectures peuvent ˆetre compos´ees d’unit´es de calcul h´et´erog`enes, comme des processeurs ou des acc´el´erateurs mat´eriels. Cette h´et´erog´en´eit´e rend le d´eploiement d’applications de plus en plus complexe, notam- ment avec l’apparition de circuits reconfigurables dynamiquement. Un des verrous majeurs `a ce d´eploiement r´eside dans la gestion des communications entre les par- ties statiques et dynamiques des applications.
Le verrou adress´e dans cette th`ese concerne la gestion des communications entre les blocs fonctionnels de l’application r´epartis de mani`ere statique en logiciel et de mani`ere dynamique en mat´eriel. Pour faciliter le d´eploiement des applications exis- tantes et `a venir, notre approche s’appuie sur deux contributions compl´ementaires : une m´ethodologie de conception bas´e sur le raffinement progressif d’acteurs flot-de- donn´ees, et un middleware distribu´e assurant les communications entre les acteurs une fois ceux-ci d´eploy´es sur la plateforme.
Premi`erement, pour assurer un mod`ele de programmation homog`ene nous avons automatis´e l’impl´ementation d’une partie des composants logiciels et mat´eriels de l’application depuis sa sp´ecification initiale. Pour cela, la m´ethode part d’un mod`ele d’entr´ee d´ecrit en UML et g´en`ere les codes cibles pour notre plateforme apr`es plusieurs ´etapes de transformation. Cette approche assure une coh´erence entre le mod`ele de calcul avec lequel sont exprim´ees les applications `a haut-niveau et le mod`ele d’ex´ecution support´e par l’architecture. Cette coh´erence apporte ´egalement une interface de programmation homog`ene pour les diff´erentes unit´es de calcul.
Deuxi`emement, la reconfiguration dynamique des acteurs mat´eriels et leurs com- munications sont g´er´ees en-ligne par le couplage r´ealis´e entre la couche du syst`eme d’exploitation et notre middleware mat´eriel.
Nous avons valid´e ces concepts sur une application dynamique de suivi de cible en traitement d’images. Dans ce contexte, nous nous sommes int´eress´es `a la vir- tualisation des communications au sein de la plateforme, ceci en mettant en place des canaux de communications, dits virtuels, permettant de faire communiquer les parties mat´erielles et logicielles de l’application de mani`ere transparente. Nos contributions ont permis d’aboutir `a un d´emonstrateur op´erationnel dans le cadre du projet FOSFOR.
9
Remerciements
Je voudrais tout d’abord remercier mes directeurs de th`ese, Fran¸cois VERDIER et Benoit MIRAMOND dont les conseils et les remarques m’ont ´et´e utiles pour mener `a bien ce projet.
Merci ´egalement aux membres du jury qui m’ont fait l’honneur d’´evaluer mon travail, Guy GOGNIAT et Daniel CHILLET qui ont accept´e d’en ˆetre les rappor- teurs, Samy MEFTALI et Bertrand GRANADO qui en ont ´et´e les examinateurs.
Je tiens `a remercier Lounis KESSAL et Mahmoud KARABERNOU pour leur soutien et leur bonne humeur tout au long de ces ann´ees. Je tiens en particulier `a remercier mes coll`egues de bureau, Laurent GANTEL, qui a toujours ´et´e l`a pour m’encourager et avec qui j’ai pass´e d’excellents moments. Je le remercie aussi bien pour son soutien moral que pour son apport scientifique, pour sa disponibilit´e et son amiti´e. Un grand merci `a Liang Zhou, qui est une femme remarquable, m`ere et th´esarde `a la fois. Merci ´egalement `a Lounis Zerioul pour sa pr´esence et ses encou- ragements, Mohemmed HAMIA, Guy WASSI, et Christian GAMON, qui ont aussi
´et´e tr`es pr´esents et qui sont devenus au fil du temps de v´eritables amis.
Une part de ces remerciements va aux membres du projet FOSFOR avec les- quels j’ai travaill´e r´eguli`erement : Fabrice MULLER, Daniel CHILLET, S´ebastien PILLEMENT, Lounis KESSAL et Nicolas KNECHT.
Enfin je souhaite exprimer toute ma gratitude envers mes parents sans lesquels je n’en serais pas l`a aujourd’hui, mon oncle Rachid, ma grand-m`ere MAMIE, mes fr`eres et sœurs, mes amis : Wafa´e, Dahlia, Habiba, Imene, Amina, Youcef et tous mes proches pour leur pr´esence et leur soutien durant toutes ces ann´ees.
Table des mati` eres
1 Introduction 19
1.1 Probl´ematiques et objectifs . . . 19
1.1.1 Probl´ematique . . . 19
1.1.2 La reconfiguration dynamique partielle . . . 19
1.1.3 L’impact de la reconfiguration dynamique . . . 20
1.2 Approche envisag´ee . . . 21
1.2.1 Organisation du document . . . 23
2 Mod`eles et m´ethodologies pour les syst`emes embarqu´es 25 2.1 Introduction. . . 25
2.2 Ing´enierie dirig´ee par les mod`eles . . . 26
2.2.1 Les mod`eles . . . 27
2.2.2 Les m´eta-mod`eles. . . 27
2.3 Apports de l’IDM. . . 29
2.3.1 Le m´eta-mod`ele : grammaire des mod`eles . . . 29
2.3.2 Langage sp´ecifique et g´en´eraliste . . . 31
2.4 Pr´esentation de l’Unified Modeling Language . . . 32
2.4.1 Etat de l’art . . . 32
2.4.2 Diagrammes UML . . . 32
2.4.3 D´efinition de profils UML . . . 35
2.4.4 Marte : un profil pour les syst`emes embarqu´es temps r´eel . . 37
2.4.5 Non Functional Properties Modeling (NFPs) . . . 38
2.4.6 Hardware Resource Model (HRM) . . . 39
2.4.7 Generic Component Modeling (GCM) . . . 40
2.5 Pr´esentation du langage AADL . . . 41
2.6 Confrontation MARTE/AADL . . . 44
2.7 Les b´en´efices de l’IDM et UML . . . 46
2.7.1 Une repr´esentation simplifi´ee . . . 46
2.7.2 Une approche mono-langage . . . 47
2.7.3 Un langage standard . . . 47
2.7.4 Automatisation . . . 47
2.7.5 R´eutilisation des sp´ecifications . . . 47
2.8 Conclusion . . . 49
3 Mod`ele de programmation des architectures h´et´erog`enes 51 3.1 Introduction. . . 51
3.2 Mod`eles de calcul et flot de conception . . . 52
3.2.1 Mod`ele de calcul . . . 52
3.2.2 Les mod`eles de calcul existants . . . 56
3.2.3 Les diff´erents flot de conception envisag´es . . . 61
3.3 Mod`eles de programmation pour le flot de donn´ees reconfigurable . . 68
3.3.1 La d´emarche choisie . . . 68
3.3.2 Mod`ele de tˆache mat´erielle . . . 68
3.3.3 De la tˆache `a l’acteur mat´eriel . . . 72
3.4 Notre flot de conception . . . 73
3.4.1 Mod`ele d’ex´ecution des acteurs . . . 73
3.4.2 Reconfiguration de l’acteur mat´eriel . . . 75
3.4.3 Etats des acteurs reconfigurables . . . 76
3.5 Conclusion . . . 77
4 Intergiciel pour plateforme reconfigurable 79 4.1 Introduction. . . 80
4.2 Projet FOSFOR . . . 80
4.2.1 Le syst`eme d’exploitation RTEMS . . . 81
4.2.2 RTEMS en mode multi-processeur . . . 81
4.2.3 D´efinition de la sous-couche MPCI . . . 82
4.2.4 Le syst`eme d’exploitation mat´eriel . . . 82
4.3 Le middleware comme support de d´eploiement des composants . . . 84
4.3.1 Historique du middleware . . . 84
4.3.2 D´efinition du middleware . . . 85
4.3.3 Adaptation du middleware pour le reconfigurable . . . 85
4.3.4 Etat de l’art sur les middlewares embarqu´es . . . 85
4.3.5 Synth`ese. . . 92
4.4 Sc´enarios de communication entre tˆaches reconfigurables . . . 93
4.4.1 R´ealisation et impl´ementation du middleware . . . 93
4.4.2 Impl´ementation du middleware sur la plateforme . . . 102
4.5 Description de la tˆache mat´erielle . . . 102
4.5.1 Architecture de la tˆache mat´erielle . . . 102
4.5.2 Mode de fonctionnement de la tˆache mat´erielle . . . 104
4.5.3 Parall´elisation du fonctionnement de la tˆache mat´erielle . . . 104
4.5.4 Protocole de communication . . . 106
4.6 Sp´ecificit´e de la tˆache mat´erielle. . . 109
4.6.1 Cas particulier de la primitive “EndCommunication( )” . . . 111
4.7 R´ealisation du middleware mat´eriel . . . 111
4.7.1 Interaction entre le Middleware mat´eriel et l’OS mat´eriel . . 112
4.7.2 Sc´enario d’initialisation . . . 113
4.7.3 Organisation du Middleware mat´eriel . . . 115
4.8 M´ecanismes de synchronisation des middlewares . . . 116
4.8.1 R´esultats . . . 118
4.9 Conclusion . . . 118
Table des mati`eres 13
5 D´eploiement de l’application sur la plateforme 121
5.1 Introduction. . . 121
5.2 D´efinition de l’application-test . . . 122
5.2.1 Partie d´etection. . . 122
5.2.2 Le suivi de cibles : Pistage . . . 123
5.3 D´eploiement sur l’architecture . . . 124
5.3.1 Rappel : Projet FOSFOR . . . 124
5.3.2 Partitionnement de l’application . . . 124
5.4 Mod´elisation de l’applicatif . . . 126
5.4.1 Consid´erations g´en´erales . . . 126
5.4.2 Le profil FOSFOR . . . 127
5.5 Validation du flot de conception sur l’application de tracking . . . . 129
5.5.1 M´eta-mod´elisation . . . 132
5.5.2 Plateforme de transformation du mod`ele SDF vers le mod`ele VHDL . . . 136
5.5.3 G´en´eration du code de l’applicatif . . . 141
5.5.4 Simulation du code g´en´er´e . . . 149
5.6 Conclusion . . . 150
6 Conclusions et travaux futurs 153 6.1 Conclusion . . . 153
6.2 Travaux futurs . . . 155
A M´eta-Mod`ele VHDL 157
Bibliographie 159
Table des figures
1.1 Illustration de la reconfiguration dynamique et partielle . . . 20
1.2 Flot de conception pour les applications de flot de donn´ees reconfi- gurables . . . 23
1.3 Communications `a travers la plate-forme . . . 23
2.1 Exemple d’un syst`eme `a mod´eliser . . . 26
2.2 Mod`ele propos´e pour la carte du syst`eme . . . 27
2.3 Le m´eta-mod`ele auquel sont conformes : le mod`ele et le syst`eme mod´elis´e . . . 28
2.4 Architecture en 4 couches employ´ee par l’IDM. . . 29
2.5 Exemple de m´eta-mod`ele . . . 30
2.6 Exemple de mod`ele utilisant une syntaxe graphique. . . 30
2.7 Exemple de mod`ele utilisant une syntaxe textuelle . . . 31
2.8 Organisation des paquetages du m´eta-mod`ele d’UML. . . 33
2.9 Classification des 13 diagrammes du langage UML . . . 35
2.10 Sp´ecialisation d’UML par le m´ecanisme de profil . . . 35
2.11 Architecture du standard MARTE . . . 38
2.12 Mod`ele g´en´eral de HRM . . . 39
2.13 Mod`ele g´en´eral de GCM . . . 40
2.14 Les diff´erents services propos´es par AADL . . . 42
2.15 D´ecoupage en couches hi´erarchiques et s´eparation des surfaces dans AADL . . . 43
2.16 Principes de la transformation de mod`eles . . . 48
3.1 Mapping entre les diff´erentes couches de plateformes pour le design orient´e plateforme . . . 54
3.2 Mapping entre les diff´erentes couches raffin´ees de plate-formes pour le design orient´e plateforme.[LNW03] . . . 55
3.3 Les approches bas´ees mod`eles et architectures . . . 62
3.4 L’int´egration de la dynamicit´e dans l’environnement GASPARD II . 63 3.5 Flot pour la g´en´eration d’environnement complet d´edi´e aux proto- types `a base d’unit´es reconfigurables . . . 64
3.6 Description globale de l’outil Madeo . . . 66
3.7 Flot de g´en´eration du design Physique . . . 67
3.8 Mod`ele de thread mat´eriel : Hybrid Thread [AA09] . . . 69
3.9 Mod`ele de thread mat´eriel : ReconOS [LP08] . . . 70
3.10 Communications `a travers la plate-forme . . . 73
3.11 Lorsque la r´eception d’un jeton requis est termin´ee, l’´etat de synchro- nisation d´eclenche l’action d´ecrite par le comportement de chaque acteur qui est directement contrˆol´e par une FSM g´en´er´ee `a partir du mod`ele SDF. Dans cet exemple, les jetons d’entr´ee A et B d´eclenchent
deux actions diff´erentes. . . 74
3.12 Le flot de transformation de mod`ele d’UML vers VHDL . . . 76
3.13 Acteurs logiciels et mat´eriels . . . 77
4.1 Architecture de la plateforme FOSFOR . . . 81
4.2 Impl´ementation de RTEMS, et de sa couche MPCI (Tir´ee du projet ANR FOSFOR [fos12]). . . 82
4.3 Repr´esentation de l’OS mat´eriel. . . 83
4.4 Aper¸cu du framework du syst`eme DNA OS [GP09] . . . 86
4.5 MPSoC logiciel . . . 87
4.6 Vue globale du reconfigurable OS pour les RSoCs [GRPR09]. . . 88
4.7 Architecture BORPH [SB06] . . . 89
4.8 Interface de la tˆache mat´erielle [AA09] . . . 90
4.9 Une vue physique de l’architecture supportant Redsharc [KSS+12] . 92 4.10 Structure en couches de l’architecture FOSFOR . . . 94
4.11 Communication Asynchrone au sein de la plateforme FOSFOR . . . 96
4.12 Communication Synchrone au sein de la plateforme FOSFOR . . . . 96
4.13 Communication Synchrone avec Timeout au sein de la plateforme FOSFOR . . . 97
4.14 Repr´esentation de la table des canaux virtuels. . . 98
4.15 R´epartition des tables de tˆaches et de canaux sur la plateforme . . . 99
4.16 L’organigramme de la primitive OpenVirtualChannel . . . 100
4.17 L’organigramme de la primitive VirtualChannelSend . . . 101
4.18 L’organigramme de la primitive VirtualChannelReceive . . . 102
4.19 L’organigramme de la primitive CloseVirtualChannel . . . 103
4.20 Architecture de la tˆache mat´erielle . . . 104
4.21 Le pipeline logiciel . . . 105
4.22 Le module de synchronisation . . . 106
4.23 Diagramme de s´equence pour les communications Synchrones . . . . 107
4.24 Communication synchrone entre tˆaches materielles . . . 107
4.25 Communication asynchrone entre tˆaches mat´erielles . . . 108
4.26 Diagramme de s´equence pour les communications Asynchrones . . . 109
4.27 Les connexions de la tˆache mat´erielle au Hardware Middleware . . . 110
4.28 L’organigramme correspondant `a la primitive EndCommunication . 112 4.29 Principe du middleware mat´eriel . . . 113
4.30 Architecture du middleware mat´eriel . . . 114
4.31 Sc´enario d’initialisation . . . 114
4.32 Organisation du middleware materiel . . . 115
4.33 Synchronisation des instances de middlewares gˆace aux services de leurs OS respectifs . . . 117
Table des figures 17
5.1 L’application de Pistage . . . 123
5.2 Vue fonctionnelle de la plate-forme de d´emonstration . . . 124
5.3 Mapping des diff´erentes tˆaches sur FOSFOR. . . 125
5.4 L’image d’une sc`ene apr`es incrustation . . . 126
5.5 Diagramme de classe de l’application de tracking . . . 128
5.6 Le profil Fosfor pour la mod´elisation des composants de l’application de tracking . . . 128
5.7 Cr´eation du diagramme ECORE . . . 130
5.8 Machine `a ´etats de la tˆache de Pistage . . . 131
5.9 Machine `a ´etats de la tˆache D´etection . . . 131
5.10 Specification du mapping . . . 132
5.11 New Ecore Diagram . . . 133
5.12 Cr´eation du diagramme Ecore . . . 134
5.13 Le diagramme Ecore du m´eta-mod`ele VHDL . . . 134
5.14 Le diagramme Ecore du m´eta-mod`ele SDF. . . 135
5.15 Cr´eation du Model Generator . . . 135
5.16 Cr´eation des plugins associ´es aux m´eta-mod`eles (exemple m´eta-mod`ele VHDL) . . . 136
5.17 Cr´eation d’un projet QVT . . . 137
5.18 Exemple d’entr´ee du moteur de tranformation SDF2VHDL . . . 140
5.19 Exemple du fichier de sortie apr`es la tranformation SDF2VHDL . . 141
5.20 Le principe de fonctionnement de l’outil Acceleo . . . 142
5.21 Cr´eation d’un nouveau projet de g´en´eration . . . 143
5.22 Cr´eation du template de g´en´eration `a partir de l’objet architecture . 143 5.23 Template de g´en´eration cr´e´e par Acceleo . . . 144
5.24 D´eclaration des d´ependances entre le module d’entr´ee : VHDL mm et le module de g´en´eration, d´ecrit dans le template de g´en´eration . . 147
5.25 D´etermination de l’objet racine, de g´en´eration, grˆace aux marqueurs de g´en´eration . . . 148
5.26 Design utilis´e pour la simulation . . . 150
5.27 D´ebut de la simulation . . . 151
5.28 Fin de la simulation - convergence . . . 151
A.1 Le diagramme Ecore du m´eta-mod`ele VHDL . . . 157
——————————–
Chapitre 1
Introduction
Contents
1.1 Probl´ematiques et objectifs . . . . 19
1.1.1 Probl´ematique . . . . 19
1.1.2 La reconfiguration dynamique partielle. . . . 19
1.1.3 L’impact de la reconfiguration dynamique . . . . 20
1.2 Approche envisag´ee . . . . 21
1.2.1 Organisation du document . . . . 23
1.1 Probl´ ematiques et objectifs
1.1.1 Probl´ematique
La complexit´e des calculs et des traitements support´es par les syst`emes em- barqu´es obligent les architectes `a concevoir des plateformes contenant des compo- sants h´et´erog`enes pour r´epondre aux besoins de l’application. Ces besoins peuvent concerner les contraintes temps r´eel, de m´emoire, ou d’impl´ementation (logicielle ou mat´erielle). Mais, en raison de cette h´et´erog´en´eit´e, il est aussi n´ecessaire de mettre en place des m´ecanismes de communication entre les diff´erents composants du syst`eme. Notre objectif dans cette th`ese, est donc d’abstraire du point de vue du d´eveloppeur de l’applicatif, `a la fois l’h´et´erog´en´eit´e et la multiplicit´e de ces unit´es de calculs. Comme nous l’expliquerons en d´etail dans le corps de ce document, cette abstraction n’est pas un probl`eme qui ne concerne que les couches basses du syst`eme, mais qui au contraire n´ecessitent de la prendre en compte et de la formali- ser d`es les premi`eres phases de la conception, de mani`ere `a garantir cette abstraction de bout en bout. L’approche propos´ee dans cette th`ese consiste alors `a adopter un flot de conception haut niveau qui permette de d´eployer des applications sur ces architectures h´et´erog`enes. Une contrainte suppl´ementaire r´esidera dans le fait que ce flot devra aussi prendre en compte la reconfiguration dynamique partielle des circuits modernes, qui permet d’augmenter l’efficacit´e d’utilisation de ces circuits.
1.1.2 La reconfiguration dynamique partielle
La reconfiguration est une propri´et´e/caract´eristique offerte par les circuits pro- grammables, ´egalement appel´es FPGA pour Field Programmable Gate Array. Elle
consiste `a changer la programmation de ces circuits logiques programmables alors qu’ils sont en activit´e. `A l’origine, ces circuits logiques programmables ont ´et´e con¸cus pour permettre de r´ealiser tr`es rapidement des fonctions logiques plus ou moins complexes, c’est-`a-dire directement op´er´ees par un circuit ´electronique. Pour cela, le FPGA permet de d´efinir et de red´efinir `a volont´e une configuration arbitraire de chemins entre des portes logiques ´el´ementaires. N´eanmoins, la red´efinition d’un cir- cuit logique au sein du FPGA est une op´eration singuli`ere, suppos´ee peu fr´equente, et r´ealis´ee alors que le syst`eme informatique au sein duquel il prend place est≪hors- fonction ≫.
Figure 1.1 – Illustration de la reconfiguration dynamique et partielle De nouveaux d´eveloppements de cette technologie ont permis d’envisager la configuration et la reconfiguration de circuits logiques programmables sans en in- terrompre le fonctionnement comme illustr´e dans la figure 1.1. Dans Reconfigu- rable System, on reconfigure totalement le FPGA via le port de configuration ex- terne ; dans Partially Reconfigurable system, on reconfigure seulement une partie du FPGA, toujours en utilisant le port de reconfiguration externe ; et enfin dans le Dynamically Reconfigurable System, le syst`eme est autonome car on effectue la reconfiguration d’une partie du FPGA en utilisant son port de reconfiguration in- terne sans interrompre le fonctionnement du reste du circuit. Cette approche ouvre de nouvelles perspectives dans la r´eduction de la taille et de la consommation des FPGAs tout en offrant de nouvelles opportunit´es `a leur exploitation.
1.1.3 L’impact de la reconfiguration dynamique
La reconfiguration dynamique permet d’augmenter l’efficacit´e d’un FPGA en allouant ses ressources logiques `a plusieurs tˆaches. Ainsi, en utilisant la notion de m´emoire virtuelle qui permet entre autres d’ex´ecuter un programme de taille plus
1.2. Approche envisag´ee 21 grande que la m´emoire physique disponible, un FPGA reconfigurable dynamique- ment peut offrir une quantit´e importante de ressources logiques virtuelles et les mapper au moment de l’ex´ecution sur une quantit´e r´eduite de ressources physi- quement disponible. Un autre avantage qui suscite un int´erˆet croissant chez les chercheurs, est la flexibilit´e introduite par la reconfiguration dynamique des FPGA qui se manifeste `a deux niveaux.
Le premier niveau permet au concepteur, de facilement adapter son application pour faire face `a de nouvelles contraintes ou pour remplacer un algorithme par un autre plus efficace. Cette flexibilit´e assure une certaine ´evolution du syst`eme.
Le second niveau correspond au choix des tˆaches `a ex´ecuter, qui peut se faire dynamiquement, par exemple en fonction des donn´ees `a traiter. Nous pouvons donc tout `a fait imaginer que les donn´ees d’entr´ee puissent influer en temps r´eel sur l’enchaˆınement des algorithmes. Le mat´eriel devient extrˆemement mall´eable et contrˆolable par logiciel, il peut ˆetre utilis´e `a des instants diff´erents pour ex´ecuter des op´erations diff´erentes. Th´eoriquement, la reconfiguration dynamique n’est pas r´eserv´ee `a une cat´egorie particuli`ere de FPGA. Cependant, certains sont plus adapt´es que d’autres pour satisfaire les contraintes temps r´eel. Le FPGA id´eal pour construire un syst`eme reconfigurable dynamiquement doit poss´eder une vitesse d’ex´ecution
´elev´ee et une dur´ee de reconfiguration tr`es faible. Malheureusement, les FPGAs com- mercialis´es `a l’heure actuelle ne r´eunissent que partiellement ces deux caract´eristiques.
Cependant, un FPGA offrant une seule des deux caract´eristiques sans que la deuxi`eme ne soit excessivement p´enalisante, peut ˆetre utilis´e efficacement pour construire un syst`eme dynamique. La dur´ee de reconfiguration a aussi un impact sur les perfor- mances d’un syst`eme dynamique, particuli`erement si la modification de la fonction- nalit´e intervient fr´equemment.
Le probl`eme de l’abstraction des communications qui nous int´eresse r´ev`ele alors une nouvelle facette. Au del`a du probl`eme spatial, introduit par l’h´et´erog´en´eit´e des composants du MPSoC, le probl`eme devient ´egalement temporel, puisque ces composants peuvent ˆetre allou´es et lib´er´es `a la vol´ee.
1.2 Approche envisag´ ee
Afin de faciliter la programmabilit´e des SoCs, nous avons d´ecid´e premi`erement de nous baser sur un flot de conception haut niveau reposant sur l’ing´enierie dirig´ee par les mod`eles. Un tel flot de conception permettrait tout d’abord de simplifier le d´eveloppement d’applications par les ing´enieurs logiciels et mat´eriels en conservant la mˆeme s´emantique des composants manipul´es de la description de l’application
`
a tr`es haut niveau, jusqu’`a son impl´ementation au niveau mat´eriel. Il permettrait
´egalement d’automatiser le d´eploiement de ces applications sur des plateformes h´et´erog`enes.
Deuxi`emement, nous proposons d’unifier les interfaces des composants h´et´erog`enes
du syst`eme afin de pouvoir abstraire les communications sur la plateforme. Cette abstraction peut ˆetre mise en place `a l’aide d’une couche suppl´ementaire appel´ee Middleware en dessous de l’application et qui offre des primitives communes `a tous les composants du syst`eme.
Nous d´ecrivons l’application de traitement d’images cibl´ee en prenant en compte les possibilit´es d’ordonnancement offertes par la reconfiguration dynamique par- tielle. A partir de l`a, le flot de conception propos´e doit pouvoir automatiser la g´en´eration du cycle de fonctionnement de chacune des tˆaches mat´erielles et logi- cielle.
Nous proposons de r´eduire l’´ecart entre la sp´ecification initiale du syst`eme et la mise en œuvre finale lorsqu’il s’agit d’architectures reconfigurables dynamiquement.
L’id´ee principale est de garder la s´emantique des composants manipul´es depuis le niveau ´elev´e et d’affiner le mod`ele jusqu’au niveau du mat´eriel. Le concept, qui existe d´ej`a dans le domaine purement logiciel avec des approches middleware, est ici ´etendu pour consid´erer ´egalement les composants mat´eriels.
Ainsi, la gestion des architectures reconfigurables ne se limite pas `a une solution technique sp´ecifique mais est plutˆot consid´er´ee comme un tout `a partir du haut (niveau mod´elisation) vers le bas (niveau impl´ementation). Une couche d’abstrac- tion sp´ecifique est d´evelopp´ee (middleware mat´eriel et logiciel) en s’appuyant sur la s´emantique utilis´ee par les composants de haut niveau.
Cette couche permet de cartographier les interactions de haut niveau entre les acteurs d’une application sp´ecifique sur une plate-forme abstraite.
Comme l’illustre laFig.1.2, nous consid´erons, `a haut niveau, la vision coh´erente et inter-op´erable d’acteurs capables de communiquer. Cette abstraction des commu- nications facilite le nombre de raffinements possibles dans la couche d’abstraction sous-jacente (Programmes) du flot de conception.
Pour atteindre cet objectif, la s´emantique des composants g´er´es est bas´ee sur le mod`ele de calculMoC d´ecrivant des flots de donn´ees synchrones(SDF Synchronous Data-Flow) [LM87b]. La description des acteurs est faite `a partir du langage gra- phique standard UML1et leurs interfaces sont d´ecrites en utilisant IDL32[CCM06].
Au plus haut niveau, nous repr´esentons chaque bloc de l’application qui effec- tue une tˆache sp´ecifique par un acteur, qui re¸coit et envoie les donn´ees par le biais de canaux virtuels. Ces acteurs partagent la mˆeme API fournie par la plate-forme virtuelle globale. Ils seront affin´es en acteurs logiciels et mat´eriels, en fonction des exigences de performance, de la complexit´e algorithmique et du comportement dy- namique. Les acteurs logiciels sont cod´es en tant que threads logiciels ; les acteurs mat´eriels comme de nouvelles structures appel´ees threads mat´eriels. A ce stade, les threads logiciels et mat´eriels partagent encore la mˆeme API.
1. Unified Modeling Language 2. Interface Description Langage
1.2. Approche envisag´ee 23
!
Figure1.2 – Flot de conception pour les applications de flot de donn´ees reconfigu- rables
Figure 1.3 – Communications `a travers la plate-forme
1.2.1 Organisation du document
Ce document est organis´e en quatre grandes parties. Dans la premi`ere intitul´ee Mod`eles et m´ethodologies pour les syst`emes embarqu´es, nous nous int´eressons aux diff´erentes techniques offertes par les technologies de l’Ing´enierie Dirig´ee par les Mod`eles, en mettant en valeur l’int´erˆet qu’elles peuvent avoir dans le cadre de la conception des syst`emes sur puces en g´en´eral et celui de la reconfiguration dyna- mique et partielle en particulier.
Dans la partie suivanteMod`ele de programmation des architectures h´et´erog`enes, nous nous focalisons sur les initiatives portant sur l’utilisation d’UML et de l’IDM pour l’analyse et la d´efinition d’un flot de conception visant `a les utiliser au mieux ; et la d´efinition d’un mod`ele de programmation des architectures h´et´erog`enes pou- vant ˆetre reconfigur´ees.
Ensuite dans le chapitreIntergiciel pour plateforme reconfigurable, nous sp´ecifions et nous impl´ementons une couche d’abstraction, qui vise `a virtualiser les communi- cation dans une plateforme h´et´erog`ene et reconfigurable.
Enfin, la partie D´eploiement de l’application sur la plateforme dans laquelle nous proposons une impl´ementation cherchant `a valider l’int´erˆet de notre approche, celle-ci consiste en la mise en oeuvre de la sp´ecification du flot de conception d´efini pr´ec´edemment et la g´en´eration de code automatique qui en d´ecoule pour la gestion de la partie mat´erielle et reconfigurable de la platefome.
Dans la derni`ere partie de ce document, nous concluons en rappelant les points essentiels de notre contribution, en discutant des points `a compl´eter, et en proposant des ouvertures pour des travaux futurs.
Chapitre 2
Mod` eles et m´ ethodologies pour les syst` emes embarqu´ es
Contents
2.1 Introduction . . . . 25 2.2 Ing´enierie dirig´ee par les mod`eles. . . . 26 2.2.1 Les mod`eles . . . . 27 2.2.2 Les m´eta-mod`eles. . . . 27 2.3 Apports de l’IDM . . . . 29 2.3.1 Le m´eta-mod`ele : grammaire des mod`eles . . . . 29 2.3.2 Langage sp´ecifique et g´en´eraliste . . . . 31 2.4 Pr´esentation de l’Unified Modeling Language . . . . 32 2.4.1 Etat de l’art . . . . 32 2.4.2 Diagrammes UML . . . . 32 2.4.3 D´efinition de profils UML . . . . 35 2.4.4 Marte : un profil pour les syst`emes embarqu´es temps r´eel . . 37 2.4.5 Non Functional Properties Modeling (NFPs) . . . . 38 2.4.6 Hardware Resource Model (HRM) . . . . 39 2.4.7 Generic Component Modeling (GCM) . . . . 40 2.5 Pr´esentation du langage AADL . . . . 41 2.6 Confrontation MARTE/AADL . . . . 44 2.7 Les b´en´efices de l’IDM et UML . . . . 46 2.7.1 Une repr´esentation simplifi´ee . . . . 46 2.7.2 Une approche mono-langage. . . . 47 2.7.3 Un langage standard . . . . 47 2.7.4 Automatisation . . . . 47 2.7.5 R´eutilisation des sp´ecifications . . . . 47 2.8 Conclusion . . . . 49
2.1 Introduction
Dans le flot de conception des SoCs, l’´etape de mod´elisation repr´esente le point de d´epart, et c’est `a partir de celle-ci que la conception se concr´etise. Dans cette optique, une nouvelle discipline a vu le jour et porte le nom d’Ing´enierie Dirig´ee par les Mod`eles (IDM). Le but de celle-ci est de faciliter la d´efinition ainsi que la
manipulation de langages offrant de nombreuses possibilit´es d’automatisation. Nous allons commencer par d´efinir dans ce chapitre cette nouvelle discipline, pr´esenter les mod`eles existants et les comparer, pour par la suite pr´esenter le langage de mod´elisation graphique Unified Modeling Langage, que nous avons choisi comme support `a notre flot de conception. Enfin nous discuterons les b´en´efices que peut prodiguer ce type d’approche et de langage.
2.2 Ing´ enierie dirig´ ee par les mod` eles
Le nombre de langages impliqu´es dans les diff´erentes ´etapes du flot de concep- tion des MPSoC est `a l’origine du vide technologique que l’on peut constater dans la conception de ces syst`emes. Cette vari´et´e repr´esente un facteur limitant dans la com- munication entre les diff´erentes ´equipes impliqu´ees dans ce processus, et restreint les possibilit´es d’automatisation. Pour cette raison, la conception des SoC repose de plus en plus sur l’Ing´enierie Dirig´ee par les Mod`eles (IDM). Le but ´etant de faciliter la d´efinition et la manipulation de langages, en offrant de nombreuses possibilit´es d’automatisation. En particulier, le langage de mod´elisation unifi´e(UML) offre le moyen d’utiliser un formalisme unique hautement sp´ecialisable pour de nombreuses activit´es, telles que celles que l’on retrouve dans la conception des syst`emes sur puce.
Figure 2.1 – Exemple d’un syst`eme `a mod´eliser
L’Ing´enierie Dirig´ee par les Mod`eles, est apparue vers la fin des ann´ees 1990, et s’est particuli`erement d´evelopp´ee lors de la parution de l’initiative Model Dri- ven Architecture [MM03] de l’Object Management Group (OMG). L’IDM est une approche dont l’´el´ement cl´e est la notion de mod`ele. Nous prendrons pour exemple le syst`eme de carte illustr´e dans la figure2.1, comme support pour la d´efinition de mod`eles.
2.2. Ing´enierie dirig´ee par les mod`eles 27
2.2.1 Les mod`eles
L’int´erˆet d’utiliser un mod`ele est de pouvoir proposer une repr´esentation plus simple de l’´el´ement mod´elis´e, en ne laissant apparaˆıtre que les informations qui nous paraissent pertinentes pour l’utilisateur du mod`ele. Dans [B´e05], Jean Bezivin four- nit une pr´esentation d´etaill´ee des principaux concepts de l’IDM. Il illustre la notion de mod`ele en nous donnant l’exemple de la carte g´eographique. En effet une carte est un mod`ele de la r´ealit´e, une simplification du monde r´eel dans lequel on ne va laisser apparaˆıtre de mani`ere compr´ehensible qu’un nombre limit´e d’informations, comme illustr´e dans la figure2.2. Il est alors possible de faire plusieurs mod`eles de la mˆeme r´ealit´e, chacun portant sur un domaine pr´ecis. Ainsi une personne d´esirant obtenir des informations sur un territoire va alors utiliser diff´erents types de cartes suivant le domaine vis´e : la g´eographie, l’´economie ou autre.
Figure2.2 – Mod`ele propos´e pour la carte du syst`eme
L’IDM caract´erise explicitement la relation qu’il existe entre un ´el´ement mod´elis´e et son mod`ele, et qui est dite :“estRepr´esent´ePar”. Celle-ci est la premi`ere des deux relations sur lesquelles reposent les principes de l’Ing´enierie Dirig´ee par les Mod`eles.
2.2.2 Les m´eta-mod`eles
La deuxi`eme relation est appel´eeestConformeA. Elle s’applique entre le mod`ele et ce qui d´efinit quelles sont les informations que l’on va retrouver dans ce mod`ele.
Ainsi, pour reprendre l’exemple de la carte, celle-ci doit ˆetre conforme `a une l´egende.
Cette l´egende va d´efinir les types de donn´ees retrouv´ees dans une carte, telles que les villes, les diff´erents types d’axes routiers, etc. D’une mani`ere g´en´erale l’IDM appelle m´eta-mod`ele toute repr´esentation visant `a d´efinir les ´el´ements que l’on va retrouver dans un mod`ele ainsi que les relations qui existent entre ces ´el´ements, de telle sorte que tout mod`ele“estConformeA” un m´eta-mod`ele.
Notons que dans l’IDM, tout est mod`ele. En particulier un m´eta-mod`ele est lui mˆeme un mod`ele, et doit donc ˆetre conforme `a son m´eta-mod`ele. Par exemple, chez un ´editeur de cartes, les diff´erents types de cartes poss`edent tr`es souvent le mˆeme type de l´egende, qui consiste g´en´eralement en l’association d’une ou plusieurs formes g´eom´etriques et d’un texte expliquant `a quoi correspond cette forme. Ainsi si toutes les l´egendes des diff´erentes cartes sont conformes `a un mˆeme m´eta-mod`ele de l´egende, l’utilisateur ne sera pas perdu d’une carte `a l’autre, il saura lire la l´egende, et comprendre les informations contenues dans la carte, comme le montre la figure 2.3.
Figure 2.3 – Le m´eta-mod`ele auquel sont conformes : le mod`ele et le syst`eme mod´elis´e
La relation “estConformeA” pourrait donc s’appliquer un nombre ind´efini de fois, chaque m´eta-mod`ele ´etant lui-mˆeme un mod`ele conforme `a un m´eta-mod`ele sup´erieur. Cependant, on comprend ais´ement qu’un trop grand nombre de ces couches pourrait ˆetre inefficace, rajoutant de la complexit´e plus difficilement ex- ploitable. Ainsi il semblerait que dans le domaine de l’informatique, l’OMG ait d´ecid´e d’un nombre optimal de niveaux qui est 4, en incluant le niveau M0 identi- fiant le syst`eme `a mod´eliser– comme le montre la figure 2.4.
Afin de borner le nombre de couches superposables, on d´etermine un type de m´eta-mod`ele particulier appel´e m´eta-m´eta-mod`ele. La particularit´e de celui-ci est qu’il est capable de s’auto-d´ecrire : il est donc conforme `a lui-mˆeme. En effet, un m´eta-m´eta-mod`ele est un m´eta-mod`ele introduisant des notions permettant de d´efinir des m´eta-mod`eles : on va donc pouvoir utiliser ces notions pour d´efinir le m´eta-m´eta-mod`ele.
2.3. Apports de l’IDM 29
Figure 2.4 – Architecture en 4 couches employ´ee par l’IDM
2.3 Apports de l’IDM
Les notions de mod`ele et de m´eta-mod`ele ont toujours exist´e. En les identifiant clairement, l’IDM place le mod`ele au centre de son approche pour l’ing´enierie lo- gicielle. En relevant le niveau d’abstraction auquel travaille l’utilisateur, afin que l’utilisateur puisse se focaliser sur les concepts qu’il veut manipuler. L’IDM permet de relever le niveau d’abstraction auquel celui-ci op`ere, par la suite cette abstraction b´en´eficie de nombreux outils lui permettant d’automatiser de nombreuses ´etapes propres `a l’ing´enierie logicielle, comme la cr´eation de langages pour exprimer ces concepts, la g´en´eration de code ou encore la transformation de mod`eles.
2.3.1 Le m´eta-mod`ele : grammaire des mod`eles
Les grammaires classiques, telles que l’EBNF (Extended Backus-Naur Form [Sco93]), permettent d’identifier les concepts que l’on souhaite exprimer `a travers le langage, mais aussi les r`egles de syntaxe de ce langage, c’est `a dire la fa¸con correcte de construire les phrases de ce langage.
Le m´eta-mod`ele lui, ne d´efinit que les ´el´ements que devra exprimer le langage, et les relations qu’il peut y avoir entre eux, comme la notion de composition ou de r´ef´erence, voire plus selon le type de m´eta-m´eta-mod`ele utilis´e. Il d´efinit donc quels ´el´ements devront comporter une phrase bien construite : on parle de syntaxe abstraite.
L’avantage du m´eta-mod`ele est qu’il permet g´en´eralement de mieux exprimer les relations entre les diff´erents concepts d’un langage. De plus il devient aussi pos- sible d’associer `a un mˆeme m´eta-mod`ele diff´erentessyntaxes concr`etes. Ces syntaxes pourront ˆetre textuelles, mais aussi graphiques.
Dans la figure 2.5, le m´eta-mod`ele d´ecrit permet de mod´eliser d’une mani`ere simpliste la structure d’un syst`eme ´electronique. Ce m´eta-mod`ele est exprim´e au for- mat MOF [Obj06]. L’´el´ement racine de ce m´eta-mod`ele est la notion de syst`eme. Un
Figure2.5 – Exemple de m´eta-mod`ele
syst`eme poss`ede un nom, et peut ˆetre compos´e de deux types d’´el´ements diff´erents : des composants et des connections.
La relation de composition est exprim´ee par l’association avec un diamant noir, et l’´etoile pr´esente au bout de chacune de ces associations sp´ecifie que le nombre d’´el´ements associ´es est ind´efini. Un composant poss`ede un nom, et peut ˆetre com- pos´e de un ou plusieurs ports. Un port poss`ede aussi un nom, et un autre attribut appel´e direction. Celui-ci est de type TypeDeDirection, une ´enum´eration qui peut avoir pour valeur Entrant, Sortant ou Bidirectionnel. Enfin les connexions d’un syst`eme sont des ´el´ements ayant deux attributs, cible et source, tous les deux de type port : une connexion se fait donc entre deux ports.
Figure2.6 – Exemple de mod`ele utilisant une syntaxe graphique
La figure2.6est un exemple de mod`ele instanciant ce m´eta-mod`ele par une syn- taxe graphique. Une repr´esentation graphique de chaque ´el´ement du m´eta-mod`ele a
´et´e ainsi d´efinie. On voit donc dans la figure une instance deSyst`eme appel´eeMon- Syst`eme, lui-mˆeme instanciant deux composants interconnect´es. Nous remarquons, que la syntaxe du langage de cette illustration n’est pas enti`erement graphique, car la d´efinition des attributs d’un port est faite suivant une syntaxe textuelle d´efinie :
<direction>:<nom>, la direction s’´ecrivantin pour Entrant,out pourSortant et inout pour bidirectionnel.
La figure 2.7repr´esente une autre instanciation de ce m´eta-mod`ele, d´efinissant les mˆemes composants que pour la figure2.6mais cette fois-ci `a l’aide d’un langage textuel.
La d´efinition compl`ete d’un langage se fait aussi en lui associant une s´emantique,
2.3. Apports de l’IDM 31
System MonSyst`eme{
Component Composant1{
Port in portC1;
}
Component Composant2{
Port out portC2;
}
Binding Composant2.portC2 Composant1.portC1;
}
Figure 2.7 – Exemple de mod`ele utilisant une syntaxe textuelle
en plus du fait d’attribuer une syntaxe concr`ete au m´eta-mod`ele. Le rˆole de la s´emantique est de pr´eciser le sens des concepts introduits par le m´eta-mod`ele.
L’IDM n’apporte `a l’heure actuelle pas de solution pr´ecise par rapport aux aspects s´emantique.
2.3.2 Langage sp´ecifique et g´en´eraliste
Nous retrouvons deux principales approches dans l’´elaboration de langages, par- ticuli`erement lorsqu’il s’agit de langages graphiques. La premi`ere consiste `a cr´eer un m´eta mod`ele, c’est `a dire une syntaxe abstraite, pour chaque domaine que l’on souhaite mod´eliser (Domain Specific Language ou DSL). En y associant une ou plusieurs syntaxes concr`etes et une s´emantique propre `a ce domaine, on cr´ee alors un langage “sur mesure”, correspondant aux concepts que l’on d´esire repr´esenter.
La seconde, consiste `a cr´eer des langages de mod´elisations dits g´en´eralistes.
C’est par exemple le cas de l’Unified Modeling Language [Obj07d], qui comme son nom l’indique est une unification des diff´erentes tendances de mod´elisation que l’on retrouve dans le domaine de l’ing´enierie logicielle. La particularit´e d’un langage g´en´eraliste est d’ˆetre constitu´e d’un m´eta-mod`ele couvrant un large spectre de concepts de la mod´elisation logicielle, comme les sp´ecifications, la description structurelle ou comportementale d’un syst`eme.
Les avantages et inconv´enients de cette approche sont alors les duaux de ceux des DSL. En effet, il ´evite la multiplication des langages, et donc de leur apprentissage, et favorise ainsi la communication des informations. De plus, il n’est plus n´ecessaire de multiplier les logiciels d’´edition, tous les aspects d’un syst`eme pouvant ˆetre cou- verts dans le mˆeme langage. En revanche, le m´eta-mod`ele de ce type de langage devient complexe `a comprendre dans son ensemble, avec une s´emantique parfois vague, et peut introduire une complexit´e superflue lorsqu’il s’agit de mod´eliser un domaine relativement simple. De plus lorsque l’on touche `a un domaine sp´ecifique, il se peut que le langage ne soit pas suffisamment g´en´eraliste, et que la mod´elisation des concepts vis´es devienne fastidieuse `a l’aide de ce langage. Nous verrons par la suite qu’UML pallie en partie cette faiblesse en proposant un m´ecanisme de sp´ecialisation par le biais de profils, en proposant un moyen standard d’´etendre son
m´eta-mod`ele.
2.4 Pr´ esentation de l’Unified Modeling Language
2.4.1 Etat de l’art
L’Unified Modeling Language est un langage de mod´elisation g´en´eraliste n´e de la fusion de diff´erentes initiatives pour la d´efinition de m´ethodologies de g´enie logiciel [RBP+91,Boo86,JCJo92]. En effet, le besoin de proposer des m´ethodes de conception logicielle pour faire face `a une complexit´e des syst`emes informatiques d´ej`a croissante est apparu d`es les ann´ees 1970 [You74,DeM78,PJ80].
La g´en´eralisation de l’approche objet dans les ann´ees 80 acc´el´era le nombre de ces initiatives, jusqu’`a ce que leur nombre atteigne plus de 50 propositions diff´erentes au milieu des ann´ees 90. Pour tenter d’apporter un peu d’unification dans cette effervescence, Rational Software engagea trois auteurs de m´ethodologies diff´erentes : James Rumbaugh [RBP+91], Grady Booch [Boo86, Boo94] et Ivar Jacobson [JCJo92]. S’apercevant qu’une m´ethodologie de conception logicielle ne pouvait ˆetre universelle et couvrir tous les diff´erents aspects m´etiers, leur initiative de m´ethodologie unifi´ee se transforma en la d´efinition d’un langage de mod´elisation orient´e objet, unifiant les diff´erents besoins de repr´esentation que l’on retrouvait `a travers les diverses m´ethodologies. Ce travail aboutit en 1996 `a la version 0.9 de l’Unified Modeling Language. Ce travail fut repris par l’OMG pour un processus de standardisation, tout en continuant son ´evolution, l’enrichissant progressivement de nouveaux concepts.
2.4.2 Diagrammes UML
Le m´eta-mod`ele d’UML se d´ecompose en diff´erents paquetages interd´ependants que l’on peut regrouper en deux principales cat´egories : ceux relatifs `a la description structurelle, et ceux relatifs `a la description comportementale. Chaque paquetage introduit alors des concepts, et pour certains d’entre eux1, une ou plusieurs syn- taxes graphiques pour les exprimer `a travers des diagrammes.
L’organisation des principaux paquetages est d´ecrite dans la figure2.8. Voici une br`eve description de chacun d’entre eux, en commen¸cant par la partie structurelle : Classes : Ce paquetage introduit les concepts de base de la mod´elisation UML, avec en particulier la notion deClass. C’est de certains de ses sous-paquetages qu’est constitu´e le noyau commun entre le MOF et UML. Les diagrammes as- soci´es sont bien sˆur lediagramme de classe, mais aussi lediagramme d’objet,
1. Certaines m´eta-classes du m´eta-mod`ele d’UML d´efinissent des concepts abstraits qui seront par la suite sp´ecialis´es. Ce sont ces sp´ecialisations qui seront repr´esent´ees graphiquement, les classes abstraites n’´etant pas instanci´ees directement. Certains concepts comportementaux sont aussi in- troduits dans la s´emantique d’action d’UML sans pour autant avoir de syntaxe concr`ete pour les exprimer.
2.4. Pr´esentation de l’Unified Modeling Language 33
Figure2.8 – Organisation des paquetages du m´eta-mod`ele d’UML
destin´e `a repr´esenter une instanciation particuli`ere des classes d´efinies dans un diagramme de classe. C’est aussi sur ces paquetages que s’appuie la syntaxe dudiagramme de paquetages comme celui de la figure2.8. Le paquetage (Pa- ckage) sert `a structurer les mod`eles en regroupant les ´el´ements par cat´egories, en y associant un espace de nommage. Le diagramme de paquetage d´ecrit alors leur organisation, en d´ecrivant notamment leur diff´erents types d’in- terd´ependances.
CompositeStructures : Ce paquetage d´efinit une meilleure fa¸con d’exprimer la composition entre les classes et leur sous-´el´ements [Boc04]. Il d´efinit notam- ment la notion de port et de connecteur, permettant d’´editer desdiagrammes de structure composite. Comme nous le verrons par la suite, c’est celui-ci qui semble le plus adapt´e pour la description d’architecture mat´erielles.
Components : Ce paquetage sp´ecialise le pr´ec´edent, et permet d’apporter les concepts de la programmation orient´ee composants `a UML. Un composant permet de repr´esenter l’abstraction d’un ensemble de classes accomplissant un groupe de fonctionnalit´es. Le diagramme de composants permet alors de repr´esenter comment s’organise un syst`eme constitu´e de ces abstractions, en mettant en ´evidence leur communication via des interfaces.
Deployments : Le but de ce paquetage est principalement d’exprimer comment vont ˆetre impl´ement´es et r´epartis les unit´es logicielles que l’on a sp´ecifi´ees
`
a l’aide des diagrammes pr´ec´edents, et plus particuli`erement le diagramme de composants. Le diagramme de d´eploiement est ainsi utile pour avoir une bonne repr´esentation d’un syst`eme r´eparti, en identifiant les infrastructures d’ex´ecution et de communication sur lesquels va ˆetre d´eploy´e le code ex´ecutable (ou artefact) du programme sp´ecifi´e.
Les paquetages suivants permettent de d´ecrire le comportement des ´el´ements
d´ecrits `a l’aide du standard UML :
CommonBehaviors : Ce paquetage introduit les notions de base pour la d´efinition comportementale d’UML, en d´efinissant par exemple la notion d’ex´ecution et les principes de communication. Ces notions seront ensuite raffin´ees dans les paquetages suivants.
UseCases : Ce paquetage introduit les concepts n´ecessaires au diagramme de cas d’utilisation. Ce dernier permet d’identifier les fonctionnalit´es que l’on at- tend d’un syst`eme, et d’identifier les acteurs externes au syst`eme impliqu´es dans ces fonctionnalit´es. Il est g´en´eralement utilis´e dans les phases initiales de sp´ecification.
Interactions : Le paquetage Interactions introduit de nombreuses notions pour sp´ecifier ou illustrer comment des instances d’objet vont communiquer entre elles. UML d´efinit diff´erents diagrammes se basant sur ces principes : le dia- gramme de s´equence, lediagramme d’interactions globales2, lediagramme de communication ou encore lediagramme temporel3. Ces diff´erentes repr´esentations sont redondantes, chacune mettant l’emphase sur un certain aspect de la com- munication. L’utilisateur pourra donc choisir parmi ceux-ci en fonction de ce qu’il souhaite repr´esenter.
StateMachines : Le paquetage StateMachines introduit les notions permettant de d´ecrire des aspects comportementaux `a l’aide de machines d’´etat-transition.
Il s’agit d’une int´egration des StateCharts de Harel [Har87a, HG97]. UML d´efinit deux cat´egories de machines d’´etats : les machines comportementales et les machines de protocoles. Les premi`eres servent `a directement sp´ecifier le comportement d’une entit´e, alors que les secondes se focalisent sur le protocole en contraignant l’ordre des interactions entre diff´erents ´el´ements du syst`eme.
Activities : Les activit´es permettent de sp´ecifier le comportement d’un syst`eme en se focalisant sur l’enchaˆınement et la coordination d’actions ´el´ementaires.
Elles permettent de repr´esenter des mod`eles de flot de contrˆole ou flot d’objets, par l’interm´ediaire du diagramme d’activit´es.
Actions : L’occurrence d’un comportement peut-ˆetre vu comme la succession d’ac- tions ´el´ementaires. Ce paquetage identifie et d´efinit une s´emantique `a toutes ces actions ´el´ementaires. Les machines d’´etats et les activit´es peuvent ˆetre vues comme des structures de contrˆole sp´ecifiant un contexte dans lequel les actions vont avoir lieu. Bien qu’un grand nombre de concepts soient iden- tifi´es dans ce paquetage, permettant de porter leur s´emantique sur la plu- part des environnements d’ex´ecution (Java, C/C++ dans diff´erents OS.), la norme UML ne d´efinit pas de syntaxe pour un grand nombre d’entre eux. Cependant, diff´erentes initiatives ont d´efini un langage d’action `a UML [Mra05,MB02,WKC+01]. De tels langages permettent l’obtention de mod`eles UML compl`etement ex´ecutables sans avoir `a rajouter de code sp´ecifique `a
2. Interaction overview 3. Timing Diagram
2.4. Pr´esentation de l’Unified Modeling Language 35 un langage d’ex´ecution particulier, de telle sorte que l’on puisse par la suite g´en´erer diff´erentes impl´ementations ex´ecutables dans diff´erents langages `a par- tir d’un unique mod`ele [MWM05].
En r´esum´e de cette pr´esentation, la figure 2.9 propose une classification des 13 diagrammes du langage UML. Les classes dont le nom est en italique repr´esentent des classes abstraites, identifiant une cat´egorie de diagrammes.
Figure2.9 – Classification des 13 diagrammes du langage UML
2.4.3 D´efinition de profils UML
UML est un langage de mod´elisation g´en´eraliste. Comme nous l’avons intro- duit dans la section 2.4.1, son m´eta-mod`ele vise `a couvrir tous les aspects de la mod´elisation logicielle. Cependant, il arrive qu’en pratique son utilisation telle quelle ne soit pas adapt´ee pour mod´eliser les concepts d’un domaine bien particulier.
Conscients de ce probl`eme, les auteurs de ce langage y ont introduit la possibilit´e de le sp´ecialiser via le m´ecanisme de profil, permettant ainsi d’utiliser UML non plus comme un langage g´en´eraliste, mais plutˆot comme un langage sp´ecifique.
Figure 2.10 – Sp´ecialisation d’UML par le m´ecanisme de profil
Pour sp´ecialiser UML, un profil joue sur diff´erents points :
Extension du m´eta-mod`ele Le m´ecanisme offre un moyen d’´etendre le m´eta- mod`ele d’UML par l’utilisation dest´er´eotypes. Un st´er´eotype permet d’´etendre toute m´eta-classe du langage UML (sauf la m´eta-classest´er´eotypeelle-mˆeme4) et de cr´eer ainsi une nouvelle m´eta-classe h´eritant de toutes les propri´et´es de la m´eta-classe ´etendue. Il devient aussi possible d’ajouter des nouvelles propri´et´es `a cette nouvelle m´eta-classe `a l’aide de tagged values. Il est pos- sible d’obliger l’utilisation de st´er´eotypes sur la m´eta-classe, de telle sorte que l’utilisateur ne soit plus autoris´e `a employer la m´eta-classe originale dans un mod`ele.
Le st´er´eotype est le m´ecanisme de base pour l’extension d’UML. Il d´efinit com- ment une m´eta-classe particuli`ere du m´eta-mod`ele d’UML peut ˆetre ´etendue pour permettre l’utilisation d’une terminologie ou d’une notation sp´ecifique `a un domaine ou une plate-forme particuli`ere.
Un st´er´eotype est li´e par un lien d’extension [Obj07c] `a une m´eta-classe par- ticuli`ere du m´eta-mod`ele. Les ”tagged values” introduites dans UML1.x sont consid´er´ees dans UML2.0 comme des propri´et´es des st´er´eotypes. Quand un st´er´eotype est appliqu´e `a un ´el´ement du mod`ele (instance de la m´eta-classe sur laquelle le st´er´eotype est d´efini), cet ´el´ement sera annot´e par ce st´erotype
<<label st´er´eotype>> et les valeurs de ses propri´et´es si elles existent, seront
consid´er´ees comme des tagged values associ´ees `a cet ´el´ement. Une tagged value a un nom et un type.
Fermeture de points de variation s´emantique : Dans le but de pouvoir s’adap- ter `a diff´erents domaines, la norme UML laisse d´elib´er´ement certains points de s´emantique ouverts. Lorsque l’on ´etend une m´eta-classe, on h´erite de sa s´emantique. Pour que le langage que l’on cr´ee soit bien d´efini, il faut donc veiller `a fixer ses points de variation s´emantique si elle en a, en fonction de la sp´ecialisation que l’on en fait.
Ajout de contraintes OCL : La nouvelle m´eta-classe que l’on cr´ee `a l’aide d’un st´er´eotype s’utilise a priori en respectant les contraintes appliqu´ees `a la m´eta- classe ´etendue. Cependant, il est possible d’ajouter des contraintes suppl´ementaires en associant des contraintes OCL (Object Constraint Langage), au st´er´eotype.
Un ´editeur UML suffisamment ´evolu´e sera capable d’interpr´eter ces contraintes et de signaler une erreur de mod´elisation.
Sp´ecialisation de la syntaxe graphique : Le m´ecanisme de profil pr´evoit la possibilit´e d’associer une forme visuelle particuli`ere au st´er´eotype que l’on d´efinit. Ainsi, on peut sp´ecialiser la syntaxe graphique en sp´ecialisant les dia- grammes. L`a aussi, un ´editeur ´evolu´e tel que Papyrus UML [CEA] permet de charger dynamiquement ces images et d’´editer directement ce nouveau type de diagramme.
4. En empˆechant la sp´ecialisation de la notion de st´er´eotype, UML s’empˆeche de modifier son m´ecanisme de sp´ecialisation, ce qui permet de pouvoir interpr´eter un profil de mani`ere syst´ematique, mais qui a aussi pour effet de limiter les possibilit´es de sp´ecialisation
2.4. Pr´esentation de l’Unified Modeling Language 37 D´efinition d’une m´ethodologie de mod´elisation : Enfin lorsque l’on d´efinit un profil, il paraˆıt n´ecessaire de bien le documenter, notamment en identifiant clairement les diagrammes avec lesquels ce profil est fait pour ˆetre utilis´e.
En effet un st´er´eotype ne pr´ecise pas par lui-mˆeme dans quel diagramme il doit ˆetre utilis´e. Lorsqu’un ´el´ement d’un m´eta-mod`ele peut apparaˆıtre dans diff´erents diagrammes, le st´er´eotype qui l’´etend le peut aussi. Or la trans- formation d’UML en un DSL cherche `a choisir les repr´esentations les plus expressives pour le domaine que l’on vise, notamment lorsqu’il existe plu- sieurs diagrammes redondants. Cela passe donc par la d´efinition de “bonnes pratiques”, voire l’interdiction d’utiliser certains ´el´ements du m´eta-mod`ele d’origine.
2.4.4 Marte : un profil pour les syst`emes embarqu´es temps r´eel Les sp´ecifications du profil MARTE [Obj07b] ajoutent de nouvelles possibi- lit´es au d´eveloppement d’applications pour les syst`emes temps r´eel et embarqu´es (RTES). L’utilisation de ce profil offre une base solide pour sp´ecifier, concevoir, v´erifier et valider un RTES.
MARTE d´efinit les fondements pour la description de mod`ele des syst`emes temps r´eels et embarqu´es. Ces concepts sont alors raffin´es pour mod´eliser et analyser des probl`emes. Dans ce sens, l’intention n’est pas de d´efinir de nouvelles techniques pour analyser les syst`emes temps r´eel et embarqu´es, mais de les soutenir. Par cons´equent, il fournit des solutions pour annoter des mod`eles avec l’information requise pour ex´ecuter l’analyse sp´ecifique. En particulier, MARTE se concentre sur l’analyse de l’ex´ecution et de la programmation. Mais, il d´efinit ´egalement un cadre g´en´eral d’analyse qui pr´evoit de sp´ecialiser n’importe quel autre genre d’analyse.
Les retomb´ees attendues de l’usage de ce profil sont de :
— fournir une mod´elisation unifi´ee pour les parties mat´erielles et logicielles du syst`eme.
— permettre l’interop´erabilit´e entre les outils de d´eveloppement utilis´es en sp´ecification, en conception, en v´erification et en g´en´eration de code ;
— faciliter la construction de mod`eles sur lesquels on peut faire des pr´evisions quantitatives tenant compte des caract´eristiques du mat´eriel et du logiciel.
Comme illustr´e sur la figure2.11, MARTE d´efinit les fondations de la mod´elisation des RTES [BBC+05] et est d´ecompos´e en diff´erents sous-profils. Nous distinguons par exemple :
1. Le mod`ele d’application qui d´ecrit les fonctionnalit´es du syst`eme.
2. Le mod`ele des ressources qui d´ecrit la plateforme d’ex´ecution en prenant compte des propri´et´es non-fonctionnelles. Ce mod`ele se compose `a son tour de trois mod`eles :
— Le mod`ele des ressources g´en´eriques.
— Le mod`ele des ressources logicielles qui d´ecrit la plateforme d’ex´ecution logi- cielle ; par exemple le syst`eme d’exploitation.
Figure 2.11 – Architecture du standard MARTE
— Le mod`ele des ressources mat´erielles qui d´ecrit la plateforme d’ex´ecution mat´erielle ; par exemple le processeur.
3. Le mod`ele d’allocation de l’application sur les ressources.
MARTE fournit une mod´elisation unifi´ee pour les parties mat´erielles et logi- cielles d’un syst`eme h´et´erog`ene, comme la consommation d’´en´ergie, et la capacit´e m´emoire ce qui est primordial `a la reconfiguration dynamique et partielle ce qui permet une meilleure int´egration des composants.
2.4.5 Non Functional Properties Modeling (NFPs)
Les propri´et´es d’une application sont regroup´ees traditionnellement en deux cat´egories : Celles propres aux fonctionnalit´es que doit remplir l’application (i.e les services) et celles li´ees `a la qualification des fonctionnalit´es attendues (i.e. les qualit´es de service).
Les premi`eres sont dites fonctionnelles, les secondes non-fonctionnelles(NFPs).
Les NFPs fournissent des informations sur diff´erentes caract´eristiques telles que les d´elais d’ex´ecution, l’utilisation de la m´emoire, la consommation d’´energie, les bandes passantes etc.
Le paquetage NFPs [Obj07b][Esp07] de MARTE formalise un ensemble de concepts de mod´elisation permettant la description pr´ecise et compl`ete des informations non- fonctionnelles. Ce paquetage vise donc `a qualifier et `a typer de mani`ere standard les propri´et´es non-fonctionnelles. Pour cela il ´etend les types de donn´ees d’UML par les principaux types manipul´es dans le domaine de l’embarqu´e et du temps-r´eel. Ces types standards sont fournis sous une forme de librairie BasicNFP Types, qu’il est possible d’importer. Par ailleurs, il est possible de d´efinir ses propres types tout en utilisant une notation standard, ce qui n’existait pas auparavant dans UML.
2.4. Pr´esentation de l’Unified Modeling Language 39
2.4.6 Hardware Resource Model (HRM)
HRM est un sous-profil de MARTE permettant de d´ecrire du mat´eriel existant ou bien d’en concevoir un nouveau `a travers plusieurs vues et diff´erents niveaux de d´etail.
HRM regroupe la plupart des concepts du mat´eriel sous une taxonomie hi´erarchique avec plusieurs cat´egories selon leur nature, fonctionnalit´e, technologie et forme.
Il comprend deux vues, une vue logique qui classifie les ressources du mat´eriel selon leurs propri´et´es fonctionnelles, et une vue physique qui les distingue selon leurs propri´et´es physiques.
Le mod`ele g´en´eral de HRM (Figure 2.12) d´efinit la structure typique d’une plateforme d’ex´ecution [TTRG06]. Il est ainsi une base commune entre le mod`ele logique et le mod`ele physique qui en font deux sp´ecialisations diff´erentes.
Figure 2.12 – Mod`ele g´en´eral de HRM
Le st´er´eotype HW Resource d´enote une entit´e g´en´erique du mat´eriel. Il four- nit au moins un HwResourceService et en requiert d’autres depuis d’autres HW Resource(s) de la mˆeme plateforme d’ex´ecution.
En effet, la collaboration des ressources par le biais de leurs services caract´erise la plateforme d’ex´ecution. Chaque HW Resource peut contenir des ownedHW res- sources qui `a leur tour peuvent ˆetre composites et ainsi de suite.
Ce m´ecanisme de composition permet de mod´eliser le mat´eriel `a diff´erentes gra- nularit´es. Dans ce sch´ema d’encapsulation successif, on consid`ere comme plateforme la HW Resource englobante de granularit´e z´ero, et si une telle ressource n’existe pas, cela sera consid´er´e comme une erreur de mod´elisation.
D’un point de vue structurel, le st´er´eotype HW Resource est similaire `a la m´eta- classe Component d’UML, mais s´emantiquement il d´efinit une entit´e d’ex´ecution mat´erielle dont les services sont annot´es par des caract´eristiques de qualit´e de service [Sel04].
Afin d’augmenter la flexibilit´e lors de la mod´elisation avec le profil HRM, HW
Resource ´etend les m´etas classes g´en´erales du noyau d’UML Classifier, Property et Instance Sp´ecification. Il est par cons´equent possible d’utiliser HRM avec tous les diagrammes de structure d’UML (diagramme de classe, diagramme de composant, diagramme de composite structure . .). De mˆeme HwResourceService ´etend la m´eta classe UML BehavioralFeature et pourra donc ˆetre associ´e `a toute vue comporte- mentale d’UML.
En ´etendant aussi Instance Specification, cela permet l’application des st´er´eotypes aux deux niveaux : classe et instance. Toutefois, la s´emantique diff`ere, car si les propri´et´es de d´efinitions d´enotent des caract´eristiques statiques et communes `a tous les objets de la classe dans le premier cas, elles repr´esenteront plutˆot des caract´eristiques dynamiques et sp´ecifiques `a chaque objet dans le second cas. Tous les st´er´eotypes du profil HRM h´eritent de HW Resource, ils b´en´eficient alors de la mˆeme structure et des mˆemes extensions. La figure 2.12 montre le second ´etage de st´er´eotypes, il s’agit de HwComponent du cˆot´e du sous-profil HwPhysical et de HwComputingResource, HwMemory, HwStorageManager, HwCommunication- Resource, HwTimingResource et HwDevice du cˆot´e du sous profil HwLogical. A ce niveau, les st´er´eotypes restent encore g´en´eriques, cependant les ´etages suivants d’h´eritages sont sp´ecifiques.
2.4.7 Generic Component Modeling (GCM)
Le sous-profil GCM permet de mod´eliser les interfaces des ports pour les formats de message ainsi que le sens de transfert ou de r´eception des donn´ees(Figure 2.13).
Figure 2.13 – Mod`ele g´en´eral de GCM
