FMI и една и съща симулация навсякъде
Моделът не трябва да развива личност
Един симулационен модел трябва да е скучен по един много специфичен начин: същият вход, същият модел, същият изход. Това звучи очевидно, докато моделът не премине от работна станция към клъстер, от лаптоп към hardware-in-the-loop, от един компилатор към друг, или от инструмент на доставчик към отдел по безопасност, който не оценява интерпретативния танц. Тогава малките числови разлики се превръщат в срещи. Срещите се превръщат в електронни таблици за съгласуване. Електронните таблици за съгласуване се превръщат в гробището, където добрите инженерни следобеди отиват да умрат.
FMI съществува, за да направи обмена на модели и съвместната симулация практични в различни инструменти. Functional Mock-up Interface дава на екипите стандартен начин за опаковане и стартиране на модели, вместо да пренасят на ръка крехък интеграционен код от една симулационна среда в друга. Това вече е полезно. Но стандартният интерфейс не прави автоматично аритметиката детерминистична. Традиционните FMI работни потоци често разчитат на поведението на IEEE 754 с плаваща запетая, платформени библиотеки, избори на компилатор, реда на изпълнение и разлики в бекендите. През повечето време това е наред. После не е наред, и разликата обикновено се открива от някой с краен срок и лице, което казва, че доставките са обещали, че това ще е лесно.
Dweve FMI атакува скучната и скъпа част: възпроизводимостта. Сайтът описва Rust имплементация на FMI за Model Exchange и Co-Simulation с детерминистична аритметика с фиксирана запетая, изградена върху Numerus. Формата на имплементацията е по-широка от демо: мулти-крейтово FMI работно пространство с представяне на модели, разбор на схеми, импорт, експорт, рантайм, решавател, оркестрация, памет, бекенди за CPU, GPU, FPGA, периферни и разпределени изпълнения, FFI, фъзинг, бенчмаркове, документация и тестове. Тя разчита на Numerus крейтове за аритметика с фиксирана запетая и десетична аритметика, плюс общия Dweve стек за симулация, регистриране, обработка на грешки, транспорт, тензори и съхранение.
Целта не е да направи симулацията да звучи мистично. Целта е един и същ FMU да спре да разказва леко различни истории, защото се е събудил на различна машина.
FMI дава обвивката, аритметиката все още пише чека
FMU е полезна обвивка. Тя носи описание на модела, двоични файлове или изходни артефакти, ресурси, променливи, състояния, часовници, зависимости и достатъчно метаданни, за да може друг инструмент да инстанцира и стъпва модела. FMI 3.0 добавя по-богати часовници, планирано изпълнение, подобрено типизиране на променливи и механизми за съвместна симулация. Изходният код на Dweve FMI е организиран около тази обвивка: fmi-schema разборва и валидира описания на модели, fmi-import зарежда FMU архиви, fmi-export изгражда архиви, fmi-model представя променливи и състояние на модела, а fmi-runtime отговаря за жизнения цикъл, достъпа до променливи, часовниците, събитията, производните и запазването или възстановяването на състояние.
Тази обвивка е необходима, но не е достатъчна. Аритметиката отдолу все още решава дали едно изпълнение е възпроизводимо. Документацията на рантайма казва, че аритметиката с фиксирана запетая използва Numerus Q31_32 за детерминистични изчисления. Метаданните на работното пространство посочват Q31.32 като формат по подразбиране за фиксирана запетая, Dec64_6 като формат по подразбиране за десетични числа и Q16.16 за време. Публичната страница говори за профилите Q31.32, Q16.16 и Dec64_6, като MPFR се използва като референтен път. Това дава на проекта ясен договор: симулацията с реални стойности трябва да бъде преобразувана в детерминистични числови профили, вместо да се оставя всеки бекенд да импровизира.
Тук има важен момент за честността. API-тата и повърхностите за съвместимост, обърнати към FMI, може все още да приемат или връщат стойности с плаваща запетая, защото стандартът и съществуващите инструменти ги очакват. Твърдението, което има значение, не е театрална чистота на всяка граница. Твърдението, което има значение, е, че основният детерминистичен път е изграден около профили с фиксирана запетая Numerus и валидация спрямо еталон с висока точност там, където сравнението има смисъл. Периферните адаптери могат да говорят външния език. Вътрешният договор не трябва да се превръща в свиване на рамене.
Числовият профил е решение на модела
Фиксираната запетая не е една магическа настройка. Модел, който се нуждае от компактни времеви стойности, модел с широки физически диапазони и модел, който отчита десетични количества, не са под еднакво напрежение. Q16.16, Q31.32 и Dec64_6 не са стикери за презентация. Те са различни договори за обхват, разделителна способност, представяне и за това къде на грешките им е позволено да съществуват.
Точно тук симулационните екипи често стават твърде небрежни. Те третират численото поведение като свойство на инструмента, а не като свойство на модела. После инструментът се промени, или бекендът се промени, или моделът бъде вграден, и изведнъж старата предпоставка се превръща в тежест за валидацията. Dweve FMI прави числовия профил част от архитектурата, а не фонови метеорологични условия. Това е по-малко бляскаво от голяма демонстрация. И добре. Големите демонстрации рядко обясняват кой отговаря за границата на закръгляването.
Крейтът за решаване на уравнения разказва същата история. Той излага характеристики на ODE системи, RK4, RKF45, Euler, конфигурация, ориентирана към BDF, адаптивен контрол на стъпката, откриване на събития и детерминистично време на решаване. Крейтът за изпълнение притежава жизнения цикъл на FMU, режимите на събития и непрекъснато време, достъпа до променливи, производните на входа, насочените и съпътстващите производни, кеширането на Якобиан, часовниците и сериализацията на състоянието. Нищо от това не е полезно, ако числовият слой не може да бъде надежден, когато се движи между хардуерни платформи. Решаващият инструмент може да е умен. Моделът може да е елегантен. Ако едно и също изпълнение изисква три съгласувания, елегантността е предимно декорация.
При съвместната симулация малките лъжи стават скъпи
Един FMU вече е достатъчно работа. Няколко FMU, свързани заедно, са мястото, където числовите и оперативните грешки стават социален проблем. Термичен модел захранва контролен модел, контролният модел захранва модел на задвижващ механизъм, моделът на задвижващия механизъм захранва механичен модел и всички се надяват, че редът на стъпките не създава тихо безсмислици. Съвместната симулация се нуждае от управление на връзките, ред на изпълнение, обмен на данни, координиране на стъпките, обработка на алгебрични цикли и начин да се каже „не“, когато графът е грешен.
Изходният код има fmi-orchestration за тази работа. Той обработва съвместна симулация с множество FMU, връзки, откриване на цикли, топологично подреждане, планиране на дялове, откриване и решаване на алгебрични цикли, история на стойностите, ред на изпълнение, време на симулацията и статистика за оркестрацията. Има fmi-cc за комуникация между свързани FMU и fmi-dist за разпределено изпълнение с координатори, регистрация на възли, съобщения, заявки за стъпки, отговори на стъпки и стойности на състоянието. Това е вид механизъм, който хората забравят, когато казват, че интеграцията е просто свързване на изходи към входове. Да, това е свързване. Но е също така синхронизация, управление на зависимости, състояние, отказ и доказателство, че свързването е направило това, което е обещало.
Съвместната симулация прави детерминизма още по-важен, а не по-малко. Ако една FMU се отклони леко и тази стойност се подаде на друга FMU, разминаването може да се разпространи. Ако редът на изпълнение се промени между възлите, разминаването може да остане скрито до по-късна стъпка. Ако един backend използва леко различен математически път, разминаването може да изглежда като поведение на модела. Ето как екипите се озовават да дебъгват физика с протоколи от срещи. Никой не би трябвало да прави това, освен ако не е бил много лош в предишен живот.
Backend-ите са избор за внедряване, а не нови истини
Дървото на изходния код разделя целите за изпълнение в backend crate-ове: CPU, GPU, FPGA, edge и разпределено. Edge backend-ът се фокусира върху устройства с ограничени ресурси, ограничена памет и нисък разход. FPGA backend-ът говори за аритметика с фиксирана запетая, DMA трансфери, управление на bitstream, изпълнение на ядра и hardware-in-the-loop. Разпределеният crate координира множество възли. Публичната страница описва CPU SIMD, GPU, FPGA, edge и разпределени пътища. Това не означава, че всяка цел е еднакво зряла за всяко натоварване. Означава, че архитектурата третира избора на backend като първостепенен въпрос.
Ключовият принцип на дизайна е, че внедряването трябва да променя къде се изпълнява симулацията, а не какво означава моделът. CPU пътят може да е най-лесен за създаване и проверка. GPU пътят може да има смисъл за големи паралелни натоварвания. FPGA пътят може да е необходим за реално време или hardware-in-the-loop. Edge пътят може да е необходим близо до машината. Разпределеното изпълнение може да е необходимо за големи свързани системи. Това са оперативни избори. Те не трябва да създават нова числена идентичност за модела.
Тук също се вижда защо отвореният код има значение. В безопасността, енергетиката, роботиката, медицинските устройства, автомобилостроенето, аерокосмическата индустрия, индустриалния контрол и цифровите близнаци, твърденията за възпроизводимост не могат да живеят само в слайдове на доставчици. Някой трябва да провери имплементацията, да фиксира версия, да пусне тестовете, да прочете случаите на отказ и да реши дали доказателствата са достатъчно добри. Имплементацията на FMI с отворен код дава на екипите по-добър път към тези доказателства. Тя не сертифицира нищо магически. Тя прави работата проверима, което е първата полезна стъпка.
Валидацията трябва да е порта, а не табло
Историята на валидацията на Dweve FMI не е само за красиви графики. README и сайтът описват MPFR референтни проверки, еквивалентност между backend-и, детерминирано възпроизвеждане, тестове за съответствие, фъзинг и типизирани грешки. Изходният код съдържа fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, property тестове, фъзинг рамки и сериализация на състоянието. Това е правилната посока. В симулационната инфраструктура валидацията не трябва да е табло, където червена линия изглежда притеснителна и някой обещава да я наблюдава. Тя трябва да е порта.
Портата има няколко части. Импортът трябва да разгледа правилно FMU архива и modelDescription. Валидацията на схемата трябва да отхвърля невалидни дефиниции на променливи, зависимости, часовници и атрибути. Числените проверки се нуждаят от оракул, когато твърдението е за точност. Паритетът между backend-и изисква едно и също състояние във всички цели за изпълнение. Възпроизвеждането изисква запазено състояние и журнали на събития, за да се възстанови изпълнението. Отказът изисква типизирани грешки, а не мистериозен доклад за несъответствие, който праща екипа да рови из журналите. Несъответствие трябва да блокира пътя за пускане, докато не бъде разбрано или изрично прието. Това звучи сурово само ако алтернативата още не ви е издала фактура.
Къде това има значение най-напред
Очевидните области са тези, където грешките в симулацията стават физически грешки: автомобилостроене, аерокосмическа индустрия, промишлено управление, медицински устройства, енергетика, роботика и инфраструктура. Модел на спирачка, контролер на помпа, модел на енергийната мрежа, роботизирана клетка, производствена линия или контролер за ОВК не става по-безопасен, защото даден слайд казва „дигитален близнак“. Той става по-безопасен, когато моделът, входните данни, числовият профил, бекендът, версията и следата за повторно изпълнение са достатъчно контролирани, за да бъдат разследвани.
Има и ъгъл на снабдяването, защото, разбира се, винаги има такъв. Ако всеки бекенд изисква отделна история за валидация, всяка промяна на хардуера се превръща в малко упражнение по ресертификация. Ако един и същ FMU може да бъде доказан веднъж и след това да работи на целевата платформа, която отговаря на оперативните ограничения, екипите получават свобода, без да се преструват, че валидацията е безплатна. Сайтът формулира това като „докажи веднъж, изпълнявай навсякъде“. Инженерният превод е малко по-малко романтичен: намали броя на местата, където един и същ модел може да противоречи на себе си.
Това е особено важно в Европа. Суверенитетът не е само къде стои сървърът. Той е също така дали даден случай за безопасност може да бъде проверен, повторен и преместен, без да се моли един доставчик за разрешение. Отворената реализация, детерминираната аритметика, възпроизводимото повторно изпълнение и паритетът на бекендите не решават политиката сами по себе си. Те правят техническата част по-малко зависима от черна кутия с прикачен търговски екип.
Какво да прегледате, преди да му се доверите
Първият въпрос за преглед е кои повърхности на FMI 3.0 вашият модел реално използва. Model Exchange, Co-Simulation, Scheduled Execution, часовници, производни, събития, двоични променливи, низове, масиви и зависимости не са едно и също натоварване. Обикновен FMU и свързана симулация с няколко FMU поставят различно напрежение върху средата за изпълнение и оркестратора.
Вторият въпрос е кой числов профил декларира моделът и защо. Ако отговорът е „какъвто и да е по подразбиране, който е работил в примера“, това не е дизайн. Профилът трябва да съответства на обхвата, разделителната способност, представянето на времето, толеранса и целевата платформа за разгръщане. Той трябва да е достатъчно видим, за да може рецензент да го оспори, без да чете целия решавател.
Третият въпрос е какви доказателства придружават даден резултат. Коя версия на източника? Коя версия на FMU? Кой modelDescription? Кой профил на Numerus? Кой бекенд? Кои проверки с оракул? Кое състояние за повторно изпълнение? Кои тестове за съответствие или свойства? Ако тези отговори са разпръснати из уики и нечия памет, симулацията все още не е готова да ѝ се вярва в сериозен работен процес.
Урокът
Урокът на Dweve FMI не е, че стандартите за симулация са скучни. Те са скучни точно по начина, по който мостовете са скучни, когато стоят стабилни. FMI дава обвивката за обмен. Фиксираната запетая с подкрепата на Numerus дава детерминираната аритметична позиция. Крайтовете за средата за изпълнение и решавателя правят модела да стъпва. Оркестрацията свързва FMU, без да се преструва, че синхронизацията на времето е тривиална. Бекендите преместват изпълнението към хардуера, който отговаря на задачата. Валидацията превръща еднаквостта в порта, а не в надежда.
Това е работата. Не грандиозно твърдение, че числата са решени завинаги. Не блестяща демонстрация, където всичко съвпада, защото е тестван само един път. Симулационна система, която познава форматите си, декларира числовия си договор, работи на различни бекенди и се проваля шумно, когато един и същ модел престане да бъде същият модел.
Моделът не трябва да развива личност. Имаме достатъчно такива в срещите.