FMI 3 Simulation Runtime in Rust | Dweve FMI
Dweve FMI is an Apache-2.0 FMI 3 runtime in Rust for Model Exchange, Co-Simulation and Scheduled Execution. Publishing in the tenth release round.
Dweve FMI adressiert Plattformdrift in der Simulation. Festkommaprofile und Backend-Prüfungen machen Unterschiede sichtbar, bevor sie einen Safety Case erreichen.
Festkomma-Arithmetikbibliothek, die FMI-Determinismus ermöglicht.
Kryptografische Beweisinfrastruktur für KI-Schlussfolgerungen.
Führen Sie den gedämpften Oszillator auf zwei unterstützten Zielen aus und vergleichen Sie die Ausgaben. Referenzprüfungen decken jede Abweichung auf, bevor sie in einen Safety Case gelangt.
Deterministische Simulation, verifiziert
Zwei Fragen entscheiden über die Beschaffung: Wo läuft es, und wer kontrolliert die Beweise? Dweve FMI läuft auf Hardware, die Sie bereits besitzen, vor Ort oder in einer europäischen Region, während Modell und Validierungsprotokoll innerhalb einer Grenze Ihrer Wahl bleiben.
Beispiel ausführen, Ergebnisse vergleichen
Ein Sicherheitsnachweis braucht mehr als ein Versprechen. Prüfen Sie den Ergebniskontrakt, die Matrix der unterstützten Zielsysteme und die auf MPFR gestützte Validierungsmethode; führen Sie dann dasselbe Beispiel auf zwei Maschinen aus und vergleichen Sie die Ausgabe, bevor Sie entscheiden, wo FMI hingehört.
Kein einzelner Lieferant, von dem man abhängt
Keine Zeit verloren durch Ergebnisabgleich
Der Grund, sich darum zu kümmern, ist operativ, nicht technisch. Indem Sie dieselbe Simulation unter einem deklarierten Kontrakt auf jeder Maschine vergleichen, sehen Sie, wo sich ein Zielsystem unterscheidet, bevor Sie den Sicherheitsfall abschließen. Teams müssen Unterschiede nicht mehr stillschweigend abgleichen. Die Arbeit läuft auf der Hardware, die Sie bereits besitzen, und ein Wechsel auf neue Geräte erhält einen expliziten Validierungspfad.
Ein Anbieter, eine Roadmap, ein Preis, den Sie nicht festlegen.
Ein neuer Chip oder eine neue Region startet die Validierung über das gesamte Portfolio neu.
Teams streiten darüber, welche Maschine das richtige Ergebnis geliefert hat.
Jede Plattform braucht ihren eigenen Sicherheitsfall, weil Zahlen unterschiedlich sein können.
Der Fall für einen Wechsel lässt sich am einfachsten als Vergleich darstellen. Auf der einen Seite Simulation, die je Plattform variiert: ein Sicherheitsfall, der für jede Maschine revalidiert wird, Teams, die Zahlen abgleichen, die bereits übereinstimmen sollten, und eine Revalidierung bei jeder Hardwareänderung. Auf der anderen Seite Ergebnisse, die unter einem deklarierten Kontrakt verglichen werden, sodass die Belege zeigen, wo sich eine Bereitstellung unterscheidet. Der Unterschied ist operativ, nicht technisch.
Laufzeit entfernen; Modell und Belege bleiben
Ein wiederverwendbarer Sicherheitsnachweis
Ein Simulationsmodell sollte jede hardwareabhängige Abweichung sichtbar machen. Dweve FMI definiert einen Ergebniskontrakt über unterstützte Zielsysteme, prüft jedes Backend gegen einen MPFR-Orakel und lässt einen Validierungsnachweis mit dem Modell reisen.
Das Ergebnis folgt dem erklärten Vertrag
Nein, Ingenieure führen es im Hintergrund aus
Es ist berechtigt zu fragen, ob so etwas etwas für Sie ist. Das ist es nicht. Ingenieure führen es im Hintergrund aus, wo es Sicherheitssimulationen über Maschinen hinweg vergleicht und Unterschiede sichtbar macht.
Ein Validierungsdatensatz folgt dem Modell
MPFR-gestützte Prüfungen erkennen Abweichungen vor der Verwendung
Sie müssen nicht verstehen, wie es funktioniert, um zu genießen, was es tut. Denken Sie an sauberes Wasser oder gute Straßen. Sie sehen die Arbeit nie, aber Ihr Tag ist besser, weil jemand sie gut gemacht hat. Hier sind vier einfache Gründe, warum es wichtig ist.
Ein Schreibtisch und ein Sicherheitsbüro
Hier ist der Kern, einfach dargestellt. Derselbe Sicherheitstest läuft auf zwei verschiedenen Computern. Auf normalen Computern können die beiden Antworten ein winziges bisschen unterschiedlich ausfallen. Damit macht der Vergleich jeden Unterschied sichtbar. Schalten Sie den Schalter um und beobachten Sie, was sich ändert. Dieser Vergleich ist der ganze Punkt.
Roboter, die sicher neben Menschen arbeiten.
Stabile Stromversorgung, getestet, bevor sie installiert wird.
Sorgfältig geprüft, bevor sie einen Patienten erreichen.
Zuerst tausendfach am Computer getestet.
Sie werden das nie selbst nutzen, aber Sie nutzen jeden Tag die Dinge, die es schützt. Ein Auto, eine medizinische Pumpe, der Strom in Ihrem Zuhause, die Maschinen in einer Fabrik. Jedes wird am Computer getestet, bevor es gebaut wird, und das ist der Teil, der Unterschiede zwischen Zielplattformen sichtbar macht. Tippen Sie auf ein Bild, um zu sehen, warum das für jedes einzelne wichtig ist.
Nichts zu installieren oder zu verwalten
Ein sorgfältiger Helfer für Sicherheitstests
Sie werden das nie selbst nutzen. Aber es ist eine kleine, sorgfältige Sache, die hilft, Autos, Flugzeuge und medizinische Geräte sicher zu halten. Hier ist die ganze Idee, Schritt für Schritt einfach erklärt, mit einem Alltagsbeispiel für jeden Schritt.
und warum es in Ihrer Umgebung wichtig ist
Ein Simulationsingenieur erstellt und führt eine FMU auf seiner Workstation aus. Dieselbe FMU kann auf einem Cluster für Parametersweeps verglichen werden. Sie kann auch auf einem FPGA-Schutz für Hardware-in-the-Loop-Szenarien verwendet werden, bei denen das Latenzbudget eng ist. Der Wiederholungsvertrag gilt für alle drei.
FMI ist in Rust auf der Numerus-Arithmetikbasis geschrieben, verwendet Festkommapfade mit MPFR-Referenzprüfungen und unterstützt Model Exchange, Co-Simulation und Scheduled Execution über fünf Backends.
Traditionelles FMI kann je nach Plattform variieren, da es auf Gleitkomma basiert. Dweve FMI verwendet einen Festkomma-Arithmetikpfad mit MPFR-Referenzprüfungen. Das Simulationsmodell und der Sicherheitsfall bleiben explizit, während dasselbe FMU-Archiv über Workstation, Cluster und FPGA verglichen werden kann. Die Bereitstellungswahl ist operativ, nicht numerisch.
Chemische Masse und Energie, PLC-Co-Simulation.
Leistungsumrichter, Integration erneuerbarer Energien.
Regelgesetz-Validierung, Pilot-in-the-Loop.
Dweve FMI bedient Bereiche, in denen Simulationsergebnisse Design und Entscheidungen beeinflussen. Automobil, Luft- und Raumfahrt, Medizingeräte, Energie, Robotik, industrielle Steuerung und digitale Zwillinge benötigen alle Belege, dass Simulationsausgaben reproduzierbar, nachvollziehbar und pro Zielplattform steuerbar sind.
Dweve FMI integriert sich über FMU-Import und -Export, Multi-Modell-Orchestrierung und Digital-Twin-Brücken in bestehende Toolchains. Importieren Sie FMUs aus jedem FMI-3.0-konformen Tool mit automatischer Umwandlung von Gleitkomma in Festkomma. Exportieren Sie FMUs für nachgelagerte Tools, die Gleitkomma benötigen.
Wenn die Toleranz überschritten wird, stoppt der Lauf mit einem typisierten Fehler und der benannten Gleichung.
Ein aufgezeichneter Lauf wird über die Twin-Brücke aus seinem Ereignisprotokoll reproduziert.
Dieselbe FMU auf CPU, GPU, FPGA und Edge. Ausgabevektoren werden verglichen.
Festkommaoperationen werden gegen eine MPFR-Referenz geprüft.
Numerische Prüfungen nutzen die Numerus-Arithmetik-Basis und eine MPFR-Referenz. Der Backend-übergreifende Vergleich führt dieselbe FMU auf jedem Ziel aus und zeichnet jede Ausgabeabweichung auf. Deterministische Wiedergabe rekonstruiert einen aufgezeichneten Lauf aus seinem Ereignisprotokoll, und Fehlermodi sind laut statt leise.
Derselbe deterministische Kernel läuft auf Workstation-CPU, GPU, FPGA-Hardware, einem eingebetteten Edge-Gerät und verteilten Knoten. Ergebnisse können unter dem deklarierten Vertrag verglichen werden, sodass die Bereitstellungswahl operativ und nicht numerisch ist.
MPFR-Grundwahrheit, nur für die Verifikation verwendet.
6 Dezimalstellen, Banking- und Abrechnungsszenarien.
32 Nachkommabits, Standardprofil, volle Präzision.
16 Nachkommabits, enge Bereiche, akkuschonend.
Q31.32 deckt die meisten Simulationsanforderungen ab. Q16.16 passt für eingebettete und Edge-Ziele. Dec64_6 deckt domänenspezifische dezimale Buchhaltung ab. Alle drei basieren auf der Numerus-Arithmetik-Basis, bei der jede Operation korrekt gerundet und gegen die MPFR-Referenzbibliothek verifiziert wird.
Ein neuer Chip oder eine neue Cloud bedeutet, das gesamte Portfolio neu zu validieren.
Eine trigonometrische Funktion in einer Bibliothek kann sich geringfügig von einer anderen unterscheiden.
Compiler-Optimierung ändert die Reihenfolge von Gleitkommazahlen; Ergebnisse verschieben sich.
Workstation, CI, Zertifizierung: Vergleichen Sie die Zielplattformen und dokumentieren Sie Unterschiede im Sicherheitsnachweis.
Das Functional Mock-up Interface ist der Industriestandard für Modellaustausch und Co-Simulation. Es wird in sicherheitskritischen Bereichen eingesetzt, in denen Simulationsergebnisse Designentscheidungen, Sicherheitsnachweise und regulatorische Einreichungen beeinflussen. Traditionelle FMI-Implementierungen basieren oft auf IEEE-754-Gleitkommaarithmetik, daher müssen Plattformunterschiede überprüft werden.
Dieselbe Simulation sollte nicht abweichen
Dweve FMI implementiert den FMI-Standard für Model Exchange, Co-Simulation und Scheduled Execution, entwickelt in Rust mit deterministischer Festkomma-Arithmetik. Reellwertige Berechnungen folgen dem konfigurierten Festkomma-Pfad. Ergebnisse können über CPU-, GPU-, FPGA-, Edge- und verteilte Ziele verglichen werden, wobei MPFR als mathematische Referenz verwendet wird, wo anwendbar. Drei Festkomma-Profile decken technische Ziele von eingebetteten Geräten bis zu GPU-Parametersweeps ab, ohne das Simulationsmodell zu ändern.