SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita

SimArch
una architettura software
per lo sviluppo
di sistemi di simulazione distribuita
Andrea D’Ambrogio, Università di Roma TorVergata
Daniele Gianni, ESA ESTEC
Giuseppe Iazeolla, Università di Roma TorVergata
Alessandra Pieroni, Università di Roma TorVergata

Agenda
Ambienti di simulazione distribuita
SimArch: nostro ambiente di simulazione
distribuita
Confronto con approcci esistenti
Versioni di SimArch sviluppate

DSIMday'11 A. D'Ambrogio 2

La simulazione dei moderni sistemi
complessi (e.g., SoS, ULS) richiede un insieme
di risorse computazionali che potrebbero non
essere disponibili su un unico host
La simulazione distribuita fornisce uno
strumento per fronteggiare la necessità di
risorse computazionali
Tuttavia, l’uso degli attuali ambienti di
simulazione distribuita resta il maggior
ostacolo alla diffusione di tale approccio



Ad esempio, gli ambienti di simulazione
basati sullo standard IEEE High Level
Architecture (HLA) richiedono una notevole
expertise e un considerevole extraeffort per
lo sviluppo di un sistema DS (distributed
simulation) rispetto ad un equivalente
convenzionale sistema LS (local simulation)


Ambienti di simulazione DS esistenti:
HLA
HLA fornisce un framework generalizzato per la
simulazione distribuita
L’obiettivo principale è incrementare i livelli di
interoperabilità e riusabilità di componenti di
simulazione
Lo standard introduce i seguenti concetti:
◦ Federato: programma di simulazione che rappresenta il
componente da riusare.
◦ Federazione: esecuzione di una simulazione distribuita
composta da un insieme di federati
◦ Run Time Infrastructure (RTI): middleware simulation
oriented che consiste di componenti RTI Local, facenti parte
di ciascun federato, ed un RTI Executive, residente su un
server centrale

Ambienti di simulazione DS esistenti:
HLA
Rispetto ai precedenti standard protocoloriented
(DIS, ALSP, etc.) l’approccio HLA solleva lo
sviluppatore da ogni problematica riguardante la
comunicazione e la sincronizzazione dei federati,
ottenendo così un considerevole effort saving nel
processo di sviluppo
Nonostante tali miglioramenti, lo standard HLA
soffre ancora di tre principali problemi:
◦ la complessità di utilizzo delle API
◦ l’implementazione delle API strettamente orientata alla simulazione
distribuita
◦ l’assenza di protocolli di comunicazione standard tra RTI Local e RTI
Executive


SimArch: ambiente di simulazione DS

L’ambiente SimArch ha lo scopo di superare
queste difficoltà, permettendo allo
sviluppatore di ottenere:
◦ un sistema DS con lo stesso effort richiesto per lo
sviluppo di un equivalente sistema LS
◦ oppure ricavare senza effort un sistema DS da un
equivalente LS


Basato su una architettura a strati
Simulation Model Layer Layer 4

Simulation Component Layer Layer 3

Discrete Event Simulation
Service Layer Layer 2

Distributed Discrete Event
Simulation Layer Layer 1

Distributed Computing Layer 0
Infrastructure

DIS CORBA
WS HLA -HLA
CORBA
ALSP

General Purpose Simulation Oriented Mixed



SimArch elimina la necessità di knowhow
degli standard DS (e.g., HLA) e riduce l’extra
effort richiesto:
◦ per lo sviluppo ex novo di sistemi DS
◦ per lo sviluppo di sistemi DS derivati da sistemi
esistenti di simulazione locale (LS)


Gli strati di SimArch
Layer 0 ‐ Distributed Computing Infrastructure – Infrastruttura
per l’elaborazione distribuita:
◦ simulation‐oriented (HLA, DIS, ALSP)
◦ general‐purpose (CORBA, Web Services, Grid)
◦ hybrid (CORBA‐HLA o HLA‐Grid)
Layer 1 – Distributed Discrete Event Simulation abstraction ‐
implementazione dei servizi DS, si poggia sul layer 0 fornendo
servizi per:
◦ sincronizzazione tra simulatori in ambiente distribuito
◦ gestione degli eventi tra simulatori remoti
Layer 2 – Transparent DES abstraction ‐ execution container,
fornisce servizi, in modalità trasparente allo sviluppatore, per
simulazioni locali (LS) o distribuite (DS):
◦ sincronizzazione e gestione di eventi a livello di entità
◦ maschera allo sviluppatore del linguaggio (layer 3) l’ambiente di
esecuzione locale o distribuito

Gli strati di SimArch
Layer 3 – Domain‐specific language implementation
◦ nel dominio dei modelli EQN (Extended Queueing Network) il
linguaggio Javabased di simulazione implementato è
denominato jEQN
◦ qualsiasi altro tipo di dominio può essere preso in
considerazione, implementando i relativi componenti
Layer 4 – Simulation model specification
◦ descrizione del modello di simulazione che verrà eseguito dai
layer sottostanti
◦ specifica del modello di simulazione per mezzo di
istanziazione dei componenti implementati a layer 3
◦ esecuzione della simulazione invocando servizi (simulation
core services) offerti dai layer sottostanti


In accordo alle linee guida per lo sviluppo di sistemi
software, le interfacce tra i layer sono definite in
modo indipendente dall’implementazione dei layer
stessi
il contenuto di ciascun layer risulta dunque essere
intercambiabile per definizione
L’intercambiabilità dei layer SimArch consente di
avere alla base (layer 0) non solo infrastrutture
distribuite di tipo HLA o DIS (che sono simulation
oriented) ma anche infrastrutture distribuite di tipo
generalpurpose (e.g., CORBA, Web Services, Grid)

Interfacce
L’intercambiabilità tra i vari layer è ottenuta
definendo un insieme di:
◦ data interface per la definizione di oggetti (come
l’oggetto Time, o l’oggetto Event), che sono poi
scambiati come parametri delle service interface
◦ service interface per le comunicazioni tra layer
adiacenti


Data Interfaces
Le data interface definiscono le modalità di
accesso al dato che viene scambiato tra i vari
layer
Definendo strutture dati astratte anziché
concrete si decrementa il livello di coupling tra
i layer
Ciò permette di modificare l’implementazione
tra i layer senza alcun impatto sull’intera
architettura

Data Interfaces


Service Interfaces
Le service interface definiscono punti di
accesso per le comunicazioni tra layer
adiacenti
L’architettura di SimArch definisce un
insieme di interfacce, una per ciascuna coppia
di layer adiacenti
La notazione adottata è del tipo
LayerXtoLayerY per indicare l’interfaccia tra il
layer X ed il layer Y

Layer0ToLayer1 e Layer1ToLayer0
Interfaces
Le interfacce tra il layer 0 ed il layer 1
rispettano lo standard HLA e non dipendono
dalla specifica implementazione usata a
layer 0
Ciò rende le interfacce indipendenti
dall’implementazione RTI usata


Interfaces
L’interfaccia Layer2ToLayer1 abilita le comunicazioni
tra layer 2 e layer 1
L’interfaccia fornisce i seguenti servizi:
◦ initDistributedSimulationInfrastructure
◦ postProcessingDistributedSimulationInfrastructure
◦ sendEvent
◦ waitNextDistributedEvent
◦ waitNextDistributedEventBeforeTime


Interfaces
L’interfaccia Layer1ToLayer2 consente al layer 1 di
gestire localmente (nel federato) eventi distribuiti in
modalità del tutto trasparente allo sviluppatore
Al fine di disaccoppiare ulteriormente i due layer, il
servizio di scheduling è distinto in:
◦ scheduleEvent
◦ scheduleSimulationEndEvent


Interfaces
La comunicazione tra layer 3 e layer 2
avviente mediante l’interfaccia
Layer3ToLayer2
Tale interfaccia mette a disposizione:
◦ servizi useroriented
◦ servizi developeroriented


User Interfaces
La Layer3ToLayer2UserInterface fornisce i servizi che
consentono allo user (i.e., lo sviluppatore a layer 4) di
scrivere codice ed eseguire il simulatore
L’interfaccia fornisce un servizio di configurazione
(registerEntity) per consentire l’aggiunta di un
componente al simulatore ed un servizio per
l’attivazione (start) dell’execution container


Developer Interfaces

La Layer3ToLayer2UserInterface fornisce
servizi DES per costruire la logica di ciascun
componente


Layer2ToLayer3 Interface
La Layer2ToLayer3Interface definisce le
modalità di accesso del layer 2 verso i
componenti simulativi del layer3


Uso di HLA – extra effort
L’utilizzo dello standard HLA per la
implementazione di sistemi DS comporta un
extra effort rispetto al corrispondente
sistema LS
Sulla base di vari esperimenti e lavori è stato
possibile quantificare l’extra‐effort
necessario alla progettazione di sistemi DS


Costi di HLA
HLA knowhow e abilità richieste
◦ 30% extra effort necessario per sviluppatori con esperienza
media
◦ 60% extra effort necessario per sviluppatori privi di
esperienza
HLA extra code effort (circa 3.5kLOC per federato)
Necessità di prendere decisioni ed effettuare scelte
progettuali
◦ Quale federato deve essere sviluppato? Quale può essere
riutilizzato?
◦ Quale modalità di avanzamento del tempo adottare?
◦ Quali dati devono essere scambiati e con chi?
◦ Quali modalità di comunicazione utilizzare?


Vantaggi dell’uso SimArch
L’uso dell’ambiente SimArch supera gli
ostacoli imposti dall’utilizzo di HLA, in
quanto:
◦ non richiede alcuna conoscenza di HLA (o di altri
standard DS)
◦ non richiede conoscenze aggiuntive rispetto allo
sviluppo di un convenzionale sistema LS
◦ introduce una procedura automatica per derivare
un sistema DS da uno LS
◦ fornisce un linguaggio domainspecific e Javabased


SimArch e stateoftheart
Ambienti DS esistenti wrt SimArch:
◦ PDNS
application domain dependent
richiede l’uso di ghost nodes per rappresentare localmente
le connessioni ad entità remote
◦ DisSimJava
nessuna sincronizzazione tra entità
implementazione non HLAcompliant
◦ DEVS/HLA
difficile transizione da sistema LS a sistema DS
interfacce di comunicazione tra layer non documentate


SimArch e stateoftheart
Linguaggi di simulazione esistenti (QNAP,
JMT, Extend, OMNET++, etc.) wrt jEQN, il
linguaggio fornito da SimArch
◦ creati ed usati per sistemi LS
◦ di difficile estensione a DS:
meccanismi di estensione basati su techniche di wrapping,
con conseguente instabilità e scarsa manutenibilità
difficile, se non impossibile, partizionare ed eseguire un
sistema LS su un ambiente DS (e.g., HLA)


Modello di riferimento
(per confronto con approcci esistenti)


Approccio di tipo1 (uso di un linguaggio di
programmazione generalpurpose come Java + HLA)
◦ Per il modello di riferimento, la dimensione della versione LS
è di 1.2 KLOC
◦ La trasformazione da LS ad una equivalente DS basato su
HLA, richiede addizionali 3.5 KLOC per federato. Quindi, la
versione DS avrà dimensione pari a 1.2 + 3x3.5 = 11.7 KLOC
Approccio di tipo2 (uso di un framework di
simulazione come SimJava o JavaSim)
◦ La dimensione della versione LS dello stesso modello di
riferimento può essere stimata intorno alle 0.5 KLOC
◦ La trasformazione in versione DS basato su HLA è
problematica in quanto detti framework sono progettati per
operare in modalità LS

Approccio di tipo3 (uso di un linguaggio di
simulazione di alto livello come ad esempio QNAP)
◦ Comporta, per il modello di riferimento, una dimensione della
versione LS di circa 0.1 KLOC
◦ La relativa versione DS è irrealizzabile in quanto la
descrizione del sistema LS prevista dal linguaggio risulta
essere fortemente dipendente dallo stesso e pertanto resta
impossibile convertire un sistema LS in un DS, ad esempio
tramite HLA


Nostro approccio
Approccio di tipo4 (SimArch e jEQN)
◦ Per la simulazione del modello di riferimento, si
ottiene una sostanziale riduzione di linee di codice
sia nella forma LS che DS
◦ La dimensione LS risulta essere 0.08 KLOC
◦ La dimensione DS ha un incremento di LOC di
0.02 KLOC per l’insieme dei tre federati, ottenendo
così una dimensione totale di 0.1 KLOC
◦ La conversione da LS a DS è meccanica e facilmente
automatizzabile


Confronto approcci

Dimensione codice di simulazione
Tipo Approccio modello di rif. (KLOC)
versione LS versione DS
Tipo 1
1.2 3.5 + 1.2 = 4.7
(General Purpose Language)
Tipo 2 instabilità e scarsa
0.5
(Local Simulation Framework) manutenibilità
Tipo 3
0.08 N/A
(Hi‐level Simulation Language)
Tipo 4
0.08 0.08 + 0.02 = 0.1
(SimArch e jEQN)


Versioni di SimArch
Le versioni di SimArch finora sviluppate
possono essere così raggruppate:
◦ generalpurpose SimArch
◦ domainspecific SimArch
nDSSimArch
wSimArch


Riferimenti
A. D'Ambrogio, D. Gianni, G. Iazeolla, “jEQN: a Java-based Language for the Distributed Simulation of Queueing
Networks”, LNCS vol. 4263/2006, Proceedings of the 21st International Symposium on Computer and Information
Sciences (ISCIS'06), Istanbul, Turkey, November 1-3, 2006.
A. D'Ambrogio, D. Gianni, G. Iazeolla, “SimJ: A Framework to Develop Distributed Simulators”, Proceedings of the
2006 Summer Computer Simulation Conference, Calgary, Canada, July 31 – August 2, 2006.
D. Gianni, A. D’Ambrogio, “A Language to Enable Distributed Simulation of Extended Queueing Networks”, Journal of
Computers, Vol. 2 n. 4, pp. 76-86, Academy Publisher, ISSN : 1796-203X, June 2007.
A. D’Ambrogio, D. Gianni, G. Iazeolla, “Software Technologies for the Interoperability, Reusability and Adaptability of
Distributed Simulators”, Proceedings of the European Simulation Interoperability Workshop (EuroSIW 2007), Genoa,
Italy, June 18-20, 2007.
D. Gianni, A. D'Ambrogio, “A Domain Specific Language for the Definition of Extended Queueing Network Models”,
Proceedings of the 26th Iasted International Conference on Software Engineering (SE 2008), Innsbruck (Austria),
February 12-14, 2008.
D. Gianni, A. D’Ambrogio, G. Iazeolla, “A Layered Architecture for the Model-driven Development of Distributed
Simulators”, Proceedings of the First International Conference on Simulation Tools and Techniques for
Communications, Networks and Systems (Simutools 2008), Marseille, France, March 3-7, 2008.
D. Gianni, A. D’Ambrogio, G. Iazeolla, A. Pieroni, “Producing simulation sequences by use of a Java-based
generalized framework”, Proceedings of the IEEE Second UKSIM European Symposium on Computer Modeling and
Simulation (EMS 2008), Liverpool (UK), September 8–10, 2008.
D. Gianni, A. D’Ambrogio, G. Iazeolla, A. Pieroni, “Distributed Simulation of Complex Systems by Use of an HLA-
transparent Simulation Language”, Proceedings of the 7th International Conference on System Simulation and
Scientific Computing (ICSC’2008), Beijing, China October 10–12, 2008.
D. Gianni, A. D’Ambrogio, G. Iazeolla, “DisSimJADE: A framework for the development of Agent-based Distributed
Simulation Systems”, Proceedings of the Second International Conference on Simulation Tools and Techniques
(SIMUTools 2009), Rome, Italy, March 2-6, 2009.
D. Gianni, A. D’Ambrogio, and G. Iazeolla, “Ontology-based Specification of Simulation Sequences”, International
Journal of Simulation Systems, Science & Technology, vol. 10, n. 1b, September 2009.
D. Gianni, A. D’Ambrogio, G. Iazeolla and A. Pieroni, "HLA-Transparent Distributed Simulation of Agent-based
Systems", in Modeling Simulation and Optimization - Focus on Applications, Shkelzen Cakaj (Ed.), ISBN: 978-953-
307-055-1, INTECH, pp. 205-223, 2010.
D. Gianni, A. D’Ambrogio, G. Iazeolla, “Software Technologies for the effortless development of distributed
simulators”, SIMULATION: Transactions of The Society for Modeling and Simulation International, in press, 2011.


Grazie per l’attenzione!


Acknowledgments
Work partially supported by funds from the
FIRB project on “Software frameworks and
technologies for distributed simulation”, from
the FIRB project on “Performance evaluation
of complex systems”, from the University of
Rome TorVergata research on “Performance
modeling of service‐oriented architectures”
and from the CERTIA Research Center.


SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita

Similar to SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita (20)

More from Daniele Gianni

More from Daniele Gianni (13)

SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita