2.4.1 Multi-modèle
Les sciences modernes expliquent le monde et la matière comme des organisations
hiérar-chiques, qu’on peut toujours redécouper en plus petits éléments qui interagissent entre eux,
de l’univers jusqu’aux particules élémentaires. Ainsi, considérer qu’un modèle est composé de
sous-modèles interagissant entre eux, comme le système cible est composé de sous-systèmes
in-teragissant entre eux, est tentant. Cette approche permet à la fois de construire un modèle
complexe comme un LEGO, et de réutiliser des sous-modèles qui seraient déjà existants, pour
décrire certaines parties du système. Il faut alors définir quels sont les composants du modèle,
et de quelle façon ils interagissent entre eux.
Un modèle qui n’est pas lui-même décomposable en sous-modèles est appelé un modèle
atomique. Un modèle qui est composé de sous-modèles est appelé un modèle couplé. Le modèle
couplé correspond alors au dernier niveau de spécification proposé par [Zeigler et al., 2000]
(niveau 4). La Figure 2.6 donne un exemple de modèle couplé, composé de trois sous-modèles
atomiques. Les sous-modèles disposent de ports d’entrée et de sortie (InetOut), leur permettant
d’échanger des données de simulation entre eux.
Figure 2.6 – Exemple de modèle couplé, composé de 3 sous-modèles atomiques (A, B et C).
Dès lors qu’on considère qu’un modèle couplé est formellement équivalent à un modèle
ato-mique, il est possible d’utiliser la notion de fermeture par composition. Ainsi, un modèle couplé
peut être composé à la fois de sous-modèles atomiques et de sous-modèles couplés. On peut ainsi
décrire une hiérarchie de modèles àN niveaux, uniquement avec ces deux concepts. La fermeture
par composition permet de réduire la complexité d’un modèle, en le définissant par rapport à des
composants existants, qui n’ont pas besoin d’être détaillés. Du point de vue de la simulation, les
modèles couplés étant formellement équivalents aux modèles atomiques, il peuvent être utilisés
de façon indifférenciée.
Parce qu’il est censé décrire de nombreuses interactions entre de nombreuses entités, un
système complexe (cf. Section 1.1.3) peut rarement être décrit à l’aide d’un seul et unique
modèle. Ainsi, ce type de système sera généralement représenté à l’aide de différents modèles
couplés entre eux, qui peuvent généralement être utilisés de façon indépendante et qui n’ont
pas obligatoirement été conçus pour communiquer entre eux. On parlera dans ce cas plutôt
de multi-modèle, composé de modèles atomiques et/ou couplés, eux-mêmes composés de
sous-modèles atomiques et/ou couplés, et ainsi de suite (cf. exemple de la Figure2.7).
Figure 2.7 – Exemple de multi-modèle hiérarchique, composé à la fois de modèles couplés et
de modèles atomiques.
À titre d’exemple, la modélisation de l’étang introduite précédemment (cf. Section 2.2.4)
pourrait être complexifiée, en introduisant la possibilité d’avoir une éclipse partielle du soleil
durant la journée étudiée. L’impact de l’éclipse sur le rayonnement du soleil au cours du temps
peut être déterminé en utilisant un modèle déjà conçu et qui est dédié à ce phénomène. Il
faudrait alors coupler notre modèle d’étang avec celui-ci, et déterminer comment ils
commu-niquent ensemble. On utiliserait alors désormais un multi-modèle pour étudier l’évolution de la
température de l’eau au cours de la journée.
Lorsque les modèles sont de natures différentes, on parle alors de multi-modèle hybride.
2.4.2 Multi-modèle hybride
Le choix du mode d’exécution dépend de la nature du modèle.
La Section 2.3.2 a permis de présenter deux grandes catégories de mode d’exécution : à
changements d’états continus (principalement avec des modèles équationnels) et à changements
d’état discrets (principalement avec des modèles à événements discrets).
Le choix du formalisme dépend fortement de la nature du système cible. Si on souhaite
mo-déliser l’élévation du niveau de la mer au cours du temps, en fonction de la fonte des glaces, il
n’y a pas de notion d’événements à proprement parler mais il y a un phénomène continu. Ainsi,
on pourra probablement le représenter dans un modèle en s’appuyant sur un formalisme
équa-tionnel. Par contre, si on souhaite modéliser le passage de clients à une caisse de supermarché,
on peut supposer que l’arrivée et le départ de chaque client à la caisse sont des événements.
Entre deux clients, il n’y a rien à observer. On utilisera par conséquent plutôt un formalisme à
événements discrets.
Cependant, selon la question qu’on se pose vis-à-vis du système cible, et donc du niveau
d’abstraction souhaité, le choix du formalisme peut être différent. Par conséquent, la
modélisa-tion d’un péage autoroutier pourrait parfaitement correspondre à un cas d’utilisamodélisa-tion de modèle
à événements discrets. Mais si on souhaite simplement déterminer une cadence de passage de
voitures, la représentation de celles-ci à l’aide d’une équation différentielle, peut être plus
ap-propriée.
Dans certains cas, le choix d’un formalisme par rapport à un autre peut ne jamais être
satis-faisant. L’exemple du péage autoroutier peut donner des résultats satisfaisants avec un modèle
équationnel la plupart du temps, et aura l’avantage de permettre l’utilisation d’un modèle simple
et potentiellement rapide à exécuter. Cependant, puisqu’il cache la complexité qu’il peut y avoir
dans ce genre de système, il ne pourra pas prendre en compte des événements particuliers, comme
la panne d’un automate ou un carambolage à l’entrée de l’autoroute, qui pourraient pourtant
avoir une importance particulière sur les résultats de simulation. On peut par conséquent
sou-haiter utiliser un modèle équationnel, représentant ainsi une vue macroscopique du système, et
le remplacer ponctuellement par un modèle à événements discrets, pour représenter le système
d’un point de vue microscopique, en prenant en compte des événements précis.
Le multi-modèle formé par le couplage de ces différents modèles hétérogènes est appelé un
modèle hybride. Interconnecter des modèles de natures différentes dans un même
multi-modèle, peut mener à devoir résoudre des problèmes liés à l’hétérogénéité, aussi bien au niveau
de la représentation du temps, qu’au niveau de la représentation des données échangées (ainsi
que sur d’autres aspects, dont purement logiciels, qui seront détaillés par la suite).
Un multi-modèle est exécuté dans le cadre d’une co-simulation.
2.4.3 Co-simulation
La notion de co-simulation intervient dès lors qu’il s’agit de simuler un multi-modèle, composé
de modèles différents, qui pourront être exécutés par des simulateurs différents. On dit qu’elle est
hybride dès lors qu’elle fait intervenir des modèles qui se reposent sur des formalismes différents.
Puisque les systèmes complexes sont difficiles à décrire (cf. Section1.1.3), il n’est pas possible
de les représenter avec un simple modèle équationnel. La simulation à événements discrets permet
de représenter les différentes (ou une partie des) entités de façon atomique, et de modéliser
les interactions qu’elles ont entre elles. Ça n’est que lors de l’exécution du modèle, grâce à la
simulation et aux résultats de simulation, qu’on pourra comprendre de quelle façon il se comporte
d’un point de vue macroscopique.
Dans un système complexe, les entités sont nombreuses et hétérogènes. Selon l’objet de la
simulation et le niveau d’abstraction nécessaire, il est peu probable qu’un seul simulateur soit
capable de permettre d’écrire un modèle pour représenter toutes celles qui sont à prendre en
considération. Cette hétérogénéité se retrouve généralement au niveau du choix des modèles, et
peut conduire à devoir utiliser des modèles qui représentent chacun un sous-système avec un
formalisme différent. Simuler un système complexe consiste donc généralement à devoir recourir
à une co-simulation hybride.
temps, et leurs horloges doivent être synchronisées pour qu’ils soient en capacité de s’attendre
les uns les autres.
2.4.4 Synchronisation du temps
Dans le cadre d’une co-simulation, chaque simulateur participant utilise sa propre horloge.
Le temps simulé, pris en considération par les modèles durant la simulation, pourra donc être
différent d’un modèle à l’autre, selon le simulateur qui l’exécute. Pour que les modèle puissent
s’échanger des données de simulation, ces horloges doivent être synchronisées, notamment pour
respecter la contrainte de causalité.
Respecter la contrainte de causalité signifie qu’il faut s’assurer que chaque simulateur (et
son modèle) reçoit toujours des données de simulation dans l’ordre croissant du temps. Ainsi,
une donnée de simulation qui est associée au temps de simulation y sera obligatoirement reçue
après une donnée de simulation associée au temps de simulation x, si y > x.
D’après [Fujimoto, 2001], il existe deux grandes catégories d’algorithmes de synchronisation
du temps, entre simulateurs : optimistes et conservatifs.
Les algorithmes conservatifs assurent à l’intégralité des simulateurs impliqués dans la
co-simulation, que la contrainte de causalité ne sera jamais violée. Ainsi, les simulateurs devront
généralement arrêter leur exécution, lorsque leur horloge aura atteint un temps simulé à partir
duquel il ne peut plus être garanti que d’autres simulateurs ne sont pas susceptibles de lui
transmettre des données de simulation associées à ce temps. Une fois que les autres simulateurs
auront avancé leur propre horloge interne, et que l’algorithme déterminera qu’il n’y a plus de
risque de recevoir de nouvelle donnée dans une certaine tranche de temps simulé, le simulateur
pourra reprendre l’avancement de sa simulation jusqu’à une nouvelle date limite.
La solution conservative peut éventuellement imposer aux simulateurs de constamment
s’at-tendre les uns les autres. Selon le type de simulation, et le type de modèles impliqués, cette
contrainte peut très fortement ralentir la co-simulation.
Afin d’obtenir de meilleurs temps d’exécution de la co-simulation, les algorithmes optimistes
préfèrent prendre le risque de temporairement violer la contrainte de causalité. Les simulateurs
pourront ainsi avancer leur horloge, sans garantie de ne pas recevoir ensuite une donnée de
simulation qu’il auraient dû intégrer à un temps qui est déjà passé pour eux. Les simulateurs
qui utilisent cette stratégie doivent impérativement être capables de résoudre cette situation, en
ayant la capacité de faire des rollbacks (cf. Section 2.3.2).
La solution optimiste permet parfois aux simulateurs d’avancer plus rapidement, en n’étant
pas obligés de systématiquement s’attendre les uns les autres. Cependant, si les modèles génèrent
beaucoup de données de simulation à se transmettre, à des temps très rapprochés, les simulateurs
auront fréquemment besoin de faire des rollbacks. Ces derniers pouvant être très coûteux en
temps d’exécution, la solution optimiste peut par conséquent parfois être moins performante
que la solution conservative, selon les modèles utilisés.
Des plateformes de co-simulation existent, et proposent différentes solutions pour gérer cette
synchronisation du temps entre les modèles. La section suivante présente quelques outils utiles
pour la co-simulation.
Dans le document
Intégration de modèles de réseaux IP à un multi-modèle DEVS, pour la co-simulation de systèmes cyber-physiques
(Page 43-47)