FMI ja sama simulointi kaikkialla
Mallin ei pitäisi kehittää persoonallisuutta
Simulaatiomallin pitäisi olla tylsä yhdellä hyvin erityisellä tavalla: sama syöte, sama malli, sama tulos. Se kuulostaa itsestäänselvyydeltä, kunnes malli siirtyy työasemasta klusteriin, kannettavasta laitteesta hardware-in-the-loop-järjestelmään, kääntäjältä toiselle tai toimittajan työkalusta turvallisuusosastolle, joka ei arvosta tulkitsevaa tanssia. Sitten pienistä numeerisista eroista tulee palavereita. Palavereista tulee täsmäytystaulukoita. Täsmäytystaulukoista tulee hautausmaa, jolle hyvät suunnitteluiltapäivät kuolevat.
FMI on olemassa, jotta mallinvaihto ja yhteissimulaatio toimisivat käytännössä eri työkalujen välillä. Functional Mock-up Interface tarjoaa tiimeille standardin tavan paketoida ja ajaa malleja sen sijaan, että hauras integraatiokoodi kannettaisiin käsin simulaatioympäristöstä toiseen. Se on jo itsessään hyödyllistä. Mutta standardiliitäntä ei automaattisesti tee aritmetiikasta determinististä. Perinteiset FMI-työnkulut nojaavat usein IEEE 754 -liukulukukäyttäytymiseen, alustakirjastoihin, kääntäjävalintoihin, suoritusjärjestykseen ja taustajärjestelmien eroihin. Useimmiten se on hyväksyttävää. Sitten se ei enää ole, ja ero huomataan yleensä sellaisen toimesta, jolla on määräaika ja jonka kasvoista näkee, että hankinta lupasi tämän olevan helppoa.
Dweve FMI keskittyy tylsään ja kalliiseen osaan: toistettavuuteen. Sivusto kuvaa Rust-pohjaista FMI-toteutusta Model Exchange- ja Co-Simulation-tiloille deterministisellä kiinteän pisteen aritmetiikalla, joka on rakennettu Numeruksen varaan. Toteutuksen rakenne on laajempi kuin demossa: moniosainen FMI-työtila, johon kuuluu malliesitys, skeeman jäsennys, tuonti, vienti, ajonaikainen ympäristö, ratkaisija, orkestrointi, muisti, taustajärjestelmät CPU:lle, GPU:lle, FPGA:lle, reuna- ja hajautetulle suoritukselle, FFI, fuzzaus, vertailuarvot, dokumentaatio ja testit. Se käyttää Numerus-kirjastoja kiinteän pisteen ja desimaaliaritmetiikkaan sekä yhteistä Dweve-pinoa simulointiin, lokitukseen, virheiden käsittelyyn, tiedonsiirtoon, tensoreihin ja tallennukseen.
Tavoitteena ei ole tehdä simuloinnista mystistä. Tavoitteena on saada sama FMU lopettamaan hieman erilaisten tarinoiden kertominen vain siksi, että se heräsi eri koneella.
FMI antaa kirjekuoren, mutta aritmetiikka kirjoittaa shekin
FMU on hyödyllinen kirjekuori. Se sisältää mallikuvauksen, binäärit tai lähdekoodiartefaktit, resurssit, muuttujat, tilat, kellot, riippuvuudet ja riittävästi metatietoa, jotta toinen työkalu voi instansioida ja askeltaa mallin. FMI 3.0 lisää rikkaammat kellot, ajoitetun suorituksen, parannetun muuttujatyypityksen ja yhteissimulaatiomekaniikan. Dweve FMI:n lähdekoodi on järjestetty tämän kirjekuoren ympärille: fmi-schema jäsentää ja validoi mallikuvaukset, fmi-import lataa FMU-arkistot, fmi-export rakentaa arkistot, fmi-model esittää muuttujat ja mallin tilan, ja fmi-runtime hallinnoi elinkaarta, muuttujien käyttöä, kelloja, tapahtumia, derivaattoja sekä tilan tallennusta ja palautusta.
Tämä kirjekuori on välttämätön, mutta ei riittävä. Alla oleva aritmetiikka ratkaisee edelleen, onko ajo toistettava. Ajonaikaisen ympäristön dokumentaation mukaan kiinteän pisteen aritmetiikka käyttää Numerus Q31_32 -muotoa deterministiseen laskentaan. Työtilan metatiedot nimeävät Q31.32:n oletuskiinteäksi muodoksi, Dec64_6:n oletusdesimaalimuodoksi ja Q16.16:n ajaksi. Julkinen sivu käsittelee Q31.32-, Q16.16- ja Dec64_6-profiileja, ja MPFR toimii vertailureittinä. Tämä antaa projektille selkeän sopimuksen: reaaliarvoinen simulointi tulisi kartoittaa deterministisiin numeerisiin profiileihin sen sijaan, että jokainen taustajärjestelmä saisi improvisoida.
There is an important honesty point here. FMI-facing APIs and compatibility surfaces may still accept or emit floating values because the standard and existing tools expect them. The claim that matters is not theatrical purity at every boundary. The claim that matters is that the core deterministic path is built around Numerus fixed-point profiles and validation against a high-precision reference where comparison is meaningful. Edge adapters can speak the outside language. The inside contract should notbecome a shrug.
Numeerinen profiili on mallipäätös
Kiinteäpisteinen esitys ei ole yksi maaginen asetus. Malli, joka tarvitsee tiiviitä aikasarvoja, malli laajoilla fysikaalisilla alueilla ja malli, joka raportoi desimaalimääriä, eivät koe samanlaista painetta. Q16.16, Q31.32 ja Dec64_6 eivät ole tarroja kalvolle. Ne ovat erilaisia sopimuksia alueesta, resoluutiosta, esitystavasta ja siitä, missä virheiden annetaan elää.
Tässä simulaatiotiimit usein käyvät liian huolimattomiksi. He kohtelevat numeerista käyttäytymistä työkalun ominaisuutena eivätkä mallin ominaisuutena. Sitten työkalu vaihtuu, taustajärjestelmä vaihtuu tai malli upotetaan, ja yhtäkkiä vanha oletus muuttuu validointitaakaksi. Dweve FMI tekee numeerisesta profiilista osan arkkitehtuuria eikä taustasäätä. Se on vähemmän näyttävää kuin iso demo. Hyvä. Isot demot harvoin kertovat, kuka omistaa pyöristysrajan.
Solver-crate kertoo saman tarinan. Se tarjoaa ODE-järjestelmäpiirteet, RK4:n, RKF45:n, Eulerin, BDF-suuntautuneen konfiguraation, adaptiivisen askelohjauksen, tapahtumantunnistuksen ja deterministisen solveriajan. Runtime-crate omistaa FMU:n elinkaaren, tapahtuma- ja jatkuva-aikaiset tilat, muuttujakäytön, syötedervaatat, suunta- ja adjungaattiderivaatat, Jacobian välimuistituksen, kellot ja tilan serialisoinnin. Mikään tästä ei ole hyödyllistä, jos numeeriseen kerrokseen ei voi luottaa, kun se liikkuu laitteistojen välillä. Solver voi olla älykäs. Malli voi olla elegantti. Jos sama ajo vaatii kolme täsmäytystä, eleganssi on enimmäkseen sisustusta.
Yhteissimulaatiossa pienistä valheista tulee kalliita
Yksi FMU on jo tarpeeksi työtä. Useat toisiinsa kytketyt FMU:t ovat paikka, jossa numeerisista ja toiminnallisista virheistä tulee sosiaalisia. Lämpömalli syöttää ohjausmallia, ohjausmalli syöttää toimilaitemallia, toimilaitemalli syöttää mekaanista mallia, ja kaikki toivovat, ettei askeljärjestys hiljaa tuota hölynpölyä. Yhteissimulaatio tarvitsee yhteyksien hallintaa, suoritusjärjestyksen, datanvaihdon, askelten koordinoinnin, algebrallisten silmukoiden käsittelyn ja tavan sanoa ei, kun graafi on väärä.
Lähdekoodissa on fmi-orchestration tätä työtä varten. Se hoitaa usean FMU:n yhteissimulaation, yhteydet, syklintunnistuksen, topologisen järjestyksen, osioiden ajoituksen, algebrallisten silmukoiden tunnistuksen ja ratkaisun, arvohistorian, suoritusjärjestyksen, simulaatioajan ja orkestrointitilastot. fmi-cc on tarkoitettu kytkettyjen FMU:iden väliseen viestintään ja fmi-dist hajautettuun suoritukseen koordinaattoreiden, solmurekisteröinnin, viestien, askelpyyntöjen, askelvastausten ja tilaarvojen kanssa. Tällaista koneistoa ihmiset unohtavat, kun he sanovat integraation olevan vain tulojen kytkemistä lähtöihin. Se on kytkemistä, kyllä. Se on myös ajoitusta, riippuvuuksien hallintaa, tilaa, vikaantumista ja todistetta siitä, että kytkennät tekivät sen, mitä ne sanoivat.
Yhteissimulointi myös korostaa determinismin merkitystä, ei vähennä sitä. Jos yksi FMU poikkeaa hieman ja tämä arvo syötetään toiseen FMU:hun, ero voi levitä. Jos suoritusjärjestys muuttuu solmujen välillä, ero voi piiloutua myöhempään vaiheeseen. Jos yksi taustaosa käyttää hieman erilaista matematiikan polkua, ero voi näyttää mallin käyttäytymiseltä. Näin tiimit päätyvät debuggaamaan fysiikkaa kokouspöytäkirjojen avulla. Kenenkään ei pitäisi joutua tekemään niin, ellei hän ole ollut hyvin tuhma edellisessä elämässä.
Taustaosat ovat käyttöönottovalintoja, eivät uusia totuuksia
Lähdepuu erottaa suorituskohteet taustaosa-krateiksi: CPU, GPU, FPGA, edge ja hajautettu. Edge-taustaosa keskittyy rajoitettuihin laitteisiin, rajattuun muistiin ja pieneen ylikuormaan. FPGA-taustaosa käsittelee kiinteän pilkun aritmetiikkaa, DMA-siirtoja, bittivirran hallintaa, ytimen suoritusta ja laitteisto-silmukkaa. Hajautettu krate koordinoi useita solmuja. Julkinen sivu kuvaa CPU SIMD-, GPU-, FPGA-, edge- ja hajautetut polut. Tämä ei tarkoita, että jokainen kohde olisi yhtä kypsä jokaiseen työkuormaan. Se tarkoittaa, että arkkitehtuuri kohtelee taustaosan valintaa ensiluokkaisena asiana.
Keskeinen suunnitteluperiaate on, että käyttöönoton tulisi muuttaa sitä, missä simulointi suoritetaan, ei sitä, mitä simulointi tarkoittaa. CPU-polku voi olla helpoin kirjoittamiseen ja varmennukseen. GPU-polku voi olla järkevä suurille rinnakkaisille työkuormille. FPGA-polku voi olla tarpeen reaaliaikaiseen tai laitteisto-silmukkaan. Edge-polku voi olla tarpeen lähellä konetta. Hajautettu suoritus voi olla tarpeen suurille kytketyille järjestelmille. Nämä ovat toiminnallisia valintoja. Niiden ei pitäisi luoda mallille uutta numeerista identiteettiä.
Tässä myös avoimen lähdekoodin merkitys korostuu. Turvallisuudessa, energiassa, robotiikassa, lääkinnällisissä laitteissa, autoteollisuudessa, ilmailussa, teollisessa ohjauksessa ja digitaalisissa kaksosissa toistettavuusväitteet eivät voi elää vain myyjän dioissa. Jonkun on tarkastettava toteutus, lukittava versio, ajettava testit, luettava virhetapaukset ja päätettävä, onko näyttö riittävää. Avoimen lähdekoodin FMI-toteutus antaa tiimeille paremman reitin tähän näyttöön. Se ei taianomaisesti sertifioi mitään. Se tekee työstä tarkastettavaa, mikä on ensimmäinen hyödyllinen askel.
Validointi on portti, ei kojelauta
Dweve FMI:n validointitarina ei ole vain kauniista jäljistä. README ja sivusto kuvaavat MPFR-vertailutarkistuksia, taustaosien välistä vastaavuutta, determinististä toistoa, yhdenmukaisuustestejä, fuzzaus- ja tyypitettyjä virheitä. Lähdekoodissa on fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, ominaisuustestejä, fuzz-valjaita ja tilan serialisointia. Tämä on oikea suunta. Simulointi-infrastruktuurissa validoinnin ei pitäisi olla kojelauta, jossa punainen viiva näyttää huolestuttavalta ja joku lupaa seurata sitä. Sen pitäisi olla portti.
Portti koostuu useista osista. Tuonnin on jäsennettävä FMU-arkisto ja modelDescription oikein. Skeemavalidoinnin on hylättävä virheelliset muuttujamääritelmät, riippuvuudet, kellot ja attribuutit. Numeeriset tarkistukset tarvitsevat oraakkelin, kun väite on tarkkuus. Taustaosien yhdenmukaisuus tarvitsee saman tilan kaikissa suorituskohteissa. Toisto tarvitsee tallennetun tilan ja tapahtumalokit suorituksen uudelleenrakentamiseen. Virheet tarvitsevat tyypitettyjä virheitä, ei salaperäistä epäsuhtaraporttia, joka lähettää tiimin kaivamaan lokitiedostoja. Epäsuhdan tulisi estää julkaisupolku, kunnes se on ymmärretty tai nimenomaisesti hyväksytty. Se kuulostaa ankaralta vain, jos vaihtoehto ei ole vielä laskuttanut sinua.
Missä tämä näkyy ensimmäisenä
Ilmeisimmät alueet ovat ne, joissa simulaatiovirheistä tulee fyysisiä virheitä: autoteollisuus, ilmailu, teollisuusautomaatio, lääkintälaitteet, energia, robotiikka ja infrastruktuuri. Jarrujärjestelmän malli, pumpun ohjain, verkkomalli, robottisolu, tuotantolinja tai HVAC-ohjain ei muutu turvallisemmaksi siksi, että kalvossa lukee digitaalinen kaksonen. Se muuttuu turvallisemmaksi, kun malli, syötteet, numeerinen profiili, backend, versio ja toistopolku ovat riittävän hallittuja tutkittaviksi.
Mukana on myös hankintanäkökulma, koska tietysti on. Jos jokainen backend vaatii oman validointitarinansa, jokainen laitteistomuutos muuttuu pieneksi uudelleensertifiointiharjoitukseksi. Jos sama FMU voidaan todistaa kerran ja sitten ajaa sillä kohdealustalla, joka sopii käyttörajoitteisiin, tiimit saavat vapautta teeskentelemättä, että validointi on ilmaista. Sivusto ilmaisee tämän niin, että todistetaan kerran ja ajetaan missä tahansa. Tekninen käännös on hieman vähemmän romanttinen: vähennetään niiden paikkojen määrää, joissa sama malli voi olla eri mieltä itsensä kanssa.
Tämä on erityisen olennaista Euroopassa. Suvereniteetti ei ole vain sitä, missä palvelin sijaitsee. Se on myös sitä, voidaanko turvallisuusperustelua tarkastaa, toistaa ja siirtää ilman, että täytyy anella lupaa yhdeltä toimittajalta. Avoin toteutus, deterministinen aritmetiikka, toistettava toisto ja backendien yhdenmukaisuus eivät yksinään ratkaise politiikkaa. Ne tekevät teknisestä osasta vähemmän riippuvaisen mustasta laatikosta, johon on liitetty myyntitiimi.
Mitä tarkistaa ennen kuin luottaa
Ensimmäinen tarkistuskysymys on, mitä FMI 3.0 -pintoja mallisi todella käyttää. Model Exchange, Co-Simulation, Scheduled Execution, kellot, derivaatat, tapahtumat, binäärimuuttujat, merkkijonot, taulukot ja riippuvuudet eivät ole sama kuormitus. Yksinkertainen FMU ja kytketty monen FMU:n simulaatio kohdistavat erilaista painetta ajonaikaiseen ympäristöön ja orkestraattoriin.
Toinen kysymys on, minkä numeerisen profiilin malli ilmoittaa ja miksi. Jos vastaus on mikä tahansa oletusarvo, joka toimi esimerkissä, se ei ole suunnitelma. Profiilin tulisi vastata aluetta, resoluutiota, ajan esitystapaa, toleranssia ja käyttökohdetta. Sen tulisi olla riittävän näkyvä, jotta tarkastaja voi haastaa sen lukematta koko ratkaisijaa.
Kolmas kysymys on, mikä näyttö kulkee tuloksen mukana. Mikä lähdeversio? Mikä FMU-versio? Mikä modelDescription? Mikä Numerus-profiili? Mikä backend? Mitkä oraakkelitarkistukset? Mikä toistotila? Mitkä yhdenmukaisuus- tai ominaisuustestit? Jos vastaukset ovat hajallaan wikissä ja jonkun muistissa, simulaatio ei ole vielä valmis luotettavaksi vakavassa työnkulussa.
Opetus
Dweve FMI:n opetus ei ole se, että simulaatiostandardit ovat tylsiä. Ne ovat tylsiä täsmälleen samalla tavalla kuin sillat ovat tylsiä, kun ne pysyvät pystyssä. FMI antaa vaihdon kehyksen. Numerus-pohjainen kiinteäpiste antaa deterministisen aritmetiikan asennon. Ajoympäristön ja ratkaisijan kirjastot saavat mallin etenemään. Orkestrointi yhdistää FMU:t teeskentelemättä, että ajoitus on triviaalia. Backendit siirtävät suorituksen laitteistolle, joka sopii tehtävään. Validointi muuttaa samankaltaisuuden portiksi toivon sijaan.
Sitä työ on. Ei suurta väitettä siitä, että luvut on ratkaistu ikuisesti. Ei kiiltävää demoa, jossa kaikki täsmää, koska vain yhtä polkua on testattu. Simulaatiojärjestelmä, joka tuntee formaattinsa, ilmoittaa numeerisen sopimuksensa, toimii eri backendien yli ja epäonnistuu äänekkäästi, kun sama malli lakkaa olemasta sama malli.
Malliin ei pitäisi kehittyä persoonallisuutta. Niitä riittää kokouksissa.