Spécification des propriétés dans un processus d aide à l optimisation

Transcription

1 Spécification des propriétés dans un processus d aide à l optimisation Une Approche, Dirigée par les Modèles, pour la Spécification des Propriétés Non Fonctionnelles des Systèmes sur Puce dans un Processus d Aide à l Optimisation Souha Kamoun, Pierre Boulet LIFL-UMR CNRS 8022, Université de Lille, INRIA Parc Scientifique de la Haute Borne Park Plaza Bâtiment A, 40 avenue Halley Villeneuve d ascq Cedex France { souha.kamoun, RÉSUMÉ. Les contraintes de temps d exécution, d utilisation de mémoire, et de consommation d énergie sont des propriétés non fonctionnelles qui doivent être modélisées pour guider la conception des systèmes embarqués. Ceci implique une utilisation optimale des ressources logicielles et matérielles, tout en respectant les contraintes de performance des systèmes embarqués multiprocesseurs. Dans ce papier, nous présentons une approche dirigée par les modèles, qui permet de fournir des modèles de conception, annotés avec des contraintes non fonctionnelles, à des outils d optimisation. Le travail est réalisé dans l environnement Gaspard2, dédié à la conception des systèmes embarqués sur puce pour des applications de traitement de signal intensif. Nous utilisons le profile UML MARTE comme langage de modélisation. Nous concluons en présentant un exemple d application pour illustrer la méthodologie. ABSTRACT. Embedded systems must provide high levels of performance for applications. However, this performance must meet real time constraints and a large number of requirements as power and energy requirements. That implies an optimal usage of both hardware and software under the strict requirements of multiprocessor systems on chip. The choice of resources is one of the basic decisions in the design of embedded systems. The decision depends essentially on the information related to performance, such as number of instructions or execution time, cost.. In this paper, we present a model-driven approach that provide annotated models for optimisation tools. This work is integrated in the framework Gaspard2, an environment dedicated to the design of high-performance embedded system-on-chip. We used MARTE as a modeling language. We conclude by illustrating our methodology with an example. L objet. Volume 8 n 2/2005, pages 1 à 15

2 2 L objet. Volume 8 n 2/2005 MOTS-CLÉS : modélisation, systèmes sur puce, propriétés non fonctionnelles, optimisation, MARTE. KEYWORDS: Modeling, systems on chip, non functional properties, optimisation, MARTE.

3 Spécification des NFP 3 1. Introduction Les applications de traitement de signal intensif exigent l utilisation de machines parallèles à hautes performances. Leur exploitation exige de la part des experts, non seulement une parfaite connaissance de l architecture mais aussi une bonne exploitation des propriétés non fonctionnelles des ressources matérielles (taille mémoire, puissance de calcul, réseau de communications...),tout en respectant les contraintes de temps et de coût. En effet, les propriétés non fonctionnelles guident l exploitation d architectures des systèmes sur puces et aident le concepteur à faire des choix de conception. Cependant, ces propriétés ne peuvent être exploitées que dans le cadre d une méthodologie bien définie. D ou la nécessité d en définir une. La définition d une méthode d aide à la conception assistée par des outils d optimisation passe nécessairement par la modélisation de ces propriétés ainsi que les outils qui permettent de les exploiter. L Ingénierie Dirigée par les Modèles (IDM) représente une véritable alternative. Nos travaux se déroulent dans le cadre de Gaspard2 (Graphical Array Specification for Parallel and Distributed Computing) (DaRT Team LIFL/INRIA, Lille, France, 2008), un environnement de conception de systèmes embarqués sur puce qui permet la co-modélisation de tels systèmes. Il fournit un support, basée sur l IDM, pour modéliser la partie logicielle de l application indépendamment de la partie matérielle, et puis d expliciter l association logiciel/application ainsi que le déploiement des composants réutilisables appelés IPs (Intelectual property). Comme illustré sur la Figure 1, GAS- PARD propose l utilisation de modèles définis à différents niveaux d abstractions. La transition entre ces différents niveaux s effectue par transformations de modèles, suivant un processus de raffinement aboutissant à la génération de code pour différentes cibles (SystemC, VHDL...). Le concepteur décrit, au plus haut niveau, l application et l architecture sur laquelle l application sera exécutée. A partir de ces deux modèles, il est alors possible de définir comment les composants de l application sont répartis sur l architecture. Cette phase, dite d association, est décrite à l aide d un modèle appelé aussi association. Les modèles d application, architecture et association sont complètement indépendants de toute technologie d implémentation. L association dans Gaspard2 étant statique et dépendante des choix du concepteur, nous avons alors proposé d automatiser cette étape en couplant Gaspard2 à un outil d optimisation, qui permet de retrouver la solution optimale. Cette solution doit prendre en considération les caractéristiques et les exigences de l application ainsi que la plateforme d exécution. D ou la nécessité d enrichir les modèles par la spécification des propriétés non fonctionnelles ainsi que les contraintes imposés par l environnement ou par le concepteur. Le recours à

4 4 L objet. Volume 8 n 2/2005 Figure 1. L environnement Gaspard2 l IDM a permis de proposer une approche basée sur les profils, les méta-modèles et la transformation de modèles. Le profil MARTE offre au concepteur la possibilité d exprimer les différentes exigences non fonctionnelles à travers l utilisation des stéréotypes. Le passage à la méta modélisation permet de passer d un modèle à un autre par transformation de modèles. Ainsi, l intégration de l outil SynDEX se traduit par la transformation d un modèle MARTE vers un modèle SynDEX. Le moteur de transformation prend en entrée un modèle conforme au méta-modèle MARTE et fournit en

5 Spécification des NFP 5 sortie un modèle conforme au méta-modèle SynDEX. Cette étape sera détaillée dans la section 3. Dans cet article, nous proposons une approche, dirigée par les modèles, qui fournit des modèles d entrée aux outils d optimisation. Le problème général du placement optimal est par essence NP-complet, le fait de définir des contraintes de performance permet de réduire l espace de solutions. Dans la section 2, nous introduisons la modélisation des propriétés non fonctionnelles dans les systèmes embarqués et plus précisemment les applications de traitement de signal intensif. Nous présentons ensuite, dans la section 3, la méthodologie que nous proposons pour répondre aux différents problèmes. Nous illustrons nos travaux avec un exemple dans la section 4, nous avons choisi le downscaler (Lee et al., 2000) comme exemple d application. Une discussion autour des différents points abordés dans cet article est donnée dans la section 5, ainsi que des perspectives pour ces travaux avant de conclure dans la section 6.

6 6 L objet. Volume 8 n 2/ Modélisation des exigences La modélisation des propriétés non fonctionnelles dans la conception des systèmes embarqués constitue une étape importante du flot de conception. Dans ce domaine, les applications utilisant de grandes quantités de données, les ressources de calcul et de mémorisation doivent intégrer l augmentation du flux de données. La conception du système doit alors s appuyer sur une modélisation des contraintes temporelles strictes en terme de cadence et de latence, et des exigences liées à la consommation d énergie, performance...en effet, il est plus facile de vérifier les exigences fonctionnelles à haut niveau, que les exigences non fonctionnelles. Ceci conduit à la violation de ces exigences non fonctionnelles. Pour souligner l importance de ce problème, on peut considérer une application qui ne respecte pas un seuil défini pour la consommation d énergie. Cette application, une fois embarquée dans un téléphones portable par exemple, produirait un problème de charge. Dans le contexte du traitement du signal, les exigences non fonctionnelles sont encore plus importantes. On distingue essentiellement : les contraintes de ressources et les contraintes temps réels. Les ressources caractérisent la puissance de calcul d une architecture et disposent d un ensemble de paramètres que l on peut dimensionner pour trouver l adéquation application/architecture la plus optimale : Les processeurs : Les paramètres considérés sont la fréquence d horloge ainsi que le nombre d instructions réalisables en un temps donné. Il est possible d attribuer un cout matériel aux processeurs, qu on essayera de minimiser lors du placement. La mémoire : Elle est caractérisée par son temps d accès et la quantité disponible par processeur. Les communications : Les communications dépendent fortement de l architecture cible. Toutefois, ils constituent le paramètre le plus difficile à gérer. Deux aspects du temps réel sont considérés dans nos applications : la cadence des acquisitions et la restitution des données, ce qui revient à dire dans une application de traitement d image par exemple : on traite 400 images/secondes ce qui correspond à l entrée des échantillons de signal. Le deuxième aspect considéré est la latence, qui modélise le temps de réponse entre l instant de production du résultat et l instant d acquisition du signal. La modélisation des propriétés non fonctionnelles dans la conception des systèmes embarqués a été abordé dans certains travaux, Dans[Chung], les exigences non fonctionnelles sont réparties en sous-exigences, ce qui permet de rationaliser la conception d architecture ainsi que le processus d exploration. Aagedal[ref]définit CQML, un langage spécifique pour les propriétés non fonctionnelles dans les systèmes à base de composants. CQML fournit une riche

7 Spécification des NFP 7 syntaxe pour l expression des aspects non fonctionnels, d ailleurs la majorité de ces concepts ont été repris dans le profil UML pour la qualité de service QoS. Zchaler [144] propose dans [ref] un cadre sémantique pour les spécifications non fonctionnelles des systèmes à base de composants. La déclaration des propriétés non fonctionnelles est faite par des mesures. Des contraintes sur ces mesures expriment les valeurs non fonctionnelles. Le langage UML ne permettant pas d exprimer les propriétés non fonctionnelles comme la performance, l énergie, les temps d exécution... Des profils ont été proposés pour remédier à cette limite. Le profil QoS&FT(Profile for Modeling Quality of Service and Fault Tolerance characteristics and mechanisms) (Object Management Group, Inc., 2004) est un standard OMG qui permet de spécifier des qualités et des exigences non fonctionnelles des systèmes. Cependant, le manque de sémantique a retardé son adaptation. D autres profils, plus orientés vers les systèmes temps réels et les systèmes embarqués, ont été proposé : OMEGA dans [ref], TURTLE[ref], AADL (Feiler et al., 2003), SPT (OMG, n.d.b) qui a été standardisé par l OMG... Le dernier profil en date est MARTE (OMG, n.d.a), un standard OMG, qui est destiné à la modélisation des systèmes temps réels embarqués. Il regroupe des concepts permettant de modéliser les exigences non fonctionnelles : le paquetage Time pour spécifier le temps ainsi que les contraintes temporelles et le paquetage NFP résultant des travaux de thèse d espinoza [ref] permet d exprimer les propriétés non fonctionnelles. Cependant, la majorité de ces travaux couplent la spécification des exigences non fonctionnelles à des approches d analyse de performance. Espinoza définit dans[ref espin] des concepts génériques de haut niveau pour faire de l analyse de performance à partir de modules paramétrés. la modélisation des NFPs est liée dans la plupart des travaux à des outils analytiques, ou des transformations vers des modèles de performances. Dans Gaspard2, le modèle d exécution étant spécifiée à la génération de code, on ne pas faire des analyses de performance à haut niveau. 3. Approche proposée La conception des systèmes complexes en traitement de signal intensif implique de réduire les coûts architecturaux et de maximiser les performances temporelles, tout en considérant les contraintes de communication, d accès mémoire et de consommation d énergie durant la phase d allocation des tâches aux ressources matérielles. Le respect de ces contraintes nécessite dans un premier temps, un travail de modélisation. Les heuristiques de placement permettent par la suite de trouver la bonne adéquation architecture/application tout en respectant les contraintes. L utilisation de l approche IDM [8] permet d utiliser des profils et des méta modèles qui garantissent la réutilisabilité des modèles. Dans notre cas, ces modèles correspondent aux modèle d application, d architecture et d association annotés d informations liés à la performance. Les transformations de modèles permettent de fournir ces modèles aux outils d optimisa-

8 8 L objet. Volume 8 n 2/2005 tion, qui donnent le placement optimale. Ceci, nous a conduit à proposer la solution suivante (Figure 2) : Figure 2. Approche proposée La première étape consiste à annoter les modèles d application, d architecture et d association avec les valeurs des propriétés non fonctionnelles. Nous utilisons le profile MARTE pour modéliser les propriétés non fonctionnelles. MARTE étant un profil qui définit les concepts clés pour les systèmes temps réels embarqués, il contient les paquetages : NFP ( propriétés non fonctionnelles) et Time (temps) qui sont parfaitement adaptés à nos besoins. Nous optons par la suite pour deux outils d optimisation : Syndex (Project INRIA AOSTE, n.d.) et un outil développé au sein de l équipe (Benyamina et al., 2007). L outil développé par (Benyamina et al., 2007) est basé sur des heuristiques de placement multi-objectifs, ce qui permet d optimiser plus d un critère à la fois. Cependant, cet outil étant encore en phase de développement, nous avons choisi alors d utiliser SynDEX, ce qui nous permet d exploiter dans l immédiat les résultats d optimisation. Ce choix implique de faire certaines modifications au niveau de nos applications, vu que certains traitements ne sont pas supportés par SynDEX tel que la répétition des tâches et l aspect multidimensionnel des tableaux de données. Notre approche étant dirigée par les modèles, on s est appuyé principalement sur l utilisation des méta modèles afin d assurer le passage vers les outils d optimisation par transformation de modèles. Le méta modèle syndex a été défini dans le cadre du

9 Spécification des NFP 9 projet openembedd[ref], ainsi qu un traducteur qui permet de faire passer les modèles syndex vers l outil syndex. Notre contribution à ce niveau a été de définir les règles de transformation entre nos modèles et les modèles syndex. Ces règles couvrent les modèles d application et d architecture. Une deuxième transformation a été définie pour assurer le passage vers (Benyamina et al., 2007). Cet outil étant à base de graphes, nous avons alors défini un méta modèle de graphe qui permet de définir complètement l application et les paramètres de l architecture matérielle tels qu on les a défini dans Gaspard2. Le graphe modèle doit être caractérisé. Ces caractéristiques sont les attributs des noeuds et arcs. Certaines de ces caractéristiques sont spécifiques à l application telles que les contraintes de temps réel et la consommation d énergie. D autres sont relatives à l architecture comme l ensemble d instructions du processeur, fréquence d horloge, consommation d énergie, taille mémoire, largeur de bande... Sans oublier ceux qui caractérisent l association des composants d application aux composants de l architecture telles les temps estimés ou les contraintes de placement. Ces derniers sont représentés par des liens entre le graphe d application et le graphe d architecture. Nous détaillons dans ce qui suit les étapes de l approche présentée Modélisation des propriétés non fonctionnelles La première étape consiste à identifier les stéréotypes MARTE qui permettent de modéliser les propriétés non fonctionnelles. L ajout de stéréotypes se fait à trois niveaux différents : l application, l architecture et l association. Pour le modèle d application, on identifie les propriétés non fonctionnelles liées aux tâches ainsi que les contraintes pour les spécifier. Nous avons choisi d appliquer le stéréotype ResourceUsage(Figure 3)sur les différentes tâches. Les différentes tagged values permettent de caractériser le temps d exécution d une tâche, la taille des messages échangés, la mémoire allouée, la mémoire utilisée, l énergie consommée...on utilise le paquetage NFP pour quantifier ces valeurs, le temps d exécution par exemple est exprimé avec NFP_Duration. Les NFPs importent aussi le paquetage VSL (value specification language),ce qui permet de varier la spécification des propriétés non fonctionnelles ; on peut alors avoir des valeurs, des variables, des expressions... Cependant, les stéréotypes NfpConstraint et TimedConstraint sont utilisés pour modéliser les exigences qu ont veut définir. Il est alors possible de mettre des contraintes de temps d exécution globale ou de consommation d énergie. Pour le modèle d architecture, on a uniquement ajouté le stéréotype hwcomponent (Figure 4)qui permet de définir les caractéristiques liés au système sur puce tel que la dimension, la surface...en associant des NfpConstraint aux composants matériels, il est possible de définir des contraintes sur ces caractéristiques,

10 10 L objet. Volume 8 n 2/2005 Figure 3. Le stéréotype ResourceUsage exemple : A( définie comme la variable de surface)<(3,mm2) exige que la surface de la puce ne dépasse pas 3mm2. Figure 4. Le stéréotype hwcomponent Pour la transformation vers SynDEX uniquement les modèle d application et d architecture sont utilisés. Cependant, pour l outil (Benyamina et al., 2007) on a besoin de caractériser les associations de tâches et de composants matériaux. Pour cela, nous avons ajouté le stéréotype ResourceUsagesur les associations dans le modèle d association. Ainsi, les tagged values permettent de spécifier les différentes propriétés non fonctionnelles liés à l exécution d une tâche sur un processeur donné.

11 Spécification des NFP Transformation vers des outils d optimisation Une fois le travail de modélisation achevé, nous procédons à l exploitation des modèles obtenus afin de les fournir comme modèles d entrée aux outils d optimisation choisis. Nous avons défini un méta-modèle de graphe qui permet d obtenir des Figure 5. MM de graphe modèles de graphes qui servent de support pour les heuristiques d optimisation utilisés dans l outil (Benyamina et al., 2007). La Figure 5 illustre les différents concepts permettant de définir le graphe. Ainsi le graphe est composé de noeuds (logiciels et matériels) et d arcs. Un noeud de graphe peut être répétitif,élémentaire, composé ou de type ressource matérielle. Les arcs liant des noeuds logiciels sont de type CommEdge, ils sont caractérisés par la valeur de la communication entre les différentes tâches. Les arcs liant des noeuds matériels sont dits TransEdge, ils portent la valeur de transmission entre les noeuds. Les arcs joignant des noeuds logiciels à des noeuds matériels sont des associations. Ils caractérisent les différentes propriétés non fonctionnelles liées à l exécution d une tâche sur un processeur tel que temps d exécution, mémoire...nous reprenons les NFPs de MARTE comme unités de mesure pour ces

12 12 L objet. Volume 8 n 2/2005 propriétés. La Figure 6 illustre l utilisation du méta-modèle de graphe pour obtenir Figure 6. Modèle de graphe des modèles de graphes compatibles avec le logiciel d optimisation qu on utilise. La deuxième transformation prend en entrée des modèles d application et d architecture Gaspard2 et fournit des modèles d application et d architecture SynDEX. L outil SynDEX (voir Figure 7) permettant le placement de signal, permet le partitionnement automatique du graphe de flot de données à un niveau de granularité élevé. Un ordonnancement monodimensionnel est alors calculé selon différentes heuristiques. Le système de placement évalue les performances des traitements : bande passante nécessaire, latence, récurrence de sortie et d entrée. SynDEX propose une méthodologie appelée " Adéquation Algorithme Architecture" [ref] basée sur des modèles de graphes autant pour spécifier l algorithme et l architecture matérielle, que pour décrire l implantation en termes de transformations de graphes. L outil SynDEx permet aussi de modéliser finement les communications comme elles sont évaluées à partir du graphe résultant du partitionnement (Sorel et al., 2000). La Figure 7 montre les principes de SynDEX, une utilisation classique de cet outil nécessite une intervention de l utilisateur pour spécifier l algorithme et l architecture ainsi que les contraintes. Dans notre approche, le travail de l utilisateur est remplacé par une génération automatique de ces modèles à partir de nos modèles Gaspard2. Un méta-modèle (voir Figure 8) de SynDEx a été défini dans le cadre du projet OpenEmbedd. Le concepteur modélise son modèle d application et d architecture dans l environnement Gaspard2

13 Spécification des NFP 13 Figure 7. Principes de SynDEX en utilisant Papyrus (, Papyrus UML n.d.), ces modèles sont transformés par la suite en modèles SynDEX. La méta-modélisation n étant pas supportée dans l outil Syn- DEX, un traducteur a également été développé dans la plate-forme OpenEmbedd. Il permet d obtenir des modèles dans le format supporté par l outil. Cependant, un retour de l outil SynDEx vers l environnement Gaspard2 n a pas encore été traitée et sera discutée dans la section Exemple Dans cette section, nous présentons un exemple pour illustrer notre approche.

14 14 L objet. Volume 8 n 2/2005 Figure 8. Ebauche du MM SynDEX 4.1. Downscaler Nous avons choisi l application Downscaler comme exemple pour illustrer nos travaux. Cette application consiste principalement à l application d un filtre horizontal et d un filtre vertical sur les images en entrée pour la construction des images en sortie. Les images traitées en entrée sont de taille 1920x1080 pixels et celles en sortie sont de taille 768x576 pixels. Nous avons donc un facteur d échelle horizontal de 5/2, et un facteur d échelle vertical de 15/8. Pour l application du filtre horizontal, 11 pixels de l image en entrée sont nécessaires pour le calcul des 2 pixels de l image en sortie. Ce processus correspond à une première étape qui consiste à calculer la moyenne des 6 pixels adjacents à chaque 5 pixels en entrée. Par la suite, 2 pixels sont sélectionnés en fonction d un ensemble de coefficients et critères bien définis. De façon similaire, l application du filtre vertical nécessite 21 pixels de l image en entrée pour la génération de 8 pixels de l image en sortie. Dans ce qui suit, et pour des raisons de lisibilité, nous nous contentons de mettre des ébauches de l application Downscaler modélisée.

15 Spécification des NFP Modélisation des propriétés non fonctionnelles Dans Gaspard2, le concepteur commence par modéliser l application et l architecture en utilisant le diagramme UML de structure composite. Les composants sont par la suite stéréotypés avec le profil MARTE. La Figure 9 constitue une partie du modèle d application du Downscaler. Dans Gaspard2, les tâches sont représentés par un composant qui peut être composé (Downscaler), élémentaire (FrameConstructor) ou répété (utilisation du stéréotype Shaped pour spécifier la répétition). Le composant Downscaler, par exemple, est un composant composé qui contient deux instances des composants HorizontalFilter et VerticalFilter. Les données traitées par les tâches sont sous forme de tableaux multidimensionnel et modélisés par des ports. Par exemple, pour représenter une vidéo, un tableau tridimensionnel est nécessaire : deux dimensions pour l image et une dimension pour le temps. Figure 9. application Downscaler Le stéréotype resourceusage figure sur les différentes tâches de l application. Dans la Figure 10, il est possible de voir les valeurs contenues dans les tagged values du stéréotype resourceusage. Ces valeurs sont exprimées à l aide du paquetage BasicNFP_Types qui utilise à son tour les VSL (value specification language). A titre d exemple, le temps d exécution (correspondant à exectime) est de type NFP_duration. Les attributs de NFP_Duration sont : unit : c est l unité de mesure utilisée. Dans la librairie MARTE, les différentes unités de mesure sont définies. clock : correspond au nom de l horloge.

16 16 L objet. Volume 8 n 2/2005 precision : définit le degré de raffinement de la performance de l opération de mesure. expr : expression VSL qui peut être une simple constante ou une variable. Elle peut aussi être composée de plusieurs expressions. source : précise la source des valeurs qui peuvent être estimés(estimated), calculés(calculated), requis (required) ou mesurées(measured). statq : c est un qualificatif qui indique le type statistique de la mesure d une propriété (maximum, minimum, pourcentage...) dir : indique l ordre des valeurs qui peut être croissant ou décroissant. En reprenant le même exemple du temps d exécution, pour le composant HDFrame- Generator on a : exect ime = (source = est, statq = max, expr = (usedresources == cpu1)?t 0 = (12, ms) : usedresources == (cpu2)?t 0 = (15, ms), dir = incr, clock = ClockF req, unit = ms) Ce qui traduit le fait que le temps d exécution pour cette tâche est estimé, statistiquement on prends la valeur maximale, l ordre des valeurs est croissant, le temps est calculé par rapport à l horloge ClockFreq et l unité de mesure du temps choisie est le ms. Pour la valeur, elle est donnée sous forme d expression conditionnelle ; en effet la valeur dépend de la ressource utilisée pour l exécution, si on utilise cpu1 alors la valeur est de 12 ms sinon si on utilise cpu2 alors la valeur est de 15 ms. Nous utilisons également des contraintes stéréotypées avec NfpConstraint et TimedConstraint. Le stéréotype NfpConstraint permet d imposer une restriction ou une condition aux éléments modélisés. Il supporte l utilisation d expressions textuelles ou de type VSL. Le stéréotype TimedConstraint hérite de NfpConstraint et permet d imposer des contraintes sur la valeur des instants ou de la durée par rapport à une horloge. Dans la Figure 10,On distingue la première contrainte stéréotypée TimedConstraint : (T 0[i + 1] T 0[i] < (2, ms) cette contrainte traduit la restriction sur la durée entre deux occurrences successives d un événement observé à T0 pour ne pas dépasser 2 ms. Ceci spécifie que la durée entre l arrivée des vidéos doit être inférieure à 2 ms. La deuxième contrainte stéréotypée NfpConstraint spécifie le temps d exécution par rapport à la ressource utilisée, c est la même expression qu on retrouve dans le temps d exécution Les outils d optimisation Dans cette partie, l outil (Benyamina et al., 2007) n étant pas encore au point, nous nous basons sur l outil syndex pour montrer les résultats de l optimisation. La

17 Spécification des NFP 17 Figure 10. les NFPs figure 11 illustre l application Downscaler généré en SynDEX. Comme signalé précédemment, SynDEX ne gère pas les tableaux multidimensionnels, de ce fait les ports ont été redéfini avec une seule dimension. Nous utilisons dans cet exemple une architecture simpliste à deux processeurs (Figure 12). Le résultat de l adéquation application/architecture est donné dans la Figure 13. Le temps se déroule de haut en bas avec une colonne par processeur. Chaque opération de calcul est représentée par une boite dont la hauteur est proportionnelle à la durée d exécution de l opération. La communication commence dès que l opération qui a fournit la donnée à transmettre est terminée, l opération qui a besoin de la donnée transférée commence dès que la communication est terminée. La valeur de la durée d une itération du graphe d adéquation est, quant à elle, donnée dans la fenêtre principale de SynDEX.

18 18 L objet. Volume 8 n 2/2005 Figure 11. appli syndex 5. Discussion et perspectives Dans cet article, nous avons pu faire le tour des différents points de notre approche. On constate que les différents travaux entrepris tournent autour de l IDM. Ceci est dû certainement au fait que l environnement Gaspard2 est basé sur l IDM. Ceci nous a permis alors de profiter des outils déjà mis en place pour construire nos travaux. L utilisation du profil MARTE nous a entre autres permis d enrichir les modèles Gaspard2 déjà existants avec des propriétés non fonctionnelles, sans avoir à les redéfinir. Ce qui constitue d une part un gain de temps énorme, et réduit d autre part les efforts du concepteur qui n est pas obligé de changer d environnements ou de refaire de nous modèles pour intégrer ses exigences non fonctionnelles. Personne ne pourra nier les avantages qu on tire en passant par la modélisation et la méta-modélisation,

19 Spécification des NFP 19 Figure 12. archi syndex Figure 13. association syndex

20 20 L objet. Volume 8 n 2/2005 cependant l IDM est loin d être la solution miraculeuse à tous nos problèmes. En effet, nous utilisons deux outils d optimisation ayant des modèles d entrées différents, ce qui nécessite un double travail de méta-modélisation et de transformations de modèles. Si nous optons pour un nouvel outil d optimisation, nous serons probablement dans l obligation de définir de nouveaux modèles et méta-modèles. D autre part, le retour vers l environnement Gaspard2, une fois le placement obtenu, n est point possible par simple transformation de modèles. Nous cherchons encore des solutions possibles pour résoudre ce problème. Nous envisageons aussi d orienter nos travaux vers l exploitation d architecture, ce qui passerait nécessairement par du refactoring au niveau de l architecture. 6. Conclusion Dans cet article, nous avons abordé la modélisation des propriétés non fonctionnelles dans l environnement Gaspard2 dédié à la conception de systèmes embarqués sur puce à l aide de l IDM. Gaspard2 est basé sur des chaînes de transformations de modèles de haut niveau, qui aboutissent à la génération de code et à la synthèse de matériel. Ces modèles sont décrits à l aide du profil MARTE. Pour assurer l utilisation de ces modèles avec des heuristiques de placement, nous les avons enrichi avec des contraintes et des exigences non fonctionnelles. Les propriétés non fonctionnelles sont considérées comme entités de premier ordre qui guident le raffinement des architectures des systèmes embarqués sur puces, elles aident également à justifier des choix particuliers de conception notamment en ce qui concerne l allocation des tâches aux ressources matérielles. Cependant pour guider les choix de conception, il était impérative de définir au départ une méthodologie de conception. Nous avons alors proposé une approche qui permet dans un premier temps d annoter directement des modèles de conception existants. Nous utilisons essentiellement le paquetage NFP qui a été défini pour déclarer, qualifier et annoter des propriétés non fonctionnelles sémantiquement bien formées dans des modèles UML. Ce paquetage inclut un langage de spécification des valeurs et des expressions (VSL) qui définit une syntaxe concrète textuelle et une grammaire formelle pour décrire des expressions temporelles et des expressions algébriques. Une fois le travail de modélisation achevé, nous passons vers l outil d optimisation. Nous avons choisi deux outils d optimisation qui ont des modèles d entrées

21 Spécification des NFP 21 différents. Nous avons défini des règles de transformation pour passer des modèles Gaspard2 vers des modèles SynDEX. 7. Bibliographie, Papyrus UMLn.d. Benyamina A. E. H., Boulet P., «Multi-objective Mapping for NoC Architecture», Journal of Digital Information Management, vol. 5, n 6, p , December, DaRT Team LIFL/INRIA, Lille, France, «Graphical Array Specification for Parallel and Distributed Computing (Gaspard2)», Feiler P. H., Lewis B., Vestal S., «The SAE Avionics Architecture Description Language (AADL) Standard : A Basis for Model-Based Architecture-Driven Embedded Systems Engineering», RTAS 2003 Workshop on Model-Driven Embedded Systems, May, Lee H., Lee B., Lee Y., Kang B., «Optimized VLSI Design for Enhanced Image Downscaler», Proceedings of the Second IEEE Asia Pacific Conference, Cheju, South Korea, p , Object Management Group, Inc., UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, , sep, OMG, «The UML profile for Modeling and Analysis of Real-time and Embedded systems», n.d.a. OMG, «UML Profile for Schedulability, Performance, and Time Specification», omg.org/docs/formal/ pdf, n.d.b. Project INRIA AOSTE, «SynDEx-IC Home Page», n.d. rapportsactivite/ra2005/aoste/uid43.html#uid43. Sorel Y., Lavarenne C., SynDEx Documentation Index, INRIA. inria.fr/syndex/doc/ ,