FMI 3 Simulation Runtime in Rust | Dweve FMI

Dweve FMI adresserer platformdrift i simulering. Fixed-point-profiler og backend-tjek gør forskelle synlige, før de når en safety case.

Fixed-point-aritmetikbibliotek, der driver FMI-determinisme.

Kryptografisk bevisinfrastruktur til AI-ræsonnering.

Kør den dæmpede oscillator på to understøttede mål, og sammenlign outputtene. Referencechecks afslører enhver divergens, før den når en safety case.

To spørgsmål afgør indkøbet: hvor kører det, og hvem kontrollerer beviserne. Dweve FMI kører på hardware, du allerede ejer, on premise eller i en europæisk region, mens modellen og valideringsposten forbliver inden for en grænse, du vælger.

En sikkerhedspåstand kræver mere end et løfte. Gennemgå resultatkontrakten, matrixen over understøttede mål og den MPFR-baserede valideringsmetode; kør derefter det samme eksempel på to maskiner og sammenlign outputtet, før du vælger, hvor FMI hører til.

Ingen enkelt leverandør at være afhængig af

Ingen tid tabt på at afstemme resultater

Grunden til at bekymre sig er operationel, ikke teknisk. Ved at sammenligne den samme simulering under én erklæret kontrakt på hver maskine ser du, hvor en målsætning afviger, før du lukker sikkerhedssagen. Teams behøver ikke længere at afstemme forskelle i stilhed. Arbejdet kører på den hardware, du allerede ejer, og en flytning til nyt udstyr får en eksplicit valideringsvej.

Én leverandør, én køreplan, én pris, du ikke fastsætter.

En ny chip eller region genstarter validering på tværs af porteføljen.

Teams skændes om, hvis maskine der producerede det rigtige resultat.

Hver platform kræver sin egen sikkerhedssag, fordi tal kan variere.

Argumentet for at skifte er lettest at se, når det lægges frem som en sammenligning. På den ene side simulering, der varierer pr. platform: en sikkerhedssag, der revalideres for hver maskine, teams, der afstemmer tal, der allerede burde matche, og en revalidering, hver gang hardwaren ændres. På den anden side resultater sammenlignet under én erklæret kontrakt, så beviserne viser, hvor en implementering afviger. Forskellen er operationel, ikke teknisk.

Fjern runtime; model og beviser forbliver

En simuleringsmodel bør gøre enhver hardwareafhængig forskel synlig. Dweve FMI definerer én resultatkontrakt på tværs af understøttede mål, kontrollerer hver backend mod en MPFR-orakel og lader én valideringsjournal følge med modellen.

Resultatet følger den erklærede kontrakt

Det er rimeligt at spørge, om noget som dette er noget, du skal håndtere. Det er det ikke. Ingeniører kører det i baggrunden, hvor det sammenligner sikkerhedssimuleringer på tværs af maskiner og gør forskelle synlige.

MPFR-baserede kontroller fanger afvigelser, før de bruges

Du behøver ikke forstå, hvordan det virker, for at nyde det, det gør. Tænk på det som rent vand eller gode veje. Du ser aldrig arbejdet, men din dag er bedre, fordi nogen gjorde det godt. Her er fire enkle grunde til, at det betyder noget.

Her er kernen, vist enkelt. Den samme sikkerhedstest kører på to forskellige computere. På almindelige computere kan de to svar blive en lille smule forskellige. Med dette gør sammenligningen enhver forskel synlig. Skift kontakten og se, hvad der ændrer sig. Den sammenligning er hele pointen.

Robotter, der arbejder sikkert tæt på mennesker.

Stabil strøm, testet før den installeres.

Kontrolleret grundigt, før de når en patient.

Testet tusindvis af gange på en computer først.

Du kommer aldrig til at bruge dette, men du bruger de ting, det hjælper med at beskytte hver dag. En bil, en medicinsk pumpe, strømmen i dit hjem, maskinerne på en fabrik. Hver eneste er testet på en computer, før den bygges, og dette er den del, der gør forskelle mellem målplatforme synlige. Tryk på et billede for at se, hvorfor det betyder noget for hver enkelt.

En omhyggelig hjælper til sikkerhedstest

Du kommer aldrig til at bruge dette selv. Men det er en lille, omhyggelig ting, der hjælper med at holde biler, fly og medicinske maskiner sikre. Her er hele idéen, ét enkelt skridt ad gangen, med et hverdagsagtigt eksempel for hver enkelt.

og hvorfor det betyder noget omkring dig

En simulationsingeniør forfatter og kører en FMU på sin workstation. Den samme FMU kan sammenlignes på et cluster til parametersweeps. Den kan også bruges på en FPGA-shelter til hardware-in-the-loop-scenarier, hvor latensbudgettet er stramt. Replay-kontrakten gælder på tværs af alle tre.

FMI er skrevet i Rust på Numerus-aritmetikbasen, bruger fixed-point-stier med MPFR-referencekontrol og understøtter Model Exchange, Co-Simulation og Scheduled Execution på tværs af fem backends.

Traditionel FMI kan variere pr. platform, fordi den bygger på floating-point. Dweve FMI bruger en fixed-point-aritmetiksti med MPFR-referencekontrol. Simuleringsmodellen og sikkerhedscasen forbliver eksplicitte, mens den samme FMU-arkiv kan sammenlignes på tværs af workstation, cluster og FPGA. Implementeringsvalget er operationelt, ikke numerisk.

Kemisk masse og energi, PLC-co-simulering.

Strømomformere, integration af vedvarende energi.

Validering af styrelove, pilot in the loop.

Motor, transmission, bremse, affjedring.

Dweve FMI betjener domæner, hvor simuleringsresultater informerer design og beslutninger. Automotive, rumfart, medicinsk udstyr, energi, robotteknologi, industriel styring og digitale tvillinger har alle brug for dokumentation for, at simuleringsoutput er reproducerbare, sporbare og kontrollerbare pr. målplatform.

Dweve FMI integreres med eksisterende værktøjskæder gennem FMU-import og -eksport, multi-model-orkestrering og digital twin-bro. Importér FMU'er fra ethvert FMI 3.0-kompatibelt værktøj med automatisk konvertering fra float til fixed. Eksportér FMU'er til downstream-værktøjer, der kræver floating-point.

Overskridelse af tolerance stopper kørslen med en typet fejl og den navngivne ligning.

En optaget kørsel gengives fra sin hændelseslog via Twin-broen.

Samme FMU på CPU, GPU, FPGA og edge. Outputvektorer sammenlignes.

Fixed-point-operationer kontrolleres mod en MPFR-reference.

Numeriske kontroller bruger Numerus-aritmetikgulvet og en MPFR-reference. Sammenligning på tværs af backends kører den samme FMU på hvert mål og registrerer enhver outputforskel. Deterministisk afspilning rekonstruerer en optaget kørsel fra sin hændelseslog, og fejltilstande er højlydte frem for stille.

Den samme deterministiske kerne kører på workstation-CPU, GPU, FPGA-hardware, en indlejret edge-enhed og distribuerede noder. Resultater kan sammenlignes under den erklærede kontrakt, så valget af implementering er operationelt, ikke numerisk.

MPFR-grundsandhed, kun brugt til verifikation.

6 decimale cifre, bank- og faktureringsscenarier.

32 fraktionsbits, standardprofil, fuld præcision.

16 fraktionsbits, snævre intervaller, batterivenlig.

Q31.32 dækker de fleste simuleringsbehov. Q16.16 passer til indlejrede og edge-mål. Dec64_6 dækker domænespecifikt decimalregnskab. Alle tre hviler på Numerus-aritmetikbasen, hvor hver operation er korrekt afrundet og verificeret mod MPFR-referencedatamatbiblioteket.

Ny chip eller cloud betyder revalidering af hele porteføljen.

En trigonometrisk funktion i ét bibliotek kan afvige en smule fra et andet.

Compileroptimering ændrer rækkefølgen af flydende kommatal; resultaterne forskydes.

Workstation, CI, certificering: sammenlign målplatformene og registrér forskellene i safety casen.

Functional Mock-up Interface er industristandarden for modeludveksling og co-simulering. Den bruges i sikkerhedskritiske domæner, hvor simuleringsresultater ligger til grund for designbeslutninger, safety cases og regulatoriske indsendelser. Traditionelle FMI-implementeringer er ofte afhængige af IEEE 754 flydende kommatal-aritmetik, så platformforskelle skal kontrolleres.

Dweve FMI implementerer FMI-standarden for Model Exchange, Co-Simulation og Scheduled Execution, bygget i Rust med deterministisk fixed-point-aritmetik. Reelle beregninger følger den konfigurerede fixed-point-sti. Resultater kan sammenlignes på tværs af CPU-, GPU-, FPGA-, edge- og distributed-mål, med MPFR som matematisk reference, hvor det er relevant. Tre fixed-point-profiler dækker ingeniørmål fra indlejrede enheder til GPU-parametersweep uden at ændre simuleringsmodellen.

Den samme FMU-arkiv kan sammenlignes på hver backend. Én simulering, én valideringsregistrering.

CHECK: outputvektorer sammenlignet med referencen

trin: 1000 backend: fpga profil: Q16.16

trin: 1000 backend: cpu profil: Q31.32

Kør referencemodellen for den dæmpede oscillator på din udviklingsmaskine og på din CI-server. Sammenlign outputvektorerne, og gem den tværgående valideringsregistrering. Kontrakten er den erklærede sammenligning og dens omfang, ikke et ukvalificeret lighedskrav.

Dweve FMI er den standardudvekslingssti for ingeniørteams, der vil sammenligne simuleringer på tværs af maskiner. Deterministisk aritmetik gør sikkerhedsargumentet eksplicit for hvert erklæret mål i stedet for at skjule platformforskelle. Arbejdet kan køre på hardware, du allerede ejer, eller i en europæisk region.

Før en bil, et fly eller en medicinsk pumpe bygges, tester ingeniører den på en computer. Problemet er, at den samme test kan variere en smule mellem maskiner, og for en bremse betyder den lille forskel noget. FMI gør sammenligningen synlig, uanset hvor simuleringen kører, så de, der kontrollerer sikkerheden, ved, hvad de sammenligner.