Co-simulazioneMetodi di ingegneria

Co-simulazione FMI

Importare e co-simulare modelli di terze parti tramite lo standard FMI — carica un FMU Dymola ed eseguilo, validalo incrociato rispetto a un modello nativo, avvolgi il tuo controllore intorno alla scatola nera attraverso l’interfaccia FMI, accoppialo in un sistema più grande, e quantifica l’errore di co-simulazione.

DjiniousLabModellazione e simulazione

Un controllore PID nativo che insegue un setpoint su un impianto FMU di terze parti importato, attraverso l’interfaccia FMI

errore di inseguimento ad anello chiuso su un FMU di terze parti: 2,9e-4 merrore di inseguimento ad anello chiuso su un FMU di terze parti
accordo CS vs ME (RMSE): 1,3e-3 maccordo CS vs ME (RMSE)
fedeltà FMU vs nativo (RMSE): 4,7e-3 mfedeltà FMU vs nativo (RMSE)
riduzione dell’errore di co-simulazione tramite affinamento del macro-step: 7.6×riduzione dell’errore di co-simulazione tramite affinamento del macro-step
notebook di progettazione: 10notebook di progettazione
requisiti PASS: 5 / 5requisiti PASS

Esegui — e controlla — un modello che non hai costruito tu.

Nessun team modella tutto in un unico strumento. Lo standard FMI esiste perché un modello costruito in Dymola, Simulink o altrove possa essere impacchettato come FMU ed eseguito altrove del tutto. Questo programma è il lato dell’importazione di quella promessa: carica un FMU di terze parti nel worker Julia di DjiniousLab, co-simulalo, validalo incrociato rispetto a una reimplementazione nativa, e — la parte che conta — avvolgi il tuo controllore intorno alla scatola nera e chiudi l’anello attraverso l’interfaccia FMI. L’interoperabilità non è una casella da spuntare; è controllare il modello di qualcun altro come se fosse il tuo.

Inserisci un FMU di terze parti e funziona e basta.

Un FMU è un modello autonomo e compilato dietro un’interfaccia C standard. Il primo notebook carica un FMU di riferimento esportato da Dymola nel worker Julia e lo co-simula — stati in uscita, orbita di fase chiusa, nessun codice sorgente, nessuna ridefinizione. Questa è l’affermazione base di interoperabilità: un modello creato in un altro strumento, eseguito qui, invariato.

Gli stati di un FMU di terze parti co-simulati dopo essere stati importati nel worker Julia — Il momento dell’importazione: un FMU esportato da Dymola caricato e co-simulato nel worker — i suoi stati escono direttamente dal modello compilato attraverso l’interfaccia FMI. Stai eseguendo un modello che non hai scritto e di cui non puoi vedere l’interno.

Co-simulazione o model-exchange — e coincidono.

FMI offre due modalità. In co-simulazione l’FMU porta con sé il proprio solver e tu chiami doStep; in model-exchange è il tuo solver a integrare le derivate dell’FMU. Lo stesso FMU eseguito in entrambi i modi si sovrappone con un RMSE di 1,3×10⁻³ m — la scelta riguarda chi possiede il solver, non l’ottenere risposte diverse. Quell’equivalenza è ciò che ti permette di inserire un FMU in un sistema più grande risolto da Julia con fiducia.

Lo stesso FMU eseguito in modalità co-simulazione e model-exchange, quasi perfettamente sovrapposto — Co-simulazione (solver proprio dell’FMU) vs model-exchange (il solver del worker che integra l’FMU): lo stesso FMU, due modalità di integrazione, sovrapposte entro 1,3×10⁻³ m. La modalità è una decisione su chi possiede il solver, non una decisione di fedeltà.

Un FMU importato e una reimplementazione nativa Julia della stessa fisica, perfettamente sovrapposte — Validazione incrociata: una ODE Julia nativa costruita a partire dagli stessi parametri dell’FMU, sovrapposta all’FMU importato — coincidono entro 4,7×10⁻³ m. (Disallineando deliberatamente un parametro divergono, il controllo negativo.) Una fedeltà di interoperabilità che puoi misurare, non solo assumere.

Chiudi un anello intorno alla scatola nera.

L’affermazione di interoperabilità più forte non è eseguire un modello di terze parti — è controllarlo. Il notebook protagonista rende l’FMU importato l’impianto e vi avvolge intorno un PID Julia nativo tramite un anello di co-simulazione manuale: leggi l’uscita dell’FMU, calcola il controllo, imposta l’ingresso dell’FMU, avanza di un passo. Il controllore non vede mai l’interno dell’FMU; gli parla solo attraverso l’interfaccia FMI — e lo porta a un setpoint con un errore di inseguimento di 2,9×10⁻⁴ m. Un controllore e un impianto di terze parti da due mondi diversi, che si incontrano sullo standard.

Un PID nativo che porta un FMU di terze parti importato verso un setpoint, con la forza di controllo mostrata — Il protagonista: un PID Julia nativo che controlla un FMU di terze parti a scatola nera attraverso l’interfaccia FMI (in alto — l’uscita che insegue il setpoint; in basso — la forza di controllo calcolata). L’impianto è il modello compilato di qualcun altro; il controllore è il tuo; l’interfaccia FMI è il contratto tra i due.

La co-simulazione ha un proprio budget di errore.

Accoppiare modelli in punti di comunicazione discreti introduce un errore tutto suo: tra un passo e l’altro, ogni modello vede i propri ingressi mantenuti costanti, quindi un macro-step troppo grande ritarda e distorce. Il programma lo quantifica — dimezzare il macro-step dimezza circa l’errore (convergenza del primo ordine), una riduzione di 7,6× nell’intera scansione. Sapere che l’errore è del primo ordine rispetto alla dimensione del passo è ciò che permette di scambiare accuratezza e velocità deliberatamente, e non per caso.

Un macro-step grossolano che ritarda rispetto al riferimento, mentre un macro-step fine lo insegue — convergenza del primo ordine della co-simulazione — Il budget di errore della co-simulazione: un macro-step grossolano (rosso) ritarda e distorce perché gli ingressi restano costanti tra i punti di comunicazione, mentre un passo fine (blu) insegue il riferimento. L’errore è del primo ordine rispetto al macro-step — dimezza il passo, dimezzi l’errore.

Ogni numero ridedotto in fase di collaudo finale.

Il notebook V&V reimporta l’FMU e ridefinisce ogni requisito da zero, stampando un quadro PASS/FAIL.

Risultato

Importazione e co-simulazione di un FMU di terze parti: 101 campioni
Accordo CS vs ME: RMSE 1,3e-3 m
Fedeltà FMU vs nativo: RMSE 4,7e-3 m
Errore di inseguimento ad anello chiuso: 2,9e-4 m
Errore di co-simulazione vs macro-step: riduzione di 7,6×

Requisito

Importazione e co-simulazione di un FMU di terze parti: R-01
Accordo CS vs ME: R-02
Fedeltà FMU vs nativo: R-03
Errore di inseguimento ad anello chiuso: R-04
Errore di co-simulazione vs macro-step: R-05

Il lato dell’importazione, su FMU di riferimento.

Il deliverable è composto da dieci notebook e dal dossier — i modelli arrivano come FMU compilati dietro l’interfaccia C FMI, non come componenti acausali di DjiniousLab, quindi non c’è alcun blocco personalizzato né canvas. Gli FMU sono riferimenti esportati da Dymola anziché modelli arbitrari di terze parti; la co-simulazione è a frequenza singola con estrapolazione a ingresso costante tra i punti di comunicazione e senza alcun solver di loop algebrico tra FMU accoppiati. E questa è specificamente la storia dell’importazione/co-simulazione — l’esportazione FMU è un percorso Rust separato nella piattaforma. Ciò che il programma dimostra è il nucleo dell’interoperabilità: caricare, co-simulare in entrambe le modalità, validare incrociato, controllare, accoppiare e quantificare l’errore di co-simulazione — ogni numero rieseguibile, il più forte dei quali un controllore nativo che chiude un anello intorno a un modello di terze parti di cui non può vedere l’interno.