SimArch: un'architectura software per lo sviluppo di sistemi di simulatione distribuita
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 465 views

Workshop presentation in DSim Day, research event on Distributed Simulation, Rome, Italy, March, 2010.

Workshop presentation in DSim Day, research event on Distributed Simulation, Rome, Italy, March, 2010.

Statistics

Views

Total Views
465
Views on SlideShare
465
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 1. SimArchuna architettura softwareper lo sviluppodi sistemi di simulazione distribuitaAndrea D’Ambrogio, Università di Roma TorVergataDaniele Gianni, ESA ESTECGiuseppe Iazeolla, Università di Roma TorVergataAlessandra Pieroni, Università di Roma TorVergata
  • 2. Agenda Ambienti di simulazione distribuita SimArch: nostro ambiente di simulazione  distribuita Confronto con approcci esistenti Versioni di SimArch sviluppateDSIMday11 A. DAmbrogio 2
  • 3. Ambienti 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 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 approccioDSIMday11 A. DAmbrogio 3
  • 4. Ambienti di simulazione distribuita Ad esempio, gli ambienti di simulazione  basati sullo standard IEEE High Level  Architecture (HLA) richiedono una notevole  expertise e un considerevole extra­effort per  lo sviluppo di un sistema DS (distributed  simulation) rispetto ad un equivalente  convenzionale sistema LS (local simulation)DSIMday11 A. DAmbrogio 4
  • 5. 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 centraleDSIMday11 A. DAmbrogio 5
  • 6. Ambienti di simulazione DS esistenti: HLA Rispetto ai precedenti standard protocol­oriented  (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 DSIMday11 A. DAmbrogio 6
  • 7. 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 LSDSIMday11 A. DAmbrogio 7
  • 8. SimArch: ambiente di simulazione DS  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 MixedDSIMday11 A. DAmbrogio 8
  • 9. SimArch: ambiente di simulazione DS SimArch elimina la necessità di know­how  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)  DSIMday11 A. DAmbrogio 9
  • 10. 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 distribuitoDSIMday11 A. DAmbrogio 10
  • 11. Gli strati di SimArch Layer 3 – Domain‐specific language implementation ◦ nel dominio dei modelli EQN (Extended Queueing Network) il  linguaggio Java­based 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 sottostantiDSIMday11 A. DAmbrogio 11
  • 12. SimArch: ambiente di simulazione DS 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  general­purpose (e.g., CORBA, Web Services, Grid) DSIMday11 A. DAmbrogio 12
  • 13. 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 adiacentiDSIMday11 A. DAmbrogio 13
  • 14. 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  architetturaDSIMday11 A. DAmbrogio 14
  • 15. Data InterfacesDSIMday11 A. DAmbrogio 15
  • 16. 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 YDSIMday11 A. DAmbrogio 16
  • 17. 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 usataDSIMday11 A. DAmbrogio 17
  • 18. Layer2ToLayer1 e Layer1ToLayer2  Interfaces L’interfaccia Layer2ToLayer1 abilita le comunicazioni  tra layer 2 e layer 1 L’interfaccia fornisce i seguenti servizi: ◦ initDistributedSimulationInfrastructure ◦ postProcessingDistributedSimulationInfrastructure ◦ sendEvent ◦ waitNextDistributedEvent ◦ waitNextDistributedEventBeforeTimeDSIMday11 A. DAmbrogio 18
  • 19. Layer2ToLayer1 e Layer1ToLayer2  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 ◦ scheduleSimulationEndEventDSIMday11 A. DAmbrogio 19
  • 20. Layer3ToLayer2 e Layer2ToLayer3  Interfaces La comunicazione tra layer 3 e layer 2 avviente mediante l’interfaccia  Layer3ToLayer2  Tale interfaccia mette a disposizione: ◦ servizi user­oriented ◦ servizi developer­orientedDSIMday11 A. DAmbrogio 20
  • 21. Layer3ToLayer2 e Layer2ToLayer3  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 containerDSIMday11 A. DAmbrogio 21
  • 22. Layer3ToLayer2 e Layer2ToLayer3  Developer Interfaces La Layer3ToLayer2UserInterface fornisce  servizi DES per costruire la logica di ciascun  componenteDSIMday11 A. DAmbrogio 22
  • 23. Layer2ToLayer3 Interface La Layer2ToLayer3Interface definisce le  modalità di accesso del layer 2 verso i  componenti simulativi del layer3DSIMday11 A. DAmbrogio 23
  • 24. 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 DSDSIMday11 A. DAmbrogio 24
  • 25. Costi di HLA  HLA know­how 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?DSIMday11 A. DAmbrogio 25
  • 26. 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 domain­specific e Java­basedDSIMday11 A. DAmbrogio 26
  • 27. SimArch e state­of­the­art 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 HLA­compliant ◦ DEVS/HLA  difficile transizione da sistema LS a sistema DS interfacce di comunicazione tra layer non documentateDSIMday11 A. DAmbrogio 27
  • 28. SimArch e state­of­the­art 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)DSIMday11 A. DAmbrogio 28
  • 29. Modello di riferimento (per confronto con approcci esistenti)DSIMday11 A. DAmbrogio 29
  • 30. Confronto con approcci esistenti Approccio di tipo1 (uso di un linguaggio di  programmazione general­purpose 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 DSIMday11 A. DAmbrogio 30
  • 31. Confronto con approcci esistenti 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 HLADSIMday11 A. DAmbrogio 31
  • 32. 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  automatizzabileDSIMday11 A. DAmbrogio 32
  • 33. 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)DSIMday11 A. DAmbrogio 33
  • 34. Versioni di SimArch Le versioni di SimArch finora sviluppate  possono essere così raggruppate: ◦ general­purpose SimArch ◦ domain­specific SimArch nDSSimArch wSimArchDSIMday11 A. DAmbrogio 34
  • 35. RiferimentiA. DAmbrogio, D. Gianni, G. Iazeolla, “jEQN: a Java-based Language for the Distributed Simulation of QueueingNetworks”, LNCS vol. 4263/2006, Proceedings of the 21st International Symposium on Computer and InformationSciences (ISCIS06), Istanbul, Turkey, November 1-3, 2006.A. DAmbrogio, D. Gianni, G. Iazeolla, “SimJ: A Framework to Develop Distributed Simulators”, Proceedings of the2006 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 ofComputers, 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 ofDistributed Simulators”, Proceedings of the European Simulation Interoperability Workshop (EuroSIW 2007), Genoa,Italy, June 18-20, 2007.D. Gianni, A. DAmbrogio, “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 DistributedSimulators”, Proceedings of the First International Conference on Simulation Tools and Techniques forCommunications, 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-basedgeneralized framework”, Proceedings of the IEEE Second UKSIM European Symposium on Computer Modeling andSimulation (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 andScientific 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 DistributedSimulation 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”, InternationalJournal 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-basedSystems", 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 distributedsimulators”, SIMULATION: Transactions of The Society for Modeling and Simulation International, in press, 2011.DSIMday11 A. DAmbrogio 35
  • 36. Grazie per l’attenzione!DSIMday11 A. DAmbrogio 36
  • 37. 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.DSIMday11 A. DAmbrogio 37