FMI és ugyanaz a szimuláció mindenhol
A modell ne alakítson ki személyiséget
Egy szimulációs modellnek egy nagyon konkrét értelemben kell unalmasnak lennie: ugyanaz a bemenet, ugyanaz a modell, ugyanaz a kimenet. Ez addig nyilvánvalónak hangzik, amíg a modell át nem költözik egy munkaállomásról egy klaszterre, egy laptopról hardware-in-the-loop környezetbe, egyik fordítóról a másikra, vagy egy gyártói eszközből egy biztonsági osztályra, amely nem értékeli az interpretatív táncot. Aztán apró numerikus eltérésekből megbeszélések lesznek. A megbeszélésekből egyeztető táblázatok. Az egyeztető táblázatokból pedig az a temető, ahol a jó mérnöki délutánok elhalnak.
Az FMI azért létezik, hogy a modellcsere és a ko-szimuláció gyakorlatias legyen az eszközök között. A Functional Mock-up Interface szabványos módot ad a csapatoknak a modellek csomagolására és futtatására, ahelyett, hogy törékeny integrációs kódot cipelnének kézzel egyik szimulációs környezetből a másikba. Ez már önmagában hasznos. De egy szabványos interfész nem teszi automatikusan determinisztikussá az aritmetikát. A hagyományos FMI-munkafolyamatok gyakran az IEEE 754 lebegőpontos viselkedésére, platformkönyvtárakra, fordítóválasztásra, végrehajtási sorrendre és háttérrendszer-különbségekre épülnek. Ez legtöbbször rendben is van. Aztán egyszer csak nincs rendben, és a különbséget általában olyasvalaki fedezi fel, akinek határideje van, és az arcáról leolvasható, hogy a beszerzés azt ígérte, ez könnyű lesz.
A Dweve FMI a reprodukálhatóság unalmas, drága részére támad. Az oldal egy Rust alapú FMI-megvalósítást ír le Model Exchange és Co-Simulation célra, determinisztikus fixpontos aritmetikával, a Numerusra építve. A megvalósítás alakja tágabb egy demónál: egy több crate-ből álló FMI-munkaterület modellreprezentációval, sémafeldolgozással, importtal, exporttal, futásidővel, megoldóval, orkesztrációval, memóriával, CPU-, GPU-, FPGA-, edge- és elosztott végrehajtási háttérrendszerekkel, FFI-vel, fuzzinggal, benchmarkokkal, dokumentációval és tesztekkel. A Numerus crate-jeire támaszkodik fixpontos és decimális aritmetikához, valamint a közös Dweve-veremre szimulációhoz, naplózáshoz, hibakezeléshez, átvitelhez, tenzorokhoz és tároláshoz.
A cél nem az, hogy a szimuláció misztikusnak tűnjön. A cél az, hogy ugyanaz az FMU ne meséljen mindig egy kicsit más történetet csak azért, mert más gépen ébredt fel.
Az FMI adja a borítékot, az aritmetika írja alá a csekket
Az FMU egy hasznos boríték. Modellleírást, bináris vagy forrás-összetevőket, erőforrásokat, változókat, állapotokat, órákat, függőségeket és elegendő metaadatot hordoz ahhoz, hogy egy másik eszköz példányosíthassa és léptethesse a modellt. Az FMI 3.0 gazdagabb órákat, ütemezett végrehajtást, jobb változótípusokat és ko-szimulációs mechanizmusokat ad hozzá. A Dweve FMI forrása a boríték köré szerveződik: az fmi-schema elemzi és érvényesíti a modellleírásokat, az fmi-import betölti az FMU-archívumokat, az fmi-export archívumokat épít, az fmi-model a változókat és a modellállapotot reprezentálja, az fmi-runtime pedig a életciklusért, a változóhozzáférésért, az órákért, az eseményekért, a deriváltakért és az állapotmentésért vagy -visszaállításért felel.
Ez a boríték szükséges, de nem elégséges. Az alatta lévő aritmetika dönti el, hogy egy futtatás reprodukálható-e. A futásidő dokumentációja szerint a fixpontos aritmetika a Numerus Q31_32 típusát használja a determinisztikus számításhoz. A munkaterület metaadatai a Q31.32-t nevezik meg alapértelmezett fix formátumként, a Dec64_6-ot alapértelmezett decimális formátumként, a Q16.16-ot pedig időhöz. A nyilvános oldal a Q31.32, Q16.16 és Dec64_6 profilokról beszél, az MPFR-t pedig referenciaként használja. Ez egyértelmű szerződést ad a projektnek: a valós értékű szimulációt determinisztikus numerikus profilokba kell leképezni, ahelyett, hogy minden háttérrendszerre hagynánk az improvizációt.
Van itt egy fontos őszinteségi szempont. Az FMI-felé mutató API-k és kompatibilitási felületek továbbra is fogadhatnak vagy kibocsáthatnak lebegőpontos értékeket, mert a szabvány és a meglévő eszközök ezt várják el. A lényegi állítás nem a színházi tisztaság minden határfelületen. A lényegi állítás az, hogy a magdeterminisztikus út a Numerus fixpontos profilokra és egy nagy pontosságú referencia elleni validálásra épül ott, ahol az összehasonlításnak értelme van. A peremadapterek beszélhetik a külső világ nyelvét. A belső szerződésnek nem szabad vállrándítássá válnia.
A numerikus profil modell-döntés
A fixpontos ábrázolás nem egy varázsbeállítás. Egy modell, amelynek kompakt időértékekre van szüksége, egy modell, amelynek széles fizikai tartományai vannak, és egy modell, amely tizedes mennyiségeket jelent, nem azonos nyomás alatt áll. A Q16.16, a Q31.32 és a Dec64_6 nem matricák egy diához. Különböző szerződések a tartományról, a felbontásról, az ábrázolásról és arról, hogy hol élhetnek a hibák.
Itt válnak gyakran túl hanyaggá a szimulációs csapatok. A numerikus viselkedést az eszköz tulajdonságaként kezelik, nem pedig a modell tulajdonságaként. Aztán az eszköz megváltozik, vagy a háttérrendszer megváltozik, vagy a modellt beágyazzák, és a régi feltételezés hirtelen validálási teherré válik. A Dweve FMI az architektúra részévé teszi a numerikus profilt, nem pedig háttér-időjárássá. Ez kevésbé látványos, mint egy nagy demó. Jó. A nagy demók ritkán magyarázzák el, hogy ki a felelős a kerekítési határértékért.
A solver crate ugyanezt a történetet meséli el. ODE-rendszer-tulajdonságokat, RK4-et, RKF45-öt, Eulert, BDF-orientált konfigurációt, adaptív lépésvezérlést, eseményérzékelést és determinisztikus solver-időt tesz elérhetővé. A runtime crate a FMU-életciklust, az esemény- és folytonos idejű módokat, a változó-hozzáférést, a bemeneti deriváltakat, az irányított és adjungált deriváltakat, a Jacobi-mátrix gyorsítótárazását, az órákat és az állapot-szerializációt birtokolja. Egyik sem hasznos, ha a numerikus rétegben nem lehet megbízni, amikor hardverek között mozog. A solver lehet okos. A modell lehet elegáns. Ha ugyanaz a futtatás három egyeztetést igényel, az elegancia többnyire csak díszlet.
A ko-szimuláció az, ahol a kis hazugságok drágává válnak
Egy FMU már önmagában is elég munka. Több, egymáshoz kapcsolt FMU esetén a numerikus és működési hibák társasági üggyé válnak. Egy termikus modell táplál egy vezérlőmodellt, a vezérlőmodell táplál egy aktuátormodellt, az aktuátormodell táplál egy mechanikai modellt, és mindenki reméli, hogy a lépéssorrend nem hoz létre csendben értelmetlenséget. A ko-szimulációhoz kapcsolatkezelésre, végrehajtási sorrendre, adatcserére, lépés-koordinációra, algebrai hurok kezelésére és egy módra van szükség, hogy nemet lehessen mondani, ha a gráf hibás.
A forrásban a fmi-orchestration végzi ezt a munkát. Több FMU-s ko-szimulációt, kapcsolatokat, ciklusfelismerést, topologikus rendezést, partíció-ütemezést, algebrai hurok felismerését és megoldását, értékelőzményt, végrehajtási sorrendet, szimulációs időt és orkesztrációs statisztikákat kezel. Van fmi-cc a kapcsolt FMU-k közötti kommunikációhoz és fmi-dist az elosztott végrehajtáshoz koordinátorokkal, csomópont-regisztrációval, üzenetekkel, lépéskérésekkel, lépésválaszokkal és állapotértékekkel. Ez az a fajta gépezet, amelyről az emberek megfeledkeznek, amikor azt mondják, hogy az integráció csak a kimenetek bekötése a bemenetekre. Igen, bekötés. De egyben időzítés, függőségkezelés, állapot, hiba és annak bizonyítéka is, hogy a bekötés azt tette, amit ígért.
A ko-szimuláció a determinizmust is fontosabbá teszi, nem kevésbé. Ha az egyik FMU kissé eltér, és ez az érték egy másik FMU-ba kerül, az eltérés továbbterjedhet. Ha a végrehajtási sorrend csomópontonként változik, az eltérés egy későbbi lépésig rejtve maradhat. Ha az egyik háttérrendszer kissé eltérő matematikai utat használ, az eltérés modellviselkedésnek tűnhet. Így végzi el a csapat a fizika hibakeresését értekezleti jegyzőkönyvekkel. Senkinek sem kellene ezt tennie, hacsak nem volt nagyon rossz egy korábbi életében.
A háttérrendszerek telepítési döntések, nem új igazságok
A forrásfa a végrehajtási célokat háttérrendszer-kráterekre bontja: CPU, GPU, FPGA, él és elosztott. Az él-háttérrendszer a korlátozott eszközökre, a korlátozott memóriára és az alacsony terhelésre összpontosít. Az FPGA-háttérrendszer fixpontos aritmetikáról, DMA-átvitelről, bitfolyam-kezelésről, kernel-végrehajtásról és hardver-in-the-loop-ról beszél. Az elosztott kráter több csomópontot koordinál. A nyilvános oldal CPU SIMD, GPU, FPGA, él és elosztott utakat ír le. Ez nem jelenti azt, hogy minden cél egyformán érett minden munkaterhelésre. Azt jelenti, hogy az architektúra a háttérrendszer-választást elsőrendű szempontként kezeli.
A kulcsfontosságú tervezési elv az, hogy a telepítésnek meg kell változtatnia, hogy hol fut a szimuláció, nem pedig azt, hogy mit jelent a szimuláció. A CPU-út lehet a legkönnyebb a szerzői és ellenőrzési munkához. A GPU-út nagy párhuzamos munkaterhelésekhez lehet értelmes. Az FPGA-út valós idejű vagy hardver-in-the-loop esetekben lehet szükséges. Az él-út a gép közelében lehet szükséges. Az elosztott végrehajtás nagy csatolt rendszerekhez lehet szükséges. Ezek működési döntések. Nem hozhatnak létre új numerikus identitást a modell számára.
Ez az a pont is, ahol a nyílt forráskód számít. A biztonság, az energia, a robotika, az orvostechnikai eszközök, az autóipar, a repülőgépipar, az ipari vezérlés és a digitális ikrek területén a reprodukálhatósági állítások nem élhetnek csak a szállítói diákon. Valakinek meg kell vizsgálnia a megvalósítást, rögzítenie kell egy verziót, futtatnia kell a teszteket, el kell olvasnia a hibaeseteket, és el kell döntenie, hogy a bizonyíték elég jó-e. Egy nyílt forráskódú FMI-megvalósítás jobb utat ad a csapatoknak ehhez a bizonyítékhoz. Nem tanúsít semmit varázsütésre. Megvizsgálhatóvá teszi a munkát, ami az első hasznos lépés.
Az érvényesítésnek kapunak kell lennie, nem irányítópultnak
A Dweve FMI érvényesítési története nem csak a szép nyomvonalakról szól. A README és az oldal MPFR referencia-ellenőrzéseket, háttérrendszerek közötti egyenértékűséget, determinisztikus visszajátszást, megfelelőségi teszteket, fuzzingot és tipizált hibákat ír le. A forrás tartalmaz fmi-test, fmi-fuzz, fmi-bench, fmi-conformance elemeket, tulajdonságteszteket, fuzz-harnesseket és állapot-szerializációt. Ez a helyes irány. A szimulációs infrastruktúrában az érvényesítés nem lehet irányítópult, ahol egy piros vonal aggasztónak tűnik, és valaki megígéri, hogy figyeli. Kapunak kell lennie.
A kapunak több része van. Az importnak helyesen kell elemeznie az FMU-archívumot és a modelDescription-t. A séma-ellenőrzésnek el kell utasítania az érvénytelen változódefiníciókat, függőségeket, órákat és attribútumokat. A numerikus ellenőrzésekhez orákulumra van szükség, ha a pontosság az állítás. A háttérrendszer-paritásnak ugyanazt az állapotot kell biztosítania a végrehajtási célok között. A visszajátszáshoz mentett állapotra és eseménynaplókra van szükség a futtatás újraépítéséhez. A hibához tipizált hibákra van szükség, nem pedig rejtélyes eltérés-jelentésre, amely a csapatot a naplókban való kutakodásra kényszeríti. Az eltérésnek blokkolnia kell a kiadási utat, amíg meg nem értik vagy kifejezetten el nem fogadják. Ez csak akkor hangzik szigorúnak, ha az alternatíva még nem számlázta ki Önt.
Hol számít ez először
A kézenfekvő területek azok, ahol a szimulációs hibák fizikai hibákká válnak: autóipar, repülés, ipari vezérlés, orvostechnikai eszközök, energia, robotika és infrastruktúra. Egy fékmodell, szivattyúvezérlő, hálózati modell, robotcella, gyártósor vagy HVAC-vezérlő nem lesz biztonságosabb attól, hogy egy prezentáció digitális ikerről beszél. Akkor válik biztonságosabbá, ha a modell, a bemenetek, a numerikus profil, a háttérrendszer, a verzió és a visszajátszási nyomvonal elég ellenőrzött ahhoz, hogy vizsgálható legyen.
Van itt beszerzési szempont is, mert persze hogy van. Ha minden háttérrendszer külön validálási történetet igényel, minden hardverváltás egy kis újratanúsítási gyakorlattá válik. Ha ugyanaz az FMU egyszer bizonyítható, majd az üzemi korlátnak megfelelő célhardveren futtatható, a csapatok szabadságot kapnak anélkül, hogy azt állítanák, a validálás ingyen van. Az oldal ezt úgy fogalmazza meg, hogy egyszer bizonyítani, és bárhol futtatni. A mérnöki fordítás valamivel kevésbé romantikus: csökkenteni azoknak a helyeknek a számát, ahol ugyanaz a modell ellentmondhat önmagának.
Ez különösen releváns Európában. A szuverenitás nem csak arról szól, hol áll a szerver. Arról is szól, hogy egy biztonsági eset vizsgálható, megismételhető és áthelyezhető-e anélkül, hogy egy szállító engedélyét kellene kuncsorogni. Egy nyílt implementáció, determinisztikus aritmetika, reprodukálható visszajátszás és háttérrendszer-paritás önmagában nem oldja meg a politikát. Viszont kevésbé függővé teszik a technikai részt egy értékesítési csapattal ellátott fekete doboztól.
Mit érdemes átnézni, mielőtt megbízik benne
Az első átvizsgálási kérdés az, hogy a modell az FMI 3.0 mely felületeit használja valójában. A Model Exchange, a Co-Simulation, a Scheduled Execution, az órák, a deriváltak, az események, a bináris változók, a karakterláncok, a tömbök és a függőségek nem ugyanazt a terhelést jelentik. Egy egyszerű FMU és egy csatolt, több FMU-s szimuláció eltérő nyomást gyakorol a futásidejű környezetre és az orkesztrátorra.
A második kérdés az, hogy a modell melyik numerikus profilt deklarálja, és miért. Ha a válasz az, hogy ami a példában működött, az nem tervezés. A profilnak illeszkednie kell a tartományhoz, a felbontáshoz, az időábrázoláshoz, a tűréshez és a telepítési célhoz. Elég láthatónak kell lennie ahhoz, hogy egy felülvizsgáló megkérdőjelezhesse anélkül, hogy a teljes megoldót elolvasná.
A harmadik kérdés az, hogy milyen bizonyíték utazik egy eredménnyel. Melyik forrásverzió? Melyik FMU-verzió? Melyik modelDescription? Melyik Numerus-profil? Melyik háttérrendszer? Melyik orákulum-ellenőrzés? Melyik visszajátszási állapot? Melyik konformitás- vagy tulajdonságteszt? Ha ezek a válaszok egy wikiben és valakinek az emlékezetében szétszórva vannak, a szimuláció még nem áll készen arra, hogy komoly munkafolyamatban megbízzanak benne.
A tanulság
A Dweve FMI tanulsága nem az, hogy a szimulációs szabványok unalmasak. Pontosan olyan értelemben unalmasak, ahogy a hidak is unalmasak, amíg állnak. Az FMI adja a cserekeretet. A Numerus-alapú fixpontos aritmetika adja a determinisztikus számtani magatartást. A futásidejű és megoldó modulok léptetik a modellt. Az orkesztráció összeköti az FMU-kat anélkül, hogy az időzítést triviálisnak állítaná be. A háttérrendszerek a feladathoz illő hardverre helyezik a végrehajtást. A validálás a hasonlóságot kapuvá alakítja remény helyett.
Ez a munka. Nem egy nagy állítás, hogy a számok örökre meg vannak oldva. Nem egy csillogó demó, ahol minden egyezik, mert csak egy utat teszteltek. Egy szimulációs rendszer, amely ismeri a formátumait, deklarálja a numerikus szerződését, több háttérrendszeren fut, és hangosan hibázik, amikor ugyanaz a modell megszűnik ugyanaz a modell lenni.
A modellnek nem kellene személyiséget kialakítania. Van belőlük elég az értekezleteken.