- L’objectif est de pouvoir simuler au plus tôt le système à étudier, à l’aide de stimuli issues du contexte opérationnel, à savoir l’environnement physique et autres systèmes connectés. Afin d’avoir des représentations fines et fidèles du contexte opérationnel, il est nécessaire d’utiliser des modèles exécutables pour les différents éléments du contexte. Ici, l’idée est d’utiliser le standard FMI plutôt que de chercher à faire des ponts sémantiques entre les langages ou d’implémenter des passerelles techniques entre outils. En effet, FMI permet d’encapsuler chaque modèle du contexte sous forme de FMU (Functional Mockup Unit). Ces FMUs sont ensuite importées dans un outil d’ingénierie système et sont connectées au système d’intérêt.
Figure 1: Graphe de co-simulation dans un IBD SysML
Le modèle obtenu, appelé aussi modèle couplé, défini alors un graphe de co-simulation (voir Figure 1). Ce graphe de co-simulation est nécessaire pour connaître la séquence d’appel aux FMUs (exécuter un pas de calcul avec la fonction fmi2dostep) et la séquence d’échange de données entre les FMUs et le modèle du système d’intérêt (grâce aux fonctions fmi2getXXX, fmi2setXXX).
Figure 2: Algorithme master basique.
L’avancement des pas de calcul et l’échange des données sont implémentés dans un algorithme master (voir Figure 2). C’est lui qui permet la co-simulation du système d’intérêt dans son contexte opérationnel. L’algorithme master est un élément clé car il permet l’échange des données et la synchronisation des FMUs lors de la co-simulation. C’est donc lui qui permet l’avancement de la simulation et l’envoi des stimuli sur le système d’intérêt, potentiellement avant même que celui-ci ne soit développé (vision boîte-noire).
Figure 3: Contexte opérationnel système et FMI.
Dans ce contexte, nous utilisons des FMUs pour la co-simulation, c’est-à-dire que les FMUs embarquent à la fois le modèle compilé (.dll, .so, etc) et le solveur qui permet son exécution (voir Figure 3). L’algorithme master se charge ensuite de synchroniser les différentes FMUs. L’observation du comportement du système soumis aux stimuli, permet de valider que le modèle du système satisfait les exigences.
Finalement, nous pensons, que ce qui est vrai pour le contexte opérationnel d’un système complet (satellite, avion, voiture, etc) l’est aussi pour un de ses sous-systèmes (voir Figure 4).
Figure 4: Contexte opérationnel sous-système et FMI.
Il s’agit de formaliser les contraintes entre propriétés clé du système sous forme d’équations acausales avec des paramètres reliés aux propriétés du système: masse, capacité de la charge utile, puissance électrique, vitesse…
Si on prend quelques hypothèses de valeurs ou d’intervalle de valeurs sur certaines de ces propriétés et si on peut utiliser des solveurs capables de résoudre les équations il devient possible de déterminer les valeurs des autres propriétés et ainsi évaluer la performance du système dans sa représentation courante et avec les hypothèses indiquées. Cette approche peut être utilisée dès l’analyse de la mission pour déterminer la faisabilité de telle ou telle classe de solution et jusqu’à la réalisation physique du produit où il sera possible de déterminer toutes les plages de valeur des propriétés du système.
-
- Nous étudions la possibilité de raffiner puis simuler une architecture fonctionnelle initiée avec un langage de haut niveau tel que SysML ou Capella et complétée par des blocs fonctionnels de plus bas niveau, formalisés dans d’autres langages.
- L’idée est de débuter la simulation au niveau du modèle haut niveau et de donner le contrôle à d’autres outils de modélisation/simulation (Simulink, Xcos, AMESim…) pour les fonctions de plus bas niveau.
Pour ce thème il y a deux axes de travail:
1. Méthodologique: nous étudions les concepts qui peuvent être réutilisés d’un niveau à l’autre (blocs, ports, activités, connecteurs, flux…) et la manière de les compléter à un niveau de détail plus fin et permettant une simulation réaliste.
2. Technique: il s’agit d’étudier la combinaison de plusieurs outils de simulations, notamment via le standard de simulation FMI (Functional Mockup Interface).
Il est donc nécessaire de pouvoir coupler ce langage à d’autres formalismes/outils complémentaires et notre priorité et d’étudier le couplage avec d’autres langages plus proches de la physique (AMESim, Fluent, Modelica, Matlab/Simulink, …) et des langages de sûreté de fonctionnement tels qu’AltaRica selon le point de vue détaillé ou le type de propriété spécifique à analyser.
Travaux de recherche en cours
Voici nos principaux partenaires de recherche:
N’hésitez pas à nous contacter si vous êtes intéressé(e).