FMI a stejná simulace všude
Model by neměl získat osobnost
Simulační model by měl být nudný jedním velmi konkrétním způsobem: stejný vstup, stejný model, stejný výstup. To zní samozřejmě, dokud se model nepřesune z pracovní stanice na cluster, z notebooku do hardware-in-the-loop, z jednoho kompilátoru na jiný, nebo z nástroje dodavatele do bezpečnostního oddělení, které neocení interpretační tanec. Pak se z drobných numerických rozdílů stanou schůzky. Ze schůzek se stanou tabulky pro odsouhlasení. Z tabulek pro odsouhlasení se stane hřbitov, kde umírají dobrá inženýrská odpoledne.
FMI existuje proto, aby byla výměna modelů a ko-simulace praktická napříč nástroji. Functional Mock-up Interface dává týmům standardní způsob, jak modely zabalit a spouštět, místo aby si ručně předávaly křehký integrační kód z jednoho simulačního prostředí do druhého. To už je užitečné. Ale standardní rozhraní automaticky nedělá aritmetiku deterministickou. Tradiční pracovní postupy FMI často spoléhají na chování s plovoucí řádovou čárkou IEEE 754, knihovny platformy, volby kompilátoru, pořadí provádění a rozdíly v backendu. Většinou to nevadí. Pak to najednou vadí, a rozdíl obvykle objeví někdo, kdo má termín a výraz ve tváři, který říká, že nákup slíbil, že to bude snadné.
Dweve FMI útočí na tu nudnou, drahou část: reprodukovatelnost. Stránka popisuje implementaci FMI v jazyce Rust pro Model Exchange a Co-Simulation s deterministickou aritmetikou s pevnou řádovou čárkou, postavenou na Numerus. Tvar implementace je širší než demo: vícecrateový FMI workspace s reprezentací modelu, parsováním schématu, importem, exportem, runtime, solverem, orchestrací, pamětí, backendy pro CPU, GPU, FPGA, edge a distribuované provádění, FFI, fuzzingem, benchmarky, dokumentací a testy. Závisí na cratech Numerus pro aritmetiku s pevnou a desetinnou řádovou čárkou, plus na běžném zásobníku Dweve pro simulaci, logování, zpracování chyb, přenos, tenzory a úložiště.
Cílem není, aby simulace zněla mysticky. Cílem je, aby stejný FMU přestal vyprávět mírně odlišné příběhy jen proto, že se probudil na jiném stroji.
FMI dává obálku, aritmetika stále píše šek
FMU je užitečná obálka. Nese popis modelu, binární nebo zdrojové artefakty, zdroje, proměnné, stavy, hodiny, závislosti a dostatek metadat, aby jiný nástroj mohl model instanciovat a krokovat. FMI 3.0 přidává bohatší hodiny, plánované provádění, lepší typování proměnných a mechanismy ko-simulace. Zdrojový kód Dweve FMI je organizován kolem této obálky: fmi-schema parsuje a validuje popisy modelů, fmi-import načítá archivy FMU, fmi-export vytváří archivy, fmi-model reprezentuje proměnné a stav modelu a fmi-runtime vlastní životní cyklus, přístup k proměnným, hodiny, události, derivace a ukládání nebo obnovení stavu.
Tato obálka je nezbytná, ale není dostačující. Aritmetika pod ní stále rozhoduje o tom, zda je běh reprodukovatelný. Dokumentace runtime říká, že aritmetika s pevnou řádovou čárkou používá Numerus Q31_32 pro deterministický výpočet. Metadata workspace pojmenovávají Q31.32 jako výchozí formát s pevnou řádovou čárkou, Dec64_6 jako výchozí desetinný formát a Q16.16 pro čas. Veřejná stránka hovoří o profilech Q31.32, Q16.16 a Dec64_6, přičemž MPFR se používá jako referenční cesta. To dává projektu jasnou smlouvu: simulace s reálnými hodnotami by měla být mapována do deterministických numerických profilů, místo aby každý backend improvizoval.
Je tu důležitý bod ohledně poctivosti. FMI orientovaná rozhraní a kompatibilní povrchy mohou stále přijímat nebo vydávat plovoucí hodnoty, protože standard a stávající nástroje je očekávají. Důležité tvrzení není divadelní čistota na každém rozhraní. Důležité tvrzení je, že základní deterministická cesta je postavena na profilech s pevnou řádovou čárkou Numerus a validaci proti referenci s vysokou přesností tam, kde má srovnání smysl. Okrajové adaptéry mohou mluvit jazykem vnějšího světa. Vnitřní smlouva by se neměla stát pokrčením ramen.
Numerický profil je rozhodnutí modelu
Pevná řádová čárka není jedno kouzelné nastavení. Model, který potřebuje kompaktní časové hodnoty, model se širokými fyzikálními rozsahy a model, který vykazuje desetinné veličiny, nemají stejný tlak. Q16.16, Q31.32 a Dec64_6 nejsou samolepky na prezentaci. Jsou to různé smlouvy o rozsahu, rozlišení, reprezentaci a o tom, kde se chybám dovolí žít.
Tady bývají simulační týmy často příliš ležérní. Chovají se k numerickému chování jako k vlastnosti nástroje, ne jako k vlastnosti modelu. Pak se změní nástroj, nebo se změní backend, nebo se model vloží do jiného prostředí, a najednou se starý předpoklad stane zátěží pro validaci. Dweve FMI dělá z numerického profilu součást architektury, ne jen okolní počasí. To je méně efektní než velká demonstrace. Dobře. Velké demonstrace málokdy vysvětlí, kdo vlastní hranici zaokrouhlování.
Crate solver vypráví stejný příběh. Vystavuje rysy ODE systémů, RK4, RKF45, Euler, konfiguraci orientovanou na BDF, adaptivní řízení kroku, detekci událostí a deterministický čas solveru. Crate runtime vlastní životní cyklus FMU, režimy událostí a spojitého času, přístup k proměnným, derivace vstupů, směrové a adjungované derivace, ukládání Jacobiánů do mezipaměti, hodiny a serializaci stavu. Nic z toho není užitečné, pokud numerické vrstvě nelze věřit, když se pohybuje napříč hardwarem. Solver může být chytrý. Model může být elegantní. Pokud stejný běh potřebuje tři sladění, elegance je většinou jen dekorace.
Ko-simulace je místo, kde se malé lži prodraží
Jedno FMU je už dost práce. Několik FMU propojených dohromady je místo, kde se numerické a provozní chyby stávají společenskými. Tepelný model napájí řídicí model, řídicí model napájí model aktuátoru, model aktuátoru napájí mechanický model a všichni doufají, že pořadí kroků tiše nevytváří nesmysly. Ko-simulace potřebuje správu spojení, pořadí provádění, výměnu dat, koordinaci kroků, řešení algebraických smyček a způsob, jak říct ne, když je graf špatně.
Zdroj má pro tuto práci fmi-orchestration. Zvládá ko-simulaci více FMU, spojení, detekci cyklů, topologické řazení, plánování oddílů, detekci a řešení algebraických smyček, historii hodnot, pořadí provádění, simulační čas a statistiky orchestrace. Existuje fmi-cc pro komunikaci mezi propojenými FMU a fmi-dist pro distribuované provádění s koordinátory, registrací uzlů, zprávami, žádostmi o kroky, odpověďmi na kroky a hodnotami stavu. To je druh strojového vybavení, na které lidé zapomínají, když říkají, že integrace je jen propojení výstupů se vstupy. Je to propojení, ano. Je to také načasování, správa závislostí, stav, selhání a důkaz, že propojení udělalo to, co říkalo.
Ko-simulace také činí determinismus důležitějším, ne méně. Pokud se jeden FMU mírně odchýlí a tato hodnota se předá dalšímu FMU, může se neshoda šířit. Pokud se pořadí provádění změní mezi uzly, může se neshoda skrývat až do pozdějšího kroku. Pokud jeden backend používá mírně odlišnou matematickou cestu, může neshoda vypadat jako chování modelu. Takto týmy končí s laděním fyziky pomocí zápisů ze schůzek. Nikdo by to nemusel dělat, pokud nebyl v předchozím životě velmi zlý.
Backendy jsou volby nasazení, ne nové pravdy
Strom zdrojového kódu odděluje cíle provádění do backendových crate: CPU, GPU, FPGA, edge a distribuované. Edge backend se zaměřuje na zařízení s omezenými prostředky, omezenou pamětí a nízkou režií. FPGA backend se zabývá aritmetikou s pevnou řádovou čárkou, přenosy DMA, správou bitstreamů, prováděním kernelů a hardware-in-the-loop. Distribuovaný crate koordinuje více uzlů. Veřejná stránka popisuje cesty CPU SIMD, GPU, FPGA, edge a distribuované. To neznamená, že každý cíl je stejně vyspělý pro každé pracovní zatížení. Znamená to, že architektura považuje volbu backendu za prvotřídní záležitost.
Klíčovým konstrukčním principem je, že nasazení by mělo změnit místo, kde simulace běží, ne to, co simulace znamená. Cesta CPU může být nejjednodušší pro tvorbu a ověřování. Cesta GPU může dávat smysl pro velké paralelní pracovní zátěže. Cesta FPGA může být potřebná pro real-time nebo hardware-in-the-loop. Cesta edge může být potřebná v blízkosti stroje. Distribuované provádění může být potřebné pro velké propojené systémy. To jsou provozní volby. Neměly by vytvářet novou numerickou identitu modelu.
To je také místo, kde záleží na open source. V oblasti bezpečnosti, energetiky, robotiky, zdravotnických zařízení, automobilového průmyslu, letectví, průmyslového řízení a digitálních dvojčat nemohou tvrzení o reprodukovatelnosti žít pouze na prodejních slajdech. Někdo musí prozkoumat implementaci, připnout verzi, spustit testy, přečíst případy selhání a rozhodnout, zda jsou důkazy dostatečné. Open source implementace FMI dává týmům lepší cestu k těmto důkazům. Nic magicky necertifikuje. Činí práci zkoumatelnou, což je první užitečný krok.
Validace by měla být brána, ne dashboard
Příběh validace Dweve FMI není jen o pěkných trasách. README a web popisují MPFR referenční kontroly, ekvivalenci napříč backendy, deterministické přehrávání, konformní testy, fuzzing a typované chyby. Zdroj obsahuje fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, property testy, fuzz harnessy a serializaci stavu. To je správný směr. V simulační infrastruktuře by validace neměla být dashboard, kde červená čára vypadá znepokojivě a někdo slíbí, že ji bude sledovat. Měla by být brána.
Brána má několik částí. Import musí správně parsovat archiv FMU a modelDescription. Schéma validace musí odmítat neplatné definice proměnných, závislosti, hodiny a atributy. Numerické kontroly potřebují orákulum, když je tvrzením přesnost. Parita backendů potřebuje stejný stav napříč cíli provádění. Přehrávání potřebuje uložený stav a protokoly událostí k rekonstrukci běhu. Selhání potřebuje typované chyby, ne záhadnou zprávu o neshodě, která posílá tým do prohledávání logů. Neshoda by měla blokovat cestu vydání, dokud není pochopena nebo výslovně přijata. To zní tvrdě pouze tehdy, pokud vám alternativa ještě neúčtovala.
Kde to má smysl především
Zřejmé oblasti jsou ty, kde se chyby v simulaci stávají fyzickými chybami: automobilový průmysl, letectví a kosmonautika, průmyslové řízení, zdravotnické prostředky, energetika, robotika a infrastruktura. Brzdový model, řídicí jednotka čerpadla, model sítě, robotická buňka, výrobní linka nebo řídicí systém HVAC se nestanou bezpečnějšími proto, že prezentace říká digitální dvojče. Stanou se bezpečnějšími, když jsou model, vstupy, numerický profil, backend, verze a stopa přehrávání dostatečně řízené, aby je bylo možné vyšetřit.
Existuje také úhel pohledu nákupčího, protože samozřejmě existuje. Pokud každý backend vyžaduje samostatný příběh validace, každá změna hardwaru se stane malým cvičením v re-certifikaci. Pokud lze stejný FMU prokázat jednou a poté spustit na cílovém zařízení, které vyhovuje provozním omezením, týmy získají svobodu, aniž by předstíraly, že validace je zadarmo. Stránky to formulují jako prokázat jednou a spouštět kdekoli. Inženýrský překlad je o něco méně romantický: snížit počet míst, kde si stejný model může protiřečit.
To je obzvláště důležité v Evropě. Suverenita není jen o tom, kde leží server. Je také o tom, zda lze bezpečnostní případ prozkoumat, opakovat a přenést, aniž bychom prosili jednoho dodavatele o svolení. Otevřená implementace, deterministická aritmetika, reprodukovatelné přehrávání a shoda backendů nevyřeší politiku samy o sobě. Dělají technickou část méně závislou na černé skříňce s připojeným obchodním týmem.
Co zkontrolovat, než tomu začnete věřit
První otázka kontroly je, které povrchy FMI 3.0 váš model skutečně používá. Model Exchange, Co-Simulation, Scheduled Execution, hodiny, derivace, události, binární proměnné, řetězce, pole a závislosti nejsou stejná zátěž. Jednoduchý FMU a propojená multi-FMU simulace kladou na běhové prostředí a orchestrátor různý tlak.
Druhá otázka je, jaký numerický profil model deklaruje a proč. Pokud je odpověď cokoli, co fungovalo v příkladu, není to návrh. Profil by měl odpovídat rozsahu, rozlišení, reprezentaci času, toleranci a cílovému nasazení. Měl by být dostatečně viditelný, aby jej mohl recenzent zpochybnit, aniž by musel číst celý solver.
Třetí otázka je, jaké důkazy cestují s výsledkem. Která verze zdroje? Která verze FMU? Který modelDescription? Který profil Numerus? Který backend? Které kontroly oracle? Který stav přehrávání? Které testy shody nebo vlastností? Pokud jsou tyto odpovědi roztroušeny po wiki a v něčí paměti, simulace ještě není připravena k důvěře ve vážném pracovním postupu.
Ponaučení
Ponaučení z Dweve FMI není, že simulační standardy jsou nudné. Jsou nudné přesně tak, jak jsou mosty nudné, když stojí. FMI poskytuje obálku výměny. Pevný bod podporovaný Numerus dává postoj deterministické aritmetiky. Crates běhového prostředí a solveru posouvají model. Orchestrace propojuje FMU, aniž by předstírala, že načasování je triviální. Backendy přesouvají provádění na hardware, který odpovídá úkolu. Validace mění shodnost na bránu místo naděje.
To je ta práce. Ne velkolepé tvrzení, že čísla jsou navždy vyřešena. Ne lesklá ukázka, kde vše souhlasí, protože byla testována pouze jedna cesta. Simulační systém, který zná své formáty, deklaruje svou numerickou smlouvu, běží napříč backendy a hlasitě selže, když stejný model přestane být stejným modelem.
Model by si neměl vytvářet osobnost. Těch už máme na poradách dost.