• Aucun résultat trouvé

3 Investigations expérimentales . . . 117

3.1 Comportement des FMU sur un nœud multi-cœurs . . . 118 3.2 Sensibilité de la co-simulation au réseau d’interconnexion . . . 121 3.3 Expérience de passage à l’échelle . . . 122

4 Approches proposées de mapping de FMU sur cluster . . . . 125

4.1 Approche par heuristiques élémentaires . . . 125 4.2 Approche par heuristiques complexes . . . 126 4.3 Approches automatiques . . . 133

5 Élaboration et utilisation d’un modèle de temps approximatif 139

5.1 Fonctionnement avec une synchronisation relaxée . . . 139 5.2 Modélisation de la phase de calcul . . . 141 5.3 Modélisation de la phase de communication . . . 143 5.4 Applications aux heuristiques complexes . . . 146

1

Introduction

1.1 Objectifs

La co-simulation des Smart Grids fait appel à la fois à des simulateurs qui exécutent une partie continue et une partie événementielle. Néanmoins, la simulation de la partie événementielle est habituellement très rapide par rapport à celles des composants phy- siques de la partie continue. Étant donné que cette thèse se préoccupe fortement des performances de la co-simulation, il est donc judicieux de s’intéresser à la partie la plus gourmande en calcul amenant un ralentissement de la co-simulation globale, c’est-à-dire celle des dispositifs physiques. Pour répondre à ce besoin, nous utilisons la plate-forme DACCOSIM pour simuler un réseau de distribution électrique. Cette plate-forme repré- sente ce type de réseau sous la forme d’un graphe de FMU qui devient ensuite un graphe de tâches hétérogènes communicant fréquemment. Toutefois, si la taille du graphe est importante, on ne peut pas exécuter ses tâches sur une seule ressource informatique (avec une taille mémoire et une puissance de calcul limitées), mais plutôt sur un cluster de PC multi-cœurs. La solution la plus simple est de placer une FMU sur un nœud de calcul, mais cela représente un gaspillage de ressources car on n’exploite pas totalement les cœurs disponibles sur chaque nœud de calcul, surtout si on n’a pas assez de ressources informatiques.

L’objectif de ce chapitre est de chercher à répartir au mieux les différents composants phy- siques (FMU) d’une même co-simulation (graphe de FMU) sur des clusters de machines multi-cœurs. Durant ces trois années de thèse, nous avons ainsi adapté DACCOSIM à ce type d’architecture en améliorant ses capacités d’exécution.

Nous évoquons, dans ce chapitre, trois approches de placement différentes : une ap- proche par heuristiques élémentaires s’appuyant uniquement sur le graphe DACCOSIM, une approche par heuristiques complexes permettant d’analyser finement le comporte- ment d’une co-simulation sur une architecture distribuée multi-cœurs, et une approche automatique ne nécessitant aucune pré-étude à l’avance. Mais avant cela, nous étudions quelques expérimentations décrivant le comportement de nos FMU sur une architecture distribuée multi-cœurs, afin de cadrer nos approches.

Pour finir, nous présentons un modèle prédictif qui permet d’estimer de manière approxi- mative nos phases de calculs et nos phases de communications, afin de les utiliser dans les approches qui nécessitent des connaissances préalables à chacune de ces deux phases.

1.2 Le mapping dans la chaîne de co-simulation

Dans cette section, nous décrivons d’une manière générale la démarche effectuée pour notre projet de co-simulation. Comme l’illustre la figure 1, notre démarche comporte quatre étapes importantes pour co-simuler un système cyber-physique sur un cluster de PC multi-cœurs :

Figure 1 – Approche suivie dans notre projet de co-simulation

1. Réalisation d’un graphe de co-simulation d’un système cyber-physique avec la plate- forme DACCOSIM qui a été présentée dans le chapitre 3.

2. Répartition des « k » FMU (tâches) sur « n » nœuds virtuels (vnode) définis dans le graphe de ressources DACCOSIM (voir le chapitre 3), tels que (k >= n), k ∈ N

et n ∈ N.

3. Création de « n » codes Java correspondant aux différents codes de co-simulation (un fichier par vnode).

4. Déploiement des « n » nœuds virtuels (vnodes) sur « n » nœuds physiques (pnodes), en appliquant un des algorithmes de mapping proposés dans les sections qui suivent. Notre travail se focalise sur l’étape 2, qui vise à attribuer chaque tâche indépendante à une ressource informatique, en cherchant à minimiser le temps d’exécution global de la co-simulation.

En accord avec EDF, nous faisons l’hypothèse que les tâches (FMU) de nos applica- tions ne changent pas dans le temps. Comme de plus les graphes de co-simulation sont statiques, on peut utiliser des approches « off-line » qui traitent des tâches fixes contrai- rement aux approches « on-line » qui traitent des applications dynamiques. Pour cela, nous avons proposé des solutions permettant de calculer le placement avant l’exécution des tâches (voir le chapitre 2). Dans ce cadre, les deux premières approches s’appuient sur une démarche partiellement manuelle qui a comme but d’analyser et d’évaluer le comportement des FMU, et la troisième est une approche automatique appliquée aux modèles à grande échelle.

Figure 2 – Les étapes de la répartition sur cluster

2

Modèle d’exécution d’une co-simulation DACCOSIM

2.1 Modèle en trois étapes

Dans notre cas, nous avons un graphe de tâches contenant des boites grises fortement connectées entre elles. Il s’agit d’un graphe différent des graphes présentés habituellement dans la littérature (voir le chapitre 2). C’est un graphe hybride dégénéré qui se comporte à la fois comme un graphe de tâches indépendantes pour exécuter la phase de calcul des FMU, et comme un graphe de tâches dépendantes de la fin des calculs jusqu’au début du pas de temps suivant. De manière générale, durant le pas de temps (hi) de l’itération i, toutes les FMU du graphe DACCOSIM exécutent leur phase de calcul en parallèle selon le mode d’orchestration défini auparavant (graphe de tâches indépendantes). À l’issue de ce pas de temps, les FMU font circuler les résultats de leurs sorties vers les entrées des FMU connectées avec elles (graphe de tâches dépendantes). Notons que pour la suite, nous allons utiliser le mode d’orchestration «ordered» car ce dernier nous permet de mesurer correctement et précisément les temps de communication contrairement au mode «overlapped» qui fausse ces mesures en exécutant en parallèle la phase de communication et de contrôle.

Dans la figure 3, nous avons un exemple qui propose quatre tâches hétérogènes in- dépendantes qui s’exécutent en parallèle pendant un même pas de temps. Avec DAC- COSIM, les wrappers des quatre FMU lancent leur phase de calcul en parallèle, cette caractéristique représente un graphe de tâches indépendantes. Ensuite, le master hiérar- chique (MA1) de ce graphe attend la fin de ces calculs pour déterminer le prochain pas

de temps de toute la co-simulation (voir le chapitre 3), cela représente une dépendance entre la phase de calcul (voir Fig. 3-a) et la phase de communication (voir Fig. 3-b) dans

Figure 3 – Exécution abstraite de DACCOSIM

le graphe DACCOSIM : on ne lance pas la phase de communication tant que les FMU n’ont pas encore finies leurs calculs (synchronisation forte dans le mode ordered), et que le master global n’a pas pris la décision globale soit de poursuivre la simulation ou de revenir en arrière. Ensuite, chaque FMU doit attendre les résultats des sorties des autres tâches connectées avec elle avant de commencer un nouveau calcul (un nouveau pas de temps), cela indique un graphe de tâches dépendantes. Notons que les FMU effectuent en fait leurs communications en parallèle, cette dernière étape représente donc à nouveau un graphe de tâches indépendantes. En outre, on peut considérer ce graphe de calcul DACCOSIM comme un modèle de tâches périodiques avec une période qui est égale à un pas de temps (voir la partie droite de la figure 3).

La figure 4 illustre une représentation détaillée du modèle d’exécution de l’exemple précédent pendant toute la co-simulation. Les communications échangées entre les diffé- rentes FMU du graphe sont effectuées à la fin du pas de temps actuel (itn), mais ne vont être prises en compte qu’à partir de l’itération suivante (it(n + 1)) (au prochain pas de temps).