FMI și aceeași simulare peste tot
Modelul nu ar trebui să dezvolte o personalitate
Un model de simulare ar trebui să fie plictisitor într-un mod foarte specific: aceeași intrare, același model, aceeași ieșire. Sună evident până când modelul trece de la o stație de lucru la un cluster, de la un laptop la hardware-in-the-loop, de la un compilator la altul, sau de la un instrument al unui furnizor într-un birou de siguranță care nu apreciază dansul interpretativ. Atunci diferențele numerice minuscule devin întâlniri. Întâlnirile devin foi de calcul pentru reconciliere. Foile de calcul pentru reconciliere devin cimitirul unde după-amiezile bune de inginerie merg să moară.
FMI există pentru a face schimbul de modele și co-simularea practice între instrumente. Functional Mock-up Interface oferă echipelor o modalitate standard de a împacheta și rula modele, în loc să care manual cod de integrare fragil de la un mediu de simulare la altul. Asta este deja util. Dar o interfață standard nu face automat aritmetica deterministă. Fluxurile de lucru FMI tradiționale se bazează adesea pe comportamentul în virgulă mobilă IEEE 754, biblioteci de platformă, alegeri de compilator, ordinea execuției și diferențe de backend. De cele mai multe ori asta este în regulă. Apoi nu mai este în regulă, iar diferența este de obicei descoperită de cineva cu un termen limită și o față care spune că achizițiile au promis că va fi ușor.
Dweve FMI atacă partea plictisitoare și scumpă: reproductibilitatea. Site-ul descrie o implementare FMI în Rust pentru Model Exchange și Co-Simulation cu aritmetică deterministă în virgulă fixă, construită pe Numerus. Forma implementării este mai amplă decât un demo: un spațiu de lucru FMI cu mai multe crate-uri, cu reprezentare de model, parsare de schemă, import, export, runtime, solver, orchestrare, memorie, backend-uri pentru CPU, GPU, FPGA, execuție edge și distribuită, FFI, fuzzing, benchmark-uri, documentație și teste. Depinde de crate-urile Numerus pentru aritmetica în virgulă fixă și zecimală, plus stiva comună Dweve pentru simulare, logare, gestionarea erorilor, transport, tensori și stocare.
Scopul nu este să facă simularea să sune mistic. Scopul este să facă același FMU să nu mai spună povești ușor diferite pentru că s-a trezit pe o mașină diferită.
FMI oferă plicul, dar aritmetica scrie în continuare cecul
Un FMU este un plic util. Transportă o descriere de model, binare sau artefacte sursă, resurse, variabile, stări, ceasuri, dependențe și suficiente metadate pentru ca un alt instrument să instanțieze și să avanseze modelul. FMI 3.0 adaugă ceasuri mai bogate, execuție programată, tipizare îmbunătățită a variabilelor și mecanisme de co-simulare. Sursa Dweve FMI este organizată în jurul acestui plic: fmi-schema parsează și validează descrierile de model, fmi-import încarcă arhive FMU, fmi-export construiește arhive, fmi-model reprezintă variabilele și starea modelului, iar fmi-runtime deține ciclul de viață, accesul la variabile, ceasuri, evenimente, derivate și salvarea sau restaurarea stării.
Acest plic este necesar, dar nu este suficient. Aritmetica de dedesubt decide în continuare dacă o rulare este reproductibilă. Documentația runtime-ului spune că aritmetica în virgulă fixă folosește Numerus Q31_32 pentru calculul determinist. Metadatele spațiului de lucru numesc Q31.32 ca format fix implicit, Dec64_6 ca format zecimal implicit și Q16.16 pentru timp. Pagina publică vorbește despre profilele Q31.32, Q16.16 și Dec64_6, cu MPFR folosit ca rută de referință. Asta oferă proiectului un contract clar: simularea cu valori reale ar trebui mapată în profile numerice deterministe, în loc să lase fiecare backend să improvizeze.
Există un punct important legat de onestitate aici. API-urile și suprafețele de compatibilitate orientate către FMI pot accepta sau emite în continuare valori în virgulă mobilă, deoarece standardul și instrumentele existente le așteaptă. Ceea ce contează nu este o puritate teatrală la fiecare graniță. Ceea ce contează este că traseul determinist de bază este construit în jurul profilelor fixed-point Numerus și al validării față de o referință de înaltă precizie acolo unde comparația are sens. Adaptoarele de la margine pot vorbi limbajul din exterior. Contractul din interior nu ar trebui să devină un ridicat din umeri.
Profilul numeric este o decizie de model
Fixed-point nu este un singur setări magice. Un model care are nevoie de valori de timp compacte, un model cu game fizice largi și un model care raportează cantități zecimale nu au aceeași presiune. Q16.16, Q31.32 și Dec64_6 nu sunt abțibilduri pentru un slide. Sunt contracte diferite despre gamă, rezoluție, reprezentare și despre locul unde erorilor li se permite să existe.
Aici echipele de simulare devin adesea prea relaxate. Tratează comportamentul numeric ca pe o proprietate a instrumentului, nu ca pe o proprietate a modelului. Apoi instrumentul se schimbă, sau backend-ul se schimbă, sau modelul este integrat, și dintr-o dată vechea presupunere devine o povară de validare. Dweve FMI face din profilul numeric o parte a arhitecturii, nu o vreme de fundal. Asta este mai puțin spectaculos decât o demonstrație mare. Bine. Demonstrațiile mari rareori explică cine deține granița de rotunjire.
Crate-ul solver spune aceeași poveste. Expune trăsăturile sistemului ODE, RK4, RKF45, Euler, configurație orientată către BDF, control adaptiv al pasului, detecție de evenimente și timp de solver determinist. Crate-ul runtime deține ciclul de viață FMU, modurile de eveniment și timp continuu, accesul la variabile, derivatele de intrare, derivatele direcționale și adiacente, cache-ul Jacobian, ceasurile și serializarea stării. Nimic din toate acestea nu este util dacă stratul numeric nu poate fi de încredere atunci când se deplasează între hardware-uri. Solver-ul poate fi inteligent. Modelul poate fi elegant. Dacă aceeași rulare are nevoie de trei reconciliări, eleganța este în mare parte mobilier.
Co-simularea este locul unde minciunile mici devin scumpe
Un singur FMU este deja suficient de multă muncă. Mai multe FMU-uri cuplate între ele sunt locul unde greșelile numerice și operaționale devin sociale. Un model termic alimentează un model de control, modelul de control alimentează un model de actuator, modelul de actuator alimentează un model mecanic și toată lumea speră că ordinea pașilor nu creează în liniște nonsens. Co-simularea are nevoie de gestionarea conexiunilor, ordinea de execuție, schimbul de date, coordonarea pașilor, gestionarea buclelor algebrice și o modalitate de a spune nu atunci când graficul este greșit.
Sursa are fmi-orchestration pentru această muncă. Se ocupă de co-simularea multi-FMU, conexiuni, detecția ciclurilor, ordonarea topologică, planificarea partițiilor, detecția și rezolvarea buclelor algebrice, istoricul valorilor, ordinea de execuție, timpul de simulare și statisticile de orchestrare. Există fmi-cc pentru comunicarea între FMU-uri cuplate și fmi-dist pentru execuția distribuită cu coordonatori, înregistrarea nodurilor, mesaje, cereri de pas, răspunsuri de pas și valori de stare. Acesta este genul de mecanism pe care oamenii îl uită atunci când spun că integrarea înseamnă doar conectarea ieșirilor la intrări. Este conectare, da. Este, de asemenea, sincronizare, gestionarea dependențelor, stare, eșec și dovada că conectarea a făcut ceea ce a spus.
Co-simularea face ca determinismul să fie mai important, nu mai puțin. Dacă un FMU deviază ușor și acea valoare alimentează alt FMU, discrepanța se poate propaga. Dacă ordinea de execuție se schimbă între noduri, discrepanța se poate ascunde până la un pas ulterior. Dacă un backend folosește o cale matematică ușor diferită, discrepanța poate părea un comportament al modelului. Așa ajung echipele să depaneze fizica cu procese-verbale de ședință. Nimeni nu ar trebui să fie nevoit să facă asta, decât dacă a fost foarte rău într-o viață anterioară.
Backend-urile sunt alegeri de implementare, nu adevăruri noi
Arborele sursă separă țintele de execuție în crate-uri de backend: CPU, GPU, FPGA, edge și distribuit. Backend-ul edge se concentrează pe dispozitive cu resurse limitate, memorie mărginită și overhead redus. Backend-ul FPGA vorbește despre aritmetică în virgulă fixă, transferuri DMA, gestionarea bitstream-urilor, execuția kernel-urilor și hardware-in-the-loop. Crate-ul distribuit coordonează mai multe noduri. Pagina publică descrie căile CPU SIMD, GPU, FPGA, edge și distribuit. Asta nu înseamnă că fiecare țintă este la fel de matură pentru fiecare sarcină de lucru. Înseamnă că arhitectura tratează alegerea backend-ului ca pe o preocupare de prim rang.
Principiul de design crucial este că implementarea ar trebui să schimbe locul unde rulează simularea, nu ceea ce înseamnă simularea. O cale CPU poate fi cea mai ușoară pentru autorizare și verificare. O cale GPU poate avea sens pentru sarcini paralele mari. O cale FPGA poate fi necesară pentru timp real sau hardware-in-the-loop. O cale edge poate fi necesară lângă mașină. Execuția distribuită poate fi necesară pentru sisteme cuplate mari. Acestea sunt alegeri operaționale. Nu ar trebui să creeze o nouă identitate numerică pentru model.
Aici contează și open source-ul. În siguranță, energie, robotică, dispozitive medicale, automotive, aerospațial, control industrial și gemeni digitali, afirmațiile de reproductibilitate nu pot trăi doar în slide-urile furnizorilor. Cineva trebuie să inspecteze implementarea, să fixeze o versiune, să ruleze testele, să citească cazurile de eșec și să decidă dacă dovezile sunt suficiente. O implementare FMI open source oferă echipelor o cale mai bună către acele dovezi. Nu certifică nimic în mod magic. Face munca inspectabilă, ceea ce este primul pas util.
Validarea ar trebui să fie o poartă, nu un tablou de bord
Povestea validării Dweve FMI nu este doar despre trace-uri frumoase. README-ul și site-ul descriu verificări de referință MPFR, echivalență între backend-uri, redare deterministă, teste de conformitate, fuzzing și eșecuri tipizate. Sursa are fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, teste de proprietate, harness-uri de fuzzing și serializare de stare. Aceasta este direcția corectă. În infrastructura de simulare, validarea nu ar trebui să fie un tablou de bord unde o linie roșie pare îngrijorătoare și cineva promite să o monitorizeze. Ar trebui să fie o poartă.
Poarta are mai multe părți. Importul trebuie să parseze corect arhiva FMU și modelDescription. Validarea schemei trebuie să respingă definiții de variabile, dependențe, ceasuri și atribute invalide. Verificările numerice au nevoie de un oracol când afirmația este despre acuratețe. Paritatea backend-urilor necesită aceeași stare pe toate țintele de execuție. Redarea necesită stare salvată și jurnale de evenimente pentru a reconstrui rularea. Eșecul necesită erori tipizate, nu un raport misterios de nepotrivire care trimite echipa să caute prin jurnale. O nepotrivire ar trebui să blocheze o cale de lansare până când este înțeleasă sau acceptată explicit. Asta sună dur doar dacă alternativa nu ți-a trimis încă factura.
Unde contează acest lucru în primul rând
Domeniile evidente sunt cele în care greșelile de simulare devin greșeli fizice: automotive, aerospațial, control industrial, dispozitive medicale, energie, robotică și infrastructură. Un model de frână, un controler de pompă, un model de rețea electrică, o celulă robotică, o linie de fabricație sau un controler HVAC nu devin mai sigure pentru că un slide spune digital twin. Devin mai sigure atunci când modelul, intrările, profilul numeric, backend-ul, versiunea și traseul de reluare sunt controlate suficient pentru a putea fi investigate.
Există și un unghi de achiziție, pentru că, bineînțeles, există. Dacă fiecare backend necesită o poveste de validare separată, fiecare schimbare de hardware devine un mic exercițiu de re-certificare. Dacă același FMU poate fi dovedit o dată și apoi rulat pe ținta care se potrivește constrângerii operaționale, echipele câștigă libertate fără să pretindă că validarea este gratuită. Site-ul formulează acest lucru ca dovedit o dată și rulat oriunde. Traducerea inginerească este puțin mai puțin romantică: reduceți numărul de locuri în care același model poate fi în dezacord cu el însuși.
Acest lucru este deosebit de relevant în Europa. Suveranitatea nu înseamnă doar unde stă serverul. Înseamnă și dacă un caz de siguranță poate fi inspectat, repetat și mutat fără a cere permisiunea unui singur furnizor. O implementare deschisă, aritmetică deterministă, reluare reproductibilă și paritate a backend-urilor nu rezolvă politica de la sine. Ele fac partea tehnică mai puțin dependentă de o cutie neagră cu o echipă de vânzări atașată.
Ce să revizuiți înainte de a avea încredere
Prima întrebare de revizuire este care suprafețe FMI 3.0 le folosește efectiv modelul dumneavoastră. Model Exchange, Co-Simulation, Scheduled Execution, ceasuri, derivate, evenimente, variabile binare, șiruri, tablouri și dependențe nu sunt aceeași sarcină de lucru. Un FMU simplu și o simulare cuplată cu mai multe FMU-uri pun presiuni diferite asupra runtime-ului și orchestratorului.
A doua întrebare este ce profil numeric declară modelul și de ce. Dacă răspunsul este orice implicit care a funcționat în exemplu, aceasta nu este o proiectare. Profilul ar trebui să se potrivească cu intervalul, rezoluția, reprezentarea timpului, toleranța și ținta de implementare. Ar trebui să fie suficient de vizibil încât un revizor să îl poată contesta fără să citească întregul solver.
A treia întrebare este ce dovezi însoțesc un rezultat. Ce versiune de sursă? Ce versiune de FMU? Ce modelDescription? Ce profil Numerus? Ce backend? Ce verificări oracol? Ce stare de reluare? Ce teste de conformitate sau de proprietate? Dacă aceste răspunsuri sunt împrăștiate într-un wiki și în memoria cuiva, simularea nu este încă pregătită să fie de încredere într-un flux de lucru serios.
Lecția
Lecția Dweve FMI nu este că standardele de simulare sunt plictisitoare. Sunt plictisitoare exact în felul în care podurile sunt plictisitoare când rămân în picioare. FMI oferă plicul de schimb. Punctul fix susținut de Numerus oferă postura aritmeticii deterministe. Cratele de runtime și solver fac modelul să pășească. Orchestrarea conectează FMU-urile fără să pretindă că sincronizarea este banală. Backend-urile mută execuția pe hardware-ul care se potrivește sarcinii. Validarea transformă identitatea într-o poartă, nu într-o speranță.
Aceasta este munca. Nu o afirmație grandioasă că numerele sunt rezolvate pentru totdeauna. Nu o demonstrație strălucitoare în care totul se potrivește pentru că a fost testată o singură cale. Un sistem de simulare care își cunoaște formatele, își declară contractul numeric, rulează pe mai multe backend-uri și eșuează zgomotos atunci când același model încetează să fie același model.
Modelul nu ar trebui să dezvolte o personalitate. Avem destule în întâlniri.