FMI och samma simulering överallt
Modellen ska inte utveckla en personlighet
En simuleringsmodell ska vara tråkig på ett mycket specifikt sätt: samma indata, samma modell, samma utdata. Det låter självklart tills modellen flyttas från en arbetsstation till ett kluster, från en bärbar dator till hardware-in-the-loop, från en kompilator till en annan, eller från ett leverantörsverktyg till en säkerhetsavdelning som inte uppskattar interpretiv dans. Då blir små numeriska skillnader möten. Möten blir avstämningskalkylblad. Avstämningskalkylbladen blir kyrkogården där bra ingenjörseftermiddagar går för att dö.
FMI finns för att göra modellutbyte och co-simulering praktiskt mellan verktyg. Functional Mock-up Interface ger team ett standardiserat sätt att paketera och köra modeller i stället för att manuellt bära med sig ömtålig integrationskod från en simuleringsmiljö till nästa. Det är redan användbart. Men ett standardgränssnitt gör inte automatiskt aritmetiken deterministisk. Traditionella FMI-arbetsflöden vilar ofta på IEEE 754 flyttalsbeteende, plattformsbibliotek, kompilatorval, exekveringsordning och skillnader i backend. För det mesta är det okej. Sedan är det inte okej, och skillnaden upptäcks oftast av någon med en deadline och en min som säger att upphandlingen lovade att detta skulle vara enkelt.
Dweve FMI angriper den tråkiga, dyra delen: reproducerbarhet. Webbplatsen beskriver en Rust-implementering av FMI för Model Exchange och Co-Simulation med deterministisk fixpunktsaritmetik, byggd på Numerus. Implementeringens form är bredare än en demo: en FMI-arbetsyta med flera crates som omfattar modellrepresentation, schemaparsning, import, export, runtime, lösare, orkestrering, minne, backends för CPU, GPU, FPGA, edge- och distribuerad exekvering, FFI, fuzzing, benchmarks, dokumentation och tester. Den är beroende av Numerus-crates för fixpunkts- och decimalaritmetik, plus den gemensamma Dweve-stacken för simulering, loggning, felhantering, transport, tensorer och lagring.
Målet är inte att få simulering att låta mystiskt. Målet är att få samma FMU att sluta berätta lite olika historier bara för att den vaknade på en annan maskin.
FMI ger kuvertet, aritmetiken skriver fortfarande checken
En FMU är ett användbart kuvert. Den bär med sig en modellbeskrivning, binärfiler eller källartefakter, resurser, variabler, tillstånd, klockor, beroenden och tillräckligt med metadata för att ett annat verktyg ska kunna instansiera och stega modellen. FMI 3.0 lägger till rikare klockor, schemalagd exekvering, förbättrad variabeltypning och co-simuleringsmekanismer. Dweve FMIs källkod är organiserad kring det kuvertet: fmi-schema parsar och validerar modellbeskrivningar, fmi-import laddar FMU-arkiv, fmi-export bygger arkiv, fmi-model representerar variabler och modelltillstånd, och fmi-runtime äger livscykel, variabelåtkomst, klockor, händelser, derivator och tillståndsspara eller återställning.
Det kuvertet är nödvändigt, men det räcker inte. Aritmetiken under avgör fortfarande om en körning är reproducerbar. Runtime-dokumentationen säger att fixpunktsaritmetik använder Numerus Q31_32 för deterministisk beräkning. Arbetsytans metadata anger Q31.32 som standardformat för fixpunkt, Dec64_6 som standardformat för decimaltal och Q16.16 för tid. Den offentliga sidan talar om profiler för Q31.32, Q16.16 och Dec64_6, med MPFR som referensväg. Det ger projektet ett tydligt kontrakt: reellvärdesimulering ska mappas till deterministiska numeriska profiler i stället för att låta varje backend improvisera.
Det finns en viktig poäng om ärlighet här. FMI-vända API:er och kompatibilitetsytor kan fortfarande acceptera eller skicka flyttalsvärden eftersom standarden och befintliga verktyg förväntar sig det. Det som spelar roll är inte teatralisk renhet vid varje gränssnitt. Det som spelar roll är att den centrala deterministiska vägen är byggd kring Numerus fixpunktsprofiler och validering mot en högprecisionsreferens där jämförelse är meningsfull. Kantadaptrar kan tala det yttre språket. Det inre kontraktet ska inte bli en axelryckning.
Numerisk profil är ett modellbeslut
Fixpunkt är inte en magisk inställning. En modell som behöver kompakta tidsvärden, en modell med breda fysikaliska intervall och en modell som rapporterar decimala kvantiteter har inte identiska krav. Q16.16, Q31.32 och Dec64_6 är inte klistermärken för en presentation. De är olika kontrakt om intervall, upplösning, representation och var fel får leva.
Det är här simuleringsgrupper ofta blir för slarviga. De behandlar numeriskt beteende som en egenskap hos verktyget snarare än en egenskap hos modellen. Sedan ändras verktyget, eller backend ändras, eller modellen bäddas in, och plötsligt blir det gamla antagandet en valideringsbörda. Dweve FMI gör den numeriska profilen till en del av arkitekturen snarare än bakgrundsväder. Det är mindre glamoröst än en stor demo. Bra. Stora demos förklarar sällan vem som äger avrundningsgränsen.
Solver-craten berättar samma historia. Den exponerar ODE-systemegenskaper, RK4, RKF45, Euler, BDF-orienterad konfiguration, adaptiv stegkontroll, händelsedetektering och deterministisk lösningstid. Runtime-craten äger FMU-livscykeln, händelse- och kontinuerlig-tid-lägen, variabelåtkomst, indata-derivator, riktnings- och adjungerade derivator, Jacobian-cachning, klockor och tillståndsserialisering. Inget av det är användbart om det numeriska lagret inte kan litas på när det flyttas mellan hårdvara. Lösaren kan vara smart. Modellen kan vara elegant. Om samma körning kräver tre avstämningar är elegansen mestadels möbler.
Co-simulering är där små lögner blir dyra
En FMU är redan tillräckligt mycket arbete. Flera FMU:er kopplade tillsammans är där numeriska och operativa misstag blir sociala. En termisk modell matar en styrmodell, styrmodellen matar en aktuatormodell, aktuatormodellen matar en mekanisk modell, och alla hoppas att stegordningen inte tyst skapar nonsens. Co-simulering behöver anslutningshantering, exekveringsordning, datautbyte, stegkoordinering, hantering av algebraiska loopar och ett sätt att säga nej när grafen är fel.
Källkoden har fmi-orchestration för det arbetet. Den hanterar multi-FMU-co-simulering, anslutningar, cykeldetektering, topologisk sortering, partitionsschemaläggning, detektering och lösning av algebraiska loopar, värdehistorik, exekveringsordning, simuleringstid och orkestreringsstatistik. Det finns fmi-cc för kommunikation mellan kopplade FMU:er och fmi-dist för distribuerad exekvering med koordinatorer, nodregistrering, meddelanden, stegförfrågningar, stegsvar och statusvärden. Det är den typen av mekanismer som människor glömmer när de säger att integration bara är att koppla utgångar till ingångar. Det är koppling, ja. Det är också tajming, beroendehantering, tillstånd, fel och bevis på att kopplingen gjorde vad den sa.
Co-simulering gör också att determinism blir viktigare, inte mindre viktig. Om en FMU avviker något och det värdet matas in i en annan FMU kan avvikelsen fortplanta sig. Om exekveringsordningen ändras mellan noder kan avvikelsen ligga dold tills ett senare steg. Om en backend använder en något annorlunda matematisk väg kan avvikelsen se ut som modellbeteende. Så hamnar team i att felsöka fysik med mötesprotokoll. Ingen borde behöva göra det om de inte har varit mycket stygga i ett tidigare liv.
Backends är driftsättningsval, inte nya sanningar
Källträdet delar upp exekveringsmål i backend-crates: CPU, GPU, FPGA, edge och distribuerat. Edge-backend fokuserar på enheter med begränsade resurser, begränsat minne och låg overhead. FPGA-backend handlar om fixpunktsaritmetik, DMA-överföringar, bitströmshantering, kernexekvering och hårdvara-i-loopen. Den distribuerade craten koordinerar flera noder. Den offentliga sidan beskriver CPU SIMD-, GPU-, FPGA-, edge- och distribuerade vägar. Det betyder inte att varje mål är lika moget för varje arbetsbelastning. Det betyder att arkitekturen behandlar backendval som en förstklassig fråga.
Den avgörande designprincipen är att driftsättning ska ändra var simuleringen körs, inte vad simuleringen betyder. En CPU-väg kan vara enklast för författande och verifiering. En GPU-väg kan vara lämplig för stora parallella arbetsbelastningar. En FPGA-väg kan behövas för realtid eller hårdvara-i-loopen. En edge-väg kan behövas nära maskinen. Distribuerad exekvering kan behövas för stora kopplade system. Det är operativa val. De ska inte skapa en ny numerisk identitet för modellen.
Det är också här som öppen källkod spelar roll. Inom säkerhet, energi, robotik, medicinteknik, fordon, flyg, industriell styrning och digitala tvillingar kan reproducerbarhetspåståenden inte bara leva i säljarens bildspel. Någon måste inspektera implementationen, låsa en version, köra testerna, läsa felfallen och avgöra om bevisen räcker. En FMI-implementation med öppen källkod ger team en bättre väg till det beviset. Den certifierar inte magiskt något. Den gör arbetet inspekterbart, vilket är det första användbara steget.
Validering ska vara en grind, inte en instrumentpanel
Dweve FMIs valideringsberättelse handlar inte bara om snygga spårningar. README och webbplatsen beskriver MPFR-referenskontroller, ekvivalens mellan backends, deterministisk uppspelning, konformitetstester, fuzzning och typade fel. Källan har fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, egenskapstester, fuzz-harnessar och tillståndsserialisering. Det är rätt riktning. I simuleringsinfrastruktur ska validering inte vara en instrumentpanel där en röd linje ser oroande ut och någon lovar att hålla koll på den. Den ska vara en grind.
Grinden har flera delar. Import måste tolka FMU-arkivet och modelDescription korrekt. Schemavalidering måste avvisa ogiltiga variabeldefinitioner, beroenden, klockor och attribut. Numeriska kontroller behöver en orakel när påståendet gäller noggrannhet. Backend-paritet behöver samma tillstånd över exekveringsmål. Uppspelning behöver sparat tillstånd och händelseloggar för att återskapa körningen. Fel behöver typade felmeddelanden, inte en mystisk avvikelserapport som skickar teamet på loggspaning. En avvikelse ska blockera en releasestig tills den är förstådd eller uttryckligen accepterad. Det låter hårt bara om alternativet inte har fakturerat dig ännu.
Där detta har betydelse först
De uppenbara domänerna är de där simuleringsfel blir fysiska fel: fordonsindustrin, flyg- och rymdindustrin, industriell styrning, medicintekniska produkter, energi, robotik och infrastruktur. En bromsmodell, pumpstyrenhet, nätmodell, robotcell, fabrikslinje eller HVAC-styrenhet blir inte säkrare för att en bild säger digital tvilling. Den blir säkrare när modellen, indata, numerisk profil, backend, version och reprisspår är kontrollerade nog att kunna undersökas.
Det finns också en upphandlingsvinkel, för det gör det förstås. Om varje backend kräver en separat valideringsberättelse blir varje hårdvaruförändring en liten omcertifieringsövning. Om samma FMU kan bevisas en gång och sedan köras på den målplattform som passar den operativa begränsningen, får team frihet utan att låtsas att validering är gratis. Webbplatsen uttrycker det som att bevisa en gång och köra överallt. Den tekniska översättningen är något mindre romantisk: minska antalet ställen där samma modell kan vara oense med sig själv.
Det är särskilt relevant i Europa. Suveränitet handlar inte bara om var servern står. Det handlar också om huruvida en säkerhetsargumentation kan granskas, upprepas och flyttas utan att tigga en leverantör om tillstånd. En öppen implementation, deterministisk aritmetik, reproducerbar repris och backend-paritet löser inte policyfrågor av sig själva. De gör däremot den tekniska delen mindre beroende av en svart låda med ett säljteam kopplat till sig.
Vad du ska granska innan du litar på det
Den första granskningsfrågan är vilka FMI 3.0-ytor din modell faktiskt använder. Model Exchange, Co-Simulation, Scheduled Execution, klockor, derivator, händelser, binära variabler, strängar, arrayer och beroenden är inte samma arbetsbelastning. En enkel FMU och en kopplad multi-FMU-simulering ställer olika krav på körningen och orkestreraren.
Den andra frågan är vilken numerisk profil modellen deklarerar och varför. Om svaret är vilken standard som helst som fungerade i exemplet, är det ingen design. Profilen bör matcha intervall, upplösning, tidsrepresentation, tolerans och distributionsmål. Den bör vara tillräckligt synlig för att en granskare ska kunna ifrågasätta den utan att läsa hela lösaren.
Den tredje frågan är vilka bevis som följer med ett resultat. Vilken källversion? Vilken FMU-version? Vilken modelDescription? Vilken Numerus-profil? Vilken backend? Vilka orakelkontroller? Vilket repristillstånd? Vilka konformans- eller egenskapsprov? Om svaren är utspridda över en wiki och någons minne, är simuleringen ännu inte redo att litas på i ett seriöst arbetsflöde.
Lärdomen
Lärdomen från Dweve FMI är inte att simuleringsstandarder är tråkiga. De är tråkiga på precis det sätt som broar är tråkiga när de håller. FMI ger utbyteshöljet. Numerus-baserad fixpunkt ger den deterministiska aritmetiska hållningen. Körnings- och lösarkratrar får modellen att stega. Orkestrering kopplar samman FMU:er utan att låtsas att tajming är trivial. Backends flyttar exekvering till den hårdvara som passar uppgiften. Validering gör likhet till en grind i stället för ett hopp.
Det är arbetet. Inte ett storslaget påstående om att siffror är lösta för alltid. Inte en glansig demo där allt stämmer för att bara en väg testades. Ett simuleringssystem som känner sina format, deklarerar sitt numeriska kontrakt, körs över backends och misslyckas högljutt när samma modell slutar vara samma modell.
Modellen ska inte utveckla en personlighet. Vi har nog av dem på möten.