Ordonnancement des simulateurs

Ce cas d'étude illustre des corrections croisées particulières entre simulateurs, qui né-cessitent un ordonnancement particulier de leur exécution. Nous avons vu précédemment que le simulateur correcteur du mouvement devait être exécuté en premier an de pouvoir corriger l'autre simulateur. La première solution proposée avec cette contrainte est donc la suivante, illustrée par les gures 4.9 et 4.10 :

1. Le simulateur régional corrige la demande et l'aectation.

2. Le simulateur local exécute autant de pas de temps que nécessaire pour avoir simulé un temps correspondant à celui d'un pas de temps du simulateur régional (3 fois dans la Figure 4.9).

3. Les vitesses moyennes des diérents arcs sont stockées par l'intergiciel à chaque pas de temps du simulateur local et la moyenne de ces vitesses sur plusieurs pas de temps est calculée puis utilisée pour corriger la vitesse dans le simulateur régional. 4. le simulateur régional est exécuté.

Figure 4.9  Solution corrigeant les vitesses

Avec cette solution, nous avons la correction du mouvement sur tout le pas de temps du simulateur régional mais la demande n'est pas correctement corrigée. Pendant l'exécution du pas de temps du simulateur régional - vert -, certains voyageurs vont entrer dans la

4.11. Correction croisée et ordonnancement de simulateurs

Figure 4.10  Solution corrigeant les vitesses

zone d'intérêt et ces voyageurs vont devenir de nouveaux voyageurs pour le simulateur local. Ces voyageurs qui entrent dans la zone font donc partie de la demande que le simulateur régional va envoyer au simulateur local et devraient être pris en compte pendant le second et le troisième pas de temps du simulateur local. C'est ce que nous avons appelé dans 4.5 la demande dynamique. Puisqu'ils entrent dans la zone pendant le pas de temps du simulateur régional, ils doivent donc être divisés en trois groupes pour les trois corrections de pas de temps du simulateur local. Ceci nous amène à la seconde solution présentée dans les gure 4.11 et 4.12 :

1. Le simulateur régional corrige la demande et l'aectation. 2. Le simulateur local exécute son premier pas de temps.

3. Le simulateur local corrige le mouvement en fonction de la vitesse calculée dans le premier pas de temps.

4. le simulateur régional est exécuté.

5. Le simulateur régional corrige la demande et l'aectation pour le second et le troi-sième pas de temps du simulateur local.

6. Le second et le troisième pas de temps du simulateur local sont exécutés.

Contrairement à la solution précédent, dans celle ci le simulateur régional corrige la demande et l'aectation pour chaque pas de temps du simulateur local. En revanche cette fois la correction de la vitesse pour le simulateur régional n'est faite que grâce au

Figure 4.11  Solution corrigeant la demande

4.11. Correction croisée et ordonnancement de simulateurs premier pas de temps du simulateur local. Avec cette solution la vitesse n'est donc pas correctement corrigé et si la vitesse est modiée lors du second ou du troisième pas de temps local, cela n'inuencera pas le simulateur régional. La seule solution pour corriger correctement les trois critères est d'exécuter plusieurs fois le pas de temps du simulateur régional en faisant des retours en arrière à la n du pas de temps comme le montre les gures 4.13 et 4.14 :

Figure 4.13  Synchronisation avec retour en arrière

Figure 4.14  Synchronisation avec retour en arrière Dans cette dernière solution :

1. La demande et l'aectation sont corrigés par le simulateur régional pour le premier pas de temps du simulateur local.

2. Le simulateur local est exécuté.

3. La simulateur local corrige le mouvement du simulateur régional.

4. Le simulateur régional est exécuté une première fois an de pouvoir corriger la demande pour le second pas de temps du simulateur local.

5. La demande et l'aectation du second pas de temps du simulateur local sont corri-gées.

6. Le simulateur local est exécuté.

7. Le simulateur local corrige le mouvement du simulateur vert avec la vitesse moyenne calculée sur les premiers et second pas de temps bleus.

8. Le simulateur régional est exécuté une seconde fois, sur le même pas de temps, avec la nouvelle correction de mouvement, an de fournir une nouvelle demande pour le troisième pas de temps du simulateur local..

9. Et cela avec autant de retours en arrière qu'il y a de pas de temps du simulateur local dans un pas de temps de simulateur régional.

Cette solution avec retour en arrière permet la correction de la demande, de l'aecta-tion et de la vitesse. Évidemment c'est une solul'aecta-tion coûteuse et le temps d'exécul'aecta-tion de la simulation est bien plus important qu'avec les deux autres comme nous le verrons dans la partie 5.3.2. Des solutions intermédiaires peuvent être utilisées ou le retour en arrière ne se fait pas à chaque pas de temps du simulateur local. Par exemple si un pas de temps du simulateur régional correspond à 20 pas de temps du simulateur local alors le retour en arrière peut être fait tous les 5 pas de temps du simulateur local.

Finalement, un dernier cas est à prendre en compte. Nous avons considéré que le plus long pas de temps (30 minutes) est un multiple du plus petit (15 secondes). Dans [Biedermann et al.2014] l'auteur propose de résoudre le cas où aucun pas de temps n'est un multiple de l'autre dans le but de fournir un framework pour les simulations multi-échelles de piétons le plus générique possible. Ainsi la solution proposée pour cor-riger la vitesse et la position des piétons à un instant t1 pour le simulateur 1 lorsque il n'y a des résultats sur le simulateur 2 qu'aux instants t2− et t2+ avec t2− < t₁ et t2+ > t₁ est d'eectuer une interpolation de ces résultats pour obtenir une estimation à l'instant t₁. Dans notre cas cela modie trois points par rapport à la dernière solution proposée -Figure 4.15 :

4.11. Correction croisée et ordonnancement de simulateurs

Figure 4.15  Synchronisation avec rollback

 Ã la n de la dernière itération du pas de temps du simulateur régional, on continue avec la première itération du second pas de temps du simulateur régional. Dans la solution précédente on continuait avec un nouveau pas de temps du simulateur local.

 Lors de la dernière itération du pas de temps du simulateur régional, la demande qui arrive dans la zone d'intérêt doit être sauvegardée et prise en compte lors de la prochaine correction de la demande.

 Le pas de temps du simulateur local situé entre les deux pas de temps du simulateur régional doit corriger le mouvement pour la n du premier pas de temps et le début du second.

L'interpolation n'est pas nécessaire dans notre cas. Au niveau de la demande on sau-vegarde simplement la demande qui est arrivée à la n du premier pas de temps du simulateur régional et elle sera ajoutée à la demande calculée par la première itération du second pas de temps. Au niveau des vitesses nos corrections se font toujours sur les laps de temps correspondant, durant toute la n du premier pas de temps du simulateur régional on a bien la vitesse calculée pendant le pas de temps du simulateur local.

Nous avons pris l'exemple d'une interaction avec un simulateur régional qui corrige la demande et l'aectation et un simulateur local corrigeant les vitesses. Nous avons vu dans le tableau 4.1 que d'autres interactions sont possibles, à savoir les cas (3), (4), (6) et (8) du tableau des types d'interaction présenté en début de chapitre. Il se trouve que le cas traité ici, le (6) est le cas le plus complexe et que les algorithmes proposés s'adaptent facilement aux autres diérents cas comme nous allons le voir ci-dessous :

 Tout d'abord dans le cas (3) où le simulateur régional corrige la demande et où le simulateur local corrige l'aectation et les vitesses, les algorithmes présentés

précédemment n'ont presque pas besoin d'être modiés. En eet, l'aectation au sein de la zone d'intérêt se fait simplement par le simulateur local après la correction de la demande venant du simulateur régional. Ce dernier est toujours exécuté après le simulateur local pour que ses vitesses soient corrigés et donc la correction de l'aectation, qui se fait à présent au même moment que celle des vitesses, est également faite avant l'exécution du simulateur régional. Le simulateur local, quant à lui, récupère la demande de la même manière que dans le cas (6) et l'aecte lui-même. La seule modication de l'algorithme est donc que dans ce cas, l'aectation est corrigée par le simulateur local et cela se fait au même moment que la correction des vitesses.

 Le cas (8) où le simulateur local ne corrige que la demande et où le simulateur régional corrige les autres est le plus simple. En eet, la correction de la demande par le simulateur local ne consiste qu'à modier les matrices Origines-Destinations du simulateur régional en ajoutant les voyageurs prévus par le local et à ne pas prendre en compte la demande dynamique 4.10.2 qui apparaît lors de l'exécution. Cette modication des matrices OD se fait avant l'exécution de la simulation. Ensuite, pendant l'exécution, tout peut donc être corrigé par le simulateur régional et on tombe sur un cas trivial comme (1) ou (2). On peut donc tout à fait exécuter le simulateur régional seul puis le simulateur local seul avec les résultats du régional.  Finalement dans le cas (4) où le simulateur régional ne corrige que l'aectation alors que le simulateur local corrige la demande, comme dans le cas précédent, la demande est corrigée avant l'exécution. Ici, puisque la demande est corrigée en amont de la simulation et qu'il n'y a pas de demande dynamique, on n'a pas besoin de retours en arrière car on se retrouve dans le cas présenté par la gure 4.9. Pendant l'exécution, on corrige l'aectation puis on exécute plusieurs pas de temps du simulateur local et enn on exécute le pas de temps du simulateur régional. Nous avons vu jusqu'ici les données que s'échangent les simulateurs et nous souhai-tons à présent donner un aperçu global de la manière dont les voyageurs seront créés, aectés, déplacés et détruits par les deux simulateurs. Nous concluons ici la présentation des interactions entre les deux simulateurs en résumant le fonctionnement du système de simulation multi-échelles proposé. Tout d'abord, comme le montre la gure 4.16 nous pouvons diérencier les voyageurs en fonction du chemin qu'ils parcourent.

Évidemment, les voyageurs qui ne passent jamais pas la zone d'intérêt - type 5 sur la gure - sont entièrement gérés par le simulateur régional. Les voyageurs dont l'origine est en dehors de la zone d'intérêt mais qui se rendent dans celle-ci - type 3 - ou qui passent par

4.11. Correction croisée et ordonnancement de simulateurs

Figure 4.16  Diérents types de voyageurs

celle-ci - type 1 - sont dans un premier temps créés, aectés et déplacés par le simulateur régional jusqu'à arriver dans la zone d'intérêt. Si la demande est corrigée par le simulateur local, alors ces voyageurs sont supprimés lorsqu'ils arrivent dans la zone et de nouveaux voyageurs seront créés selon la matrice OD locale. En revanche, si la demande est corrigée par le simulateur régional, alors ils restent en activité et sont également créés dans le simulateur local.

Les voyageurs dont l'origine se situe à l'intérieur de la zone d'intérêt types 2 et 4 -sont créés par les deux simulateurs en même temps à l'aide de la matrice OD du simulateur régional, qui aura au besoin intégré la matrice OD locale (cf. correction de la demande plus haut).

Dans tous les cas, l'aectation en dehors de la zone d'intérêt se fait par le simulateur régional. L'aectation à l'intérieur de la zone se fait par le simulateur correcteur de l'affectation, s'il s'agit du simulateur local alors les voyageurs qui viennent de l'extérieur -types 1 et 3 - sont simplement ré-aectés une fois dans la zone en conservant leur origine et leur destination.

Enn, chaque voyageur est déplacé à la fois dans les deux simulateurs séparément selon leur propre modèle et la cohérence est assurée avec la correction de vitesse moyenne des arcs.

4.12 Conclusion

Fondés sur notre état de l'art, nous avons conclu de la pertinence de dénir un modèle d'intergiciel pour le couplage de simulateurs, dans le cadre d'une simulation multi-échelles. Dans ce chapitre, nous nous sommes attelés à cette tâche. Nous avons commencé par présenter une méthodologie pour classier les simulateurs selon leurs caractéristiques et déterminer le type de couplage entre eux. Nous avons ensuite discuté de la question de la validation des simulateurs de mobilité, notion nécessaire pour la correction des simulateurs les uns les autres. Puis, nous avons présenté le modèle d'intergiciel pour le couplage de simulateurs, en nous focalisant successivement sur les aspects qui doivent être traités. Le modèle sert à l'implémentation d'un outil informatique avec lequel deux simulateurs peuvent être connectés pour obtenir une simulation multi-échelles, développé dans le chapitre suivant.

Les principaux choix eectués dans ce chapitre sont :

1. L'application de fonctions d'agrégation d'information et des fonctions de probabilité an de créer de l'information pour passer d'une représentation des voyageurs à une autre

2. La conversion de chaque section du réseau agrégé en un ensemble de chemins corres-pondants dans le réseau détaillé puis de faire correspondre l'aectation et le temps de parcours, également à l'aide de fonctions d'agrégation et de probabilité

3. Lorsque c'est nécessaire, l'utilisation d'un retour en arrière pendant la synchronisa-tion des simulateurs permettant de rejouer des pas de temps