Cette section concerne la création d’un artéfact multiplexeur. Dans la spécification d’un multi-modèle MECSYCO, il n’est pas possible de connecter deux artéfacts de couplage sur le même port d’entrée d’un m-agent. Sinon, deux évènements simultanés pourraient arriver sur ce port ce qui engendrerait un conflit non géré. À l’étape de multi-modélisation de notre démarche, dans le cadre de la réutilisation de modèles existants, il est possible que l’évènement entrant dans un modèle/multi-modèle doive être généré à partir des sorties de plusieurs modèles sources (nécessité d’agréger des données) ou que deux modèles transmettent leurs évènements au même port (nécessité de gérer les conflits).
L’intérêt du multiplexeur découle de la manière dont DEVS est utilisé dans MECSYCO, qui utilise une implémentation décentralisée du formalisme DEVS classique. Pour montrer ce que cela implique, nous allons commencer par présenter deux types de conflits et voir comment ces conflits
7.3. Agrégation d’évènements et artéfact multiplexeur sont traités dans les formalismes DEVS classique et DEVS parallèle puis dans MECSYCO. Cela permettra de d’éclaircir les raisons de l’hypothèse faite sur les connexions dans MECSYCO. Finalement nous introduirons l’artéfact multiplexeur, un artéfact de couplage particulier qui permet de connecter plusieurs ports de sortie de différents modèles pour les connecter à un même port d’entrée en réalisant au préalable une opération d’agrégation de données.
7.3.1 Différents conflits
Plusieurs évènements internes simultanés
Ce conflit arrive lorsque plusieurs modèles souhaitent exécuter leurs évènements internes simultanément. Dans le formalisme DEVS classique, ce problème est résolu grâce à la fonction de sélection Select : 2D− {} → Dqui choisi l’ordre dans lequel les modèles seront exécutés.
Dans le cas de MECSYCO, nous utilisons le formalisme DEVS classique avec ports mais implémenté de manière décentralisée, nous n’avons pas de fonction Select. Dans le cas décentralisé et parallèle, i.e. pour DEVS parallèle comme pour MECSYCO, les modèles ayant des évènements internes simultanées s’exécutent en même temps. Le problème est décalé sur la gestion entre l’exécution de l’évènement interne du modèle ou l’intégration des évènements externes arrivant au même moment.
Conflit entre évènements internes et externes
Ce type de conflit n’apparait pas dans le formalisme DEVS classique grâce à la fonction Select. Au contraire, le formalisme DEVS parallèle n’utilise pas de fonction globale de sélection, chaque modèle doit gérer localement les conflits entre évènements internes et externes grâce à une fonction de confluence δconv. La spécification d’un modèle atomique en DEVS parallèle est donc :
Mi= (Xi, Yi, S, δext, δin, λ, ta, δconv)
Par cette méthode δconv, chaque modèle définit en local s’il exécute en premier son évènement interne, s’il commence par intégrer les évènements externes arrivant au même temps ou tout autre comportement permettant de sortir du conflit.
Il faut noter que dans le formalisme DEVS parallèle, les messages échangés de contiennent pas juste des évènements associés à des ports mais des Bag d’évènements. Nativement, si plusieurs évènements externes arrivent simultanément sur un même port, la fonction de transition externe δext se chargera du choix de l’ordre d’exécution. Il y a donc deux niveaux de gestion de conflit, (1) choisir entre exécuter l’évènement interne ou les évènements externes imminents (réalisé par la fonction de confluence), et (2) choisir comment intégrer les évènements externes simultanés (réalisé par la fonction de transition externe dans DEVS parallèle).
Pour MECSYCO, le choix de l’algorithme CMB est d’exécuter en premier l’évènement interne puis les évènements externes imminents, ce comportement remplace la fonction de confluence.
Pour les évènements externes simultanés entrant dans un modèle, nous faisons l’hypothèse au travers de nos artéfacts de couplage qu’un port d’entrée n’est connecté qu’à un port de sortie et que l’ordre d’exécution des évènements sur différents ports n’a pas d’importance. Nous n’utilisons donc que des évènements atomiques et pas des Bags d’évènements. Cette hy-pothèse entraine qu’à l’heure actuelle, il n’y a jamais de conflits d’évènements externes arrivant simultanément sur un même port dans MECSYCO. Nous verrons qu’un artéfact multiplexeur nous permettra de relaxer cette hypothèse parfois non valable.
7.3.2 Artéfact multiplexeur
Le but de la création d’un artéfact multiplexeur est de permettre la connexion de plusieurs ports de sortie sur un même port d’entrée, autorisant l’agrégation de données issus de plusieurs ports et la gestion des évènements simultanées sur un même port. Le problème de gestion des évènements simultanés est l’une des faiblesses de l’algorithme de Chandy-Misra-Bryant [Zeigler et al., 2000]).
Fonctionnement
La Figure 7.5 présente un exemple d’utilisation de l’artéfact multiplexeur pour agréger des données venant de trois modèles et les afficher sur un graphe 3D. Le multiplexeur se place entre les artéfacts de couplage connectés aux agents émetteurs et l’artéfact de couplage connecté à l’agent receveur. Le multiplexeur se charge de capter les évènements et les estampilles temporelles liées à la synchronisation, et de renvoyer l’évènement correspondant après l’application d’une opération d’agrégation (appelée dans l’exemple StateXYZ ) ou l’estampille temporelle la plus imminente en absence d’évènement. Il faut noter que l’application de l’opération d’agrégation ne coûte pas de temps simulé (pas de délai minimum de propagation).
Figure 7.5 – Exemple d’utilisation du multiplexeur pour agréger trois données. Pour résumer, l’artéfact multiplexeur :
1. est connecté à plusieurs artéfacts de couplage et regroupe leurs évènements sous forme de Bag,
2. applique une opération d’agrégation sur le Bag d’évènements créé pour générer un évè-nement unique,
3. renvoi cet évènement à un (ou plusieurs) artéfact de couplage sans influencer l’estampille temporelle.
Le multiplexeur peut donc aussi servir pour choisir dans quel ordre des évènements arrivant sur un même port doivent être appliqués.
Représentation de l’opération
Pour se rapprocher de la notation DEVS, une opération d’agrégation entre les ports de sortie out de n modèles mi et les ports d’entrée in de k modèles mj peut être représentée par la fonction : Oaggregation(mout i )1≤i≤n→(min j )1≤j≤k : Vmout 1 × . . . × Vmout n → ∩ 1≤j≤kVmin j Avec :
7.3. Agrégation d’évènements et artéfact multiplexeur — Vmout
i , 0 ≤ i ≤ n, l’ensemble des valeurs admissibles des ports de sortie out des modèles mi.
— Vmin
j , 0 ≤ j ≤ k, l’ensemble des valeurs admissibles du port d’entrée in du modèle mj. L’opération d’agrégation prend en entrée un ensemble des valeurs admissibles de plusieurs ports de sortie issus d’un ou plusieurs modèles, et leur applique une transformation pour ren-voyer une valeur admissible pour tous les ports d’entrée (généralement de différents modèles) qui doivent recevoir l’information.
Intégration à mm2xml
L’ajout de l’artéfact multiplexeur aux artéfacts de MECSYCO a été effectué dans les lan-gages au niveau de la description des couplages. La Figure 7.6présente deux exemples d’ajout d’opération d’agrégation en mm2xml, l’utilisation est la même dans cs2xml.
internal couplings
{aggregation StateAggregationXY, ( model1."outX" , model1."outY" ) -> (model2."in")} {aggregation "operation.MyOp" arg1=2., (model1."a" , model2."b") -> (model3."in")}
Figure 7.6 – Description d’opérations d’agrégation
La première opération nommée "StateAggregationXY" permet simplement de transformer deux évènements dont les données sont des réels, en un évènement contenant un tuple (un paquet) de deux réels. Cette opération, déjà présente dans le cœur MECSYCO, est identifiée par un mot-clé.
La deuxième opération est identifiée par le nom de la classe qui effectuera la transformation. Cet exemple montre le cas où l’opération n’est pas disponible dans le cœur MECSYCO et devra être chargée à chaud lors de la co-simulation. Notons que les opérations d’agrégation disposent de paramètres. Dans le langage, ces paramètres sont définis juste après le nom de l’opération en donnant l’identifiant du paramètre et sa valeur.
7.3.3 Bilan
Dans le cas général, MECSYCO utilise des évènements atomiques et donc des connexions simples entre les modèles. Le multiplexeur nous permet de créer des liaisons complexes entre modèles en agrégeant des évènements venant de plusieurs sources, ainsi que de traiter des évè-nements simultanés arrivant sur un même port d’entrée.
Le fonctionnement du multiplexeur correspond à l’utilisation de Bags de données à l’image de ce qui est fait dans DEVS parallèle. Mais contrairement à ce dernier, le traitement des Bags est extérieur au modèle. Il est donc possible d’implémenter différentes politiques de gestion des évènements simultanés pour un modèle sans toucher à son implémentation propre ni à l’artéfact de modèle qui a permis son intégration.
L’utilisation de l’artéfact multiplexeur est permise dans le langage mm2xml décrivant les multi-modèles, mais aussi dans le langage cs2xml lors de la description des connexions aux outils d’observation (graphes...). Les opérations d’agrégation, au même titre que les autres opérations, peuvent être chargées à chaud dans MECSYCO Java. Les nouvelles opérations peuvent donc être facilement utilisées dans les langages. Pour l’instant, l’utilisation des opérations d’agrégation dans les langages et dans MECSYCO souffre des mêmes limites que les opérations standards sur les évènements. Les informations concernant les opérations (paramètres, données d’entrée et données
de sortie) ne sont disponibles que dans le code. Il faudrait y associer des descriptions pour faciliter leur réutilisation. C’est l’un des points d’amélioration de notre travail.