Projet Ep-Atr

previous up next contents
Précédent : Logiciels Remonter : Projet EP-ATR, Environnement de programmation Suivant : Actions industrielles

Résultats nouveaux

Nos thèmes de recherche introduits en [*] ont donné lieu aux résultats décrits dans les sections suivantes :

Signal V4

 

Participants : Patricia Bournai , Thierry Gautier , Paul Le Guernic , David Nowak , Jean-Pierre Talpin


Résumé : La version nouvelle de Signal, Signal V4, est définie en coopération avec la société TNI (François Dupont), qui développe et commercialise l'environnement Sildex issu des travaux sur Signal. Une définition préliminaire avait été publiée en 1994, sans qu'un certain nombre de points soient stabilisés.


Opérateurs sur tableaux

Le principe de base adopté pour la définition d'opérateurs sur tableaux a été de se conformer strictement à la forme implicite du contrôle qui constitue une caractéristique fondamentale de Signal : il n'y a donc pas de construction explicite de boucle en Signal. De plus, le caractère «flot de données» et compositionnel du langage est préservé par les opérateurs utilisés dans des équations sur signaux de type tableau.

Deux opérateurs importants sont alors l'accès aux éléments d'un tableau :



Y := T[I$_1$,...,I$_n$]



et la définition, éventuellement partielle, de tableau :

T := (I$_1$,...,I$_n$) : Y



Dans le cas général, T est un tableau de dimension n, Y est un tableau de dimension p et les I$_i$ sont des tableaux d'entiers de dimension p. L'opérateur d'accès définit à chaque instant la valeur de ${\tt Y}(j_1,\ldots,j_p)$ par celle de ${\tt T}({\tt I_1}(j_1,\ldots,j_p),\ldots,{\tt I_n}(j_1,\ldots,j_p))$(un tableau peut être considéré comme une fonction d'un produit de domaines entiers vers un domaine quelconque). L'opérateur de définition est l'opérateur dual, mais dans lequel certains éléments peuvent être définis plusieurs fois.

En l'état actuel, tous les éléments d'un tableau ont la même horloge, cependant, un tableau peut être défini partiellement, ce qui pourrait à terme amener à considérer des horloges vectorielles. Un travail important reste à faire sur la compilation des tableaux en Signal.

Types de modules

Nous avons ajouté à la définition de Signal V4 la possibilité de spécifier des assertions utilisables comme hypothèses de compilation. Il peut être en effet nécessaire pour compiler un programme, de supposer des propriétés sur l'environnement ou sur la sémantique de certaines opérations. Les assertions devront pouvoir être prises en compte par le calcul d'horloges.

Par ailleurs, pour représenter de manière plus pratique les états d'un système de transition (traduction des Statecharts, par exemple), nous avons ajouté une notion de types énumérés dans Signal V4. Là encore, le calcul d'horloges devra pouvoir prendre en compte les relations induites par leur utilisation.

Partant des travaux sur l'abstraction de comportement d'un processus, nous avons formalisé ces abstractions en un calcul de types qui a abouti à la définition d'un système de modules pour Signal [26,34]. Un prototype a été réalisé.

Le travail de compilation de Signal V4 a permis d'intégrer d'une part les nouveaux opérateurs sur horloges, d'autre part les types externes (ce qui permet d'écrire des programmes manipulant des signaux dont les types ne sont pas définis en Signal : fenêtres graphiques, etc.). L'éditeur graphique de Signal a été adapté à Signal V4, dans une version intermédiaire dite H2-V4 permettant d'assurer une compatibilité avec les programmes existants. La mise en place d'outils nouveaux dans l'environnement Signal s'effectue désormais sur cette version.

Ordre supérieur et mobilité

 

Participants : David Nowak , Jean-Pierre Talpin


Résumé : Nous avons élaboré une sémantique des processus d'ordre supérieur qui autorise le transport de processus au moyen de signaux. Nous avons défini un cadre de la théorie des types permettant d'en vérifier les propriétés temporelles et causales.


Afin de généraliser l'approche et la démarche de programmation synchrone mise en oeuvre dans le langage Signal, nous avons élaboré une sémantique des processus d'ordre supérieur pour Signal. Cette sémantique autorise le transport de processus au moyen de signaux. Nous retrouvons dans cette proposition tous les traits de la méthodologie de programmation propre au langage Signal, un opérateur de composition qui permet une spécification progressive des systèmes. Ces travaux, tout d'abord envisagés dans le cadre de Signal, peuvent être généralisés à des calculs plus expressifs (le lambda-calcul, le join-calcul). Ces réflexions nous amènent à considérer la programmation synchrone comme une méthodologie de programmation au même titre que le typage dans les langages de programmation conventionnels.

Modèle comportemental de systèmes à objets

 

Participants : Albert Benveniste , Paul Le Guernic , Jean-Pierre Talpin


Résumé : Le langage de spécification BDL caractérise les causalités et le contrôle des composants d'une application distribuée au moyen de familles d'ordres partiels. Étant donnée une topologie de ces composants, BDL met en évidence leur confinement, leur distribution, sous la forme d'un réseau asynchrone de capsules synchrones. Les propriétés du réseau peuvent être vérifiées. Les capsules peuvent être compilées séparément. La conformité du système par rapport à sa spécification initiale peut être validée. BDL intervient dans cette démarche comme interface à l'intégration d'outils de vérification, de compilation et de test.


Le langage de spécification BDL a pour principe la caractérisation d'un modèle des causalités et du contrôle entre les composants logiciels d'une application. Ce modèle est basé sur une notion mathématique très simple : les familles d'ordres partiels. Ces ordres partiels permettent non seulement de représenter les causalités entre les actions réalisées dans l'application, mais également un modèle de l'état et du contrôle dans l'application. Étant donnée une configuration logicielle, ils peuvent être transformés afin de mettre en évidence le confinement ou la distribution des composants du système. L'ordre partiel correspondant à chaque confinement peut être compilé séparément, en faisant appel à des techniques d'optimisation de la programmation synchrone, afin de générer un talon de programme mettant en oeuvre le séquencement des interactions du composant avec son environnement. Il résulte de cette optimisation la génération d'un code cible constitué de talons de programmes, où le parallélisme et les communications exprimés dans la spécification initiale sont compilés d'une manière sécurisée et optimale. La tâche revenant au programmeur se réduit ensuite à coder les calculs élémentaires devant être effectués par les composants du système. La conformité du codage final par rapport à la spécification initiale du système peut enfin être testée dans la phase ultime de validation du logiciel. BDL intervient dans cette méthodologie de développement comme support au raffinement des spécifications successives, et comme interface à l'intégration d'outils de vérification, de compilation et de test. Il est tout autant, pour son utilisateur, un langage de spécification expressif et structuré, qu'un support de représentation intermédiaire simple permettant d'utiliser des logiciels d'analyse, de test, de vérification et d'optimisation existants.

Ce travail s'effectue en étroite collaboration avec le projet Pampa.

Format commun DC+ et multi-formalisme

 

Participants : Jean-René Beauvais , Albert Benveniste , Loïc Besnard , Thierry Gautier , Roland Houdebine , Paul Le Guernic , Sylvain Machard , Éric Rutten , Yan-Mei Talpin-Tang


Résumé : Le format DC+, issu des travaux des projets européens Synchron et Sacres, permet de représenter, par delà un langage particulier, la paradigme «flots de données synchronisés». Il constitue aussi un format concret, servant de vecteur commun de représentation, pour des programmes ou des propriétés sur lesquels on souhaite appliquer des transformations définies dans le cadre du modèle synchrone. C'est le cas notamment pour le projet Sacres (voir section [*]), où DC+ est utilisé pour représenter des programmes Signal et Statecharts, sur lesquels peuvent être appliqués des outils de vérification et de génération de code. L'interopérabilité entre Statecharts et Signal soulève des problèmes de composition de comportements différents, de non déterminisme, de communication entre entités, que nous traitons dans le cadre sémantique unifié fourni par DC+.


Une sémantique formelle de DC+ a été définie [45] dans le formalisme FSTS («Fair Synchronous Transition Systems») introduit par Amir Pnueli. La contribution de chaque équation de DC+ à la relation de transition entre un état s et son successeur possible s', s'exprime par une assertion faisant intervenir les variables de l'équation sous les formes v et v', représentant respectivement les valeurs de la variable dans s et s', et l'assertion ${\it clocked\/}(v')$ qui signifie que v' a une valeur ($v' \neq \bot$).

Toujours en utilisant le formalisme FSTS, nous avons défini une sémantique dite don't care du sous-format STS de DC+ (voir section [*]). Chaque signal u, en STS, a une horloge booléenne qui lui est associée; cette horloge est un signal, soit ${\rm clk}_u$, lui-même défini à l'horloge maîtresse, tick. Le prédicat ${\it clocked\/}(u)$ est alors équivalent à ${\rm clk}_u = {\sc t}$. La sémantique don't care est définie, sans utilisation du prédicat ${\it clocked\/}(u)$, en considérant que chaque fois que ${\rm clk}_u \neq {\sc t}$, u peut avoir une valeur quelconque, don't care. Cette sémantique est utilisée dans le projet Sacres pour définir la traduction de programmes DC+, issus de Signal ou de Statecharts, vers le format FSM, point d'entrée du model checker de Siemens.

Spécification multi-formalisme avec Statecharts et Signal


  

L'interopérabilité entre Statecharts et Signal est étudiée dans le cadre du projet Sacres sous l'angle d'une traduction des formalismes de Statemate en équations Signal ou DC+. Combiner les conceptions différentes des langages constitue le sujet de réflexion de ce travail. Par exemple, un module Statecharts au comportement réactif doit être capable d'accepter toute configuration de présence/absence de ses entrées; or si on rend possible de spécifier une partie de son comportement par un sous-module Signal, celui-ci peut introduire des contraintes sur la prise en considération ou non de la présence d'une de ces entrées. Par ailleurs, les variables de Statemate ont une valeur au départ de la réaction, qui est celle prise en compte dans toutes leurs apparitions dans des calculs; leur nouvelle valeur, le cas échéant, ne sera prise en compte qu'à la réaction suivante. Par contraste, les signaux de Signal (en particulier les événements et booléens) prennent à un instant donné une valeur qui est la solution du système des diverses équations qui s'appliquent à lui.

Des schémas de traduction des Statecharts vers DC+ ont été définis pour la version commerciale des Statecharts développée par la société i-Logix et nommée Magnum. Ces schémas couvrent l'essentiel des fonctionnalités offertes par l'outil : concurrence et hiérarchie d'automates, gestion de l'historique des sous-automates suspendus, actions complexes, static reactions, mini-spec. Ces schémas ont ensuite été utilisés pour implémenter un traducteur automatique dans le cadre du projet Sacres. Ce traducteur est interfacé avec l'outil commercial et produit du code DC+, qui peut alors être utilisé comme point d'entrée des outils construits autour de DC+ : générateur de code séquentiel ou distribué, preuves, évaluation de performances. L'accent se porte maintenant sur l'évaluation des bénéfices apportés par cette traduction. Des exemples industriels fournis par British Aerospace serviront de base à cette étude. Le code généré par les outils DC+ sera par exemple comparé à celui produit par l'outil commercial Magnum.

Propriétés dynamiques sur événements discrets

 

Participants : Michel Le Borgne , Hervé Marchand


Résumé : Nous nous sommes intéressés à deux problèmes de contrôle, le premier concernant la commande optimale avec des objectifs de contrôle de nature logique et arithmétique, et le second la commande en présence de pertes d'informations. Dans les deux cas, des solutions ont été apportées.


Deux problèmes de contrôle soulevés par les études sur la sécurité des postes de transformation électriques ont été résolus :

Le système de calcul formel Sigali a été enrichi par l'implémentation des fonctions de manipulation des ADD ainsi que des passages fonction de coût $\rightarrow$ relations algébriques. Le package TDD utilisé par Sigali s'est vu doter d'algorithmes de réordonnancement automatique des variables, qui ont considérablement augmenté ses performances. Quelques problèmes demeurent au niveau de la compatibilité entre ces réordonnancements de variables et certains algorithmes sur les ADD [33].

Génération et réduction symbolique d'automates

 



Participants : Olga Kouchnarenko , Michel Le Borgne , Paul Le Guernic , Hervé Marchand , Sophie Pinchinat


Résumé : Nous avons défini une équivalence comportementale appelée la bisimulation symbolique pour les systèmes dynamiques polynomiaux et les automates associés. Un algorithme pour le calcul de la bisimulation symbolique utilisant les techniques de vérification de l'outil Sigali est proposé. La construction de l'automate quotient modulo cette bisimulation est élaborée.


Une méthode pour la génération d'un automate fini, à partir du système d'équations polynomial produit automatiquement à la compilation des programmes Signal, a été étudiée l'année dernière. Le format d'automate nous a donné accès à de nombreux outils du package CADP (et plus précisement Open-Caesar). Un petit logiciel, qui relie le compilateur Signal à CADP, a été mis au point.

Cette année, le travail autour de cette problématique s'attache essentiellement à l'étude de la minimisation de l'automate généré. La méthode de minimisation s'inspire de [BFH$^{+}$92].

Nous sommes en train d'implanter dans l'environnement Signal, et à l'aide de la bibliothèque Open-Caesar, des méthodes de réduction par quotient et de comparaison pour des équivalences de type bisimulation. La relation de bisimulation choisie est celle de la bisimulation symbolique qui est exprimée sous forme de polynômes. Cette définition nous promet une grande souplesse par rapport aux méthodes de représentation d'états, tant au niveau de leur syntaxe que de la définition des fonctions d'équivalence d'automates et de réduction d'automates par cette bisimulation. En plus, elle permet d'appliquer ces fonctions dans le cadre de la technologie symbolique TDD et BDD.

Les développements logiciels sont basés sur des formats communs de représentation de systèmes, permettant la conception et l'ajout rapide de nouveaux modules de vérification.

Ces travaux sont conduits notamment dans le cadre du projet européen Syrf (voir section [*]).

Préemption dans les langages réactifs



Participants : Sophie Pinchinat , Éric Rutten


 

Résumé : Cette étude, menée avec R.K. Shyamasundar, du TIFR à Bombay (Inde), poursuit nos travaux sur un cadre unifié pour la spécification de la sémantique des primitives de préemption dans les langages réactifs.


Ce travail a commencé par l'étude de la préemption dans les langages Signal et Esterel, ce qui a mené à la définition de l'algèbre de processus PAL (Process Algebra Language). La définition de PAL est telle qu'elle contient Signal et Esterel. Des traductions des noyaux de chacun des langages dans PAL sont proposées, et la preuve de leur correction est en cours, vis-à-vis d'un critère d'équivalence fondé sur la bisimulation. On s'attend à pouvoir intégrer à ce cadre des langages comme Lustre (d'une façon proche de Signal) et Argos (d'une façon proche d'Esterel).

Le cadre de l'algèbre PAL conduit naturellement à étudier les propriétés de minimalité du jeu d'opérateurs qui y sont introduits, autrement dit les propriétés d'expressivité de ces opérateurs les uns par rapport aux autres.

Nous avons proposé un cadre formel basé sur les systèmes de sémantiques opérationnelles structurelles pour caractériser les opérateurs de préemption, et identifier les sous-classes d'opérateurs d'interruption et de suspension pour lesquelles nous avons établi des résultats d'expressivité comparée (par transformation des systèmes). À notre connaissance, des travaux de nature aussi générale sur les primitives de préemption n'ont encore jamais été abordés.

Transformations affines d'horloges

 

Participants : Thierry Gautier , Paul Le Guernic , Irina Smarandache , Sanjay Rajopadhye (projet Api)


Résumé : Dans le cadre de l'action Cairn (voir section [*]), et afin de permettre un meilleur interfaçage entre structures régulières (Alpha) et irrégulières (Signal), nous avons défini en Signal des transformations affines, qui introduisent des relations nouvelles sur les variables d'horloges d'un programme. Les propriétés des relations affines peuvent être exploitées pour la vérification de contraintes de synchronisation entre horloges qui ne pouvaient pas être vérifiées par le calcul d'horloges existant (calcul booléen).


Une transformation affine de paramètres entiers strictement positifs ${\it ( n,\varphi, d )}$ appliquée à l'horloge ${\it h_1}$ va induire une horloge ${\it h_2}$ en insérant ${\it (n - 1)}$ instants fictifs entre deux instants successifs de ${\it h_1}$, puis en prenant chaque ${\it d^{eme}}$ instant à partir de l'instant ${\it \varphi}$. Le positionnement relatif des instants appartenant aux horloges ${\it h_1}$ et ${\it h_2}$ définit une relation affine ${\it ( n,\varphi, d )}$ que l'on notera ${\it h_2 {=} {${(h_1)}_{(n, \varphi, d)}$}}$.De manière plus générale, dans la relation affine ${\it ( n, \varphi, d )}$,${\it \varphi}$ peut être un entier arbitraire.

En Signal, la vérification de contraintes de synchronisation entre deux horloges ${\it h_1}$ et ${\it h_2}$ est équivalente à la vérification de leur synchronisabilité : les horloges ${\it h_1}$ et ${\it h_2}$ sont synchronisables dans un processus P s'il existe un flot dans P dans lequel les instants de $h_1$ et $h_2$ coïncident. Afin d'accroître la puissance du calcul d'horloges, nous avons mis en évidence de nouvelles règles de synchronisabilité basées sur les propriétés des relations affines. Ces propriétés sont déduites d'un calcul sur les valeurs des triplets ${\it ( n, \varphi, d )}$ associés aux relations affines. Nous avons ainsi pu obtenir des conditions nécessaires et suffisantes sur les valeurs des triplets ${\it ( n, \varphi, d )}$ et ${\it ( n', \varphi', d' )}$pour que les horloges ${(h_u)}_{(n, \varphi, d)}$ et ${(h_u)}_{(n', \varphi', d')}$ soient synchronisables. Ce résultat est basé sur l'existence d'une forme canonique d'une relation affine ${\it ( n, \varphi, d )}$entre deux horloges [28,35].

Nous avons mis en oeuvre une représentation des horloges en relation affine compatible avec la représentation actuelle des horloges. Nous avons implémenté un premier ensemble de règles de synchronisabilité pour des horloges sous-échantillonnages affines sur une horloge h (${(h)}_{(n, \varphi, d)}$ avec n=1 et $\varphi\ge 0$) et des horloges définies comme union ou intersection de telles horloges. Cela constitue un point de départ vers l'utilisation de techniques de manipulation de polyèdres.

Cette mise en oeuvre nous a d'ores et déjà permis d'expérimenter, sur une application de codage d'images (34 Mbits/s), un interfaçage de niveau fin entre Signal et Alpha.

Mises en oeuvre distribuées

 

Participants : Albert Benveniste , Paul Le Guernic , Sylvain Machard , Éric Rutten


Résumé : La génération de code distribué pour les programmes synchrones pose deux grands types de difficultés. 1/ La compilation directe de code C (ou, plus généralement, de code séquentiel) n'est pas compatible avec une recomposition ultérieure avec d'autres modules. En d'autres termes, on ne peut pas compiler séparément (du moins de façon brutale) des programmes synchrones. 2/ Une architecture distribuée ne s'accomode pas, en général, de l'hypothèse de synchronisme parfait qui correspond au modèle de la programmation synchrone. Pour le premier problème, nous avons proposé une notion de «tâche atomique» qui constitue le grain maximal autorisant une compilation séparée avec réutilisation possible dans tout contexte. Pour le second problème, nous avons proposé la propriété d'endochronie pour un programme synchrone, qui garantit que ce composant peut être distribué en s'appuyant uniquement sur les services d'une communication de type ``send/receive'' fiable.

Sur ces bases, une méthodologie est en cours de développement pour la génération de code distribué [12], qui implique : 1/ la spécification par l'utilisateur, au niveau du programme source, de la répartition du programme, 2/ l'application de transformations automatisées du code intermédiaire, qui contrôle la correction du partitionnement, 3/ la génération du code distribué correspondant aux différents processus et à leurs communications.


Critères pour la distribution de programmes synchrones

La particularité du modèle synchrone (qui fait aussi sa souplesse) est la possibilité pour le contrôle, lors d'une réaction, de prendre des décisions sur la base de l'absence de tel ou tel événement. Ceci est évidemment impossible en univers distribué de nature asynchrone, où la notion de réaction n'existe pas (à moins de distribuer une horloge globale). Nous avons mis en évidence une classe de programmes, dits endochrones, dont aucune décision de contrôle ne nécessite de tester l'absence de signaux dans l'environnement. Ces programmes peuvent être aisément utilisés en tant que modules dans une exécution répartie. De plus, le compilateur Signal sait trouver des conditions suffisantes fines garantissant cette propriété.

Lorsqu'un module n'est pas endochrone, on sait le rendre endochrone en lui rajoutant un petit moniteur, spécifié en Signal. Ceci revient à attacher au module le protocole dont il a besoin, préalablement à toute répartition. Encore une fois, dans les cas standards (il y a des cas qui ne le sont pas), ceci est pris en charge par le compilateur.

Tâches atomiques précompilables

Les programmes qui sont mono-horloge et dont toutes les sorties dépendent de toutes les entrées s'exécutent naturellement selon le schéma 1/ lire les entrées, 2/ calculer la réaction, 3/ produire les sorties. Et il n'y a pas d'autre schéma envisageable. Ces programmes peuvent être compilés séparément : une fois les entrées lues, on est armé pour calculer la réaction, on peut le faire en toute tranquillité et dans n'importe quel ordre. On peut donc compiler de tels modules en code séquentiel et les conserver tels quels. Cette remarque se généralise au cas multi-horloge, et aboutit à la notion de tâche atomique. Ainsi, on augmente en général considérablement le grain des actions qu'un scheduler doit gérer à l'éxécution, contribuant à la simplification du scheduler.

Modèle abstrait de programme réparti

Ce modèle abstrait se présente donc sous la forme d'un ensemble de tâches atomiques, ordonnancées par un scheduler. Les tâches atomiques sont endochrones par construction, il reste à s'assurer que le scheduler l'est aussi, ainsi que les modules résultant de son partitionnement. on suppose, pour simplifier, que les tâches atomiques ne sont pas partitionnées. Dans le cas contraire, on synthétise les petits moniteurs additionnels. On dispose ainsi d'un modèle abstrait de programme réparti, équivalent au source, et dont les communications sont conformes au modèle asynchrone de communication send/receive. Dans ce modèle abstrait, on notera que, grâce aux propriétés de la composition synchrone de programmes, on peut répliquer certains calculs sur des processeurs différents, afin de minimiser les communications ou de faciliter l'obtention de l'endochronie.

Il reste alors à :

Cette approche est développée au sein des projets Esprit Sacres et Syrf, et est présentée dans [21,31].

Synthèse de circuits et conception de systèmes matériels/logiciels

 

Participants : Michel Allemand , Patricia Bournai , Apostolos Kountouris , Paul Le Guernic , Jean-Christophe Le Lann , Christophe Wolinski , François Bodin (projet Caps)


Résumé : Les performances finales d'un système temps réel dépendent fortement d'optimisations et de choix d'implémentation à bas niveau Il est donc indispensable de ne pas négliger cet aspect de la problématique, et de chercher à préserver les qualités de la spécification initiale. Nous présentons ici deux axes de recherche : la synthèse de circuits et la conception conjointe matériel/logiciel.


Prototypage et synthèse de circuits

L'exploration du modèle synchrone pour le prototypage rapide et sûr d'architectures s'est poursuivie cette année dans différentes directions.

Ceci a été rendu possible par l'élaboration d'une méthode de traduction directe de programmes Signal en netlist VHDL, où chaque processus de base trouve son équivalent dans une bibliothèque de macro-cellules [25]. Quelques expériences de synthèse menées autour d'un générateur automatique ont été présentées à notre partenaire industriel (Motorola, Austin), et se sont révélées particulièrement non prohibitives en termes de coût matériel [30]. Un autre prototype génère un code VHDL comportemental qui optimise le travail ultérieur des outils de synthèse logique (utilisation de don't care en cas d'absence d'une horloge) [23]. Ces études trouvent aussi leur application dans le cadre du projet Cairn (voir section [*]).

Ceci permet de donner à Signal un vrai statut de langage de description comportemental de haut niveau. Ses avantages sont multiples. Le premier de ces avantages réside dans la sémantique bien définie du langage, qui permet d'envisager la synthèse comme un ensemble de transformations prouvées formellement. Cette tâche est désormais incontournable à plusieurs titres : elle permet de gérer sans encombre une complexité sans cesse croissante, inhérente aux classes de circuits ou systèmes étudiés (Asics, DSP, FPGA...) et d'éviter des retours en arrière laborieux lors du cycle de conception du produit; elle possède également l'avantage de réduire le temps de certification d'un produit.

La synthèse comportementale connaît également de nouvelles tendances et exigences auxquelles Signal et l'approche synchrone semblent répondre. Il en est ainsi par exemple de la reconnaissance à haut niveau de caractéristiques d'activités temporelles de partitions de circuits : reconnaissance d'exclusivité d'utilisation d'opérateurs aussi bien pour le partage de ressources que pour la prédictabilité ou la minimisation de puissance des circuits. Le calcul d'horloges de Signal correspond bien à de telles exigences. Une approche au niveau transistor a d'ores et déjà été esquissée.

Nous parions donc sur ces travaux engagés pour exhiber plus clairement le rôle que Signal peut tenir concernant la modélisation de composants disponibles sur le marché et leur intégration dans des descriptions concrètes. Ceci sous-tend une exploration des niveaux sub-RTL : modélisation des délais et contraintes de synchronisation (set-up, hold) notamment.

Conception conjointe de systèmes matériels/logiciels

La conception conjointe de systèmes matériels/logiciels est, dans le cas général, très complexe. Elle est composée de plusieurs activités qui, dans la phase finale, devraient nous permettre de construire un système sûr, satisfaisant les fonctionnalités demandées et les contraintes imposées comme le temps de réponse, le débit, le coût, la consommation d'énergie, la taille de la mémoire, etc. Dans le contexte de construction de tels systèmes, plusieurs axes ont été particulièrement étudiés :

Dans le cadre du premier thème, nous avons poursuivi notre étude concernant la conception et le développement d'outils assurant la partitionnement et l'ordonnancement des tâches sur le système hétérogène imposé. Nous avons développé un nouvel algorithme qui est une extension du DLS (Dynamic Level Scheduling) pour le cas d'un graphe dynamique. Il permet d'intégrer, entre autres, la connaissance des exclusivités des tâches et ainsi améliore l'ordonnancement. Un logiciel spécifique a été développé en Java; il comprend un module de manipulation et de visualisation d'un graphe dynamique ordonnancé.

Dans le deuxième thème, nous avons étudié différents types d'optimisation (que l'on peut réaliser, soit directement par la transformation du graphe, soit par la manipulation de la représentation des données) et leur influence sur la taille et la performance du code généré. Les optimisations que nous avons étudiées sont les suivantes :

Une maquette logicielle a été développée en Java pour générer le code C et le code VHDL. Les résultats obtenus prouvent la nécessité de tels types d'optimisation.

Dans le troisième thème, les travaux sur la génération de simulateurs modélisant les aspects temporels d'exécution des applications écrites en Signal, sur une architecture choisie, ont été poursuivis. Ces travaux ont donné lieu au développement de méthodes et outils automatiques pour l'évaluation de performances en fonction des choix architecturaux d'implémentation (i.e. répartition, communications, ordonnancement, implémentation matérielle ou logicielle, etc.).

Techniques d'algèbre MaxPlus pour l'évaluation de performances

 

Participants : Albert Benveniste , Claude Jard (projet Pampa), Stéphane Gaubert (projet Meta2, Rocquencourt)


évaluation de performance: technique permettant l'analyse du comportement temporel (au sens du temps réel) d'un programme sur une architecture.
automate temporisé: modèle consistant à affecter des spécifications de comportement temporel aux actions situées sur les transitions d'un automate.
algèbre MaxPlus: algèbre linéaire construite sur le semi-anneau (Z,max,+), elle est adaptée à la manipulation formelle pour les modèles d'évaluation de performance.

Résumé : Grâce au travail conduit au sein du projet EP-ATR par A. Kountouris et P. Le Guernic, nous disposons d'une technique permettant d'associer, à tout couple constitué d'un programme Signal et d'une architecture support (également spécifiée en Signal), un autre programme Signal modélisant la consommation de temps par ce programme s'exécutant sur l'architecture considérée. Restait à développer une technique symbolique permettant le raisonnement sur ce type de modèle. Nous avons développé une extension des techniques d'algèbre MaxPlus, promues et étudiées au sein du groupe du même nom (G. Cohen, J-P. Quadrat, F. Baccelli, S. Gaubert), permettant de couvrir le cas qui nous intéressait. Dans cette algèbre, la manipulation symbolique de modèles d'évaluation de performance de programmes Signal se présente comme un problème d'algèbre linéaire, avec toutefois des spécificités dues aux particularités du semi-anneau ``MaxPlus''. Outre l'objectif visé, cette algèbre permet de modéliser les Réseaux de Petri temporisés généraux.


Le point de départ est le modèle de calcul de la figure [*].

   Figure: Calcul: $\forall n ~y_n=y_{n-1}+u_n$, modélisé par un automate de graphes. Le premier diagramme montre une abstraction du calcul $\forall n\,:y_n=y_{n-1}+u_n$ sous la forme d'une chaîne infinie de graphes de dépendance. Dans le second diagramme, les petites pastilles représentent des «épingles», qui permettent de recoller chaque tranche de graphe aux tranches précédente et suivante, ce qui donne une notion de concaténation. Cette notion est utilisée dans le troisième diagramme pour construire le «langage» $a^\omega$, où a est le symbole constitué du graphe figurant sur l'unique transition de cet automate.

\begin{figure}\centerline{\psfig {figure=u+y-pin.eps,width=12cm}}\end{figure}


Les programmes Signal permettent en fait de décrire des calculs qui changent dynamiquement en fonction de l'état logique du programme. Le modèle prototype est donc celui du troisième diagramme de la figure [*], mais avec un automate fini et un alphabet de graphes permettant d'étiqueter les transitions. Le modèle en question est équivalent à celui des graphes de dépendance étiquetés par des horloges. La figure [*] en montre un exemple, avec le graphe infini obtenu par dépliage.


   Figure: Un automate de graphes. Le diagramme en haut à gauche montre l'automate. Ses transitions sont étiquetées par les graphes A,B,C, et la concaténation se fait comme à la figure précédente. On vérifie que le dépliage de cet automate donne bien le graphe infini en bas à gauche -- le symbole $\ast$ est l'opérateur «étoile» des langages réguliers.

\begin{figure}\centerline{\psfig {figure=automaton.eps,width=11cm}}\end{figure}


Le diagramme de la figure [*] montre la représentation graphique, dans notre algèbre MaxPlus, du modèle de la figure [*].


   Figure: Représentation graphique des équations de point fixe satisfaites par le modèle MaxPlus correspondant à l'automate de graphe de la figure [*]. Chaque rond code, à l'aide d'une série formelle dans une algèbre adaptée (résultat de nos travaux), les dates au plus tôt d'occurrences successives de X et Ydans les états $S_1$ et $S_2$ de l'automate. La confluence de flèches vers un rond indique que les dates sont des ``max'' des dates des ronds origines des flèches correspondantes, augmentées de $\delta_{{\tt X}}$ (resp. $\delta_{{\tt Y}}$) lorsque l'action A,B ou C est effectuée. L'utilisation du temps multiforme $\delta_{{\tt X}}$, $\delta_{{\tt Y}}$ permet de différentier le coût d'une même action selon qu'il s'agit de X ou de Y. On code ainsi une équation de point fixe dont la solution fournit une représentation des dates d'occurrence. La technique consiste alors à effectuer tous les raisonnements sur ce type de diagramme.

\begin{figure}\centerline{\psfig {figure=flow-graph-multi.eps,width=8cm}}\end{figure}


Il existe d'autres représentations, plus compactes, sous la forme d'expressions régulières -- tandis que la figure [*] est une représentation avec états explicites.

Expérimentation de synthèse d'automatismes

 

Participants : Patricia Bournai , Michel Le Borgne , Paul Le Guernic , Hervé Marchand


Résumé : Un prototype pour le développement d'automatismes a été réalisé. Cet environnement permet de décrire en Signal les processus à contrôler et les objectifs de commande. Un simulateur permet ensuite de visualiser l'exécution du programme.


Dans le cadre de notre collaboration avec EDF (voir section [*]), nous avons réalisé un prototype d'environnement de développement assisté d'automatismes discrets/continus [13,32,36]. Cet environnement permet la spécification en Signal des processus à contrôler, des objectifs de commande et/ou des propriétés à vérifier. Dans ce but, l'intégration dans Signal de fonctions externes «Sigali» permettant d'exprimer des objectifs de vérification au niveau source a maintenant été étendue aux objectifs de contrôle classiques tels que l'invariance, l'accessibilité et l'attractivité. Il est également possible de simuler le système contrôlé, le simulateur étant généré automatiquement. Les contrôleurs calculés par le module de calcul formel Sigali étant sous forme équationnelle, le simulateur comporte un résolveur d'équations proposant des choix de commandes cohérents avec les objectifs. L'utilisateur peut alors exprimer ses choix à travers une interface graphique, soit en désignant les commandes, soit de façon aléatoire; il existe d'autre part deux modes de fonctionnement : mode pas à pas et mode continu.

Applications en robotique, images et contrôle

 



Participants : Jean-René Beauvais , Fernando Jimenez-Fraustro , Hervé Marchand , Éric Rutten , François Chaumette (projet Temis), Stéphane Donikian (projet Siames), Éric Marchand (projet Temis)


intégration: caractère d'un environnement dans lequel différents outils, mettant en oeuvre différentes fonctionnalités, sont connectés de telle façon que le passage de l'un à l'autre au cours du développement d'une application ne nécessite pas l'intervention de l'utilisateur. Une façon de faire est d'utiliser un format de modélisation, commun à tous les outils, qui soit le support de l'échange entre eux de modèles de l'application à différents stades d'avancement.

Résumé : Les expérimentations auxquelles nous nous livrons, dans le cadre de collaborations tant à l'intérieur qu'à l'extérieur de l'Institut, visent à valider les concepts et le fonctionnement de nos outils. Les domaines d'application des travaux du projet comprennent le traitement du signal (continu échantillonné) comme le contrôle discret au sens de commutation entre modes continus. Nous étudions particulièrement dans nos expérimentations le caractère intégré de notre environnement. Cette intégration est importante, tant au niveau de la spécification de systèmes hybrides (mêlant plusieurs types de langages), qu'à celui du développement (faisant intervenir une variété d'outils de vérification et de mise en oeuvre).



previous up next contents Précédent : Logiciels Remonter : Projet EP-ATR, Environnement de programmation Suivant : Actions industrielles