FMI e la stessa simulazione ovunque
Il modello non deve sviluppare una personalità
Un modello di simulazione dovrebbe essere noioso in un modo molto specifico: stesso input, stesso modello, stesso output. Sembra ovvio finché il modello non passa da una workstation a un cluster, da un laptop a un hardware-in-the-loop, da un compilatore a un altro, o da uno strumento del fornitore a un ufficio di sicurezza che non apprezza la danza interpretativa. Poi piccole differenze numeriche diventano riunioni. Le riunioni diventano fogli di calcolo di riconciliazione. I fogli di calcolo di riconciliazione diventano il cimitero dove muoiono i buoni pomeriggi di ingegneria.
FMI esiste per rendere pratico lo scambio di modelli e la co-simulazione tra strumenti. La Functional Mock-up Interface offre ai team un modo standard per impacchettare ed eseguire modelli invece di trasportare a mano codice di integrazione fragile da un ambiente di simulazione all'altro. Questo è già utile. Ma un'interfaccia standard non rende automaticamente deterministica l'aritmetica. I flussi di lavoro FMI tradizionali spesso si basano sul comportamento in virgola mobile IEEE 754, sulle librerie di piattaforma, sulle scelte del compilatore, sull'ordine di esecuzione e sulle differenze di backend. La maggior parte delle volte va bene. Poi non va più bene, e la differenza viene di solito scoperta da qualcuno con una scadenza e un'espressione che dice che l'approvvigionamento aveva promesso che sarebbe stato facile.
Dweve FMI attacca la parte noiosa e costosa: la riproducibilità. Il sito descrive un'implementazione FMI in Rust per Model Exchange e Co-Simulation con aritmetica deterministica a virgola fissa, costruita su Numerus. La forma dell'implementazione è più ampia di una demo: uno spazio di lavoro FMI multi-crate con rappresentazione del modello, parsing dello schema, importazione, esportazione, runtime, solver, orchestrazione, memoria, backend per CPU, GPU, FPGA, edge ed esecuzione distribuita, FFI, fuzzing, benchmark, documentazione e test. Dipende dai crate Numerus per l'aritmetica a virgola fissa e decimale, oltre allo stack comune Dweve per simulazione, logging, gestione dei guasti, trasporto, tensori e archiviazione.
L'obiettivo non è rendere la simulazione mistica. L'obiettivo è far sì che lo stesso FMU smetta di raccontare storie leggermente diverse perché si è svegliato su una macchina diversa.
FMI fornisce la busta, l'aritmetica scrive ancora l'assegno
Un FMU è una busta utile. Contiene una descrizione del modello, binari o artefatti sorgente, risorse, variabili, stati, clock, dipendenze e metadati sufficienti affinché un altro strumento possa istanziare e fare avanzare il modello. FMI 3.0 aggiunge clock più ricchi, esecuzione schedulata, tipizzazione delle variabili migliorata e meccanismi di co-simulazione. Il sorgente di Dweve FMI è organizzato attorno a quella busta: fmi-schema analizza e valida le descrizioni dei modelli, fmi-import carica gli archivi FMU, fmi-export costruisce archivi, fmi-model rappresenta variabili e stato del modello, e fmi-runtime gestisce il ciclo di vita, l'accesso alle variabili, i clock, gli eventi, le derivate e il salvataggio o ripristino dello stato.
Quella busta è necessaria, ma non è sufficiente. L'aritmetica sottostante decide ancora se un'esecuzione è riproducibile. La documentazione del runtime dice che l'aritmetica a virgola fissa usa Numerus Q31_32 per il calcolo deterministico. I metadati dello spazio di lavoro nominano Q31.32 come formato fisso predefinito, Dec64_6 come formato decimale predefinito e Q16.16 per il tempo. La pagina pubblica parla dei profili Q31.32, Q16.16 e Dec64_6, con MPFR usato come percorso di riferimento. Questo dà al progetto un contratto chiaro: la simulazione a valori reali dovrebbe essere mappata in profili numerici deterministici invece di lasciare che ogni backend improvvisi.
Qui c'è un punto di onestà importante. Le API rivolte a FMI e le superfici di compatibilità possono ancora accettare o emettere valori in virgola mobile perché lo standard e gli strumenti esistenti li richiedono. Ciò che conta non è una purezza teatrale a ogni confine. Ciò che conta è che il percorso deterministico centrale sia costruito attorno ai profili a virgola fissa Numerus e alla validazione rispetto a un riferimento ad alta precisione dove il confronto ha senso. Gli adattatori periferici possono parlare il linguaggio esterno. Il contratto interno non dovrebbe diventare un'alzata di spalle.
Il profilo numerico è una decisione di modello
La virgola fissa non è un'unica impostazione magica. Un modello che necessita di valori temporali compatti, un modello con ampi intervalli fisici e un modello che riporta quantità decimali non hanno la stessa pressione. Q16.16, Q31.32 e Dec64_6 non sono adesivi per una diapositiva. Sono contratti diversi su intervallo, risoluzione, rappresentazione e su dove gli errori possono risiedere.
È qui che i team di simulazione spesso diventano troppo superficiali. Trattano il comportamento numerico come una proprietà dello strumento piuttosto che come una proprietà del modello. Poi lo strumento cambia, o il backend cambia, o il modello viene incorporato, e improvvisamente la vecchia ipotesi diventa un onere di validazione. Dweve FMI rende il profilo numerico parte dell'architettura anziché un dato di sfondo. È meno affascinante di una grande demo. Bene. Le grandi demo raramente spiegano chi possiede il confine dell'arrotondamento.
La crate del solver racconta la stessa storia. Espone i tratti del sistema ODE, RK4, RKF45, Eulero, configurazione orientata a BDF, controllo adattivo del passo, rilevamento di eventi e tempo di solver deterministico. La crate di runtime possiede il ciclo di vita dell'FMU, le modalità a eventi e a tempo continuo, l'accesso alle variabili, le derivate di ingresso, le derivate direzionali e aggiunte, la cache Jacobiana, gli orologi e la serializzazione dello stato. Nulla di tutto ciò è utile se il livello numerico non può essere considerato affidabile quando si sposta tra hardware diversi. Il solver può essere intelligente. Il modello può essere elegante. Se la stessa esecuzione richiede tre riconciliazioni, l'eleganza è per lo più arredamento.
La co-simulazione è dove le piccole bugie diventano costose
Un singolo FMU è già abbastanza lavoro. Diversi FMU accoppiati insieme sono dove gli errori numerici e operativi diventano sociali. Un modello termico alimenta un modello di controllo, il modello di controllo alimenta un modello di attuatore, il modello di attuatore alimenta un modello meccanico, e tutti sperano che l'ordine dei passi non stia silenziosamente creando assurdità. La co-simulazione richiede gestione delle connessioni, ordine di esecuzione, scambio di dati, coordinamento dei passi, gestione dei loop algebrici e un modo per dire di no quando il grafo è sbagliato.
La sorgente ha fmi-orchestration per quel lavoro. Gestisce la co-simulazione multi-FMU, le connessioni, il rilevamento dei cicli, l'ordinamento topologico, la pianificazione delle partizioni, il rilevamento e la risoluzione dei loop algebrici, la cronologia dei valori, l'ordine di esecuzione, il tempo di simulazione e le statistiche di orchestrazione. C'è fmi-cc per la comunicazione tra FMU accoppiati e fmi-dist per l'esecuzione distribuita con coordinatori, registrazione dei nodi, messaggi, richieste di passo, risposte di passo e valori di stato. Questo è il tipo di meccanismo che la gente dimentica quando dice che l'integrazione è solo collegare le uscite agli ingressi. È collegamento, sì. È anche temporizzazione, gestione delle dipendenze, stato, guasto e prova che il collegamento ha fatto ciò che diceva.
La co-simulazione rende la determinismo più importante, non meno. Se un FMU devia leggermente e quel valore alimenta un altro FMU, il disaccordo può propagarsi. Se l'ordine di esecuzione cambia tra i nodi, il disaccordo può nascondersi fino a un passo successivo. Se un backend usa un percorso matematico leggermente diverso, il disaccordo può sembrare un comportamento del modello. È così che i team finiscono per fare debug della fisica con i verbali delle riunioni. Nessuno dovrebbe doverlo fare, a meno che non sia stato molto cattivo in una vita precedente.
I backend sono scelte di distribuzione, non nuove verità
L'albero sorgente separa i target di esecuzione in crate backend: CPU, GPU, FPGA, edge e distribuito. Il backend edge si concentra su dispositivi con risorse limitate, memoria vincolata e basso overhead. Il backend FPGA parla di aritmetica a virgola fissa, trasferimenti DMA, gestione del bitstream, esecuzione del kernel e hardware-in-the-loop. Il crate distribuito coordina più nodi. La pagina pubblica descrive i percorsi CPU SIMD, GPU, FPGA, edge e distribuito. Questo non significa che ogni target sia ugualmente maturo per ogni carico di lavoro. Significa che l'architettura tratta la scelta del backend come una preoccupazione di prima classe.
Il principio di progettazione cruciale è che la distribuzione dovrebbe cambiare dove viene eseguita la simulazione, non cosa significa la simulazione. Un percorso CPU può essere il più semplice per l'autorizzazione e la verifica. Un percorso GPU può avere senso per carichi di lavoro paralleli di grandi dimensioni. Un percorso FPGA può essere necessario per il real-time o hardware-in-the-loop. Un percorso edge può essere necessario vicino alla macchina. L'esecuzione distribuita può essere necessaria per grandi sistemi accoppiati. Queste sono scelte operative. Non dovrebbero creare una nuova identità numerica per il modello.
Questo è anche il punto in cui l'open source conta. In sicurezza, energia, robotica, dispositivi medici, automotive, aerospaziale, controllo industriale e gemelli digitali, le affermazioni di riproducibilità non possono vivere solo nelle slide dei fornitori. Qualcuno deve ispezionare l'implementazione, fissare una versione, eseguire i test, leggere i casi di errore e decidere se le prove sono sufficienti. Un'implementazione FMI open source offre ai team una strada migliore verso queste prove. Non certifica magicamente nulla. Rende il lavoro ispezionabile, che è il primo passo utile.
La validazione dovrebbe essere un cancello, non una dashboard
La storia della validazione di Dweve FMI non riguarda solo tracce carine. Il README e il sito descrivono controlli di riferimento MPFR, equivalenza tra backend, replay deterministico, test di conformità, fuzzing ed errori tipizzati. Il sorgente ha fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, test di proprietà, harness di fuzzing e serializzazione dello stato. Questa è la direzione corretta. Nell'infrastruttura di simulazione, la validazione non dovrebbe essere una dashboard in cui una linea rossa sembra preoccupante e qualcuno promette di tenerla d'occhio. Dovrebbe essere un cancello.
Il cancello ha diverse parti. L'importazione deve analizzare correttamente l'archivio FMU e modelDescription. La validazione dello schema deve rifiutare definizioni di variabili, dipendenze, clock e attributi non validi. I controlli numerici necessitano di un oracolo quando l'affermazione è l'accuratezza. La parità dei backend richiede lo stesso stato su tutti i target di esecuzione. Il replay richiede stato salvato e log degli eventi per ricostruire l'esecuzione. Gli errori richiedono errori tipizzati, non un misterioso rapporto di mancata corrispondenza che manda il team a frugare nei log. Una mancata corrispondenza dovrebbe bloccare un percorso di rilascio finché non viene compresa o esplicitamente accettata. Sembra duro solo se l'alternativa non ti ha ancora mandato la fattura.
Dove conta per prima
I domini ovvi sono quelli in cui un errore di simulazione diventa un errore fisico: automotive, aerospaziale, controllo industriale, dispositivi medici, energia, robotica e infrastrutture. Un modello di freno, un controllore di pompa, un modello di rete elettrica, una cella robotica, una linea di produzione o un controllore HVAC non diventano più sicuri perché una slide dice digital twin. Diventano più sicuri quando modello, ingressi, profilo numerico, backend, versione e traccia di riproduzione sono abbastanza controllati da poter essere indagati.
C’è anche un aspetto di procurement, perché ovviamente c’è. Se ogni backend richiede una storia di validazione separata, ogni cambio hardware diventa una piccola ri-certificazione. Se lo stesso FMU può essere dimostrato una volta e poi eseguito sul target che soddisfa il vincolo operativo, i team guadagnano libertà senza fingere che la validazione sia gratuita. Il sito lo esprime come dimostrare una volta ed eseguire ovunque. La traduzione ingegneristica è leggermente meno romantica: ridurre i punti in cui lo stesso modello può essere in disaccordo con sé stesso.
Questo è particolarmente rilevante in Europa. La sovranità non è solo dove si trova il server. È anche se un safety case può essere ispezionato, ripetuto e spostato senza dover chiedere il permesso a un fornitore. Un’implementazione aperta, aritmetica deterministica, riproduzione ripetibile e parità dei backend non risolvono da sole le questioni politiche. Rendono però la parte tecnica meno dipendente da una scatola nera con un team di vendita attaccato.
Cosa rivedere prima di fidarsi
La prima domanda di revisione è quali superfici FMI 3.0 usa davvero il tuo modello. Model Exchange, Co-Simulation, Scheduled Execution, clock, derivate, eventi, variabili binarie, stringhe, array e dipendenze non sono lo stesso carico di lavoro. Un FMU semplice e una simulazione accoppiata multi-FMU mettono pressioni diverse su runtime e orchestratore.
La seconda domanda è quale profilo numerico dichiara il modello e perché. Se la risposta è qualunque default funzionasse nell’esempio, quella non è una progettazione. Il profilo deve corrispondere a intervallo, risoluzione, rappresentazione del tempo, tolleranza e target di deployment. Deve essere abbastanza visibile che un revisore possa contestarlo senza leggere l’intero solver.
La terza domanda è quali evidenze viaggiano con un risultato. Quale versione della sorgente? Quale versione dell’FMU? Quale modelDescription? Quale profilo Numerus? Quale backend? Quali controlli oracolo? Quale stato di riproduzione? Quali test di conformità o di proprietà? Se queste risposte sono sparse in una wiki e nella memoria di qualcuno, la simulazione non è ancora pronta per essere considerata affidabile in un flusso di lavoro serio.
La lezione
La lezione di Dweve FMI non è che gli standard di simulazione sono noiosi. Sono noiosi esattamente nel modo in cui i ponti sono noiosi quando restano in piedi. FMI dà l’involucro di scambio. Il fixed-point supportato da Numerus dà la postura aritmetica deterministica. Le crate di runtime e solver fanno avanzare il modello. L’orchestrazione collega gli FMU senza fingere che il timing sia banale. I backend spostano l’esecuzione sull’hardware adatto al compito. La validazione trasforma l’uguaglianza in un gate invece che in una speranza.
Questo è il lavoro. Non una grande affermazione che i numeri sono risolti per sempre. Non una demo scintillante dove tutto corrisponde perché è stato testato solo un percorso. Un sistema di simulazione che conosce i propri formati, dichiara il proprio contratto numerico, gira su più backend e fallisce rumorosamente quando lo stesso modello smette di essere lo stesso modello.
Il modello non dovrebbe sviluppare una personalità. Ne abbiamo abbastanza di quelle nelle riunioni.