FMI i ista simulacija svugdje
Model ne bi smio razviti osobnost
Simulacijski model trebao bi biti dosadan na jedan vrlo specifičan način: isti ulaz, isti model, isti izlaz. To zvuči očito sve dok se model ne preseli s radne stanice na klaster, s prijenosnika na hardware-in-the-loop, s jednog prevoditelja na drugi ili iz alata proizvođača u odjel za sigurnost koji ne cijeni interpretativni ples. Tada male numeričke razlike postanu sastanci. Sastanci postanu tablice za usklađivanje. Tablice za usklađivanje postanu groblje na kojem umiru dobri inženjerski poslijepodnevi.
FMI postoji kako bi razmjena modela i kosimulacija bili praktični među alatima. Functional Mock-up Interface timovima daje standardan način pakiranja i pokretanja modela umjesto ručnog prenošenja fragilnog integracijskog koda iz jednog simulacijskog okruženja u drugo. To je već korisno. No standardno sučelje ne čini aritmetiku automatski determinističkom. Tradicionalni FMI tijekovi rada često ovise o ponašanju IEEE 754 pomičnog zareza, bibliotekama platforme, izboru prevoditelja, redoslijedu izvršavanja i razlikama u pozadinskim sustavima. Većinom je to u redu. A onda nije u redu, a razliku obično otkrije netko s rokom i izrazom lica koji govori da je nabava obećala da će to biti jednostavno.
Dweve FMI napada dosadni, skupi dio: ponovljivost. Stranica opisuje FMI implementaciju u Rustu za Model Exchange i Co-Simulation s determinističkom aritmetikom fiksne točke, izgrađenu na Numerusu. Oblik implementacije širi je od demonstracije: višestruki FMI radni prostor s prikazom modela, parsiranjem sheme, uvozom, izvozom, izvođenjem, rješavačem, orkestracijom, memorijom, pozadinskim sustavima za CPU, GPU, FPGA, rubno i distribuirano izvođenje, FFI, fuzzingom, mjerilima, dokumentacijom i testovima. Ovisi o Numerus bibliotekama za aritmetiku fiksne točke i decimalnu aritmetiku, uz uobičajeni Dweve složeni okvir za simulaciju, zapisivanje, obradu pogrešaka, prijenos, tenzore i pohranu.
Cilj nije učiniti simulaciju mističnom. Cilj je spriječiti da isti FMU priča malo drugačije priče jer se probudio na drugom računalu.
FMI daje omotnicu, aritmetika još uvijek piše ček
FMU je korisna omotnica. Nosi opis modela, binarne datoteke ili izvorne artefakte, resurse, varijable, stanja, satove, ovisnosti i dovoljno metapodataka da drugi alat može instancirati i pokretati model. FMI 3.0 dodaje bogatije satove, planirano izvršavanje, poboljšano tipiziranje varijabli i mehanizme kosimulacije. Izvorni kod Dweve FMI-ja organiziran je oko te omotnice: fmi-schema parsira i validira opise modela, fmi-import učitava FMU arhive, fmi-export gradi arhive, fmi-model predstavlja varijable i stanje modela, a fmi-runtime upravlja životnim ciklusom, pristupom varijablama, satovima, događajima, derivacijama i spremanjem ili vraćanjem stanja.
Ta omotnica je nužna, ali nije dovoljna. Aritmetika ispod nje i dalje odlučuje je li izvođenje ponovljivo. Dokumentacija izvođenja kaže da aritmetika fiksne točke koristi Numerus Q31_32 za determinističko računanje. Metapodaci radnog prostora navode Q31.32 kao zadani format fiksne točke, Dec64_6 kao zadani decimalni format i Q16.16 za vrijeme. Javna stranica govori o profilima Q31.32, Q16.16 i Dec64_6, s MPFR-om kao referentnom rutom. To projektu daje jasan ugovor: simulacija s realnim vrijednostima trebala bi se preslikati u determinističke numeričke profile umjesto da svaki pozadinski sustav improvizira.
Ovdje postoji važna točka poštenja. Sučelja okrenuta prema FMI-ju i površine kompatibilnosti i dalje mogu prihvaćati ili emitirati vrijednosti s pomičnim zarezom jer ih standard i postojeći alati očekuju. Tvrdnja koja je bitna nije teatralna čistoća na svakoj granici. Bitna je tvrdnja da je temeljni deterministički put izgrađen oko Numerus profilâ fiksne točke i validacije prema referenci visoke preciznosti tamo gdje je usporedba smislena. Rubni adapteri mogu govoriti vanjskim jezikom. Unutarnji ugovor ne smije postati odmahivanje rukom.
Numerički profil odluka je modela
Fiksna točka nije jedan čarobni postav. Model kojem trebaju kompaktne vremenske vrijednosti, model sa širokim fizičkim rasponima i model koji izvještava decimalne količine nemaju identičan pritisak. Q16.16, Q31.32 i Dec64_6 nisu naljepnice za slajd. Riječ je o različitim ugovorima o rasponu, rezoluciji, reprezentaciji i tome gdje je pogreškama dopušteno živjeti.
Ovdje simulacijski timovi često postanu previše ležerni. Numeričko ponašanje tretiraju kao svojstvo alata, a ne kao svojstvo modela. Zatim se alat promijeni, ili se pozadinski sustav promijeni, ili se model ugradi, i odjednom stara pretpostavka postane teret validacije. Dweve FMI čini numerički profil dijelom arhitekture, a ne pozadinskim vremenom. To je manje glamurozno od velike demonstracije. Dobro. Velike demonstracije rijetko objašnjavaju tko je vlasnik granice zaokruživanja.
Crate solvera priča istu priču. Izlaže osobine ODE sustava, RK4, RKF45, Euler, BDF-orijentiranu konfiguraciju, adaptivnu kontrolu koraka, detekciju događaja i determinističko vrijeme solvera. Runtime crate posjeduje životni ciklus FMU-ja, načine rada s događajima i kontinuiranim vremenom, pristup varijablama, derivacije ulaza, usmjerene i adjungirane derivacije, predmemoriranje Jacobijana, satove i serijalizaciju stanja. Ništa od toga nije korisno ako se numeričkom sloju ne može vjerovati kada se kreće kroz hardver. Solver može biti pametan. Model može biti elegantan. Ako isto izvođenje zahtijeva tri usklađivanja, elegancija je uglavnom namještaj.
Ko-simulacija je mjesto gdje male laži postaju skupe
Jedan FMU već je dovoljno posla. Nekoliko povezanih FMU-jeva mjesto je gdje numeričke i operativne pogreške postaju društveni problem. Toplinski model hrani upravljački model, upravljački model hrani model aktuatora, model aktuatora hrani mehanički model, i svi se nadaju da redoslijed koraka tiho ne stvara besmislicu. Ko-simulacija treba upravljanje vezama, redoslijed izvođenja, razmjenu podataka, koordinaciju koraka, rukovanje algebarskim petljama i način da se kaže ne kada je graf pogrešan.
Izvorni kod ima fmi-orchestration za taj posao. Ona upravlja ko-simulacijom s više FMU-jeva, vezama, detekcijom ciklusa, topološkim sortiranjem, raspoređivanjem particija, detekcijom i rješavanjem algebarskih petlji, poviješću vrijednosti, redoslijedom izvođenja, vremenom simulacije i statistikom orkestracije. Postoji fmi-cc za komunikaciju između povezanih FMU-jeva i fmi-dist za distribuirano izvođenje s koordinatorima, registracijom čvorova, porukama, zahtjevima za korak, odgovorima na korak i vrijednostima statusa. To je vrsta mehanizma koju ljudi zaborave kada kažu da je integracija samo povezivanje izlaza s ulazima. Povezivanje je, da. Također je i vremensko usklađivanje, upravljanje ovisnostima, stanje, kvar i dokaz da je povezivanje učinilo ono što je reklo.
Ko-simulacija također čini determinizam važnijim, a ne manje važnim. Ako jedan FMU malo odstupa i ta se vrijednost proslijedi drugom FMU-u, neslaganje se može proširiti. Ako se redoslijed izvršavanja promijeni među čvorovima, neslaganje se može sakriti do kasnijeg koraka. Ako jedan pozadinski mehanizam koristi malo drugačiji matematički put, neslaganje može izgledati kao ponašanje modela. Tako timovi završe debugirajući fiziku uz zapisnike sa sastanaka. Nitko to ne bi trebao morati raditi osim ako nije bio jako loš u prošlom životu.
Pozadinski mehanizmi su izbori implementacije, a ne nove istine
Stablo izvornog koda odvaja ciljeve izvršavanja u crate-ove pozadinskih mehanizama: CPU, GPU, FPGA, edge i distribuirano. Edge pozadinski mehanizam fokusira se na uređaje s ograničenim resursima, ograničenu memoriju i niske režijske troškove. FPGA pozadinski mehanizam bavi se aritmetikom fiksne točke, DMA prijenosima, upravljanjem bitstreamom, izvršavanjem jezgri i hardverom u petlji. Distribuirani crate koordinira više čvorova. Javna stranica opisuje CPU SIMD, GPU, FPGA, edge i distribuirane putove. To ne znači da je svaki cilj jednako zreo za svako radno opterećenje. To znači da arhitektura tretira izbor pozadinskog mehanizma kao pitanje od prvorazredne važnosti.
Ključni dizajnerski princip je da implementacija treba promijeniti gdje se simulacija izvodi, a ne što simulacija znači. CPU put može biti najlakši za autorstvo i verifikaciju. GPU put može imati smisla za velika paralelna radna opterećenja. FPGA put može biti potreban za rad u stvarnom vremenu ili hardver u petlji. Edge put može biti potreban u blizini stroja. Distribuirano izvršavanje može biti potrebno za velike povezane sustave. To su operativni izbori. Ne bi trebali stvoriti novi numerički identitet za model.
Ovo je također mjesto gdje je otvoreni kod važan. U sigurnosti, energetici, robotici, medicinskim uređajima, automobilskoj industriji, zrakoplovstvu, industrijskom upravljanju i digitalnim blizancima, tvrdnje o ponovljivosti ne mogu živjeti samo u prodajnim prezentacijama dobavljača. Netko mora pregledati implementaciju, zaključati verziju, pokrenuti testove, pročitati slučajeve pogrešaka i odlučiti je li dokaz dovoljno dobar. Implementacija FMI-ja otvorenog koda daje timovima bolji put do tog dokaza. Ona ništa ne certificira magično. Čini rad preglednim, što je prvi koristan korak.
Validacija bi trebala biti vrata, a ne nadzorna ploča
Priča o validaciji Dweve FMI-ja nije samo o lijepim tragovima. README i stranica opisuju MPFR referentne provjere, ekvivalentnost među pozadinskim mehanizmima, determinističku reprodukciju, testove usklađenosti, fuzzing i tipizirane pogreške. Izvorni kod sadrži fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, testove svojstava, fuzz harnessove i serijalizaciju stanja. To je ispravan smjer. U infrastrukturi simulacije, validacija ne bi trebala biti nadzorna ploča na kojoj crvena linija izgleda zabrinjavajuće i netko obeća da će je pratiti. Trebala bi biti vrata.
Ta vrata imaju nekoliko dijelova. Uvoz mora ispravno parsirati FMU arhivu i modelDescription. Validacija sheme mora odbiti nevažeće definicije varijabli, ovisnosti, satove i atribute. Numeričke provjere trebaju oracle kada je tvrdnja točnost. Paritet pozadinskih mehanizama treba isto stanje na svim ciljevima izvršavanja. Reprodukcija treba spremljeno stanje i zapise događaja za ponovnu izgradnju pokretanja. Pogreška treba tipizirane pogreške, a ne tajanstveno izvješće o nepodudarnosti koje šalje tim u istraživanje kroz zapisnike. Nepodudarnost bi trebala blokirati put izdanja dok se ne razumije ili izričito prihvati. To zvuči strogo samo ako vam alternativa još nije naplatila uslugu.
Gdje je to najprije važno
Očita područja su ona gdje pogreške u simulaciji postaju fizičke pogreške: automobilska industrija, zrakoplovstvo, industrijska regulacija, medicinski uređaji, energetika, robotika i infrastruktura. Model kočnice, upravljač pumpe, model mreže, robotska ćelija, tvornička linija ili upravljač HVAC-a ne postaju sigurniji zato što slajd kaže digitalni blizanac. Postaju sigurniji kada su model, ulazi, numerički profil, pozadinski sustav, verzija i trag ponavljanja dovoljno kontrolirani da se mogu istražiti.
Postoji i kut nabave, jer naravno da postoji. Ako svaki pozadinski sustav zahtijeva zasebnu priču o validaciji, svaka promjena hardvera postaje mali postupak ponovne certifikacije. Ako se isti FMU može dokazati jednom, a zatim pokrenuti na ciljnom sustavu koji odgovara operativnim ograničenjima, timovi dobivaju slobodu bez pretvaranja da je validacija besplatna. Stranica to formulira kao dokazati jednom i pokrenuti bilo gdje. Inženjerski prijevod je nešto manje romantičan: smanjiti broj mjesta gdje se isti model može razilaziti sa samim sobom.
To je posebno relevantno u Europi. Suverenitet nije samo pitanje gdje se poslužitelj nalazi. To je također pitanje može li se sigurnosni slučaj pregledati, ponoviti i premjestiti bez moljakanja jednog dobavljača za dopuštenje. Otvorena implementacija, deterministička aritmetika, ponovljivo ponavljanje i paritet pozadinskih sustava ne rješavaju politiku sami po sebi. Oni čine tehnički dio manje ovisnim o crnoj kutiji s prodajnim timom.
Što pregledati prije nego što mu vjerujete
Prvo pitanje pregleda je koje FMI 3.0 površine vaš model zapravo koristi. Model Exchange, Co-Simulation, Scheduled Execution, satovi, derivacije, događaji, binarne varijable, nizovi znakova, polja i ovisnosti nisu isti radni teret. Jednostavan FMU i povezana simulacija s više FMU-a stavljaju različit pritisak na izvođačko okruženje i orkestrator.
Drugo pitanje je koji numerički profil model deklarira i zašto. Ako je odgovor ono što je zadano radilo u primjeru, to nije dizajn. Profil bi trebao odgovarati rasponu, razlučivosti, prikazu vremena, toleranciji i ciljnom sustavu implementacije. Trebao bi biti dovoljno vidljiv da ga recenzent može dovesti u pitanje bez čitanja cijelog rješavača.
Treće pitanje je koji dokazi putuju s rezultatom. Koja verzija izvora? Koja verzija FMU-a? Koji modelDescription? Koji Numerus profil? Koji pozadinski sustav? Koje provjere oraclea? Koje stanje ponavljanja? Koji testovi usklađenosti ili svojstava? Ako su ti odgovori razbacani po wikiju i nečijem sjećanju, simulacija još nije spremna za povjerenje u ozbiljnom radnom procesu.
Pouka
Pouka Dweve FMI nije da su standardi simulacije dosadni. Oni su dosadni na točno onaj način na koji su mostovi dosadni kada ostaju stabilni. FMI daje okvir za razmjenu. Numerus-podržana fiksna točka daje deterministički aritmetički stav. Izvođačko okruženje i rješavačke biblioteke čine korak modela. Orkestracija povezuje FMU-ove bez pretvaranja da je vremenski raspored trivijalan. Pozadinski sustavi premještaju izvođenje na hardver koji odgovara zadatku. Validacija pretvara istovjetnost u vrata umjesto u nadu.
To je posao. Ne velika tvrdnja da su brojevi zauvijek riješeni. Ne sjajna demonstracija gdje se sve podudara jer je testiran samo jedan put. Simulacijski sustav koji poznaje svoje formate, deklarira svoj numerički ugovor, radi na različitim pozadinskim sustavima i glasno ne uspijeva kada isti model prestane biti isti model.
Model ne bi trebao razviti osobnost. Imamo ih dovoljno na sastancima.