FMI a rovnaká simulácia všade
Model by nemal vyvinúť osobnosť
Simulačný model by mal byť nudný jedným veľmi konkrétnym spôsobom: rovnaký vstup, rovnaký model, rovnaký výstup. To znie samozrejme, až kým sa model nepresunie z pracovnej stanice na klaster, z notebooku do hardvéru v slučke, z jedného kompilátora na druhý, alebo z nástroja dodávateľa do bezpečnostného oddelenia, ktoré neocení interpretačný tanec. Potom sa z malých numerických rozdielov stanú stretnutia. Zo stretnutí sa stanú tabuľky na odsúhlasenie. Tabuľky na odsúhlasenie sa stanú cintorínom, kde umierajú dobré inžinierske popoludnia.
FMI existuje, aby výmenu modelov a ko-simuláciu sprístupnil naprieč nástrojmi. Functional Mock-up Interface dáva tímom štandardný spôsob, ako zabaliť a spúšťať modely, namiesto ručného prenášania krehkého integračného kódu z jedného simulačného prostredia do druhého. To je užitočné. Štandardné rozhranie však automaticky nezaručuje deterministickú aritmetiku. Tradičné pracovné postupy FMI často závisia od správania s pohyblivou rádovou čiarkou IEEE 754, knižníc platformy, výberu kompilátora, poradia vykonávania a rozdielov v backendoch. Väčšinou to je v poriadku. Potom to v poriadku nie je, a rozdiel zvyčajne objaví niekto, kto má termín a výraz tváre, ktorý hovorí, že obstarávanie sľubovalo, že to bude jednoduché.
Dweve FMI útočí na nudnú a drahú časť: reprodukovateľnosť. Stránka opisuje implementáciu FMI v jazyku Rust pre Model Exchange a Co-Simulation s deterministickou aritmetikou s pevnou rádovou čiarkou, postavenú na Numerus. Tvar implementácie je širší ako demo: viacvrstvový pracovný priestor FMI s reprezentáciou modelu, parsovaním schémy, importom, exportom, runtime, riešičom, orchestráciou, pamäťou, backendmi pre CPU, GPU, FPGA, edge a distribuované vykonávanie, FFI, fuzzingom, benchmarkmi, dokumentáciou a testami. Závisí od crate-ov Numerus pre aritmetiku s pevnou a pohyblivou rádovou čiarkou, plus od bežného stacku Dweve pre simuláciu, logovanie, spracovanie chýb, prenos, tenzory a ukladanie.
Cieľom nie je urobiť simuláciu mystickou. Cieľom je, aby rovnaký FMU prestal rozprávať mierne odlišné príbehy, pretože sa zobudil na inom počítači.
FMI dáva obálku, aritmetika stále píše šek
FMU je užitočná obálka. Nesie opis modelu, binárne súbory alebo zdrojové artefakty, zdroje, premenné, stavy, hodiny, závislosti a dostatok metadát na to, aby iný nástroj mohol model vytvoriť a krokovo spúšťať. FMI 3.0 pridáva bohatšie hodiny, plánované vykonávanie, vylepšené typovanie premenných a mechanizmy ko-simulácie. Zdrojový kód Dweve FMI je organizovaný okolo tejto obálky: fmi-schema parsuje a overuje opisy modelov, fmi-import načítava archívy FMU, fmi-export vytvára archívy, fmi-model reprezentuje premenné a stav modelu a fmi-runtime spravuje životný cyklus, prístup k premenným, hodiny, udalosti, derivácie a ukladanie alebo obnovenie stavu.
Táto obálka je nevyhnutná, ale nie dostatočná. Aritmetika pod ňou stále rozhoduje o tom, či je beh reprodukovateľný. Dokumentácia runtime hovorí, že aritmetika s pevnou rádovou čiarkou používa Numerus Q31_32 na deterministický výpočet. Metadáta pracovného priestoru označujú Q31.32 ako predvolený formát s pevnou rádovou čiarkou, Dec64_6 ako predvolený desatinný formát a Q16.16 pre čas. Verejná stránka hovorí o profiloch Q31.32, Q16.16 a Dec64_6, pričom MPFR sa používa ako referenčná cesta. To dáva projektu jasnú zmluvu: simulácia s reálnymi hodnotami by sa mala mapovať do deterministických numerických profilov namiesto toho, aby každý backend improvizoval.
Je tu dôležitý bod týkajúci sa poctivosti. Rozhrania a kompatibilné povrchy smerujúce k FMI môžu stále prijímať alebo emitovať plávajúce hodnoty, pretože štandard a existujúce nástroje ich očakávajú. Dôležité tvrdenie nie je divadelne čisté na každom rozhraní. Dôležité tvrdenie je, že základná deterministická cesta je postavená na profiloch s pevnou rádovou čiarkou Numerus a validácii proti referencii s vysokou presnosťou tam, kde má porovnanie zmysel. Okrajové adaptéry môžu hovoriť jazykom vonkajšieho sveta. Vnútorná zmluva by sa nemala stať pokrčením pliec.
Numerický profil je rozhodnutie modelu
Pevná rádová čiarka nie je jedno magické nastavenie. Model, ktorý potrebuje kompaktné časové hodnoty, model so širokými fyzikálnymi rozsahmi a model, ktorý vykazuje desatinné veličiny, nemajú rovnaký tlak. Q16.16, Q31.32 a Dec64_6 nie sú nálepky na prezentáciu. Sú to rôzne zmluvy o rozsahu, rozlíšení, reprezentácii a o tom, kde sa chyby môžu nachádzať.
Tu sú simulačné tímy často príliš neformálne. Správajú sa k numerickému správaniu ako k vlastnosti nástroja, nie ako k vlastnosti modelu. Potom sa zmení nástroj, zmení sa backend, alebo sa model vloží do iného systému, a zrazu sa starý predpoklad stane záťažou pre validáciu. Dweve FMI robí numerický profil súčasťou architektúry, nie pozadím počasia. To je menej efektné ako veľká ukážka. Dobre. Veľké ukážky málokedy vysvetlia, kto vlastní hranicu zaokrúhľovania.
Crate solver rozpráva rovnaký príbeh. Vystavuje vlastnosti ODE systémov, RK4, RKF45, Euler, konfiguráciu orientovanú na BDF, adaptívne riadenie kroku, detekciu udalostí a deterministický čas riešiča. Crate runtime vlastní životný cyklus FMU, režimy udalostí a spojitého času, prístup k premenným, vstupné derivácie, smerové a adjungované derivácie, ukladanie Jacobiho matíc do vyrovnávacej pamäte, hodiny a serializáciu stavu. Nič z toho nie je užitočné, ak numerickej vrstve nemožno dôverovať, keď sa pohybuje naprieč hardvérom. Riešič môže byť dômyselný. Model môže byť elegantný. Ak rovnaký beh vyžaduje tri zosúladenia, elegancia je väčšinou len dekorácia.
Pri ko-simulácii sa malé klamstvá predražia
Jedno FMU je už dosť práce. Niekoľko prepojených FMU je miesto, kde sa numerické a prevádzkové chyby stávajú spoločenskými. Tepelný model napája riadiaci model, riadiaci model napája model aktuátora, model aktuátora napája mechanický model a všetci dúfajú, že poradie krokov potichu nevytvára nezmysly. Ko-simulácia potrebuje správu spojení, poradie vykonávania, výmenu údajov, koordináciu krokov, spracovanie algebraických slučiek a spôsob, ako povedať nie, keď je graf nesprávny.
Zdroj má na túto prácu fmi-orchestration. Zvláda ko-simuláciu viacerých FMU, spojenia, detekciu cyklov, topologické usporiadanie, plánovanie oddielov, detekciu a riešenie algebraických slučiek, históriu hodnôt, poradie vykonávania, simulačný čas a štatistiky orchestrácie. Existuje fmi-cc pre komunikáciu medzi prepojenými FMU a fmi-dist pre distribuované vykonávanie s koordinátormi, registráciou uzlov, správami, požiadavkami na kroky, odpoveďami na kroky a stavovými hodnotami. To je druh mechanizmov, na ktoré ľudia zabúdajú, keď hovoria, že integrácia je len prepojenie výstupov so vstupmi. Je to prepojenie, áno. Je to tiež načasovanie, správa závislostí, stav, zlyhanie a dôkaz, že prepojenie urobilo to, čo sľúbilo.
Ko-simulácia tiež robí determinizmus dôležitejším, nie menej. Ak sa jeden FMU mierne odchýli a táto hodnota sa prenesie do ďalšieho FMU, nezhoda sa môže šíriť. Ak sa zmení poradie vykonávania medzi uzlami, nezhoda sa môže skryť až do neskoršieho kroku. Ak jeden backend používa mierne odlišnú matematickú cestu, nezhoda môže vyzerať ako správanie modelu. Takto tímy končia pri ladení fyziky pomocou zápisníc zo stretnutí. Nikto by to nemusel robiť, pokiaľ nebol v predchádzajúcom živote veľmi zlý.
Backendy sú voľby nasadenia, nie nové pravdy
Zdrojový strom rozdeľuje ciele vykonávania do backendových crate-ov: CPU, GPU, FPGA, edge a distribuované. Edge backend sa zameriava na zariadenia s obmedzenými zdrojmi, ohraničenú pamäť a nízku réžiu. FPGA backend hovorí o aritmetike s pevnou rádovou čiarkou, DMA prenosoch, správe bitstreamov, vykonávaní jadier a hardvéri v slučke. Distribuovaný crate koordinuje viacero uzlov. Verejná stránka opisuje CPU SIMD, GPU, FPGA, edge a distribuované cesty. To neznamená, že každý cieľ je rovnako vyspelý pre každú pracovnú záťaž. Znamená to, že architektúra považuje výber backendu za prvotriednu záležitosť.
Kľúčovým dizajnovým princípom je, že nasadenie by malo meniť to, kde sa simulácia vykonáva, nie to, čo simulácia znamená. CPU cesta môže byť najjednoduchšia pre tvorbu a overovanie. GPU cesta môže dávať zmysel pre veľké paralelné pracovné záťaže. FPGA cesta môže byť potrebná pre real-time alebo hardvér v slučke. Edge cesta môže byť potrebná v blízkosti stroja. Distribuované vykonávanie môže byť potrebné pre veľké prepojené systémy. To sú prevádzkové voľby. Nemali by vytvárať novú numerickú identitu modelu.
Tu tiež záleží na open source. V oblasti bezpečnosti, energetiky, robotiky, zdravotníckych zariadení, automobilového priemyslu, letectva, priemyselného riadenia a digitálnych dvojčiat nemôžu tvrdenia o reprodukovateľnosti žiť len vo vendor slides. Niekto musí preskúmať implementáciu, pripnúť verziu, spustiť testy, prečítať prípady zlyhania a rozhodnúť, či sú dôkazy dostatočné. Open source implementácia FMI dáva tímom lepšiu cestu k týmto dôkazom. Nič magicky necertifikuje. Robí prácu preskúmateľnou, čo je prvý užitočný krok.
Validácia by mala byť brána, nie dashboard
Príbeh validácie Dweve FMI nie je len o pekných stopách. README a webová stránka opisujú MPFR referenčné kontroly, ekvivalenciu naprieč backendmi, deterministické prehrávanie, konformitné testy, fuzzing a typované zlyhania. Zdroj obsahuje fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, property testy, fuzz harnessy a serializáciu stavu. To je správny smer. V simulačnej infraštruktúre by validácia nemala byť dashboard, kde červená čiara vyzerá znepokojujúco a niekto sľubuje, že to bude sledovať. Mala by byť brána.
Brána má niekoľko častí. Import musí správne analyzovať FMU archív a modelDescription. Schémová validácia musí odmietnuť neplatné definície premenných, závislosti, hodiny a atribúty. Numerické kontroly potrebujú orákulum, keď je tvrdením presnosť. Parita backendov potrebuje rovnaký stav naprieč cieľmi vykonávania. Prehrávanie potrebuje uložený stav a denníky udalostí na obnovenie behu. Zlyhanie potrebuje typované chyby, nie záhadnú správu o nezhode, ktorá pošle tím na lov do logov. Nezhoda by mala blokovať cestu vydania, kým nie je pochopená alebo explicitne prijatá. To znie tvrdo, len ak vám alternatíva ešte nevyfakturovala.
Kde to záleží najskôr
Zrejmé oblasti sú tie, kde sa chyby v simulácii stávajú fyzickými chybami: automobilový priemysel, letectvo a kozmonautika, priemyselné riadenie, zdravotnícke zariadenia, energetika, robotika a infraštruktúra. Model bŕzd, regulátor čerpadla, model siete, robotická bunka, výrobná linka alebo regulátor HVAC sa nestanú bezpečnejšími preto, lebo snímka hovorí o digitálnom dvojčati. Stanú sa bezpečnejšími vtedy, keď sú model, vstupy, numerický profil, backend, verzia a stopa prehrávania dostatočne kontrolované na to, aby sa dali preskúmať.
Existuje aj uhol obstarávania, pretože, samozrejme, existuje. Ak každý backend vyžaduje samostatný príbeh validácie, každá zmena hardvéru sa stáva malým cvičením re-certifikácie. Ak sa dá rovnaký FMU dokázať raz a potom spustiť na cieľovom zariadení, ktoré vyhovuje prevádzkovým obmedzeniam, tímy získajú slobodu bez predstierania, že validácia je zadarmo. Stránka to formuluje ako dokázať raz a spustiť kdekoľvek. Inžiniersky preklad je o niečo menej romantický: znížiť počet miest, kde môže rovnaký model nesúhlasiť so sebou samým.
To je obzvlášť dôležité v Európe. Suverenita nie je len o tom, kde stojí server. Je aj o tom, či sa dá bezpečnostný prípad preskúmať, zopakovať a presunúť bez toho, aby sme jedného dodávateľa prosili o povolenie. Otvorená implementácia, deterministická aritmetika, reprodukovateľné prehrávanie a parita backendov nevyriešia politiku samy osebe. Robia však technickú časť menej závislou od čiernej skrinky s pripojeným obchodným tímom.
Čo preskúmať predtým, než tomu začnete dôverovať
Prvá otázka na preskúmanie je, ktoré povrchy FMI 3.0 váš model skutočne používa. Model Exchange, Co-Simulation, Scheduled Execution, hodiny, derivácie, udalosti, binárne premenné, reťazce, polia a závislosti nie sú rovnaká záťaž. Jednoduchý FMU a spojená multi-FMU simulácia kladú na runtime a orchestrátor rozdielny tlak.
Druhá otázka je, ktorý numerický profil model deklaruje a prečo. Ak je odpoveďou čokoľvek, čo fungovalo v príklade, nie je to návrh. Profil by mal zodpovedať rozsahu, rozlíšeniu, časovej reprezentácii, tolerancii a cieľovému nasadeniu. Mal by byť dostatočne viditeľný na to, aby ho mohol recenzent spochybniť bez čítania celého riešiteľa.
Tretia otázka je, aké dôkazy sprevádzajú výsledok. Ktorá verzia zdroja? Ktorá verzia FMU? Ktorý modelDescription? Ktorý profil Numerus? Ktorý backend? Ktoré kontroly oracle? Ktorý stav prehrávania? Ktoré testy zhody alebo vlastností? Ak sú tieto odpovede roztrúsené po wiki a v pamäti niekoho, simulácia ešte nie je pripravená na dôveru vo vážnom pracovnom postupe.
Ponaučenie
Ponaučenie z Dweve FMI nie je, že štandardy simulácie sú nudné. Sú nudné presne tak, ako sú mosty nudné, keď stoja. FMI poskytuje obálku výmeny. Pevný bod podporovaný Numerus poskytuje deterministický aritmetický postoj. Runtime a krabice riešiteľa posúvajú model. Orchestrácia spája FMU bez predstierania, že časovanie je triviálne. Backendy presúvajú vykonávanie na hardvér, ktorý sa hodí na danú prácu. Validácia mení rovnakosť na bránu namiesto nádeje.
To je tá práca. Nie veľkolepé tvrdenie, že čísla sú navždy vyriešené. Nie lesklá ukážka, kde všetko súhlasí, pretože sa testovala iba jedna cesta. Simulačný systém, ktorý pozná svoje formáty, deklaruje svoju numerickú zmluvu, beží naprieč backendmi a hlasno zlyhá, keď rovnaký model prestane byť rovnakým modelom.
Model by si nemal vytvárať osobnosť. Tých máme na poradách dosť.