FMI und dieselbe Simulation überall
The model should not develop a personality
A simulation model should be dull in one very specific way: same input, same model, same output. That sounds obvious until the model moves from a workstation to a cluster, from a laptop to hardware-in-the-loop, from one compiler to another, or from a vendor tool into a safety office that does not appreciate interpretive dance. Then tiny numerical differences become meetings. Meetings become reconciliation spreadsheets. Reconciliation spreadsheets become the graveyard where good engineering afternoons go to die.
FMI exists to make model exchange and co-simulation practical across tools. The Functional Mock-up Interface gives teams a standard way to package and run models instead of hand-carrying fragileintegration code from one simulation environment to the next. That is already useful. But a standard interface does not automatically make arithmetic deterministic. Traditional FMI workflows often sit on IEEE 754 floating-point behaviour, platform libraries, compiler choices, execution order, and backend differences. Most of the time that is fine. Then it is not fine, and the difference is usually discovered by someone with a deadline and a face that says procurement promised this would be easy.
Dweve FMI attacks the boring, expensive part: reproducibility. The site describes a Rust FMI implementation for Model Exchange and Co-Simulation with deterministic fixed-point arithmetic, built on Numerus. The implementation shape is broader than a demo: a multi-crate FMI workspace with model representation, schema parsing, import, export, runtime, solver, orchestration, memory, backends for CPU, GPU, FPGA, edge and distributed execution, FFI, fuzzing, benchmarks, docs, and tests. It depends on Numerus crates for fixed-point and decimal arithmetic, plus the common Dweve stack for simulation, logging, fault handling, transport, tensors, and storage.
The goal is not to make simulation sound mystical. The goal is to make the same FMU stop telling slightly different stories because it wokeup on a different machine.
FMI gives the envelope, arithmetic still writes the cheque
AnFMU is a useful envelope. It carries a model description, binaries or source artefacts, resources, variables, states, clocks, dependencies, and enough metadata for another tool to instantiate and step the model. FMI 3.0 adds richer clocks, scheduled execution, improved variable typing, and co-simulation machinery. Dweve FMI’s source is organized around that envelope: fmi-schema parses and validates model descriptions, fmi-import loads FMU archives, fmi-export builds archives, fmi-model represents variables and model state, and fmi-runtime owns lifecycle, variable access, clocks, events, derivatives, and state save or restore.
That envelope is necessary, but it is not sufficient. The arithmetic underneath still decides whether a run is reproducible. The runtime docs say fixed-point arithmetic uses Numerus Q31_32 for deterministic computation. The workspace metadata names Q31.32 as the default fixed format, Dec64_6 as the default decimal format, and Q16.16 for time. The public page talks about Q31.32, Q16.16, and Dec64_6 profiles, with MPFR used as the reference route. That gives the project a clear contract: real-valued simulation should be mapped into deterministic numeric profiles instead of leaving every backend to improvise.
An dieser Stelle gibt es einen wichtigen Punkt der Ehrlichkeit. FMI-Schnittstellen und Kompatibilitätsebenen können weiterhin Gleitkommawerte akzeptieren oder ausgeben, weil der Standard und die vorhandenen Werkzeuge sie erwarten. Worauf es ankommt, ist nicht eine theatralische Reinheit an jeder Grenze. Worauf es ankommt, ist, dass der zentrale deterministische Pfad auf Numerus-Festkommaprofilen und der Validierung gegen eine hochpräzise Referenz aufbaut, wo ein Vergleich sinnvoll ist. Edge-Adapter können die Sprache der Außenwelt sprechen. Der Vertrag im Inneren sollte kein Achselzucken sein.
Das numerische Profil ist eine Modellentscheidung
Festkomma ist keine magische Einstellung. Ein Modell, das kompakte Zeitwerte braucht, ein Modell mit breiten physikalischen Bereichen und ein Modell, das Dezimalgrößen meldet, haben nicht denselben Druck. Q16.16, Q31.32 und Dec64_6 sind keine Aufkleber für eine Folie. Sie sind unterschiedliche Verträge über Bereich, Auflösung, Darstellung und darüber, wo Fehler leben dürfen.
Hier werden Simulationsteams oft zu nachlässig. Sie behandeln numerisches Verhalten als eine Eigenschaft des Werkzeugs und nicht als eine Eigenschaft des Modells. Dann ändert sich das Werkzeug, oder das Backend ändert sich, oder das Modell wird eingebettet, und plötzlich wird die alte Annahme zu einer Validierungslast. Dweve FMI macht das numerische Profil zu einem Teil der Architektur und nicht zu Hintergrundwetter. Das ist weniger glamourös als eine große Demo. Gut. Große Demos erklären selten, wem die Rundungsgrenze gehört.
Die Solver-Crate erzählt dieselbe Geschichte. Sie stellt ODE-System-Traits, RK4, RKF45, Euler, BDF-orientierte Konfiguration, adaptive Schrittsteuerung, Ereigniserkennung und deterministische Solverzeit bereit. Die Runtime-Crate besitzt den FMU-Lebenszyklus, Ereignis- und kontinuierliche Zeitmodi, Variablenzugriff, Eingabeableitungen, Richtungs- und adjungierte Ableitungen, Jacobi-Caching, Uhren und Zustandsserialisierung. Nichts davon ist nützlich, wenn der numerischen Schicht nicht vertraut werden kann, wenn sie über Hardware hinweg bewegt wird. Der Solver kann clever sein. Das Modell kann elegant sein. Wenn derselbe Lauf drei Abstimmungen braucht, ist die Eleganz meist nur Möbel.
Co-Simulation ist, wo kleine Lügen teuer werden
Eine FMU ist schon genug Arbeit. Mehrere gekoppelte FMUs sind der Ort, an dem numerische und operationelle Fehler sozial werden. Ein thermisches Modell speist ein Steuerungsmodell, das Steuerungsmodell speist ein Aktuatormodell, das Aktuatormodell speist ein mechanisches Modell, und alle hoffen, dass die Schrittfolge nicht leise Unsinn erzeugt. Co-Simulation braucht Verbindungsverwaltung, Ausführungsreihenfolge, Datenaustausch, Schrittkoordination, Behandlung algebraischer Schleifen und eine Möglichkeit, Nein zu sagen, wenn der Graph falsch ist.
Die Quelle hat fmi-orchestration für diese Arbeit. Sie behandelt Multi-FMU-Co-Simulation, Verbindungen, Zykluserkennung, topologische Sortierung, Partitionsplanung, Erkennung und Lösung algebraischer Schleifen, Werteverlauf, Ausführungsreihenfolge, Simulationszeit und Orchestrierungsstatistiken. Es gibt fmi-cc für die Kommunikation zwischen gekoppelten FMUs und fmi-dist für verteilte Ausführung mit Koordinatoren, Knotenregistrierung, Nachrichten, Schrittanfragen, Schrittantworten und Statuswerten. Das ist die Art von Mechanik, die Menschen vergessen, wenn sie sagen, Integration sei nur das Verdrahten von Ausgängen mit Eingängen. Es ist Verdrahtung, ja. Es ist auch Timing, Abhängigkeitsverwaltung, Zustand, Fehler und der Beweis, dass die Verdrahtung getan hat, was sie versprochen hat.
Co-Simulation macht Determinismus nicht weniger, sondern noch wichtiger. Weicht ein FMU leicht ab und dieser Wert speist ein anderes FMU, kann sich die Abweichung fortpflanzen. Ändert sich die Ausführungsreihenfolge zwischen den Knoten, kann die Abweichung bis zu einem späteren Schritt verborgen bleiben. Nutzt ein Backend einen leicht anderen Mathematikpfad, kann die Abweichung wie Modellverhalten aussehen. So landen Teams dabei, Physik mit Besprechungsprotokollen zu debuggen. Das sollte niemand tun müssen, außer man war in einem früheren Leben sehr unartig.
Backends sind Bereitstellungsoptionen, keine neuen Wahrheiten
Der Quellbaum trennt die Ausführungsziele in Backend-Crates: CPU, GPU, FPGA, Edge und verteilt. Das Edge-Backend konzentriert sich auf Geräte mit begrenzten Ressourcen, begrenztem Speicher und geringem Overhead. Das FPGA-Backend befasst sich mit Festkommaarithmetik, DMA-Übertragungen, Bitstream-Verwaltung, Kernel-Ausführung und Hardware-in-the-Loop. Die verteilte Crate koordiniert mehrere Knoten. Die öffentliche Seite beschreibt CPU-SIMD-, GPU-, FPGA-, Edge- und verteilte Pfade. Das bedeutet nicht, dass jedes Ziel für jede Arbeitslast gleich ausgereift ist. Es bedeutet, dass die Architektur die Backend-Wahl als erstklassiges Anliegen behandelt.
Das entscheidende Entwurfsprinzip ist, dass die Bereitstellung ändern sollte, wo die Simulation läuft, nicht was die Simulation bedeutet. Ein CPU-Pfad mag für die Erstellung und Verifizierung am einfachsten sein. Ein GPU-Pfad kann für große parallele Arbeitslasten sinnvoll sein. Ein FPGA-Pfad kann für Echtzeit- oder Hardware-in-the-Loop-Anwendungen erforderlich sein. Ein Edge-Pfad kann in der Nähe der Maschine erforderlich sein. Verteilte Ausführung kann für große gekoppelte Systeme erforderlich sein. Das sind operative Entscheidungen. Sie sollten keine neue numerische Identität für das Modell schaffen.
Genau hier ist Open Source wichtig. In den Bereichen Sicherheit, Energie, Robotik, medizinische Geräte, Automobil, Luft- und Raumfahrt, industrielle Steuerung und digitale Zwillinge können Reproduzierbarkeitsansprüche nicht nur in Verkaufsfolien von Anbietern leben. Jemand muss die Implementierung prüfen, eine Version festlegen, die Tests ausführen, die Fehlerfälle lesen und entscheiden, ob die Beweise ausreichen. Eine Open-Source-FMI-Implementierung gibt Teams einen besseren Weg zu diesen Beweisen. Sie zertifiziert nichts auf magische Weise. Sie macht die Arbeit überprüfbar, was der erste nützliche Schritt ist.
Validierung sollte ein Tor sein, kein Dashboard
Die Validierungsgeschichte von Dweve FMI handelt nicht nur von hübschen Ablaufverfolgungen. Die README und die Website beschreiben MPFR-Referenzprüfungen, backendübergreifende Äquivalenz, deterministische Wiedergabe, Konformitätstests, Fuzzing und typisierte Fehler. Der Quellcode enthält fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, Eigenschaftstests, Fuzz-Harnesses und Zustandsserialisierung. Das ist die richtige Richtung. In der Simulationsinfrastruktur sollte Validierung kein Dashboard sein, auf dem eine rote Linie besorgniserregend aussieht und jemand verspricht, sie im Auge zu behalten. Sie sollte ein Tor sein.
Das Tor hat mehrere Teile. Der Import muss das FMU-Archiv und modelDescription korrekt parsen. Die Schema-Validierung muss ungültige Variablendefinitionen, Abhängigkeiten, Uhren und Attribute ablehnen. Numerische Prüfungen benötigen ein Orakel, wenn der Anspruch Genauigkeit ist. Backend-Parität benötigt denselben Zustand über alle Ausführungsziele hinweg. Wiedergabe benötigt gespeicherten Zustand und Ereignisprotokolle, um den Lauf zu rekonstruieren. Fehler benötigen typisierte Fehler, keinen mysteriösen Abweichungsbericht, der das Team zum Stöbern in Protokollen schickt. Eine Abweichung sollte einen Release-Pfad blockieren, bis sie verstanden oder ausdrücklich akzeptiert ist. Das klingt nur hart, wenn die Alternative Ihnen noch keine Rechnung gestellt hat.
Wo das zuerst relevant wird
Die offensichtlichen Bereiche sind die, in denen Simulationsfehler zu physischen Fehlern werden: Automobilindustrie, Luft- und Raumfahrt, industrielle Steuerung, Medizingeräte, Energie, Robotik und Infrastruktur. Ein Bremsmodell, eine Pumpensteuerung, ein Netzmodell, eine Roboterzelle, eine Fertigungslinie oder ein HLK-Regler wird nicht sicherer, weil eine Folie digitalen Zwilling sagt. Es wird sicherer, wenn Modell, Eingaben, numerisches Profil, Backend, Version und Replay-Pfad kontrolliert genug sind, um sie zu untersuchen.
Es gibt auch einen Beschaffungsaspekt, denn natürlich gibt es den. Wenn jedes Backend eine eigene Validierungsgeschichte erfordert, wird jede Hardwareänderung zu einer kleinen Rezertifizierungsübung. Wenn derselbe FMU einmal nachgewiesen und dann auf dem Zielsystem ausgeführt werden kann, das zur Betriebsbedingung passt, gewinnen Teams Freiheit, ohne so zu tun, als sei Validierung kostenlos. Die Website formuliert das als einmal beweisen und überall ausführen. Die technische Übersetzung ist etwas weniger romantisch: die Zahl der Stellen reduzieren, an denen dasselbe Modell mit sich selbst uneins sein kann.
Das ist besonders in Europa relevant. Souveränität ist nicht nur eine Frage des Serverstandorts. Es geht auch darum, ob ein Sicherheitsnachweis geprüft, wiederholt und übertragen werden kann, ohne einen Lieferanten um Erlaubnis zu bitten. Eine offene Implementierung, deterministische Arithmetik, reproduzierbares Replay und Backend-Parität lösen Politik nicht von allein. Sie machen den technischen Teil weniger abhängig von einer Blackbox mit Vertriebsteam.
Was vor dem Vertrauen zu prüfen ist
Die erste Prüffrage ist, welche FMI-3.0-Oberflächen Ihr Modell tatsächlich nutzt. Model Exchange, Co-Simulation, Scheduled Execution, Uhren, Ableitungen, Ereignisse, binäre Variablen, Zeichenketten, Arrays und Abhängigkeiten sind nicht dieselbe Arbeitslast. Ein einfacher FMU und eine gekoppelte Multi-FMU-Simulation belasten Laufzeit und Orchestrator unterschiedlich.
Die zweite Frage ist, welches numerische Profil das Modell deklariert und warum. Wenn die Antwort lautet, was auch immer als Standard im Beispiel funktioniert hat, ist das kein Design. Das Profil sollte Bereich, Auflösung, Zeitdarstellung, Toleranz und Einsatzziel abdecken. Es sollte sichtbar genug sein, dass ein Prüfer es hinterfragen kann, ohne den gesamten Solver zu lesen.
Die dritte Frage ist, welche Nachweise mit einem Ergebnis mitgeliefert werden. Welche Quellversion? Welche FMU-Version? Welche modelDescription? Welches Numerus-Profil? Welches Backend? Welche Oracle-Prüfungen? Welcher Replay-Zustand? Welche Konformitäts- oder Eigenschaftstests? Wenn diese Antworten über ein Wiki und die Erinnerung von jemandem verstreut sind, ist die Simulation noch nicht bereit, in einem ernsthaften Arbeitsablauf vertraut zu werden.
Die Lektion
Die Lektion von Dweve FMI ist nicht, dass Simulationsstandards langweilig sind. Sie sind langweilig genau so, wie Brücken langweilig sind, wenn sie stehen bleiben. FMI liefert den Austauschrahmen. Numerus-gestützter Festkomma liefert die deterministische Arithmetik-Haltung. Laufzeit- und Solver-Crates lassen das Modell schreiten. Orchestrierung verbindet FMUs, ohne so zu tun, als sei Timing trivial. Backends verlagern die Ausführung auf die Hardware, die zur Aufgabe passt. Validierung verwandelt Gleichheit in ein Tor statt in eine Hoffnung.
Das ist die Arbeit. Keine große Behauptung, dass Zahlen für immer gelöst sind. Keine glänzende Demo, in der alles übereinstimmt, weil nur ein Pfad getestet wurde. Ein Simulationssystem, das seine Formate kennt, seinen numerischen Vertrag erklärt, über Backends läuft und laut scheitert, wenn dasselbe Modell aufhört, dasselbe Modell zu sein.
Das Modell sollte keine Persönlichkeit entwickeln. Davon haben wir in Besprechungen genug.