6.2.1 Besoin d’une évolution de la norme FMI
Nous avons vu qu’il est possible de rencontrer des événements de type state events et/ou de type time events dans un système complexe. L’actuelle version 2.0 de la norme FMI ne détecte ces événements qu’à la fin d’un pas de temps, alors que nous avons vu que ces événements peuvent être urgents et nécessiter un traitement immédiat. La norme FMI 2.0 suit le même principe qu’EPOCHS, et engendre des retards de traitement des événements (surtout si le pas de temps est grand) en les prenant en compte seulement au début du prochain pas de temps. Ce qui signifie que la simulation n’est pas précise et ne reflétera pas la réalité.
Dans notre modèle (section 4.2), nous avons proposé de procéder par une exploration du futur suivie d’un rollback pour détecter les événements imprévisibles, au milieu d’un pas de temps. Dès lors, nous pouvons réduire le pas de temps et co-simuler au mieux le système dès l’émergence du premier événement, dans le but de le traiter avec un délai le plus réduit possible. Néanmoins, les retours en arrière générés ralentissent la co-simulation globale de notre système, et il est préférable d’en faire le moins souvent possible.
C’est pour cela que nous proposons d’améliorer la norme FMI et l’API JavaFMI, plus par- ticulièrement en ajoutant les primitives suivantes : fmi21DoStep(), fmi21GetNextEventTime(), et fmi21breakPendingStep() [71]. Cet enrichissement6 de la norme FMI permettra de
traiter les événements sans délais avec un surcoût de temps d’exécution réduit au strict minimum.
6.2.2 Principe de la primitive fmi21DoStep()
Dans DACCOSIM, chaque dispositif physique (FMU) effectue un pas de simulation de taille hi en appelant la primitive fmi2doStep() définie dans la version 2.0 du standard FMI, afin d’exécuter ses calculs à l’itération i. Néanmoins, cette fonction ne traite pas les événements intervenants au milieu d’un pas de temps et ne le signale qu’à la fin de ce pas de temps. Pour remédier à cela, nous proposons d’améliorer la primitive fmi2DoStep() par la primitive fmi21DoStep(stepSize, ↑7 nextEventTime) qui permet de détecter avec
précision un state event sans exploration du futur (solution proposée jusqu’ici dans notre modèle) : cette nouvelle primitive autorise le solveur numérique de la FMU à s’arrêter exactement à la première apparition d’un state event, ce qui semble simple à réaliser
6. Ces propositions ont été publié dans la conférence ETFA’2016 (Emerging Technologies And Factory Automation) dans la catégorie « Work in progress », et ont été récompensées par un « Best Paper Award ».
compte-tenu des solveurs numériques qui fonctionnent en interne avec une succession de micro pas de temps (des pas de temps internes).
La figure 13 illustre le comportement de ces deux primitives. La nouvelle primitive
fmi21DoStep() interrompt automatiquement son pas de temps dès qu’elle détecte son
premier state event (se) afin de le signaler au master de co-simulation.
Figure 13 – Comportement des primitives fmi2DoStep() etfmi21DoStep() dans l’intégration d’un pas de calcul d’un composant physique
Comme le résume le diagramme de la figure 14, si un événement est bien détecté, cette primitive retourne le code fmi21Event et fournit le timestamp de l’événement par la variable de sortie nextEventT ime (paramètre passé par référence) qui retourne sa date d’apparition. Dans le cas où il n’apparaît pas de state event, la valeur de la variable de sortie nextEventT ime correspond à la fin du pas de temps sans interruption et retourne le code fmi21NoEvent. L’utilisation de cette fonction évite l’exploration du futur qui implique des rollbacks et un ralentissement excessif de la co-simulation globale.
6.2.3 Principe de la primitive fmi21BreakPendingStep()
Dans la version actuelle de la norme FMI, quand une des FMU s’arrête prématu- rément, les autres FMU du système continuent leurs calculs jusqu’à la fin du pas de temps proposé par le master. Cela entraîne des calculs inutiles et réduit les performances de la co-simulation globale. Pour cette raison, nous proposons une nouvelle primitive appelée fmi21BreakPendingStep(earlierTime) permettant d’interrompre l’exécution des autres FMU qui n’ont pas encore fini d’intégrer leur pas de temps. Ces exécutions seront arrêtées par un appel asynchrone de cette primitive. Pour ce faire, les FMU du sys- tème s’arrêteront au earlierT ime si elles n’ont pas encore atteint la fin du pas de temps (leur objectif initial était bien au delà de earlierT ime). Dans le cas contraire, les FMU s’arrêtent immédiatement pour effectuer un rollback et reprendre leurs calculs jusqu’à atteindre ce nouveau point (earlierT ime).
Figure 14 – Diagramme du fonctionnement de la primitive fmi21DoStep()
6.2.4 Principe de la primitive fmi21GetNextEventTime()
Afin de connaître à l’avance la date du prochain time event prévisible dans la partie événementielle, nous proposons une nouvelle primitive fmi21GetNextEventTime() qui permet à la partie événementielle (∆) de signaler à l’avance la date précise de son prochain événement connu. En fait, le master du co-simulateur utilisé (le master dans DACCOSIM) doit exploiter aussi cette information pour définir à l’avance la valeur du prochain pas de temps calé à la date exacte du prochain time event prévisible.
Comme le montre la figure 15, cette primitive permet de définir la date des événements prévisibles qui apparaissent pendant la co-simulation.
Exemple
La figure 16 illustre un exemple d’un système comportant trois FMU, ces dernières devraient exécuter leurs calculs pendant un pas de temps h0, de manière simultanée sur
différents nœuds du cluster. Comme le montre cette figure, FMU1 génère un événement de type state event au temps simulé t0
i et s’arrête en exécutant la primitive fmi21DoStep(ti) (qui détecte avec précision la date de ce state event). La FMU1 en question signale aux autres FMU (FMU2 et FMU3) d’arrêter leur calcul à t0
i en appelant la primitive
fmi21BreakPendingStep (t0i). Vu que la FMU2 réalise des calculs légers, elle a déjà atteint
Figure 15 – Illustration de la primitive fmi21GetNextEventTime() dans la partie événementielle
afin de ré-exécuter son calcul jusqu’à t0
i. À l’inverse, FMU3 est plus gourmande en calcul et n’a pas encore atteint (ti). Le solveur de cette FMU s’arrêtera ainsi à t0i à l’effet de la primitive fmi21BreakPendingStep(). Au final, dans cet exemple, une seule FMU aura effectué un rollback pour traiter au plutôt le state event à t0
i.