FMI og den samme simulering overalt
Modellen skal ikke udvikle en personlighed
En simulationsmodel skal være kedelig på én helt bestemt måde: samme input, samme model, samme output. Det lyder indlysende, indtil modellen flytter fra en arbejdsstation til et cluster, fra en bærbar til hardware-in-the-loop, fra én compiler til en anden, eller fra et leverandørværktøj til en sikkerhedsafdeling, der ikke sætter pris på fortolkende dans. Så bliver små numeriske forskelle til møder. Møder bliver til afstemningsregneark. Afstemningsregneark bliver til kirkegården, hvor gode ingeniøreftermiddage går hen for at dø.
FMI findes for at gøre modeludveksling og co-simulation praktisk på tværs af værktøjer. Functional Mock-up Interface giver teams en standardmåde at pakke og køre modeller på i stedet for at slæbe skrøbelig integrationskode fra ét simuleringsmiljø til det næste. Det er allerede nyttigt. Men en standardgrænseflade gør ikke automatisk aritmetik deterministisk. Traditionelle FMI-workflows hviler ofte på IEEE 754 flydende komma-adfærd, platformbiblioteker, compilervalg, eksekveringsrækkefølge og backend-forskelle. Det er som regel fint. Så er det ikke fint, og forskellen opdages typisk af en person med en deadline og et ansigt, der siger, at indkøb lovede, at dette ville være nemt.
Dweve FMI angriber den kedelige, dyre del: reproducerbarhed. Sitet beskriver en Rust-FMI-implementering til Model Exchange og Co-Simulation med deterministisk fastpunktsaritmetik, bygget på Numerus. Implementeringens form er bredere end en demo: et multi-crate FMI-workspace med modelrepræsentation, skema-parsing, import, eksport, runtime, solver, orkestrering, hukommelse, backends til CPU, GPU, FPGA, edge og distribueret eksekvering, FFI, fuzzing, benchmarks, dokumentation og tests. Det afhænger af Numerus-crates til fastpunkts- og decimalaritmetik plus den fælles Dweve-stak til simulering, logning, fejlhåndtering, transport, tensorer og lagring.
Målet er ikke at få simulering til at lyde mystisk. Målet er at få den samme FMU til at holde op med at fortælle lidt forskellige historier, fordi den vågnede på en anden maskine.
FMI giver konvolutten, aritmetikken skriver stadig checken
En FMU er en nyttig konvolut. Den bærer en modelbeskrivelse, binære filer eller kildeartefakter, ressourcer, variabler, tilstande, clocke, afhængigheder og nok metadata til, at et andet værktøj kan instantiere og trinvis køre modellen. FMI 3.0 tilføjer rigere clocke, planlagt eksekvering, forbedret variabeltypning og co-simulation-maskineri. Dweve FMI’s kildekode er organiseret omkring den konvolut: fmi-schema parser og validerer modelbeskrivelser, fmi-import indlæser FMU-arkiver, fmi-export bygger arkiver, fmi-model repræsenterer variabler og modeltilstand, og fmi-runtime ejer livscyklus, variabeladgang, clocke, hændelser, afledte og tilstandsgemning eller -genskabelse.
Den konvolut er nødvendig, men den er ikke tilstrækkelig. Aritmetikken under den afgør stadig, om en kørsel er reproducerbar. Runtime-dokumentationen siger, at fastpunktsaritmetik bruger Numerus Q31_32 til deterministisk beregning. Workspace-metadataene navngiver Q31.32 som standard fastpunktsformat, Dec64_6 som standard decimalformat og Q16.16 til tid. Den offentlige side taler om Q31.32-, Q16.16- og Dec64_6-profiler, hvor MPFR bruges som referencevej. Det giver projektet en klar kontrakt: reel værdi-simulering bør kortlægges til deterministiske numeriske profiler i stedet for at lade hver backend improvisere.
Der er et vigtigt ærlighedspunkt her. FMI-vendte API'er og kompatibilitetsflader kan stadig acceptere eller udsende flydende værdier, fordi standarden og de eksisterende værktøjer forventer det. Det afgørende er ikke teatralsk renhed ved enhver grænseflade. Det afgørende er, at den centrale deterministiske sti er bygget op omkring Numerus fixed-point-profiler og validering mod en højpræcisionsreference, hvor sammenligning giver mening. Edge-adaptere kan tale det eksterne sprog. Den interne kontrakt bør ikke blive et skuldertræk.
Den numeriske profil er en modelbeslutning
Fixed-point er ikke én magisk indstilling. En model, der har brug for kompakte tidsværdier, en model med brede fysiske intervaller og en model, der rapporterer decimale størrelser, har ikke identiske krav. Q16.16, Q31.32 og Dec64_6 er ikke klistermærker til en præsentation. De er forskellige kontrakter om interval, opløsning, repræsentation og hvor fejl må bo.
Det er her, simulationsteams ofte bliver for afslappede. De behandler numerisk adfærd som en egenskab ved værktøjet snarere end en egenskab ved modellen. Så ændrer værktøjet sig, eller backend ændrer sig, eller modellen bliver integreret, og pludselig bliver den gamle antagelse en valideringsbyrde. Dweve FMI gør den numeriske profil til en del af arkitekturen snarere end baggrundsvejr. Det er mindre glamourøst end en stor demo. Godt. Store demoer forklarer sjældent, hvem der ejer afrundingsgrænsen.
Solver-craten fortæller samme historie. Den eksponerer ODE-systemtræk, RK4, RKF45, Euler, BDF-orienteret konfiguration, adaptiv trinstyring, hændelsesdetektering og deterministisk solvertid. Runtime-craten ejer FMU-livscyklussen, hændelses- og kontinuerlig-tilstande, variabeladgang, inputafledte, retningsbestemte og adjungerede afledte, Jacobi-cache, ure og tilstandsserialisering. Intet af det er nyttigt, hvis det numeriske lag ikke kan betros, når det flytter på tværs af hardware. Solveren kan være snedig. Modellen kan være elegant. Hvis den samme kørsel kræver tre afstemninger, er elegansen for det meste inventar.
Co-simulation er, hvor små løgne bliver dyre
Én FMU er allerede nok arbejde. Flere FMU'er koblet sammen er, hvor numeriske og operationelle fejl bliver sociale. En termisk model fodrer en styremodel, styremodellen fodrer en aktuatormodel, aktuatormodellen fodrer en mekanisk model, og alle håber, at trinrækkefølgen ikke stille og roligt skaber nonsens. Co-simulation har brug for forbindelsesstyring, eksekveringsrækkefølge, dataudveksling, trinkoordinering, håndtering af algebraiske sløjfer og en måde at sige nej, når grafen er forkert.
Kilden har fmi-orchestration til det arbejde. Den håndterer multi-FMU co-simulation, forbindelser, cyklusdetektering, topologisk sortering, partitionsplanlægning, detektering og løsning af algebraiske sløjfer, værdihistorik, eksekveringsrækkefølge, simulationstid og orkestreringsstatistik. Der er fmi-cc til kommunikation mellem koblede FMU'er og fmi-dist til distribueret eksekvering med koordinatorer, node-registrering, beskeder, trinanmodninger, trinsvar og statusværdier. Det er den slags maskineri, folk glemmer, når de siger, at integration bare er at forbinde outputs til inputs. Det er forbindelser, ja. Det er også timing, afhængighedsstyring, tilstand, fejl og bevis på, at forbindelserne gjorde, hvad de sagde.
Co-simulering gør også determinisme vigtigere, ikke mindre. Hvis én FMU afviger en smule, og den værdi føres ind i en anden FMU, kan uoverensstemmelsen forplante sig. Hvis eksekveringsrækkefølgen ændres på tværs af noder, kan uoverensstemmelsen skjule sig indtil et senere trin. Hvis én backend bruger en lidt anden matematisk sti, kan uoverensstemmelsen ligne modeladfærd. Sådan ender teams med at fejlsøge fysik med mødereferater. Ingen burde skulle gøre det, medmindre de har været meget slemme i et tidligere liv.
Backends er implementeringsvalg, ikke nye sandheder
Kildetræet adskiller eksekveringsmål i backend-crates: CPU, GPU, FPGA, edge og distribueret. Edge-backenden fokuserer på enheder med begrænsede ressourcer, afgrænset hukommelse og lav overhead. FPGA-backenden beskæftiger sig med fixed-point-aritmetik, DMA-overførsler, bitstream-administration, kerneeksekvering og hardware-in-the-loop. Det distribuerede crate koordinerer flere noder. Den offentlige side beskriver CPU-SIMD-, GPU-, FPGA-, edge- og distribuerede stier. Det betyder ikke, at hvert mål er lige modent til enhver arbejdsbyrde. Det betyder, at arkitekturen behandler valg af backend som et førsteklasses anliggende.
Det afgørende designprincip er, at implementering skal ændre, hvor simuleringen kører, ikke hvad simuleringen betyder. En CPU-sti kan være nemmest til forfatterarbejde og verifikation. En GPU-sti kan give mening til store parallelle arbejdsbyrder. En FPGA-sti kan være nødvendig til realtid eller hardware-in-the-loop. En edge-sti kan være nødvendig tæt på maskinen. Distribueret eksekvering kan være nødvendig til store koblede systemer. Det er operationelle valg. De bør ikke skabe en ny numerisk identitet for modellen.
Det er også her, open source betyder noget. Inden for sikkerhed, energi, robotteknologi, medicinsk udstyr, bilindustrien, rumfart, industriel styring og digitale tvillinger kan reproducerbarhedspåstande ikke kun leve i leverandørpræsentationer. Nogen skal inspicere implementeringen, fastlåse en version, køre testene, læse fejltilfældene og beslutte, om beviserne er gode nok. En open source FMI-implementering giver teams en bedre vej til det bevis. Den certificerer ikke magisk noget. Den gør arbejdet inspicerbart, hvilket er det første nyttige skridt.
Validering skal være en port, ikke et dashboard
Dweve FMIs valideringshistorie handler ikke kun om pæne spor. README'en og siden beskriver MPFR-referencekontrol, tværgående backend-ækvivalens, deterministisk afspilning, konformitetstest, fuzzing og typede fejl. Kilden har fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, egenskabstest, fuzz-harness og tilstandsserialisering. Det er den rigtige retning. I simuleringsinfrastruktur bør validering ikke være et dashboard, hvor en rød linje ser bekymrende ud, og nogen lover at holde øje med den. Det bør være en port.
Porten har flere dele. Import skal parse FMU-arkivet og modelDescription korrekt. Skemavalidering skal afvise ugyldige variabeldefinitioner, afhængigheder, clocke og attributter. Numeriske kontroller har brug for en orakel, når påstanden er nøjagtighed. Backend-paritet har brug for den samme tilstand på tværs af eksekveringsmål. Afspilning har brug for gemt tilstand og hændelseslogge for at genskabe kørslen. Fejl har brug for typede fejlmeddelelser, ikke en mystisk afvigelsesrapport, der sender teamet på jagt gennem logge. En afvigelse bør blokere en udgivelsessti, indtil den er forstået eller eksplicit accepteret. Det lyder kun hårdt, hvis alternativet ikke har sendt dig en regning endnu.
Hvor det betyder noget først
De oplagte domæner er dem, hvor simuleringsfejl bliver til fysiske fejl: bilindustrien, rumfart, industriel styring, medicinsk udstyr, energi, robotteknologi og infrastruktur. En bremsemodel, pumpecontroller, elnetmodel, robotcelle, fabrikslinje eller HVAC-controller bliver ikke sikrere, fordi en slide siger digital tvilling. Den bliver sikrere, når modellen, input, numerisk profil, backend, version og replay-spor er kontrolleret nok til at kunne undersøges.
Der er også en indkøbsvinkel, for selvfølgelig er der det. Hvis hver backend kræver en separat valideringshistorie, bliver hver hardwareændring til en lille gen-certificeringsøvelse. Hvis den samme FMU kan bevises én gang og derefter køres på den target, der passer til den operationelle begrænsning, får teams frihed uden at lade som om, validering er gratis. Sitet formulerer det som at bevise én gang og køre hvor som helst. Den tekniske oversættelse er lidt mindre romantisk: reducér antallet af steder, hvor den samme model kan være uenig med sig selv.
Det er især relevant i Europa. Suverænitet handler ikke kun om, hvor serveren står. Det handler også om, hvorvidt en sikkerhedssag kan inspiceres, gentages og flyttes uden at tigge én leverandør om tilladelse. En åben implementering, deterministisk aritmetik, reproducerbar replay og backend-paritet løser ikke politik alene. De gør den tekniske del mindre afhængig af en black box med et salgsteam tilknyttet.
Hvad man skal gennemgå, før man stoler på det
Det første review-spørgsmål er, hvilke FMI 3.0-flader din model faktisk bruger. Model Exchange, Co-Simulation, Scheduled Execution, clock, afledte størrelser, hændelser, binære variabler, strenge, arrays og afhængigheder er ikke den samme arbejdsbyrde. En simpel FMU og en koblet multi-FMU-simulation lægger forskelligt pres på runtime og orkestrator.
Det andet spørgsmål er, hvilken numerisk profil modellen erklærer, og hvorfor. Hvis svaret er "hvad end der virkede i eksemplet", er det ikke et design. Profilen skal matche range, opløsning, tidsrepræsentation, tolerance og deployment-target. Den skal være synlig nok til, at en reviewer kan udfordre den uden at læse hele solveren.
Det tredje spørgsmål er, hvilke beviser der følger med et resultat. Hvilken kildeversion? Hvilken FMU-version? Hvilken modelDescription? Hvilken Numerus-profil? Hvilken backend? Hvilke orakelkontroller? Hvilken replay-tilstand? Hvilke konformans- eller egenskabstests? Hvis svarene er spredt ud over en wiki og nogens hukommelse, er simulationen endnu ikke klar til at blive betroet i en seriøs arbejdsgang.
Lærdommen
Lærdommen fra Dweve FMI er ikke, at simuleringsstandarder er kedelige. De er kedelige på præcis samme måde, som broer er kedelige, når de bliver stående. FMI giver udvekslingsrammen. Numerus-baseret fixed-point giver den deterministiske aritmetiske holdning. Runtime- og solver-crates får modellen til at tage skridt. Orkestrering forbinder FMU'er uden at lade som om, timing er trivielt. Backends flytter eksekvering til den hardware, der passer til opgaven. Validering gør ensartethed til en gate i stedet for et håb.
Det er arbejdet. Ikke en storslået påstand om, at tal er løst for evigt. Ikke en skinnende demo, hvor alt matcher, fordi kun én sti er testet. Et simuleringssystem, der kender sine formater, erklærer sin numeriske kontrakt, kører på tværs af backends og fejler højlydt, når den samme model holder op med at være den samme model.
Modellen skal ikke udvikle en personlighed. Vi har nok af dem til møderne.