FMI in ista simulacija povsod
Model ne sme razviti osebnosti
Simulacijski model mora biti dolgočasen na en zelo specifičen način: enak vhod, enak model, enak izhod. To se sliši samoumevno, dokler se model ne preseli z delovne postaje na gručo, s prenosnika v okolje s strojno opremo v zanki, z enega prevajalnika na drugega ali iz orodja dobavitelja v varnostni oddelek, ki ne ceni interpretativnega plesa. Potem majhne numerične razlike postanejo sestanki. Sestanki postanejo preglednice za usklajevanje. Preglednice za usklajevanje postanejo pokopališče, kjer umirajo dobri inženirski popoldnevi.
FMI obstaja zato, da izmenjava modelov in skupna simulacija postaneta praktični v različnih orodjih. Functional Mock-up Interface ekipam ponuja standarden način pakiranja in izvajanja modelov, namesto da bi ročno prenašale krhko integracijsko kodo iz enega simulacijskega okolja v drugo. To je že koristno. Toda standardni vmesnik samodejno ne zagotovi deterministične aritmetike. Tradicionalni poteki FMI pogosto temeljijo na obnašanju plavajoče vejice IEEE 754, knjižnicah platforme, izbiri prevajalnika, vrstnem redu izvajanja in razlikah v zaledju. Večino časa je to v redu. Potem ni več v redu, razliko pa običajno odkrije nekdo z rokom in obrazom, ki pove, da je nabava obljubila, da bo to enostavno.
Dweve FMI napada dolgočasni, dragi del: ponovljivost. Spletno mesto opisuje implementacijo FMI v jeziku Rust za izmenjavo modelov in skupno simulacijo z deterministično aritmetiko fiksne vejice, zgrajeno na Numerus. Oblika implementacije je širša od predstavitve: večdelni prostor FMI s predstavitvijo modela, razčlenjevanjem sheme, uvozom, izvozom, izvajalnim okoljem, reševalcem, orkestracijo, pomnilnikom, zaledji za CPU, GPU, FPGA, robno in porazdeljeno izvajanje, FFI, fuzzing, merili uspešnosti, dokumentacijo in testi. Odvisen je od Numerusovih paketov za aritmetiko fiksne in decimalne vejice ter skupnega sklada Dweve za simulacijo, beleženje, obravnavo napak, prenos, tenzorje in shranjevanje.
Cilj ni narediti simulacije mistične. Cilj je, da isti FMU preneha pripovedovati nekoliko drugačne zgodbe, ker se je prebudil na drugem računalniku.
FMI daje ovojnico, aritmetika še vedno piše ček
FMU je uporabna ovojnica. Nosijo opis modela, binarne datoteke ali izvorne artefakte, vire, spremenljivke, stanja, ure, odvisnosti in dovolj metapodatkov, da lahko drugo orodje instancira in koraka model. FMI 3.0 dodaja bogatejše ure, načrtovano izvajanje, izboljšano tipizacijo spremenljivk in mehanizme za skupno simulacijo. Izvorna koda Dweve FMI je organizirana okoli te ovojnice: fmi-schema razčlenjuje in potrjuje opise modelov, fmi-import nalaga arhive FMU, fmi-export gradi arhive, fmi-model predstavlja spremenljivke in stanje modela, fmi-runtime pa upravlja življenjski cikel, dostop do spremenljivk, ure, dogodke, odvode ter shranjevanje ali obnovitev stanja.
Ta ovojnica je nujna, vendar ni zadostna. Aritmetika pod njo še vedno odloča, ali je izvajanje ponovljivo. Dokumentacija izvajalnega okolja pravi, da aritmetika fiksne vejice uporablja Numerus Q31_32 za deterministično računanje. Metapodatki delovnega prostora imenujejo Q31.32 kot privzeti format fiksne vejice, Dec64_6 kot privzeti decimalni format in Q16.16 za čas. Javna stran govori o profilih Q31.32, Q16.16 in Dec64_6, pri čemer se MPFR uporablja kot referenčna pot. To projektu daje jasno pogodbo: simulacija z realnimi vrednostmi mora biti preslikana v deterministične numerične profile, namesto da vsako zaledje prepusti improvizaciji.
Tu je pomembna točka poštenosti. Vmesniki, namenjeni FMI, in površine združljivosti lahko še vedno sprejemajo ali oddajajo vrednosti s plavajočo vejico, ker to pričakujeta standard in obstoječa orodja. Bistvena trditev ni teatralna čistost na vsaki meji. Bistvena trditev je, da je osrednja deterministična pot zgrajena okoli profilov fiksne vejice Numerus in validacije proti visoko natančni referenci, kjer je primerjava smiselna. Robni adapterji lahko govorijo jezik zunanjega sveta. Notranja pogodba ne sme postati brezbrižnost.
Numerični profil je odločitev modela
Fiksna vejica ni ena čarobna nastavitev. Model, ki potrebuje kompaktne časovne vrednosti, model s širokimi fizikalnimi razponi in model, ki poroča decimalne količine, nimajo enakih pritiskov. Q16.16, Q31.32 in Dec64_6 niso nalepke za predstavitev. So različne pogodbe o razponu, ločljivosti, predstavitvi in o tem, kje lahko živijo napake.
Tu so simulacijske ekipe pogosto preveč sproščene. Numerično obnašanje obravnavajo kot lastnost orodja in ne kot lastnost modela. Potem se orodje spremeni, ali se ozadje spremeni, ali se model vgradi, in nenadoma stara predpostavka postane breme validacije. Dweve FMI naredi numerični profil del arhitekture in ne ozadja. To je manj glamurozno kot velika predstavitev. Dobro. Velike predstavitve le redko pojasnijo, kdo je lastnik meje zaokroževanja.
Zbirka reševalca pripoveduje isto zgodbo. Izpostavlja lastnosti sistemov ODE, RK4, RKF45, Euler, konfiguracijo, usmerjeno v BDF, prilagodljiv nadzor korakov, zaznavanje dogodkov in deterministični čas reševalca. Zbirka izvajalnega okolja upravlja življenjski cikel FMU, načina dogodkov in neprekinjenega časa, dostop do spremenljivk, vhodne odvode, smerne in adjungirane odvode, predpomnjenje Jakobijevih matrik, ure in serializacijo stanja. Nič od tega ni uporabno, če numerični sloj ni zaupanja vreden, ko se premika po strojni opremi. Reševalec je lahko pameten. Model je lahko eleganten. Če isti zagon potrebuje tri usklajevanja, je elegance večinoma pohištvo.
Pri skupni simulaciji majhne laži postanejo drage
Eden FMU je že dovolj dela. Več povezanih FMU je tam, kjer numerične in operativne napake postanejo družbene. Toplotni model napaja krmilni model, krmilni model napaja model aktuatorja, model aktuatorja napaja mehanski model in vsi upajo, da vrstni red korakov tiho ne ustvarja nesmisla. Skupna simulacija potrebuje upravljanje povezav, vrstni red izvajanja, izmenjavo podatkov, usklajevanje korakov, obravnavo algebraičnih zank in način, kako reči ne, ko je graf napačen.
Vir ima fmi-orchestration za to delo. Upravlja skupno simulacijo več FMU, povezave, zaznavanje ciklov, topološko razvrščanje, načrtovanje particij, zaznavanje in reševanje algebraičnih zank, zgodovino vrednosti, vrstni red izvajanja, simulacijski čas in statistiko orkestracije. Obstaja fmi-cc za komunikacijo med povezanimi FMU in fmi-dist za porazdeljeno izvajanje s koordinatorji, registracijo vozlišč, sporočili, zahtevami po korakih, odzivi na korake in statusnimi vrednostmi. To je vrsta mehanizmov, na katere ljudje pozabijo, ko rečejo, da je integracija samo povezovanje izhodov z vhodi. Je povezovanje, da. Je tudi časovna uskladitev, upravljanje odvisnosti, stanje, napake in dokaz, da je povezovanje naredilo, kar je obljubilo.
Ko-simulacija tudi povečuje pomen determinizma, ne zmanjšuje ga. Če en FMU nekoliko odstopa in ta vrednost vpliva na drug FMU, se lahko neskladje razširi. Če se vrstni red izvajanja spremeni med vozlišči, lahko neskladje ostane skrito do poznejšega koraka. Če ena zaledna rešitev uporablja nekoliko drugačno matematično pot, je lahko neskladje videti kot obnašanje modela. Tako ekipe končajo pri razhroščevanju fizike s pomočjo zapisnikov sestankov. Tega ne bi smel početi nihče, razen če je bil v prejšnjem življenju zelo poreden.
Zaledne rešitve so izbire uvajanja, ne nove resnice
Izvorno drevo ločuje izvedbene cilje na zaledne crate-e: CPU, GPU, FPGA, rob in porazdeljeno. Robna zaledna rešitev se osredotoča na naprave z omejenimi viri, omejen pomnilnik in nizko obremenitev. Zaledna rešitev FPGA obravnava aritmetiko s fiksno vejico, prenose DMA, upravljanje bitstreamov, izvajanje jeder in strojno v zanki. Porazdeljeni crate usklajuje več vozlišč. Javna stran opisuje poti CPU SIMD, GPU, FPGA, rob in porazdeljeno. To ne pomeni, da je vsak cilj enako zrel za vsako delovno obremenitev. Pomeni, da arhitektura obravnava izbiro zaledne rešitve kot prvovrstno zadevo.
Ključno oblikovalsko načelo je, da bi moralo uvajanje spremeniti, kje simulacija teče, ne kaj simulacija pomeni. Pot CPU je morda najlažja za avtorstvo in preverjanje. Pot GPU je morda smiselna za velike vzporedne delovne obremenitve. Pot FPGA je morda potrebna za delovanje v realnem času ali strojno v zanki. Robna pot je morda potrebna blizu stroja. Porazdeljeno izvajanje je morda potrebno za velike sklopljene sisteme. To so operativne izbire. Ne bi smele ustvariti nove numerične identitete za model.
Tu je tudi pomemben odprtokodni vidik. Na področjih varnosti, energije, robotike, medicinskih pripomočkov, avtomobilske industrije, letalstva, industrijskega krmiljenja in digitalnih dvojčkov trditve o ponovljivosti ne morejo živeti samo v prodajnih predstavitvah. Nekdo mora pregledati implementacijo, določiti različico, zagnati teste, prebrati primere napak in se odločiti, ali so dokazi dovolj dobri. Odprtokodna implementacija FMI daje ekipam boljšo pot do teh dokazov. Ničesar ne certificira čudežno. Omogoča preglednost dela, kar je prvi koristen korak.
Preverjanje bi moralo biti vrata, ne nadzorna plošča
Zgodba o preverjanju Dweve FMI ni samo o lepih sledeh. README in spletno mesto opisujejo referenčne preglede MPFR, enakovrednost med zalednimi rešitvami, deterministično ponovitev, teste skladnosti, fuzzing in tipizirane napake. Izvorna koda vsebuje fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, teste lastnosti, fuzz harnesse in serializacijo stanja. To je prava smer. V infrastrukturi za simulacijo preverjanje ne bi smelo biti nadzorna plošča, kjer je rdeča črta videti zaskrbljujoča in nekdo obljubi, da jo bo spremljal. Moral bi biti vrata.
Vrata imajo več delov. Uvoz mora pravilno razčleniti arhiv FMU in modelDescription. Preverjanje sheme mora zavrniti neveljavne definicije spremenljivk, odvisnosti, ure in atribute. Numerični pregledi potrebujejo oracle, ko gre za natančnost. Enakovrednost zalednih rešitev potrebuje enako stanje v vseh izvedbenih ciljih. Ponovitev potrebuje shranjeno stanje in dnevnike dogodkov za obnovo zagona. Napake potrebujejo tipizirana sporočila, ne skrivnostnega poročila o neskladju, ki pošlje ekipo na raziskovanje dnevnikov. Neskladje bi moralo blokirati pot izdaje, dokler ni razumljeno ali izrecno sprejeto. To se sliši ostro le, če vam alternativa še ni zaračunala.
Kje je to najprej pomembno
Očitna področja so tista, kjer se napake pri simulaciji spremenijo v fizične napake: avtomobilska industrija, letalstvo in vesolje, industrijska regulacija, medicinske naprave, energetika, robotika in infrastruktura. Zavorni model, krmilnik črpalke, model omrežja, robotska celica, proizvodna linija ali krmilnik HVAC ne postane varnejši zato, ker diapozitiv pravi digitalni dvojček. Varnejši postane, ko so model, vhodi, numerični profil, zaledje, različica in sled ponovitev dovolj nadzorovani za preiskavo.
Obstaja tudi nabavni vidik, ker seveda obstaja. Če vsako zaledje zahteva svojo zgodbo o validaciji, vsaka sprememba strojne opreme postane majhna vaja ponovnega certificiranja. Če je mogoče isti FMU dokazati enkrat in ga nato zagnati na ciljni napravi, ki ustreza operativnim omejitvam, ekipe dobijo svobodo, ne da bi se pretvarjale, da je validacija brezplačna. Spletno mesto to opisuje kot dokazati enkrat in zagnati kjer koli. Inženirski prevod je nekoliko manj romantičen: zmanjšati število mest, kjer lahko isti model nasprotuje samemu sebi.
To je še posebej pomembno v Evropi. Suverenost ni le v tem, kje strežnik stoji. Je tudi v tem, ali je mogoče varnostni primer pregledati, ponoviti in prenesti brez prošnje enemu dobavitelju za dovoljenje. Odprta implementacija, deterministična aritmetika, ponovljiva ponovitev in pariteta zaledij sami po sebi ne rešijo politike. Vendar naredijo tehnični del manj odvisen od črne škatle s prodajno ekipo.
Kaj pregledati, preden mu zaupate
Prvo vprašanje pri pregledu je, katere površine FMI 3.0 vaš model dejansko uporablja. Model Exchange, Co-Simulation, Scheduled Execution, ure, odvodi, dogodki, binarne spremenljivke, nizi, polja in odvisnosti niso enaka obremenitev. Preprost FMU in sklopljena simulacija z več FMU postavljata različne zahteve pred izvajalno okolje in orkestrator.
Drugo vprašanje je, kateri numerični profil model deklarira in zakaj. Če je odgovor karkoli, kar je delovalo v primeru, to ni zasnova. Profil mora ustrezati obsegu, ločljivosti, predstavitvi časa, toleranci in ciljni napravi. Biti mora dovolj viden, da ga lahko pregledovalec izpodbija brez branja celotnega reševalnika.
Tretje vprašanje je, kateri dokazi spremljajo rezultat. Katera različica izvorne kode? Katera različica FMU? Kateri modelDescription? Kateri profil Numerus? Katero zaledje? Katera preverjanja z orakljem? Katero stanje ponovitve? Kateri testi skladnosti ali lastnosti? Če so ti odgovori raztreseni po wikiju in spominu nekoga, simulacija še ni pripravljena na zaupanje v resnem delovnem toku.
Nauk
Nauk Dweve FMI ni v tem, da so standardi simulacije dolgočasni. Dolgočasni so natanko tako, kot so mostovi dolgočasni, ko stojijo. FMI zagotavlja ovojnico izmenjave. Fiksna točka s podporo Numerus daje deterministično aritmetično držo. Zabojniki izvajalnega okolja in reševalnika naredijo korak modela. Orkestracija povezuje FMU, ne da bi se pretvarjala, da je časovanje trivialno. Zaledja premaknejo izvajanje na strojno opremo, ki ustreza nalogi. Validacija spremeni enakost v vrata namesto v upanje.
To je delo. Ne velika trditev, da so številke za vedno rešene. Ne bleščeča predstavitev, kjer se vse ujema, ker je bila preizkušena le ena pot. Simulacijski sistem, ki pozna svoje formate, deklarira svojo numerično pogodbo, deluje v različnih zaledjih in glasno odpove, ko isti model preneha biti isti model.
Model ne bi smel razviti osebnosti. Teh imamo na sestankih dovolj.