7.3 Transformation de modèle entre SGridML et CosiML
7.3.2 Génération d’un modèle de cosimulation CosiML
La génération d’un modèle de cosimulation CosiML requiert un modèle de comportement SGridML, un modèle de catalogue CatalogML et un modèle d’allocation AllocationML. La figure 7.4illustre les
Chapitre 7. L’architecture fonctionnelle au service de la simulation d’un Smart Grid
liens de dépendance entre ces différents modèles.
Figure 7.4 – Modèles nécessaires à la génération du modèle CosiML, et liens de dépendance
Certaines règles de transformation sont simples : les unités de simulation du modèle de catalogue liées par le modèle d’allocation sont copiées dans le modèle de cosimulation, de même pour la configuration de la cosimulation sélectionnée. Mais les règles de génération de ports et de liens sont plus complexes car elles demandent de nombreux parcours des modèles, et des conditions particulières de génération. Le principe est le suivant. À partir d’un élément SGridML::Connection du modèle de comportement : 1. Cette connection est liée à un SGridML::Input et un SGridML::Output, que nous appelons res- pectivement In et Out. Pour chacun, nous identifions son élément conteneur SGridML::Function,
que nous nommons Fin, Fout. Cette connexion peut être éventuellement liée à un SGridML::Transmission,
que nous appelons T .
2. Ces SGridML::SimulationBehaviors peuvent être alloués sur des unités de simulation. Ainsi, chaque connexion peut concerner entre 0 et trois unités de simulations CosiML::Simulation- Units. Nous les appelons A, B et C. Nous considèrons une quatrième pseudo-unité de simulation ∅ pour signifier qu’un SGridML::SimulationBehavior n’a pas été alloué.
3. Selon les possibilités d’allocation de ces trois SGridML::SimulationBehaviors sur ces quatre CosiML::SimulationUnits, entre zéro et deux CosiML::Ports et entre zéro et deux CosiML::Links peuvent être générés dans le modèle CosiML.
Dans le cas où T est “alloué” sur ∅ nous considérons que la connexion a une transmission instantanée. Mais nous décidons d’interdire les cas où Fin ou Fout ne sont pas alloués (la connexion est ignorée). Pour chaque élément SGridML::Connection, le tableau7.1montre, pour chaque possibilité d’allocation retenue de Fin, Fout et T sur A, B, C et ∅, les éléments à générer dans le modèle de sortie CosiML. Nous utilisons la notation suivante pour les ports et les liens devant être générés :
7.4. Conclusion du chapitre
pas alloué. Nous écrivons ∈ ∅ pour T dans les cas où T n’est pas alloué, ou qu’il n’existe pas (la connexion n’est reliée à aucun SGridML::Transmission).
— −−→Out et ←In représentent respectivement un CosiML::Output et un CosiML::Input transformé− à partir de In et Out (respectivement). −−−−−−→Out − In représente un CosiML::Output transformé à partir du couple (In, Out).
— A → B représente un CosiML::Link généré entre les ports de sortie générés de A et ceux d’entrée de B.
— Nous ne représentons pas le CosiML:Port supplémentaire de synchronisation généré dans le cas d’un signal discret, car ils suivent les même règles de création et de connexion que le CosiML::Port d’information.
Éléments d’entrée Éléments générés
Unités liées à
Connection SimulationBehavior Port Link
FOut FIn T A B C A ∈ A ∈ A ∈ A - - - - A, ∅ ∈ A ∈ A ∈ ∅ - - - - A, B ∈ A ∈ B ∈ B −−→Out ←In− - A → B ∈ A ∈ B ∈ A −−→Out ←In− - A → B ∈ A ∈ A ∈ B −−→ Out←− In −−−−−−→ Out − In←−−−−−− Out − In - A → B → A A, B, ∅ ∈ A ∈ B ∈ ∅ −−→Out ←In− - A → B A, B, C ∈ A ∈ B ∈ C −−→Out ←In− −−−−−−→ Out − In←−−−−−− Out − In A → C → B Table 7.1 – Les différentes possibilités de transformation d’un élément Connection vers des éléments Port et Link
La figure 7.5 montre une extraction d’une composition des modèles d’entrée, correspondant au cas de la dernière ligne du tableau7.1. La figure7.6 montre un extrait du modèle de sortie correspondant aux éléments générés dans ce même cas.
Nous implémentons ces règles de transformation dans un script Acceleo.
7.4
Conclusion du chapitre
Nous présentons dans ce chapitre un nouveau DSL, SGridML, créé pour lister les comportements de simulation devant être modélisés pour simuler un Smart Grid. Nous comparons son objectif à celui d’un langage d’architecture fonctionnelle en conception de système, en définissant le système comme étant les artéfacts de simulation (scénario de cosimulation, modèles et unités de simulation). La particularité de ce langage est notamment de distinguer deux types de comportement de simulation : les comportements fonctionnels et les comportements de transmission.
Chapitre 7. L’architecture fonctionnelle au service de la simulation d’un Smart Grid
Figure 7.5 – Exemple de connexion impliquée dans trois unités de simulation
7.4. Conclusion du chapitre
moins, nous justifions son intérêt dans notre démarche par le développement d’une transformation de modèles, qui permet de générer automatiquement un modèle CosiML. Cette transformation se base sur deux autres langages créés en plus de SGridML : CatalogML et AllocationML. En plus de fournir un support de validation de contraintes de cohérence grâce à des règles sémantiques, l’utilisation de ces langages ainsi que la transformation de modèles apportent un nouveau gain de temps dans l’application de notre démarche de cosimulation et de chacune de ses itérations. Le prochain chapitre formalisera la constitution d’un environnement de simulation de Smart Grid, appelé Smart Grid Simulation Fra- mework, composé notamment des outils présentés dans ce chapitre et les précédents, et illustrera son utilisation dans le cadre de notre démarche.
8
Présentation de Smart Grid Simulation Framework sur un cas
d’étude et observations
Sommaire
8.1 Contexte du cas d’étude . . . .108 8.1.1 Présentation du problème . . . 108 8.1.2 Utiliser le Smart Grid Simulation Framework . . . 109 8.2 Déroulement de la démarche . . . .110 8.2.1 Phase 1 : modélisation du système de l’île de Sein . . . 110 8.2.1.1 Modèle de comportement de la simulation . . . .110 8.2.1.2 Modèle de catalogue et d’allocation . . . .112 8.2.1.3 Modèle de cosimulation . . . .113 8.2.1.4 Développement des unités de simulation . . . .115 8.2.2 Phase 2 : Configurer la cosimulation FMI . . . 117 8.2.2.1 Adapter les modèles en FMU . . . .117 8.2.2.2 Implémenter le scénario de cosimulation dans le master FMI . . . . .118 8.2.3 Phase 3 : Analyser les résultats . . . 119 8.2.3.1 Évaluer les résultats de simulation . . . .119 8.2.3.2 Prendre les décisions d’itération ou valider le modèle de la solution . .121 8.3 Observations . . . .121 8.4 Conclusion du chapitre . . . .123
Ce chapitre présente l’utilisation du Smart Grid Simulation Framework, qui est le nom que nous donnons à l’environnement constitué de l’ensemble de nos outils présentés dans les chapitres 6 et 7
précédents. Notre objectif est de montrer l’application des différentes contributions de nos travaux sur un cas d’étude identifié : celui de l’évolution du réseau électrique de l’Île de Sein. Nous présentons dans la première section la problématique de ce cas d’étude, et rappelons la démarche qui sera utilisée et qui a déjà été présentée au chapitre5. La deuxième section illustre étape par étape la mise en œuvre de cette démarche, et son utilisation avec le Smart Grid Simulation Framework. Puis, la troisième
Chapitre 8. Présentation de Smart Grid Simulation Framework sur un cas d’étude et observations
section généralise les observations qui peuvent être faites sur l’utilisation de notre environnement dans un contexte plus général que le cas d’étude de l’Île de Sein.