Scuola di Scienze Matematiche, Fisiche e Naturali Tesi di...

Scuola di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea in Informatica

Tesi di Laurea

S I M U L A Z I O N E F E D E R ATA :C A R AT T E R I S T I C H E P R I N C I PA L I ,

S TA N D A R D D I S P O N I B I L I , C A S I D I S T U D I O .

F E D E R AT E D S I M U L AT I O N : M A I NF E AT U R E S , AVA I L A B L E S TA N D A R D , S T U D Y

C A S E S .

lamberto pauletti

Relatore: Paolo Lollini

Anno Accademico 2016-2017

Lamberto Pauletti: Simulazione federata: caratteristiche principali, standarddisponibili, casi di studio., Corso di Laurea in Informatica, © Anno Accade-mico 2016-2017

I N D I C E

0.1 Prefazione 71 Panoramica sui sistemi e la simulazione 9

1.1 I sistemi ed i Systems-of-Systems 91.2 La simulazione 11

2 Simulazione di un sistema 132.1 Principali scopi della simulazione 132.2 Vantaggi e svantaggi della simulazione 142.3 Tipologie di simulazione 152.4 Progettazione e studio di una simulazione 162.5 Modelli di simulazione 172.6 Esempio di un simulatore 20

2.6.1 Tipologia di simulazione 212.6.2 Modello di simulazione 212.6.3 Esecuzione della simulazione 22

3 Simulazione federata 253.1 Panoramica sulla simulazione federata 253.2 Vantaggi della simulazione federata 263.3 Esecuzione e sviluppo di una simulazione federata 263.4 Problematiche della simulazione federata 28

3.4.1 Interoperabilità e connessione 293.4.2 Sincronizzazione temporale 31

4 Standard per la simulazione federata 354.1 Standard come soluzione ai problemi 354.2 Distributed Interactive Simulation 364.3 High Level Architecture 374.4 Caratteristiche generali 384.5 Infrastructure RTI 404.6 Modello ad oggetti 43

5 Applicazioni dello standard HLA 455.1 Concetti generali 455.2 Simulazione risposta ai disastri 46

5.2.1 Caratteristiche generali 465.2.2 Federati coinvolti 465.2.3 Modello ad oggetti 485.2.4 Funzionamento della simulazione 49

1

2 Indice

5.3 Simulazione collisioni orbitali 505.3.1 Caratteristiche generali 505.3.2 Federati coinvolti 505.3.3 Modello ad oggetti 525.3.4 Funzionamento della simulazione 53

5.4 Simulazione di sistema missilistico aria-aria 545.4.1 Caratteristiche generali 545.4.2 Federati coinvolti 555.4.3 Modello ad oggetti 565.4.4 Funzionamento della simulazione 57

6 Integrazione di un simulatore in una federazione 596.1 Adattare il simulatore allo standard HLA 596.2 Caratteristiche dell’RTI 62

6.2.1 Software dell’RTI 626.2.2 Sincronizzazione temporale 63

6.3 Inizializzazione della federazione 646.4 Connessione alle classi del FOM 64

6.4.1 Inviare e ricevere interazioni 656.4.2 Registrare e scoprire oggetti 676.4.3 Aggiornare e riflettere gli attributi 68

6.5 Abbandono e chiusura della federazione 717 Simulazione di Systems-of-Systems: caso di studio 73

7.1 Il simulatore di SoS 737.1.1 Google Blockly4SoS 737.1.2 Il simulatore in Python 767.1.3 Struttura e componenti del simulatore 77

7.2 Caso di studio: il Football Simulator 787.2.1 Obiettivi 797.2.2 Modifiche strutturali principali 807.2.3 Struttura del modulo HLA 827.2.4 L’esecuzione della simulazione 86

7.3 Conclusioni e sviluppi futuri 887.3.1 Conclusioni 887.3.2 Sviluppi futuri 88

E L E N C O D E L L E F I G U R E

Figura 1 Interdipendenze tra le varie infrastrutture. 11Figura 2 Grafo degli eventi. 23Figura 3 Simulazione parallela e distribuita. 28Figura 4 Accoppiamento centrale, tutti i simulatori sono con-

nessi ad un canale comune. 30Figura 5 Accoppiamento laterale, sono creati dei canali di

comunicazione tra ogni coppia di simulatori. 30Figura 6 Mancata sincronizzazione temporale tra due simu-

latori. 33Figura 7 Struttura del framework HLA. 40Figura 8 Rappresentazione dei diversi federati in comunica-

zione con L’RTI. 48Figura 9 Rappresentazione dei diversi federati in comunica-

zione con L’RTI. 51Figura 10 Rappresentazione dei diversi federati in comunica-

zione con L’RTI. Ognuno dei due velivoli è simulatodall’insieme dei tre federati che ne riproducono ilcomportamento. 56

Figura 11 Elementi principali di una simulazione federata conl’HLA. 60

Figura 12 Connessione della simulazione con l’RTI attraversoil modulo HLA. 61

Figura 13 Meccanismo di comunicazione tra federati e RTI. 63Figura 14 Processo di creazione e test del simulatore di SoS. 74Figura 15 Google Blockly4SoS, blocco del SoS del Football

Simulator. 75Figura 16 Struttura del Football Simulator con l’integrazione

del modulo HLA. 81

3

"A mia zia Tamara"

0.1 prefazione 7

0.1 prefazione

In ambito informatico la simulazione è l’imitazione delle operazionieseguite nel tempo da un sistema o da processo reale[4]. Grazie aisimulatori è possibile analizzare le prestazioni ed il comportamento deisistemi. Esistono vari ambiti in cui è possibile sfruttare la simulazione adesempio nei servizi di trasporto, in campo militare, nella produzioneindustriale e nell’automazione. Ci sono anche metodi alternativi divalutazione di un sistema, uno dei più noti oltre al primo citato è lamodellazione analitica. Mettendo a confronto i vari metodi, lasimulazione di un sistema risulta la più idonea per l’analisi di sistemicomplessi. L’informatizzazione oggi è arrivata ad inserirsi in una sempremaggiore varietà di sistemi. A questo punto è necessario mettere i varisistemi in comunicazione tra loro affinché siano forniti nuovi servizi efunzionalità. Per poter riprodurre il comportamento di questi sistemi ènecessario interconnettere più simulatori all’interno di un unicasimulazione. Questa particolare tecnica di simulazione è chiamatasimulazione federata ed è il principale argomento della tesi. I principalicontributi di questo lavoro per la tematica trattata sono i seguenti:

• Approfondimento degli aspetti principali legati alla simulazione diun sistema e soprattutto alla simulazione federata.

• Analisi dello standard High Level Archietecture (HLA), propostocome soluzione alle maggiori problematiche della simulazionefederata.

• Presentazione di alcuni casi di studio già esistenti, che sfruttanoHLA per implementare delle simulazioni federate.

• Approfondimento sui passi principali per rendere un simulatoreconforme allo standard HLA.

• Applicazione delle conoscenze acquisite su un reale caso di studio,effettuando i primi passi per rendere un simulatore diSystems-of-Systems conforme allo standard High LevelArchitecture.

All’interno di questo lavoro gli argomenti sopra indicati sono cosìstrutturati:

• Capitolo 1: in questo capitolo sono introdotti i concetti principalidi sistema e di simulazione.

8 Elenco delle figure

• Capitolo 2: all’interno di questo capitolo sono illustrati gli aspettipiù importanti della simulazione di un sistema. Nella parte finaleviene presentato un semplice esempio di simulatore, con lo scopodi mostrare concretamente gli aspetti più importanti dellasimulazione.

• Capitolo 3: in questo capitolo si trattano i punti fondamentali dellasimulazione federata. Sono analizzati i vantaggi, i metodi diesecuzione e sviluppo e soprattutto le problematiche legate allaconnessione ed alla sincronizzazione di più simulatori.

• Capitolo 4: in questo capitolo sono discussi gli aspetti principali ele caratteristiche più rilevanti dello standard per la simulazionefederata: High Level Architecture (HLA).

• Capitolo 5: all’interno di tale capitolo sono illustrate delle realisimulazioni federate con HLA, mostrando differenti tipologie disimulazioni interconnesse grazie a questo standard. L’analisi diquesti esempi concreti permette di comprendere meglio ed inmaniera più diretta le caratteristiche e le particolarità dellostandard HLA.

• Capitolo 6: in questo capitolo è descritta la metodologia con cuipoter adattare un simulatore allo standard HLA. Nella prima partesono presenti dei concetti più generali, riprendendo anche ciò che èstato esposto nel capitolo quarto. Nella seconda parte sonoarticolati e studiati i procedimenti per: inserire il federatoall’interno della federazione, permettere al federato di scambiaredati con l’esterno ed infine terminare la comunicazione.

• Capitolo 7: nel capitolo finale è presentato un caso di studio il cuiobiettivo è quello di adattare allo standard HLA un simulatore diSystem-of-Systems il cui codice sorgente è generato tramitel’applicazione Google Blockly4SoS. Sono ripresi molti aspettimostrati nel capitolo precedente ed applicati alla struttura di unospecifico simulatore. L’idea alla base di questo progetto è quella direndere il simulatore in questione conforme allo standard HLA,cercando di applicare modifiche che siano il meno invasivepossibile. In questo modo si cerca sia di fornire al simulatore unmeccanismo che gli permetta di inviare e ricevere dati dall’esterno,sia di alterare il meno possibile il comportamento e la strutturaoriginale.

1PA N O R A M I C A S U I S I S T E M I E L A S I M U L A Z I O N E

In questo capitolo vi è una panoramica generale sui sistemi ed i Systems-of-Systems per introdurre i concetti della simulazione.Nella sezione 1.1 sono presentate le nozioni principali di sistema e diSystems-of-Systems(SoS), proponendo anche un semplice esempio disimulatore di SoS. Successivamente sono introdotti gli aspetti principalidella simulazione di sistemi e di SoS (sezione 1.2).

1.1 i sistemi ed i systems-of-systems

Un sistema è definito come un insieme di oggetti che si scambiano intera-zioni e sono interdipendenti, con lo scopo di raggiungere un obiettivo[1].Il concetto di sistema è relativo, infatti esso è classificato e riconosciutosecondo la sua natura e comportamento: in informatica è considerato uninsieme di elaboratori o dispositivi elettronici interconnessi e predispostiper fornire funzionalità e servizi di elaborazione agli utenti.Negli ultimi decenni il mondo ha assistito ad una massiccia digitalizza-zione delle infrastrutture e dei servizi grazie allo sviluppo dei sistemiinformatici. In molti domini come: difesa, produzione energetica, traspor-ti, industria e tanti altri, vi è la necessità di creare nuovi e più complessisistemi, interconnettendo quelli già esistenti. Ad oggi, grazie anche alprogresso ed all’ampliamento della rete e delle nuove tecnologie di comu-nicazione, questo è attuabile. Una composizione di un insieme di sistemiautonomi ed indipendenti, che fornisce nuovi servizi agli utilizzatori, èchiamata Systems-of-Systems (SoS)[3]. Con i systems-of-systems è possi-bile integrare in un unico sistema, più sistemi eterogenei e che operanoanche in ambienti completamente diversi, chiamati Constituent Systems(CS). I SoS forniscono una visione generale e la possibilità di gestire edanalizzare una rete di sistemi in cui questi agiscono e si influenzanoreciprocamente. Una caratteristica dei moderni systems-of-systems è lacomplessità: è stato raggiunto un livello strutturale e comportamentale

9

10 panoramica sui sistemi e la simulazione

che rende molto complicato il funzionamento di essi. Infatti con l’informa-tizzazione di sempre più sistemi ed infrastrutture, cresce ed evolve ancheil livello di articolazione dei systems-of-systems. Tuttora, la disponibilitàe l’affidabilità di questi sono caratteristiche sempre più necessarie per lasocietà moderna.I campi di applicazione dei systems-of-systems sono molteplici. Un casoparticolare che mette in risalto le caratteristiche e funzionalità di unsimulatore per SoS, si ha nelle infrastrutture civili di un territorio[6]. Alfine di gestire ed organizzare i principali servizi che devono essere fornitiad una popolazione, sono presenti sistemi informatici che regolano:

• Gestione dell’energia.

• Distribuzione dell’acqua.

• Trasporti.

• Telecomunicazioni.

• Servizi di emergenza.

Per poter analizzare le interdipendenze tra questi sistemi è possibile sfrut-tare una simulazione di un SoS, che mette in relazione i punti in comunealle infrastrutture, come illustrato nella Figura 1. Tale sistema si rivelaparticolarmente utile per studiare gli effetti che uno scenario catastrofico,ad esempio una calamità naturale, potrebbe portare al territorio. Infatti,eventuali disagi e malfunzionamenti provocati ad uno dei sistemi pos-sono ripercuotersi sugli altri. Due infrastrutture si dicono dipendenti seuna perdita o una riduzione di qualità di un servizio in una può portareun degrado di un servizio in un altra. Avere a disposizione un sistemache rappresenta un modello di tutte queste infrastrutture e ne mette inrisalto le vulnerabilità, può essere utile per migliorare l’organizzazionedi queste soprattutto nelle situazioni critiche.

1.2 la simulazione 11

Figura 1: Interdipendenze tra le varie infrastrutture.

1.2 la simulazione

Con il termine simulazione si intende la riproduzione del comporta-mento di un sistema[4]. Questa tecnica include la generazione di unastoria artificiale del sistema e, con l’osservazione di essa, è possibileanalizzare e stimare le sue caratteristiche operative[1]. Il comportamentodel sistema e la sua evoluzione nel tempo sono studiate sviluppandoun modello di simulazione; questo permette di descrivere le operazionidi un sistema e come esse devono essere simulate[4]. In alcuni casi, èpossibile sviluppare un modello che sia abbastanza semplice da essererisolto con dei metodi matematici; questi prevedono: calcolo differenziale,teoria delle probabilità, metodi algebrici ed altre tecniche matematiche.Tuttavia molti sistemi reali sono così complessi che i loro modelli nonsono risolvibili matematicamente: in questi casi è appropriato l’utilizzodi una simulazione computerizzata per riprodurre il modello di simula-zione del sistema in esame; questo tipo di strategia con le sue principalicaratteristiche è analizzato nel capitolo successivo. Parallelamente allacrescita e lo sviluppo dei systems-of-systems, aumenta anche la necessità

12 panoramica sui sistemi e la simulazione

di analizzarne il comportamento. Infatti, grazie alle tecniche di simulazio-ne federata, più complesse rispetto a quelle di simulazione di un unicosistema, è possibile simulare la maniera in cui più sistemi interconnessie che si influenzano reciprocamente operano. Tuttavia, questo tipo ditecnica, richiede una maggiore attenzione, rispetto alla simulazione di unsingolo sistema, vista la complessità strutturale dei sistemi considerati.Per realizzare una simulazione di un sistema del genere, devono ancheessere considerati i seguenti aspetti[12]:

• EterogeneitàQuesta particolare simulazione, deve supportare più simulazioniconcorrenti di sistemi eterogenei e che operano talvolta in scenari esu dati profondamente diversi.

• SincronizzazioneVi è la necessità di gestire e sincronizzare temporalmente tuttigli eventi provenienti dai differenti simulatori. Infatti i simulatoriagiscono in base al tipo di sistemi riprodotti, che possono lavorarea tempi e frequenze molto diversi tra loro.

• OverheadDurante la simulazione vengono scambiati molti messaggi ed even-ti tra i simulatori. Il tempo impiegato per inviare ed attenderemessaggi è tempo di overhead. Maggiore è il numero di messaggiscambiati, maggiore è il tempo necessario alla sincronizzazione.

• ScalabilitàNel caso in cui il sistema da simulare sia spesso soggetto ad ag-giunte e rimozioni di elementi, è necessario che il modello simulatosupporti e semplifichi queste operazioni.

Le tecniche e gli aspetti implementativi di una simulazione di questo tiposaranno analizzati nei capitoli successivi.

2S I M U L A Z I O N E D I U N S I S T E M A

In questo capitolo viene presentata una descrizione più in dettagliosui sistemi e soprattutto sulla loro simulazione, concludendo con unsemplice esempio di un simulatore. Nelle prime due sezioni (2.1 e 2.2)sono presentati gli scopi, i vantaggi e gli svantaggi della simulazionedi un sistema. Successivamente sono illustrate le diverse tipologie disimulazione di un sistema dinamico. In seguito, all’interno della sezione2.4 vengono ripercorsi tutti i passi principali della progettazione di unasimulazione. Una delle parti fondamentali di una simulazione è il modellodi essa; nella sezione 2.5 sono illustrate tutte le principali caratteristicheche deve comprendere un generico modello di simulazione. Infine èstato deciso di riportare un esempio di una simulazione di un semplicesistema (sezione 2.6). Questo è stato fatto con lo scopo di render chiaried applicare qui concetti, descritti nelle sezioni precedenti.

2.1 principali scopi della simulazione

Una simulazione consente di ricreare il comportamento di un sistemareale al fine di:

• Rappresentare sistemi reali complessi, tenendo conto anche dellesorgenti di incertezza, ovvero introducendo anche delle variabilideterminate da distribuzioni di probabilità.

• Riprodurre il comportamento di un sistema in riferimento anche asituazioni che non sono sperimentabili direttamente. Ad esempio lariproduzione di un disastro naturale, che colpisce una certastruttura ed il relativo calcolo dei danni, è una situazione nonriproducibile nel mondo reale.

• Verificare l’efficacia di un cambiamento da apportare ad unsistema, prima della sua effettiva implementazione.

13

14 simulazione di un sistema

Si deduce che, in generale, lo scopo della simulazione è quello di ricrearein un ambiente controllato le dinamiche del sistema reale, dando una suavisione globale; essa, infatti, evidenzia le interdipendenze tra le diverseparti, mostra l’evolvere del sistema nel tempo, monitorando i valori deiparametri che lo influenzano, e fornisce gli indicatori di performance.

2.2 vantaggi e svantaggi della simulazione

La simulazione di un sistema è una tecnica ampiamente sfruttata, datoche da essa è possibile trarre i seguenti vantaggi:

• Riduzione dei costiCon la simulazione di un sistema, nuove politiche, procedureoperative, regole di decisione, componenti hardware/software, etc..possono essere testate ed analizzate prima di essere inseriteconcretamente nel sistema reale. Mentre gli esperimenti realipossono essere molto costosi e rischiosi, grazie alla simulazione èpossibile valutare in anticipo le conseguenze che può portare unadeterminata modifica del sistema. Ad esempio, è possibileverificare l’impatto che ha l’inserimento di una nuova postazione,in una catena di montaggio, prima della sua effettiva installazione.

• Riduzione dei tempiEseguire un esperimento su un sistema reale può richiedere moltotempo, mentre con la simulazione bastano pochi minuti perottenere gli stessi risultati.

• Ripetibilità e comprensioneGrazie all’utilizzo degli elaboratori è possibile ripetere lasimulazione molte più volte, risparmiando tempo rispetto allasperimentazione sul sistema concreto. In questo modo essendol’esperimento più facilmente ripetibile, è possibile raccogliere unaquantità di dati maggiore e quindi si ha una migliorecomprensione del comportamento del sistema.

• Riduzione dei rischiA causa della paura di un fallimento le idee ed i cambiamenti piùrischiosi non sono neppure provate. Grazie alla simulazione questoè invece possibile dato il basso rischio; sono quindi incoraggiate leinnovazioni ed i miglioramenti anche più radicali.

Tuttavia l’utilizzo della simulazione ha anche dei punti a sfavore:

2.3 tipologie di simulazione 15

• Lo sviluppo di un modello di simulazione può rivelarsi oneroso,anche a causa del personale altamente qualificato richiesto.

• I risultati della simulazioni non sono facilmente interpretabili,l’analisi di questi dati può risultare anche molto complessa.

• La simulazione non fornisce risultati precisi se i dati in input ed ilmodello di simulazione non sono sufficientemente accurati.

2.3 tipologie di simulazione

La simulazione di un sistema dinamico può essere di due tipologie[1]:

• Simulazione deterministicaL’esito della simulazione, su un determinato modello di sistema, èlegato in maniera deterministica ai parametri in ingresso: con glistessi parametri la simulazione avrà sempre la medesimaconclusione.

• Simulazione stocasticaL’esito della simulazione è legato sia ai parametri in ingresso, chealla casualità riprodotta mediante l’utilizzo di variabili aleatorie. Ilfunzionamento è simulato utilizzando distribuzioni di probabilitàper generare eventi, i quali andranno ad alterare il modo di agiredel sistema.

Vi è la necessità, per un sistema dinamico, definire un meccanismo diavanzamento del tempo per far procedere il tempo simulato o clock; lasimulazione di un sistema viene effettuata in due possibili modi:

• Simulazione sincrona (time-driven)In questo tipo di simulazione viene fissato un parametro temporaleclock incrementato in maniera fissa nel tempo; quindi vienemonitorato il sistema in questi precisi intervalli di tempo. Sipossono avere intervalli di inattività dove non avvengono eventid’interesse.

• Simulazione asincrona (event-driven)In questo caso invece il valore del clock viene incrementato nonappena si verifica un evento, quindi non seguirà dei tempiprefissati, ma l’avvenire degli eventi. Non si hanno in questo casointervalli di tempo dove il sistema resta inattivo.


2.4 progettazione e studio di una simulazione

La progettazione e lo studio di una simulazione segue generalmente iseguenti passi[4]:

1. Analisi del problemaViene studiato il problema da affrontare, identificando lecomponenti essenziali e le misure di prestazione d’interesse.

2. Formulazione modello simulazionePer poter costruire un adeguato modello di simulazione delsistema in esame, è necessario considerare le seguenti fasi:

• Definizione delle variabili di stato.

• Realizzazione del metodo per generare casualmente eventi.

• Identificazione degli eventi che fanno cambiare lo stato delsistema.

• Identificazione delle transizioni di stato provocate dagli eventi.

• Scelta di una misura del tempo simulato.

3. Analisi modello simulazioneIn questa fase viene verificata l’accuratezza del modello realizzatocon diverse modalità. Il modello è analizzato dal punto di vistaconcettuale, con gli esperti del settore applicativo, in questo modosono evidenziati errori ed omissioni.

4. Scelta del software e costruzione del programmaDopo aver definito il modello, questo deve essere implementato eda tale scopo è possibile utilizzare diversi strumenti:

• Linguaggi general purpose, classici linguaggi diprogrammazione, richiedono molto lavoro per implementareuna simulazione.

• Linguaggi di simulazione generali, sono linguaggi diprogrammazione specifici per la simulazione, il temponecessario all’implementazione è minore rispetto a quello deilinguaggi general purpose.

• Simulatori, sono packages per la simulazione orientati alleapplicazioni. Permettono di realizzare un programma disimulazione utilizzando menù grafici senza bisogno diprogrammare.

2.5 modelli di simulazione 17

• Fogli elettronici, per problemi di piccole dimensioni è possibileutilizzarli per avere un idea del funzionamento del sistema.

5. Validazione del modello di simulazioneIn questa fase viene verificato se il modello realizzato, forniscerisultati validi per il sistema in esame: ovvero se i valori reali sonoben approssimati da quelli generati dal modello di simulazione.

6. Progettazione della simulazioneVengono scelte le modalità di esecuzione della simulazione adesempio la durata della simulazione, i dati da raccogliere, etc..

7. Esecuzione della simulazione ed analisi dei risultatiViene eseguito su uno o più elaboratori il programma dellasimulazione. Al termine vengono analizzati i risultati prodotti.

8. Presentazione delle conclusioniViene prodotta una relazione che riassume tutto lo studioeffettuato.

2.5 modelli di simulazione

Come già è stato introdotto nel capitolo 1, per poter rappresentare inmodo preciso il comportamento di un sistema e poterlo fare corretta-mente interagire con i vari eventi, è necessario costruire un modello disimulazione che permetta di descrivere le operazioni su un sistema ecome esse devono essere simulate[4]. A seconda del tipo di modello uti-lizzato è possibile concentrarsi su determinate caratteristiche e parametri,trascurandone invece altri. Gli elementi che costituiscono un modello disimulazione sono:

• Variabili di statoIn ogni istante un sistema è descritto da un insieme di variabilidi stato, che ne definiscono lo stato interno. Queste servono aillustrare le rappresentazioni interne e corrispondono agli attributidel sistema, alle sue caratteristiche e proprietà. Alcuni esempi divariabili di stato possono essere il numero di utenti nel sistema, laposizione di un treno su una linea ferroviaria, etc.. Nei modelli disistemi discreti le variabili di stato cambiano in determinati istanti,in seguito all’avvenire di un evento o al raggiungimento di un certotempo; a sua volta il cambiamento dei valori di queste variabili puòcausare altri eventi.


• EventiUn evento è un qualsiasi accadimento istantaneo che fa variare ilvalore di almeno una delle variabili di stato, causando un cambia-mento di stato.Ci sono due tipi di eventi:

– Eventi endogeni, che si verificano all’interno del sistema.

– Eventi esogeni, esterni al sistema.

Ad esempio, in un simulatore di linee ferroviarie, il completamentodi una tratta ferroviaria da parte di un treno è un evento endo-geno, dipende soltanto da fattori interni al sistema. Mentre in unsimulatore di un sistema che gestisce una coda di user, l’arrivo diun nuovo utente è esogeno, dato che dipende da fattori esterni alsistema. Gli eventi si possono suddividere in:

– Time event, individuati da un istante temporale nel calendariodegli eventi.

– State event, individuati da una specifica condizione del sistema(indipendente dal tempo) che porta al verificarsi di questo tipodi eventi.

Ad esempio l’arrivo di un nuovo utente nel sistema è un time eventdipende solo dal tempo, mentre il completamento di una trattaferroviaria è un state event, poichè non dipende dal tempo ma daaltre circostanze (velocità media, numero di stazioni in cui sosta-re, eventuali malfunzionamenti etc.. ) che portano al compimentodell’evento.

• Entità ed attributiLe entità sono i singoli elementi del sistema, queste determinanol’accadere degli eventi e/o reagiscono ad eventi. Ci sono due tipi dientità:

– Entità dinamiche, sono elementi che fluiscono nel sistema,ovvero che non permangono in esso per tutta la durata dellasimulazione.

– Entità statiche, sono oggetti definiti all’interno del sistema, chea differenza delle entità dinamiche, rimangono nel sistema pertutta la simulazione.

Un utente che entra nel sistema, dopo che è stato servito, abbandonail sistema: è un’entità dinamica; una postazione in una catena dimontaggio, che esegue sempre determinate operazioni, è statica. Le

2.5 modelli di simulazione 19

entità hanno degli attributi che forniscono il valore di determinatidati assegnati ad esse. Ad esempio è possibile che un utente abbiacome attributo il tempo in cui è entrato nel sistema, mentre unapostazione ne abbia uno che indica se è libera o occupata.

• RisorseLe risorse sono elementi del sistema che forniscono un servizio alleentità. Un’entità può richiedere una risorsa; nel caso in cui questanon sia disponibile, sarà necessario porre l’entità in attesa; nonappena la risorsa torna disponibile, l’entità la potrà occupare peril tempo necessario per poi rilasciarla. Nell’organizzazione dellerisorse è necessario occuparsi anche della gestione delle liste diattesa. Ci possono anche essere risorse che permettono di essereutilizzate da più entità contemporaneamente: ad esempio si ha unserver che può gestire un numero N di utenti insieme; nel caso incui sopraggiungano più di N utenti, questi dovranno essere postiin una coda.

• ListeRappresentano un insieme di entità associate, in attesa di un par-ticolare evento o risorsa. Queste possono essere ordinate secondovarie politiche: first-in-first-out, last-in-first-out, oppure secondo gliattributi delle entità in coda. Ad esempio in un sistema dove gliuser richiedono una certa risorsa, che può essere acquisita da unoalla volta, è necessario inserire in una lista quelli che arrivano quan-do la risorsa è occupata. Questa lista può essere gestita secondovarie politiche: coda first-in-first-out, secondo un attributo di prioritàpresente su ogni user, etc..

• AttivitàUn’attività è un azione svolta nel tempo da una componente delsistema: inizia quando sono soddisfatte una serie di specifiche con-dizioni e termina dopo un certo tempo o in base ad altri eventiche accadono nel sistema. Ad esempio l’attività ’Assembla portiera’in una catena di montaggio inizia quando tutte le risorse (posta-zioni e materiali) sono disponibili e termina non appena l’ultimapostazione finisce il suo compito. Tuttavia il tempo di durata diun’attività può essere condizionato da dei ritardi, un esempio dipossibile ritardo è il tempo di attesa nelle liste.


2.6 esempio di un simulatore

Questo esempio rappresenta in maniera semplificata e concettuale ilfunzionamento e le caratteristiche principali di un semplice simulatoredi un sistema ad eventi discreti. Come caso di studio è stata selezionatala simulazione della gestione di una coda a singolo canale per poteraccedere ad una risorsa. I campi di applicazione reale di tale strutturasono molteplici: fila di clienti in una banca, utenti di un call center, userda gestire da un server, etc.. A scopo esemplificativo, al fine di dareconcretezza alla descrizione, è stato scelto di mostrare la simulazione diun server che deve processare le richieste di un insieme di user.Il funzionamento generale di questo esempio si divide in tre principalipassi:

1. Gli user entrano nel sistema richiedendo il server.

2. Gli user sono serviti.

3. Gli user lasciano il sistema.

Supponendo che il server possa gestire, in un certo tempo, al massimoun user alla volta, nel caso in cui ne sopraggiunga uno ed il server siaancora occupato, l’utente viene posto in attesa in una ‘ fila ’. Questa ‘fila ’ di utenti in attesa di essere serviti, è gestita tramite una coda FIFO(First-In-First-Out), con questo tipo di coda il server gestisce prima lerichieste degli user che da più tempo permangono nel sistema.

L’esecuzione della simulazione è descritta in base all’ accadimento didue eventi:

• Entra un user nel sistema.Quando un user entra nel sistema, viene verificato lo stato del servere si hanno due possibilità:

– Server occupato, l’user viene aggiunto in fondo alla coda diattesa.

– Server libero, la richiesta dell’user viene immediatamenteprocessata e quindi questo può lasciare il sistema.

• Esce un user dal sistema.Quando un user esce dal sistema, viene verificato se ci sono altriuser in coda:

– Coda vuota, il server viene posto in attesa di altre richieste.

2.6 esempio di un simulatore 21

– Coda non vuota, viene estratto l’utente in testa alla coda ed èprocessata la sua richiesta.

2.6.1 Tipologia di simulazione

La coda a singolo canale è una particolare simulazione che è conveniente-mente rappresentabile secondo le seguenti tipologie e criteri:

• Simulazione dinamicaQuesto tipo di simulazione è dinamica, infatti rappresenta il sistemain un certo arco temporale. Ogni user entra dopo un certo numerodi minuti (> 0) dall’ultimo arrivato, perciò non possono arrivaredue user contemporaneamente. Il server ha un tempo di serviziovariabile, per cui è occupato a gestire un utente.

• Simulazione asincronaPer questa tipologia di simulazione è vantaggioso scegliere unclock asincrono, ovvero si ha un incremento, in minuti, del clock togniqualvolta si verifica un evento. Nel caso fosse stato scelto unclock sincrono, sarebbe stato necessario scandire tutti gli intervallidurante l’esecuzione. In questo modo si sarebbero presentati ancheintervalli di non interesse durante i quali non avvenivano eventi.

• Simulazione stocasticaQuesta simulazione è una simulazione stocastica dato che sonopresenti due variabili il cui valore non è fisso, ma dipende da unacerta distribuzione di probabilità:

– ta, tempo che intercorre tra l’arrivo di due user.

– ts, tempo impiegato dal server per processare la richiesta diun utente.

Gli eventi ’Entra un user’ ed ’Esce un user’ sono condizionati dallacasualità, quindi l’esecuzione di più simulazioni darà ogni voltarisultati diversi.

2.6.2 Modello di simulazione

Al fine di poter effettuare esperimenti e poter rappresentare il comporta-mento di questo sistema, è definito un modello caratterizzato dai seguentielementi:


• Variabili di stato

– SQ(t), (State Queue) indica il numero di user in attesa nellacoda, all’ istante t. SQ(t) > 0

– SS(t), (State Server) indica se il server è occupato oppure noall’ istante t. SS(t) == 0∨ SS(t) == 1

Queste due variabili insieme, ci danno una descrizione completadello stato della simulazione ad un certo istante t del clock.

• Eventi

– A, rappresenta l’arrivo di un user nel sistema.

– D, rappresenta un user che lascia il sistema dopo essere statoservito.

– E, indica che la simulazione verrà fermata.

• Entità

– User, sono entità dinamiche che entrano ed escono dal sistema.Ognuno di questi ha associato come attributi il tempo di arrivonel sistema ta ed il tempo di servizio per cui dovrà occupare ilserver ts.

– Server, è un entità statica all’interno del sistema. Ha comeattributo un intero che indica se è occupato o libero.

• RisorseIn questo caso il server può anche essere rappresentato come unarisorsa di cui usufruiscono gli utenti.

• ListeDato che il server gestisce una richiesta per volta, esso ha associatauna lista di user in attesa. Quest’ultima è organizzata come unacoda FIFO.

• AttivitàLe due principali attività di questa simulazione sono l’arrivo degliuser ed il servizio del server.

2.6.3 Esecuzione della simulazione

L’esecuzione della simulazione segue l’andamento del grafo degli even-ti: Figura 2. Questo grafo serve ad avere una visione d’insieme dello

2.6 esempio di un simulatore 23

svolgimento della prova. In esso i nodi rappresentano i vari eventi edall’avvenire di essi sono modificate alcune variabili di stato. Gli archiinvece sono le relazioni che legano coppie di eventi: ogni arco ha dellecondizioni che determinano l’accadere di un evento.

Figura 2: Grafo degli eventi.

• Arriva un user < A, ta >Viene incrementato di 1 il numero di user in coda SQ++ ed il clockdel sistema clock = clock+ ta del tempo di arrivo dell’user.Nel caso in cui il server sia libero SS == 0, allora l’user può essereprocessato immediatamente dal server.

• Esce un user < D, ts >Viene decrementato di 1 il numero di user in coda SQ−− ed ilclock del sistema clock = clock+ ts del tempo impiegato dal serverper processare la richiesta dell’user.Nel caso in cui ci siano altri user in coda SQ > 0 allora il serverresta occupato SS = 1, altrimenti se la coda è vuota SQ == 0, ilserver è libero SS = 0 e pronto ad accettare la richiesta del primouser che arriva.


• Termina simulazione < E,n >Appena si verifica questo evento, se il clock del sistema ha raggiuntoun istante maggiore o uguale di n, clock >= n, la simulazionefinisce.

Il meccanismo che regola l’avvenire degli eventi futuri in una simulazionead eventi discreti si basa sulla programmazione di questi, che dovrannoavvenire nel corso della simulazione. L’avvenimento degli eventi: Arrivaun user e Esce un user segue le distribuzioni di probabilità di essi, mentrel’evento Termina simulazione è programmato in base alla durata scelta perla simulazione.

3S I M U L A Z I O N E F E D E R ATA

In questo capitolo è introdotta, insieme a tutti i suoi aspetti principali,la simulazione federata. Nella parte iniziale, all’interno della sezione3.1, è presentata una breve panoramica sull’argomento, focalizzandol’attenzione sull’ambito applicativo di questa tecnica. In seguito sonomostrati i vantaggi portati dalla simulazione federata. Nella sezionesuccessiva 3.3 sono trattati sia gli aspetti che riguardano lo sviluppo diuna simulazione federata, sia le caratteristiche sulla sua esecuzione intermine di risorse hardware. Nell’ultima parte (sezione 3.4) sono messein risalto le problematiche della simulazione federata, in particolarefocalizzando l’attenzione sui problemi di interoperabilità e connessione esugli aspetti della sincronizzazione.

3.1 panoramica sulla simulazione federata

Come descritto nella sezione precedente, un simulatore è utilizzato persimulare l’esecuzione di un sistema permettendo di studiare in segui-to i risultati prodotti: questo si presta idoneo se si ha da simulare unsolo sistema indipendente. Nel caso in cui debba essere analizzato unsistema complesso formato da un insieme di sistemi eterogenei, comeun system-of-systems, un unico simulatore potrebbe non esistere o nonessere sufficiente. Una soluzione a questa problematica è fornita dal-la simulazione federata. Infatti, sfruttando le tecniche di simulazionefederata vengono connessi ed interfacciati i simulatori dei differenti si-stemi in modo che, essendo reciprocamente influenzati, venga creata ununica simulazione. Questa unione di più simulatori è chiamata federa-zione. Dentro la federazione il singolo simulatore è chiamato federato;essi, durante la loro esecuzione, devono occuparsi di inviare e riceverenotizie sugli eventi d’interesse. Utilizzando la simulazione federata èpossibile rappresentare il comportamento di un unico grande sistemacomposto da più sistemi connessi, rispettando tutti gli aspetti previsti

25

26 simulazione federata

per la simulazione dei systems-of-systems.

3.2 vantaggi della simulazione federata

L’approccio alla simulazione federata è nato in ambito militare e si èsuccessivamente allargato verso i settori dove questa tecnica porta dellemigliorie e dei vantaggi non indifferenti.I principali vantaggi della simulazione federata sono:

• AnalisiCapacità di analizzare il comportamento e mettere alla luce le inter-dipendenze di sistemi composti da più entità interagenti; sistemi lacui analisi con un modello matematico o con un unico simulatorenon sarebbe fattibile.

• TestOpportunità di riprodurre situazioni e contesti raramente riprodu-cibili nella realtà, dato il costo ed il rischio elevati. Grazie a questoè possibile testare degli scenari e dei casi prima di apportare dellemodifiche reali su un sistema. La simulazione federata può fornireanche uno strumento di supporto alle applicazioni, permettendo diverificare e scegliere quale decisione è la migliore.

• EstendibilitàOgni simulazione federata è espandibile: è possibile aggiungere nuo-vi federati che potranno interagire con quelli già presenti. Questacaratteristica è ben attuabile con l’utilizzo di standard che definisco-no delle specifiche e delle regole che ogni federato deve soddisfareper entrare nella federazione. Adattandosi ed uniformandosi adun certo standard viene garantito anche un riuso di modelli disimulazione già esistenti.

3.3 esecuzione e sviluppo di una simulazione federata

Alcuni degli aspetti più importanti da considerare per l’implementazionee lo sviluppo di una simulazione federata sono[13]:

• Sistema di scambio delle informazioniLa capacità di passare le informazioni significative tra i federati.

3.3 esecuzione e sviluppo di una simulazione federata 27

• Rappresentazione dell’ambienteLe possibilità dei federati di interagire e condividere gli ambienti incui essi operano.

• Rappresentazione delle entitàLa capacità dei federati di mantenere sincronizzate le informazionitra le entità nella simulazione.

• ModelliIl modello interno di ogni federato deve essere convalidato e coor-dinato attraverso la federazione.

• Raccolta di datiDurante l’esecuzione della simulazione è necessario raccogliere idati e le informazioni più significative, al fine di eseguire in seguitoun corretto processo di analisi.

Tenendo conto di queste caratteristiche, è ovvio che la costruzione ela gestione di una simulazione federata risulta un processo laborioso ecomplicato. É possibile implementare delle soluzioni specifiche per ogniparticolare simulazione, rispettando tutti i punti sopra citati. Al fine disemplificare e generalizzare buona parte di queste operazioni e creareun modello architetturale per la simulazione federata, sono stati definitidegli standard che provvedono a definire dei framework e delle lineeguida per organizzare e gestire al meglio la federazione. Alcuni di essisaranno analizzati nei capitoli successivi.Una simulazione federata per essere eseguita in un tempo utile puòrichiedere risorse hardware non indifferenti. Infatti le simulazioni,a causadell’altissimo numero di elementi che interagiscono tra loro, sono tra leapplicazioni più onerose in termini di tempo di esecuzione. Per poterrendere più veloce l’esecuzione di più simulazioni connesse, è possibilesuddividere il carico di lavoro su più unità di elaborazione, seguendodue differenti approcci, vedi Figura 3:

- Simulazione parallelaIl modello simulato è eseguito su una piattaforma dove le unità dielaborazione sono strettamente accoppiate, generalmente si trattadi sistemi multiprocessore con memoria condivisa. Questa tipologiaha una latenza di passaggio di informazioni bassa e quindi anchebuone prestazioni. Nel caso in cui debbano essere simulati sistemimolto complessi, si ha necessità di componenti hardware di uncerto livello il cui costo può risultare molto elevato.


- Simulazione distribuitaLe unità di elaborazione che eseguono i vari simulatori, non sitrovano sulla stessa piattaforma e non sono dello stesso tipo, masono interconnesse grazie a reti LAN, WAN ed Internet. La latenzadi questo tipo di reti è molto più rilevante rispetto all’altro caso,infatti è di diversi ordini di grandezza più grande. Tuttavia graziealla simulazione distribuita è possibile collegare entità eterogeneee geograficamente distribuite in luoghi diversi, permettendo lasimulazione di modelli molto più articolati.

Figura 3: Simulazione parallela e distribuita.

Le architetture reali per la simulazione sono di fatto un unione di entram-be le architetture viste: sono composte da un certo numero di elaboratoriconnessi in rete, dove ogni elaboratore può essere caratterizzato da unsistema a singolo processore o multiprocessore.

3.4 problematiche della simulazione federata

La simulazione federata è una tecnica che può portare ad una conoscenzamigliore e più approfondita di un sistema composto da diversi sistemi.Come illustrato precedentemente, il centro della questione è il seguente: isistemi rappresentati da una simulazione federata sono composti da piùentità eterogenee che necessitano di interfacciarsi; sono proprio questecaratteristiche che rendono la presente tipologia di simulazione unastrategia non banale da realizzare correttamente. Sono presenti dei puntifondamentali, sui quali è necessario prestare maggiore attenzione al finedi implementare propriamente una simulazione.

3.4 problematiche della simulazione federata 29

3.4.1 Interoperabilità e connessione

Tutte le entità coinvolte nella simulazione hanno necessità di essere in-terfacciate per poter garantire la corretta trasmissione e ricezione delleinformazioni e dei dati. Il trasferimento dei dati tra i sistemi può essereanalizzato da due punti di vista[17]:

• Connettività tecnicaConsiste nel descrivere il modo che i sistemi adottano per risolve-re il problema dello scambio e della condivisione dei dati con lealtre piattaforme. É fortemente legata alla capacità dei sistemi diimplementare una comune sintassi e struttura dati per creare unaconnessione tra di essi (connettività semantica). Per poter raggiun-gere questo obiettivo è necessario stabilire come i diversi sistemipossono scambiarsi le informazioni ed in che modo queste sonocombinate con le piattaforme che le ricevono.

• Connettività semanticaTratta la necessità di concordare tra i vari sistemi delle definizionicomuni al fine di favorire lo scambio dei dati. La connettività se-mantica dà un contesto comune alle informazioni in uno scenariodove differenti sistemi le elaboreranno poi in una propria maniera.Grazie alla connettività semantica, le informazioni ed i dati sonoautomaticamente capibili e consequenzialmente riusabili, da sistemiche non sono coinvolti nella loro creazione.

Per tutto quello che riguarda invece la tipologia di connessione tra idiversi sistemi, possono essere considerate due diverse tecnologie:

• Accoppiamento centrale (Central coupling)In questo tipo di architettura di comunicazione, le diverse appli-cazioni comunicano tra loro attraverso un canale o ponte logico.Viene supportata la comunicazione sincrona ed asincrona così comela trasformazione dei dati al fine di poter connettere anche entitàeterogenee. Tale tecnologia è adottata specialmente quando vieneutilizzato uno standard per la simulazione federata(come HighLevel Architecture). Infatti in questo caso tutti i partecipanti allasimulazione devono uniformarsi a delle regole e supportare lo stan-dard di formato di scambio della federazione. L’integrazione di unnuovo simulatore nella federazione è relativamente semplice e si


limita all’implementazione di un interfaccia tra il simulatore ed ilcanale logico di comunicazione.

Figura 4: Accoppiamento centrale, tutti i simulatori sono connessi ad un canalecomune.

• Accoppiamento laterale (Lateral coupling)Nel caso in cui non sia possibile poter applicare lo stesso standarddi scambio messaggi a tutti i sistemi coinvolti, l’accoppiamentocentrale non è sfruttabile. Infatti per realizzare federazioni di sistemimolto diversi in termini di interfacce, modelli e rappresentazione deltempo, viene adottato l’accoppiamento laterale. Quest’ultimo forzala creazione di comunicazioni dedicate tra ogni coppia di federati,in accordo con le rispettive specifiche di connessione. In questomodo sono messi in contatto tutti i membri della federazione. Uninconveniente di questa tecnica è il grande numero di collegamentidedicati che si creano ogni volta che viene aggiunto un nuovomembro ad una federazione esistente. Una possibile soluzione aquesto problema è la creazione di link riutilizzabili.

Figura 5: Accoppiamento laterale, sono creati dei canali di comunicazione traogni coppia di simulatori.


3.4.2 Sincronizzazione temporale

Un altro aspetto fondamentale da considerare è la sincronizzazione tem-porale tra i vari simulatori che compongono la federazione. A livellogenerale, il principale scopo della sincronizzazione temporale, è quello diassicurare che i particolari eventi o messaggi siano processati dai federatinel corretto ordine. Si tratta quindi di un requisito basilare per l’esecuzio-ne di più simulazioni in uno scenario comune.La particolare attenzione prestata al problema della gestione del tempo ègiustificata dal fatto che non esiste una soluzione unica ed ottima per tuttii possibili simulatori ed i loro differenti meccanismi di temporizzazione.Tuttavia è possibile categorizzare gli elementi di una federazione, indi-pendentemente dalle rappresentazioni del tempo interne, ma secondo leparticolari funzionalità di interazione offerte e richieste[17]:

• Eventi discretiTali sistemi consentono una comunicazione con un tempo variabile.Infatti questa è determinata dall’accadere di un un evento internoo dal raggiungimento di uno stato nel quale il simulatore richiedeun interazione con l’ambiente esterno. Ad esempio, nel caso di unfederato simulatore di traffico aereo, viene inviata una notifica adun altro federato raccoglitore di dati, soltanto quando un velivoloatterra in un certo aeroporto e tale evento non avviene ad un tempocostante e prestabilito.

• Passi temporali costanti (Constant time steps)Questa tipologia di simulatori è progettata per offrire un interazioneogni volta che trascorre un preciso lasso di tempo. Tali intervallitemporali possono essere di due tipi: brevi per migliorare l’accu-ratezza dei risultati, lunghi per incrementare la performance dellasimulazione. Nel caso di un simulatore navale, viene inviato unmessaggio contenente la posizione della nave ad intervalli regolariad un federato che la visualizza a video. Se gli intervalli di tempoche intercorrono tra un messaggio e l’altro sono brevi, sarà migliorela precisione con cui la posizione della nave è visualizzata.

• Tempo reale (Real time)Le simulazioni real time prevedono l’intervento umano durante laloro esecuzione. Questi sistemi lavorano con una organizzazione deltempo ad intervalli di tempo molto brevi e costanti, sincronizzaticon il tempo reale. Perciò la capacità di attendere i risultati prodotti


dagli altri federati è molto limitata. Un simulatore di volo deveinteragire direttamente con un utente, esso riceve continuamenteinput dall’utilizzatore. La frequenza con cui esso riceve ed invia datiagli altri federati, deve rispettare il tempo reale, senza consentireritardi, per evitare d’interferire con l’utilizzo del simulatore da partedell’utente.

C’è la possibilità inoltre che un particolare simulatore implementi unacombinazione di meccanismi di gestione del tempo. Ad esempio che essosi aggiorni ed invii notifiche periodicamente ed inoltre sia condizionatodalla ricezione irregolare di messaggi da parte di un altro federato. All’in-terno della federazione la scelta di un appropriato sistema di gestione deltempo globale, dipende quindi dalla combinazione dei differenti modellidi tempo che hanno i diversi simulatori.A scopo esemplificativo è riportato in seguito un esempio di un erratasincronizzazione tra due diversi simulatori ad eventi discreti. Questoesempio esplicita quanto può essere dannoso per due simulatori federatinon essere ben sincronizzati temporalmente.Consideriamo una simulazione in ambito militare, dove per semplicitàsono presenti soltanto due differenti simulatori:

1. Simulatore A: simulatore di un carro armato, può generare l’evento’fire’, indicando che sta sparando verso un determinato bersaglio.Questo evento produce messaggio da inviare al simulatore delbersaglio.

2. Simulatore B: è un simulatore di un veicolo che è il bersagliodel simulatore A. Ha la possibilità di generare l’evento ’move’ perspostarsi in un altra zona del campo di battaglia.

Il simulatore A in seguito all’evento ’fire’ invia al simulatore B il relativomessaggio al tempo logico 10.Tale messaggio dovrebbe essere consegnato in quell’istante e produrrequindi nel simulatore B un corrispettivo evento. Tuttavia a causa di unamancata sincronizzazione il simulatore B avanza al tempo simulato 20 egenera l’evento ’move’, senza prima ricevere il messaggio da A.


Figura 6: Mancata sincronizzazione temporale tra due simulatori.

Si presenta un’anomalia temporale per cui non viene consegnato ilmessaggio al tempo giusto e quindi viene compromessa l’esecuzione: l’a-vanzamento temporale all’istante 20 sarebbe dovuto avvenire soltanto do-po aver ricevuto il dato. In questo modo invece il messaggio è consegnatonel ’passato’ di B causando così un errore di sincronizzazione.

4S TA N D A R D P E R L A S I M U L A Z I O N E F E D E R ATA

In questo capitolo sono illustrati gli standard per la simulazione federata,in particolare sono descritti gli aspetti generali dello standard attualmentepiù utilizzato: High Level Architecture (HLA). Inizialmente, nella sezione4.1 sono presenti le principali motivazioni sull’utilizzo degli standard perla simulazione federata. In seguito viene fornita una breve descrizionesullo standard Distributed Interactive Simulation (DIS) con le sue princi-pali caratteristiche (sezione 4.2). Viene quindi introdotto nella successivasezione 4.3, lo standard High Level Architecture (HLA), analizzando ivantaggi e le migliorie rispetto al DIS. A questo punto incomincia unadescrizione più approfondita sugli aspetti e le principali funzionalitàdi questo standard. Inizia con le caratteristiche principali presenti nellasezione 4.4, per poi passare alla spiegazione delle funzioni delle duecomponenti essenziali ovvero la Run Time Infrastructure (sezione 4.5) edil modello ad oggetti (4.6).

4.1 standard come soluzione ai problemi

Nei capitoli precedenti è stata descritta la simulazione federata comeuno strumento di supporto tanto utile quanto di difficile gestione. Perpoter infatti riuscire a risolvere le problematiche legate ad essa è possibilesia adottare delle soluzioni ad hoc progettandole appositamente per laparticolare simulazione, sia sfruttare degli standard esistenti che offronogli strumenti ed i meccanismi necessari. L’impiego di questi ha permessodi riutilizzare, estendere e garantire interoperabilità tra le simulazioni: inquesto modo sempre su più sistemi, per studiarne il comportamento el’evoluzione, sono state adottate delle tecniche di simulazione federata.Tali standard sono nati alla fine del secolo scorso in ambito militare, dovela simulazione era fortemente usata. I principali motivi che hanno spintoil dipartimento della Difesa degli Stati Uniti ad investire su questo tipodi ricerca sono stati:

35

36 standard per la simulazione federata

• Taglio dei costiLa fine della guerra fredda ha portato dei tagli alle spese militari,quindi al fine di risparmiare sulle nuove prove, fu deciso che erapiù conveniente riusare il codice di simulazioni già realizzate chesvilupparne di nuovo ogni volta.

• InternetLa nascita e la rapida espansione di Internet ha reso possibilemettere in comunicazione entità geograficamente anche molto di-stanti, permettendo di creare simulazioni sempre più complesse edarticolate.

I principali standard utilizzati per la federazione di più simulatorie lo scambio dei dati sono il protocollo DIS (Distributed InteractiveSimulation) e l’architettura HLA (High Level Architecture).

4.2 distributed interactive simulation

Nacque all’inizio degli anni 90, conosciuto come ADS[14] (AdvancedDistributed Simulation) e consisteva nella definizione di uno specificoset di messaggi che avrebbero trasportato le informazioni tra i vari si-mulatori. A partire da questo progetto è stato sviluppato il protocolloDIS, con l’obiettivo di definire un’infrastruttura per collegare simulazionidi vario tipo collocate in luoghi differenti. Grazie a ciò viene permessodi interagire ed interoperare tra le varie piattaforme, consentendo lariproduzione di scenari realistici per la simulazione di attività altamenteinterattive; la sua prima applicazione fu infatti la simulazione militare.I principali punti che caratterizzano lo standard DIS sono:

• Standardizzazione rigida dei messaggi chiamati PDUs (ProtocolData Units) scambiati sia tra le varie applicazioni di simulazioneche tra i gestori della simulazione. Per condurre simulazioni semprepiù sofisticate sono stati introdotti sempre più tipologie di PDU.Questi messaggi sono sempre inviati in broadcast verso tutte le altreentità.

• Non è prevista l’esistenza di un computer centrale che controllil’intera simulazione.

• I singoli simulatori hanno la responsabilità di comunicare alla reteogni cambiamento di stato che li coinvolge.

4.3 high level architecture 37

• Sono presenti degli algoritmi per ridurre il traffico sulla rete utiliz-zata dal DIS.

Il Distributed Interactive Simulation è un protocollo di simulazione matu-ro che è riconosciuto come standard internazionale dall’IEEE. Nonostantequeste caratteristiche il DIS presenta anche degli svantaggi:

• Nel tempo, per aggiornare le funzionalità dello standard, sono statiaggiunti nuovi tipi di PDU; l’architettura dello standard rimanesempre la stessa. Aumentando la grandezza dei dati all’interno deiPDU si ha anche una richiesta di banda maggiore per trasmetterlisulla rete.

• I PDU sono immessi sulla rete senza protezione ed un qualsiasi’partecipante’ potrebbe intercettare tutte le comunicazioni sulla rete.

• Il supporto per l’aggregazione e la disaggregazione delle entitàalla simulazione è limitato. Simulatori con diverse versioni dellostandard DIS o che implementano in maniera differente dei PDU,potrebbero non essere collegabili.

• Ogni volta che un’entità deve inviare un’informazione la inviasempre in broadcast verso tutti i partecipanti: questa politica èmolto dispendiosa in termini di risorse di rete.

4.3 high level architecture

Uno degli standard più importanti, per la simulazione federata, è l’HighLevel Architecture (HLA) IEEE 1516.[10] Fu sviluppato all’inizio deglianni 90 dal Defence Modeling and Simulation Office (DMSO) per il Dipar-timento della Difesa degli Stati Uniti, allo scopo di creare un frameworkper le simulazioni militari. Col seguire degli anni, grazie all’HLA, èstato possibile utilizzare la simulazione federata in molti altri campioltre a quello militare: impianti industriali avanzati[24], test di situazionicatastrofiche[19], simulazioni aeronavali[28], simulazioni di traffico stra-dale[29], etc..L’HLA definisce un framework comune per la connessione e l’interazionedi più simulatori. Le sue caratteristiche principali lo distinguono comestandard non solo per la simulazione militare, contesto nel quale è nato,ma come supporto per tutte le simulazioni dove è necessario connetterepiù simulatori. I principali obiettivi di questo standard sono:


• Riusabilità del codice delle simulazioni.

• Interoperabilità tra le varie entità della simulazione.

• Separazione della logica del modello di simulazione dal sistemadistribuito che la esegue. Le strutture definite da HLA infatti sonoindipendenti dall’implementazione interna dei simulatori.

Rispetto al protocollo DIS, lo standard HLA definisce una robusta ar-chitettura di invio/ricezione dati, che consente sia di ottimizzare leperformance della rete che di rendere la simulazione più flessibile emodulare. Inoltre l’HLA non ha una specifica implementazione o si basasu particolari software o linguaggi di programmazione: ogni volta chesono disponibili nuove tecnologie è sempre possibile progettare nuoviframework di HLA. Per queste ragioni High Level Architecture è sta-to scelto come punto di riferimento negli standard per la simulazionedistribuita.

4.4 caratteristiche generali

L’architettura su cui si basa questo standard comprende tre componentiprincipali[10]:

1. HLA RulesLe regole dell’HLA descrivono le responsabilità dei federati e delleloro relazioni con la Run Time Infrastructure (RTI). Le regole sidividono in due categorie :

• Regole per la federazione, sono regole globali che riguardanol’intera federazione e la sua esecuzione.

• Regole per i federati, sono regole più specifiche per i singolifederati.

2. Interface SpecificationLe specifiche d’interfaccia invece, definiscono come avvengono leinterazioni tra i federati e l’RTI (Run Time Infrastructure), infattiogni interazione tra due federati avviene ed è regolata da essa. Idue elementi principali che costituiscono una simulazione con HLAsono, come illustrato in Figura 7:

• FederatiDurante un simulazione federata, i federati interfacciati non

4.4 caratteristiche generali 39

necessariamente dovranno essere soltanto simulatori. Infatti po-tranno esserci anche delle unità di supporto come ’spettatori’,raccoglitori di dati ed interfacce con utenti reali. Lo standardquindi non impone restrizioni su che cosa può rappresentareun singolo federato; tuttavia è necessario che ognuno di essiimplementi determinate funzionalità al fine di consentire atutti gli oggetti della simulazione federata di interagire corret-tamente tra loro. La federazione è l’insieme di tutti i federatipartecipanti alla simulazione, questa struttura a componen-ti permette una facile composizione e scomposizione dellesimulazioni.

• RTI (Run Time Infrastructure)Si tratta dell’infrastruttura che fornisce servizi e supporto atutti i federati della simulazione, permettendo così la comunica-zione e l’interazione tra essi: tutte le informazioni scambiate trai federati passano attraverso l’RTI. La sua implementazione ècompletamente indipendente dai federati che la sfruttano. L’R-TI da supporto e fornisce servizi ai federati, come un sistemaoperativo fornisce servizi ai programmi e alle applicazioni[9].

3. Object Model Template (OMT)Descrive le classi di oggetti che compongono una simulazione ele classi delle possibili interazioni. Il modello ad oggetti è essen-ziale, infatti una delle sue più importanti funzionalità è fornire uninterfaccia tra i federati e l’RTI. Questo viene sfruttato per garantireuna rappresentazione di tutte le entità, ad un livello più alto diastrazione, che rispecchia il comportamento e lo stato dei federati.Ciascuno deve sottoscriversi ad una classe di oggetti, così l’inte-roperabilità e lo scambio di informazioni tra i federati, avviene inrealtà tra rappresentazioni di essi. L’HLA non impone vincoli sulcontenuto dei modelli ad oggetti: viene lasciata libera la definizionedel formato d’interscambio dei dati.


Figura 7: Struttura del framework HLA.

4.5 infrastructure rti

Il ruolo della Run Time Infrastructure è soltanto quello di fungere dasupporto per le simulazioni. Non avere un ruolo attivo ed un propriostato, permette a questa infrastruttura di rimanere più generica possibile.Ci sono infatti molteplici implementazioni di RTI alcune delle più uti-lizzate sono: MAK RTI, CERTI RTI, Pitch RTI. Questi software possonoessere sfruttati da una simulazione federata ed ognuno di essi forniscesei gruppi di servizi di supporto:

• Federation ManagementSono delle funzioni che permettono la creazione e l’apertura dellefederazioni, l’ingresso e l’uscita di un federato da una federazione.Oltre a questo scopo la Gestione della Federazione fornisce serviziche riguardano la simulazione nel suo complesso: possibilità dicreare punti di salvataggio e di recupero dello stato, gestione deipunti di sincronizzazione.

• Declaration ManagementFornisce i mezzi per permettere ai federati di specificare qualiinformazioni sono da loro richieste ed inviate. I federati che si

4.5 infrastructure rti 41

aggregano ad una federazione, prima di sottoscriversi ad un istanzadi un oggetto ed aggiornare gli attributi di essa, devono invocaregli appropriati servizi di Declaration Management.

• Object ManagementQuesti servizi provvedono al vero e proprio scambio di messaggitra oggetti e federati. Grazie alla Gestione degli Oggetti, è possibilespedire o ricevere interazioni, propagare le modifiche effettuatesugli attributi di proprietà di un federato e registrare nuove istanzedi un oggetto.

• Ownership ManagementIn una simulazione federata gli attributi di un’entità non sono stati-camente di proprietà di un federato. Il cambiamento del possessodegli oggetti ed attributi, durante l’esecuzione, è supportato daiservizi di Gestione della Proprietà. Questi servizi sono importantidato che, in ogni istante dell’esecuzione, l’aggiornamento di unparticolare attributo è permesso soltanto al federato che ne è ilproprietario.

• Time ManagementPer garantire un corretto e consistente svolgimento di una simula-zione federata è necessario un meccanismo di Gestione del Tempo.In generale, l’avanzamento temporale deve essere coordinato coni servizi di Gestione degli Oggetti, così che le informazioni sianotrasmesse ai federati in tempo e nel giusto ordine [10].Nell’HLA è presente un tempo logico o tempo di simulazione glo-bale; l’avanzamento di questo è gestito in maniera tale da garantireche i messaggi siano consegnati ai simulatori nel giusto ordine. Imeccanismi di Time Management dell’RTI, forniti ai federati, sonovolti al controllo dell’avanzamento del tempo simulato della federa-zione: un federato deve quindi associare sia se stesso, che alcunesue attività, con l’asse temporale di HLA[9].Lo standard fornisce due tipologie di scambio di messaggi, perspecificare in che modo i messaggi trasmessi siano consegnati allafederazione:

– Time Stamp Order (TSO), il mittente assegna ai messaggi unprecisa data ed ora. Questi messaggi devono essere consegnatiai destinatari rispettando l’ordine temporale indicato. Conquesta politica sono prevenute le anomalie temporali, ma sipresenta un elevato tempo di latenza.


– Receive Order (RO), l’ordine di consegna è arbitrario e nonnecessariamente segue quello temporale. Il tempo di latenzaè minore rispetto al TSO, ma si possono presentare anomalietemporali.

Un federato che entra in una federazione può essere categorizzatoa seconda della gestione del tempo utilizzata e richiesta:

– Time-regulating, un federato appartiene a questa categoria se as-socia alcune sue attività (invio di interazioni ed aggiornamentodi attributi di un oggetto) con dei punti dell’asse temporaledella federazione: questi eventi hanno quindi un Time stamporder associato.

– Time-constrained, un federato è vincolato nel tempo se è in-teressato a ricevere messaggi (ricezione di aggiornamenti diattributi e interazioni) in TSO.

– Regulating and constrained, un federato che è sia Time-regulating,che Time-constrained.

– Neither regulating nor constrained, lo è un federato le cui attivitànon sono coordinate temporalmente dall’RTI e non necessitaquindi dei servizi i servizi di Time Management.

Grazie a queste funzionalità in questo standard è facilitata l’inte-roperabilità tra federati che hanno differenti politiche di gestionetemporale.

• Data Distribution ManagementSono servizi legati alla Declaration Management (DM), questi ultimiinfatti trattano la possibilità dei federati di aggiornare e ricevereaggiornamenti dagli oggetti. Grazie alle informazioni ricevute dalDeclaration Management l’RTI imposta dei filtri che distribuiscono idati tra i federati. I servizi di Data Distribution Management (DDM)sfruttano il filtraggio per fornire una migliore distribuzione dei dati,soprattutto quando la federazione è di dimensioni importanti. Loscopo delle funzioni di DDM è quello di rendere la comunicazionedi dati più efficiente distribuendo i dati soltanto ai federati che lirichiedono.

I dettagli sui meccanismi utilizzati dai federati per comunicare con l’RTIe viceversa, sono trattati nel capitolo 6.

4.6 modello ad oggetti 43

4.6 modello ad oggetti

Nello standard HLA per garantire la corretta interazione e condivisionedi informazioni tra i federati è utilizzato un modello ad oggetti. Durantela simulazione ogni federato è responsabile dell’aggiornamento di una opiù istanze di classi e queste si occupano di interfacciarsi con l’RTI pertrasmettere le informazioni agli altri federati. Attraverso il meccanismopublish-subscribe, ogni federato deve specificare quali oggetti dovrà ag-giornare e da quali invece ricevere informazioni.Il modello ad oggetti, chiamato Object Model Template (OMT), si divi-de a sua volta in due sotto modelli: Federation Object Model (FOM) eSimulation Object Model (SOM). Entrambi i modelli sono stati definitiper creare un livello di astrazione oltre le caratteristiche specifiche diogni federato per facilitare il riutilizzo dei federati e per migliorare lacondivisione delle informazioni tra gli sviluppatori delle simulazioni.

• Federation Object Model (FOM)Ne è presente uno per federazione e descrive tutte le entità che sonocoinvolte nell’interazione con la federazione; non sono considerateinfatti le entità interne del singolo federato. Ogni istanza di unoggetto nell’HLA è un’istanza di una classe presente nel FOM.Durante l’esecuzione della simulazione ogni federato è responsabiledell’aggiornamento delle informazioni dei rispettivi oggetti i qualipotranno comunicarle al resto della federazione. Un oggetto puòessere aggiornato soltanto da un federato che ne detiene la proprietà;i servizi che permettono ai federati di scambiarsi il possesso deglioggetti sono forniti dall’RTI.

• Simulation Object Model (SOM)Ogni federato ne possiede uno e descrive tutti i federati in terminidi categorie di classi di oggetti ed attributi analizzando i dettaglidelle specifiche interne. Questo modello fornisce le caratteristicheriguardo la capacità, di un federato, di scambiare informazioniesternamente. Tramite il SOM è possibile valutare quanto sia ap-propriato per un federato partecipare o meno ad una federazioneverificando quali dati esso può mettere a disposizione e quali invecepotrebbero essere richiesti.

Ogni oggetto trattato da questi modelli rappresenta un’entità duraturanel tempo che subisce continui aggiornamenti e variazioni di stato duran-te la simulazione. In particolare tutti gli oggetti condivisi in un modello


HLA sono istanze di classi di oggetti che appartengono al FOM. Nellasimulazione ogni oggetto si interfaccia direttamente con l’RTI.Nell’Object Model Template vengono descritte classi di oggetti, ogniclasse ha al suo interno una serie di attributi che la caratterizzano. Unattributo di una classe è identificato come una porzione dello stato del-l’oggetto e l’insieme di tutti gli attributi caratterizza completamente lostato di esso. Al massimo un federato è responsabile dell’aggiornamentodi un attributo di un istanza di un oggetto. In questo modo i federatisi scambiano le informazioni comunicando, attraverso i servizi messi adisposizione dall’RTI, il valore degli attributi delle istanze di oggetti chepossiedono.Esiste una relazione che avvicina molto il modello ad oggetti dell’HLAcon i concetti ’Object Oriented’(OO) presenti nei linguaggi di program-mazione. Uno scopo delle tecniche Object Oriented è di descrivere l’astra-zione del sistema con l’obiettivo di una completa comprensione di questo[9]. Per il modello ad oggetti di HLA l’ambito di applicazione previsto èpiù stretto e specifico, si focalizza infatti sulle esigenze e le capacità discambio di informazioni tra federati. La differenza principale tra i mo-delli OO in generale e quello dell’HLA sta negli stessi oggetti: nei primigli oggetti sono caratterizzati da dati ed operazioni(metodi), nell’HLAinvece questi sono definiti interamente dagli attributi. Un’altra differenzasostanziale è presente anche nell’ interazione tra gli oggetti, mentre glioggetti dei modelli Object Oriented comunicano tra loro scambiandosimessaggi, quelli dell’HLA non interagiscono tra loro direttamente, masono i federati che si occupano, attraverso i servizi offerti dall’RTI, dipassare e ricevere informazioni da essi.

5A P P L I C A Z I O N I D E L L O S TA N D A R D H L A

In questo capitolo sono presentati degli esempi di applicazioni dellostandard High Level Architecture ad alcune simulazioni federate. Questicasi di studio sono stati realmente trattati ed il materiale è reperibile allefonti citate. Nella prima parte (sezione 5.1), è presente la metodica con cuisono analizzati i vari esempi proposti. Nelle successive sezioni (5.2, 5.3,5.4) sono mostrati i tre esempi, seguendo sempre la stessa metodologiadi presentazione, ovvero: caratteristiche generali sul simulatore, tipi difederati coinvolti, particolare modello ad oggetti sfruttato ed infine ilfunzionamento dell’esecuzione della simulazione.

5.1 concetti generali

Le simulazioni qui proposte hanno uno scopo esclusivamente didatticoed esemplificativo, infatti non sono approfondite in dettaglio le loro ca-ratteristiche più specifiche. Quello che è mostrato negli esempi seguentiillustra a grandi linee l’implementazione ed il funzionamento di una si-mulazione federata che utilizza lo standard HLA. In particolare sono statianalizzati tutti gli aspetti che riguardano i federati della simulazione ed irispettivi oggetti utilizzati per l’interazione tra essi; nella parte finale diogni esempio è mostrato in che modo viene eseguita la simulazione fede-rata. Non sono state analizzate in profondità le specifiche implementativedella Run Time Infrastructure (RTI); le simulazioni federate proposteutilizzano note implementazioni dell’RTI come MAK RTI e CERTI RTI,che provvedono a fornire le principali funzioni di sincronizzazione escambio di dati. I dettagli su come l’RTI implementa ed esegue tutte lesue funzionalità non sono trattate in questo lavoro di tesi.I casi di studio analizzati sono i seguenti:

• Simulazione sistema di risposta ai disastriQuesto esempio è il più semplice ed intuitivo; il numero di federati

45

46 applicazioni dello standard hla

coinvolti è esiguo e l’esecuzione della simulazione segue sempre unpreciso ordine.

• Simulazione collisioni orbitaliIn questo esempio la simulazione coinvolge un maggior numerodi federati e l’esecuzione segue una particolare sincronizzazionetemporale.

• Simulazione sistema missilisticoNell’ultimo esempio i principali federati sono raggruppati in due en-tità (caccia rosso, caccia blu) che, durante l’esecuzione, si scambianouna serie di messaggi ed interazioni.

5.2 simulazione di una piattaforma per la preparazione aidisastri e la reazione nella gestione delle strutture[19]

5.2.1 Caratteristiche generali

L’obiettivo di questa simulazione è l’imitazione di una situazione di disa-stro all’interno di una struttura e la riproduzione delle relative proceduredi evacuazione, ripristino d’emergenza e recupero strutturale. In parti-colare sono analizzati gli scenari ed i danni provocati da un terremotoe da un incendio e le relative ripercussioni su simulatori di sistemi dievacuazione e ripristino. Per questa particolare simulazione federata, alfine di garantire una corretta sincronizzazione e interoperabilità tra isimulatori, è stata sfruttata una già esistente implementazione della RunTime Infrastructure (RTI): CERTI RTI 1. Quest’ultima segue lo standardIEEE 1516 dell’HLA e fornisce tutte le funzioni descritte nel capitoloprecedente.

5.2.2 Federati coinvolti

Nella simulazione di questo tipo di sistema Disaster Preparedness andManagement System (DPRS), sono essenziali quattro federati:

• Strumento di analisi dei terremotiSfruttando il U.S. Geological Survey (USGS) Server, questo federatofornisce i dati sismici più importanti di un certo terremoto. Ad esso

1 http://savannah.nongnu.org/projects/certi

5.2 simulazione risposta ai disastri 47

viene inviata una query contenente le informazioni di un partico-lare terremoto, l’USGS Server restituisce i dati sismici rilevanti diquell’evento.

• Simulatore di responso strutturaleCon l’utilizzo del simulatore OpenSees è possibile analizzare i danniche un terremoto può provocare ad un edificio. OpenSees in baseai dati sismici ricevuti ed alle informazioni della struttura, è ingrado di di riprodurre i danni causati dal sisma ai punti chiavedello stabile.

• Simulatore di incendiNel caso in cui si verifichi anche un incendio all’interno dell’edificio,il Fire Dynamic Simulator (FDS) è incaricato di stimare la concentra-zione dei livelli di gas tossico che può compromettere l’evacuazionedella struttura.

• Simulatori di risposta alle catastrofiQuesta tipologia di simulatori è considerata come un unico federato:il software Anylogic 7 fornisce una piattaforma di simulazionecomune sfruttata per lo sviluppo e la gestione dei diversi simulatori.Con esso vengono creati tre differenti tipi di simulazioni di rispostead un disastro:

– Simulatore di evacuazione di un edificio, il cui scopo è analiz-zare il comportamento degli occupanti dell’edificio in seguitoad una situazione catastrofica.

– Simulatore di recupero di emergenza, è composto da duemoduli: uno che valuta i danni non strutturali, provocati peresempio all’impianto elettrico e l’altro che simula le proceduredi ripristino di emergenza da attuare, in relazione al tipo didanneggiamento.

– Simulatore di ripristino strutturale dell’edificio, analizza i da-ti del sisma e i danni strutturali provocati, per stimare unpossibile processo di ripristino dell’edificio.


Figura 8: Rappresentazione dei diversi federati in comunicazione con L’RTI.

5.2.3 Modello ad oggetti

I federati sopra descritti comunicano attraverso delle istanze di classidi oggetti, che fungono da interfaccia tra i federati e l’RTI; queste classifanno parte del Federation Object Model (FOM) e sono:

• USGSRequest, contiene le informazioni da passare allo strumento dianalisi dei terremoti USGS.

• Earthquake, all’interno di essa sono presenti tutte le informazionispecifiche del sisma.

• GroundMotion, presenta i dati relativi al movimento della terra dovec’è l’edificio.

• StructuralDisplacement, contiene i dati sugli spostamenti causati dalsisma alla struttura.

5.2 simulazione risposta ai disastri 49

• FireInformation, fornisce le informazioni sul tipo d’incendio che sisviluppa.

• FractionalEffectiveDose, descrive il tipo e la diffusione dei gas tossiciprodotti dal fuoco.

Ciascuna di queste classi al momento dell’esecuzione della simulazionesarà istanziata in un oggetto i cui attributi saranno letti ed aggiornati daifederati a cui è consentito. L’RTI fornisce le adeguate funzioni perpermettere ai federati di specificare quali attributi degli oggetti essiaggiorneranno (publish) e da quali invece riceveranno informazioni(subscribe).

Classi USGS OpenSees FDS Anylogic 7

USGSRequest Subscrive PublishEarthquake Publish Subscrive

GroundMotion Susbscrive PublishStructuralDisplacement Publish Subscrive

FireInformation Subscrive PublishFractionalEffectiveDose Publish Subscrive

5.2.4 Funzionamento della simulazione

Il funzionamento di questa simulazione si suddivide in una serie di passida eseguire sempre nel giusto ordine.

1. Il federato Anylogic 7 invia allo strumento di analisi dei terremotiUSGS, tramite USGSRequest, il tipo del particolare sisma da simula-re. Il federato USGS, appena riceve la richiesta, invia le informazionispecifiche del terremoto ad Anylogic 7 aggiornando gli attributi diEarthquake.

2. Dopo aver ottenuto valori più dettagliati del sisma, Anylogic 7,calcola i dati sul movimento della terra ed aggiornando i valoridell’istanza della classe GroundMotion, li passa al federato simula-tore del responso strutturale OpenSees. Quest’ultimo, dopo averricevuto le informazioni sul movimento del terreno, sfrutta l’istanzadi StructuralDisplacement per passare ad Anylogic 7 i dati suglispostamenti ed i danni provocati alla struttura.


3. Attraverso FireInformation il federato Anylogic 7 invia al simulatored’incendi FDS le informazioni riguardanti il tipo di incendio dasimulare. Con esse l’FDS calcola i dati relativi ai gas tossici rila-sciati e li trasferisce nuovamente, grazie a FractionalEffectiveDose, alsoftware per la simulazioni di risposta alle catastrofi.

I punti 2 e 3 dell’esecuzione sono indipendenti: infatti il processo disimulazione di incendio e le relative ripercussioni che si hanno sul simu-latore dell’evacuazione sono totalmente indipendenti dalla simulazionedel terremoto. Questa modularità permette di simulare anche scenaridove non sono presenti incendi, evitando semplicemente di passare ericevere dati dal federato FDS. In ogni caso, nella parte finale della simu-lazione, Anylogic 7 smista i dati ricevuti ai due simulatori di ripristino ea quello di evacuazione, che simulano rispettive procedure di recuperoed evacuazione.

5.3 simulazione di sistema di collisioni su larga scala dioggetti leo(low earth orbital)[20]

5.3.1 Caratteristiche generali

Il danneggiamento e la distruzione di un satellite in seguito ad unacollisione con dei detriti è una minaccia molto seria. I satelliti LEO (LowEarth Orbital) orbitano tra i 160 e i 2000 km dalla superficie terrestre edil numero di detriti presenti in questa fascia di spazio è molto elevato.Con la simulazione di collisioni LEO, è riprodotta la posizione ed ilcomportamento dei satelliti e dei detriti spaziali, inoltre sono calcolati itempi e le posizioni orbitali delle possibili collisioni. In questo modelloHLA non è stato specificato il tipo di software RTI utilizzato, dato chel’implementazione proposta è completamente indipendente da esso.

5.3.2 Federati coinvolti

In questa simulazione operano i seguenti federati:

• Simulatore di orbita e comportamento dei satelliti LEOGrazie ad esso sono simulate le orbite ed i dettagli della traiettoriadei satelliti LEO: ad ogni passo della simulazione questi valori sonorestituiti per essere analizzati.

5.3 simulazione collisioni orbitali 51

• Simulatore di detriti spazialiQuesto simulatore ha il compito di riprodurre l’orbita seguita da ungruppo di detriti spaziali. Nella federazione ci possono essere anchepiù federati di questo tipo, così da rappresentare una quantità didetriti maggiore.

• Simulatore delle orbite dei detriti generati dalle collisioniDopo una collisione tra due oggetti spaziali, si generano altri detriti;con questo federato sono riprodotte le orbite degli oggetti generatiin seguito ad un contatto.

• Software di ispezione delle collisioni e generazione di detritiQuesto federato ha il compito di verificare, in base ai dati ricevutidai simulatori di satelliti e detriti, se si presentano delle collisioni: intal caso esso calcola le informazioni dei detriti generati. Il federatoin questione ha anche l’incarico di iniziare, mettere in pausa eterminare l’intera simulazione.

• Strumento visualizzazionePermette di visualizzare grafici in due o tre dimensioni degli oggettiorbitanti.

• Strumento di raccolta datiRegistra le informazioni degli eventi d’interesse dell’intera simula-zione.

Figura 9: Rappresentazione dei diversi federati in comunicazione con L’RTI.


5.3.3 Modello ad oggetti

Le classi di interazioni condivise attraverso la federazione, che devonofungere da interfaccia tra i federati e l’RTI sono:

• Satellite, è una classe utilizzata per descrivere i dettagli dell’orbita,della posizione e della velocità di un satellite LEO.

• SpaceDebris, questa classe specifica la posizione e la velocità di certogruppo di detriti.

• LowOrbitalCollision, contiene le informazioni relative ad una collisio-ne.

• NewDebrisGeneration, indica il numero di detriti generati in seguitoad un impatto ed il momento in cui questo è avvenuto.

• SimControl, è una classe d’interazione le cui istanze sono sfruttatedai federati per gestire e sincronizzare correttamente la federazione.

Sono qui riportate le informazioni sulle interazioni tra i federati e glioggetti descritte col meccanismo publish, subscribe:

Simulatore di Simulatore/i di Software diClassi satelliti LEO di gruppi analisi collisioni e

di detriti generazione detriti

Satellite Publish SubscribeSpaceDebris Publish Subscribe

LowOrbitalCollision PublishNewDebrisGeneration Publish

SimControl Publish Publish PublishSubscribe Subscribe Subscribe

5.3 simulazione collisioni orbitali 53

Simulatore delle Strumento di Strumento diClassi orbite dei visualizzazione raccolta dati

detriti generati

Satellite Subscribe SubscribeSpaceDebris Publish Subscribe Subscribe

LowOrbitalCollision Subscribe SubscribeNewDebrisGeneration Subscribe Subscribe Subscribe

SimControl Publish Publish PublishSubscribe Subscribe Subscribe

5.3.4 Funzionamento della simulazione

L’esecuzione della simulazione si basa su due passi fondamentali, ripetutifino a che non si raggiunge un limite di tempo, che indica la fine dellaprova:

1. Tutta la simulazione avanza con un grande lasso temporale (∆ =0.02s), all’interno di esso vengono ricercati i segmenti di tempodove potrebbero avvenire delle collisioni. In tale passo (ti, ti +∆) ifederati eseguono le seguenti azioni in questo ordine:

• I federati di visualizzazione e raccolta di dati eseguono soltantooperazioni di sincronizzazione temporale.

• Il federato di simulazione dei satelliti LEO calcola ed invia laposizione dei satelliti agli oggetti di tipo Satellite. Il federatodella simulazione dei detriti ed il simulatore di delle orbitedei detriti generati, inviano le posizioni dei rispettivi corpisimulati ai vari SpaceDebris.

• Il federato incaricato di analizzare le collisioni e generare de-triti riceve i dati da Satellite e SpaceDebris; tramite essi comparala posizione dei satelliti con quella dei detriti. Nel caso in cui icorpi siano abbastanza vicini (distanza 6 360m), può accade-re una collisione e quindi si procede al passo 2, scandendo piùin dettaglio il segmento di tempo del possibile impatto. In casocontrario continua la ricerca ripetendo nuovamente il passo 1.

2. Nel segmento di tempo delle possibili collisioni, la simulazioneavanza di un intervallo temporale molto più piccolo rispetto alpasso 1 (δ = 0.0005s), non appena questo lasso di tempo è scandito


completamente torna al passo precedente. In ognuno di questipiccoli avanzamenti temporali (ti, ti + δ), vengono eseguite delleoperazioni di ricerca e di stima delle collisioni:

• Il federato di simulazione dei satelliti LEO calcola ed invia laposizione dei satelliti agli oggetti di tipo Satellite. Il federatodella simulazione dei detriti e quello delle orbite dei detritigenerati, inviano le posizioni dei rispettivi corpi simulati aivari SpaceDebris.

• I federati di raccolta dati, visualizzazione e di ispezione dellecollisioni e generazione detriti, ricevono tramite le interazioniSatellite e SpaceDebris i dati sulle varie posizioni. L’ultimo lianalizza e nel caso due corpi si trovino ad una distanza moltopiccola (distanza 6 9m), vengono studiate la posizione preci-sa e le informazioni sulla grandezza dei due oggetti, per poterdeterminare se avviene o meno un impatto. Nel caso di colli-sione i dati su di essa sono inviati all’istanzaLowOrbitalCollisione le informazioni sui detriti generati a NewDebrisGeneration.

• Se la collisione si verifica, il federato di simulazione delle or-bite dei detriti generati, in accordo con gli attributi letti daNewDebrisGeneration, crea nuove istanze di SpaceDebris coni dettagli dei nuovi detriti formati. I federati di raccolta in-formazioni e visualizzazione ricevono le specifiche relativeallo scontro da LowOrbitalCollision e alla generazione di nuovidetriti NewDebrisGeneration.

• Nel caso che il segmento di tempo della possibile collisionesia stato scandito completa

Scuola di Scienze Matematiche, Fisiche e Naturali Tesi di...

Documents

Transcript of Scuola di Scienze Matematiche, Fisiche e Naturali Tesi di...