Contribution à un environnement de Co-Simulation distribuée pour Smart Grids Modèle d’intégration et de synchronisation d’un système complexe

Télécharger le fichier original (Mémoire de fin d’études)

Simulation des systèmes complexes : réseaux électriques intelligents

Un Smart Grid, ou réseau électrique intelligent, dispose d’unités de contrôle (centra-lisées ou distribuées) qui interagissent en temps réel. Ces interactions ont lieu d’une part entre ces composants et le réseau électrique pour prélever des informations (pilotage distance du réseau et reconfiguration de sa topologie), et d’autre part avec certains clients pour oﬀrir une flexibilité au réseau de distribution (résolution ou limitation de contraintes locales de tension ou de transit), en utilisant un système de communication performant. Les Smart Grids comportent à la fois des composants physiques (dispositifs du réseau électrique) évoluant en temps continu, et des composants numériques évo-luant en temps discret (réseau de télécommunication et unités de contrôle), hautement connectés avec le monde physique environnant. Au vu de la complexité d’un tel système, la première exigence est de le maîtriser puis de l’exploiter à l’optimum afin de valider son fonctionnement. Néanmoins, pour pouvoir le simuler sans simplifier ni les modèles ni leurs interactions, il est nécessaire d’adopter un nouveau type de simulation dit « co-simulation » ou bien « multi-simulation » (co-simulation purement logicielle donc sans HIL, voir la section suivante).

Processus de validation pour les systèmes complexes

Dans la littérature, on trouve globalement trois possibilités de validation pour les systèmes complexes [27]. De la simulation de ces systèmes (MIL) à la simulation en temps réel (SIL et HIL) [27], on peut les résumer comme suit :
— Model-In-the-Loop (MIL) est une technique utilisée pour modéliser le compor-tement d’un système. Elle est adoptée pour valider par simulation les diﬀérents algorithmes de contrôle et les corriger avant la fabrication des prototypes.
— Software-In-the-Loop (SIL) est un type de processus qui comporte deux parties : la première existe dans l’outil de simulation natif et la deuxième partie est un code exécutable. Autrement dit, ce type s’assure que le code fonctionne correctement sans aucun matériel ; c’est une méthode eﬃcace pour évaluer et critiquer un logiciel avant son utilisation dans le monde réel.
— Hardware-In-the-Loop (HIL) est une plate-forme qui exécute à la fois le mo-dèle et le matériel. Elle est utilisée pour valider les performances du matériel en contrôlant les entrées de la simulation en temps réel 2, c’est-à-dire qu’elle combine le hardware et le software dans le but d’avoir une analyse complète du système. Avec cette approche, on pourrait détecter les anomalies tout au long de son déve-loppement avant même l’installation du matériel sur le terrain [45]. Cela évitera à la fois la perte de temps et le coût inhérent à sa réparation ou à sa modification. C’est une technique eﬃcace dans les systèmes de contrôle-commande, comme dans les applications des véhicules électriques hybrides [57].

C’est quoi une co-simulation ?

La co-simulation est une technique de simulation des systèmes complexes, permettant de combiner plusieurs modèles hétérogènes réalisés avec des outils diﬀérents et par des experts issus de domaines variés. Elle est considérée comme un environnement unique, regroupant des simulateurs existants afin d’éviter de redévelopper à nouveau tous les composants de ce système.
La multi-simulation est similaire à la co-simulation, mais sans configuration (HIL) (Hardware-In-the-Loop). Dans le présent manuscrit, nous utilisons le terme « co-simulation » qui englobe celui de « multi-simulation ». À noter que seul le terme de co-simulation est connu dans le monde Anglo-Saxon. Les diﬀérents outils de la co-simulation échangent des données et interagissent fortement avec les autres composants du système par un envoi de messages. Notons également que nous travaillons, dans cette thèse, avec la co-simulation de uses cases (cas d’utilisation) des réseaux électriques intelligents métiers fournis par EDF R&D.
D’un point de vue informatique, une co-simulation se présente comme l’exécution d’un graphe de tâches hétérogènes fortement couplées. Une co-simulation comprend trois phases principales, décrites dans l’article [8] et présentées ci-dessous :
La phase d’initialisation : cette étape primordiale permet d’élaborer le graphe de tâches (préparer les communications des composants), et d’initialiser les entrées et les sorties du système global.
Désigne une simulation où le temps de la simulation progresse exactement comme le temps physique.
La phase de co-simulation proprement dite qui permet de lancer l’exécution de tous les composants de notre système.
La phase de clôture représente la fin de la co-simulation globale et le rapatriement des résultats.
De manière générale, la co-simulation permet de valider le bon fonctionnement des systèmes complexes hybrides

Contraintes imposées par les Smart Grids

Étant donné que cette thèse est liée directement à EDF, nous prenons en compte les contraintes imposées par l’environnement industriel des Smart Grids (contraintes des systèmes événementiels et des systèmes physiques). Il s’agit donc de combiner des logiciels simulant des composants événementiels de type événement et contrôle-commande avec des logiciels simulant les composants électriques (physiques). Ces modèles de simulation sont soumis aux contraintes citées dans les sous-sections suivantes.

Co-simulation de systèmes physiques

La simulation des dispositifs physiques s’appuie sur des solveurs qui discrétisent le temps continu en intervalles de temps dits pas de temps. La figure 2 précédente illustre un modèle de temps d’un composant physique avec un pas de temps (temps de calcul et communication) constant noté (tcc ou hi) à l’itération i. Les solveurs numériques de ces dispositifs physiques utilisent des pas de temps internes notés tci pour résoudre les équations de la physique (ODE 3, DAE 4) [56], c’est-à-dire des composants qui intègrent et mélangent des équations diﬀérentielles du temps avec des équations algébriques. À l’issue d’un pas de temps (hi), ces composants physiques communiquent et échangent des données. Ainsi, les solveurs des composants physiques peuvent utiliser des pas de temps constants, ou des pas de temps auto-adaptatifs (variables). Notons qu’un pas de temps ne doit être ni trop petit pour ne pas ralentir la co-simulation, ni trop grand pour éviter de causer des erreurs dans les calculs [29].
Dans le cas où les simulateurs sont synchrones, tous les composants du modèle utilisent et partagent le même pas de temps (hi). Lorsque celui-ci s’achève, les composants envoient leurs sorties (résultats) vers les entrées d’autres composants. Cependant, l’exécution de cette méthode peut entraîner beaucoup de communications, surtout si le pas de temps est petit. En revanche, si le système comporte des simulateurs asynchrones, la co-simulation peut théoriquement choisir des pas de temps variables. Mais dans ce cas, il est très Ordinary Diﬀerential Equation diﬃcile d’implémenter une solution qui synchronise les données échangées au sein du même système, surtout lorsque les composants utilisent des pas de temps variables avec la possibilité de retourner en arrière (déclencher le mécanisme de rollback).
Un système contient plusieurs composants physiques qui s’influencent mutuellement, mais selon deux types de couplages, à savoir le couplage fort et le couplage faible. Ils sont résumés comme suit :
— Couplage fort et fréquent
Dans ce type de couplage, les composants physiques du système fonctionnent avec un pas de temps unique (hi) pour tous les composants du système, en s’échangeant fréquemment leurs résultats intermédiaires après chaque pas de temps. On peut utiliser des pas de temps constants ou des pas de temps auto-adaptatifs (petit).
— Couplage faible
Dans ce type de couplage, les composants physiques du même système sont d’avan-tage autonomes, fonctionnent de manière relativement indépendante, et avec une contrainte de temps relâchée. Le couplage faible se prête bien à des solutions de type SMA 5 et on trouve des solutions qui utilisent des pas de temps diﬀérenciés 6.
Dans les travaux de cette thèse, nous utilisons nécessairement un couplage fort et fréquent à cause des constantes de temps des composants physiques sous-jacentes.
Dans les systèmes complexes, les composants physiques génèrent souvent des événe-ments de type state events vers les composants discrets. Par exemple, si la température dépasse un certain seuil, le composant physique déclenche une alarme qui représente un événement interne envoyé au contrôleur. Il est impossible de définir la véritable date d’apparition d’un événement interne (comme une alarme), car celui-ci peut apparaître au milieu d’un pas de temps (hi). Le modèle d’un simulateur de système physique ne peut donc pas connaître ces événements à l’avance. À l’inverse, les composants de contrôle génèrent souvent des événements de type time events facilement prédictibles.

Table des matières

Introduction générale
1 Contexte scientifique et industriel
2 Problématique
2.1 Concevoir un modèle hybride
2.2 Concevoir une distribution effectuée sur clusters de co-simulation
3 Plan de mémoire
État de l’art : Co-simulation distribuée sur Cluster de PC multicoeurs
1 Co-simulation appliquée aux Smart Grids
1 Introduction
2 Terminologies et notions de base
3 Simulation des systèmes complexes : réseaux électriques intelligents
3.1 Processus de validation pour les systèmes complexes
3.2 C’est quoi une co-simulation ?
3.3 Contraintes imposées par les Smart Grids
3.3.1 Co-simulation de systèmes physiques
3.3.2 Co-simulation de systèmes événementiels
4 Standards de co-simulation
4.1 Functional Mock-up Interface
4.2 High Level Architecture
5 Types de synchronisation pour la co-simulation
6 Solutions pour la question du temps dans une co-simulation
6.1 Solutions centrées HLA
6.2 Solutions centrées FMI
6.3 Solutions hybrides HLA/FMI
6.4 Solutions Ad Hoc
7 Positionnement de notre solution
8 Conclusion
2 Placement des tâches dans une architecture distribuée
1 Introduction
2 Placement des tâches
2.1 Graphe des tâches
2.2 Types de placement des tâches
2.3 Méthodes de résolution de placement des tâches
2.3.1 Méthodes exactes
2.3.2 Méthodes approchées
3 Performances sur machines parallèles
3.1 Impact de l’architecture sur les performances
3.2 Importance du réseau d’interconnexion
3.2.1 Réseaux locaux type Ethernet
3.2.2 Réseau Infiniband
3.3 Modélisation des exécutions des programmes parallèles
3.3.1 Modélisation du temps de calcul
3.3.2 Modélisation du temps de communication
3.4 Techniques de modélisation des performances
3.4.1 Loi d’Amdahl
3.4.2 Loi de Gustafson
4 Conclusion et positionnement de notre problème
3 Plate-forme de co-simulation distribuée (DACCOSIM)
1 Introduction
2 Approche utilisée
3 DACCOSIM
3.1 Principaux concepts de l’architecture de DACCOSIM
3.2 Caractéristiques détaillées de DACCOSIM
4 Co-simulation avec DACCOSIM
4.1 Fonctionnement de DACCOSIM
4.2 Briques de base utilisées dans DACCOSIM
4.3 Validation des résultats obtenus par DACCOSIM
5 Déploiement sur cluster
5.1 Clusters d’expérimentation
5.2 Structure et utilisation de DacRun
6 Limitations actuelles de DACCOSIM
7 Améliorations apportées dans DACCOSIM
8 Conclusion
Contribution à un environnement de Co-Simulation distribuée pour Smart Grids Modèle d’intégration et de synchronisation d’un système complexe
1 Introduction
2 Définitions et approche de couplage
2.1 Notations
2.2 Approche de couplage
2.3 Hypothèses sur nos plate-formes à coupler
3 Scénarios réalistes de co-simulation d’un Smart Grid
4 Architecture et fonctionnement d’un co-simulateur hybride classique
4.1 Principe d’un co-simulateur hybride classique
4.2 Notre modèle de co-simulation hybride classique
4.2.1 Le besoin d’explorer le futur des FMU
4.2.2 Architecture générale de notre co-simulateur hybride classique
4.2.3 Fonctionnement de notre modèle hybride classique
4.2.4 Fonctionnement de la sous-couche 1 « Exploration du futur»
4.2.5 Fonctionnement de la sous-couche 2 « Interfaçage »
4.3 Optimisation de notre modèle de temps
4.4 Limitations de notre modèle hybride classique
5 Concepts d’événements dans le contrôle-commande
6 Nouvelle approche de co-simulation hybride
6.1 Motivation pour une co-simulation entièrement FMI
6.2 Proposition d’évolution de la norme FMI
6.2.1 Besoin d’une évolution de la norme FMI
6.2.2 Principe de la primitive fmi21DoStep()
6.2.3 Principe de la primitive fmi21BreakPendingStep()
6.2.4 Principe de la primitive fmi21GetNextEventTime()
6.3 Architecture de co-simulation hybride entièrement DACCOSIM .
6.4 Travaux de normalisation au sein des FMI Working Groups
7 Conclusion
5 Mapping des tâches de type « FMU » sur cluster de PC multi-coeurs
1 Introduction
1.1 Objectifs
1.2 Le mapping dans la chaîne de co-simulation
2 Modèle d’exécution d’une co-simulation DACCOSIM
2.1 Modèle en trois étapes
2.2 Modélisation du temps d’exécution
3 Investigations expérimentales
3.1 Comportement des FMU sur un noeud multi-coeurs
3.1.1 Comportement des FMU par rapport aux calculs classique HPC
3.1.2 Détermination du nombre de FMU supportées par un noeud multi-coeurs
3.2 Sensibilité de la co-simulation au réseau d’interconnexion
3.3 Expérience de passage à l’échelle
4 Approches proposées de mapping de FMU sur cluster
4.1 Approche par heuristiques élémentaires
4.2 Approche par heuristiques complexes
4.3 Approches automatiques
5 Élaboration et utilisation d’un modèle de temps approximatif
5.1 Fonctionnement avec une synchronisation relaxée
5.2 Modélisation de la phase de calcul
5.3 Modélisation de la phase de communication
5.4 Applications aux heuristiques complexes
6 Conclusion
6 Évaluation et expérimentation des approches
1 Introduction
2 Métriques utilisées
3 Mise en oeuvre d’une co-simulation DACCOSIM sur cluster de PC multicoeurs
4 Observations préliminaires
4.1 Influence de la charge des FMU sur la fréquence des coeurs
4.2 Variabilité des mesures
5 Accélération de co-simulation de thermique de bâtiment
5.1 Use case de petits calculs en « thermique de bâtiment »
5.2 Use-case de moyens calculs en « thermique du bâtiment »
5.3 Use case de gros calcul en « thermique du bâtiment »
5.3.1 Test de speedup et de size up
5.3.2 Premiers tests de passage à l’échelle par réplication (scaling)
6 Passage à l’échelle de co-simulations de réseau électrique
6.1 Use-case de grande taille en « réseau électrique et thermique »
6.2 Analyse des performances obtenues
7 Évaluation de notre modèle approximatif de performance
7.1 Expérimentations pour calibration du modèle
7.1.1 Phase de calcul
7.1.2 Phase de communication
7.2 Confrontation modélisation/expérimentation
8 Conclusion
Conclusion générale
1 Synthèse des travaux de la thèse
2 Perspectives