FMI et la même simulation partout
Le modèle ne doit pas développer de personnalité
Un modèle de simulation doit être ennuyeux d'une manière très précise : mêmes entrées, même modèle, mêmes sorties. Cela semble évident jusqu'à ce que le modèle passe d'un poste de travail à un cluster, d'un ordinateur portable à une simulation avec matériel dans la boucle, d'un compilateur à un autre, ou d'un outil de fournisseur à un bureau de sécurité qui n'apprécie pas la danse interprétative. Alors, de minuscules différences numériques deviennent des réunions. Les réunions deviennent des feuilles de calcul de rapprochement. Les feuilles de calcul de rapprochement deviennent le cimetière où les bons après-midis d'ingénierie vont mourir.
FMI existe pour rendre l'échange de modèles et la co-simulation pratiques entre les outils. L'interface Functional Mock-up donne aux équipes un moyen standard d'empaqueter et d'exécuter des modèles au lieu de transporter à la main un code d'intégration fragile d'un environnement de simulation à l'autre. C'est déjà utile. Mais une interface standard ne rend pas automatiquement l'arithmétique déterministe. Les flux de travail FMI traditionnels reposent souvent sur le comportement en virgule flottante IEEE 754, les bibliothèques de la plateforme, les choix de compilateur, l'ordre d'exécution et les différences de backend. La plupart du temps, cela convient. Puis cela ne convient plus, et la différence est généralement découverte par quelqu'un qui a une échéance et un visage qui dit que les achats ont promis que ce serait facile.
Dweve FMI s'attaque à la partie ennuyeuse et coûteuse : la reproductibilité. Le site décrit une implémentation FMI en Rust pour l'échange de modèles et la co-simulation avec une arithmétique déterministe en virgule fixe, construite sur Numerus. La forme de l'implémentation est plus large qu'une démo : un espace de travail FMI multi-crates avec représentation de modèle, analyse de schéma, importation, exportation, exécution, solveur, orchestration, mémoire, backends pour CPU, GPU, FPGA, exécution en périphérie et distribuée, FFI, fuzzing, benchmarks, documentation et tests. Il dépend des crates Numerus pour l'arithmétique en virgule fixe et décimale, plus la pile commune Dweve pour la simulation, la journalisation, la gestion des défauts, le transport, les tenseurs et le stockage.
L'objectif n'est pas de rendre la simulation mystique. L'objectif est d'empêcher le même FMU de raconter des histoires légèrement différentes parce qu'il s'est réveillé sur une machine différente.
FMI fournit l'enveloppe, l'arithmétique signe toujours le chèque
Un FMU est une enveloppe utile. Il contient une description de modèle, des binaires ou des artefacts source, des ressources, des variables, des états, des horloges, des dépendances et suffisamment de métadonnées pour qu'un autre outil puisse instancier et faire avancer le modèle. FMI 3.0 ajoute des horloges plus riches, une exécution planifiée, un typage de variables amélioré et des mécanismes de co-simulation. Le code source de Dweve FMI est organisé autour de cette enveloppe : fmi-schema analyse et valide les descriptions de modèle, fmi-import charge les archives FMU, fmi-export construit les archives, fmi-model représente les variables et l'état du modèle, et fmi-runtime gère le cycle de vie, l'accès aux variables, les horloges, les événements, les dérivées et la sauvegarde ou la restauration d'état.
Cette enveloppe est nécessaire, mais elle n'est pas suffisante. L'arithmétique en dessous décide toujours si une exécution est reproductible. La documentation d'exécution indique que l'arithmétique en virgule fixe utilise Numerus Q31_32 pour le calcul déterministe. Les métadonnées de l'espace de travail nomment Q31.32 comme format fixe par défaut, Dec64_6 comme format décimal par défaut et Q16.16 pour le temps. La page publique parle des profils Q31.32, Q16.16 et Dec64_6, avec MPFR utilisé comme voie de référence. Cela donne au projet un contrat clair : la simulation à valeurs réelles doit être mappée dans des profils numériques déterministes au lieu de laisser chaque backend improviser.
Il y a ici un point d'honnêteté important. Les API orientées FMI et les surfaces de compatibilité peuvent encore accepter ou émettre des valeurs flottantes, car la norme et les outils existants les attendent. Ce qui compte n'est pas une pureté théâtrale à chaque frontière. Ce qui compte, c'est que le chemin déterministe central soit construit autour de profils à virgule fixe Numerus et d'une validation par rapport à une référence de haute précision là où la comparaison a un sens. Les adaptateurs périphériques peuvent parler le langage extérieur. Le contrat interne ne doit pas devenir un haussement d'épaules.
Le profil numérique est une décision de modèle
La virgule fixe n'est pas un réglage magique. Un modèle qui a besoin de valeurs temporelles compactes, un modèle avec de larges plages physiques et un modèle qui rapporte des quantités décimales n'ont pas les mêmes contraintes. Q16.16, Q31.32 et Dec64_6 ne sont pas des autocollants pour une présentation. Ce sont des contrats différents concernant la plage, la résolution, la représentation et l'endroit où les erreurs sont autorisées à vivre.
C'est là que les équipes de simulation deviennent souvent trop négligentes. Elles traitent le comportement numérique comme une propriété de l'outil plutôt que comme une propriété du modèle. Puis l'outil change, ou le backend change, ou le modèle est intégré, et soudain l'ancienne hypothèse devient un fardeau de validation. Dweve FMI fait du profil numérique une partie de l'architecture plutôt qu'une météo de fond. C'est moins glamour qu'une grande démonstration. Tant mieux. Les grandes démonstrations expliquent rarement qui possède la frontière d'arrondi.
La crate du solveur raconte la même histoire. Elle expose les traits de systèmes ODE, RK4, RKF45, Euler, une configuration orientée BDF, un contrôle adaptatif du pas, la détection d'événements et un temps de solveur déterministe. La crate d'exécution possède le cycle de vie FMU, les modes d'événement et de temps continu, l'accès aux variables, les dérivées d'entrée, les dérivées directionnelles et adjointes, la mise en cache jacobienne, les horloges et la sérialisation d'état. Rien de tout cela n'est utile si la couche numérique ne peut pas être fiable lorsqu'elle se déplace sur du matériel. Le solveur peut être astucieux. Le modèle peut être élégant. Si la même exécution nécessite trois réconciliations, l'élégance est surtout du mobilier.
La co-simulation est l'endroit où les petits mensonges deviennent coûteux
Un seul FMU est déjà assez de travail. Plusieurs FMU couplés ensemble, c'est là que les erreurs numériques et opérationnelles deviennent sociales. Un modèle thermique alimente un modèle de contrôle, le modèle de contrôle alimente un modèle d'actionneur, le modèle d'actionneur alimente un modèle mécanique, et tout le monde espère que l'ordre des étapes ne crée pas silencieusement des absurdités. La co-simulation nécessite une gestion des connexions, un ordre d'exécution, un échange de données, une coordination des étapes, une gestion des boucles algébriques et un moyen de dire non lorsque le graphe est faux.
La source contient fmi-orchestration pour ce travail. Elle gère la co-simulation multi-FMU, les connexions, la détection de cycles, le tri topologique, l'ordonnancement des partitions, la détection et la résolution des boucles algébriques, l'historique des valeurs, l'ordre d'exécution, le temps de simulation et les statistiques d'orchestration. Il y a fmi-cc pour la communication entre FMU couplés et fmi-dist pour l'exécution distribuée avec coordinateurs, enregistrement de nœuds, messages, demandes d'étapes, réponses d'étapes et valeurs de statut. C'est le genre de mécanisme que les gens oublient lorsqu'ils disent que l'intégration consiste simplement à connecter des sorties à des entrées. C'est du câblage, oui. C'est aussi du timing, de la gestion des dépendances, de l'état, des échecs et la preuve que le câblage a fait ce qu'il prétendait.
La co-simulation rend aussi le déterminisme plus important, pas moins. Si une FMU dérive légèrement et que cette valeur alimente une autre FMU, le désaccord peut se propager. Si l'ordre d'exécution change entre les nœuds, le désaccord peut rester caché jusqu'à une étape ultérieure. Si un backend utilise un chemin mathématique légèrement différent, le désaccord peut ressembler à un comportement du modèle. C'est ainsi que des équipes finissent par déboguer la physique avec des comptes rendus de réunion. Personne ne devrait avoir à faire cela, sauf s'il a été très mauvais dans une vie antérieure.
Les backends sont des choix de déploiement, pas de nouvelles vérités
L'arborescence source sépare les cibles d'exécution en crates de backend : CPU, GPU, FPGA, edge et distribué. Le backend edge se concentre sur les appareils contraints, la mémoire bornée et la faible surcharge. Le backend FPGA traite de l'arithmétique en virgule fixe, des transferts DMA, de la gestion des bitstreams, de l'exécution des kernels et du matériel dans la boucle. La crate distribuée coordonne plusieurs nœuds. La page publique décrit les chemins CPU SIMD, GPU, FPGA, edge et distribué. Cela ne signifie pas que chaque cible est également mature pour chaque charge de travail. Cela signifie que l'architecture traite le choix du backend comme une préoccupation de premier ordre.
Le principe de conception crucial est que le déploiement doit changer l'endroit où la simulation s'exécute, pas ce que la simulation signifie. Un chemin CPU peut être le plus facile pour l'écriture et la vérification. Un chemin GPU peut avoir du sens pour de grandes charges de travail parallèles. Un chemin FPGA peut être nécessaire pour le temps réel ou le matériel dans la boucle. Un chemin edge peut être nécessaire près de la machine. L'exécution distribuée peut être nécessaire pour de grands systèmes couplés. Ce sont des choix opérationnels. Ils ne doivent pas créer une nouvelle identité numérique pour le modèle.
C'est aussi là que l'open source compte. Dans la sécurité, l'énergie, la robotique, les dispositifs médicaux, l'automobile, l'aérospatiale, le contrôle industriel et les jumeaux numériques, les affirmations de reproductibilité ne peuvent pas vivre uniquement dans les diapositives des fournisseurs. Quelqu'un doit inspecter l'implémentation, épingler une version, exécuter les tests, lire les cas d'échec et décider si les preuves sont suffisantes. Une implémentation FMI open source donne aux équipes un meilleur chemin vers ces preuves. Elle ne certifie rien par magie. Elle rend le travail inspectable, ce qui est la première étape utile.
La validation doit être une porte, pas un tableau de bord
L'histoire de la validation de Dweve FMI ne concerne pas seulement de jolies traces. Le README et le site décrivent les vérifications de référence MPFR, l'équivalence entre backends, la relecture déterministe, les tests de conformité, le fuzzing et les échecs typés. La source contient fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, des tests de propriétés, des harnais de fuzzing et la sérialisation d'état. C'est la bonne direction. Dans l'infrastructure de simulation, la validation ne doit pas être un tableau de bord où une ligne rouge semble inquiétante et où quelqu'un promet de la surveiller. Elle doit être une porte.
La porte a plusieurs parties. L'importation doit analyser correctement l'archive FMU et le modelDescription. La validation de schéma doit rejeter les définitions de variables, les dépendances, les horloges et les attributs invalides. Les vérifications numériques ont besoin d'un oracle lorsque la revendication est la précision. La parité des backends nécessite le même état sur toutes les cibles d'exécution. La relecture nécessite un état sauvegardé et des journaux d'événements pour reconstruire l'exécution. L'échec nécessite des erreurs typées, pas un rapport de désaccord mystérieux qui envoie l'équipe explorer les journaux. Un désaccord doit bloquer un chemin de publication jusqu'à ce qu'il soit compris ou explicitement accepté. Cela semble dur seulement si l'alternative ne vous a pas encore facturé.
Là où cela compte en premier
Les domaines évidents sont ceux où les erreurs de simulation deviennent des erreurs physiques : l'automobile, l'aérospatiale, le contrôle industriel, les dispositifs médicaux, l'énergie, la robotique et les infrastructures. Un modèle de frein, un contrôleur de pompe, un modèle de réseau électrique, une cellule robotisée, une ligne d'usine ou un contrôleur CVC ne devient pas plus sûr parce qu'une diapositive dit « jumeau numérique ». Il devient plus sûr lorsque le modèle, les entrées, le profil numérique, le backend, la version et la trace de relecture sont suffisamment contrôlés pour être investigués.
Il y a aussi un angle d'approvisionnement, car bien sûr il y en a un. Si chaque backend exige une histoire de validation distincte, chaque changement matériel devient un petit exercice de re-certification. Si le même FMU peut être prouvé une fois puis exécuté sur la cible qui correspond à la contrainte opérationnelle, les équipes gagnent en liberté sans prétendre que la validation est gratuite. Le site le formule comme « prouver une fois et exécuter partout ». La traduction technique est légèrement moins romantique : réduire le nombre d'endroits où le même modèle peut être en désaccord avec lui-même.
Cela est particulièrement pertinent en Europe. La souveraineté ne réside pas seulement dans l'emplacement du serveur. Elle réside aussi dans la capacité d'inspecter, de répéter et de déplacer un dossier de sécurité sans supplier un fournisseur d'en obtenir la permission. Une implémentation ouverte, une arithmétique déterministe, une relecture reproductible et la parité des backends ne résolvent pas la politique à eux seuls. Ils rendent toutefois la partie technique moins dépendante d'une boîte noire accompagnée d'une équipe commerciale.
Ce qu'il faut examiner avant de faire confiance
La première question d'examen est de savoir quelles surfaces FMI 3.0 votre modèle utilise réellement. Model Exchange, Co-Simulation, Scheduled Execution, les horloges, les dérivées, les événements, les variables binaires, les chaînes, les tableaux et les dépendances ne représentent pas la même charge de travail. Un FMU simple et une simulation couplée multi-FMU exercent des pressions différentes sur l'exécution et l'orchestrateur.
La deuxième question est de savoir quel profil numérique le modèle déclare et pourquoi. Si la réponse est « le défaut qui a fonctionné dans l'exemple », ce n'est pas une conception. Le profil doit correspondre à la plage, à la résolution, à la représentation temporelle, à la tolérance et à la cible de déploiement. Il doit être suffisamment visible pour qu'un examinateur puisse le contester sans lire l'intégralité du solveur.
La troisième question est de savoir quelles preuves accompagnent un résultat. Quelle version de source ? Quelle version de FMU ? Quel modelDescription ? Quel profil Numerus ? Quel backend ? Quelles vérifications par oracle ? Quel état de relecture ? Quels tests de conformité ou de propriété ? Si ces réponses sont éparpillées dans un wiki et dans la mémoire de quelqu'un, la simulation n'est pas encore prête à être digne de confiance dans un flux de travail sérieux.
La leçon
La leçon de Dweve FMI n'est pas que les normes de simulation sont ennuyeuses. Elles sont ennuyeuses exactement de la même manière que les ponts sont ennuyeux lorsqu'ils restent debout. FMI fournit l'enveloppe d'échange. L'arithmétique à virgule fixe adossée à Numerus fournit la posture arithmétique déterministe. Les crates d'exécution et de solveur font avancer le modèle. L'orchestration connecte les FMU sans prétendre que la synchronisation est triviale. Les backends déplacent l'exécution vers le matériel adapté à la tâche. La validation transforme la similarité en un critère plutôt qu'en un espoir.
C'est là le travail. Pas une grande affirmation selon laquelle les nombres sont résolus pour toujours. Pas une démo brillante où tout correspond parce qu'un seul chemin a été testé. Un système de simulation qui connaît ses formats, déclare son contrat numérique, fonctionne sur plusieurs backends et échoue bruyamment lorsque le même modèle cesse d'être le même modèle.
Le modèle ne devrait pas développer de personnalité. Nous en avons déjà assez dans les réunions.