1. Middleware Solutions for Integrated Simulation Environments Leila Jalalihttp://www.ics.uci.edu/~ljalali/ljalali@ics.uci.edu Distributed Systems Middleware11/28/2012 Leila JalaliGroup

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. Introduction 1 Simulation: the process of designing a modelof a real world system and conductingexperiments with this model for our purpose:2cheaper, 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 Jalali3Distributed Systems Middleware Group 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 4Distributed Systems MiddlewareGroup 5. Simulation Integration- historicalviewDistributed Interactive Simulation (DIS)High Level Architecture (HLA) (1990today) Army Projects(1996-today) Defense1975 1980 1985 19901995 2000 SIMulator NETworking (SIMNET) (19831990) Combat SimulatorsDefense CommunityAggregate Level Simulation Protocol (ALSP)(19911997ish) War-gaming models Dungeons and DragonsAdventureBoard GamesMulti-User Dungeon (MUD)(Xerox PARC)Games Multi-User Video GamesInternet & Gaming Community11/28/2012 Leila Jalali 5 Distributed Systems Middleware Group 6. Current approaches DIS 1990ALSP 1991 HLA 1996 not fully requires strict requires the individual simulators to conform todistributed adherence tothe standard; might not be always possible [20] no time causality, i.e., all The standard may not have been designed tomanagementsimulation events handle the new simulator needsservice must be Low level knowledge needed from the does notprocessed inpractitioner [22]managetime stamp order Cost issues, Complexity [22]latency and proven to be Current model registration in HLA needs a lot ofcausality very system manual work [20] foundations specific and does No support for semantic interoperabilityfor distributed not provide a Transparencyreal-time general Network- too big and mainly applied in defenseHLA issimulation [6]interoperability[20] HLA MATLAB- HLA SLX Model-integration20072000 20002011solution [5]specific implementatiosimulation generic modelingtoof a n designed language with RTI environment tool, modeling extensibility, uses a customcommunicati 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 2003Integration of multiple Health care domain, focuses on how data can beBusiness process integrationworkflows transformed before it is used by anothermiddleware to facilitate the integrationdownstream component modelof applications11/28/2012 Leila Jalali 6Distributed Systems MiddlewareGroup 7. General Challenges Managing Complexity of Interoperating Systems Analysis of cause- effect relationships Correctness of Multisimulations What, how, when to exchange the informationamong multiple simulators? Time synchronization: causality correctness Data exchange: data transformations Scalability11/28/2012 Leila Jalali 7 Distributed Systems Middleware Group 8. General Challenges- Our Focus Managing Complexity of Interoperating Systems Analysis of cause- effect relationships Methodology to developmultisimulations using meta-modelsand meta-level modules Correctness of Multisimulations Formal Specifications ofmultisimulations What, how, when to exchange the informationamong 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 Scalabilitygraphs for data exchange11/28/2012 Leila Jalali8 Distributed Systems MiddlewareGroup 9. Autonomous simulators with specific platform issues Simulator PlatformSimulator Platform simulator isimulator j source code parametersdatabases source codeparametersdatabases11/28/2012 Leila Jalali 9Distributed Systems MiddlewareGroup 10. Complex analysissmart decisionsusing multisimulations what-if analysis policy making algorithmsAutonomous simulators withspecific platform issuesSimulator PlatformSimulator Platform simulator i simulator j source code parametersdatabases source code parametersdatabases11/28/2012 Leila Jalali 10Distributed Systems Middleware Group 11. Complex analysissmart decisionsusing multisimulationswhat-if analysis policy making algorithms run-time RAISE MiddlewareTime Synchronizer Data Transformers Integrated simulation environmentactions dependencyactionsdescriptorstypedatadata typesimulator isimulator jspecification Analyzespecification Observe and extractReflect Autonomous simulators withspecific platform issuesSimulator Platform Simulator Platform simulator isimulator jsource code parametersdatabases source codeparametersdatabases11/28/2012Leila Jalali11 Distributed Systems Middleware Group 12. Reflective Architecture for IntegratedSimulation Environments- RAISEComplex Applicationsrun-timeData ExchangeTime Synchronization dependencies DataConsistency Synchronizer Controller TransformersMeta levelLock-tablemeta-actions Lock ManagerExternalAnalyzer & Adaptor DataSourcesMeta modelsStructural specification: UML diagrams, metamodelsInteractions: dependency sets, interdependent data Observe & ExtractReflect Base levelINLET Drillsim Fire, Earthquake LTESim(Transportation Model)(Activity Model)(Crisis Model)(Communication Model)11/28/2012 Leila Jalali12Distributed Systems MiddlewareGroup 13. RAISE Methodology Developer(integrator)Meta level 1. Reification: extract simulators meta-data and construct meta-modelsBase level simulator1 simulator2 simulator3 Live data preprocessing steps Base level Meta levelUML diagrams, human in the loop processMaking the underlying simulators more understandableBack-up Slides11/28/2012Leila Jalali13Distributed Systems MiddlewareGroup 14. RAISE Methodology (cont.) Developer(integrator)Meta levelBase level simulator1 simulator2 simulator3 Live datapreprocessing steps 2. Analysis of meta-models:extract inter-dependencies anddescribe them using dependency 3. descriptorsCreate wrappers for each simulator to interface with meta- level11/28/2012 Leila Jalali 14 Distributed Systems MiddlewareGroup 15. RAISE Methodology (cont.) Developer Decision-maker(integrator) System-wide analyzerrunmultisimulationMeta levelRun-timemeta-modelsinter-dependenciesBase levelBase level simulator1 simulator2 simulator3 Live datasimulator1 simulator2 simulator3 Live datapreprocessing steps run-time execution 3. Run multisimulation: 2. Analysis of meta-models: Wrappers decide whether toextract inter-dependencies andcommunicate with meta-level or notdescribe them using dependency What, how, when to exchange the 3. descriptorsCreate wrappers for eachinformation among multiple simulator to interface with meta-simulators level Ensuring correctness: time synchronization15 Distributed Systems Middleware11/28/2012 Leila Jalali data management Group 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 16Distributed Systems Middleware Group 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:FireSimulatorFire & SmokeActivitySimulator Someone extinguished the fireVisualization time Still the fire there? Conflict 11/28/2012 Leila Jalali17 Distributed Systems Middleware Group 18. Time Synchronization- relatedworkTime In distributedIn networksIn distributedSynchronizatio systemssimulationnapproaches Clock Parallel Discrete Conservative CristianSynchronization -Network timeEvent Simulation Optimistic algorithm protocol Distributed Scaled real- Berkley Time scale Interactive Transformation Simulationtime algorithm -Client-server -Time stamp synch Aggregated Level Lamport -Beacon node Simulation Protocol broadcast algorithm -Light weight time High Level synchronizationArchitecture Time Warp 11/28/2012 Leila Jalali SPEEDS 18Distributed Systems MiddlewareGroup 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 2event 3time time 1: while (simulation still in progress) do1: while (simulation still in progress) do 2:Event e= nextEvent;2: for each tick do3:while(e!=null) do3:read data; 4: process(e);4:modify data; 5: time= timestampe(e);5:time = time + t ; 6: e= nextEvent;6: end for 7:end while7: end while 8: end while(2) The source code of simulators is largely legacy. Need to change as little as possible in implementing time19synchronization 11/28/2012 Leila JalaliDistributed Systems MiddlewareGroup 20. Meta-Synchronization Model Multisimulationdependencies meta-actions Meta levelMetaSynchronizerwrapper wrapperwrapperwrapperactions . . .actions Base level d . . . dSimulator iSimulator j Capture steps in a time-stepped simulator or events in an event-basedsimulator in the concept of multisimulation action Synchronization is needed at the meta level to ensure causalcorrectness (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 Jalali20Distributed Systems MiddlewareGroup 21. Dependencies Internal actions vs. External actions External actions access at least one data item which is an interdependent dataitem [Inspired by global/local transactions] 11/28/2012Leila Jalali 21 Distributed Systems MiddlewareGroup 22. Dependency Preservation inSchedules 11/28/2012 Leila Jalali 22 Distributed Systems MiddlewareGroup 23. Schedule Example Formal Definition: back-up slides 11/28/2012 Leila Jalali 23 Distributed Systems MiddlewareGroup 24. Synchronization ProtocolBase-levelWrappers Meta-level Wrappers are writtenfor each simulator to internal action allowcontrol the executionof individualsimulators11/28/2012 Leila Jalali24 Distributed Systems Middleware Group 25. Synchronization ProtocolBase-levelWrappers Meta-level Wrappers are writtenfor each simulator to internal action allowcontrol the executionexternal action grant*of individual external action allowsimulatorsexternal action done Upon receivingexternal actions: updates on interdependent dataschedule* at meta-level11/28/2012 Leila Jalali25Distributed Systems MiddlewareGroup 26. Synchronization ProtocolBase-levelWrappers Meta-level Wrappers are writtenfor each simulator to internal action allowcontrol the executionexternal action grant*of individual external action allowsimulatorsexternal action done Upon receivingexternal actions: updates on interdependent dataschedule* at meta-level meta-actionsinternal action allowexternal action grant Upon receiving updatesexternal action allowmeta-actions are external action donegenerated at meta-levelupdates11/28/2012 Leila Jalali26Distributed Systems MiddlewareGroup 27. Solutions to Synch. problem 11/28/2012 Leila Jalali 27 Distributed Systems MiddlewareGroup 28. Lock Step Strategy Lock-step Scheduling: the most conservativeapproach 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 Jalali28Distributed Systems MiddlewareGroup 29. Conservative Strategy current time=ti...a1a2next action of Sj is delayed:...a1a2 current time=tj 11/28/2012 Leila Jalali 29 Distributed Systems MiddlewareGroup 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...a1a2 next action of Sj is not delayeda1a2current time=tj 11/28/2012 Leila Jalali30Distributed Systems MiddlewareGroup 31. Effectiveness of Scheduling Strategies Conservative and optimistic strategies maybecome more (or less) effective as amultisimulation progresses Initially, the cost of abort is small, so the optimisticstrategy performs better than conservativestrategy As the simulator proceeds, aborts costs becomeincreasingly high We propose a cost-driven hybrid approach thatcombines the benefits of both the optimistic andconservative strategies by considering theunderlying dependencies to make an informeddecision on whether to abort or delay an action Middleware11/28/2012 Leila Jalali 31Distributed Systems Group 32. A Cost-Driven Hybrid SchedulingStrategy Combines the benefits of both the conservative and optimistic strategies Considers the expected cost of both conservative and optimisticscheduling of each action, and chooses the method with thelower expected cost Minimizes the expected execution time for each simulator inthe integrated executioncurrent time=ti...a1 a2 Need to make a decision to allow the next action of Sj or to dea1 a2 current time=tj 11/28/2012 Leila Jalali32 Distributed Systems Middleware Group 33. How to make the decision? duration of time that Sj may receive an update from Si that results in violation current time=tiupdate on diSia1a2 abortedSja1 ak allowed not aborted current time=tj next action= ak delayed necessaryunnecessary 11/28/2012 Leila Jalali33Distributed Systems MiddlewareGroup 34. How to make the decision? duration of time that Sj may receive an update from Si that results in violation current time=tiupdate on diSia1a2 abortedSja1 ak allowed not aborted current time=tj next action= ak delayed necessaryunnecessary 11/28/2012 Leila Jalali34Distributed Systems MiddlewareGroup 35. Computing the costs 11/28/2012 Leila Jalali 35 Distributed Systems MiddlewareGroup 36. Probability of abortBack-up Slides 11/28/2012 Leila Jalali 36 Distributed Systems MiddlewareGroup 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 MiddlewareGroup 38. Optimization 2: RelaxingDependenciessmokt-bound=5 selevelwalkinguserspeed v-distance =3m speedNum. ofongoingn-update=5 Num. ofuserscalls11/28/2012 Leila Jalali38 Distributed Systems Middleware Group 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 andcalculates the evolving distribution of smoke, fire gases andtemperature 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 levelsimulations of 3GPP Long Term Evolution11/28/2012Leila Jalali 39Distributed Systems Middleware Group 40. Experiments: Integrating three simulators usingRAISE2. Communication Simulator: LTESim1. Evacuation Simulator: DrillSIMTotal num.of evacuees3. Fire Simulator: CFAST some results 11/28/2012 Leila Jalali 40Distributed Systems Middleware Group 41. Case study- simulators propertiesEvacuation Simulator CommunicationFire Simulator Simulator DrillSim LTESimCFAST Simulates a Performs network levelSimulates the effects of response activity simulations of 3GPP LTEfire and smoke inside a evacuationEvent based building Time stepped Open source (in Time stepped Open source (inMatlab)Black-box (no access to Java) Parameters: num. of source) Agent basedtransmit and receive Parameters: building Parameters: health antennas, uplink delay,geometry, materials of profile, visual distance, network layout, channelconstruction, fire speed of walking, num.model, bandwidth,properties, etc. of ongoing call, etc. frequency, receiver noise, Output: temperatures, Output: num. ofetc. pressure, gas evacuees, injuries, etc Output: pathloss, concentrations: CO2, etc. throughput, etc. 11/28/2012 Leila Jalali41 Distributed Systems Middleware Group 42. Experiments Intermediate PhaseEarly PhaseIntermediate Phase Late Phase Early PhaseLate Phase(a)simulation phase (no. of actions) (b)simulation phase (no. of actions) OS: OptimisticCS: ConservativeHS: HybridLS: 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. Experiments- dependencies2400.531830.2101243.0081127.999 1082.647903.162 975.581710.081639.099320.073315.492 27.288 36.87327.26335.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 43Distributed Systems Middleware Group 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 MiddlewareGroup 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 Jalali45 Distributed Systems Middleware Group 46. Experiments- relaxations StrategyCSOSHS Metric Without WithWithout WithWithout With Relaxations Relaxations Relaxations Relaxations Relaxations Relaxations CFAST592.228 510.376 778.364 353.856 292.283 201.598 DrillSim 404.293 393.634 312.182 296.341 104.29398.781 LTEsim 946.432 883.812 1420.091 825.120731.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 46Distributed Systems Middleware Group 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 47Distributed Systems Middleware Group 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.)HarmfulAgents Profile : conditions Health NodesCell Links CFAST Drillsim48Distributed Systems Middleware Group 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 canthe input data of the other simulatorexecute concurrently Need data transformation, GIS Need time synchronization to preserveconversions, time adaptations, etc.casualty (e.g. scheduling) Need intermediate data transformations based on dependencies, GIS conversions, Simulation output etc. Model 1transformedoutputSimulationSimulationModel i ... Model j Simulation Output Model 2intermediateoutputs. . Output . synchronization(a) Pipeline executionSimulation Model n (b) Concurrent execution49Distributed Systems Middleware Group 50. Our Goal Goal: During the concurrent execution of multiple simulators,transform the data generated/updated by simulators intodata 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. Useful approaches for data exchangeData Exchange in HLASchema MappingOntologies A pub/sub model [4] Data Exchange is an old, but recurrent, Matching strategies for- Based on routing spaces anddatabase 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 schemasontologies (e.g. FCA-- Supports dynamic multicast[80] , XML databases [77],Merge, IFMAP, MAFRAgrouping Data exchange & query answering forframeworks) [93]incomplete data sources [PDMS]Data Exchange in S&MData Exchange in workflows DEVS frameworks (Python DEVSIMPY, MATLAB/Simulink) AXMEDIS for workflow management systems Model integration (using DSML) Integration of multiple workflows (SESA) 51Distributed Systems Middleware Group 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 inanother simulator Modeled as a directed graph of convertors We assume that the transformations between two dependent data items are given to usTransformations RuntimeC2 Simulator i AC1B Simulator jC352Distributed Systems Middleware Group 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 edgeRuntimeC2Simulator i d1 id1 jSimulator j C1. .C3. .. .D1i Source data dmjC5Intermediate data..D1j Target data .C4Directed edges: d1 k C Convertors C7 Simulator k 1 .C6 . . back-up slides Distributed Systems Middleware Group 53 54. Cost Model54 Distributed Systems Middleware Group 55. Transformation problem Transform a single source data item to a single target dataitem 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 dataitems Consider some of the dependencies among multiple simulators Retain flexibility to model/run multiple data exchange scenarios Transform Multiple source data item - multiple target55Distributed Systems Middleware Group 56. Transformation (one-to-one) Transform a single source data item to a singletarget data item Consider one dependency between two data items at a time |N| = 2: Shortest path Runtime C2 Simulator i d1 i d1 jSimulator jC1..C3 .. ..dmj C5... C4d1 k C7Simulator k . C6. .56Distributed Systems Middleware Group 57. Transformation (one-to-all) Transform a single source data item to all targetdata items Consider all the dependencies for a data item N = V: minimum spanning treeRuntimeC2Simulator i d1 id1 jSimulator j C1. .C3. .. .dmjC5...C4d1 kC7 Simulator k .C6 . . 57 Distributed Systems Middleware Group 58. Transformation (one-to-many) Transform a single source data item - multiple target dataitems 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)RuntimeC2Simulator i d1 i d1 jSimulator j C1 . .C3 . . . . dmjC5 . . .C4 d1 kC7Simulator k.C6.. 58Distributed Systems Middleware Group 59. Transformation problem: our focus Given a transformation graph find atransformation plan with minimum totalcost from a single source data item tomultiple target data items NP-hard (the problem of computing the Minimumdirected Steiner Tree can be reduced to an instanceof this problem) in small transformation graphs Polynomial time algorithm for Steiner tree when we haveO(1) terminals [78] in large transformation graphs Shortest paths heuristic bases on Prims minimum59 Distributed Systems Middleware Group 60. TR Problem in Small TG In multisimulations, in some of real world scenarios thesize of transformation graph and the number of targetdata items for a specific source data item is relativelysmall the experiments of soup membrane can be used to solvethe Steiner Tree Problem efficiently [78] Polynomial time algorithm for Steiner tree when we haveO(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. TR Problem in Small TG (cont.)Optimal TR for small transformation graphs 61 Distributed Systems Middleware Group 62. TR problem in large TG In multisimulations, in some scenarios the sizeof transformation graph and the number of targetdata items for a specific source data item mightbe large Compute a minimum spanning tree of thissubgraph [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 Slides62 Distributed Systems Middleware Group 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 63Distributed Systems Middleware Group 64. An emergency response usecase smokewrapper wrappercars demandCFASTDrillsimnum. ofongoing calls cell-throughput building geometrywrapper wrapper cell-throughput TranSim LTESim 64Distributed Systems Middleware Group 65. Geographies registered in the case study: Simulator TypeEntity TypesDescriptionRasterCell UCI outdoor regionDrillsimRasterCellCalIT2 building floorsRasterCell DBH building floors TranSimNetwork Node, Link Road NetworkLTESimGISPoint, PolygonCell towers and throughputInput and Output Parameters of simulators:Simulator TypeData itemtypeGeo. Type DrillsimInCell-throughput int (0-100)Cell Occupancy int(>=0) CellOut Cars demandint(>=0) Cell Num. of ongoing calls int(>=0) Cell TranSimCars demandint(>=0)Node In Cell-throughput int (0-100) Node Carsint(>=0)NodeOut Occupancy int(>=0)LinkLTESim InNum. of ongoing calls int(>=0)PointOutCell-throughput int (0-100) Polygon 65 Distributed Systems Middleware Group 66. Transformations Graphscell-to-polygon walkingmph-to-km/h user C281speedspeed C30cell-to-polygonLTESim smoke-to-levelDrillsim harmful condition C29 C214smoke-to-healthhealthsmokeCFASTC21 C22Drillsimnum. of cell-to-polygonongoing num. ofC28 users 2calls polygon-to-cellDrillsimcell-to-polygonLTESim5pathloss C31 coverageC29 polygon-to-cellcell-to-node LTESim Drillsim C32cars demand C8num. of carsthroughput 3TranSimDrillsimC9cell-to-node 66Distributed Systems Middleware Group 67. Transformations ResultsTransformation Convertor Total num. Total time Avg. time Avg. Transformation Avg.TR Transformation timeID(ms) overhead (ms)time (ms) (ms)1 30109 2.208 0.0204.4422.64528106 2.285 0.02129 30.382 0.1272 28240.592 0.0240.0240.02429 00 03 8 220.409 0.0180.8080.423981.869 0.2334 21300 6.207 0.0200.0480.03222300 8.345 0.0275 31210.408 0.0190.9040.81032 91.998 0.22267Distributed Systems Middleware Group 68. Experiment set up- large graphs The default value for and is set to one in the cost functionmeaning that the communication and computationnormalized cost units are the same The effect of using optimal and heuristic TR algorithms inreduction of transformation cost Generate random graphs with GT-ITM random graphgenerator [23] (2500 nodes and 10660 edges with latencybetween 10 to 90 ms) Measurements are averaged for 500 data exchange over thecomplete multisimulation phase (over 3500 actions) 68 Distributed Systems Middleware Group 69. Experiment Results69Distributed Systems Middleware Group 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 70Distributed Systems Middleware Group 71. HLA and MultisimulationsCriterion HLA MultisimulationsObjective Interoperability Semantic Interoperability, Reusability, Flexibility Reusability [24]Formal DEVS/HLA Maude [27]SpecificationDomain DefenseFlexible via use of domain ontologies [20]Complexity Low level knowledge No need to conform the internal propertiesneeded Semantic constraints implemented at the Lack of semanticmetalevel [22]interoperabilityTime ManagementOptimistic, Conservative, and Hybrid methods Optimistic and conservative[25?]methods Relaxed dependencies [23]Data Exchange A pub/sub model based on Data exchange using transformation graphsrouting spaces and regionsSeparation of Merges domain-specific and Separate concerns related to simulation domain toConcerns integrated simulation[20] Demo paper at Middleware 2009those related to integration mechanisms [21] [26] aspects[21] ARM09: Adaptive Reflective Middleware 2009[22] DOS10: Middleware Doctoral Symposium 2010[23] Spring SIW11: Simulation Interoperability Workshop 2011[24] FHCT11: Formal Modeling: Actors, Open Systems, Biological Systems 2011[25] submitted to TOMACS12: ACM Transactions on Modeling and Computer Simulation 2012[26] Caltech Smart Grid Symposium 2011[27] TMS/DEVS11: Theory of Modeling and Simulation 201111/28/2012 Leila Jalali 71Distributed Systems MiddlewareGroup 72. Conclusion and Future work Contributions:1. Architecture for simulation integration A methodology to develop multisimulations2. Time synchronization Hybrid approach for synchronization Relaxation model3. A Data Exchange Use-case TR graph and algorithms4. 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 Jalali72 Distributed Systems Middleware Group 73. Thanksjalalil@uci.eduhttp://www.ics.uci.edu/~ljalali/ Distributed Systems Middleware11/28/2012 Leila JalaliGroup 74. Back-up slides Distributed Systems Middleware11/28/2012 Leila JalaliGroup 75. Checkpoiting protocol Back to main slide 11/28/2012 Leila Jalali 75 Distributed Systems MiddlewareGroup 76. Checkpoiting protocol (cont.) Back to main slide 11/28/2012 Leila Jalali 76 Distributed Systems MiddlewareGroup 77. Rollback using checkpoints Restart from a checkpoint S2 restarts from t=0log replay all incoming messages using log S1S2 S3 t=0 apply the update from S1 at t=8 continue the executionchkichkjusing 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 recentcheckpoint before t=8Back to main slide11/28/2012 Leila Jalali 77Distributed Systems Middleware Group 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 incominglogmessages using log messages using log apply the update from S1 at apply the updatet=8from S2 at t=10update from S1 continue the execution continue the t=8 execution t=10 t=10Back to main slide11/28/2012 Leila Jalali78 Distributed Systems Middleware Group 79. Proof of reduction Membership of ST in NP: trivial Hardness: take instance G=(V,E), k of VertexCover 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, ifand only if G has vertex cover with k verticesBack to main slide 11/28/2012 Leila Jalali79 Distributed Systems Middleware Group 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 Prims 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 vertexin T. Add to T the shortest path that connects x with T.Back to main slide 11/28/2012 Leila Jalali 80Distributed Systems Middleware Group 81. Data Transformations in concurrentexecutionBack to main slide11/28/2012 Leila Jalali81 Distributed Systems Middleware Group 82. Pyramid of specifications: Observe-Analyze-Adapt cycle (i) Observe changes in desired attributes of independentlyexecuting simulations at runtime (reification) (ii) Analyze and evaluate whether changes in the observedattributes impact parameters in other simulators (iii) Adapt the execution of the multisimulation by enforcing thechanges back into the impacted simulators (reflection)11/28/2012 Leila Jalali 82Distributed Systems Middleware Group 83. Using Formal Specificationsb. System analyzera. developer try changes Formal Formal methodsspecificationmake changestool Reasoning engine Meta level run-timemeta-modelsinter-dependencies Base levelBase level simulator1 simulator2 simulator3 Live datasimulator1 simulator2 simulator3 Live datapreprocessing steps run-time executionUsing Maude specification by a developer toanswer questions at design steps:- What kind of simulator we need? - e.g. Micro vs. Macro traffic simulatorMaude can help to see the scenarios before the real integration which results in a cost effectiveBack-up Slidesdevelopment11/28/2012Leila Jalali 83Distributed Systems Middleware Group 84. Modeling Multisimulations in Maude Multisimulations concept Maude conceptA simulator Maude class(inheriting from Oid-Object)Simulator objectMaude objectSimulator typeMaude rewrite rulesMultisimulation configuration Maude configurationUpdates, acks Maude messagesBehaviour specification Rewrite rulesBack to main slide11/28/2012 Leila Jalali84 Distributed Systems Middleware Group 85. The Maude Rewriting Language Developed at SRI Maximizes simplicity (only equations and rules), Performanceand Expressiveness ( Equation pattern matching, User-definablesyntax 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 MiddlewareGroup 86. Using FS to choose a simulator2. What kind of simulator is appropriate? Developer(integrator) Macro traffic simulator?- tend to model traffic Add a third simulatoras 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 ofMeta level rl[SC] :Traffic Simulator smokeLevel(fs,syn,n,t) .vehicles and drivers ingreat detail, includinginteractionsamong vehicles, laneBase levelchanging, etc. Activity FireSimulator Simulator(Drillsim)(CFAST)Back to main slide11/28/2012 Leila Jalali86 Distributed Systems Middleware Group 87. Using FS to choose a simulator2. What kind of simulator is appropriate?(1) Macroscopic (macro) models (e.g. Strada, Metacor):Lowtend to model traffic as a continuous flow, oftenusing formulations based on hydrodynamic flowlevel of detailstheories.(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, lanetime 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?FireActivitySimulatorTraffic Simulator Macro simulators do not have Simulator (syn) (fs)(?) ability to capture the detailed behavior needed to study traffic87 Distributed Systems Middleware 11/28/2012Leila Jalalinetworks with dynamic traffic Group 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 sendingMeta level rl[SC] : smokeLevel(fs,syn,n,t) .between the simulators using Mauderules Decide if we need a new relationshipBase levelto bring into the scenarioActivityFireCommunicationSimulatorAdd a new relationship SimulatorSimulator (syn) (fs) (com) numUsers (syn,com,n,t)time-stamp Number of people usingNum. of people cellphones in activity simulator smokeLevel(fs,syn,n,t)as a parameter that effectssmokenumber of users in thetime-stamp communication simulator Back to main slide11/28/2012 Leila Jalali88Distributed Systems MiddlewareGroup 89. Multisimulation configuration 11/28/2012 Leila Jalali 89 Distributed Systems MiddlewareGroup 90. Configurations transitionsBack to main slide11/28/2012 Leila Jalali90 Distributed Systems Middleware Group 91. Using capabilities of Maude As the multisimulation system grows, consistency checksbecome more important Using the reflective capability of Maude to formalizemetadata 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 ruleBack to main slide Adapt information exchange9111/28/2012 Leila Jalali Distributed Systems Middlewarei.e. granularity of data being Group 92. Using Formal Specifications (cont.) Running Maude as a simulator to have the abstract view of the integration - Useful when there is no access to the simulation model - Faster simulation e.g. cover all the states (wide range of simulations) in less time - Using Maude reasoning tool to narrowing the states to see which paths leads tothe current state Add a third simulatorMuade Specifications op smokeLevel : Sim-Oid Syn-Oid Int Int -> Msg [ctor] . rl[FS] : [fs : FS | syn: asyn, smoke: n, temp: t] => [fs : FS | syn: asyn, smoke: n, temp: t] smokeLevel(fs,syn,n,t) . Develop a new simulator asMeta level rl[SC] :Traffic Simulator smokeLevel(fs,syn,n,t) . an object in Maude Modeling the relationships between existing simulatorsBase level and the new simulator using Maude rules Activity FireroadBlock(syn,trans,n,t)Simulator Simulator(syn)(fs)time-stampNum. of people smokeLevel(fs,syn,n,t) Back to main slidesmoketime-stamp 11/28/2012 Leila Jalali92 Distributed Systems Middleware Group 93. Abstract Data Type (ADT) ADTs are specified in Maude using functional modules Data type: elements + operations on these elementsfmod is *** reuse, modularity *** data types and subtyping *** names/and arities of operations *** how to compute functionsendfm Sort Kinds sort Animal . subsort Dog < Animal . sorts Terrier Hound Toy Sporting . subsorts Terrier Hound Toy Sporting < Dog .Back to main slide11/28/2012 Leila Jalali93 Distributed Systems Middleware Group 94. Operator Declaration An operation can be thought of as a pathway betweensortsop : -> [] . attributes assoc, comm, id: , ctorBack to main slide11/28/2012 Leila Jalali 94Distributed Systems Middleware Group 95. Full Maude: Configuration Module classes ~ bigger versions of sorts objects ~ bigger versions of variables messages ~ bigger versions of operations An object can be represented as a term < O: C | att1:val1, , attn: valn > O is the object identifier of sort Oid C is the class of the object att1 to attn are the attributes of the object val1 to valn are their current values Example: < "Peter" : Person | age : 35, status : single > Class declarations: class Person | age : Nat, status : Status . Back to main slide11/28/2012 Leila Jalali95Distributed Systems MiddlewareGroup 96. Messages Messages are defined as terms of sort Msg:msgs marry? yes no : Oid Oid -> Msg . Message transmission modeled abstractly since we have multisets: Send a marry? message:crl [propose] : < X : Person | age : N, status : single >=>< X : Person | status : waitFor(Y) >marry?(Y, X)if N > 15 .Back to main slide11/28/2012 Leila Jalali 96Distributed Systems Middleware Group 97. Modeling type of a simulator Modeling a simulatorsort Sim-Oid .op ACS : -> Sim-Oid . *** Activity Simulator Type of a simulator: time-stepped or event-basedop clock:_ : Int -> Attr [ctor] .op smokeHigh:_ : Bool -> Attr [ctor] .op f1 : Int Int -> Bool .vars n t c : Int .var b : Bool .rl[TS] :acs : ACS | smokeHigh: b, clock: c]=> [acs : ACS | smokeHigh: f1(n,t), clock: (c + t)] .rl[EB] :[acs : ACS | smokeHigh: b, clock: c]=> [acs : ACS | smokeHigh: f1(n,t), clock: (c + timestamp(e)] . Back to main slide11/28/2012 Leila Jalali 97 Distributed Systems MiddlewareGroup 98. Modeling dependencies Using Maude messages Fire simulator sends the smoke level to the synchronizerusing a Maude operation to create a messagesmokeLevelop smokeLevel : Sim-Oid Syn-Oid Int Int -> Msg [ctor] .rl[FS] :[fs : FS | syn: asyn, smoke: n, temp: t]=> [fs : FS | syn: asyn, smoke: n, temp: t] smokeLevel(fs,syn,n,t) .rl[SC] :smokeLevel(fs,syn,n,t)[syn : SYN | acs: acs, smoke: n, temp: t]=> [syn : SYN | acs: ACS, smoke: n, temp: t] smoke(syn,acs,n,t).rl[AS] :smoke(syn,acs,n,t)[acs : ACS | smokeHigh: b, clock: c]=> [acs : ACS | smokeHigh: f1(n,t), clock: (c + 1)] .Back to main slides 11/28/2012 Leila Jalali98 Distributed Systems Middleware Group 99. Rules with conditions crl [ crl1 ]: FS(FS1 : fsi(t) | S(s1) | M(m1) | X(x1) | Q(q1) | SmokeLevel(t) { all | current }) ACS(ACS1 | Sub1 | ACS(ACS1) : Acs(t1) -> Acs(t2) : t1 : false | SmokeLevel(t) | tbound: Tboundin, distance : TDis, flag : Distance| unknown ) =>ACS (ACS1 : Acs(t)| P(p1) | M(m1) | X(x1) | Q(q1) | SmokeLevel(t) { all | current1 })ACS (ACS1 | Sub1 | N(N1) : Acs(t) -> N(N2) : t1 : true | SmokeLevel(t) | tbound: Tboundin, distance : TDis, flag : , itemlenth : item | unknown ) if t := t + 1 /tbound := t1 + 1 /distance := (TDis * t+ tbound* item ) / t.Back to main slide11/28/2012 Leila Jalali 99Distributed Systems Middleware Group 100. (4) Hybrid Strategy (cont.) Back to main slides Distributed Systems Middleware 11/28/2012 Leila Jalali 100 Group 101. (4) Hybrid Strategy (cont.) Distributed Systems Middleware 11/28/2012 Leila Jalali 101 Group 102. Correct strategy Back to main slides 11/28/2012 Leila Jalali 102 Distributed Systems Middleware Group 103. Deadlock free strategy Back to main slides 11/28/2012 Leila Jalali 103 Distributed Systems Middleware Group 104. Data Exchange Architecture WrappersConvertors InputInput InputInputs OutputOutput Data Exchange OutputOutputs ModuleGeography Models Geographies InputInput Data Exchange entitiesPolicies OutputOutput typesBase levelSimulators Black Box Concurrent simulation execution in RAISE Systems Middleware104Distributed 11/28/2012 Leila JalaliGroup 105. Data Transformation in looselycoupled integration- SPLASH Time: households may do grocery shopping once a week while the BMI model expects daily calorie input. GIS conversions: may also be needed between, say, the store locator model and the transportation model or the household model. Number of values: Some models may produce a time series of data, while another expects only single event data. In this case, the connector is a sequence of multiple calls to the second model, one for each time series element.11/28/2012 Leila Jalali 105 Distributed Systems Middleware Group 106. Pipeline simulation execution- loosely coupled(cont.) (1) Execute the transportation model to obtain a travel time matrix. Travel time is used in the household model and affects each households choice of grocery store (2) Execute the household model to obtain the state of all households and stores e.g. the latest food store visited by the household, its demographic type (3) Execute a data transformation script to transform the output of step (2) into a format suitable for BMI model executionstep (4). This transformation uses additional data files that describe the characteristics of each person in a household, including age, weight, height, as well as the nutritional characteristics of the food sold at each store (4) Execute the BMI model on the result of step (3) to calculate the BMI of each member of the householdthe latitude and a travel time longitudeTransportation matrix of the household and Demographic, Modelstore Behavioral, GIS data sources forHouseholdthe choice ofModel grocery store initialization of modelsStore Location OptimizationOutput of mash-up simulationEating and Exercise Model11/28/2012 Leila Jalali106 Distributed Systems MiddlewareGroup 107. Transformations Graphs the latitude and longitude of the 1 household andVISIM store time location C28 C30 Google-mapsHouseholdTransportationC29 the latestsimpleConversion store visitedC28calories 2HouseholdBMIConversionBMI C29 age, weight, etc. 11/28/2012 Leila Jalali 107Distributed Systems MiddlewareGroup 108. Well-formed Schedule 11/28/2012 Leila Jalali 108 Distributed Systems Middleware Group 109. Schedule 11/28/2012 Leila Jalali 109 Distributed Systems Middleware Group 110. Transformation Graph (cont.) How to construct the graphTransformations Runtime C2C1 C3 C5 C4 C7 C6Transformation Pool C8C9110 Distributed Systems Middleware Group 111. Transformation Graph (cont.) How to construct the graph TransformationsWe assume that we have aRuntimetransformation pool, eachtransformation is a set ofC2convertors successively transforms C1data from one simulator until itproduces a semantically C3meaningful data for anothersimulator:C5C4C7C6 Transformation PoolC8C9 111 Distributed Systems Middleware Group 112. Transformation Graph (cont.) TransformationsRuntimeSC2Simulator i d1 id1 j Simulator j C1.C3.. dmjC5C4d1 k Simulator kC7.C6..dnkC8C9Back to main slidesTransformation Pool 112Distributed Systems Middleware Group 113. Transformation Path in TG TransformationsRuntimeST1C2Simulator i D1 iD1 j Simulator j C1.C3..D mjC5D1i Source data C4D1k Simulator kIntermediate data C7.D1j Target data C6..Directed edges: C1Convertors Back to main slides Distributed Systems Middleware Group 113 114. An incorrect example A Schedule: a sequence of external actions (taken by one or more simulators) interleaved with corresponding meta/wrapper actions 11/28/2012 Leila Jalali 114 Distributed Systems Middleware Group 115. An incorrect example A Schedule: a sequence of external actions (taken by one or more simulators) interleaved with corresponding meta/wrapper actions 11/28/2012 Leila Jalali 115 Distributed Systems Middleware Group 116. An incorrect example A Schedule: a sequence of external actions (taken by one or more simulators) interleaved with corresponding meta/wrapper actions 11/28/2012 Leila Jalali 116 Distributed Systems Middleware Group 117. Pipeline simulation execution- looselycoupled Provide a framework in which models cannot be tightly integrated into a common framework mediated by sets of input and output data [IBM Splash project]Transportation Demographic, Model Behavioral, GIS data sources forHousehold initialization ofModel Output of models mash-up simulationStore Location OptimizationEating and Exercise Model 117 Distributed Systems Middleware11/28/2012 Leila Jalali Group 118. Pipeline execution- An example scenario time matrix. Travel time is (1) Execute the transportation model to obtain a travel used in the household model and affects each households choice of grocery store (2) Execute the household model to obtain the state of all households and stores e.g. the latest food store visited by the household, its demographic type (3) Execute a data transformation script to transform the output of step (2) into a format suitable for BMI model executionstep (4). This transformation uses additional data files that describe the characteristics of each person in a household, including age, weight, height, as well as the nutritional characteristics of the food sold at each store (4) Execute the BMI model on the result of step (3) to calculate the BMI of each member of the householdthe latitude and a travel time longitudeTransportation matrix of the household and Demographic, Modelstore Behavioral, GIS data sources forHouseholdthe choice ofModel grocery store initialization of modelsStore Location OptimizationOutput of mash-up simulationEating and Exercise Back to main slides Model118 Distributed Systems Middleware11/28/2012 Leila JalaliGroup 119. An Examlpe: CFAST - Drillsim Interaction Interaction between Fire simulation and Drillsim smoke from fire can affect someones healthAgents Profile : Health Harmful conditions in Agents Actions : Telleach space at any time PeopleCFASTDrillsim11/28/2012 Leila Jalali 119 Distributed Systems Middleware Group 120. Experimental setup Three machines (Intel(R) Core 2 Duo P8700 2.53 GHz, 4 GB, Pentium(R)43 GHz 1 GB, Intel(R) Core 2 Duo E8400 3.0GHz, 4GB) connected to eachother with a Gigabit Ethernet controllerinterdependent-data 11/28/2012 Leila Jalali120Distributed Systems Middleware Group 121. Metamodels11/28/2012 Leila JalaliBack to mainDistributed Systems Middleware slides121 Group 122. Valid Transformation Plan CV(Ni, Nj)C1 NiNj NiDistributed Systems Middleware 11/28/2012 Leila Jalali122 Group 123. Transformation Description Transformation descriptor: XML using two primitives: DEPENDECNY, CONVERTOR 1 2