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

SimArchSimArchuna architettura softwareuna architettura softwareper lo sviluppoper lo sviluppodi sistemi di simulazione distribuitadi sistemi di simulazione distribuitaAndrea D’Ambrogio, Università di Roma TorVergataDaniele Gianni, ESA ESTECGiuseppe Iazeolla, Università di Roma TorVergataAlessandra Pieroni, Università di Roma TorVergata

AgendaAgendaAmbienti di simulazione distribuitaSimArch: nostro ambiente di simulazione distribuitaConfronto con approcci esistentiVersioni di SimArch sviluppate

DSIMday'11 A. D'Ambrogio 2

Ambienti di simulazione distribuitaAmbienti di simulazione distribuita

La simulazione dei moderni sistemi complessi (e.g., SoS, ULS) richiede un insieme di risorse computazionali che potrebbero non essere disponibili su un unico hostLa 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


Ambienti di simulazione distribuitaAmbienti di simulazione distribuita

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:Ambienti di simulazione DS esistenti:HLAHLA

HLA fornisce un framework generalizzato per la simulazione distribuitaL’obiettivo principale è incrementare i livelli di interoperabilità e riusabilità di componenti di simulazioneLo 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 simulationoriented 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:Ambienti di simulazione DS esistenti:HLAHLA

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 sviluppoNonostante 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


SimArchSimArch: ambiente di simulazione DS : 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


SimArchSimArch: ambiente di simulazione DS : ambiente di simulazione DS Basato su una architettura a strati


Simulation Model Layer

Simulation Component Layer

Discrete Event Simulation Service Layer

Distributed Discrete Event Simulation Layer

Distributed Computing Infrastructure

Layer 4

Layer 3

Layer 2

Layer 1

Layer 0

CORBA WS HLA DIS

ALSP

CORBA-HLA

General Purpose Simulation Oriented Mixed

SimArchSimArch: ambiente di simulazione DS: ambiente di simulazione DS

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 Gli strati di SimArchSimArchLayer 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 Gli strati di SimArchSimArchLayer 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


SimArchSimArch: ambiente di simulazione DS: ambiente di simulazione DSIn accordo alle linee guida per lo sviluppo di sistemi software, le interfacce tra i layer sono definite in modo indipendente dall’implementazione dei layerstessi

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 simulationoriented) ma anche infrastrutture distribuite di tipo generalpurpose (e.g., CORBA, Web Services, Grid)


InterfacceInterfacceL’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 layeradiacenti


Data Data InterfacesInterfacesLe 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 layerCiò permette di modificare l’implementazione tra i layer senza alcun impatto sull’intera architettura


Data Data InterfacesInterfaces


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


Layer0ToLayer1 e Layer1ToLayer0 Layer0ToLayer1 e Layer1ToLayer0 InterfacesInterfaces

Le interfacce tra il layer 0 ed il layer 1rispettano lo standard HLA e non dipendono dalla specifica implementazione usata alayer 0

Ciò rende le interfacce indipendenti dall’implementazione RTI usata



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



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



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


Layer3ToLayer2 e Layer2ToLayer3 Layer3ToLayer2 e Layer2ToLayer3 User User InterfacesInterfaces

La Layer3ToLayer2UserInterface fornisce i servizi che consentono allo user (i.e., lo sviluppatore a layer 4) di scrivere codice ed eseguire il simulatoreL’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


Layer3ToLayer2 e Layer2ToLayer3 Layer3ToLayer2 e Layer2ToLayer3 Developer Developer InterfacesInterfaces

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


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


Uso di HLA Uso di HLA –– extra extra efforteffort

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 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 dellVantaggi dell’’uso uso SimArchSimArchL’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


SimArchSimArch e e statestateofofthetheartart

Ambienti DS esistenti wrt SimArch:◦ PDNS

application domain dependent

richiede l’uso di ghost nodes per rappresentare localmente le connessioni ad entità remote

◦ DisSimJavanessuna sincronizzazione tra entitàimplementazione non HLAcompliant

◦ DEVS/HLA difficile transizione da sistema LS a sistema DSinterfacce di comunicazione tra layer non documentate


SimArchSimArch e e statestateofofthetheartart

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 riferimentoModello di riferimento(per confronto con approcci esistenti)(per confronto con approcci esistenti)

DSIMday'11 29A. D'Ambrogio

Confronto con approcci esistentiConfronto con approcci esistentiApproccio 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


Confronto con approcci esistentiConfronto con approcci esistentiApproccio 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 approccioNostro approccioApproccio 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 approcciConfronto approcci


Tipo�Approccio�Dimensione�codice�di�simulazione�

modello�di�rif.�(KLOC)�versione�LS� versione�DS�

Tipo�1��(General Purpose Language) 1.2 3.5 + 1.2 = 4.7

Tipo�2�(Local Simulation Framework) 0.5 instabilità e scarsa

manutenibilitàTipo�3��

(Hi‐level Simulation Language) 0.08 N/A

Tipo�4��(SimArch e jEQN) 0.08 0.08 + 0.02 = 0.1

�

Versioni di Versioni di SimArchSimArchLe versioni di SimArch finora sviluppate possono essere così raggruppate:◦ generalpurpose SimArch◦ domainspecific SimArch


wSimArchnDSSimArch

RiferimentiRiferimentiA. 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 lGrazie per l’’attenzione!attenzione!

AcknowledgmentsAcknowledgmentsWork 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

Documents