FMI i ta sama symulacja wszędzie
Model nie powinien rozwijać osobowości
Model symulacyjny powinien być nudny w jednym, bardzo konkretnym sensie: te same dane wejściowe, ten sam model, ten sam wynik. Brzmi to oczywisto, dopóki model nie przeniesie się ze stacji roboczej na klaster, z laptopa do układu hardware-in-the-loop, z jednego kompilatora na inny, albo z narzędzia dostawcy do działu bezpieczeństwa, który nie docenia tańca interpretacyjnego. Wtedy drobne różnice numeryczne stają się spotkaniami. Spotkania stają się arkuszami kalkulacyjnymi do uzgodnień. Arkusze kalkulacyjne do uzgodnień stają się cmentarzyskiem, na którym umierają dobre popołudnia inżynierskie.
FMI istnieje po to, aby wymiana modeli i ko-symulacja były praktyczne w różnych narzędziach. Functional Mock-up Interface daje zespołom standardowy sposób pakowania i uruchamiania modeli, zamiast ręcznego przenoszenia kruchego kodu integracyjnego z jednego środowiska symulacyjnego do następnego. To już jest przydatne. Ale standardowy interfejs nie sprawia automatycznie, że arytmetyka jest deterministyczna. Tradycyjne przepływy pracy FMI często opierają się na zachowaniu zmiennoprzecinkowym IEEE 754, bibliotekach platformowych, wyborach kompilatora, kolejności wykonywania i różnicach w backendach. W większości przypadków to wystarcza. Potem przestaje wystarczać, a różnicę zwykle odkrywa ktoś z terminem i miną mówiącą, że dział zakupów obiecał, że to będzie łatwe.
Dweve FMI atakuje nudną, kosztowną część: odtwarzalność. Strona opisuje implementację FMI w języku Rust dla Model Exchange i Co-Simulation z deterministyczną arytmetyką stałoprzecinkową, zbudowaną na Numerus. Kształt implementacji jest szerszy niż demo: wieloskrzynkowy obszar roboczy FMI z reprezentacją modelu, parsowaniem schematów, importem, eksportem, środowiskiem wykonawczym, solverem, orkiestracją, pamięcią, backendami dla CPU, GPU, FPGA, brzegowego i rozproszonego wykonywania, FFI, fuzzowaniem, benchmarkami, dokumentacją i testami. Zależy od skrzynek Numerus dla arytmetyki stałoprzecinkowej i dziesiętnej, plus wspólnego stosu Dweve do symulacji, logowania, obsługi błędów, transportu, tensorów i przechowywania.
Celem nie jest uczynienie symulacji mistyczną. Celem jest sprawienie, aby ten sam FMU przestał opowiadać nieco inne historie, ponieważ obudził się na innej maszynie.
FMI daje kopertę, ale arytmetyka wciąż wypisuje czek
FMU to użyteczna koperta. Niesie opis modelu, binarne artefakty lub kod źródłowy, zasoby, zmienne, stany, zegary, zależności i wystarczająco dużo metadanych, aby inne narzędzie mogło utworzyć instancję modelu i wykonać krok. FMI 3.0 dodaje bogatsze zegary, planowane wykonywanie, lepsze typowanie zmiennych i mechanizmy ko-symulacji. Źródło Dweve FMI jest zorganizowane wokół tej koperty: fmi-schema parsuje i waliduje opisy modeli, fmi-import ładuje archiwa FMU, fmi-export buduje archiwa, fmi-model reprezentuje zmienne i stan modelu, a fmi-runtime zarządza cyklem życia, dostępem do zmiennych, zegarami, zdarzeniami, pochodnymi oraz zapisem i przywracaniem stanu.
Ta koperta jest konieczna, ale niewystarczająca. Arytmetyka pod spodem nadal decyduje, czy uruchomienie jest odtwarzalne. Dokumentacja środowiska wykonawczego mówi, że arytmetyka stałoprzecinkowa używa Numerus Q31_32 do deterministycznych obliczeń. Metadane obszaru roboczego wymieniają Q31.32 jako domyślny format stałoprzecinkowy, Dec64_6 jako domyślny format dziesiętny, a Q16.16 dla czasu. Strona publiczna mówi o profilach Q31.32, Q16.16 i Dec64_6, z MPFR używanym jako trasa referencyjna. To daje projektowi jasny kontrakt: symulacja o wartościach rzeczywistych powinna być mapowana na deterministyczne profile numeryczne, zamiast pozostawiać każdemu backendowi improwizację.
Warto tu uczciwie powiedzieć wprost. Interfejsy i powierzchnie zgodności skierowane do FMI mogą nadal przyjmować lub zwracać wartości zmiennoprzecinkowe, ponieważ standard i istniejące narzędzia tego oczekują. Nie chodzi o teatralną czystość na każdej granicy. Liczy się to, że główna ścieżka deterministyczna opiera się na profilach stałoprzecinkowych Numerus oraz walidacji względem referencji o wysokiej precyzji tam, gdzie porównanie ma sens. Adaptery brzegowe mogą mówić językiem świata zewnętrznego. Kontrakt wewnętrzny nie powinien być wzruszeniem ramion.
Profil numeryczny to decyzja modelu
Stały przecinek to nie jedno magiczne ustawienie. Model potrzebujący zwartych wartości czasu, model o szerokich zakresach fizycznych i model raportujący wielkości dziesiętne nie mają identycznych wymagań. Q16.16, Q31.32 i Dec64_6 to nie naklejki na slajd. To różne kontrakty dotyczące zakresu, rozdzielczości, reprezentacji i tego, gdzie błędy mogą się znajdować.
To właśnie tutaj zespoły symulacyjne często bywają zbyt nonszalanckie. Traktują zachowanie numeryczne jako właściwość narzędzia, a nie modelu. Potem narzędzie się zmienia, backend się zmienia albo model jest osadzany i nagle stare założenie staje się ciężarem walidacyjnym. Dweve FMI czyni profil numeryczny częścią architektury, a nie tłem pogodowym. To mniej efektowne niż duże demo. Dobrze. Duże dema rzadko wyjaśniają, kto odpowiada za granicę zaokrągleń.
Krata solvera opowiada tę samą historię. Udostępnia cechy systemów ODE, RK4, RKF45, Eulera, konfigurację zorientowaną na BDF, adaptacyjną kontrolę kroku, wykrywanie zdarzeń i deterministyczny czas solvera. Krata wykonawcza odpowiada za cykl życia FMU, tryby zdarzeń i czasu ciągłego, dostęp do zmiennych, pochodne wejściowe, pochodne kierunkowe i sprzężone, buforowanie Jakobianów, zegary i serializację stanu. Żadne z tego nie jest przydatne, jeśli warstwa numeryczna nie budzi zaufania przy przenoszeniu między platformami sprzętowymi. Solver może być sprytny. Model może być elegancki. Jeśli to samo uruchomienie wymaga trzech uzgodnień, elegancja jest w większości dekoracją.
Ko-symulacja to miejsce, gdzie małe kłamstwa stają się kosztowne
Jeden FMU to już sporo pracy. Kilka połączonych FMU to miejsce, gdzie błędy numeryczne i operacyjne stają się sprawą społeczną. Model termiczny zasila model sterowania, model sterowania zasila model siłownika, model siłownika zasila model mechaniczny i wszyscy mają nadzieję, że kolejność kroków po cichu nie tworzy bzdur. Ko-symulacja wymaga zarządzania połączeniami, kolejności wykonania, wymiany danych, koordynacji kroków, obsługi pętli algebraicznych i sposobu na odmowę, gdy graf jest błędny.
Do tej pracy służy w źródłach fmi-orchestration. Obsługuje ko-symulację wielu FMU, połączenia, wykrywanie cykli, porządkowanie topologiczne, planowanie partycji, wykrywanie i rozwiązywanie pętli algebraicznych, historię wartości, kolejność wykonania, czas symulacji i statystyki orkiestracji. Jest też fmi-cc do komunikacji między sprzężonymi FMU oraz fmi-dist do wykonania rozproszonego z koordynatorami, rejestracją węzłów, komunikatami, żądaniami kroków, odpowiedziami kroków i wartościami statusu. To ten rodzaj mechaniki, o której ludzie zapominają, gdy mówią, że integracja to tylko podłączanie wyjść do wejść. To okablowanie, tak. To także synchronizacja, zarządzanie zależnościami, stan, awarie i dowód, że okablowanie zrobiło to, co deklarowało.
Ko-symulacja sprawia też, że determinizm staje się ważniejszy, a nie mniej ważny. Jeśli jeden FMU nieznacznie dryfuje, a ta wartość trafia do innego FMU, rozbieżność może się rozprzestrzeniać. Jeśli kolejność wykonywania zmienia się między węzłami, rozbieżność może się ukrywać aż do późniejszego kroku. Jeśli jeden backend używa nieco innej ścieżki matematycznej, rozbieżność może wyglądać jak zachowanie modelu. Tak właśnie zespoły kończą z debugowaniem fizyki za pomocą protokołów ze spotkań. Nikt nie powinien musieć tego robić, chyba że w poprzednim życiu był bardzo niegrzeczny.
Backendy to wybory wdrożeniowe, nie nowe prawdy
Drzewo źródłowe dzieli cele wykonania na krety backendów: CPU, GPU, FPGA, edge i rozproszone. Backend edge koncentruje się na urządzeniach o ograniczonych zasobach, ograniczonej pamięci i niskim narzucie. Backend FPGA zajmuje się arytmetyką stałoprzecinkową, transferami DMA, zarządzaniem bitstreamem, wykonywaniem jąder i sprzętem w pętli. Kreacja rozproszona koordynuje wiele węzłów. Strona publiczna opisuje ścieżki CPU SIMD, GPU, FPGA, edge i rozproszone. To nie znaczy, że każdy cel jest równie dojrzały dla każdego obciążenia. Oznacza to, że architektura traktuje wybór backendu jako sprawę pierwszorzędną.
Kluczową zasadą projektową jest to, że wdrożenie powinno zmieniać miejsce, w którym działa symulacja, a nie znaczenie symulacji. Ścieżka CPU może być najłatwiejsza do tworzenia i weryfikacji. Ścieżka GPU może mieć sens w przypadku dużych równoległych obciążeń. Ścieżka FPGA może być potrzebna do pracy w czasie rzeczywistym lub sprzętu w pętli. Ścieżka edge może być potrzebna w pobliżu maszyny. Wykonywanie rozproszone może być potrzebne w przypadku dużych sprzężonych systemów. To są wybory operacyjne. Nie powinny tworzyć nowej tożsamości numerycznej modelu.
To jest również miejsce, w którym open source ma znaczenie. W bezpieczeństwie, energetyce, robotyce, urządzeniach medycznych, motoryzacji, lotnictwie, sterowaniu przemysłowym i cyfrowych bliźniakach twierdzenia o powtarzalności nie mogą żyć tylko na slajdach dostawców. Ktoś musi sprawdzić implementację, przypiąć wersję, uruchomić testy, przeczytać przypadki awarii i zdecydować, czy dowody są wystarczające. Implementacja FMI w open source daje zespołom lepszą drogę do tych dowodów. Nie certyfikuje niczego magicznie. Sprawia, że praca jest możliwa do sprawdzenia, co jest pierwszym użytecznym krokiem.
Walidacja powinna być bramą, a nie pulpitem
Historia walidacji Dweve FMI to nie tylko ładne ślady. README i strona opisują referencyjne kontrole MPFR, równoważność między backendami, deterministyczne odtwarzanie, testy zgodności, fuzzowanie i typowane błędy. Źródło zawiera fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, testy właściwości, uprzęże fuzzujące i serializację stanu. To jest właściwy kierunek. W infrastrukturze symulacyjnej walidacja nie powinna być pulpitem, na którym czerwona linia wygląda niepokojąco i ktoś obiecuje ją obserwować. Powinna być bramą.
Brama ma kilka części. Import musi poprawnie analizować archiwum FMU i modelDescription. Walidacja schematu musi odrzucać nieprawidłowe definicje zmiennych, zależności, zegary i atrybuty. Kontrole numeryczne potrzebują wyroczni, gdy twierdzenie dotyczy dokładności. Parytet backendów wymaga tego samego stanu na wszystkich celach wykonania. Odtwarzanie wymaga zapisanego stanu i dzienników zdarzeń, aby odtworzyć przebieg. Awarie wymagają typowanych błędów, a nie tajemniczego raportu o niezgodności, który wysyła zespół na poszukiwania w logach. Niezgodność powinna blokować ścieżkę wydania, dopóki nie zostanie zrozumiana lub jawnie zaakceptowana. To brzmi surowo tylko wtedy, gdy alternatywa jeszcze nie wystawiła ci rachunku.
Gdzie to ma znaczenie w pierwszej kolejności
Oczywiste obszary to te, w których błędy symulacji stają się błędami fizycznymi: motoryzacja, lotnictwo, sterowanie przemysłowe, urządzenia medyczne, energetyka, robotyka i infrastruktura. Model hamulca, sterownik pompy, model sieci, komórka robotyczna, linia produkcyjna czy sterownik HVAC nie stają się bezpieczniejsze, ponieważ slajd mówi cyfrowy bliźniak. Stają się bezpieczniejsze, gdy model, dane wejściowe, profil numeryczny, backend, wersja i ślad odtwarzania są wystarczająco kontrolowane, aby można było je zbadać.
Jest też aspekt zakupowy, bo oczywiście jest. Jeśli każdy backend wymaga osobnej historii walidacji, każda zmiana sprzętu staje się małym ćwiczeniem z ponownej certyfikacji. Jeśli ten sam FMU można udowodnić raz, a potem uruchomić na docelowej platformie, która spełnia ograniczenia operacyjne, zespoły zyskują swobodę bez udawania, że walidacja jest darmowa. Witryna ujmuje to jako udowodnienie raz i uruchamianie wszędzie. Inżynierskie tłumaczenie jest nieco mniej romantyczne: zmniejsz liczbę miejsc, w których ten sam model może być ze sobą w sprzeczności.
Jest to szczególnie istotne w Europie. Suwerenność to nie tylko to, gdzie znajduje się serwer. To także to, czy przypadek bezpieczeństwa można zbadać, powtórzyć i przenieść bez proszenia jednego dostawcy o pozwolenie. Otwarta implementacja, deterministyczna arytmetyka, powtarzalne odtwarzanie i zgodność backendów nie rozwiązują polityki same w sobie. Sprawiają jednak, że część techniczna jest mniej zależna od czarnej skrzynki z dołączonym zespołem sprzedaży.
Co sprawdzić, zanim temu zaufasz
Pierwsze pytanie kontrolne brzmi: z których powierzchni FMI 3.0 twój model faktycznie korzysta. Model Exchange, Co-Simulation, Scheduled Execution, zegary, pochodne, zdarzenia, zmienne binarne, łańcuchy, tablice i zależności to nie to samo obciążenie. Prosty FMU i sprzężona symulacja wielu FMU wywierają różny nacisk na środowisko uruchomieniowe i orkiestratora.
Drugie pytanie brzmi: jaki profil numeryczny deklaruje model i dlaczego. Jeśli odpowiedź brzmi „cokolwiek domyślnie zadziałało w przykładzie”, to nie jest projekt. Profil powinien odpowiadać zakresowi, rozdzielczości, reprezentacji czasu, tolerancji i docelowej platformie wdrożenia. Powinien być na tyle widoczny, aby recenzent mógł go zakwestionować bez czytania całego solvera.
Trzecie pytanie brzmi: jakie dowody towarzyszą wynikowi. Która wersja źródła? Która wersja FMU? Który modelDescription? Który profil Numerus? Który backend? Które kontrole orakla? Który stan odtwarzania? Które testy zgodności lub właściwości? Jeśli te odpowiedzi są rozproszone po wiki i w czyjejś pamięci, symulacja nie jest jeszcze gotowa, aby jej zaufać w poważnym przepływie pracy.
Lekcja
Lekcja Dweve FMI nie jest taka, że standardy symulacji są nudne. Są nudne dokładnie w ten sposób, w jaki mosty są nudne, gdy stoją. FMI zapewnia kopertę wymiany. Arytmetyka stałoprzecinkowa oparta na Numerus zapewnia deterministyczną postawę numeryczną. Skrzynie środowiska uruchomieniowego i solvera wykonują krok modelu. Orkiestracja łączy FMU bez udawania, że synchronizacja czasu jest trywialna. Backendy przenoszą wykonanie na sprzęt, który pasuje do zadania. Walidacja zamienia identyczność w bramę zamiast w nadzieję.
To jest praca. Nie wielkie twierdzenie, że liczby są rozwiązane na zawsze. Nie błyszczące demo, w którym wszystko się zgadza, ponieważ przetestowano tylko jedną ścieżkę. System symulacyjny, który zna swoje formaty, deklaruje swój kontrakt numeryczny, działa na różnych backendach i głośno zawodzi, gdy ten sam model przestaje być tym samym modelem.
Model nie powinien rozwijać osobowości. Mamy ich wystarczająco dużo na spotkaniach.