Middleware Solutions for Integrated       Simulation Environments                             Leila Jalali                ...
Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulat...
Introduction                                                                           1 Simulation: the process of desig...
Motivation for New SimulationPlatforms Many available simulators    Operate on specific domains      e.g fire simulator...
Simulation Integration- historicalviewDistributed Interactive Simulation (DIS)        High Level Architecture (HLA)       ...
Current approaches       DIS 1990                  ALSP 1991                                       HLA 1996 not fully    ...
General Challenges Managing Complexity of Interoperating Systems    Analysis of cause- effect relationships Correctness...
General Challenges- Our Focus Managing Complexity of Interoperating Systems    Analysis of cause- effect relationships ...
Autonomous simulators with                                                                                                ...
Complex analysis                                                        smart decisions              using multisimulation...
Complex analysis                                                                    smart decisions              using mul...
Reflective Architecture for IntegratedSimulation Environments- RAISE                                                      ...
RAISE Methodology Developer(integrator)                                                              Meta level           ...
RAISE Methodology (cont.) Developer(integrator)                                                              Meta level   ...
RAISE Methodology (cont.) Developer                                                                 Decision-maker(integra...
Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulat...
The Synchronization Challenge  Ensuring causal correctness in concurrently     executing simulators while preserving simu...
Time Synchronization- relatedwork  Time           In distributed            In networks          In distributed  Synchroni...
Time Synchronization Challenges (1) Different simulators represent time differently and implement varying time advancement...
Meta-Synchronization Model                                                                 Multisimulation                ...
Dependencies       Internal actions vs. External actions         External actions access at least one data item which i...
Dependency Preservation inSchedules  11/28/2012   Leila Jalali                             22   Distributed Systems Middl...
Schedule Example                                            Formal Definition: back-up slides 11/28/2012   Leila Jalali  ...
Synchronization Protocol                              Base-level              Wrappers                                    ...
Synchronization Protocol                              Base-level              Wrappers                                    ...
Synchronization Protocol                              Base-level              Wrappers                                    ...
Solutions to Synch. problem   11/28/2012   Leila Jalali                             27   Distributed Systems Middleware  ...
Lock Step Strategy   Lock-step Scheduling: the most conservative      approach by having a lock step schedule        All...
Conservative Strategy                              current time=ti                                                  ...  ...
Optimistic Strategy  External actions from different simulations are allowed   whenever they are requested  We accept th...
Effectiveness of Scheduling Strategies  Conservative and optimistic strategies may      become more (or less) effective a...
A Cost-Driven Hybrid SchedulingStrategy  Combines the benefits of both the conservative and     optimistic strategies    ...
How to make the decision?                                   duration of time that Sj may receive an update from Si that re...
How to make the decision?                                   duration of time that Sj may receive an update from Si that re...
Computing the costs  11/28/2012   Leila Jalali                             35   Distributed Systems Middleware           ...
Probability of abort                                                            Back-up Slides 11/28/2012   Leila Jalali ...
Optimization1: Checkpointing and Rollback mechanism         Abort operation in multisimulations is not always            ...
Optimization 2: RelaxingDependencies                            smok                                      t-bound=5 s    ...
A Case Study for simulationintegration To validate the proposed reflective architecture Using three disparate pre-existi...
Experiments: Integrating three simulators usingRAISE                                          2. Communication Simulator: ...
Case study- simulators properties  Evacuation Simulator           Communication                  Fire Simulator           ...
Experiments                                   Intermediate Phase                                                          ...
Experiments- dependencies                                                                                                 ...
Experiments- different simulators  Synchronization overhead and Total execution time of   different simulators CFAST, Dri...
Experiments- checkpointing & rollback  Drillsim (activity simulator) has been modified to     develop checkpointing mecha...
Experiments- relaxations Strategy                    CS                    OS                      HS Metric           Wit...
Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulat...
Data Exchange Problem   • How to exchange/tranform the information among simulators in     multisimulations execution   • ...
Pipeline vs. Concurrent executionPipeline execution :                                 Concurrent execution :• Execute the ...
Our Goal• Goal: During the concurrent execution of multiple simulators,  transform the data generated/updated by simulator...
Useful approaches for data exchange  Data Exchange in HLA                          Schema Mapping                         ...
Model Transformations• Convertors can be combined to support a transformation• One-to -one mapping from one data item in a...
Transformation Graph     •     One data item can involve in many dependencies     •     We consider one-to-many mapping th...
Cost Model    54       Distributed Systems Middleware Group
Transformation problem Transform a single source data item to a single target data  item    Consider one dependency betw...
Transformation (one-to-one)• Transform a single source data item to a single  target data item    Consider one dependency...
Transformation (one-to-all) Transform a single source data item to all target  data items   Consider all the dependencie...
Transformation (one-to-many) Transform a single source data item - multiple target data  items    Consider some of the d...
Transformation problem: our focus Given a transformation graph find a  transformation plan with minimum total  cost from ...
TR Problem in Small TG• In multisimulations, in some of real world scenarios the  size of transformation graph and the num...
TR Problem in Small TG (cont.)Optimal TR for small transformation graphs                                             61   ...
TR problem in large TG• In multisimulations, in some scenarios the size  of transformation graph and the number of target ...
TR problem in large TG (cont.)IterativeTR for large transformation graphs1.  Input: P: The initial plan, K: Number of iter...
An emergency response usecase                                                     smoke                                   ...
Geographies registered in the case study:         Simulator     Type            Entity Types                        Descri...
Transformations Graphs                                          cell-to-polygon       walking      mph-to-km/h            ...
Transformations ResultsTransformation   Convertor   Total num.   Total time     Avg. time     Avg. Transformation     Avg....
Experiment set up- large graphs• The default value for α and β is set to one in the cost function  meaning that the commun...
Experiment Results        69      Distributed Systems Middleware Group
Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulat...
HLA and MultisimulationsCriterion                           HLA                                     MultisimulationsObject...
Conclusion and Future work  Contributions:        1. Architecture for simulation integration                A methodolog...
Thanks                                    jalalil@uci.edu                            http://www.ics.uci.edu/~ljalali/     ...
Back-up slides                                         Distributed Systems Middleware11/28/2012   Leila Jalali            ...
Checkpoiting protocol                                                      Back to main slide 11/28/2012   Leila Jalali  ...
Checkpoiting protocol (cont.)                                                     Back to main slide 11/28/2012   Leila Ja...
Rollback using checkpoints        Restart from a checkpoint             • S2 restarts from t=0log                        ...
Simulator restarts        S2 aborts because of the update received from S1        S3 aborts because of the update receiv...
Proof of reduction          Membership of ST in NP: trivial          Hardness: take instance G=(V,E), k of Vertex       ...
Approximation algorithms          Several different algorithms that guarantee ratio 2           (or, more precise: 2 – 2/...
Data Transformations in concurrentexecution                                                            Back to main slide...
 Pyramid of specifications: Observe-Analyze-Adapt cycle (i) Observe changes in desired attributes of independently  exe...
Using Formal Specifications                                                                          b. System analyzera. ...
Modeling Multisimulations in Maude       Multisimulations concept               Maude concept      A simulator            ...
The Maude Rewriting Language         Developed at SRI         Maximizes simplicity (only equations and rules), Performan...
Using FS to choose a simulator                                              2. What kind of simulator is appropriate? Deve...
Using FS to choose a simulator2. What kind of simulator is appropriate?(1) Macroscopic (macro) models (e.g. Strada, Metaco...
Using FS to add a relationshipMuade Specifications                                                                        ...
Multisimulation configuration  11/28/2012   Leila Jalali                             89   Distributed Systems Middleware ...
Configurations transitions                                                    Back to main slide11/28/2012   Leila Jalali...
Using capabilities of Maude As the multisimulation system grows, consistency checks  become more important Using the ref...
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Integrated Simulation Environments
Upcoming SlideShare
Loading in …5
×

Integrated Simulation Environments

1,812 views

Published on

The focus of the presentation is to develop a framework and platform that supports the integration of multiple models, simulations, and data. My aim is to develop methods to integrate a set of simulated environments to make it possible to combine various independent simulators, developed by different domain experts. This would make it possible for researchers to build complex, multi-domain simulations by integrating existing and well-established simulators, so they can explore different alternatives and conduct low cost experiments.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,812
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • e.g. 1. flight training simulators in defence developed by DoD2. INLET : the first real-time online earthquake loss estimation tool by Imagecat UCI others: HAZUS from FEMA for Estimating Potential Losses from Disasters 3. VISSIM: multi modal traffic flow modeling by PTV in Germany, others: PARAMICS,4. Drillsim: evacuation simulator by UCI5. Network simulator: ns2, qualnet6. Fire fighter traning simulators: e.g. Fireblast:Advanced Live Fire Training Simulator from FireBlast Inc.
  • DIS based on SIMnetInformation exchange over an internetwork in the form of standardized protocol data units (PDUs) Best for small-scale exercises on LANsALSP Incorporated time management technology to ensure a consistent world state in the face ofOut-of-order message deliveryWidely varying latency
  • not fully distributedeach message must be received and treated by each node, which clutter thebandwidth even though not a lot of data is transmitteddoes not manage latency and causality that madethe reusability of simulations impossible. no time management service was incorporated which caused data losses due to therejection of too old packetsstrong foundations for distributed real-time simulationHLA: Existing Integrated platforms, define a standard model and The approaches are costly, time consuming, easily fail, difficult to maintain, difficult to scaleHLA-based network simulation for interactive communication systemOPNET [27], JAVAGPSS [28], DEVSJAVA [29], and PIOVRA uses a custom developed domain-specificmodeling language (DSML) for the definition of integrationmodels
  • RAISEPyramid showing summary of specifications. The three levels indicates (a) a detailed base-level view that specifies simulators, (b) a multisimulation wide view with integration modules and abstract properties extracted from the underlying base-level simulators, (c) the end view point from the perspective of the complex analysis using underlying multisimulations.
  • Should have top user level indicating what is needed – decision support…..
  • RAISEPyramid showing summary of specifications. The three levels indicates (a) a detailed base-level view that specifies simulators, (b) a multisimulation wide view with integration modules and abstract properties extracted from the underlying base-level simulators, (c) the end view point from the perspective of the complex analysis using underlying multisimulations.
  • This is a very interesting research proposal that will requireknowledge in various domains: simulation, middleware technology,software engineering. and databases!
  • modified features of integration are reflected back to the base-level
  • modified features of integration are reflected back to the base-level
  • Example illustrates how causality violations may occur in concurrently executing simulators without an effective time synchronizationConsider a fire simulator that communicates to other simulators, say, agents in activity simulators that are capable of extinguishing the fire. Without correct ordering of actions across simulators, the visualization interface might show that an agent extinguished the fire before the fire event started! Synchronization is complicated by the fact that integrating simulators may represent time differently and implement varying time advancement mechanisms.
  • Time stepped Simulators: for each execution of the main control loop the simulation time is incremented by one quantum of time Δt. Event-based Simulators: execution is driven by an event list, E=emm=1,2,…, each event has a time stamp (usually causality preserving) and the simulation time jumps from one event time stamp to the next without representing all the values in between. Time stepped Simulators:for each execution of the main control loop the simulation time is incremented by one quantum of time Δt. Event-based Simulators: execution is driven by an event list, E={e_m│m=1,2,…}, each event has a time stamp (usually causality preserving) and the simulation time jumps from one event time stamp to the next without representing all the values in between.
  • Dependencies enable us to partition the set of data items at a simulator, 𝐷𝑖, into local data items, 𝐿𝐷𝑖, and interdependent data items, 𝐼𝐷𝑖, such that 𝐿𝐷𝑖∩𝐼𝐷𝑖=∅ and 𝐷𝑖=𝐿𝐷𝑖∪𝐼𝐷𝑖Internal actions : actions that read or modify only the portion of data that is local to the simulatorExternal actions: access at least one data item which is an interdependent data itemDependencies enable us to partition the set of data items at a simulator, 𝐷_𝑖, into local data items, 𝐿𝐷_𝑖, and interdependent data items, 〖𝐼𝐷〗_𝑖, such that 〖𝐿𝐷〗_𝑖∩〖𝐼𝐷〗_𝑖=∅ and 𝐷_𝑖=〖𝐿𝐷〗_𝑖∪〖𝐼𝐷〗_𝑖Internal actions, 〖𝐼𝐴〗_𝑖: actions that read or modify only the portion of data that is local to the simulatorExternal actions, 〖𝐸𝐴〗_𝑖: access at least one data item which is an interdependent data item
  • .
  • The meta-synchronizer can make an informed decision about an action based on 𝐸𝐶𝐷, the expected cost of conservatively scheduling (delay), and 𝐸𝐶𝐴, the expected cost of optimistically scheduling (abort or rollback). Maintain statistics that help for decision making. Compute probability of the abort or rollback if the action is unsafe,the cost of abort or rollback, the cost of unnecessary delayThen make an informed decision: details in the paperThe meta-synchronizer can make an informed decision about an action based on 〖𝐸𝐶〗_𝐷, the expected cost of conservatively scheduling (delay), and 〖𝐸𝐶〗_𝐴, the expected cost of optimistically scheduling (abort or rollback). Maintain statistics that help for decision making. Computeprobability of the abort or rollback if the action is unsafe,the cost of abort or rollback, the cost of unnecessary delayThen make an informed decision: details in the paper
  • Abort: if 𝑆𝑗 receives an update from a simulator 𝑆𝑖𝜖 𝐷𝑒𝑝(𝑆𝑗) via a meta-action <𝑚𝑎𝑑𝑖,𝑑𝑗,𝑡𝑠′> such that: 𝑡𝑠′<𝑡𝑗. We consider 𝑚𝑎𝑥(0,𝑡𝑗−𝑡𝑖) because we are only interested in those simulators in 𝑆𝑗’s dependency set lagging behind the time in 𝑆𝑗. if  𝐸𝐶𝐷(𝑎𝑘)<𝐸𝐶𝐴(𝑎𝑘) the action will be delayed:𝐶𝐷<𝑝𝐴(1−𝑝𝐴) .𝐶𝐴𝐶𝐷=𝑎𝑗∈𝐴𝑑𝑢𝑑𝑡𝑑𝑢𝑗𝐶𝐴=𝑡𝑗−𝑡𝑑𝑙or with checkpointing :𝐶𝐴=𝐶𝑅=𝑡𝑗−𝑡𝑑𝑙𝑗−𝑡𝑐h𝑘𝑛+𝐶𝐶𝐻𝐾𝑗𝑝𝐴=𝑆𝑖𝜖 𝐷𝑒𝑝(𝑆𝑗)𝑖𝑒𝑥𝑝 [−𝑛𝑖𝑗𝑢𝑝𝑑𝑎𝑡𝑒𝑠.𝑚𝑎𝑥(0,𝑡𝑗−𝑡𝑖)𝑡𝑖]We consider 𝑚𝑎𝑥(0,𝑡_𝑗−𝑡_𝑖) because we are only interested in those simulators in 𝑆_𝑗’s dependency set lagging behind the time in 𝑆_𝑗.
  • Cost of rollback to the last checkpoint:𝐶𝑅=𝑡𝑗−𝑡𝑑𝑙𝑗−𝑡𝑐h𝑘𝑛+𝐶𝐶𝐻𝐾𝑗𝑡𝑑𝑙𝑗 : the time in between the simulator spent in delay𝐶𝐶𝐻𝐾𝑗: the overhead for storing/checkpointingCost of rollback to the last checkpoint:𝐶_𝑅=𝑡_𝑗−𝑡_(〖𝑑𝑙〗_𝑗 )−𝑡_(〖𝑐ℎ𝑘〗_𝑛 )+𝐶_(〖𝐶𝐻𝐾〗_𝑗 )𝑡_(〖𝑑𝑙〗_𝑗 ) : the time in between the simulator spent in delay𝐶_(〖𝐶𝐻𝐾〗_𝑗 ): the overhead for storing/checkpointing
  • We consider three types of deviations:Time (t-bound):Consider the dependency between the smoke level, in a fire simulator and the person’s health condition in an evacuation simulator, t-bound=5 indicates that we assume the smoke level will not affect the health condition immediately, but instead, in less than 5 s. Therefore the smoke level must be reflected to health conditions with at most a 5s delay to be consistent.Value (v-distance): Consider the dependency between the person’s speed of walking, in an activity simulator and the user speed condition in a communication simulator, v-distance =3m indicates that we assume the user speed will not be affected by the changes on individual’s walking speed immediately, but instead, if the difference of values becomes higher than 3 m, the changes need to be reflected. Number of changes (n-update): Consider the dependency between the number of ongoing calls in an activity simulator and number of users in a communication simulator. n-update=5 indicates that updates on the number of ongoing calls will not affect the number of users immediately but there should be at most five updates on the number of ongoing calls before it is reflected into the number of users.the relaxations as conjunction and/or disjunction of three deviation types: t-bound, v-distance, n-updatesWe consider three types of deviations:Time (t-bound):Consider the dependency between the smoke level, in a fire simulator and the person’s health conditionin an evacuation simulator, t-bound=5indicates that we assume the smoke level will not affect the health condition immediately, but instead, in less than 5 s. Therefore the smoke level must be reflected to health conditions with at most a 5s delay to be consistent.Value(v-distance): Consider the dependency between the person’s speed of walking, in an activity simulator and the user speed conditionin a communication simulator, v-distance =3m indicates that we assume the user speed will not be affected by the changes on individual’s walking speed immediately, but instead, if the difference of values becomes higher than 3 m, the changes need to be reflected. Number of changes (n-update): Consider the dependency between the number of ongoing calls in an activity simulator and number of users in a communication simulator. n-update=5indicates that updates on the number of ongoing calls will not affect the number of users immediately but there should be at most five updates on the number of ongoing calls before it is reflected into the number of users.
  • illustrates average synchronization overhead per action and average execution time per action during different phases of execution (i.e. for different numbers of actions)synchronization overhead is calculated by adding the synchronization overhead in all simulators. In LS and CS, we consider the total delay time, i.e. the duration a simulator is blocked and the locking overhead, to calculate the synchronization overhead. In OS, we consider the total abort/rollback time and the checkpointing time. In HS, the synchronization overhead is calculated by adding the delay times and the abort/rollback times and checkpointing times. The synchronization overhead in CS and HS is lower as compared to OS and LS during later phases of execution. Because of high blocking time in LS and abort time in OS. In HS, initially, the cost of abort is small, so the strategy will lean towards being optimistic and is hence closer to OS in performance. as the number of actions increases, HS becomes increasingly conservative and approaches the behavior of CS.
  • represents the synchronization overhead in OS, CS, and HS for different number of dependencies in the late phase of simulationWe introduced synthetic dependencies to investigate the scalability of our approaches as the number of interdependent data items in different simulators increasesWe see overall performance of HS is better than CS and OS over a broad range of dependenciesAnother observation is that increasing the number of dependencies has an adverse effect on OS as compared the CS and HS
  • Constructing a complete transformation with reusable transformation building blocksreusable transformation to be a transformation that can be used in several contexts to produce a required data
  • Goal: During the concurrent execution of multiple simulators, transform the data generated/updated by simulators into input data required by other dependent simulators. -- minimize transformation cost at runtime.-- retain flexibility to model/run multiple data exchange scenarios.Flow: model transformations and transformation cost. Given: convertors and how converters can be combined to support transformation… Transformations -- 1 to 1 mapping from 1 output data item to an input data item… Modeled as is a weakly connected graph of convertors..However, 1 data item may have many dependencies…1 to many mapping that captures all dependenvies…..generates a DAG???Nodes in this graph are what?? Edges are what??
  • How to generate schema mappings and how to use them for data exchange?
  • Define transformations as a set of convertors to transform a data in one simulator into the data in another simulatorEach transformation is a weakly connected directional graph of convertors successively transforms data from one simulator until it produces a data for another simulator
  • Goal: During the concurrent execution of multiple simulators, transform the data generated/updated by simulators into input data required by other dependent simulators. -- minimize transformation cost at runtime.-- retain flexibility to model/run multiple data exchange scenarios.Flow: model transformations and transformation cost. Given: convertors and how converters can be combined to support transformation… Transformations -- 1 to 1 mapping from 1 output data item to an input data item… Modeled as is a weakly connected graph of convertors..However, 1 data item may have many dependencies…1 to many mapping that captures all dependenvies…..generates a DAG???Nodes in this graph are what?? Edges are what??
  • where 𝜑𝑃and 𝜏𝑃 are normalized values 𝛼,𝛽≥0where 𝜑_𝑃and 𝜏_𝑃 are normalized values 𝛼,𝛽≥0
  • Consider the whole duration of simulation TR Problem: Given a transformation task find a valid transformation plan with minimum total costSingle source data item to a single target data item|N| = 2: Shortest path: A* in WCDGs [12]Single source data item to all target data itemsN = V: minimum spanning tree [13]Single source data item - multiple target data items NP-hard (the problem of computing the Minimum directed Steiner Tree can be reduced to an instance of the TR problem)in small transformation graphsPolynomial time algorithm for Steiner tree when we have O(1) terminals [14]in large transformation graphsShortest paths heuristic bases on Prim’s minimum spanning tree algorithm [15]Multiple source data item - multiple target data items in large graphs
  • Consider the whole duration of simulation For dniin simulator i and dmjin simulator j, where there exists a dependency(𝑑𝑛𝑖∈𝐷𝑖)->𝑑𝑚𝑗∈𝐷𝑗 find a valid transformation plan with minimum total costThe annotated tree TP rooted at S=dniwith all the terminal vertices (leaves) at dmjwhere each node and edge is annotated by the convertors performed at the node and the data items that are transmitted along the link respectivelyConsider the whole durationof simulation For dniin simulator i and dmjin simulator j, where there exists a dependency〖(𝑑〗_𝑛𝑖∈𝐷_𝑖)->(𝑑_𝑚𝑗∈𝐷_𝑗 ) find a valid transformation plan with minimum total costThe annotated tree TP rooted at S=dniwith all the terminal vertices (leaves) at dmjwhere each node and edge is annotated by the convertors performed at the node and the data items that are transmitted along the link respectively
  • When the size of transformation graph |TG| is small, say, less than 5, the experiments of soup membrane can be used to solve the Steiner Tree Problem efficiently [78]. However, when the number of vertices is 10 or more, this experiment just cannot give the right answer. In multisimulations, in most of real world scenarios the size of transformation graph and the number of target data items for a specific source data item is relatively small.
  • Building geometry from CFAST and Drillsim can determine the number of transmit and receive antenna in LTEsim.
  • The default value for α and β is set to one in the cost function meaning that the communication and computation normalized cost units are the same.The effect of using optimal and heuristic CCD algorithms in reduction of transformation cost.
  • Random graph generator: using the transit-stub model
  • [21] Jalali, L., Venkatasubramanian, N., Mehrotra, S.: Reflective Middleware Architecture for Simulation Integration,ARM’09, Urbana Champaign, Illinois (2009)[22] Jalali, L., Venkatasubramanian, N., Mehrotra, S.: Middleware Solutions for Integrated Simulation Environments, The Proc. of 7th Middleware Doctoral Symposium (2010)[23] Jalali, L., Venkatasubramanian, N., Mehrotra, S.: Interoperability of Multiple Autonomous Simulators in Integrated Simulation Environments, Spring SIW'11 (2011)[24] Formal Modeling: Leila Jalali, SharadMehrotra, NaliniVenkatasubramanian. Multisimulations: Towards Next Generation Integrated Simulation Environments. Formal Modeling: Actors, Open Systems, Biological Systems 2011: 352-367[25] submitted to TOMACS’11[26] A Formal Specification Framework for Consistent Multisimulations, L. Jalali, S. Mehrotra, N. Venkatasubramanian, C. Talcott, Poster in Southern California Smart Grid Research Symposium, California Institute of Technology, 2011. [27] Integrated Simulation Environments for Emergency Response Management, L. Jalali, S. Mehrotra, N. Venkatasubramanian, Poster in Southern California Smart Grid Research Symposium, Oct. 2010. 
  • This is a very interesting research proposal that will
  • consistent For every update sent from 𝑆𝑖 to the meta-synchronizer and reflected into 𝑆𝑗before 𝑐h𝑘𝑗(𝑛), then the sending of that update must have happened before 𝑐h𝑘𝑖(𝑛For every update sent from 𝑆𝑖 to the meta-synchronizer before 𝑐h𝑘𝑖(𝑛) and reflected into 𝑆𝑗 after 𝑐h𝑘𝑗(𝑛), the corresponding meta-action of that update must be saved to meta-actions queue to be replayed if the simulators has to roll back.consistent For every update sent from 𝑆_𝑖 to the meta-synchronizer and reflected into 𝑆_𝑗before 〖𝑐ℎ𝑘〗_𝑗 (𝑛), then the sending of that update must have happened before 〖𝑐ℎ𝑘〗_𝑖 (𝑛For every update sent from 𝑆_𝑖 to the meta-synchronizer before 〖𝑐ℎ𝑘〗_𝑖 (𝑛) and reflected into 𝑆_𝑗 after 〖𝑐ℎ𝑘〗_𝑗 (𝑛), the corresponding meta-action of that update must be saved to meta-actions queue to be replayed if the simulators has to roll back.
  • Based on the conditions for a consistent global multisimulation checkpoint, we have to prevent an update by 𝑆𝑖, within 𝑐h𝑘𝑖(𝑛), from being received by another simulator 𝑆𝑗, with 𝑐h𝑘𝑗(𝑛−1). We do not have to block 𝑆𝑗,until 𝑆𝑖 has taken its checkpoint.In fact, the n counter attached to each update will solve this problem, and simulators do not have to be blocked by the algorithm. If a simulator receives an update from another simulator, that is already running in the next checkpoint interval, the corresponding simulator takes a checkpoint of its execution state before reflecting that update. Based on the conditions for a consistent global multisimulation checkpoint, we have to prevent an update by 𝑆_𝑖, within 〖𝑐ℎ𝑘〗_𝑖 (𝑛), from being received by another simulator 𝑆_𝑗, with 〖𝑐ℎ𝑘〗_𝑗 (𝑛−1). We do not have to block 𝑆_𝑗,until 𝑆_𝑖 has taken its checkpoint.In fact, the n counter attached to each update will solve this problem, and simulators do not have to be blocked by the algorithm. If a simulator receives an update from another simulator, that is already running in the next checkpoint interval, the corresponding simulator takes a checkpoint of its execution state before reflecting that update.
  • Implementation issueConsider 2 flags abortabort-cIf a simulator receive an update from other simulator for which it needs to abort to apply that update the abort flag will be onIf a simulator is in cascade list of a simulator for which an abort flag is on then abort-c flag will be onThere can be cases in which we have a simulator with both flags on
  • Steiner tree- NP completeness
  • Φ𝑖 represents a state of a simulatorΦ_𝑖 represents a state of a simulator
  • Use formal specification as a mechanism to explore other characteristics of integration -- such as resilience properties of the integrated execution through targeted state space analysisExamples to show that lightweight formal methods can helpnarrowing feasible ranges of parameter settings for simulatorsquickly abstract and focus on properties (and execution paths) of interest determine how changes in one simulator can impact the overall executionquickly determining whether a specific event generated from a simulator can cause undesirable events in other simulators (e.g. chemical plume propagation to a region where traffic is congested and folks have no way out)
  • To assure correct observe-analyze-adapt cycle in dynamically changing simulation modelsHaving a semantic model for specifying and reasoning about correctness of multisimulationsi.e. how different meta-level modules (e.g. synchronizer) can be used to coordinate the consistent flow of information between multiple simulatorsUsing the rewriting logic based Maude tool a logic-based language is better suited to deal with constraints, reflection, and the planning processallows their use for system prototyping and debugging of specifications
  • We consider 𝑚𝑎𝑥(0,𝑡𝑗−𝑡𝑖) because we are only interested in those simulators in 𝑆𝑗’s dependency set lagging behind the time in 𝑆𝑗. We consider 𝑚𝑎𝑥(0,𝑡_𝑗−𝑡_𝑖) because we are only interested in those simulators in 𝑆_𝑗’s dependency set lagging behind the time in 𝑆_𝑗.
  • In step (1), the transportation model is executed with a default set of travel demand parameters to obtain the daily travel time matrix, which is stored as a text file. In step (2), each household uses the travel time―along with other factors such as the stores at which friends and neighbors shop―to determine its choice of grocery store. To obtain the travel time between a household and a store, the latitude and longitude of the household and store are first mapped to the zone in which they belong in the transportation network. Subsequently, the travel time of this OD pair is read from the text file by the household model. In the household model, each simulation tick represents an elapsed real-time of approximately two days. However, in step (4), the BMI model, which takes the input generated from step (2), expects the calories of each person for each day. The data transformation in step (3) eliminates the mismatch of the output of the household model with the input of the calories-to-BMI model.
  • 𝐶𝑉=𝑐𝑣𝑐𝑣=𝑓𝐷𝑇𝑥…𝑥𝐷𝑇:𝐼𝑛𝑥…𝑥𝐼𝑛->𝑂𝑢𝑡Transformation: A set of convertors successively transforms data from one simulator until it produces a semantically meaningful data for another simulatorA path from a source node to a target node in weakly connected directional graph of convertors𝑇𝑅(𝐼𝑛,𝑂𝑢𝑡)=𝑔𝐷𝑇𝑥…𝑥𝐷𝑇𝑔𝐷𝑇𝑥…𝑥𝐷𝑇=𝑔𝐷𝑇𝑥…𝑥𝐷𝑇:𝐼𝑛𝑥…𝑥𝐼𝑛->𝑆𝑒𝑚𝑎𝑛𝑡𝑖𝑐𝑂𝑢𝑡, 𝑔=.𝑐𝑣∗, 𝑐𝑣∈𝐶𝑉For all dependencies add associated TRs from the transformation pool to the graphTG: A set of weakly connected graphs𝐶𝑉={𝑐𝑣│𝑐𝑣=𝑓_(𝐷𝑇𝑥…𝑥𝐷𝑇):𝐼𝑛𝑥…𝑥𝐼𝑛->𝑂𝑢𝑡}Transformation: A set of convertors successively transforms data from one simulator until it produces a semantically meaningful data for another simulatorA path from a source node to a target node in weakly connected directional graph of convertors〖𝑇𝑅〗_((𝐼𝑛,𝑂𝑢𝑡))={𝑔_(𝐷𝑇𝑥…𝑥𝐷𝑇) |𝑔_(𝐷𝑇𝑥…𝑥𝐷𝑇)=𝑔_(𝐷𝑇𝑥…𝑥𝐷𝑇):𝐼𝑛𝑥…𝑥𝐼𝑛->𝑆𝑒𝑚𝑎𝑛𝑡𝑖𝑐𝑂𝑢𝑡, 𝑔=(.𝑐𝑣)∗, 𝑐𝑣∈𝐶𝑉}
  • Household model: An agent-based model in which each household has specific characteristics (income, food preferences, ), decides where to shop, which foods to purchase, and how much to exercise.Transportation model: A model providing travel time required between two input locations (such as household to nearby stores).Store Location model: An optimization model used by retail stores (in this case a food store) to select optimal locations for establishing a new store.Calories to BMI model: A computational model that converts daily calories, fat, etc. consumption and physical activity to BMI change for a given individual
  • In step (1), the transportation model is executed with a default set of travel demand parameters to obtain the daily travel time matrix, which is stored as a text file. In step (2), each household uses the travel time―along with other factors such as the stores at which friends and neighbors shop―to determine its choice of grocery store. To obtain the travel time between a household and a store, the latitude and longitude of the household and store are first mapped to the zone in which they belong in the transportation network. Subsequently, the travel time of this OD pair is read from the text file by the household model. In the household model, each simulation tick represents an elapsed real-time of approximately two days. However, in step (4), the BMI model, which takes the input generated from step (2), expects the calories of each person for each day. The data transformation in step (3) eliminates the mismatch of the output of the household model with the input of the calories-to-BMI model.
  • Reusability of translators/adaptors (e.g. scale conversion) express adaptors as a service with a service description
  • Integrated Simulation Environments

    1. 1. Middleware Solutions for Integrated Simulation Environments Leila Jalali http://www.ics.uci.edu/~ljalali/ ljalali@ics.uci.edu Distributed Systems Middleware11/28/2012 Leila Jalali Group
    2. 2. Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulations  Modeling Synchronization Problem using concepts from Multidatabases  A Hybrid Scheduling Approach  Optimizations: Checkpointing and roll-back; Relaxation models  An Emergency Response Case Study Data Exchange in Multisimulations  Modeling Data Exchange using Transformation Graphs  Data Transformation Plan Generation: Algorithms  An Emergency Response Use Case Formal Specification of Multisimulations  Modeling Multismulations in Maude for rapid prototyping and analysis Conclusions and Future work11/28/2012 Leila Jalali 2 Distributed Systems Middleware Group
    3. 3. Introduction 1 Simulation: the process of designing a model of a real world system and conducting experiments with this model for our purpose: 2 cheaper, safer, easier, and quicker Planning and decision support:  1. Defence simulations 3  2. Emergency response simulations Domain specific testing and analysis: 4  3. Traffic analysis  4. Human behaviour study: crowd dynamics 5  5. Network simulators 6 Immersive synthetic platforms for training  6. Fire fighter training simulators 11/28/2012 Leila Jalali 3 Distributed Systems Middleware Group
    4. 4. Motivation for New SimulationPlatforms Many available simulators  Operate on specific domains  e.g fire simulators, transportation simulators Infeasible to build complex simulations entirely from scratch  Need domain expertise to have an in-depth understanding of the phenomena  Economic and organizational constraints  The increasingly complex requirements Need ability to:  Bring together simulators from various modeling domains: Multisimulations  Model and test larger and more complex scenarios  Study cause- effect relationships to integrate simulators11/28/2012 Leila Jalali 4 Distributed Systems Middleware Group
    5. 5. Simulation Integration- historicalviewDistributed Interactive Simulation (DIS) High Level Architecture (HLA) (1990–today) Army Projects (1996-today) Defense1975 1980 1985 1990 1995 2000 SIMulator NETworking (SIMNET) (1983–1990) Combat SimulatorsDefense Community Aggregate Level Simulation Protocol (ALSP) (1991–1997ish) War-gaming models Dungeons and Dragons Adventure Board Games Multi-User Dungeon (MUD)(Xerox PARC) Games Multi-User Video GamesInternet & Gaming Community11/28/2012 Leila Jalali 5 Distributed Systems Middleware Group
    6. 6. Current approaches DIS 1990 ALSP 1991 HLA 1996 not fully  requires strict  requires the individual simulators to conform to distributed adherence to the standard; might not be always possible [20] no time causality, i.e., all  The standard may not have been designed to management simulation events handle the new simulator needs service must be  Low level knowledge needed from the does not processed in practitioner [22] manage time stamp order  Cost issues, Complexity [22] latency and  proven to be  Current model registration in HLA needs a lot of causality very system manual work [20] foundations specific and does  No support for semantic interoperability for distributed not provide a  Transparency real-time general Network- too big and mainly applied in defense HLA is simulation [6] interoperability [20] HLA MATLAB- HLA SLX Model-integration 2007 2000 2000 2011 solution [5] specific implementatio simulation generic modeling to of a n designed language with RTI environment tool, modeling extensibility, uses a custom communicati specifically for the a development developed DSML networks [27] integration into Matlab [28] on for based on HLA [29] env. model definition [30] SESA 2007 Splash 2010 BPI 2003 Integration of multiple Health care domain, focuses on how data can be Business process integration workflows transformed before it is used by another middleware to facilitate the integration downstream component model of applications11/28/2012 Leila Jalali 6 Distributed Systems Middleware Group
    7. 7. General Challenges Managing Complexity of Interoperating Systems  Analysis of cause- effect relationships Correctness of Multisimulations  What, how, when to exchange the information among multiple simulators?  Time synchronization: causality correctness  Data exchange: data transformations Scalability11/28/2012 Leila Jalali 7 Distributed Systems Middleware Group
    8. 8. General Challenges- Our Focus Managing Complexity of Interoperating Systems  Analysis of cause- effect relationships  Methodology to develop multisimulations using meta-models and meta-level modules Correctness of Multisimulations  Formal Specifications of multisimulations  What, how, when to exchange the information among multiple simulators?  Modeling synchronization problem using concepts from multidatabases  Time synchronization: causality correctness  Hybrid approach for  Data exchange: data transformations synchronization  Relaxation models  Using transformation Scalability graphs for data exchange11/28/2012 Leila Jalali 8 Distributed Systems Middleware Group
    9. 9. Autonomous simulators with specific platform issues Simulator Platform Simulator Platform simulator i simulator j source code parameters databases source code parameters databases11/28/2012 Leila Jalali 9 Distributed Systems Middleware Group
    10. 10. Complex analysis smart decisions using multisimulations what-if analysis policy making algorithms Autonomous simulators with specific platform issues Simulator Platform Simulator Platform simulator i simulator j source code parameters databases source code parameters databases11/28/2012 Leila Jalali 10 Distributed Systems Middleware Group
    11. 11. Complex analysis smart decisions using multisimulations what-if analysis policy making algorithms run-time RAISE Middleware Time Synchronizer Data Transformers Integrated simulation environment actions dependency actions descriptors type data data type simulator i simulator j specification Analyze specification Observe and extract Reflect Autonomous simulators with specific platform issues Simulator Platform Simulator Platform simulator i simulator j source code parameters databases source code parameters databases11/28/2012 Leila Jalali 11 Distributed Systems Middleware Group
    12. 12. Reflective Architecture for IntegratedSimulation Environments- RAISE Complex Applications run-time Data Exchange Time Synchronization dependencies Data Consistency Synchronizer Controller Transformers Meta level Lock-table meta-actions Lock Manager External Analyzer & Adaptor Data Sources Meta models Structural specification: UML diagrams, metamodels Interactions: dependency sets, interdependent data Observe & Extract Reflect Base level INLET Drillsim Fire, Earthquake LTESim (Transportation Model) (Activity Model) (Crisis Model) (Communication Model)11/28/2012 Leila Jalali 12 Distributed Systems Middleware Group
    13. 13. RAISE Methodology Developer(integrator) Meta level 1. Reification: extract simulators’ meta- data and construct meta-models Base level simulator1 simulator2 simulator3 Live data preprocessing steps Base level Meta level  UML diagrams, human in the loop process  Making the underlying simulators more understandable Back-up Slides 11/28/2012 Leila Jalali 13 Distributed Systems Middleware Group
    14. 14. RAISE Methodology (cont.) Developer(integrator) Meta level Base level simulator1 simulator2 simulator3 Live data preprocessing steps 2. Analysis of meta-models: extract inter-dependencies and describe them using dependency 3. descriptors Create wrappers for each simulator to interface with meta- level 11/28/2012 Leila Jalali 14 Distributed Systems Middleware Group
    15. 15. RAISE Methodology (cont.) Developer Decision-maker(integrator) System-wide analyzer run multisimulation Meta level Run-time meta-models inter-dependencies Base level Base level simulator1 simulator2 simulator3 Live data simulator1 simulator2 simulator3 Live data preprocessing steps run-time execution 3. Run multisimulation: 2. Analysis of meta-models:  Wrappers decide whether to extract inter-dependencies and communicate with meta-level or not describe them using dependency  What, how, when to exchange the 3. descriptors Create wrappers for each information among multiple simulator to interface with meta- simulators level  Ensuring correctness:  time synchronization 15 Distributed Systems Middleware 11/28/2012 Leila Jalali  data management Group
    16. 16. Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulations  Modeling Synchronization Problem using concepts from Multidatabases  A Hybrid Scheduling Approach  Optimizations: Checkpointing and roll-back; Relaxation models  An Emergency Response Case Study Data Exchange in Multisimulations  Modeling Data Exchange using Transformation Graphs  Data Transformation Plan Generation: Algorithms  An Emergency Response Use Case Formal Specification of Multisimulations  Modeling Multismulations in Maude for rapid prototyping and analysis Conclusions and Future work11/28/2012 Leila Jalali 16 Distributed Systems Middleware Group
    17. 17. The Synchronization Challenge  Ensuring causal correctness in concurrently executing simulators while preserving simulators’ autonomy  An example of causality violations without an effective time synchronization: Fire Simulator Fire & Smoke Activity Simulator Someone extinguished the fire Visualization time Still the fire there? Conflict 11/28/2012 Leila Jalali 17 Distributed Systems Middleware Group
    18. 18. Time Synchronization- relatedwork Time In distributed In networks In distributed Synchronizatio systems simulation n approaches • Clock • Parallel Discrete • Conservative • Cristian Synchronization -Network time Event Simulation • Optimistic algorithm protocol • Distributed • Scaled real- • Berkley • Time scale Interactive Transformation Simulation time algorithm -Client-server -Time stamp synch • Aggregated Level • Lamport -Beacon node Simulation Protocol broadcast algorithm -Light weight time • High Level synchronization Architecture • Time Warp 11/28/2012 Leila Jalali • SPEEDS 18 Distributed Systems Middleware Group
    19. 19. Time Synchronization Challenges (1) Different simulators represent time differently and implement varying time advancement mechanisms. Time-stepped simulators Event-based simulators : : event 1 event 2 event 3 time time 1: while (simulation still in progress) do 1: while (simulation still in progress) do 2: Event e= nextEvent; 2: for each tick do 3: while(e!=null) do 3: read data; 4: process(e); 4: modify data; 5: time= timestampe(e); 5: time = time + Δt ; 6: e= nextEvent; 6: end for 7: end while 7: end while 8: end while (2) The source code of simulators is largely legacy.  Need to change as little as possible in implementing time 19 synchronization 11/28/2012 Leila Jalali Distributed Systems Middleware Group
    20. 20. Meta-Synchronization Model Multisimulation dependencies meta-actions Meta level MetaSynchronizer wrapper wrapper wrapper wrapper actions . . . actions Base level d . . . d’ Simulator i Simulator j  Capture steps in a time-stepped simulator or events in an event-based simulator in the concept of multisimulation action  Synchronization is needed at the meta level to ensure causal correctness (correctness criteria)  Meta-level view:  Delay: action is delayed  Schedule: action is granted to be safely executed [Inspired by work from multidatabase concurrency] 11/28/2012 Leila Jalali 20 Distributed Systems Middleware Group
    21. 21. Dependencies   Internal actions vs. External actions  External actions access at least one data item which is an interdependent data item [Inspired by global/local transactions] 11/28/2012 Leila Jalali 21 Distributed Systems Middleware Group
    22. 22. Dependency Preservation inSchedules  11/28/2012 Leila Jalali 22 Distributed Systems Middleware Group
    23. 23. Schedule Example  Formal Definition: back-up slides 11/28/2012 Leila Jalali 23 Distributed Systems Middleware Group
    24. 24. Synchronization Protocol Base-level Wrappers Meta-level Wrappers are written for each simulator to internal action allow control the execution of individual simulators 11/28/2012 Leila Jalali 24 Distributed Systems Middleware Group
    25. 25. Synchronization Protocol Base-level Wrappers Meta-level Wrappers are written for each simulator to internal action allow control the execution external action grant * of individual external action allow simulators external action done Upon receiving external actions: updates on interdependent data schedule* at meta- level 11/28/2012 Leila Jalali 25 Distributed Systems Middleware Group
    26. 26. Synchronization Protocol Base-level Wrappers Meta-level Wrappers are written for each simulator to internal action allow control the execution external action grant * of individual external action allow simulators external action done Upon receiving external actions: updates on interdependent data schedule* at meta- level meta-actions internal action allow external action grant Upon receiving updates external action allow meta-actions are external action done generated at meta-level updates 11/28/2012 Leila Jalali 26 Distributed Systems Middleware Group
    27. 27. Solutions to Synch. problem  11/28/2012 Leila Jalali 27 Distributed Systems Middleware Group
    28. 28. Lock Step Strategy  Lock-step Scheduling: the most conservative approach by having a lock step schedule  All simulators advance step by step  At any step they synchronize by locking at data item level until the next step  By locking interdependent data in the beginning of action and releasing the locks at the end, we can prevent deadlocks  Our experiments show very high synchronization time when using this approach 11/28/2012 Leila Jalali 28 Distributed Systems Middleware Group
    29. 29. Conservative Strategy  current time=ti ... a1 a2 next action of Sj is delayed: ... a’1 a’2 current time=tj 11/28/2012 Leila Jalali 29 Distributed Systems Middleware Group
    30. 30. Optimistic Strategy  External actions from different simulations are allowed whenever they are requested  We accept the fact that dependency violations can occur  Resolve the violation when it does occur by aborting the actions that caused the violation current time=ti ... a1 a2 next action of Sj is not delayed a’1 a’2 current time=tj 11/28/2012 Leila Jalali 30 Distributed Systems Middleware Group
    31. 31. Effectiveness of Scheduling Strategies  Conservative and optimistic strategies may become more (or less) effective as a multisimulation progresses  Initially, the cost of abort is small, so the optimistic strategy performs better than conservative strategy  As the simulator proceeds, aborts costs become increasingly high  We propose a cost-driven hybrid approach that combines the benefits of both the optimistic and conservative strategies by considering the underlying dependencies to make an informed decision on whether to abort or delay an action Middleware11/28/2012 Leila Jalali 31 Distributed Systems Group
    32. 32. A Cost-Driven Hybrid SchedulingStrategy  Combines the benefits of both the conservative and optimistic strategies  Considers the expected cost of both conservative and optimistic scheduling of each action, and chooses the method with the lower expected cost  Minimizes the expected execution time for each simulator in the integrated execution current time=ti ... a1 a2 Need to make a decision to allow the next action of Sj or to de a’1 a’2 current time=tj 11/28/2012 Leila Jalali 32 Distributed Systems Middleware Group
    33. 33. How to make the decision? duration of time that Sj may receive an update from Si that results in violation current time=ti update on di Si a1 a2 aborted Sj a’1 a’k … allowed not aborted current time=tj next action= a’k delayed necessary unnecessary  11/28/2012 Leila Jalali 33 Distributed Systems Middleware Group
    34. 34. How to make the decision? duration of time that Sj may receive an update from Si that results in violation current time=ti update on di Si a1 a2 aborted Sj a’1 a’k … allowed not aborted current time=tj next action= a’k delayed necessary unnecessary  11/28/2012 Leila Jalali 34 Distributed Systems Middleware Group
    35. 35. Computing the costs  11/28/2012 Leila Jalali 35 Distributed Systems Middleware Group
    36. 36. Probability of abort  Back-up Slides 11/28/2012 Leila Jalali 36 Distributed Systems Middleware Group
    37. 37. Optimization1: Checkpointing and Rollback mechanism  Abort operation in multisimulations is not always cost effective  (i) long-running scientific simulation programs designed to run for days need to restart from the beginning  (ii) as the result of aborting one simulator, multiple dependent simulators that used its updates need to restart as well, which enforce very significant overhead on multisimulation execution  We explore a checkpointing and rollback mechanism [Elnozahy et al. 2002] that enables a simulator to restart effectively from a checkpoint  Computing the cost of roll-back: Back-up Slides11/28/2012 Leila Jalali 37 Distributed Systems Middleware Group
    38. 38. Optimization 2: RelaxingDependencies smok t-bound=5 s e level walking user speed v-distance =3m speed Num. of ongoing n-update=5 Num. of users calls11/28/2012 Leila Jalali 38 Distributed Systems Middleware Group
    39. 39. A Case Study for simulationintegration To validate the proposed reflective architecture Using three disparate pre-existing simulators: 1. CFAST (Consolidated Model of Fire and Smoke Transport): a fire simulator  Simulates the effects of fire and smoke inside a building and calculates the evolving distribution of smoke, fire gases and temperature 2. Drillsim: an activity simulator  Multi-agent system that simulates human behavior in a crisis 3. LTESim: a communication simulator  Abstracts the physical layer and performs network level simulations of 3GPP Long Term Evolution11/28/2012 Leila Jalali 39 Distributed Systems Middleware Group
    40. 40. Experiments: Integrating three simulators usingRAISE 2. Communication Simulator: LTESim1. Evacuation Simulator: DrillSIM Total num. of evacuees 3. Fire Simulator: CFAST some results 11/28/2012 Leila Jalali 40 Distributed Systems Middleware Group
    41. 41. Case study- simulators properties Evacuation Simulator Communication Fire Simulator Simulator DrillSim LTESim CFAST  Simulates a Performs network level Simulates the effects of response activity simulations of 3GPP LTE fire and smoke inside a evacuation Event based building Time stepped Open source (in Time stepped Open source (in Matlab) Black-box (no access to Java) Parameters: num. of source) Agent based transmit and receive Parameters: building Parameters: health antennas, uplink delay, geometry, materials of profile, visual distance, network layout, channel construction, fire speed of walking, num. model, bandwidth, properties, etc. of ongoing call, etc. frequency, receiver noise, Output: temperatures, Output: num. of etc. pressure, gas evacuees, injuries, etc Output: pathloss, concentrations: CO2, etc. throughput, etc. 11/28/2012 Leila Jalali 41 Distributed Systems Middleware Group
    42. 42. Experiments Intermediate Phase Early Phase Intermediate Phase Late Phase Early Phase Late Phase (a) simulation phase (no. of actions) (b) simulation phase (no. of actions) OS: Optimistic CS: Conservative HS: Hybrid LS: Lock- step scheduling  (a) Average synchronization overhead  (b) Total execution time in different simulation phases  Total number of dependencies=100  HS, initially, the cost of abort is small, so the strategy will lean towards being optimistic/closer to OS in performance as the number of actions increases, it Middleware 42 Distributed Systems 11/28/2012 Leila Jalali Group
    43. 43. Experiments- dependencies 2400.53 1830.210 1243.008 1127.999 1082.647 903.162 975.581 710.081 639.099 320.073 315.492 27.288 36.873 27.263 35.655  Synchronization overhead for different number of dependencies in the late phase of simulation  Overall performance of HS is better than CS and OS over a broad range of dependencies 11/28/2012 Leila Jalali 43 Distributed Systems Middleware Group
    44. 44. Experiments- different simulators  Synchronization overhead and Total execution time of different simulators CFAST, DrillSim, and LTEsim  We need take into account the type of simulator and number of dependencies  Overhead in LTESim is very high when OS is used  an event-based simulator with a large number of external events that access the interdependent data items (e.g. throughput) results in aborts 11/28/2012 Leila Jalali 44 Distributed Systems Middleware Group
    45. 45. Experiments- checkpointing & rollback  Drillsim (activity simulator) has been modified to develop checkpointing mechanism  using libckpt user level incremental checkpointing  Results of optimistic scheduling (OS) and hybrid scheduling (HS) with and w/o checkpointing checkpointing overhead 11/28/2012 Leila Jalali 45 Distributed Systems Middleware Group
    46. 46. Experiments- relaxations Strategy CS OS HS Metric Without With Without With Without With Relaxations Relaxations Relaxations Relaxations Relaxations Relaxations CFAST 592.228 510.376 778.364 353.856 292.283 201.598 DrillSim 404.293 393.634 312.182 296.341 104.293 98.781 LTEsim 946.432 883.812 1420.091 825.120 731.423 423.923 Total 1943.013 1787.882 2499.637 1475.317 1127.999 724.302  Total number of relaxed dependencies= 10  Relaxations always help into get better results in terms of synchronization overhead and total execution time 11/28/2012 Leila Jalali 46 Distributed Systems Middleware Group
    47. 47. Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulations  Modeling Synchronization Problem using concepts from Multidatabases  A Hybrid Scheduling Approach  Optimizations: Checkpointing and roll-back; Relaxation models  An Emergency Response Case Study Data Exchange in Multisimulations  Modeling Data Exchange using Transformation Graphs  Data Transformation Plan Generation: Algorithms  An Emergency Response Use Case Formal Specification of Multisimulations  Modeling Multismulations in Maude for rapid prototyping and analysis Conclusions and Future work11/28/2012 Leila Jalali 47 Distributed Systems Middleware Group
    48. 48. Data Exchange Problem • How to exchange/tranform the information among simulators in multisimulations execution • Challenges: – Data from a simulator is transformed into the meaningful input for another simulator – Different simulators represent data items differently (e.g. different geography representation such as raster, network, etc.) Harmful Agents Profile : conditions Health NodesCell Links CFAST Drillsim 48 Distributed Systems Middleware Group
    49. 49. Pipeline vs. Concurrent executionPipeline execution : Concurrent execution :• Execute the simulators one at a time  Provide a framework in which• Transform the output of a simulator into independent simulation models can the input data of the other simulator execute concurrently• Need data transformation, GIS  Need time synchronization to preserve conversions, time adaptations, etc. casualty (e.g. scheduling)  Need intermediate data transformations based on dependencies, GIS conversions, Simulation output etc. Model 1 transformed output Simulation Simulation Model i ... Model j Simulation Output Model 2 intermediate outputs . . Output . synchronization (a) Pipeline execution Simulation Model n (b) Concurrent execution 49 Distributed Systems Middleware Group
    50. 50. Our Goal• Goal: During the concurrent execution of multiple simulators, transform the data generated/updated by simulators into data required by other dependent simulators – minimize transformation cost at runtime – retain flexibility to model/run multiple data exchange scenarios• Challenges: – Dependencies among simulators may be many and complex – Not necessarily a static transformation scenario: need the ability to consider subset of dependencies to model/run different scenarios 50 Distributed Systems Middleware Group
    51. 51. Useful approaches for data exchange Data Exchange in HLA Schema Mapping Ontologies A pub/sub model [4]  Data Exchange is an old, but recurrent,  Matching strategies for- Based on routing spaces and database problem concepts, attributesregions - Schema mappings and query answering in Clio and relations [43] express an interest in (IBM) [76]  Ontologies for GIS receiving certain data  Transformation graphs in ETL process [83] (integrated geographic or sending data by  Finding best queries through Steiner tree information systems) defining subscription generation [81, 82] [91] regions and update - Answering specific user queries (Q system)  Mapping discovery regions - Answering relationship queries over entity-relation-  Comparing & Merging Interest management style data graphs (STAR) [39] concepts using platform (LUICID)  Semantic trees for relational DB schemas ontologies (e.g. FCA-- Supports dynamic multicast [80] , XML databases [77], Merge, IFMAP, MAFRAgrouping  Data exchange & query answering for frameworks) [93] incomplete data sources [PDMS] Data Exchange in S&M Data Exchange in workflows DEVS frameworks (Python DEVSIMPY, MATLAB/Simulink)  AXMEDIS for workflow management systems Model integration (using DSML)  Integration of multiple workflows (SESA) 51 Distributed Systems Middleware Group
    52. 52. Model Transformations• Convertors can be combined to support a transformation• One-to -one mapping from one data item in a simulator into a data item in another simulator • Modeled as a directed graph of convertors • We assume that the transformations between two dependent data items are given to us Transformations Runtime C2 Simulator i A C1 B Simulator j C3 52 Distributed Systems Middleware Group
    53. 53. Transformation Graph • One data item can involve in many dependencies • We consider one-to-many mapping that captures all dependencies from one data item in a simulator into data items in other simulators • Generates a transformation graph: – The vertices correspond to the various data items (source and target, intermediate) – The directed edges between two vertices represents the connection that converts/transmit the data – The associated conversion cost is represented by the weight of the edge Runtime C2 Simulator i d1 i d1 j Simulator j C1 . . C3 . . . .D1i Source data dmj C5 Intermediate data . .D1j Target data . C4Directed edges: d1 k C Convertors C7 Simulator k 1 . C6 . . back-up slides Distributed Systems Middleware Group 53
    54. 54. Cost Model 54 Distributed Systems Middleware Group
    55. 55. Transformation problem Transform a single source data item to a single target data item  Consider one dependency between two data items at a time Transform a single source data item to all target data items  Consider all the dependencies for a data item Transform a single source data item - multiple target data items  Consider some of the dependencies among multiple simulators  Retain flexibility to model/run multiple data exchange scenarios Transform Multiple source data item - multiple target 55 Distributed Systems Middleware Group
    56. 56. Transformation (one-to-one)• Transform a single source data item to a single target data item  Consider one dependency between two data items at a time  |N| = 2: Shortest path Runtime C2 Simulator i d1 i d1 j Simulator j C1 . . C3 . . . . dmj C5 . . . C4 d1 k C7 Simulator k . C6 . . 56 Distributed Systems Middleware Group
    57. 57. Transformation (one-to-all) Transform a single source data item to all target data items  Consider all the dependencies for a data item  N = V: minimum spanning tree Runtime C2 Simulator i d1 i d1 j Simulator j C1 . . C3 . . . . dmj C5 . . . C4 d1 k C7 Simulator k . C6 . . 57 Distributed Systems Middleware Group
    58. 58. Transformation (one-to-many) Transform a single source data item - multiple target data items  Consider some of the dependencies from a data item in a simulator to data items in other simulators  NP-hard (the problem of computing the Minimum directed Steiner Tree can be reduced to an instance of this problem) Runtime C2 Simulator i d1 i d1 j Simulator j C1 . . C3 . . . . dmj C5 . . . C4 d1 k C7 Simulator k . C6 . . 58 Distributed Systems Middleware Group
    59. 59. Transformation problem: our focus Given a transformation graph find a transformation plan with minimum total cost from a single source data item to multiple target data items  NP-hard (the problem of computing the Minimum directed Steiner Tree can be reduced to an instance of this problem)  in small transformation graphs  Polynomial time algorithm for Steiner tree when we have O(1) terminals [78]  in large transformation graphs  Shortest paths heuristic bases on Prim’s minimum 59 Distributed Systems Middleware Group
    60. 60. TR Problem in Small TG• In multisimulations, in some of real world scenarios the size of transformation graph and the number of target data items for a specific source data item is relatively small• the experiments of soup membrane can be used to solve the Steiner Tree Problem efficiently [78]• Polynomial time algorithm for Steiner tree when we have O(1) terminals: – Enumerate all sets W of at most r – 2 non-terminals – For each W, find a minimum spanning tree – Take the best over all these solutions 60 Distributed Systems Middleware Group
    61. 61. TR Problem in Small TG (cont.)Optimal TR for small transformation graphs 61 Distributed Systems Middleware Group
    62. 62. TR problem in large TG• In multisimulations, in some scenarios the size of transformation graph and the number of target data items for a specific source data item might be large• Compute a minimum spanning tree of this subgraph [83]• Start with a subtree T consisting of one terminal• While T does not span all terminals – Select a terminal x not in T that is closest to a vertex in T. – Add to T the shortest path that connects x with T Back-up Slides 62 Distributed Systems Middleware Group
    63. 63. TR problem in large TG (cont.)IterativeTR for large transformation graphs1. Input: P: The initial plan, K: Number of iterations;2. Output: P: The refined plan;1. for all j=0 to k do2. Ni= SelectNode(P);3. RefinePlan(P,Ni);4. return P;RefinePlan 63 Distributed Systems Middleware Group
    64. 64. An emergency response usecase smoke wrapper wrapper cars demand CFAST Drillsim num. of ongoing calls cell-throughput building geometry wrapper wrapper cell-throughput TranSim LTESim 64 Distributed Systems Middleware Group
    65. 65. Geographies registered in the case study: Simulator Type Entity Types Description Raster Cell UCI outdoor region Drillsim Raster Cell CalIT2 building floors Raster Cell DBH building floors TranSim Network Node, Link Road Network LTESim GIS Point, Polygon Cell towers and throughputInput and Output Parameters of simulators: Simulator Type Data item type Geo. Type Drillsim In Cell-throughput int (0-100) Cell Occupancy int(>=0) Cell Out Cars demand int(>=0) Cell Num. of ongoing calls int(>=0) Cell TranSim Cars demand int(>=0) Node In Cell-throughput int (0-100) Node Cars int(>=0) Node Out Occupancy int(>=0) Link LTESim In Num. of ongoing calls int(>=0) Point Out Cell-throughput int (0-100) Polygon 65 Distributed Systems Middleware Group
    66. 66. Transformations Graphs cell-to-polygon walking mph-to-km/h user C28 1 speed speed C30 cell-to-polygon LTESim smoke-to-levelDrillsim harmful condition C29 C21 4 smoke-to-health health smoke CFAST C21 C22 Drillsim num. of cell-to-polygon ongoing num. of C28 users 2 calls polygon-to-cellDrillsim cell-to-polygon LTESim 5 pathloss C31 coverage C29 polygon-to-cell cell-to-node LTESim Drillsim C32 cars demand C8 num. of cars throughput 3 TranSimDrillsim C9 cell-to-node 66 Distributed Systems Middleware Group
    67. 67. Transformations ResultsTransformation Convertor Total num. Total time Avg. time Avg. Transformation Avg.TR Transformation time ID (ms) overhead (ms) time (ms) (ms) 1 30 109 2.208 0.020 4.442 2.645 28 106 2.285 0.021 29 3 0.382 0.127 2 28 24 0.592 0.024 0.024 0.024 29 0 0 0 3 8 22 0.409 0.018 0.808 0.423 9 8 1.869 0.233 4 21 300 6.207 0.020 0.048 0.032 22 300 8.345 0.027 5 31 21 0.408 0.019 0.904 0.810 32 9 1.998 0.222 67 Distributed Systems Middleware Group
    68. 68. Experiment set up- large graphs• The default value for α and β is set to one in the cost function meaning that the communication and computation normalized cost units are the same• The effect of using optimal and heuristic TR algorithms in reduction of transformation cost• Generate random graphs with GT-ITM random graph generator [23] (2500 nodes and 10660 edges with latency between 10 to 90 ms)• Measurements are averaged for 500 data exchange over the complete multisimulation phase (over 3500 actions) 68 Distributed Systems Middleware Group
    69. 69. Experiment Results 69 Distributed Systems Middleware Group
    70. 70. Outline Motivation for New Simulation Platforms Reflective Architecture and Methodology Synchronization in Multisimulations  Modeling Synchronization Problem using concepts from Multidatabases  A Hybrid Scheduling Approach  Optimizations: Checkpointing and roll-back; Relaxation models  An Emergency Response Case Study Data Exchange in Multisimulations  Modeling Data Exchange using Transformation Graphs  Data Transformation Plan Generation: Algorithms  An Emergency Response Use Case Formal Specification of Multisimulations  Modeling Multismulations in Maude for rapid prototyping and analysis Conclusions and Future work11/28/2012 Leila Jalali 70 Distributed Systems Middleware Group
    71. 71. HLA and MultisimulationsCriterion HLA MultisimulationsObjective ─ Interoperability ─ Semantic Interoperability, Reusability, Flexibility ─ Reusability [24]Formal ─ DEVS/HLA ─ Maude [27]SpecificationDomain ─ Defense ─ Flexible via use of domain ontologies [20]Complexity ─ Low level knowledge ─ No need to conform the internal properties needed ─ Semantic constraints implemented at the ─ Lack of semantic metalevel [22] interoperabilityTime Management ─ Optimistic, Conservative, and Hybrid methods ─ Optimistic and conservative [25?] methods ─ Relaxed dependencies [23]Data Exchange ─ A pub/sub model based on ─ Data exchange using transformation graphs routing spaces and regionsSeparation of ─ Merges domain-specific and ─ Separate concerns related to simulation domain toConcerns integrated simulation [20] Demo paper at Middleware 2009 those related to integration mechanisms [21] [26] aspects [21] ARM’09: Adaptive Reflective Middleware 2009 [22] DOS’10: Middleware Doctoral Symposium 2010 [23] Spring SIW’11: Simulation Interoperability Workshop 2011 [24] FHCT’11: Formal Modeling: Actors, Open Systems, Biological Systems 2011 [25] submitted to TOMACS’12: ACM Transactions on Modeling and Computer Simulation 2012 [26] Caltech Smart Grid Symposium 2011 [27] TMS/DEVS’11: Theory of Modeling and Simulation 2011 11/28/2012 Leila Jalali 71 Distributed Systems Middleware Group
    72. 72. Conclusion and Future work  Contributions: 1. Architecture for simulation integration  A methodology to develop multisimulations 2. Time synchronization  Hybrid approach for synchronization  Relaxation model 3. A Data Exchange Use-case  TR graph and algorithms 4. Formal specification using Maude capabilities  Analyze the scenarios in a cost effective development  Future work:  Data Transformations and Ontologies  Adaptive Checkpointing Protocol  End User Experience11/28/2012 Leila Jalali 72 Distributed Systems Middleware Group
    73. 73. Thanks jalalil@uci.edu http://www.ics.uci.edu/~ljalali/ Distributed Systems Middleware11/28/2012 Leila Jalali Group
    74. 74. Back-up slides Distributed Systems Middleware11/28/2012 Leila Jalali Group
    75. 75. Checkpoiting protocol  Back to main slide 11/28/2012 Leila Jalali 75 Distributed Systems Middleware Group
    76. 76. Checkpoiting protocol (cont.) Back to main slide 11/28/2012 Leila Jalali 76 Distributed Systems Middleware Group
    77. 77. Rollback using checkpoints  Restart from a checkpoint • S2 restarts from t=0log • replay all incoming messages using log S1 S2 S3 t=0 • apply the update from S1 at t=8 • continue the execution chki chkj using checkpoints: t=8 • S2 restarts from checkpoint chki t=8 • replay all incoming messages using log t=10 until t=8 then apply the update from S1 t=11 • which checkpoint? the most recent checkpoint before t=8 Back to main slide 11/28/2012 Leila Jalali 77 Distributed Systems Middleware Group
    78. 78. Simulator restarts  S2 aborts because of the update received from S1  S3 aborts because of the update received from S2 S2 • S2 restarts from t=0 S3 • S3 restarts from t=0 • replay all incoming • replay all incominglog messages using log messages using log • apply the update from S1 at • apply the update t=8 from S2 at t=10 update from S1 • continue the execution • continue the t=8 execution t=10 t=10 Back to main slide 11/28/2012 Leila Jalali 78 Distributed Systems Middleware Group
    79. 79. Proof of reduction  Membership of ST in NP: trivial  Hardness: take instance G=(V,E), k of Vertex Cover  Build G’ by subdividing each edge  Set N = set of new vertices  All edges length 1  G’ has Steiner Tree with |E|+k – 1 edges, if and only if G has vertex cover with k vertices Back to main slide 11/28/2012 Leila Jalali 79 Distributed Systems Middleware Group
    80. 80. Approximation algorithms  Several different algorithms that guarantee ratio 2 (or, more precise: 2 – 2/n).  Shortest paths heuristic  Ration 2 – 2/n (no proof here)  Bases on Prim’s minimum spanning tree algorithm Start with a subtree T consisting of one terminal While T does not span all terminals  Select a terminal x not in T that is closest to a vertex in T.  Add to T the shortest path that connects x with T. Back to main slide 11/28/2012 Leila Jalali 80 Distributed Systems Middleware Group
    81. 81. Data Transformations in concurrentexecution  Back to main slide11/28/2012 Leila Jalali 81 Distributed Systems Middleware Group
    82. 82.  Pyramid of specifications: Observe-Analyze-Adapt cycle (i) Observe changes in desired attributes of independently executing simulations at runtime (reification) (ii) Analyze and evaluate whether changes in the observed attributes impact parameters in other simulators (iii) Adapt the execution of the multisimulation by enforcing the changes back into the impacted simulators (reflection)11/28/2012 Leila Jalali 82 Distributed Systems Middleware Group
    83. 83. Using Formal Specifications b. System analyzera. developer try changes Formal Formal methods specification make changes tool Reasoning engine Meta level run-time meta-models inter-dependencies Base level Base level simulator1 simulator2 simulator3 Live data simulator1 simulator2 simulator3 Live data preprocessing steps run-time execution Using Maude specification by a developer to answer questions at design steps: - What kind of simulator we need? - e.g. Micro vs. Macro traffic simulator Maude can help to see the scenarios before the real integration which results in a cost effective Back-up Slides development 11/28/2012 Leila Jalali 83 Distributed Systems Middleware Group
    84. 84. Modeling Multisimulations in Maude Multisimulations concept Maude concept A simulator Maude class (inheriting from Oid-Object) Simulator object Maude object Simulator type Maude rewrite rules Multisimulation configuration Maude configuration Updates, acks Maude messages Behaviour specification Rewrite rules Back to main slide11/28/2012 Leila Jalali 84 Distributed Systems Middleware Group
    85. 85. The Maude Rewriting Language  Developed at SRI  Maximizes simplicity (only equations and rules), Performance and Expressiveness ( Equation pattern matching, User-definable syntax and data)  Features  High performance engine  Modularity and parameterization  Reflection -- using descent and ascent functions  Search and model-checking  Full Maude: > maude.linux full-maude.maud Back to main slide11/28/2012 Leila Jalali 85 Distributed Systems Middleware Group
    86. 86. Using FS to choose a simulator 2. What kind of simulator is appropriate? Developer(integrator) Macro traffic simulator? - tend to model traffic Add a third simulator as a continuous flow Muade Specifications op smokeLevel : Sim-Oid Syn-Oid Int Int -> Msg [ctor] . rl[FS] : Micro traffic simulator? [fs : FS | syn: asyn, smoke: n, temp: t] => [fs : FS | syn: asyn, smoke: n, temp: t] smokeLevel(fs,syn,n,t) . - capture the behavior of Meta level rl[SC] : Traffic Simulator smokeLevel(fs,syn,n,t) …. vehicles and drivers in great detail, including interactions among vehicles, lane Base level changing, etc. Activity Fire Simulator Simulator (Drillsim) (CFAST) Back to main slide 11/28/2012 Leila Jalali 86 Distributed Systems Middleware Group
    87. 87. Using FS to choose a simulator2. What kind of simulator is appropriate?(1) Macroscopic (macro) models (e.g. Strada, Metacor): Low tend to model traffic as a continuous flow, often using formulations based on hydrodynamic flow level of details theories.(2) Mesoscopic (meso) models (e.g. DynaMIT,DYNASMART) : model individual vehicles, but at anaggregate level, usually by speed-density relationshipsand queuing theory approaches. High(3) Microscopic (micro) models: (e.g. MITSIMLab,Vissim) :capture the behavior of vehicles and drivers in • Using Micro simulators can be verygreat detail, including interactions among vehicles, lane time consuming and tedious because of the detailed nature ofchanging, response to incidents, and behavior at the models, the preparation ofmerging points. Add a third simulator to the scenario input data (e.g. network coding and representation) - do we really need it? Fire Activity Simulator Traffic Simulator • Macro simulators do not have Simulator (syn) (fs) (?) ability to capture the detailed behavior needed to study traffic 87 Distributed Systems Middleware 11/28/2012 Leila Jalali networks with dynamic traffic Group
    88. 88. Using FS to add a relationshipMuade Specifications  Modeling the relationships between op smokeLevel : Sim-Oid Syn-Oid Int Int -> Msg [ctor] . rl[FS] : existing simulators [fs : FS | syn: asyn, smoke: n, temp: t] => [fs : FS | syn: asyn, smoke: n, temp: t] smokeLevel(fs,syn,n,t) .  Analyze the parameters sending Meta level rl[SC] : smokeLevel(fs,syn,n,t) …. between the simulators using Maude rules  Decide if we need a new relationship Base level to bring into the scenario Activity Fire Communication Simulator Add a new relationship Simulator Simulator (syn) (fs) (com) numUsers (syn,com,n,t) time-stamp Number of people using Num. of people cellphones in activity simulator smokeLevel(fs,syn,n,t) as a parameter that effects smoke number of users in the time-stamp communication simulator Back to main slide 11/28/2012 Leila Jalali 88 Distributed Systems Middleware Group
    89. 89. Multisimulation configuration  11/28/2012 Leila Jalali 89 Distributed Systems Middleware Group
    90. 90. Configurations transitions Back to main slide11/28/2012 Leila Jalali 90 Distributed Systems Middleware Group
    91. 91. Using capabilities of Maude As the multisimulation system grows, consistency checks become more important Using the reflective capability of Maude to formalize metadata and carry out various meta-analyses  meta-reduce: returns the representation of fully reduced from a term using the equations as a parameter.  meta-apply: simulates the application of a given rewrite rule to a term Explore all the behaviors from an initial state up to termination Checking that in all execution sequences all messages arrive to their destinations Information justifying or qualifying a rule and rate information about a rule Back to main slide  Adapt information exchange9111/28/2012 Leila Jalali Distributed Systems Middleware i.e. granularity of data being Group

    ×