Modélisation en langage VHDL-AMS des systèmes pluridisciplinaires

Modélisation en langage VHDL-AMS des systèmes pluridisciplinaires

CREATION ET TRANSFORMATION DE MODELE 

Au cours du premier chapitre, nous avons montré que notre problématique de modélisation système basée sur l’application de la norme VHDL-AMS, s’insérait parfaitement dans un processus de conception guidé par les modèles. Nous avons retenu comme norme de l’ingénierie système l’EIA-632, avec pour volonté de s’appuyer sur les recommandations de l’OMG en Ingénierie guidée par les Modèles (MDA/MDE). Dans ce contexte, notre proposition a été d’utiliser le VHDL-AMS comme le langage de modélisation et de simulation de la solution physique, au sens des recommandations de l’EIA-632. Dans cette optique, nous avons montré qu’il y avait des avantages fondamentaux très attractifs de pouvoir cosimuler directement des systèmes mixtes (numérique-analogique) et accueillir des modélisations de disciplines différentes : Electrique, Electronique, Thermique, Mécanique, Fluidique. Cette aptitude peut être étendue par des techniques de cosimulation outils (cas de Cosimate 287H[Cos06] avec l’utilisation d’un bus de données) mettant en relation dynamique des simulateurs mettant en jeu des modèles écrits dans des langages différents (entre deux outils différents comme par exemple SystemVision 28H[Sys50] et Matlab/Simulink 289H[Mat] ou au sein d’un même outil comme SeamLess 290H[Sea] avec une cosimulation VHDL et C). Cependant nous n’aborderons pas dans ce travail de thèse l’utilisation du langage VHDL-AMS comme héritier du travail de modélisation amont, réalisé pour l’établissement de la solution logique en conception système selon l’EIA-632. Nous rappellerons néanmoins que les résultats obtenus par des travaux récents 291H[Ham05] 29H[Mau05] 54F[Gui03] 5F[Alb05], ont montré que dans la plateforme HiLeS 293H[Ham05], qui propose une solution logique dans un formalisme à base de réseaux de Petri, la traduction automatique du système de commande en VHDL-AMS, pouvait être réalisée de différentes façons. Il nous reste donc à montrer que le VHDL-AMS peut être un langage cible pour d’autres sources de modélisation, c’est-à-dire soit par modélisation directe, soit par modélisation en appliquant des règles de transformations à partir de modèles d’ores et déjà créés dans un autre cadre. Si les modèles sont les principaux acteurs du processus MDA 294H[MDA], la transformation de modèle en est le mécanisme principal 56F[MCV05]. Il convient tout d’abord de définir les principales caractéristiques et les différents langages et outils qui supportent ces transformations. Cela va nous permettre grâce à cette taxonomie et cette présentation des différentes techniques de transformation, de choisir la transformation de modèle la plus adéquate à nos besoins. C’est l’objectif de ce chapitre qui : ƒ Précisera de façon plus approfondie la notion de Transformation de Modèles, ƒ Etablira le meta modèle du formalisme VHDL-AMS, ƒ Explorera les transformations de modèles au niveau meta modèle. 

Taxonomie des Transformations de Modèles

 Dans l’optique de décider quelle approche de transformation de modèle est la plus adaptée pour répondre à notre problème, nous allons tout d’abord nous intéresser aux différents types de transformations de modèle existants, pour ensuite en faire ressortir  Méta Modèle Modèle Source Modèle Cible conforme à conforme à Transformation les différentes caractéristiques et propriétés principales qui seront pour nous des critères de choix pour les transformations de modèle vers le modèle VHDL-AMS cible. 

Types de Transformations 

Les différents types de transformations que l’on peut rencontrer, dépendent de ce que l’on a en entrée et de ce que l’on souhaite obtenir en sortie. Dans la référence 295H[MCV05], est tout d’abord précisé que, suivant que l’entité en entrée est un programme (code source, code machine) ou un modèle, on utilise le terme de transformation de programme ou transformation de modèle. Néanmoins, la transformation de modèle englobe la transformation de programme étant donné qu’un modèle peut avoir plusieurs niveaux d’abstraction pouvant aller d’un modèle d’analyse abstrait (en passant par un modèle plus concret de conception) pour aller vers un modèle très concret de code source. Ainsi les transformations de modèle incluent aussi les transformations entre des modèles de niveaux d’abstraction différents (design vers code ou code vers design dans le cas d’un projet de reverse engineering). 

Transformation endogène et exogène

 Dans le contexte de transformation de modèles, ceux-ci peuvent être exprimés par le biais de langages de modélisation (par exemple en UML ou en VHDL-AMS pour des modèles de conception, ou en assembleur pour des modèles de code source). La syntaxe et la sémantique des langages de modélisation sont exprimées par un méta modèle, concept défini dans l’introduction générale qui sera approfondi au cours du paragraphe 296H2.3. Prenant en compte ces langages de modélisation dans lesquels les modèles source et cible de la transformation sont exprimés, une première distinction doit être précisée entre les transformations endogènes et exogènes. Les transformations endogènes mettent en jeu des modèles exprimés dans un même langage (possédant donc le même méta modèle). La  Figure 22 représente ce type de transformation avec un modèle d’entrée et de sortie conformes à un même méta modèle. Figure 24 : Principe de la Transformation de Modèle Endogène Chapitre 2 : Création et Transformation de Modèle – 45 – Méta Modèle Source Modèle Source Modèle Cible Conforme à Conforme à Transformation Méta Modèle Cible Il peut ainsi s’agir : ƒ D’une optimisation : la transformation a pour but d’améliorer par exemple la qualité d’exécution (en terme de performance) du modèle, tout en préservant la sémantique du modèle, ƒ D’une restructuration : la transformation entraine un changement de la structure interne du modèle afin d’améliorer la qualité de certaines caractéristiques comme la modularité et la réutilisation, sans modifier le comportement du modèle, ƒ D’une simplification : la transformation va permettre de simplifier la complexité de la syntaxe du modèle. La transformation exogène, quant à elle, met en jeu des modèles exprimés dans des langages différents. La 298H dépeint ce type de transformation avec les modèles d’entrée et de sortie ayant des meta modèles différents. Figure 25 : Principe de la Transformation de Modèle Exogène Comme pour la transformation endogène, on peut citer plusieurs exemples de transformation exogène : ƒ La migration : la transformation d’un modèle écrit dans un certain langage en un modèle écrit dans un autre langage, tout en gardant le même niveau d’abstraction. ƒ La synthèse : la transformation d’un modèle de haut niveau, très abstrait (spécification, modèle fonctionnel) vers un modèle de bas niveau plus concret (code généré, exécutable). ƒ Le « reverse engineering » : il s’agit d’une transformation de synthèse inverse qui permet d’extraire des spécifications de haut niveau d’un modèle de bas niveau. 

 Transformation horizontale et verticale

Une deuxième distinction importante est faite entre les transformations. Elle se base cette fois-ci sur les niveaux d’abstraction des modèles sources vis-à-vis des modèles cibles. Il s’agit des transformations horizontales et verticales. Une transformation horizontale présente des modèles sources et cibles ayant le même niveau d’abstraction. La 29HFigure 24 dépeint ce type de transformation en représentant la fusion de deux modèles de même niveau d’abstraction afin d’obtenir un troisième modèle.