I. Introduction








télécharger 57.03 Kb.
titreI. Introduction
date de publication12.07.2017
taille57.03 Kb.
typeDocumentos
ar.21-bal.com > droit > Documentos






Projet du second semestre

Master 1 informatique de Lille 1

Sous la responsabilité de :

- Philippe Dumont

- Eric Piel
Pierre Gressier Mai 2005

SOMMAIRE

I. Introduction 4

II. Contexte 5

II.1.Ptolemy 5

I.1.1Historique 5

a)Gabriel : 1986-1991 5

b)Ptolemy classique : 1990-1997 5

c)Ptolemy II 1996 -2005 ? 6

I.1.2Description 6

II.2.Array-OL 7

II.2.1.Description 7

II.2.2. Modèle Global 7

II.2.3.Modèle local 8

II.3.Simulation de Array-OL dans Ptolemy II 9

III. Travail réalisé 9

III.1.Installation et manipulation de Array-OL dans Ptolemy II 9

III.2.Portage de AOL de Ptolemy II 3 à Ptolemy II 4 11

III.3.Gestion des tokens en linéarisant les tableaux 12

III.4.Codage de l’application FRN 14

IV. Conclusion 15


I.Introduction


Dans le cadre du master 1 informatique, un projet doit être réalisé pour valider son année. J’ai choisi le projet s’intitulant : développement d’applications pour Ptolemy II. Ce projet a pour but de connaître et comprendre l’environnement Ptolemy et le langage Array-OL. Ces derniers étant dédiés à la programmation pour l’embarqué. Après avoir présenté l’application et le module Array-OL, une présentation du travail effectué et des difficultés rencontrées sera faite.

II.Contexte


  1. Ptolemy

  1. Historique

  1. Gabriel : 1986-1991

La première génération de logiciel créé par le groupe de Berkeley fut le logiciel Gabriel, écrit en Lisp et destiné au traitement de signal. C'est durant son développement que les diagrammes de flux de données synchrone (SDF) et leurs techniques de planifications séquentielles/parallèles se sont développés.

Gabriel incluait des générateurs de code pour DSP (principalement Motorola). Il possédait aussi des co-simulateurs matériel/logiciel, ainsi que des générateurs de codes parallèles, qui produisaient du code assembleur destiné à être exécuté sur un simulateur d’architecture de multiprocesseur.

Gabriel était aussi doté d’une interface graphique utilisateur.

  1. Ptolemy classique : 1990-1997

La version Ptolemy classique, initiée conjointement par les Professeurs Edouard Lee et Dave Messerschmitt en 1990, fut été écrite dans C++. Ce fut le premier environnement de modélisation à supporter les modèles de calcul multiples combinés hiérarchiquement.

Les fonctionnalités SDF de Gabriel furent portées dans le nouvel environnement tandis que la gestion des flux de données booléen (BDF), flux de données dynamiques (DDF), flux de données synchrones multidimensionnel (MDSDF) et réseaux de processus (PN) des domaines lui étaient intégrés.

Simultanément au portage des générateurs de code DSP, Ptolemy s’est vu doté de générateur de code C et VHDL. Le concept de target a aussi été développé : une target encapsule la connaissance de matériels spécifiques des plates-formes et explicite la construction de modèles pouvant être exécutés sur des processeurs embarqués (cartes avec DSP,…).

Un domaine d'événement discret, mettant en évidence le lien entre réseaux de communication et traitement du signal, a aussi été mis au point tandis qu’un simulateur matériel, Thor, fut développé en adaptant un projet open-source du même nom.

L’équipe Ptolemy fit une contribution majeure aux techniques d’ordonnancement de SDF en introduisant le concept de « single appearance schedules » qui minimise la taille du code généré. L’équipe a aussi introduit le concept de « higher order components » qui augmente l’expressivité des syntaxes visuelles. L’interface utilisateur de Ptolemy dérive ainsi d’une extension de l’interface originelle de Gabriel.

Des parties de Ptolemy ont été commercialisées au sein de système Agilent ADS tandis que les méthodes de Ptolemy sont utilisées par Cadence dans le système SPW.

  1. Ptolemy II 1996 -2005 ?

A partir de 1996, le groupe Ptolemy a commencé à travailler sur une nouvelle version du logiciel pour étendre ses fonctionnalités : c’est le projet Ptolemy II.

Les principales raisons étaient de pouvoir bénéficier de l’intégration de fonctionnalité de réseau, de migration de code, de pouvoir supporter nativement les threads et des possibilités offertes par Java pour les interfaces utilisateurs.

Ptolemy II introduit ainsi la notion de domaine de polymorphisme (où les composants peuvent être conçus pour fonctionner dans des domaines multiples) et des modèles modaux (où des machines à états finies sont combinées hiérarchiquement avec d'autres modèles de calcul). L’équipe a aussi construit un domaine de temps continu, compatible avec la modélisation modale et hybride.

Ptolemy II possède un système de typage de données avec inférence de type et le polymorphisme de données et une sémantique très riche. Le concept de types comportementaux est alors apparu : composants et domaines peuvent avoir des définitions d'interfaces décrivant statiquement leur structure, mais aussi leur dynamique.

Certaines capacités SDF de Ptolemy classique furent portées dans cette nouvelle version, tandis que le modèle de flux de données hétérochrome fut présenté. Les équipe Ptolemy développèrent un toolkit GUI fondé sur Java, une nouvelle interface graphique, un plotter Java et un composant pour de l’animation 3D. Des modèles peuvent maintenant être intégré à des pages Web sous forme d’applets Java.

Cette version intègre aussi la notion de classes et sous-classes orientés acteurs avec héritage et inclut aussi la modélisation de systèmes sans fil. Ptolemy II s’est également vu doté de la gestion du cycle de vie des acteurs, de l’évaluation dynamique des composants « higher-order », et ajouté de nombreux domaines expérimentaux pour l’exploration du temps réel et du calcul distribué.

La génération automatique de code a, elle aussi, été revue : elle est très différente de Ptolemy classique / Gabriel. Au lieu que ce soit les composants qui génèrent le code, Ptolemy II est doté d’un framework de composants spécialisés fondé sur Java et qui utilise XML pour la persistance des données. Ptolemy II propose aussi la notion de modèles migrants.

  1. Description

Ptolemy II est un logiciel de conception graphique de systèmes de traitement du signal ou de l’image. C’est un outil de modélisation et de simulation d’application pour l’embarqué.



  1. Array-OL

  1. Description

Array-OL (Array Oriented Langage) est un langage dédié à la description d’applications de traitement du signal systématique. Ces applications manipulent de grandes quantités de données qui sont traitées par un ensemble de tâches.

Les données sont représentées dans des tableaux ; les flux de données sont eux aussi stockés sous forme de tableaux, mais avec une dimension infinie. Les tâches consomment un ou plusieurs tableaux en les découpant en « morceaux » de taille identique qui sont appelés motif. Puis à partir de ces derniers, on calcule de nouveaux motifs que l’on range dans un ou plusieurs tableaux résultats. La chaîne se poursuit, les tableaux produits sont, à leur tour, consommés.

Le langage Array-OL ne constitue pas un langage de programmation complet.

Dans le cadre du traitement de signal, ce langage n’est pas destiné à être exécuté dans une architecture dite « classique », mais dans une architecture embarquée avec des composants spécialisés.

  1. Modèle Global

Le modèle global est un graphe orienté dans lequel les sommets sont des tableaux ou des tâches et les flèches indiquent le sens de l’exécution. Chaque tâche consomme un ou plusieurs tableaux et produit à son tour un ou plusieurs tableaux résultats. Le nombre des dimensions du ou des tableaux résultats peut être différent du ou des tableaux consommés. Le nombre de dimensions des tableaux n’est pas borné et la taille des dimensions n’est pas limitée. Néanmoins, il ne peut y avoir qu’une seule dimension infinie par tableau. De plus, le graphe ne peut pas comporter de cycles.


Figure 1 : Le niveau global

  1. Modèle local

Le modèle local définit l’interaction entre les tâches et les tableaux. La façon dont la tâche consomme et produit les tableaux qui lui sont associés peut être étudiée en couple tâche – tableau. Et ceci que les tableaux soient opérandes ou résultats. Ces couples sont appelés « demi-tâche ».

Motif :

Lorsque l’on prend un couple appelé demi-tâche, la tâche va prendre un sous-ensemble du tableau et réaliser des traitements dessus. Le sous-ensemble est appelé motif. Une fois l’opération réalisée sur le motif en cours, la tâche va recommencer sur le motif suivant qui est forcément de même forme que le premier. La forme d’un motif est donc fixée pour chaque couple tâche-tableau.



Figure 2 : Deux exemples de motifs

Notion d’ajustage :

L’ajustage permet de définir la forme du motif pour chaque demi-tâche. Pour décrire la forme, il est précisé explicitement le nombre et la taille de chacune des dimensions. La matrice d’ajustage indique quels éléments du tableau vont faire parti du motif. Cette matrice définit la manière dont on passe d’un élément à un autre dans le tableau. De plus, la forme du motif n’a pas forcément le même nombre de dimensions que le tableau. En effet, le motif a au plus le même nombre de dimension que le tableau.

Notion de pavage :

Maintenant que l’on a la forme du motif, il est important de savoir comment on se déplace d’un motif à l’autre. Chaque demi-tâche possède une matrice de pavage et une référence d’origine. Pour obtenir un nouveau motif, il suffit d’itérer sur les vecteurs contenu dans cette matrice en partant de l’origine. Il est à noter que les dimensions sont thoriques.

  1. Simulation de Array-OL dans Ptolemy II

Le module Array-OL contient ses propres paquetages dans Ptolemy II. En effet, la plupart des classes de Array-OL sont intégrées comme sous paquetage dans le paquetage Ptolemy.Actor de Ptolemy II. Le module modifie également quelques fichiers de base de Ptolemy II pour permettre une intégration à part entière à l’application. Ces fichiers sont essentiellement des fichiers XML de configuration.

En outre, Array-OL ajoute un nouveau directeur à Ptolemy II. Ce directeur est le directeur d’Array-OL, c’est la seule classe java qui est ajouté par le module qui ne soit pas dans le paquetage de Ptolemy.Actor.AOLActor.

Le module Array-OL est un acteur supplémentaire qui contient un ensemble de jeu de tâches qui sont ajoutés aux autres tâches déjà contenues dans Ptolemy II.

III.Travail réalisé


  1. Installation et manipulation de Array-OL dans Ptolemy II

L’installation du plugin Array-OL dans Ptolemy a tout d’abord nécessité l’installation de Ptolemy II 3.0.2. L’installation de ce dernier peut être faite aussi bien sous Linux que sous Windows. J’ai choisi de faire cette installation sous Linux. En effet, je ne connaissais pas très bien cet environnement, cela m'a donc donné l'occasion d'approfondir mes connaissances. L’installation de Ptolemy II est très lente, puisqu’elle est en réalité une compilation de l’application, ce qui nécessite bien entendu une machine virtuelle java. Une variable PTII doit être configurée, pour que l’installation puisse se réaliser à l’aide d’un makefile. Une fois cette opération terminée, il faut installer le plugin Array-OL. Ce dernier étant un paquetage supplémentaire de Ptolemy II, il suffit de l’ajouter à l’emplacement lui correspondant dans l’arborescence de Ptolemy II. Une fois cela fait, il faut de nouveau compiler Ptolemy II. Il est à noter que cette opération peut, bien entendu, être faite avec une seule compilation de Ptolemy II si Array-OL est ajouté avant la première compilation.

Ayant à disposition quelques exemples simples de petites applications codées en Array-OL, j’ai commencé par les manipuler de façon à essayer de comprendre le fonctionnement. Ne connaissant pas Ptolemy, la compréhension n’a pas a été facile. Il me fallait comprendre le fonctionnement du langage Array-OL. Même à l’aide de deux documentations ceci n’a pas été évident. Il m’a fallu des explications complémentaires de mes responsables de projet pour que je puisse enfin comprendre le fonctionnement complet de Array-OL.

J’ai ensuite installé la version 4 de Ptolemy II : cette dernière m’a causé quelques soucis de compatibilité avec la version 3. En effet, lorsque j’installais deux versions en même temps, uniquement la dernière installée pouvait encore être lancée. Il m’a donc fallu configurer le lancement de façon à avoir plusieurs versions simultanées de Ptolemy II sur le même ordinateur. Ce problème venait du fait que l’application utilise une variable d’environnement pour se lancer qui s’appelle PTII est qui doit contenir le chemin où se trouve Ptolemy II.

  1. Portage de AOL de Ptolemy II 3 à Ptolemy II 4

Une fois la compréhension du fonctionnement de Array-OL acquise, l’étape suivante a été le portage du plugin Array-OL de la version 3 à la version 4 de Ptolemy II. En effet, Array-OL a été créé avec la version 3 de Ptolemy II et il nécessitait quelques modifications pour passer à la version 4.

Pour pouvoir réaliser cette étape, il m’a été indispensable d’installer Eclipse et de réussir à compiler Ptolemy dans ce dernier. Cette opération n’a pas été une chose aisée puisqu’elle nécessite une bonne connaissance d’Eclipse ainsi que de Ptolemy II. Heureusement, les développeurs de Ptolemy II ont travaillé dans cet environnement et un mode opératoire est disponible pour la compilation de Ptolemy II dans Eclipse. A l’aide de cette documentation, j’ai pu installer et compiler Ptolemy II 4.0.1 dans Eclipse, mais Ptolemy 3.0.2 n’a jamais compilé avec le mode opératoire donné. Ceci ne m’a pas pénalisé puisque le module Array-OL fonctionné déjà sur la version 3 et que mon travail consistait au passage vers la version 4.

Une fois Ptolemy II 4.0.1 installé et compilé dans Eclipse, le portage de Array-OL devenait plus accessible. J’ai ainsi créé quatre projets java dans Eclipse (Ptolemy II 3.0.2, Ptolemy II 3.0.2 avec le module Array-OL, Ptolemy II 4.0.1 et Ptolemy II 4.0.1 avec le module Array-OL) de façon à pouvoir plus facilement effectuer le portage.

Ptolemy II étant adapté pour tourner sous différents systèmes d’exploitation et avec des configurations différentes les unes des autres, de nombreuses classes sont inutiles lors de l’utilisation de Array-OL. De plus, ces classes provoquent des erreurs de compilation et il faut ainsi différencier les classes qui provoquent des erreurs dues au portage des classes qui provoquent des erreurs de compilation dues à l’absence d’un module de Ptolemy II. De façon à ne pas être « gêné » par ces classes qui ne m’intéressaient pas, je les ai tous simplement supprimées. Il a ainsi fallu analyser toutes les erreurs de compilation mises à jour dans Eclipse des classes qui servaient au portage de Array-OL.

Ce portage a donc consisté, dans un premier temps, à la compréhension de l’organisation des classes dans le paquetage de Array-OL dans la version 3 de Ptolemy II, de façon à comprendre d’où venaient les erreurs présentes dans la version 4. J’ai donc fait une comparaison des classes modifiées entre la version 3 et la version 4 de Ptolemy II pour situer les erreurs et ainsi pouvoir les corriger. Les problèmes venaient, pour leur majorité, de la suppression d’une classe interne à une autre de Ptolemy II dans un paquetage annexe, qui servait de parseur XML au module Array-OL.

Cette classe,  MoMLInfo, sous classe de NamedObj dans le package Ptolemy.Kernel.Util est un parser de fichier XML. La classe NamedObj comportent toutes les méthodes de manipulation des objets MoML. Le rajout de cette classe a permis le fonctionnement du module Array-OL dans la version 4 de Ptolemy II.

Pour finir ce portage, il fallait créer un fichier patch de mise à jour de la version 3 à la version 4. Cette opération a été effectuée à l’aide de la commande diff suivante :

Diff –upr –N –x *.class ptII4.0.1/ ptII4.0.1_AOL/ > ptII_AOL.patch

  1. Gestion des tokens en linéarisant les tableaux

Cette partie se concentre principalement sur le module Array-OL. Les « tableaux » qui géraient les tokens étaient en réalité des « pairs » qui contenaient une référence et le token. Le but étant ici de stocker ces tokens dans des tableaux n’ayant qu’une seule dimension. La classe de la version originale de Array-OL (MatrixMultiDimToken) contenait trois classes internes qui permettaient le codage des tokens en « pairs ». Le travail consistait donc à modifier ces trois classes pour linéariser la gestion dans un tableau avec une seule dimension. Le travail a été fait en deux phases : l’algorithme et le codage.

En ce qui concerne la première phase, en prenant exemple avec des matrices à trois dimensions, l’algorithme a été réalisé assez rapidement. Avec cet exemple en trois dimensions, la généralisation à n dimensions s’est faite sans problème.

Par contre au niveau du codage, quelques problèmes sont intervenus. Notamment à cause de la présence de deux constructeurs. Le premier prend en paramètre une IntMatrixToken et le second MatrixToken. Pour le premier le type IntMatrixToken permet de récupérer le nombre de dimension et la taille de chacune d’entre elle, donc le codage de celui-ci n’a pas été compliqué. Quant au deuxième, le type MatrixToken permet de récupérer le nombre de dimensions, mais pas la taille de chacune d’entre elles. De ce fait, le codage de ce constructeur n’a pas été possible. De plus, tous les exemples rencontrés utilisés le deuxième constructeur, donc les tests n’ont pas été possibles.

Voici un exemple de code qui concerne cet algorithme, avec le constructeur qui prend en paramètre le type IntMatrixToken. Ce constructeur récupère le nombre de dimensions et les tailles de chacune d’entre elles, de façon à pouvoir calculer la taille maximale du tableau de linéarisation :

/**

* @param vect_dim a IntMatrixToken contenant le nombre et la taille de chacune des dimensions

*/

public TabOneDim(IntMatrixToken vect_dim)

{

// Nombre de dimensions

int nbDim = vect_dim.getRowCount();

// initialisation du tableau contenant les grandeurs des dimensions

dim = new int[nbDim];

// Taille du tableau de Tokens

int tailleTab = 1;

for (int i = 0; i < nbDim; i++)

{

// On calcule la taille maximale avec toutes les dimensions

tailleTab = tailleTab * vect_dim.getElementAt(i,1);

// On récupère les tailles maximales de toutes les dimensions

dim[i] = vect_dim.getElementAt(i,1);

}

// On crée le tableau de Tokens à la taille maximale de toutes les dimensions

tab = new Token[tailleTab];

System.out.println("Tab créé avec IntMatrixToken");

}

En ce qui concerne les méthodes « put » et « get », en considérant que les informations sont récupérées par le constructeur, le codage de ces deux méthodes n’a pas causé de problème. Il s’agit d’une transformation d’un tableau à n dimensions vers un tableau n’ayant qu’une seule dimension et inversement. Cette transformation est faite avec un calcul à l’aide du nombre de dimensions et des tailles de chacune d’entre elles. Voici en exemple la méthode « put » :
/** Permet de placer le Token data dans le tableau.

* @param key InMatrixToken le vecteur de position

* @param data le Token à mettre dans le tableau

*/

public void put(IntMatrixToken key, Token data)

{

// Attributs

int pos = 0;

int tmp;

// Boucle de calcul de la position dans la tableau linéaire

for(int i = 0; i < (dim.length - 1); i++)

{

tmp = 1;

for(int j = 0; j < i; j++)

tmp = tmp * dim[j];

pos = pos + key.getElementAt(i,0) * tmp;

}

tab[pos]=data;

}

  1. Codage de l’application FRN

Le codage de cette application FRN (Frontend Radio Numérique) a été un nouvel aspect du projet. En effet, il fallait utiliser le module Array-OL en mode graphique, c'est-à-dire coder dans le langage Array-OL et non plus uniquement en java comme cela était le cas depuis le début de ce projet (lorsqu’il y avait des modifications de code à faire). Cette partie consistait à coder l’application FRN dans la version 4 de Ptolemy II en Array-OL, avec comme outil, la même application codée avec la version 2 de Ptolemy II.

Pour commencer, il me fallait ajouter les tâches qu’utilise cette application à Ptolemy II. Pour cela, il faut indiquer à Ptolemy II des les prendre en compte. Ptolemy II utilise des fichiers XML pour définir les liens avec les tâches. Il fallait donc modifier ces fichiers XML de configuration et leur ajouter l’existence des tâches qu’utilise l’application FRN.

Une fois ajouter, les classes java (qui représentent les tâches) qui sont utilisés par la FRN comportaient des erreurs, puisqu’elles étaient prévues pour compiler avec la version 2 de Ptolemy II. Ces classes se basaient sur des méthodes d’autres classes de Ptolemy II qui ont été supprimé ou modifié. Il a donc fallu analyser les problèmes de compilation de ces classes.

Ces problèmes résolus, l’application pouvait doit fonctionner dans le module Array-OL sous la version 4 de Ptolemy II.

IV. Conclusion


Ce projet m’a permis une approche des projets en entreprise où chacun s’occupe d’une partie du développement d’une application. J’ai ainsi pu apercevoir la complexité qu’apporte un projet de cette ampleur. Il m’a également permis de me rendre un peu plus compte des difficultés que l’on peut rencontrer dans la réalisation de projets à long terme et des points auxquels il faut faire attention pour mener à bien un développement. J’ai également pris conscience de la difficulté du travail seul face à un tel projet, et compris pourquoi les projets se travaillent toujours en équipe.

ANNEXES

Exemple de d’ajustage dans Array-OL :


O = (0)


Installation de Ptolemy II :

  1. Install JDK1.4.0 or later, add the jdk bin directory to your path so that javac and java are available, and have the make command available.

  2. Set the PTII environment variable to the top level Ptolemy directory, that is the directory above this directory

- bash :

PTII=c:\\Program\ Files\\Ptolemy\\Ptolemy\ II\ 2.0

export PTII

- csh :

setenv PTII /users/yourname/ptII

  1. Run configure

cd "$PTII"

rm -f config.*

. /configure

  1. Ptolemy is shipped with .class and .jar files, but the $PTII/bin/scripts needs to be updated. The safest thing to do is to run make fast install on the entire tree :

make fast install

  1. Start vergil

PTII/bin/vergil


similaire:

I. Introduction iconIntroduction générale Introduction aux ordinateurs

I. Introduction iconTD/tp 1 Introduction au sdk d’Android 1 Introduction
«*. univ-lr fr» pour éviter d’utiliser le proxy pour les adresses internes à l’ulr

I. Introduction icon1. Clique d’abord sur «Visite virtuelle Haussman» et regarde l’introduction...
«Visite virtuelle Haussman» et regarde l’introduction à la belle architecture du bâtiment

I. Introduction iconI introduction

I. Introduction iconI introduction

I. Introduction iconI. Introduction

I. Introduction iconI introduction

I. Introduction iconA. Introduction

I. Introduction iconI introduction

I. Introduction iconI. introduction








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com