Co-simulazioni

Co-simulazione Dymola-Abaqus
Co-simulazione Dymola-Abaqus

Interfacciamento Dymola e SIMULIA
È possibile interfacciare Dymola e gli strumenti SIMULIA Abaqus, iSight e FIPER.
L’interfaccia può servire ad effettuare per esempio una co-simulazione. L’immagine mostra l’animazione di un modello di yacht in sella ad un moto ondoso, le cui superfici di controllo sono state modellate in Dymola.
Un esempio di co-simulazione Dymola Abaqus di un sistema frenante anti-bloccaggio ad alta fedeltà è presentato in questo documento e fa parte della Conferenza Modelica 2009: Interfacciare Dymola con Abaqus

La Functional Mock-up Interface (FMI)

L’FMI (Functional Mock-up Interface) definisce un’interfaccia che lavora con file eseguibili chiamati FMU (Unità Funzionale Mock-up). Le funzioni FMI vengono utilizzate (chiamate) da un simulatore per creare una o più istanze dell’ FMU, chiamate modelli, e di eseguire questi modelli, in genere insieme ad altri modelli. Una FMU può comprendere i propri integratori (co-simulazione) o richiedere al simulatore di eseguire l’integrazione numerica.
L’FMI è nata per fare sì che un ambiente di modellazione come Dymola in grado di generare codice C di un modello di un sistema dinamico potesse essere facilmente interfacciato ed utilizzato all’interno o insieme ad altri modelli e ambienti di simulazione. I modelli sono descritti da equazioni differenziali, algebriche e discrete che comprendono tempo, stati ed eventi. I modelli, per essere trattati con questa interfaccia, possono essere o particolarmente complessi per un utilizzo in simulazioni offline o online oppure ottimizzati per un utilizzo in sistemi di controllo embedded su micro-processori. È possibile utilizzare diverse istanze di un modello e collegare i modelli gerarchicamente. Il modello esportato è indipendente dal simulatore di destinazione.

Interfaccia del Modello:

Tutte le equazioni necessarie sono vengono risolte chiamando funzioni “C” standard. Il linguaggio “C” viene utilizzato perché è il linguaggio di programmazione più esportabile oggi ed è l’unico linguaggio di programmazione che può essere utilizzato in tutti i sistemi di controllo embedded.

Flusso dati nella FMI
Flusso dati nella FMI

Descrizione dello schema del Modello:

Lo schema definisce la struttura e il contenuto di un file XML generato da un ambiente di modellazione. Questo file XML contiene la definizione di tutte le variabili nel modello in modo standardizzato. È quindi possibile eseguire il codice C in un sistema embedded senza il sovraccarico della definizione delle variabili (l’alternativa potrebbe essere quella di memorizzare queste informazioni nel codice C e accedervi tramite chiamate di funzione, ma questo non è pratico per sistemi embedded e non per modelli di grandi dimensioni). Inoltre, la definizione delle variabili è una struttura dati complessa e gli strumenti devono essere liberi di rappresentare questa struttura dati nei loro programmi. L’approccio scelto permette a ciascun tool di archiviare e accedere alle definizioni di variabili (senza fare alcun uso di memoria o calcolo da parte di funzioni standard di accesso), nel linguaggio di programmazione dell’ambiente di simulazione, di solito C + +, C # o Java. Esistono molte librerie open source e commerciali in diversi linguaggi di programmazione per poter leggere file XML in una struttura dati appropriata. SI veda, per esempio.

Un modello è distribuito in un unico file zip che include diversi file:
(1) Un file XML contenente la definizione di tutte le variabili e le altre informazioni del modello.
(2) I sorgenti C del modello (comprese le librerie runtime necessarie utilizzate nel modello) e / o librerie a collegamento dinamico (DLL) per uno o più target diversi. Questa soluzione è particolarmente usata nel caso in cui il provider del modello voglia nascondere il codice sorgente per mantenerne il know-how. Un modello può contenere parametri fisici o dimensioni geometriche.
(3) Ulteriori dati possono essere inclusi nel file zip, come un’icona del modello (file bitmap), alcuni file di documentazione, mappe e tabelle necessarie al modello, e tutte le librerie di oggetti o DLL che vengono utilizzate.