Le standard de simulation FMI 2.0

Ce standard a été initié par la société Daimler AG pour favoriser les échanges de

mo-dèles de simulation entre les fournisseurs et les équipementiers (OEM37) dans le monde

automobile. Ce standard FMI, indépendamment des outils, permet de faire de la simu-lation de modèles dynamiques, suivant deux approches : Model Exchange (FMI 1.0) et

Co-simulation (FMI 2.0). Le premier mode FMI 1.0 a été publié en 2010, tandis que le

se-cond (FMI 2.0) est rendu public en juillet 2014. Ce standard semble avoir été bien adopté par de nombreux éditeurs de logiciels. Le nombre d’outils disponibles est assez conséquent [FMI19] (section tools). Une description succincte de ces deux standards est présentée dans la section suivante.

2.8.5.1 Quelques fondamentaux de FMI

Pour être exécutés les modèles, au format FMI 1.0, doivent être intégrés à une plate-forme de simulation, puisque ces modèles ne contiennent pas leurs propres solveurs d’équa-tions différentielles. De par la nature même de cette approche, ce standard FMI 1.0 ne permet pas de faire de la simulation en entreprise étendue. C’est la raison pour laquelle, ce standard FMI 1.0 ne sera pas plus abordé dans le reste de cette thèse.

À l’inverse, le standard FMI 2.0 impose que les modèles de simulation contiennent leur propre intégrateur d’équations différentielles. Le logiciel contenant le modèle, le solveur et

le fichier de description des entrées/sorties de ce même modèle est dénommée FMU38.

Les bénéfices sont multiples. Le premier est de bien mieux protéger la propriété intellec-tuelle du fournisseur, puisqu’il n’a pas besoin de dévoiler le type de solveur et les paramètres internes employés, nécessaires à l’exécution de son modèle (figure 2.21-FMU/Slave). Cette

37. Original Equipment Manufacturer 38. Functional Mockup Unit

protection intellectuelle (IP39) permet seulement au fournisseur de visualiser le contenu de son propre modèle, sans pouvoir accéder au contenu des modèles des autres parte-naires (figure Fig. 2.22-b). Les figures 2.22-a & figure 2.23-Computer1&2) représentent une autre possibilité offerte par ce standard FMI-2.0 pour réaliser des co-simulations multiples, distribuées et hétérogènes [Nee+14][Gal+15]. Cette co-simulation peut prendre plusieurs formes : l’exécution de FMU simple, tout comme l’exécution d’outils de simulation (fi-gure 2.23-Simulation tool). Ces outils de simulation peuvent être des logiciels spécifiques métiers de partenaires, et dont ils ne souhaitent pas partager le code source et/ou l’exé-cutable. Cela peut être également du matériel, dont les commandes sont converties au standard FMI. L’algorithme Master contient l’ensemble des moyens de connexion réseau

(par exemple CORBA40, DCOM41, ou encore le logiciel pour la communication réseau :

CosiMateTM, exploité dans le projet MOISE) et les fonctions nécessaires au cadencement

de la simulation. Dans cette figure, le FMU sert d’intermédiaire entre la communication réseau et l’outil de simulation.

Figure 2.21 – Architecture de simulation FMI de base [FMI14].

Il faut noter que le standard FMI-2.0 ne spécifie pas de moyens de communication réseau. La définition de ces moyens est laissée à l’appréciation de l’entreprise réalisant cette co-simulation, ou aux entreprises partenaires dans le cas d’une entreprise étendue.

Figure 2.22 – Les aspects « collaboratif » et « privé » du standard FMI 2.0 [FMI14].

39. Intellectual Property

40. Common Object Request Broker Architecture 41. Distributed Component Object Model

Figure 2.23 – Architecture de simulation FMI distribuée [FMI14].

2.8.5.2 La gestion du temps dans FMI

La gestion du temps avec le standard FMI est de type coordonné (selon la définition

HLA). L’algorithme master définit le temps de départ tStart et de fin tStopdu temps simulé,

et le pas d’avancement/de communication de la simulation tci → t_ci+1. À chaque pas de

communication, l’algorithme master gère les échanges de données entre les différents FMU. À la fin d’un calcul, il lit les données de chaque FMU puis transmet les données récupérées à destination des FMU qui en ont besoin pour le pas de calcul suivant. Cette action est

répétée jusqu’à la fin du temps de calcul tStop.

Si le standard FMI propose un algorithme master de base, il semble plus performant de créer un algorithme master adapté à la cosimulation, qui prend en compte les différentes branches et boucles de rétroaction du modèle de co-simulation. Il en est de même pour la mise en place des mécanismes de rollback [Ler+17].

2.8.5.3 Les avantages et inconvénients

Le grand avantage du standard FMI est sa simplicité (par rapport à HLA, par exemple) et sa large diffusion auprès du monde industriel. C’est une des raisons pour lesquelles ce standard a été retenu par le projet MOISE, d’autant plus que deux membres partenaires

du projet ont fourni les outils tant pour la modélisation avec SimulationXTM que pour

le moyen de communication réseau entre les FMU CosiMateTM. L’autre intérêt, c’est la

présence d’une communauté importante et vivante autour de ce standard.

Parmi les inconvénients, l’API du standard FMI ne fournit pas de mécanismes standards pour gérer les événements et la demande de rollback, lorsque l’état du FMU a changé durant un pas de calcul et pour lequel les autres FMU doivent en être informés. Autre difficulté, l’API de ce standard est avant tout une API pour échanger des données scalaires. Il est difficile de passer simplement des paramètres de type vecteur (en prévision pour une version ultérieure de ce standard). Enfin, comme le standard FMI ne précise pas un protocole de communication, pour faire de la co-simulation via le réseau, il faut intégrer ces mécanismes dans l’algorithme master, sans oublier de mettre en place les serveurs adéquats sur chaque unité d’exécution.