Co-simulationMéthodes d’ingénierie

Co-simulation FMI

Importer et co-simuler des modèles fournisseurs via la norme FMI — charger une FMU Dymola et l’exécuter, la valider par recoupement face à un modèle natif, envelopper la boîte noire de votre propre régulateur via l’interface FMI, la coupler dans un système plus large, et quantifier l’erreur de co-simulation.

DjiniousLabModélisation et simulation

Un régulateur PID natif suivant une consigne sur un procédé FMU fournisseur importé via l’interface FMI

erreur de suivi en boucle fermée sur une FMU fournisseur: 2,9e-4 merreur de suivi en boucle fermée sur une FMU fournisseur
concordance CS vs ME (RMSE): 1,3e-3 mconcordance CS vs ME (RMSE)
fidélité FMU vs natif (RMSE): 4,7e-3 mfidélité FMU vs natif (RMSE)
réduction de l’erreur de co-simulation par affinement du macro-pas: 7.6×réduction de l’erreur de co-simulation par affinement du macro-pas
notebooks de conception: 10notebooks de conception
exigences RÉUSSI: 5 / 5exigences RÉUSSI

Exécuter — et commander — un modèle que vous n’avez pas construit.

Aucune équipe ne modélise tout dans un seul outil. La norme FMI existe pour qu’un modèle construit dans Dymola, Simulink ou ailleurs puisse être empaqueté en FMU et exécuté dans un tout autre environnement. Ce programme est le volet import de cette promesse : charger une FMU fournisseur dans le worker Julia de DjiniousLab, la co-simuler, la valider par recoupement face à une ré-implémentation native, et — la partie qui compte — envelopper la boîte noire de votre propre régulateur et fermer la boucle via l’interface FMI. L’interopérabilité n’est pas une case à cocher ; c’est commander le modèle de quelqu’un d’autre comme s’il était le vôtre.

Déposez une FMU fournisseur et elle s’exécute, tout simplement.

Une FMU est un modèle compilé, autonome, derrière une interface C standard. Le premier notebook charge une FMU de référence exportée depuis Dymola dans le worker Julia et la co-simule — les états sortent, l’orbite de phase se referme, sans code source, sans re-dérivation. C’est la promesse de base de l’interopérabilité : un modèle rédigé dans un autre outil, exécuté ici, sans modification.

Les états d’une FMU fournisseur co-simulés après import dans le worker Julia — Le moment de l’import : une FMU exportée depuis Dymola, chargée et co-simulée dans le worker — ses états sortent directement du modèle compilé via l’interface FMI. Vous exécutez un modèle que vous n’avez pas écrit et dont vous ne pouvez pas voir l’intérieur.

Co-simulation ou échange de modèle — et ils concordent.

FMI propose deux modes. En co-simulation, la FMU embarque son propre solveur et vous appelez doStep ; en échange de modèle, votre solveur intègre les dérivées de la FMU. La même FMU exécutée des deux façons se superpose à 1,3×10⁻³ m RMSE près — le choix porte sur qui possède le solveur, pas sur l’obtention de réponses différentes. Cette équivalence est ce qui permet de mêler une FMU à un système plus large résolu par Julia en toute confiance.

La même FMU exécutée en modes co-simulation et échange de modèle, se superposant presque exactement — Co-simulation (solveur propre à la FMU) contre échange de modèle (le solveur du worker intégrant la FMU) : la même FMU, deux modes d’intégration, se superposant à 1,3×10⁻³ m près. Le mode est une décision de propriété du solveur, pas de fidélité.

Une FMU importée et une ré-implémentation native Julia de la même physique se superposant exactement — Validation par recoupement : une EDO native Julia construite à partir des propres paramètres de la FMU, superposée à la FMU importée — elles concordent à 4,7×10⁻³ m près. (Décaler délibérément un paramètre et elles divergent, le contrôle négatif.) Une fidélité d’interopérabilité que l’on mesure, et non que l’on suppose.

Fermer une boucle autour de la boîte noire.

La revendication la plus forte en matière d’interopérabilité n’est pas d’exécuter un modèle fournisseur — c’est de le commander. Le notebook vedette fait de la FMU importée le procédé et l’enveloppe d’un PID natif Julia via une boucle de co-simulation manuelle : lire la sortie de la FMU, calculer la commande, fixer l’entrée de la FMU, avancer d’un pas. Le régulateur ne voit jamais l’intérieur de la FMU ; il ne lui parle qu’à travers l’interface FMI — et la pilote vers une consigne avec une erreur de suivi de 2,9×10⁻⁴ m. C’est un régulateur et un procédé fournisseur issus de deux mondes différents, se rencontrant sur la norme.

Un PID natif pilotant une FMU fournisseur importée vers une consigne, avec la force de commande affichée — La pièce maîtresse : un PID natif Julia commandant une FMU fournisseur en boîte noire via l’interface FMI (en haut — la sortie suivant la consigne ; en bas — la force de commande calculée). Le procédé est le modèle compilé de quelqu’un d’autre ; le régulateur est le vôtre ; l’interface FMI est le contrat entre les deux.

La co-simulation a son propre budget d’erreur.

Coupler des modèles en des points de communication discrets introduit une erreur qui lui est propre : entre les pas, chaque modèle voit ses entrées maintenues constantes, si bien qu’un macro-pas trop grand retarde et déforme le résultat. Le programme la quantifie — diviser le macro-pas par deux divise à peu près l’erreur par deux (convergence du premier ordre), une réduction de 7,6× sur le balayage. Savoir que l’erreur est du premier ordre par rapport à la taille du pas est ce qui permet d’arbitrer délibérément entre précision et vitesse, plutôt que par accident.

Un macro-pas grossier retardant sur la référence tandis qu’un macro-pas fin la suit — la convergence de co-simulation du premier ordre — Le budget d’erreur de co-simulation : un macro-pas grossier (rouge) retarde et se déforme car les entrées sont maintenues constantes entre les points de communication, tandis qu’un pas fin (bleu) suit la référence. L’erreur est du premier ordre par rapport au macro-pas — diviser le pas par deux divise l’erreur par deux.

Chaque valeur re-dérivée au moment de la validation finale.

Le notebook V&V réimporte la FMU et re-dérive chaque exigence depuis zéro, en affichant un tableau RÉUSSI/ÉCHEC.

Résultat

Import et co-simulation d’une FMU fournisseur : 101 échantillons
Concordance CS vs ME : 1,3e-3 m RMSE
Fidélité FMU vs natif : 4,7e-3 m RMSE
Erreur de suivi en boucle fermée : 2,9e-4 m
Erreur de co-simulation vs macro-pas : réduction de 7,6×

Exigence

Import et co-simulation d’une FMU fournisseur : R-01
Concordance CS vs ME : R-02
Fidélité FMU vs natif : R-03
Erreur de suivi en boucle fermée : R-04
Erreur de co-simulation vs macro-pas : R-05

Le volet import, sur des FMU de référence.

Le livrable est dix notebooks et le dossier — les modèles arrivent sous forme de FMU compilées derrière l’interface C de FMI, et non comme des composants acausaux DjiniousLab, donc pas de bloc personnalisé ni de canevas. Les FMU sont des références exportées depuis Dymola plutôt que des modèles tiers arbitraires ; la co-simulation est à taux unique avec extrapolation à entrée constante entre les points de communication, et sans solveur de boucle algébrique entre FMU couplées. Et il s’agit spécifiquement du volet import/co-simulation — l’export de FMU est une filière Rust distincte dans la plateforme. Ce que le programme démontre, c’est le cœur de l’interopérabilité : charger, co-simuler dans les deux modes, valider par recoupement, commander, coupler, et quantifier l’erreur de co-simulation — chaque valeur recalculable, la plus forte d’entre elles étant un régulateur natif fermant une boucle autour d’un modèle fournisseur dont il ne peut pas voir l’intérieur.