Utilizzo dei processi aziendali per la co simulazione di modelli dinamici

UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Informatica
Utilizzo dei processi aziendali per la
co-simulazione di modelli dinamici
Tesi di Laurea Magistrale
Laureando:
Besian POGACE
Relatore:
Chiar.mo Prof. Alberto BARTOLI
Correlatore:
Ph.D. Carlos KAVKA
_____________________________________
ANNO ACCADEMICO 2015-2016

Indice
1 Introduzione 1
2 Simulazione con FMI 3
2.1 Introduzione a FMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 FMI for Model Exchange . . . . . . . . . . . . . . . . . . . . 4
2.1.2 FMI for Co-Simulation . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Struttura di un FMU . . . . . . . . . . . . . . . . . . . . . . 10
2.2 FMI 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 FMU Software Development Kit (SDK) . . . . . . . . . . . . 12
2.2.2 Struttura dei ﬁle sorgenti dei modelli . . . . . . . . . . . . . . 12
2.2.3 Esempi di modelli della SDK . . . . . . . . . . . . . . . . . . 16
2.3 Simulazione con Simulation X . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Creazione di pendulum.fmu . . . . . . . . . . . . . . . . . . . 18
2.3.2 Co-simulazione di bouncingBall.fmu e inc.fmu . . . . . . . . . 18
2.4 Problemi di co-simulazione . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Co-simulazioni di modelli con retroazione . . . . . . . . . . . 20
2.4.2 Co-simulazione di modelli senza retroazione . . . . . . . . . . 21
2.5 FMI 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 BPMN 26
3.1 Introduzione a BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Elementi di primo livello . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Elementi di secondo livello . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Utilizzo di BPMN 2.0 per la Co-simulazione 35
4.1 Analisi di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Diagramma BPMN di co-simulazione . . . . . . . . . . . . . . . . . . 36
4.3 Esecuzione con BPMN Engine . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Activiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Elementi BPMN di Activiti . . . . . . . . . . . . . . . . . . . 41
4.3.3 JavaFMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
i

5 Realizzazione del progetto 45
5.1 Simulazione di bouncingBall.fmu in Activiti . . . . . . . . . . . . . . 45
5.2 File di configurazione della simulazione . . . . . . . . . . . . . . . . . 51
5.3 Diagramma BPMN finale per la co-simulazione . . . . . . . . . . . . 52
5.4 SimulationServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Esecuzione e confronto con SimulationX . . . . . . . . . . . . . . . . 57
5.6 Interfaccia utente per la configurazione (MasterCreator) . . . . . . . 59
6 Conclusioni 63
6.1 Conclusioni personali dell’autore . . . . . . . . . . . . . . . . . . . . 64
A 68
ii

Elenco delle ﬁgure
2.1 Struttura interna di modello FMU . . . . . . . . . . . . . . . . . . . 11
2.2 Esempio di co-simulazione in SimulationX . . . . . . . . . . . . . . . 19
2.3 schema di descrizione in FMI 2.0 . . . . . . . . . . . . . . . . . . . . 24
3.1 Task del primo livello . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Sub-process espanso (sinistra) e incapsulato (destra) . . . . . . . . . 29
3.3 Gateway di primo livello . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Alcuni start event e end event di primo livello . . . . . . . . . . . . . 30
3.5 Data object e data store . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Eventi intermedi di secondo livello . . . . . . . . . . . . . . . . . . . 32
3.7 Categorie degli eventi intermedi . . . . . . . . . . . . . . . . . . . . . 32
3.8 L’event gateway di secondo livello . . . . . . . . . . . . . . . . . . . . 33
3.9 Task di secondo livello . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Diagramma BPMN di collaborazione tra processo Master e processi
Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Diagramma BPMN del processo Slave . . . . . . . . . . . . . . . . . 38
4.3 Espansione del sub-process Simulation . . . . . . . . . . . . . . . . . 38
5.1 Primo diagramma semplice di simulazione di bouncingBall.fmu visua-
lizzato in Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Seconda soluzione, con le fasi di simulazione, visualizzata in Eclipse . 46
5.3 Visualizzazione del processo slave per la terza soluzione in Eclipse . 49
5.4 Visualizzazione del sub-process Simulate in Eclipse . . . . . . . . . . 50
5.5 Visualizzazione dell’intero processo master ﬁnale in Eclipse . . . . . 53
5.6 (a) Simulazione con Activiti (b) Simulazione con SimulationX . . . . 58
5.7 Schermata iniziale di MasterCreator . . . . . . . . . . . . . . . . . . 59
5.8 Schermata di inserimento modello . . . . . . . . . . . . . . . . . . . 60
5.9 Schermata iniziale con modelli inseriti . . . . . . . . . . . . . . . . . 61
5.10 Schermata di inserimento dipendenza di input . . . . . . . . . . . . . 62
iii

Capitolo 1
Introduzione
Il progetto di tesi esposto nel presente elaborato ha avuto come obiettivo la defini-
zione di una metodologia per la creazione del processo master per la co-simulazione
di modelli dinamici. Tale metodologia è stata formalizzata utilizzando un linguaggio
standard per la modellazione di processi aziendali. Il progetto si è inserito nelle at-
tività di ricerca dell’azienda ESTECO S.p.A., che mi ha ospitato come tirocinante
e tesista. ESTECO infatti da anni studia come coniugare simulazioni di modelli
dinamici e workflow di processi aziendali.
L’interesse per le simulazioni di modelli è in continua crescita nell’ingegneria
moderna. L’aumento delle conoscenze e delle capacità computazionali ha permes-
so agli ingegneri di trattare un numero sempre maggiore di argomenti e problemi
sempre più complessi. Proprio la complessità, nonché altri fattori come i costi o
l’impraticabilità reale di vari esperimenti, hanno determinato un interesse crescente
nei confronti delle simulazioni in ambienti controllati e i relativi strumenti per la
loro realizzazione. Tuttavia l’esistenza di molteplici tipi di simulazioni, di modelli,
di strumenti e di ambiti di studio rappresenta un ostacolo all’integrazione finale di
risultati, la quale è determinante per renderli utili a livello pratico. Spesso questi
problemi sono risolti con metodi ad hoc, analizzando i casi specifici; tuttavia, la
soluzione definitiva al problema dell’integrazione consiste nel fornire agli strumenti
di simulazione degli standard ben definiti.
L’interfaccia FMI (Functional Mockup Interface) si sta affermando come uno
dei principali standard in grado di supportare la creazione e lo scambio di modelli
dinamici tra vari strumenti, nonché di eseguire simulazioni di tali modelli [1]. Per
questi motivi FMI è lo standard scelto per la prima parte del progetto di tesi dedicata
alle simulazioni di modelli dinamici. Si noti però che l’interfaccia non definisce delle
regole chiare nel processo di orchestrazione di vari modelli durante la simulazione.
Per quanto riguarda i workflow di processi aziendali, da anni l’attenzione del-
l’azienda ESTECO è rivolta all’utilizzo di standard per la loro costruzione, con
particolare attenzione a BPMN (Business Process Model and Notation). Da alcuni
studi e progetti svolti è emerso che questo standard possiede potenzialità di utiliz-
1

zo trasversali, che vanno oltre i processi aziendali e che possono essere sfruttate in
campo ingegneristico.
L’obiettivo finale dell’intero progetto consiste dunque nell’utilizzare lo standard
BPMN, per riuscire a coordinare simulazioni di modelli creati con l’interfaccia FMI.
Questo obiettivo presenta delle difficoltà, principalmente nel fatto che i due stan-
dard non sono stati sviluppati per essere utilizzati insieme, in quanto appartengono
ad ambiti molto diversi. Oltre a questo, entrambi gli standard sono relativamente
recenti (l’attuale versione per entrambi è la 2.0), sono utilizzati maggiormente in
ambito lavorativo dalle aziende e poco utilizzati in ambito accademico. Di conse-
guenza la ricerca di informazioni per lo studio dei due standard o di lavori che ne
fanno uso è molto limitata. Durante la realizzazione di questo progetto, nella fase
di ricerca bibliografica, non sono stati trovati materiali nella letteratura che abbiano
cercato di raggiungere un obiettivo simile a quello appena presentato.
In conclusione di questa introduzione si illustrano brevemente il contenuto dei
capitoli di cui si compone il presente elaborato. Il secondo e il terzo capitolo sono
incentrati, rispettivamente, sullo studio degli standard FMI e BPMN, e ne appro-
fondiscono in particolare le caratteristiche ritenute più importanti e utili in funzione
del progetto di tesi. Lo studio dello standard FMI comprende una fase realizzativa
di modelli basati su tale standard, di cui sono presentati alcuni esempi nel relativo
capitolo. Il capitolo 4 descrive in dettaglio la fase di analisi, studio e progettazione
per l’utilizzo contemporaneo e sinergico dei due standard al fine di raggiungere gli
obiettivi prefissati. Nel capitolo viene presentato in particolare lo schema concet-
tuale di simulazione modellato con BPMN, che rappresenta il punto di partenza
del progetto; vengono inoltre esaminate le diverse possibilità di esecuzione di tale
schema. Il quinto capitolo è interamente dedicato alla fase realizzativa del progetto.
In dettaglio, nel capitolo viene descritta la costruzione del diagramma eseguibile per
gestire l’orchestrazione, la costruzione di un servizio su cui il diagramma si appoggia
per la computazione dei modelli e la costruzione di un interfaccia utente per con-
figurare l’intera simulazione. Il sesto e ultimo capitolo presenta le conclusioni sul
lavoro svolto.
2

Capitolo 2
Simulazione con FMI
2.1 Introduzione a FMI
FMI (Functional Mock-Up Interface) è un’interfaccia standard progettata per la
modellizzazione e la simulazione di sistemi complessi, dove gli elementi individuali
possono appartenere a un insieme eterogeneo di discipline dell’ingegneria, potendo
anche questi essere stati sviluppati con degli strumenti indipendenti. L’obiettivo di
questa interfaccia è quello di riuscire a rappresentare interamente i modelli (fisici,
meccanici, elettrici, ecc.) usati per la simulazione tramite delle funzioni e strutture
dati predefinite, fornendo una maggiore facilità di interazione con gli strumenti di
simulazione dei modelli, nonché tra diversi modelli in una co-simulazione.
FMI è stato sviluppato inizialmente come parte del progetto europeo MODE-
LISAR [2], iniziato nel 2008. Questo progetto si focalizzava sull’utilizzo dello stan-
dard FMI nell’ambito dell’ingegneria automobilistica, e in parte sullo standard AU-
TOSAR [3]. Per tali motivi FMI risulta maggiormente utilizzato all’interno degli
strumenti di sviluppo industriale delle aziende partner del progetto MODELISAR
(DassaultSystèmes, Daimler AG, Qtronic, SimpackGmbH, Trialog, Volkswagen A.G,
Volvo, per citarne alcuni). Tuttavia la specifica dello standard FMI non è stretta-
mente legata con i modelli di simulazioni automobilistici, e quindi l’utilizzo di questo
standard si può trovare anche in altri ambiti, come quello energetico, ferroviario,
aeronautico, aereospaziale [4].
Il numero di tool di simulazione che si basano su FMI sta crescendo rapidamente,
grazie ad alcune loro caratteristiche, come la facilità di utilizzo che conferiscono alle
piattaforme di simulazioni, la facoltà di proteggere la proprietà intellettuale e di
garantire licenze in modo molto facilitato ai simulatori sviluppati [5].
Lo standard FMI è composto di due parti principali: FMI for Model Exchan-
ge e FMI for Co-Simulation. In poche parole, la prima serve per la creazione dei
modelli che implementano l’interfaccia, mentre la seconda serve a definire le intera-
zioni tra modelli, quando questi vengono messi nello stesso ambiente di simulazione.
3

Nelle prossime sezioni saranno illustrate in maniere più approfondite queste due
componenti principali dello standard.
2.1.1 FMI for Model Exchange
Questa prima parte dello standard FMI permette di creare modelli eseguibili che
rappresentino interamente modelli semplici di discipline diverse, oppure sistemi com-
posti dinamici e direttamente simulabili. I modelli cos`ı generati sono chiamati FMU
(Functional Mock-Up Unit). Essi implementano l’interfaccia definita in FMI for
Model Exchange e possono essere eseguiti da qualsiasi ambiente di modellazione
e simulazione; quest’ultimo può, infatti, implementare a sua volta l’interfaccia, in
quanto i modelli non contengono informazioni o file di configurazione relativi a un
simulatore specifico [4].
L’interfaccia consiste delle seguenti parti:
• Interfaccia del modello: tutte le funzioni necessarie per la descrizione del
modello vengono elaborate tramite l’esecuzione di funzioni standardizzate nel
linguaggio ’C’. L’utilizzo di questo linguaggio di programmazione è dovuto alla
sua alta portabilità tra vari sistemi (si noti che il linguaggio ’C’ è impiegato in
quasi tutti i sistemi di controllo dedicati), e alla sua maggiore efficienza rispetto
ad altri linguaggi (in [6] viene fatto un confronto tra ’C’ e Java, facendo notare
come le versioni in Java siano più lente nelle esecuzioni di circa 30
• Schema di descrizione del modello: che illustra la struttura e il contenuto
di un file XML (eXtensible Markup Language) generato dagli strumenti di
modellazione. Il file XML contiene le definizioni delle variabili del modello
in forma standard. In questo modo è possibile separare queste definizioni
dalle effettive istanze in esecuzione del modello. Questo porta a una riduzione
dei costi per ottenere tali informazioni, in quanto il caso contrario porterebbe
una ridondanza di informazioni sulle variabili, un fenomeno noto con il termine
overhead. Inoltre la rappresentazione grafica della descrizione dei modelli viene
realizzata dagli sviluppatori di strumenti che implementano l’interfaccia FMI.
Descrizione matematica del modello
I modelli sono sistemi dinamici descritti da equazioni algebriche, differenziali e di-
screte. Il compito dell’interfaccia Model Exchange è di risolvere numericamente tali
sistemi. Essi sono di tipo continuo a tratti (piecewise continuous system), dove le
discontinuità possono avvenire in determinati istanti chiamati eventi. Gli eventi
sono noti a priori, oppure sono definiti in modo implicito.
La rappresentazione dell’esecuzione del modello avviene grazie agli stati del mo-
dello, che si suddividono tra quelli continui e quelli a tempo discreto. Gli stati
continui sono un insieme di numeri reali (raggruppati in un vettore) che seguono
una funzione continua rispetto al tempo per determinati intervalli. Gli stati a tempo
4

discreto, invece, sono insiemi di variabili reali, intere, di tipo stringa e di tipo logico
(logica booleana), che sono costanti per determinati intervalli e cambiano solo al
momento di un evento.
L’istante in cui avviene un evento può essere definito in una delle seguenti
condizioni, producendo il più breve istante temporale:
• Un istante ti che è stato predefinito al momento di un precedente istante
ti−1, dal FMU, oppure dall’ambiente di simulazione dovuto a un cambiamento
discontinuo degli input (descritto in seguito). Gli eventi definiti in questo
modo sono chiamati eventi temporali.
• Un istante in cui un indicatore di evento zj(t) cambia il suo dominio da zj > 0
a zj < 0 o viceversa. Eventi definiti in questi istanti sono chiamati eventi di
stato.
• Un istante definito da una funzione chiamata alla fine di ogni passo di inte-
grazione (step). Questi eventi sono usati per esempio per modificare dinami-
camente i valori di alcuni stati, che non sono numericamente ammissibili. Essi
vengono chiamati eventi di step.
Un modello potrebbe contenere altre variabili, che descriveremo in seguito, che
possono essere rappresentati, come per gli stati, da insiemi di reali, interi, booleani e
stringhe, e che sono continue a tratti in funzione del tempo. Similmente agli stati, le
variabili non reali possono subire cambiamenti solo dopo un evento. Queste variabili
prendono il significato di parametri, variabili di input, variabili di output e variabili
interne. I parametri sono valori che rimangono costanti dopo l’inizializzazione del
modello. Le variabili di input e output sono pensate per essere usate nelle connes-
sioni fra modelli. Le variabili interne non vengono usate nelle connessioni ma sono
usate all’interno dei modelli con lo scopo di ispezionare i risultati.
Un FMU è inizializzato da una funzione che assegna ad alcune delle variabili
dei valori iniziali, dati come parametri alla funzione. Per permettere l’utilizzo di
algoritmi specializzati di inizializzazione, la funzione viene lasciata per essere de-
finita dallo strumento che implementa l’interfaccia, ma gli argomenti che verranno
utilizzati come parametri di questa funzione sono definiti nello schema di descrizione
del modello.
L’inizializzazione viene seguita da una fase di integrazione continua del model-
lo. In pratica, a istanti predefiniti dall’ambiente di simulazione, viene effettuato il
calcolo delle derivate per gli stati continui, e se ci sono interconnessioni tra modelli,
vengono fatti i passaggi dei dati dalle variabili di output a quelle di input e vengono
salvati i risultati di interesse. L’integrazione continua, come spiegato precedente-
mente, viene interrotta dagli eventi (eventi temporali, di stato o di step). Quando
avviene un evento viene chiamata una funzione che calcola i nuovi valori per gli stati
(continui e discreti).
5

Nel seguito di questo capitolo, si presenta un’interfaccia in linguaggio ’C’ distri-
buita dal sito ufficiale dello standard FMI [7].
Schema di descrizione del modello
Tutte le informazioni di un modello, escludendo le sue equazioni, sono salvate in un
file di testo in formato XML, e seguono una struttura ben definita in uno schema
XSD (XML Schema Definition). In particolare, la descrizione contiene le variabili
del modello e i loro attributi, come il nome, l’unità di misura, il valore iniziale di
default e cos`ı via.
In seguito si mostra un esempio del file XML che descrive il modello, estratto da
[8]:
<?xmlversion="1.0"encoding="UTF8"?>
<fmiModelDescription fmiVersion="1.0"
modelName="Modelica.Mechanics.Rotational.Examples.Friction"
modelIdentifier="Modelica_Mechanics_Rotational_Examples_Friction"
guid="{8c4e810f-3df3-4a00-8276-176fa3c9f9e0}"
description="Drive train with clutch and brake" version="3.1"
generationTool="Dymola Version 7.4, 2010-01-25"
generationDateAndTime="2009-12-22T16:57:33Z"
variableNamingConvention="structured" numberOfContinuousStates="6"
numberOfEventIndicators="34">
<UnitDefinitions>
<BaseUnitunit="rad">
<DisplayUnitDefinitiondisplayUnit="deg"gain="57.2957795130823"/>
</BaseUnit>
</UnitDefinitions>
<TypeDefinitions>
<Type name="Modelica.SIunits.Torque">
<RealTypequantity="MomentOfInertia"unit="kg.m2"min="0.0"/>
</Type>
<Type name="Modelica.SIunits.AngularVelocity">
<RealTypequantity="AngularVelocity"unit="rad/s"/>
</Type>
</TypeDefinitions>
<DefaultExperimentstartTime="0.0"stopTime="3.0"tolerance="0.0001"/>
<ModelVariables>
<ScalarVariable name="inertia1.J" valueReference="16777217"
description="Moment of inertia" variability="parameter">
<RealdeclaredType="Modelica.SIunits.Torque"start="1"/>
</ScalarVariable>
<ScalarVariable name="inertia1.w" valueReference="33554433"
description="Absolute angular velocity of component (= der(phi))">
<RealdeclaredType="Modelica.SIunits.AngularVelocity"start="100"/>
</ScalarVariable>
...
</ModelVariables>
</fmiModelDescription>
6

Per semplicità si descrivono solo lo schema di livello più alto (top level, nell’esem-
pio fmiModelDescription) e quello delle variabili (ModelVariables). Una descrizione
integrale dello schema seguito nell’esempio si può trovare in [8].
Il top level schema contiene una serie di attributi XML dell’elemento ”radi-
ce” del documento che definiscono le proprietà globali del modello, e una serie di
elementi XML, che come si nota dall’esempio più sopra, sono: UnitDefinitions, Ty-
peDefinitions, DefaultExperiment e ModelVariables. L’ultimo elemento tra questi,
ma che non si trova nell’esempio, è l’elemento VendorAnnotations, opzionalmente
usato dagli strumenti di modellazione per tenere informazioni di proprio interesse.
In seguito si elencano gli attributi dell’elemento ”radice” seguendo lo schema di
descrizione del modello presentato in [8]:
• fmiVersion: versione dello standard FMI for Model Exchange usata a creare
il file XML.
• modelName: il nome del modello.
• modelIdentifier: la stringa che viene utilizzata come prefisso dei nomi delle
funzioni del modello e come nome del file in cui tutte le informazioni del
modello vengono salvate.
• guid: sta per ”GloballyUniqueIDentifier” ed è un identificatore univoco del
modello.
• description: descrizione breve del modello.
• author: nome ed organizzazione dell’autore del modello.
• version: versione del modello.
• generationTool: nome dello strumento (tool) che ha generato il file XML.
• generationDateAndTime: data e ora quando è stato generato il file XML.
• variableNamingConvention: definisce se i nomi seguono una particolare
convenzione.
• numberOfContinuousStates: indica il numero degli stati continui del mo-
dello.
• numberOfEventIndicators: indica il numero degli indicatori di eventi.
L’elemento XML che descrive le variabili di modello, ModelVariables, è la parte
centrale della descrizione del modello, e consiste di un set ordinato di elementi
ScalarVariable, che rappresenta una sola variabile, di un solo tipo tra reale, intero,
booleano, stringa o un tipo definito all’interno dell’elemento TypeDefinitions. Gli
attributi dell’elemento ScalarVariable sono:
• name: il nome pieno e univoco della variabile (le variabili sono identificate
dal nome in un FMU).
• valueReference: serve per identificare la variabile all’interno dell’interfaccia
del modello e viene specificata dallo strumento che genera le funzioni.
• description: descrizione opzionale per il significato della variabile.
• variability: definisce come i valori per questa variabile possono cambiare.
Può assumere solo alcuni valori tra cui:
7

– ”constant”: il valore è fisso e non cambia.
– ”parameter”: il valore non cambia dopo l’inizializzazione del modello.
– ”discrete”: il valore può cambiare durante l’inizializzazione e con gli
eventi.
– ”continuous”: non ci sono restrizioni, ma solo le variabili reali possono
avere questo valore.
• causality: definisce come la variabile viene resa visibile all’esterno del mo-
dello. E un’informazione necessaria quando si hanno connessioni tra diversi
modelli FMU. Può assumere solo i seguenti valori:
– ”input”: il valore può essere dato da fuori, inizialmente prende il valore
assegnato all’attributo start (vedi sotto).
– ”output”: il valore può essere utilizzato in una connessione.
– ”internal”: alla variabile si può solo chiederle il valore per salvarla come
risultato, e si può assegnare un valore solo prima della fine dell’inizializ-
zazione.
– ”none”: la variabile non influenza le equazioni del modello, e serve solo
ai tool che effettuano la simulazione.
• alias: definisce se la variabile rispettiva è un alias.
Per descrivere il tipo di una variabile solo uno tra gli elementi Real, Integer,
Boolean, String o Enumeration può essere presente all’interno di ScalarVariable.
Gli attributi di questi elementi sono:
• declaredType: se presente, è il nome di un tipo definito in TypeDefinitions.
Per Enumeration quest’attributo è richiesto obbligatoriamente.
• start: valore iniziale della variabile, assegnata anche nelle funzioni dell’inter-
faccia del modello.
• fixed: definisce il significato dell’attributo start, se causality non è ”input”.
Quest’attributo è ammesso solo se è presente anche start, e può assumere i
valori:
– true: significa che start è il valore iniziale della variabile (dopo l’inizia-
lizzazione la variabile ha il valore di start).
– false: significa che start è un valore ipotetico (dopo l’inizializzazione la
variabile può avere un valore diverso da start).
In fine, l’elemento ScalarVariable può contenere un elemento DirectDependency,
il quale definisce la dipendenza di una variabile di output dagli input. Questo
elemento è presente solo nelle variabili che hanno l’attributo causality uguale a
”output”. Se non presente, implica che la variabile (di output) dipende direttamente
da tutte le variabili di input. Se presente, lista i nomi di tutte le variabili in input
(con causality = ”input”) da cui dipende direttamente, ciascuno rappresentato da
un elemento Name.
8

2.1.2 FMI for Co-Simulation
Diversamente da FMI for Model Exchange, questa seconda parte dello standard FMI
serve per riuscire ad accoppiare (coupling) due o più modelli in un ambiente di co-
simulazione. La co-simulazione è una tecnica di simulazione per sistemi accoppiati
(tempo continuo e tempo discreto), che sfrutta la struttura modulare dei problemi di
accoppiamento in tutte le fasi del processo di simulazione, cioè preparazione iniziale,
integrazione temporale e post-processing [4].
Lo standard definisce che in un ambiente di co-simulazione lo scambio di dati tra
due sottosistemi avviene solamente in alcuni punti discreti di comunicazione (com-
munication point). Nel periodo in mezzo a due punti di comunicazione i sottosistemi
sono elaborati in modo indipendente da altri, ciascuno dal proprio risolutore, chia-
mato solver. L’algoritmo di controllo dello scambio di dati tra i sottosistemi viene
chiamato Master, e si preoccupa della sincronizzazione della comunicazione tra i
solver delle simulazioni, che in questa gerarchia sono meglio noti come Slaves.
FMI for Co-Simulation rende disponibile un’interfaccia per la comunicazione
tra il master e gli slave, e supporta una classe estesa e generica di algoritmi ma-
ster. Da notare comunque che la definizione degli algoritmi master non fa parte
dell’interfaccia.
Ci sono due modi di fornire all’ambiente di co-simulazione degli slave: sottosi-
stemi forniti del loro specifico solver, che possono essere simulati come componenti
stand-alone (un file dll), oppure sottosistemi con il proprio strumento di simulazio-
ne, in cui sono stati costruiti. Entrambi i modi sono trattati dallo standard FMI for
Co-Simulation.
Precedentemente si è visto come nella descrizione del modello ci sono informa-
zioni che possono aiutare il master a specificare come la comunicazione tra modelli
avviene in un ambiente di co-simulazione. Oltre a quelle informazioni, l’interfac-
cia FMI for Co-Simulation ne aggiunge altre specifiche agli slave, che sono degli
indicatori di capacità (capability flags) per caratterizzare l’abilità nel sostenere al-
goritmi master avanzati, come ad esempio, la possibilità di poter usare degli step
di comunicazione variabili, estrapolazione di segnale di ordini più grandi, o altro
ancora.
L’interfaccia passa attraverso tutte le fasi del processo di simulazione, partendo
da quella di impostazione e inizializzazione dei modelli, nella quale il master analizza
le connessioni tra i vari modelli, carica in memoria gli FMU necessari, crea tutte
le istanze e assegna i valori iniziali per ciascuna di esse. In seguito si procede con
l’integrazione temporale, in cui ciascun modello viene simulato individualmente in
intervalli di tempo e lo scambio di dati viene orchestrato dal master nei communi-
cation point definiti prima, accedendo a delle variabili o assegnandoli dei valori. In
fine, vengono elaborati a posteriori i dati e visualizzati i risultati, ciascuno in modo
indipendente per qualsiasi sottosistema, e viene liberata la memoria usata dai FMU.
L’interfaccia, similmente a FMI for Model Exchange, consiste delle due parti:
interfaccia di co-simulazione e lo schema di descrizione della co-simulazione. La
9

prima consiste di una serie di funzioni in linguaggio ’C’ per lo scambio di valori tra
input e output, e per lo scambio di informazioni legate alla situazione (status) delle
istanze. La seconda definisce lo schema di un file in formato XML, che contiene,
oltre alle informazioni sul modello nel caso dell’interfaccia Model Exchange, altre
legate alla simulazione, come ad esempio gli indicatori di capacità descritti prima.
La descrizione dell’interfaccia di co-simulazione viene lasciata alla sezione 2.2.1.
Schema di descrizione della co-simulazione
Per quanto riguarda lo schema di descrizione della co-simulazione, essa utilizza le
stesse convenzioni e i tipi di dati dello schema XML definito per FMI for Model
Exchange, con in aggiunta due importanti differenze:
1. La definizione dello schema principale in formato XSD (fmiModelDescrip-
tion.xsd) è stata modificata aggiungendo un ulteriore elemento Implementa-
tion.
2. Un file di schema per questo elemento è stato aggiunto per definire gli elementi
necessari al supporto della descrizione della co-simulazione.
L’elemento Implementation definisce un tipo di ”implementazione” nel conte-
sto di co-simulazione, che può essere solo uno degli elementi CoSimulation Tool
oppure CoSimulation StandAlone. Questi due tipi sono stati descritti in preceden-
za in questo capitolo. Il primo definisce un sottosistema con il proprio strumento
di simulazione, mentre il secondo definisce il sottosistema fornito del proprio sol-
ver. Entrambi questi due elementi contengono l’elemento Capabilities, mentre solo
CoSimulation Tool contiene l’elemento Model.
L’elemento Capabilities definisce gli indicatori di capacità descritti in preceden-
za, come la possibilità di gestire dimensioni variabili di step di comunicazione, di
gestione degli eventi, di rifiutare e ripetere uno step di comunicazione, di inter-
polazione di input continui, e altri ancora. L’elemento Model definisce il modello
associato allo slave, che deve essere eseguito dal simulatore. In alcuni casi questo
elemento può contenere più elementi File che definiscono altri file necessari (possono
essere altri modelli, file di calibrazione, ecc.) al modello.
La descrizione integrale dello schema è contenuto nella specifica dello standard
FMI for Co-Simulation in [4].
2.1.3 Struttura di un FMU
Un modello FMU è un file con l’estensione .fmu, che in realtà consiste di un file zip
che ”impacchetta” le seguenti componenti:
• Le sorgenti in linguaggio C’ del modello, nelle quali vengono implementate le
funzioni dell’interfaccia FMI, alcune delle quali verranno spiegate in dettaglio
nelle prossime parti.
10

• Opzionalmente, le sorgenti in forma compilata (DLL o shared libraries) del
modello, le quali sono direttamente eseguibili.
• Il file XML della descrizione del modello, che contiene tutta l’informazione
statica per le variabili necessarie al modello. Inoltre questo file viene usato
pure dal master per costruire una rete di dipendenze che dirige il modo in cui
viene svolta l’esecuzione della simulazione.
• Altri file con informazione supplementare per il modello (documentazione
integrativa, immagini, altro).
Un esempio di struttura interna di un FMU si vede nella figura 2.1.
Figura 2.1: Struttura interna di modello FMU
2.2 FMI 1.0
La descrizione fino ad ora fatta di FMI si basa sulla prima versione dello standard,
rilasciata nel 2010, mentre l’attuale versione dello standard è la 2.0 rilasciata nel
2014. In questo paragrafo continueremo ad analizzare più in dettaglio lo standard,
basandoci sulla versione 1.0, per descrivere l’interfaccia e l’ambiente di sviluppo di
modelli (Software Development Kit) rilasciati con questa versione.
La descrizione della versione 2.0 viene rilasciata a una parte successiva del
documento, facendo notare le principali differenze con la versione 1.0.
Il motivo principale per il quale questo lavoro si è focalizzato principalmente
sulla prima versione, sta nel fatto che è quella più usata e supportata da strumenti
di creazione modelli e di simulazione. Molti strumenti di software sono ancora in
fase di sviluppo per supportare la seconda versione, mentre alcuni la supportano solo
parzialmente. Una tabella indicativa di come vengono supportate le due versioni da
tutti i software conosciuti che implementano l’interfaccia FMI, si può trovare sul
sito ufficiale dello standard [9].
11

2.2.1 FMU Software Development Kit (SDK)
La FMU SDK è un kit gratuito fornito da QTronic( [10]) con lo scopo di mostrare
gli usi fondamentali degli FMU, di aiutare lo sviluppo di software e modelli che si
basano sull’interfaccia FMI e in più servire come punto di partenza per lo sviluppo
di applicazioni che importano ed esportano gli FMU.
La sua distribuzione viene fatta tramite un file zip che contiene:
• Delle sorgenti in linguaggio ’C’ contenenti le funzioni delle interfacce per Mo-
del Exchange e Co-Simulation, che sono descritte all’interno della specifica
dell’interfaccia FMI [4] [8], e che vengono usati per la creazione di modelli,
• Delle sorgenti in linguaggio ’C’ per alcuni modelli FMU (discreti e continui),
i rispettivi file XML per la descrizione dei modelli, e altre informazioni legate
a ciascun modello (ad es. immagini, documentazione, ecc.),
• Un parser XML per estrarre informazioni dalle descrizioni del modello,
• Dei file batch per la compilazione dei modelli, e la costruzione degli FMU,
• Delle sorgenti in linguaggio ’C’ per l’implementazione di un semplice simula-
tore, che permette di simulare gli FMU e scrivere i risultati in un file CSV,
• Dei file batch per la simulazione degli FMU.
Tutte queste risorse esistono per entrambe le versioni di FMI (a parte il file batch
per la creazione dei modelli che crea direttamente modelli per entrambe versioni, e
il file batch per la simulazione di FMU).
Nella seguente sezione si presenta più in dettaglio come sono strutturate le sor-
genti in ’C’ dei modelli, analizzando in dettaglio le funzioni dell’interfaccia, e le
funzioni che bisogna implementare per la creazione dei modelli. Queste funzio-
ni e la struttura dei file che li contengono sono facilmente osservabili grazie alla
distribuzione della SDK.
2.2.2 Struttura dei file sorgenti dei modelli
Gli FMU possono contenere file sorgenti diversi in base al fatto che implementino
l’interfaccia Model Exchange oppure quella Co-Simulation. La convenzione per que-
sti file stabilisce che tutti i nomi di funzioni (in ’C’) e di definizione dei tipi debbano
iniziare con il prefisso ”fmi”.
Normalmente le funzioni dell’interfaccia che devono essere implementate fanno
parte del file principale in linguaggio ’C’ del modello (questo file prende il nome dal-
l’attributo modelIdentifier all’interno del file XML di descrizione del modello). Al
loro interno essi devono includere fmuTemplate.h, un header file, e fmuTemplate.c,
che sono identici per tutti i modelli (si trovano in condivisione con tutti). fmu-
Template.h a sua volta può includere in sé uno tra gli header file fmiFunctions.h o
fmiModelFunctions.h, nei casi in cui si usa l’interfaccia Co-Simulation (CS) o Model
Exchange (ME), rispettivamente.
12

Ulteriormente fmiFunctions.h include il header file fmiPlatformTypes.h nel pro-
prio interno, mentre fmiModelFunctions.h include fmiModelTypes.h.
fmiModelTypes.h(ME) e fmiPlatformTypes.h(CS)
Possiedono le definizioni dei tipi per gli argomenti in input e in output delle funzio-
ni. Per aiutare la portabilità, come argomenti delle funzioni non vengono usati tipi
del linguaggio ’C’, ma vengono ridefiniti con degli alias. Questi header file vengo-
no usati sia dal modello sia dal simulatore. I tipi definiti in questi brevi file sono:
fmiComponent, fmiValueReference, fmiUndefinedValueReference, fmiReal, fmiInte-
ger, fmiBoolean, fmiString. Inoltre vengono anche definiti i due valori fmiTrue e
fmiFalse per il tipo fmiBoolean.
fmiModelFunctions.h(ME) e fmiFunctions.h(CS)
Contengono i prototipi delle funzioni che vengono rese accessibili agli ambienti di
simulazione. In modo da avere più istanze per ciascun modello, i nomi di que-
ste funzioni vengono modificati a tempo di esecuzione, e il nome risultante sarà
composto dal nome del prototipo della funzione unito al nome dell’identificatore
del modello. Questi header file contengono anche le definizioni di altri tipi come:
fmiStatus, fmiCallbackLogger, fmiCallbackAllocateMemory, fmiCallbackFreeMemo-
ry, fmiStepFinished (solo per CS), fmiCallbackFunctions (raggruppa le precedenti 3
(4 per CS)), fmiEventInfo e fmiStatusKind (solo per CS).
fmuTemplate.h(ME)
Aggiunge alle definizioni effettuate dai file che importa, altre che definiscono il tipo
ModelState e il tipo ModelInstance. Inoltre definisce la struttura di dati per le
variabili del modello, in cui le variabili vengono raggruppate secondo il loro tipo
(fmiReal, fmiBoolean, ...), ordinate in array nominati brevemente per identificare il
tipo (con nomi come r, b, ecc. rispettivamente per real, boolean, ecc.), e identificate
tramite il loro valore di riferimento (value reference, fmiValueReference). Viene
definito anche un array per contenere gli indicatori degli eventi, chiamata pos(z),
con z l’indice dell’indicatore.
fmuTemplate.c(ME)
Come si può intuire dal nome, è una sorta di template contenente codice che è
identico per tutti i modelli. Serve per definire quasi tutte le funzioni che vengono
utilizzate dagli ambienti di simulazione per gestire i modelli, lasciando non definite
solo alcune che devono essere implementate in maniera diversa in base alle carat-
teristiche del modello (sono implementate nel file sorgente principale, che ha come
nome l’identificatore del modello).
13

In seguito si elencano alcune funzioni importanti in questo file, con una breve
descrizione del loro utilizzo.
• Inizialmente, sono definite le funzioni per la gestione delle istanze del modello.
La funzione instantiateModel serve per creare una nuova istanza del modello,
e allocarla in memoria insieme con altri dati di sua appartenenza. Inoltre essa
chiama la funzione setStartValues, che deve essere implementata nella sorgente
principale del modello, e che permette di assegnare dei valori iniziali alle va-
riabili del modello. La funzione init serve per inizializzare il modello e chiama
la funzione initialize, che è una delle funzioni da implementare nella sorgen-
te principale del modello, usata per definire l’evento iniziale del modello. La
funzione terminate invece serve per terminare il modello, ossia assegnare allo
stato del modello il valore modelTerminated. In fine, la funzione freeInstance
serve a liberare la memoria occupata dall’istanza del modello (e i suoi dati)
una volta che la sua esecuzione è stata terminata.
• In seguito, sono definite le funzioni per l’assegnazione e l’estrazione dei valori
delle variabili, funzioni che sono generalmente note con i nomi di setter e getter
rispettivamente. Per i setter ci sono le funzioni fmiSetReal, fmiSetInteger, fmi-
SetBoolean, fmiSetString, e per i getter ci sono dei nomi analoghi (fmiGetReal,
...).
• La funzione fmiGetDerivatives serve, come si intuisce dal nome, per calcolare le
derivate per le variabili reali. Al suo interno viene chiamata la funzione getReal,
che è una funzione da implementare nella sorgente principale del modello, in cui
vengono definite le equazioni differenziali. La funzione getReal viene chiamata
anche all’interno della funzione fmiGetContinuousStates, che calcola i valori
degli stati continui.
• La funzione fmiGetEventIndicators viene utilizzata per ottenere gli indicatori
degli eventi, e chiama la funzione getEventIndicator, che è una funzione da
implementare nella sorgente principale, la quale controlla il dominio degli in-
dicatori degli eventi in modo da notare cambiamenti che indicano gli eventi
(come spiegato in 2.1.1).
• La funzione fmiEventUpdate viene chiamata quando l’istanza del modello ri-
scontra un evento. Essa chiama al proprio interno la funzione eventUpdate,
che è una funzione da implementare nella sorgente principale, che contiene il
codice da eseguire con il triggering di un evento.
• La funzione fmiSetTime è utilizzata per assegnare alle istanze dei modelli il
tempo di esecuzione della simulazione.
• La funzione getStatus serve all’ambiente di simulazione a interrogare lo stato
attuale delle istanze, descritto con uno dei valori di tipo fmiStatus.
14

• Alla fine di questo elenco, ci sono le funzioni fmiDoStep e fmiCancelStep. fmi-
DoStep è una delle funzioni più importanti (sicuramente la più lunga conside-
rando le righe di codice) di questo file. Essa serve per svolgere l’integrazione
temporale della simulazione, svolgendo uno step dell’istanza in cui calcola i
nuovi valori delle variabili, chiamando la funzione getReal, e la funzione getE-
ventIndicator per controllare se si è riscontrato un evento, e in caso positivo
chiamando anche eventUpdate. La funzione fmiCancelStep viene usata nel ca-
so sia necessario rifiutare uno step (nella versione originale della distribuzione
della SDK essa ritorna uno status di errore).
Sorgente principale del modello
Per la descrizione di un modello usando l’interfaccia FMI, può bastare definire solo la
sorgente principale del modello e il file di descrizione del modello (in formato XML).
Per questo, tale sorgente è un elemento fondamentale per la rappresentazione del
modello dove vengono definite le caratteristiche principali tramite variabili e funzioni
che si descriveranno.
Inizialmente, all’interno di questo file, vengono definite delle variabili, che rap-
presentano informazioni contenute anche nella descrizione del modello, per creare
un collegamento inconfondibile tra i due file, creando un’unica rappresentazione del
modello. Queste variabili sono l’identificatore del modello, MODEL IDENTIFIER,
e l’identificatore univoco GUID (GloballyUniqueIDentifier). In seguito, vengono de-
finiti dei parametri che indicano il numero di variabili per ciascun tipo, il numero di
stati, e il numero di indicatori di evento. I valori di questi parametri sono utilizzati
dalle funzioni all’interno del file fmuTemplate.c. Successivamente, sono definite le
variabili del modello, ciascuna rappresentata da un nome univoco, a cui viene as-
sociato un valore, che è il valore di riferimento delle variabili all’interno dell’array
di tipo di appartenenza (valuereference, come indicato in sezione 2.2.2). Tra queste
variabili vengono definite quelle di stato, cioè che servono a rappresentare lo stato
della simulazione, inserendole all’interno dell’array STATES.
Come descritto precedentemente, in questo file vengono implementate le fun-
zioni: setStartValues, initialize, getReal, getEventIndicator ed eventUpdate. Queste
funzioni, fondamentali per la descrizione del modello e delle sue dinamiche, sono
spiegate come segue:
• setStartValues: viene chiamato da instantiateModel, e serve a stabilire dei
valori per tutte le variabili dell’istanza che ammettono un valore iniziale.
Inoltre vengono anche determinati i valori di dominio per gli indicatori di
eventi.
• initialize: chiamato da init, aggiudica il primo evento temporale della simu-
lazione, se ce n’è uno.
• getReal: chiamato da più di una funzione, serve a ritornare i valori per
tutte le variabili dell’istanza. I valori ritornati sono risultato di un calcolo
15

effettuato con le formule lineari o differenziali del sistema scritte in linguaggio
’C’ all’interno di questa funzione.
• getEventIndicator: viene chiamato da fmiGetEventIndicators e fmiDoStep,
e serve per indicare gli indicatori di evento, come descritto in precedenza.
• eventUpdate: viene chiamato da più funzioni, quando si riscontra un even-
to. Serve per eseguire le funzionalità implementate all’interno e decidere
eventualmente il prossimo evento.
2.2.3 Esempi di modelli della SDK
Tra i contenuti della SDK si trovano degli esempi di modelli che sono stati costruiti
dagli sviluppatori della SDK, seguendo l’interfaccia FMI. Inizialmente essi sono di-
stribuiti con dei file sorgenti (quello principale, fmuTemplate.c, fmuTemplate.h, ...)
accompagnati dal file di descrizione modello (modelDescription.xml) e da immagini
e documentazione rispettiva.
Alcuni file batch, distribuiti anche essi nella SDK, rendono possibile la compila-
zione dei file sorgente, e grazie alla lettura del modelDescription.xml (con dei parser
XML), costruiscono i modelli nella forma di un FMU (in formato .fmu).
Altri file batch usano delle altre sorgenti della SDK per simulare i modelli, e
scrivere i risultati in un file di formato CSV, di nome results.csv.
I modelli sono i seguenti:
• inc: è un modello matematico che incrementa un contatore di un’unità per
ogni secondo di tempo di simulazione. Ha uno stato in cui l’istanza viene
terminata, ed è quando il contatore raggiunge il valore 13. Questo è un mo-
dello che mostra l’utilizzo della funzione eventUpdate implementandola come
decisore del prossimo evento.
• dq: è un modello matematico dell’equazione di test di Dahlquist. Il modello
mostra come creare un modello con equazioni differenziali per ottenere una
soluzione analitica.
• values: è un modello che non appartiene a nessuna particolare disciplina, ma
che mostra come utilizzare tutti i tipi di variabili dell’interfaccia FMI.
• vanDerPol: è un modello matematico dell’oscillatore di Van DerPol. Come
dq, anche questo modello mostra come utilizzare equazioni differenziali per la
simulazione di un sistema, ma in questo caso si usano due variabili di stato.
• bouncingBall: è un modello fisico che simula una pallina che viene lasciata
in caduta libera da una certa altezza, sotto soltanto l’effetto della forza di
gravità. Al momento di collisione con il suolo, si scatena un evento che fa rim-
balzare la pallina sul verso opposto, facendola riprendere quota fino a fermarsi
per poi riscendere, come normalmente accade a un tale sistema fisico reale.
Questo modello ha anche una costante di elasticità la quale, se minore di uno,
fa perdere velocità nel rimbalzare, perciò la quota massima raggiungibile in
16

seguito è minore a quella precedente. In questo modo la pallina tende ad avvi-
cinarsi sempre di più al suolo con il passare del tempo. Il modello non ha uno
stato finale almeno che non venga fermato dalla simulazione, ma continua ad
aver un moto oscillatorio con la quota che si avvicina sempre di più al valore
del suolo. Questo è un modello che mostra l’utilizzo degli indicatori di eventi,
di come si possono utilizzare gli stati del modello e di come un modello fisico
può essere descritto con l’interfaccia FMI.
I due modelli su cui si focalizzerà di più per il progetto di questa tesi sono
bouncingBall e inc, e una loro interazione in un ambiente di co-simulazione verrà
descritta nel prossimo paragrafo.
2.3 Simulazione con Simulation X
Uno degli obiettivi principali dello standard FMI è di rendere possibile a un FMU
esportato (costruito) da un particolare software, a poter operare con altri strumenti
di vari tipi e produttori, e rendere possibile a strumenti che importano (accettano)
FMU esportati da altri, di orchestrare la comunicazione tra gli ultimi [11].
Molti software di simulazione offrono la possibilità di importare modelli FMU
nei propri ambienti, e uno tra questi, utilizzato nel progetto di questa tesi per la
simulazione dei modelli esempio descritti precedentemente, è SimulationX [12]. La
simulazione con questo software ha permesso di studiare più facilmente i modelli e lo
standard, grazie anche a una migliore visualizzazione di dati rispetto alla simulazione
fornita nella SDK. In più questo software offre la possibilità di creare un ambiente
di co-simulazione con più modelli, costruendo una rete di connessione tra modelli in
maniera veloce e intuitiva, grazie all’interfaccia utente. La co-simulazione grazie a
questo software, sarà affrontata più avanti in questa sezione.
SimulationX è un software CAE per la simulazione, la modellazione, l’analisi e
l’ottimizzazione dei sistemi complessi, ed è stato sviluppato da ITI GmbH (da inizio
2016 opera con il nome ESI ITI GmbH, in quanto acquistato dall’ESI Group [13]).
La principale caratteristica di questo software è la rappresentazione interattiva dei
modelli tramite l’interfaccia utente, e che si possano interconnettere facilmente con
azioni di tipo drag and drop. Questo software è noto anche per aver adottato il
supporto al linguaggio orientato agli oggetti Modelica (open-source), che è uno dei
linguaggi principali usati per la creazione di modelli di simulazione (sviluppato da
Modelica Association, organizzazione non-profit strettamente legata allo standard
FMI).
Inoltre SimulationX rende possibile l’uso del software in modo gratuito, grazie
alla versione Student Edition, per uso accademico, la quale è stata usata per le
simulazioni che verranno descritte più avanti. Da notare che questa versione offre
funzionalità molto più limitate rispetto alla versione completa del software, come di
solito accade in questi tipi di distribuzione del software.
17

2.3.1 Creazione di pendulum.fmu
Per provare un’implementazione pratica dell’interfaccia FMI, è stato costruito un
semplice modello fisico, chiamato pendulum. Questo modello imita un pendolo fisico
ideale, sul quale agisce soltanto la forza di gravità, e il quale può essere inizializzato
lasciandolo in caduta libera oppure dandogli una velocità iniziale, da qualsiasi punto
di partenza nell’intervallo di ±90◦ dal punto di equilibrio.
A questo modello si può assegnare un valore di input che si trova nell’intervallo
precedente, che rappresenta un ostacolo per il pendolo, facendolo rimbalzare nella
direzione opposta al momento di collisione, simile al caso in bouncingBall.fmu. In
effetti, ci sono alcune analogie tra i modelli, ma su pendulum.fmu si hanno equazioni
differenziali con più parametri, e soprattutto si è creato un modello che interagisce
con altri grazie agli input/output, che è una caratteristica mancante degli altri
esempi di modelli della SDK.
Il modello è stato realizzato usando la SDK, implementando le funzioni come
descritto in precedenza. In seguito alla realizzazione del modello, sono state eseguite
varie simulazioni con SimulationX, in cui si è notato come il modello rispecchia le
caratteristiche dei modelli reali.
2.3.2 Co-simulazione di bouncingBall.fmu e inc.fmu
La simulazione individuale dei modelli bouncingBall.fmu e inc.fmu con Simulatio-
nX, produce risultati identici alla simulazione effettuata con la SDK, facilmente
confrontabili in quanto i modelli hanno una bassa complessità di simulazione.
In seguito alla simulazione individuale, si è cercato di sfruttare SimulationX per
creare un ambiente di co-simulazione, e aggiungere i due modelli in esso. Per fare
questo, si è dovuto fare delle modifiche ai modelli, in quanto non possiedono variabili
di input e output per lo scambio di valori. In particolare, sono stati creati due nuovi
modelli (per mantenere le risorse dei modelli originali invariate) che rappresentano
i precedenti, ma con alcune modifiche. Il nuovo modello di bouncingBall ha due
variabili aggiuntive, dove la prima è un parametro che specifica il valore iniziale
dell’altezza da cui la pallina viene lasciata cadere, mentre il secondo è un valore
in input, che rappresenta il livello del suolo con cui la pallina dovrebbe scontrarsi.
Per questo modello, il suolo può essere un valore costante durante l’esecuzione della
simulazione, oppure variabile nel tempo secondo una funzione. Per rispondere ai
nuovi comportamenti introdotti nel modello, sono state modificate anche le funzioni
getEventIndicators ed eventUpdate.
In più nel nuovo modello di bouncingBall, gli stati sono definiti come valori in
output, per fornire informazioni agli altri modelli in comunicazione.
Nell’ambiente di co-simulazione sarà il modello inc modificato a fornire come
input i valori per determinare il livello del suolo del modello bouncingBall. Per fare
questo il nuovo modello inc possiede tre variabili di cui i primi due sono dei parametri
che indicano un valore iniziale e il valore del passo di incremento o decremento a
18

ogni iterazione, mentre il terzo rappresenta il valore finale calcolato, che viene fornito
come input al modello bouncingBall.
Un esempio di co-simulazione di questi modelli viene fornito nella figura 2.2.
Figura 2.2: Esempio di co-simulazione in SimulationX
Le due immagini sono ottenute da SimulationX. In quella a sinistra si può notare
il grafo delle connessioni dei due modelli, mentre in quella a destra il grafico dei
risultati dell’esecuzione. Come si può vedere, questa simulazione ha una durata di 10
secondi, e con la linea verde viene visualizzata la variazione dell’altezza della pallina
nel tempo, mentre la linea rossa rappresenta la variazione lineare (crescente) del
livello del suolo. Il grafico mostra facilmente come questi due modelli interagiscono
in questa co-simulazione.
2.4 Problemi di co-simulazione
Come conseguenza della creazione di modelli di simulazione, e unendo insieme questi
modelli con l’obiettivo di creare diverse situazioni di co-simulazione, a volte sono sta-
ti verificati comportamenti diversi da quelli previsti, e altre ancora completamente
errati.
Nel lavoro svolto in [11] viene fatto notare che sebbene i modelli costruiti e
gli algoritmi di master sono conformi allo standard FMI, essi possono comunque
presentare comportamenti non previsti oppure non deterministici. In esso inoltre
vengono definite alcune caratteristiche e capacità di esecuzione che gli FMU devono
possedere, ma che nello standard sono definite come opzionali, e che sono rara-
mente implementati nei modelli effettivi. Come estensione di tale lavoro, in [1]
vengono identificati alcuni casi particolari di connessione e comunicazione tra FMU,
analizzando le loro caratteristiche e presentando degli accorgimenti agli algoritmi
19

master per ciascuno dei casi, in modo da ottenere delle esecuzioni di simulazione
deterministiche. Questi casi sono raggruppati nelle seguenti due categorie:
• Co-simulazioni di modelli che contengono retroazione: simulazioni in cui lo
scambio di variabili ha inizio e fine nello stesso FMU. In questa categoria si
hanno due varianti: retroazione diretta e retroazione ritardata.
• Co-simulazioni di modelli senza retroazione: simulazioni in cui si può speci-
ficare un ordine di esecuzione per gli FMU. Le varianti per questa categoria
sono:
– Modelli con lo stesso passo di esecuzione.
– Modelli con passo diverso di esecuzione, ma di base comune.
– Modelli con passo di esecuzione e base diverse.
Nelle seguenti sezioni presentiamo ciascuna di queste varianti, introducendo an-
che le caratteristiche che gli FMU devono avere e gli accorgimenti sugli algoritmi
master, proposti in questo studio.
2.4.1 Co-simulazioni di modelli con retroazione
La prima variante di questi modelli, in cui gli FMU sono connessi in retroazione,
e questa è diretta. Questo significa che si ha una dipendenza interna diretta delle
variabili di output da quelle di input e che nel modello è presente un ciclo algebrico,
cioè i valori delle variabili di output sono funzioni di se stesse nello stesso step di
simulazione. I cicli algebrici si possono risolvere con il metodo di iterazioni di punto
fisso (iterazione funzionale), noto in letteratura anche come il metodo iterativo di
Picard [14]. Nella co-simulazione, questo metodo iterativo si può adattare definendo
un algoritmo master in questo modo:
1. Per ciascun FMU:
(a) Salva lo stato del FMU e gli output
(b) Simula FMU
(c) Collega i valori di output con gli altri FMU
2. Per ciascun FMU:
(a) Ripristina lo stato del FMU
(b) Se l’output non converge e le condizioni dello step non sono state soddi-
sfate, torna al passo 1.
Per riuscire ad adottare questo tipo di master, gli FMU devono essere in grado
di sopportare le procedure di salvataggio e ripristino del loro stato completo, mecca-
nismo noto come rollback. La versione 1.0 dello standard FMI non definisce questo
meccanismo, diversamente dalla versione 2.0, che aggiunge le funzioni necessarie agli
FMU, come si vedrà in seguito di questo documento, nella sezione 2.5.
20

La seconda variante di questi modelli contiene una retroazione ritardata. Questo
quando alla presenza di uno schema di connessioni tra FMU con retroazione, ci sia
almeno una dipendenza di output da input, che sia ritardata rispetto alle dipendenze
dirette. In generale, questo tipo di dipendenza non produce più un ciclo algebrico,
perciò rende più semplice la soluzione delle equazioni, però in un ambiente di co-
simulazione, si hanno delle complicazioni, in quanto in un certo istante un FMU
può ricevere come input, valori di output calcolati in step di simulazione errati.
Per risolvere questo problema, si usa il meccanismo di rollback, presentando un
algoritmo master come questo:
1. Per FMUx con dipendenza ritardata:
(a) Salva lo stato del FMUx
(b) Simula FMUx
(c) Collega i valori di output con gli altri FMU
2. Per gli altri FMU:
(a) Simula FMU
(b) Collega gli output con altri FMU.
3. Ripristina lo stato di FMUx e simula FMUx.
In generale, l’algoritmo può essere utilizzato anche nel caso in cui FMUx non
abbia dipendenza ritardata. In questo caso il primo FMU simulato deve sostituire
FMUx in questo algoritmo (usato per eseguire i passi 1 e 3).
A livello pratico, è stato possibile costruire un modello di co-simulazione di que-
sta categoria (la prima variante), utilizzando due istanze del modello creato pendu-
lum.fmu, le quali scambiano in input/output, informazioni legate alla loro posizione
e velocità, per verificare le situazioni di collisioni. Eseguendo la co-simulazione
con SimulationX, si sono verificati errori di computazione nei momenti di collisione
tra pendoli, in quanto l’algoritmo master per l’orchestrazione della simulazione non
possiede gli accorgimenti mostrati in precedenza.
2.4.2 Co-simulazione di modelli senza retroazione
In questo tipo di co-simulazione, non ci sono cicli di connessione, e questo significa
che l’esecuzione degli FMU può seguire un ordine preciso, partendo da un certo
FMU e finendo in un altro l’esecuzione per quel step di comunicazione.
La prima variante di questi è quella in cui tutti gli FMU hanno lo stesso step
di comunicazione. In questi casi non sono necessari aggiustamenti dell’algoritmo
master.
La seconda variante è quella in cui gli FMU non hanno lo stesso step di comu-
nicazione, ma comunque questi step sono tali che quello maggiore e anche quelli
intermedi sono multipli del più piccolo step, chiamato base. Per questa variante
21

si hanno altri due casi. Seguendo l’ordine di simulazione, se un FMU ha uno step
h1, minore rispetto al seguente, con uno step h2, esso si deve simulare tante volte
quanto il multiplo di h1 per produrre lo step del FMU seguente, cioè k volte, dove
h2 = k∗h1. Nel caso inverso invece, se un FMU1 ha uno step maggiore del seguente,
FMU2, i suoi valori di output devono essere interpolati per tutti gli step necessari
dal seguente FMU, analogamente al caso precedente per k volte. Per questo secondo
caso si ha il seguente aggiustamento all’algoritmo master:
1. Simula FMU1
2. Simula FMU2
(a) Interpola il valore di output di FMU1 per lo step di comunicazione.
(b) Simula FMU2.
(c) Se FMU2 non è stato simulato k volte, vai al passo 2.
La terza variante è simile alla seconda variante, con la differenza che gli step
non hanno una base in comune. Anche per questa variante si hanno due casi, come
la precedente. Il primo è quello in cui un FMU1 ha uno step inferiore al seguente,
FMU2. In questo caso non si può praticare la soluzione della variante precedente,
cioè simulare per k volte, ma bisogna verificare una corrispondenza degli step di
comunicazione, il che significa che si deve verificare se la simulazione per k volte
porta a un output corretto per simulare FMU2. Nel caso in cui non ci sia una
corrispondenza bisogna eseguire un’estrapolazione del valore di output da 1, prima
di passare questo valore a FMU2. Il seguente è l’aggiustamento che si effettua
all’algoritmo master:
1. Simula FMUx
(a) Calcola k.
(b) Simula FMUx k volte.
(c) Se si verifica una corrispondenza con step di FMU seguente, salta al passo
3.
2. Estrapola il valore di output per lo step del FMU seguente.
3. Passa il valore di output al FMU seguente.
4. Simula FMU seguente.
Per quanto riguarda il secondo caso di questa variante, si esegue un aggiusta-
mento all’algoritmo master come nella variante precedente, in cui i valori di output
dal primo FMU vengono interpolati per ogni step di comunicazione del secondo.
L’aggiustamento che viene effettuato al master è lo stesso, con l’eccezione della
simulazione di FMU2 per k volte.
Con SimulationX, è stato possibile eseguire la simulazione di modelli di co-
simulazione di questa categoria. Uno degli esempi per questi modelli è quello pre-
sentato precedentemente con le versioni modificate di inc.fmu e bouncingBall.fmu.
22

La simulazione per questi modelli può essere eseguita per ciascuna delle 3 varianti,
ossia per lo stesso step, step diversi ma con la stessa base, oppure step diversi con
base diversa.
2.5 FMI 2.0
La seconda versione dello standard FMI è stata rilasciata nel 2014. Questa versione
comporta grandi cambiamenti rispetto alla 1.0, e nel seguito di questa sezione ver-
ranno descritti quelli principali. Da notare che la versione 2.0 non è retro compatibile
con i modelli costruiti tramite la versione 1.0 dello standard.
Come prima cosa, in FMI 1.0 si ha una separazione tra le interfacce Model Ex-
change e Co-Simulation, definite in due documenti diversi, mentre in questa versione
entrambe le interfacce sono descritte nello stesso documento e sono state unificate in
una. Con questa unione un FMU implementa entrambe le interfacce simultaneamen-
te, e nella descrizione del modello (in XML) esistono nuovi elementi ModelExchange
e Co-Simulation che indicano quale interfaccia è stata implementata. In seguito è
l’ambiente di simulazione a stabilire quale interfaccia usare, chiamando la rispettiva
funzione di inizializzazione, fmi2InstantiateModel o fmi2InstantiateSlave.
Da notare inoltre che tutte le funzioni in linguaggio ’C’ dell’interfaccia possiedono
un nuovo prefisso fmi2.
FMI 2.0 possiede anche la possibilità di salvare e ripristinare lo stato intero di
un FMU, che consiste di informazioni legate alle variabili (stati, parametri, valori in
input, identificatori dei file, stato interno del FMU), e che permette il meccanismo
di rollback, utile per alcuni algoritmi master, come spiegato in precedenza. Una
volta ripristinato lo stato di un FMU, da esso si può procedere con la simulazione
interrotta. Lo stato di un FMU può essere anche serializzato e copiato in un vettore
di byte. Questo permette di salvare lo stato di un FMU in un file, e permette le ini-
zializzazioni da stati stabili (nel caso di modelli in cui l’inizializzazione e dispendiosa
dal punto di vista computazionale [15]).
Altri cambiamenti in questa versione si vedono nella categorizzazione delle va-
riabili esposte. All’interno della descrizione del modello, l’attributo causality delle
variabili è stato modificato per accettare uno dei seguenti valori:
• ”parameter”: una variabile dal valore costante durante la simulazione e
indipendente.
• ”input”: come nella versione 1.0.
• ”output”: come nella versione 1.0.
• ”local”: valore calcolato da altre variabili, non utilizzato da altri modelli.
L’attributo variability delle variabili che descrive come la variabile cambia nel
tempo, in questa versione, oltre ad accettare i valori ”constant”, ”discrete” e ”con-
tinuous” come nella versione 1.0, può accettare anche altri due valori:
23

• ”fixed”: il valore della variabile è fisso dopo l’inizializzazione (come ”para-
meter” in 1.0).
• ”tunable”: il valore della variabile è costante per intervalli di tempo tra
due eventi causati esternamente al modello. Questo significa che questi valori
possono essere ”messi a punto” (tuning) durante una simulazione (vedere [15]).
Ancora sulla descrizione delle variabili, la descrizione delle dipendenze delle va-
riabili di output da quelle di input è stata modificato, rimuovendo l’elemento Direct-
Dependency dalla descrizione delle variabili, e inserendo un nuovo elemento Model-
Structure come ”figlio” dell’elemento fmiModelDescription, che è provvisto di liste
ordinate per descrivere gli input, le derivate e gli output.
La figura 2.3 mostra lo schema di descrizione del modello per la versione 2.0,
dove si notano i cambiamenti descritti sopra.
Figura 2.3: schema di descrizione in FMI 2.0
Un’altra funzionalità nuova introdotta in FMI 2.0 è quella del calcolo delle de-
rivate parziale delle variabili (di input o di stato), nonché la creazione di matrici
24

Jacobiane, che può essere utilizzata dai metodi di integrazione implicita, per la
linearizzazione del FMU, o per usarle nei filtri estesi di Kalman, per citare alcuni.
In fine, altre modifiche che meritano essere menzionate sono:
• Una gestione precisa degli eventi temporali.
• Definizione delle unità di misure migliorata.
• Rimozione dell’alias nella definizione delle variabili.
• Introduzione di un ordine per listare le variabili (input, output, stati continui),
utile per la linearizzazione degli FMU.
La versione 2.0 dello standard FMI porta novità importanti per le funzionalità
dei modelli che implementano questa interfaccia, la più importante delle quali è pro-
babilmente l’introduzione del concetto di stato interno di un FMU, e le funzionalità
per salvarlo e ripristinarlo, descritte in precedenza.
Nonostante questo, come accennato in precedenza, la versione 2.0 non è ancora
molto diffusa tra gli strumenti che implementano questo standard. Alcuni di loro
implementano solo una parte, come per esempio l’importazione o esportazione di
FMU creati con 2.0, mentre altri sono ancora in fase di implementazione di questa
versione. Oltre a questo, è da notare che i software che hanno già svolto un’imple-
mentazione completa della seconda versione, non potevano essere usati per questo
progetto di tesi, in quanto sono distribuiti con una licenza non gratuita.
La SDK distribuita dal sito ufficiale dello standard, per la 2.0 contiene gli stessi
esempi di modelli visti precedentemente (bouncingBall, inc, dq, ecc.). Questi mo-
delli però, a parte essere implementati con le funzioni definite in versione 2.0, non
contengono un’implementazione effettiva delle nuove funzionalità introdotte, e le
differenze con i modelli della versione precedente sono poche.
Per questi motivi, in questo progetto di tesi è stata sfruttata la versione FMI 1.0
con modelli creati utilizzando questa versione.
25

Capitolo 3
BPMN
3.1 Introduzione a BPMN
BPMN sta per Business Process Model and Notation, ed è uno standard utilizzato
per modellare i processi aziendali. La modellazione viene fatta tramite una de-
scrizione grafica dei processi aziendali, simile ai diagrammi di flusso, usati da anni
nell’ambito. Questa rappresentazione grafica è associata in maniera univoca a un
linguaggio standard e queste due parti insieme compongono lo standard BPMN.
Nel corso degli anni sono emerse varie notazioni per la modellazione di processi,
spesso proprietarie agli strumenti di modellazione e sistemi di gestione del workflow.
Alcuni standard affermati sono XPDL (XML Process Definition Language) e BPEL
(Business Process Execution Language).
BPMN è originariamente un progetto della Business Process Management Ini-
tiative (BPMI), un consorzio di compagnie per lo sviluppo di software pensato co-
me rappresentazione grafica di processi descritti con BPML, un altro linguaggio di
modellazione di processi che può essere eseguito da un BPMS (Business Process
Management System). I BPMS sono dei sistemi che possono controllare ed eseguire
dei processi seguendo dei modelli appropriati o descrizioni formali di questi processi.
Per quanto riguarda BPML, il suo sviluppo è stato abbandonato in favore di BPEL.
Nel 2004 fu rilasciata la prima versione di BPMN e, nel 2006, dopo che BPMI
diventò parte dell’OMG (Object Management Group), venne accettata come stan-
dard OMG. Un altro standard che fa parte di questo gruppo è il noto UML (Unified
Modeling Language). L’attuale versione, 2.0, fu rilasciata nel 2011 e segnò un grande
cambiamento per lo standard in quanto oltre agli elementi grafici definisce anche la
rappresentazione seguendo un modello semantico. Tale modello fa s`ı che gli elementi
vengano rappresentati con una struttura XML, che segue uno schema XSD definito
dalla specifica BPMN 2.0, permettendo cos`ı anche la possibilità di esecuzione (ri-
nunciando a BPML e BPEL) e di rendere possibile lo scambio di diagrammi tra
software di modellazione ed esecuzione di processi in modo formalizzato e efficiente.
26

L’obiettivo di BPMN non è solo quello di standardizzare la rappresentazione
dei processi aziendali ma anche di avvicinare molti livelli aziendali all’utilizzo dei
diagrammi per questi processi. Tradizionalmente l’utilizzo di diagrammi di processi
aziendali veniva svolto maggiormente a livello manageriale e serviva agli altri livelli
aziendali come informazione indicativa delle loro richieste, mentre con l’utilizzo di
questo standard si riduce il margine tra la descrizione dei processi aziendali e l’imple-
mentazione tecnica. In effetti la sua rappresentazione grafica con quadrati, frecce,
rombi, cerchi, ecc. mantiene la familiarità con i vecchi diagrammi di flusso usati
negli ultimi 25 anni, e dall’altro lato gli utilizzatori vengono avvicinati maggiormen-
te alla programmazione in quanto questi elementi sono interpretabili ed eseguibili.
Inoltre lo standard contiene anche operazioni di iterazione sui dati, come cicli e
verifica di condizioni, gestione di eccezioni, transazioni e altri elementi ispirati alla
programmazione.
Un’altra caratteristica importante di BPMN è che permette l’estendibilità dei
propri elementi e attributi, al patto di verificare che i nuovi modelli costruiti siano
aderenti alla specifica.
Tutte queste caratteristiche rendono lo standard BPMN uno dei principali attori
tra gli standard per la modellazione dei processi aziendali. Il numero degli strumenti
che utilizzano questo standard è sempre più grande, e una grande parte di questi
sono elencati nel sito ufficiale dello standard [16]. Inoltre il numero sempre in crescita
di siti web, blog e pubblicazioni dimostrano un continuo aumento di interesse per
questo standard [17].
Nel sito ufficiale si possono trovare anche vari esempi di diagrammi, che conten-
gono vari elementi dello standard. Nel proseguo di questo capitolo verranno descritti
e analizzati alcuni elementi principali, molti dei quali sono importanti per il progetto
di questa tesi. Questa descrizione è simile a quella svolta in [18], dove gli elemen-
ti vengono separati in due gruppi principali. Il primo gruppo, chiamato nel testo
di riferimento come primo livello, è una palette che raccoglie gli elementi che sono
sufficienti per la modellazione descrittiva dei processi. Il secondo gruppo o secondo
livello, aggiunge elementi più complessi e meno comuni al primo, completando cos`ı
l’intero standard BPMN.
3.2 Elementi di primo livello
Gli elementi di questo gruppo servono a descrivere la gran maggioranza dei processi
aziendali, a patto che essi non possiedano comportamenti dovuti ad eventi. Ad
eccezione dei flussi e degli eventi legati ai messaggi, questi elementi sono ereditati
dai tradizionali diagrammi di flusso. In seguito si descrive ciascuno degli elementi e
vengono illustrate per ciascuno immagini della rappresentazione grafica nell’editor
di BeePMN [19].
Le attività, meglio note come activity, rappresentano una unità di lavoro effettua-
to durante il processo. Esse sono visualizzate come rettangoli con vertici arrotondati.
27

Una activity può essere un task (compito) oppure un sub-process (sottoprocesso). Il
task è un elemento ”atomico”, nel senso che non possiede parti interne descrivibili e
la sua azione e lo stato finale del suo compimento vengono suggerite dal suo nome.
Un sub-process invece è un elemento composto, contenente vari elementi al proprio
interno, e viene modellato come un processo di secondo ordine, con sequenze di
esecuzione per gli elementi interni.
I task sono visualizzati come le activity ma hanno un’icona nell’angolo, che
rappresenta il tipo del task. Ci sono 8 tipi di task, ma per questo livello si definiscono
i 3 che sono:
• User task: un task che deve essere svolto da una persona (utente).
• Service task: un activity automatico, cioè l’azione viene svolta automatica-
mente quando l’esecuzione del processo (sequence flow) raggiunge questo task,
senza l’intervento dell’utente. In processi eseguibili questo task indica che il
compito viene svolto da un servizio esterno.
• Abstract task: il tipo di task non è definito.
Figura 3.1: Task del primo livello
Un sub-process ha più modi di visualizzazione. Esso può essere incapsulato
(collapsed), cioè viene visualizzato come un normale activity con un simbolo [+] nella
parte sotto centrale. In alternativa può essere espanso, cioè viene visualizzato come
un quadrato ingrandito con all’interno il diagramma di secondo ordine che descrive
il sub-process. Al momento dell’arrivo dell’esecuzione al sub-process, questa passa
allo start event del diagramma di secondo ordine, mentre al raggiungimento del
end event del sub-process, l’esecuzione prosegue fuori dall’elemento nel diagramma
principale. Gli elementi start event ed end event verranno descritti più avanti. Una
regola importante definita dallo standard è quella che nel diagramma di secondo
ordine lo start event non deve avere un tipo: l’inizio del diagramma interno al
sub-process è scatenato solo dall’arrivo dell’esecuzione.
Una variante di sub-process è quella che viene chiamata ad-hoc. La caratteristica
di questa variante di sub-process è che non tutti gli elementi interni possono essere
eseguiti seguendo un ordine per completarlo.
I sub-process sono distinti da altri chiamati call activity, che sono dei sub-process
”riusabili”, in quanto sono definiti indipendentemente dal processo, e possono essere
28

Figura 3.2: Sub-process espanso (sinistra) e incapsulato (destra)
usati anche in altri processi senza essere modificati. La visualizzazione dei call
activity è diversa dai sub-process perché è caratterizzata da un bordo più spesso del
quadrato.
Un gateway, un altro elemento del primo livello, è un elemento visualizzato come
un rombo che serve per controllare l’esecuzione dividendola in due o più cammini.
I gateway sono divisi in due categorie: esclusivi e paralleli. I gateway esclusivi, noti
anche con il nome XOR gateway, rendono possibile solo uno dei cammini per fare
proseguire l’esecuzione del processo, valutando un’espressione o condizione sui dati
del processo. Un gateway di questo tipo viene contraddistinto da una ’X’ all’interno
del rombo, ma può anche essere visualizzato con nessun simbolo. I gateway paralleli
invece separano l’esecuzione in entrata dell’elemento in più esecuzioni che devono
essere eseguite in parallelo senza restrizioni di condizioni, e sono contraddistinti da
un simbolo ’+’ dentro il rombo.
Figura 3.3: Gateway di primo livello
Altro caso di utilizzo per i gateway è quando abbiamo più flussi di esecuzione in
entrata, e solo un flusso in uscita. In tal caso il gateway esclusivo accetta soltanto il
primo flusso ad arrivare per ciascuna esecuzione, ignorando i restanti flussi per quella
esecuzione, che potrebbero giungere in seguito. Dall’altro lato, il gateway parallelo
in questo caso aspetta finché tutti i flussi in entrata siano arrivati al gateway prima
di permettere al flusso in uscita di proseguire l’esecuzione. In questo caso il gateway
parallelo ha il ruolo di sincronizzare i flussi che di solito sono stati separati da un
altro gateway parallelo precedentemente.
29

Lo start event è visualizzato come un cerchio con bordo sottile, ed è un altro
elemento del primo livello. Un processo deve avere almeno un start event, che
è l’elemento dove l’esecuzione ha inizio. L’icona all’interno del cerchio, chiamata
trigger, indica il tipo di evento che scatena l’inizio dell’esecuzione di un processo.
Il trigger può essere di tipo message, in cui l’inizio avviene dopo il ricevimento di
un messaggio, di tipo timer, cioè un evento temporaneo, di tipo multiple, in cui
l’inizio avviene via molteplici tipi di eventi, e ultimo, di tipo none, cioè di tipo
non specificato o se l’inizio avviene manualmente da un task. Come spiegato in
precedenza, i sub-process devono possedere un start event di tipo none.
Figura 3.4: Alcuni start event e end event di primo livello
Analogamente agli start event, si hanno gli end event, che indicano la fine di un
cammino nei processi e sottoprocessi. Gli end event sono visualizzati nei diagrammi
come cerchi con un bordo più spesso. L’icona all’interno del cerchio negli end event,
indica il tipo di segnale lanciato alla fine del cammino. In questo primo livello
abbiamo quattro tipi: none, message, terminate, multiple. Il none end event non
lancia nessun segnale come risultato, gli end event di tipo message lanciano un
messaggio, gli end event di tipo multiple possono lanciare più di un segnale (ad
esempio due messaggi diversi) come risultato finale, e in fine l’end event di tipo
terminate indica che il processo oppure il sottoprocesso che arriva a questo elemento
termina immediatamente, anche se contiene cammini paralleli ancora in esecuzione.
Lo sequence flow, una freccia continua nei diagrammi, rappresenta il flusso di
esecuzione dei processi. Una sequenza di linee di flusso è confinata a stare all’interno
di un ordine di processo, perciò non può oltrepassare i bordi di un sub-process o di
un process pool (la descrizione dei pool viene fatta in seguito).
I message flow, dall’altro canto, sono delle linee tratteggiate che rappresentano
un flusso di messaggi all’interno di un processo. Essi possono collegare qualsiasi tipo
di activity, message event, o black-box pool. Inoltre, gli elementi connessi da queste
linee possono appartenere a processi diversi.
Un pool (piscina), è un rettangolo di solito allungato in orizzontale ma che può
essere disegnato anche verticalmente, che serve come contenitore di processo, cioè
30

contiene al proprio interno tutti gli elementi che compongono il processo, collegati
dalle sequence flow. Se visualizzato in orizzontale il pool contiene un’etichetta nella
parte sinistra la quale è il proprio nome identificativo (nella visualizzazione verticale
l’etichetta si trova in alto). I pool possono anche non visualizzare gli elementi al
proprio interno ma renderli impliciti. In questo caso vengono chiamati black-box
pool, cioè sono come delle scatole nere, e servono nei diagrammi con più processi
(pool) per descrivere la collaborazione tra questi. Tale collaborazione avviene grazie
ai flussi di messaggi scambiati tra i processi.
Opzionalmente i pool possono essere suddivisi in quelli che vengono chiamati lane
o piste, che servono per associare alcune attività dei processi a determinati attori,
ruoli, dipartimenti, o qualsiasi tipo di categorizzazione che gli si vuole attribuire.
I pool e lane sono concetti ereditati dai tradizionali diagrammi di flusso.
Le text annotations (annotazioni testuali) sono utilizzati nei diagrammi come
informazione aggiuntiva testuale per gli elementi. Essi infatti non possono essere
non collegati ad un elemento preciso del diagramma, e questo collegamento viene
fatto tramite le associations (associazioni), le quali sono visualizzati come una linea
di puntini equidistanti. Le text annotations e le associations sono degli artifacts,
elementi di informazione aggiuntiva che non influiscono l’esecuzione del processo.
Figura 3.5: Data object e data store
Gli ultimi elementi descritti in questo paragrafo e quindi appartenenti al primo
livello, sono quelli per la descrizione dei dati e del loro flusso (data flow). Prima della
versione 2.0 di BPMN, essi facevano parte degli artifacts, mentre in questa versione
essi sono definiti come elementi, di nome data object e data store. Il data object rap-
presenta una variabile locale del processo, temporanea in quanto esiste solo durante
l’esecuzione del processo. La sua visualizzazione è simile a un foglio con un angolo
piegato, come comunemente vengono visualizzati anche i file. Il data store dall’altro
lato, rappresenta dati persistenti, informazioni che comunemente vengono disposte
nei database. In effetti la sua visualizzazione è quella che tradizionalmente viene
associata ai database. Questi elementi devono essere legati grazie alle associations
a degli elementi, come ad esempio attività, eventi, sequence flow, message flow, ecc.
31

3.3 Elementi di secondo livello
In questa sezione vengono descritti gli elementi dello standard BPMN, aggiuntivi a
quelli descritti nella sezione precedente. Comunque per la semplicità del documento
vengono descritti solo quelli utilizzati nel progetto di tesi.
Come prima cosa si nota che il secondo livello si focalizza maggiormente sul
completamento della sottoclasse degli eventi. Nel primo livello si nota come il flusso
di esecuzione procede con il completamento delle attività in modo sequenziale, e gli
eventi definiscono solo l’inizio e la fine dell’esecuzione. Nel secondo livello vengono
introdotti, oltre a tipi aggiuntivi per start event ed end event, gli eventi intermedi
che permettono altri tipi di comportamenti all’esecuzione di un processo.
Figura 3.6: Eventi intermedi di secondo livello
Gli eventi intermedi sono visualizzati come cerchi con un doppio bordo, e come
per gli altri eventi visti, il simbolo all’interno indica il tipo di trigger dell’evento.
Alcuni tipi di trigger introdotti con questo secondo livello sono:
• Timer, dovuto a una durata temporale.
• Signal, dovuto a un segnale. Un segnale differisce da un messaggio in quanto
viene lanciato per tutto il processo (broadcast), mentre il messaggio ha un
destinatario specificato.
• Conditional, dovuto al cambiamento di condizioni su alcuni dati (si effettua
un monitoraggio continuo di questi dati).
• Error, dovuto a un errore nell’esecuzione.
Figura 3.7: Categorie degli eventi intermedi
Gli eventi intermedi sono divisi in quattro categorie principali: catching, thro-
wing, boundary interrupting e boundary non-interrupting. I throwing intermediate
32

event (caratterizzati da un’icona scura), sono quelli che fanno innescare un deter-
minato evento, mentre i catching intermediate event sono quelli in cui l’esecuzione
prosegue in seguito (che ”catturano” l’esecuzione). I boundary sono eventi assegnati
all’esecuzione di un sub-process o task (sono disegnati sul bordo di questi elementi),
e possono interrompere o meno la loro esecuzione per innescare un evento.
In questo livello viene definito anche un nuovo tipo per i gateway, l’event gateway.
Questo gateway è visualizzato con un rombo con all’interno un multiple intermediate
event. La scelta del percorso viene fatta in base al tipo di evento che il gateway
cattura, ed è una regola BPMN che ogni percorso uscente dal gateway deve terminare
in un intermediate catching event.
Figura 3.8: L’event gateway di secondo livello
Per quanto riguarda i tipi di task, alcuni nuovi per questo livello sono:
• Send task: quasi identico come funzione all’intermediate message throwing
event, in quanto manda un messaggio ad un destinatario.
• Receive task: serve per ricevere un messaggio, come message catching event.
• Script task: simile al service task, ma in questo caso, nei processi eseguibili,
questo task contiene un piccolo programma, di linguaggio Javascript o Groovy,
contenuto all’interno del XML e che deve essere eseguito dal motore.
Figura 3.9: Task di secondo livello
Sempre sulle activity, questo livello introduce dei modi offerti da BPMN per non
farle completare fino a che non vengono eseguite un certo numero di volte. Il primo,
loop activity, imita il ciclo do-while della programmazione, cioè fa ripetere l’attività
in continuo fin quando non si raggiunge una determinata condizione. Il secondo,
33

multi-instance activity, è il ciclo for-each, il quale determina il numero totale di
volte da fare eseguire l’attività. Similmente a questo secondo modo, la multiple pool
offre la possibilità di eseguire più processi in parallelo.
34

Capitolo 4
Utilizzo di BPMN 2.0 per la
Co-simulazione
Come spiegato nell’introduzione di questo documento, l’obiettivo di questo progetto
di tesi è stato quello di riuscire a usare lo standard BPMN nella costruzione di pro-
cessi che riescano ad orchestrare modelli creati con l’interfaccia FMI in un ambiente
di co-simulazione.
Nei precedenti capitoli sono stati descritti i due standard principali di questo
progetto di tesi: FMI e BPMN. Bisogna notare come questi standard appartengono
ad ambiti molto diversi. Il primo è pensato come standard per la creazione di modelli
e la loro simulazione, principalmente nell’ambito ingegneristico, e maggiormente
in quello automobilistico. Il secondo invece è stato pensato come uno strumento
per offrire una rappresentazione semplice e univoca dei processi aziendali, legati
maggiormente al mondo del business e manageriale. Questi standard non sono stati
definiti per essere usati insieme e collaborare direttamente per raggiungere l’obiettivo
spiegato sopra. In effetti, in una prima fase di analisi non sono stati trovati lavori
precedenti che cercassero di utilizzare insieme questi due standard.
4.1 Analisi di progetto
Molti strumenti che eseguono simulazioni di modelli, necessitano di uno schema
grafico in input che rappresenta le connessioni tra i modelli, e che di solito viene
costruito o modificato dall’utente. Ma la parte principale per eseguire la simulazione
è l’algoritmo master che gestisce la simulazione dei modelli e che coordina le loro
interazioni, lo scambio di dati e la gestione delle eccezioni. Gli algoritmi del master
di solito sono proprietari e vengono nascosti all’utente. Come spiegato in preceden-
za, lo standard FMI non definisce come costruire un algoritmo master, ma lascia
agli strumenti che implementano lo standard ad applicare i propri algoritmi. Nella
specifica dello standard [4] viene mostrato solo un esempio in forma di pseudoco-
35

dice per descrivere un possibile algoritmo per il coordinamento di modelli durante
la computazione.
Il progetto di questa tesi parte dall’idea di utilizzare BPMN per trasformare
il pseudocodice di quest’algoritmo master in un diagramma di processo BPMN.
L’idea è nata all’interno del gruppo di ricerca di ESTECO, in una collaborazione
che include l’autore di questo documento, per un articolo già accettato che verrà
presentato nella 2016 IEEE International Symposium on Systems Engineering (IS-
SE) [20]. Questo lavoro cerca di esplorare le potenzialità di BPMN, per sfruttarle
nella rappresentazione grafica integrale dello schema delle connessioni fra modelli,
come anche appunto nella costruzione di processi per la gestione dell’orchestrazione
dei modelli, che è il focus del progetto di tesi. Una versione integrale dell’articolo si
trova nell’appendice di questo documento.
Nelle prossime sezioni di questo capitolo si descrive la fase di analisi del proget-
to di tesi. Nella sezione 4.2 viene descritto in dettaglio il diagramma concettuale
creato basandosi sull’algoritmo master in pseudocodice della specifica FMI. Tale
diagramma è una rappresentazione solo visuale di quello che sarà alla fine il dia-
gramma BPMN per la co-simulazione. Per realizzare un diagramma eseguibile è
stato prima scelto e analizzato un framework capace di interpretare ed eseguire gli
elementi BPMN. Questo framework viene trattato nella sezione 4.3 di questo capi-
tolo, analizzando alcune differenze importanti rispetto allo standard BPMN nella
implementazione degli elementi. Inoltre, in tale sezione vengono presentati anche
uno strumento che aiuta la costruzione di diagrammi eseguibili dal framework e una
libreria che permette l’esecuzione di modelli FMU all’interno di tale framework.
La fase di realizzazione del diagramma eseguibile viene esposta nel capitolo 5, in
cui viene descritto inizialmente la costruzione di un diagramma per la simulazione
di un unico modello e in seguito la costruzione di un diagramma generico per la
simulazione di numerosi modelli. Oltre a questo per l’esecuzione dei modelli FMU
è stato necessario realizzare un servizio servlet e un’interfaccia utente che permette
la configurazione della simulazione in modo semplificato, anche queste trattate nel
prossimo capitolo.
4.2 Diagramma BPMN di co-simulazione
In questo paragrafo si analizza lo schema BPMN concettuale costruito per l’orche-
strazione dell’intera simulazione di due FMU, come succede anche nell’algoritmo
della specifica FMI su cui si basa questo diagramma. Questi FMU sono connessi
come nell’esempio presentato in [1], cioè sono due integratori interconnessi in uno
schema di retroazione, e ad ogni iterazione della simulazione si effettua uno scambio
di dati tra i due.
In figura 4.1 si presenta l’intero diagramma BPMN per la simulazione. Nel
diagramma i pool che rappresentano i due processi slave sono mostrati come black-
box pool, e si può notare che la visualizzazione della collaborazione tra i processi
36

Figura 4.1: Diagramma BPMN di collaborazione tra processo Master e processi
Slave
slave e il processo master viene fatta in modo esplicito mostrando lo scambio dei
messaggi. Nel processo master si nota come l’esecuzione passa sequenzialmente per
quattro fasi diverse, rappresentate dai rispettivi sub-process visualizzati in modo
incapsulato. Queste fasi corrispondono a quelle descritte nel secondo capitolo, sulla
parte della co-simulazione, e sono:
• Instantiation: avvio dei processi slave con rispettivo caricamento degli FMU.
• Initialization: fase di inizializzazione dei modelli.
• Simulation: esecuzione della simulazione con l’iterazione nel tempo.
• Shutdown: fase di terminazione e de-allocazione dalla memoria degli FMU.
I sub-process mandano messaggi ai processi slave che a loro volta eseguono le
funzioni dell’interfaccia FMI e ottengono da esse i risultati che passano in seguito
al processo master. La figura 4.2 illustra il diagramma BPMN per i processi slave.
Il processo slave ha come inizio un message start event, il che significa che co-
mincia la sua esecuzione solo dopo aver ricevuto un messaggio dal processo master.
La maggior parte dei service task usati sono dei richiami alle funzioni principali
dell’interfaccia FMI viste nel capitolo 2, e quindi verranno usati per eseguire quelle
funzioni. Da notare che l’esecuzione dell’intermediate throwing message event in
seguito all’esecuzione del task Initialize porta ad un event gateway. Il compito di
tale gateway, come descritto nel capitolo 3, è quello di assegnare l’esecuzione a uno
dei quattro eventi successivi. Questo dovuto dal fatto che i task getReal, setReal e
doStep sono eseguiti per tutte le iterazioni. Lo scambio di dati tra i processi master
e slave viene fatto grazie al passaggio dei data object.
37

Figura 4.2: Diagramma BPMN del processo Slave
Nella figura 4.3 si vede in maggior dettaglio il sub-process Simulation del dia-
gramma della figura 4.1, il quale è il più interessante dei quattro, visto che è quel-
lo che gestisce l’orchestrazione degli FMU, stabilendo l’ordine di esecuzione e lo
scambio dei dati.
Figura 4.3: Espansione del sub-process Simulation
38

In questa figura, il gateway che segue lo start event fa un controllo sui dati tc,
tStop e Status, che sono delle variabili del processo che rappresentano rispettiva-
mente un determinato tempo della simulazione, il tempo di fine esecuzione, e lo
stato generale di questa. Come si può notare, questo sub-process contiene tre parti
principali che corrispondono alle funzionalità di getter, setter e doStep viste nella
sezione 2.2.2 e ciascuna di queste viene svolta per entrambi gli FMU. Si ricorda
che le getter servono per ottenere i valori di interesse per la simulazione da delle
determinate variabili, al contrario dei setter che assegnano dei nuovi valori per le
variabili input degli FMU. La funzione doStep esegue i calcoli corrispondenti a un
determinato step h.
In queste figure si può notare che vengono usate solo le funzioni getReal e SetReal,
e vengono omessi i getter e setter per gli altri tipi di dati per mantenere semplice la
visualizzazione dei diagrammi.
Importante ripetere che questo diagramma rispecchia l’algoritmo master in forma
di pseudocodice proposto dalla specifica FMI, ma niente vieta ad avere diagrammi
BPMN che siano diversi da questo, per simulare degli FMU. In effetti, non si può
avere un diagramma BPMN general-purpose capace di effettuare tutti i tipi di si-
mulazioni. Oltre a questo per ciascun algoritmo master potrebbero corrispondere
più diagrammi diversi. Ma questo è un ulteriore vantaggio che BPMN dispone ver-
so altri strumenti di simulazione, in quanto offre agli utenti maggiore facilità nella
scelta e costruzione degli algoritmi.
4.3 Esecuzione con BPMN Engine
Nella sezione precedente è stata presentata una prima fase concettuale del progetto
ed è stata analizzata la rappresentazione grafica dell’esecuzione dei modelli con pro-
cessi BPMN, con la conseguente creazione del diagramma dei processi. In questa
sezione invece si presentano i dettagli legati all’analisi dell’esecuzione effettiva del
diagramma. Come descritto precedentemente, la rappresentazione visuale dei dia-
grammi BPMN è corrisposta univocamente da una rappresentazione in linguaggio
XML. Questo ha dato a molteplici strumenti la possibilità di interpretare univo-
camente questo linguaggio, in modo da interpretare ed eseguire automaticamente
ciascun elemento BPMN, e di conseguenza eseguire processi interi. Questi strumenti
sono meglio noti con il nome di BPMN Engine (motori di esecuzione).
Tra molti BPMN engine che sono in circolazione, la scelta per il progetto di
questa tesi è ricaduta su Alfresco Activiti [21]. Alfresco Activiti è un framework
che comprende più strumenti, tra cui l’engine, e nella prossima sottosezione si
presenteranno le sue caratteristiche che sono di interesse per il progetto.
39

4.3.1 Activiti
Lo sviluppo di Activiti ha inizio nel 2010 come proseguo di jBPM [22] da due dei
principali sviluppatori di quest’ultimo, al momento del passaggio presso l’azienda
Alfresco [23]. In effetti, la prima versione rilasciata di Activiti fu la 5.0, per indicare
la continuazione da jBPM 4.
Per il progetto di questa tesi viene usata la distribuzione Activiti Community
che contiene i seguenti strumenti:
• Engine: il motore di esecuzione di workflow BPMN.
• Explorer: un’applicazione web che permette di fare deploy di processi, ini-
ziare la loro esecuzione, osservare l’andamento delle esecuzioni, e altro ancora.
• Modeler: un’applicazione web per la creazione grafica di workflow.
In alternativa al Modeler, per la creazione di diagrammi BPMN è stato usato un
plug-in per l’IDE Eclipse [24], Activiti Designer, il quale verrà trattato nel seguito
di questo capitolo.
Activiti Engine è il nucleo di questa piattaforma, ed è un motore di esecuzione
in linguaggio Java. Questo motore è composto dal Process engine, che gestisce i
processi e mette a disposizione vari servizi utili, e un altro motore che implementa
la specifica BPMN 2.0 e fornisce un’interfaccia per permettere l’interazione con i
servizi dell’engine [25].
Activiti Explorer è un’applicazione web eseguibile su qualsiasi web server (ad
es. Apache Tomcat), che tra varie funzionalità permette all’utente di caricare i
propri processi BPMN all’interno, per poi eseguirli e monitorarne l’andamento. Esso
contiene anche un database configurabile dall’utente, in cui vengono salvati dati
legati alle esecuzioni, agli utenti che utilizzano l’applicazione, dati storici, ecc. In
fine oltre alla visualizzazione grafica degli errori, vengono mantenuti anche dei file
di log per molti tipi di informazioni, aspetti questi che sono molto utili allo sviluppo
di processi eseguibili BPMN.
Activiti Designer (Eclipse)
Activiti Designer, il plug-in di Eclipse, offre la possibilità di creare facilmente dia-
grammi BPMN, utilizzando la propria palette degli elementi di tale standard. Pur-
troppo, rispetto allo standard, la palette presenta un numero inferiore di elementi,
e ci sono alcune caratteristiche che sono diverse dalle definizioni in BPMN. Questo
si rispecchia anche nel motore di esecuzione di Activiti, nel quale non sono state
implementate molte funzionalità legate ad alcuni elementi, o addirittura non sono
inclusi altri elementi per intero. Oltre alla creazione e modifica grafica dei diagram-
mi, Activiti Designer offre anche la possibilità di accedere alla rappresentazione
XML. Questo è risultato molto utile durante il lavoro per il progetto di tesi, in
quanto il plug-in ha mostrato comportamenti errati (ad es. non visualizzazione di
40

Utilizzo dei processi aziendali per la co simulazione di modelli dinamici

Utilizzo dei processi aziendali per la co simulazione di modelli dinamici

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (13)

Similar to Utilizzo dei processi aziendali per la co simulazione di modelli dinamici

Similar to Utilizzo dei processi aziendali per la co simulazione di modelli dinamici (20)

Utilizzo dei processi aziendali per la co simulazione di modelli dinamici