FMI un tā pati simulācija visur
Modelim nevajadzētu attīstīt personību
Simulācijas modelim vienā ļoti konkrētā veidā vajadzētu būt garlaicīgam: viena ievade, viens modelis, viena izvade. Tas izklausās pašsaprotami, līdz modelis pārvietojas no darbstacijas uz klasteri, no klēpjdatora uz aparatūras cilpu, no viena kompilatora uz citu vai no piegādātāja rīka uz drošības nodaļu, kurai nepatīk interpretatīvā deja. Tad niecīgas skaitliskas atšķirības kļūst par sapulcēm. Sapulces kļūst par saskaņošanas izklājlapām. Saskaņošanas izklājlapas kļūst par kapsētu, kur mirst labas inženierijas pēcpusdienas.
FMI pastāv, lai modeļu apmaiņa un kopīgā simulācija būtu praktiska dažādos rīkos. Functional Mock-up Interface sniedz komandām standarta veidu, kā iepakot un palaist modeļus, tā vietā, lai ar rokām pārnēsātu trauslu integrācijas kodu no vienas simulācijas vides uz nākamo. Tas jau ir noderīgi. Taču standarta saskarne automātiski nepadara aritmētiku deterministisku. Tradicionālās FMI darbplūsmas bieži balstās uz IEEE 754 peldošā komata uzvedību, platformas bibliotēkām, kompilatora izvēli, izpildes secību un aizmugures atšķirībām. Lielākoties tas ir labi. Tad tas vairs nav labi, un atšķirību parasti atklāj kāds ar termiņu un seju, kas saka, ka iepirkums solīja, ka tas būs viegli.
Dweve FMI risina garlaicīgo un dārgo daļu: atkārtojamību. Vietnē aprakstīta Rust FMI implementācija Model Exchange un Co-Simulation ar deterministisku fiksētā komata aritmētiku, kas veidota uz Numerus. Implementācijas apjoms ir plašāks nekā demonstrācija: vairāku krātuņu FMI darbvieta ar modeļa attēlojumu, shēmas parsēšanu, importu, eksportu, izpildlaiku, risinātāju, orķestrēšanu, atmiņu, CPU, GPU, FPGA, edge un sadalītas izpildes aizmugurēm, FFI, fuzzing, etalonmērījumiem, dokumentāciju un testiem. Tā ir atkarīga no Numerus krātuvēm fiksētā komata un decimālajai aritmētikai, kā arī no kopējās Dweve tehnoloģiju kopas simulācijai, žurnālu reģistrēšanai, kļūdu apstrādei, transportam, tenzoriem un krātuvei.
Mērķis nav padarīt simulāciju mistisku. Mērķis ir panākt, lai viens un tas pats FMU pārstātu stāstīt nedaudz atšķirīgus stāstus tāpēc, ka tas pamodās citā mašīnā.
FMI dod aploksni, bet aritmētika joprojām raksta čeku
FMU ir noderīga aploksne. Tā satur modeļa aprakstu, bināros failus vai avota artefaktus, resursus, mainīgos, stāvokļus, pulksteņus, atkarības un pietiekami daudz metadatu, lai cits rīks varētu izveidot modeli un veikt tā soļus. FMI 3.0 pievieno bagātākus pulksteņus, plānotu izpildi, uzlabotu mainīgo tipu noteikšanu un kopīgās simulācijas mehānismus. Dweve FMI avota kods ir organizēts ap šo aploksni: fmi-schema parsē un validē modeļa aprakstus, fmi-import ielādē FMU arhīvus, fmi-export veido arhīvus, fmi-model attēlo mainīgos un modeļa stāvokli, un fmi-runtime pārvalda dzīves ciklu, mainīgo piekļuvi, pulksteņus, notikumus, atvasinājumus un stāvokļa saglabāšanu vai atjaunošanu.
Šī aploksne ir nepieciešama, bet nepietiekama. Aritmētika zem tās joprojām nosaka, vai palaišana ir atkārtojama. Izpildlaika dokumentācijā teikts, ka fiksētā komata aritmētika izmanto Numerus Q31_32 deterministiskiem aprēķiniem. Darbvietas metadatos Q31.32 ir nosaukts par noklusējuma fiksēto formātu, Dec64_6 par noklusējuma decimālo formātu un Q16.16 laikam. Publiskajā lapā runāts par Q31.32, Q16.16 un Dec64_6 profiliem, un MPFR tiek izmantots kā atsauces ceļš. Tas projektam dod skaidru līgumu: reālās vērtības simulācija jākartē deterministiskos skaitliskos profilos, nevis jāatstāj katram aizmugures risinājumam improvizēt.
Šeit ir svarīgs godīguma jautājums. FMI saskarnes un saderības virsmas joprojām var pieņemt vai izvadīt peldošā komata vērtības, jo standarts un esošie rīki tās sagaida. Svarīgais apgalvojums nav teatrāla tīrība katrā robežpunktā. Svarīgais apgalvojums ir tas, ka pamata deterministiskais ceļš ir veidots ap Numerus fiksētā komata profiliem un validāciju pret augstas precizitātes atsauci tur, kur salīdzināšanai ir jēga. Robežu adapteri var runāt ārējā valodā. Iekšējais līgums nedrīkst kļūt par vienaldzīgu atmetienu ar roku.
Skaitliskais profils ir modeļa lēmums
Fiksētais komats nav viens maģisks iestatījums. Modelim, kam vajadzīgas kompaktas laika vērtības, modelim ar plašiem fizikāliem diapazoniem un modelim, kas ziņo decimālos lielumus, nav identisks spiediens. Q16.16, Q31.32 un Dec64_6 nav uzlīmes prezentācijas slaidam. Tie ir dažādi līgumi par diapazonu, izšķirtspēju, attēlojumu un to, kur kļūdām ir atļauts atrasties.
Šeit simulācijas komandas bieži kļūst pārāk paviršas. Tās uztver skaitlisko uzvedību kā rīka īpašību, nevis modeļa īpašību. Tad rīks mainās, vai mainās aizmugures sistēma, vai modelis tiek iegults, un pēkšņi vecais pieņēmums kļūst par validācijas slogu. Dweve FMI padara skaitlisko profilu par arhitektūras daļu, nevis fonā esošiem laikapstākļiem. Tas nav tik iespaidīgi kā liela demonstrācija. Labi. Lielas demonstrācijas reti izskaidro, kam pieder noapaļošanas robeža.
Solvera krātuve stāsta to pašu stāstu. Tā atklāj ODE sistēmu pazīmes, RK4, RKF45, Euler, BDF orientētu konfigurāciju, adaptīvu soļu kontroli, notikumu noteikšanu un deterministisku solvera laiku. Izpildlaika krātuve pārvalda FMU dzīves ciklu, notikumu un nepārtraukta laika režīmus, mainīgo piekļuvi, ievades atvasinājumus, virziena un adjungētos atvasinājumus, Jakobi matricas kešošanu, pulksteņus un stāvokļa serializāciju. Nekas no tā nav noderīgs, ja skaitlisko slāni nevar uzticēt, kad tas pārvietojas starp aparatūrām. Solveris var būt gudrs. Modelis var būt elegants. Ja vienai un tai pašai palaišanai vajag trīs saskaņošanas reizes, elegance pārsvarā ir tikai dekorācija.
Kopīgā simulācija ir vieta, kur mazi meli kļūst dārgi
Viens FMU jau ir pietiekami daudz darba. Vairāki FMU, kas savienoti kopā, ir vieta, kur skaitliskās un darbības kļūdas kļūst sociālas. Termiskais modelis baro vadības modeli, vadības modelis baro izpildmehānisma modeli, izpildmehānisma modelis baro mehānisko modeli, un visi cer, ka soļu secība klusi nerada muļķības. Kopīgā simulācija prasa savienojumu pārvaldību, izpildes secību, datu apmaiņu, soļu koordināciju, algebrisko cilpu apstrādi un veidu, kā pateikt nē, ja grafs ir nepareizs.
Avotā šim darbam ir fmi-orchestration. Tas apstrādā vairāku FMU kopīgo simulāciju, savienojumus, ciklu noteikšanu, topoloģisko kārtošanu, nodalījumu plānošanu, algebrisko cilpu noteikšanu un risināšanu, vērtību vēsturi, izpildes secību, simulācijas laiku un orķestrācijas statistiku. Ir fmi-cc saziņai starp savienotiem FMU un fmi-dist sadalītai izpildei ar koordinatoriem, mezglu reģistrāciju, ziņojumiem, soļu pieprasījumiem, soļu atbildēm un statusa vērtībām. Tāda ir tā mehānika, ko cilvēki aizmirst, kad saka, ka integrācija ir tikai izeju savienošana ar ieejām. Jā, tā ir vadu vilkšana. Tā ir arī laika noteikšana, atkarību pārvaldība, stāvoklis, kļūmes un pierādījums, ka vadi izdarīja to, ko tie solīja.
Līdzsimulācija arī padara determinismu svarīgāku, nevis mazāk svarīgu. Ja viens FMU nedaudz novirzās un šī vērtība tiek padota citam FMU, nesakritība var izplatīties tālāk. Ja izpildes secība mainās starp mezgliem, nesakritība var palikt nepamanīta līdz vēlākam solim. Ja viens backend izmanto nedaudz atšķirīgu matemātikas ceļu, nesakritība var izskatīties pēc modeļa uzvedības. Tā komandas nonāk pie tā, ka fizikas kļūdas tiek meklētas, pārlasot sapulču protokolus. Nevienam nevajadzētu to darīt, ja vien viņš iepriekšējā dzīvē nav bijis ļoti slikts.
Backend izvēle ir izvietošanas lēmums, nevis jauna patiesība
Avota koka struktūrā izpildes mērķi ir sadalīti backend krātuvēs: CPU, GPU, FPGA, edge un distributed. Edge backend ir paredzēts ierobežotu resursu ierīcēm, ierobežotai atmiņai un zemām izmaksām. FPGA backend attiecas uz fiksēta punkta aritmētiku, DMA pārsūtīšanu, bitstream pārvaldību, kodola izpildi un aparatūras cilpā (hardware-in-the-loop). Distributed krātuve koordinē vairākus mezglus. Publiskajā lapā ir aprakstīti CPU SIMD, GPU, FPGA, edge un distributed ceļi. Tas nenozīmē, ka katrs mērķis ir vienlīdz nobriedis katram darba slodzes veidam. Tas nozīmē, ka arhitektūra backend izvēli uzskata par pirmšķirīgu jautājumu.
Galvenais dizaina princips ir tāds, ka izvietošanai vajadzētu mainīt to, kur simulācija tiek izpildīta, nevis to, ko simulācija nozīmē. CPU ceļš var būt visērtākais autorēšanai un verifikācijai. GPU ceļš var būt piemērots lielām paralēlām darba slodzēm. FPGA ceļš var būt nepieciešams reāllaika vai aparatūras cilpas darbībai. Edge ceļš var būt nepieciešams tuvu iekārtai. Distributed izpilde var būt nepieciešama lielām savienotām sistēmām. Tie ir operacionāli lēmumi. Tie nedrīkst radīt jaunu modeļa skaitlisko identitāti.
Šeit arī atklājas atvērtā koda nozīme. Drošībā, enerģētikā, robotikā, medicīnas ierīcēs, automobiļu rūpniecībā, aviācijā, rūpnieciskajā vadībā un digitālajos dvīņos reproducējamības apgalvojumi nevar palikt tikai pārdevēju prezentācijās. Kādam ir jāpārbauda implementācija, jāfiksē versija, jāpalaiž testi, jāizlasa kļūmju gadījumi un jāizlemj, vai pierādījumi ir pietiekami. Atvērtā koda FMI implementācija dod komandām labāku ceļu uz šiem pierādījumiem. Tā neko maģiski neapstiprina. Tā padara darbu pārbaudāmu, kas ir pirmais noderīgais solis.
Validācijai vajadzētu būt vārtiem, nevis panelim
Dweve FMI validācijas stāsts nav tikai par skaistiem izsekošanas datiem. README un vietne apraksta MPFR atsauces pārbaudes, backend savstarpējo ekvivalenci, deterministisku atkārtošanu, atbilstības testus, fuzzing un tipizētas kļūmes. Avotā ir fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, īpašību testi, fuzz rīki un stāvokļa serializācija. Tas ir pareizais virziens. Simulācijas infrastruktūrā validācijai nevajadzētu būt panelim, kur sarkana līnija izskatās satraucoša un kāds sola tai sekot. Tai vajadzētu būt vārtiem.
Vārtiem ir vairākas daļas. Importam ir jāparsē FMU arhīvs un modelDescription pareizi. Shēmas validācijai ir jānoraida nederīgas mainīgo definīcijas, atkarības, pulksteņi un atribūti. Skaitliskajām pārbaudēm ir nepieciešams orākuls, ja apgalvojums attiecas uz precizitāti. Backend paritātei ir nepieciešams vienāds stāvoklis visos izpildes mērķos. Atkārtošanai ir nepieciešami saglabāti stāvokļi un notikumu žurnāli, lai atjaunotu izpildi. Kļūmēm ir nepieciešamas tipizētas kļūdas, nevis noslēpumains neatbilstības ziņojums, kas liek komandai rakņāties pa žurnāliem. Neatbilstībai vajadzētu bloķēt izlaišanas ceļu, līdz tā ir saprasta vai skaidri pieņemta. Tas izklausās skarbi tikai tad, ja alternatīva vēl nav iesniegusi rēķinu.
Kur tas vispirms ir svarīgi
Acīmredzamās jomas ir tās, kur simulācijas kļūdas kļūst par fiziskām kļūdām: automobiļu rūpniecība, aviācija, rūpnieciskā vadība, medicīnas ierīces, enerģētika, robotika un infrastruktūra. Bremžu modelis, sūkņa kontrolleris, tīkla modelis, robotu šūna, rūpnīcas līnija vai HVAC kontrolleris nekļūst drošāks tāpēc, ka prezentācijā teikts digitālais dvīnis. Tas kļūst drošāks, kad modelis, ievaddati, skaitliskā profils, backends, versija un atkārtojuma izsekošana ir pietiekami kontrolēti, lai to varētu izmeklēt.
Ir arī iepirkuma aspekts, jo, protams, tāds ir. Ja katram backendam ir nepieciešams atsevišķs validācijas stāsts, katra aparatūras maiņa kļūst par nelielu atkārtotas sertifikācijas vingrinājumu. Ja vienu un to pašu FMU var pierādīt vienreiz un pēc tam palaist uz mērķa, kas atbilst darbības ierobežojumiem, komandas iegūst brīvību bez izlikšanās, ka validācija ir bezmaksas. Vietne to formulē kā pierādīt vienreiz un palaist jebkur. Inženiertehniskais tulkojums ir nedaudz mazāk romantisks: samazināt vietu skaitu, kurās viens un tas pats modelis var nonākt pretrunā ar sevi.
Tas ir īpaši aktuāli Eiropā. Suverenitāte nav tikai tas, kur atrodas serveris. Tā ir arī tas, vai drošības lietu var pārbaudīt, atkārtot un pārvietot bez lūgšanās vienam piegādātājam pēc atļaujas. Atvērta ieviešana, deterministiska aritmētika, reproducējama atkārtota izpilde un backendu paritāte paši par sevi neatrisina politiku. Tie padara tehnisko daļu mazāk atkarīgu no melnās kastes ar pārdošanas komandu.
Kas jāpārskata pirms uzticēšanās
Pirmais pārskatīšanas jautājums ir, kuras FMI 3.0 virsmas jūsu modelis faktiski izmanto. Model Exchange, Co-Simulation, Scheduled Execution, pulksteņi, atvasinājumi, notikumi, binārie mainīgie, virknes, masīvi un atkarības nav viens un tas pats darba apjoms. Vienkāršs FMU un savienota vairāku FMU simulācija rada atšķirīgu slodzi izpildlaikam un orķestrētājam.
Otrais jautājums ir, kuru skaitlisko profilu modelis deklarē un kāpēc. Ja atbilde ir kāds noklusējums, kas darbojās piemērā, tā nav dizains. Profilam jāatbilst diapazonam, izšķirtspējai, laika attēlojumam, pielaidei un izvietošanas mērķim. Tam jābūt pietiekami redzamam, lai recenzents to varētu apstrīdēt bez visa risinātāja izlasīšanas.
Trešais jautājums ir, kādi pierādījumi ceļo kopā ar rezultātu. Kura avota versija? Kura FMU versija? Kurš modelDescription? Kurš Numerus profils? Kurš backends? Kuras orākula pārbaudes? Kurš atkārtojuma stāvoklis? Kuri atbilstības vai īpašību testi? Ja šīs atbildes ir izkaisītas pa viki un kāda cilvēka atmiņu, simulācija vēl nav gatava uzticēšanai nopietnā darba plūsmā.
Mācība
Dweve FMI mācība nav tā, ka simulācijas standarti ir garlaicīgi. Tie ir garlaicīgi tieši tādā veidā, kā tilti ir garlaicīgi, kamēr tie stāv. FMI dod apmaiņas ietvaru. Numerus balstīts fiksētais punkts dod deterministiskās aritmētikas nostāju. Izpildlaika un risinātāja krātuves liek modelim soļot. Orķestrācija savieno FMU bez izlikšanās, ka laika noteikšana ir triviāla. Backendi pārvieto izpildi uz aparatūru, kas atbilst darbam. Validācija pārvērš vienādību par vārtiem, nevis cerību.
Tas ir darbs. Ne liels apgalvojums, ka skaitļi ir atrisināti uz visiem laikiem. Ne spīdīga demonstrācija, kur viss sakrīt, jo tika pārbaudīts tikai viens ceļš. Simulācijas sistēma, kas zina savus formātus, deklarē savu skaitlisko līgumu, darbojas dažādos backendos un skaļi neizdodas, kad viens un tas pats modelis pārstāj būt viens un tas pats modelis.
Modelim nevajadzētu attīstīt personību. Mums tādu pietiek sapulcēs.