Integrated Simulation Environments

Middleware Solutions for Integrated
Simulation Environments
Leila Jalali
http://www.ics.uci.edu/~ljalali/
ljalali@ics.uci.edu

Distributed Systems Middleware
11/28/2012 Leila Jalali Group

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 work

11/28/2012 Leila Jalali
2 Distributed Systems Middleware
Group

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

Group

Motivation for New Simulation
Platforms
 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 simulators
Group

Simulation Integration- historical
view

Distributed Interactive Simulation (DIS) High Level Architecture (HLA)
(1990–today) Army Projects (1996-today) Defense

1975 1980 1985 1990 1995 2000

SIMulator NETworking (SIMNET)
(1983–1990) Combat Simulators

Defense 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 Games

Internet & Gaming Community

Group

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 applications
Group

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

 Scalability

Group

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
exchange
Group

Autonomous simulators with
specific platform issues

Simulator Platform
Simulator Platform simulator i simulator j

source code parameters databases source code parameters databases

Group

Complex analysis
smart decisions using multisimulations

what-if analysis

policy making algorithms

Autonomous simulators with

Simulator Platform


Group

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

Simulator Platform


Group

Reflective Architecture for Integrated
Simulation 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)

Group

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

Group

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

Group

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
11/28/2012 Leila Jalali  data management
Group

Outline






Group

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

Group

Time Synchronization- related
work
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

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
Group

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]

Group

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]

Group

Dependency Preservation in
Schedules



Group

Schedule Example


Formal Definition: back-up slides

Group

Synchronization Protocol
Base-level Wrappers
Meta-level

 Wrappers are written
for each simulator to internal action allow

control the execution
of individual
simulators

Group

Base-level Wrappers
Meta-level

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

Group

Base-level Wrappers
Meta-level

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

Group

Solutions to Synch. problem



Group

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

Group

Conservative Strategy



current time=ti
...
a1 a2

next action of Sj is delayed:
...
a’1 a’2

current time=tj

Group

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

Group

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 Middleware
31 Distributed Systems
Group

A Cost-Driven Hybrid Scheduling
Strategy
 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

Group

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



Group

Computing the costs



Group

Probability of abort


Back-up Slides

Group

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 Slides

Group

Optimization 2: Relaxing
Dependencies


smok
t-bound=5 s
e
level
walking user
speed v-distance =3m speed

Num. of
ongoing n-update=5 Num. of
users
calls
Group

A Case Study for simulation
integration
 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 Evolution

Group

Experiments: Integrating three simulators using
RAISE

2. Communication Simulator: LTESim
1. Evacuation Simulator: DrillSIM

Total num.
of evacuees

3. Fire Simulator: CFAST
some results
Group

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.

Group

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
Group

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

Group

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

Group

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

Group

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

Group

Outline






Group

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
Nodes

Cell

Links CFAST Drillsim

48 Distributed Systems Middleware Group

Pipeline vs. Concurrent execution
Pipeline 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

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


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, attributes
regions - 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, MAFRA
grouping  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)


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


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 .
C4
Directed edges: d1 k
C Convertors C7 Simulator k
1 .
C6 .
.

back-up slides Distributed Systems Middleware Group
53

Cost Model


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


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
C1
.
. C3 .
. .
.
dmj
C5
.
.
.
C4
d1 k
C7 Simulator k
.
C6 .
.


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
C1
.
. C3 .
. .
.
dmj
C5
.
.
.
C4
d1 k
C7 Simulator k
.
C6 .
.


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
C1
.
. C3 .
. .
.
dmj
C5
.
.
.
C4
d1 k
C7 Simulator k
.
C6 .
.


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

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


TR Problem in Small TG (cont.)
Optimal TR for small transformation graphs


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


TR problem in large TG (cont.)
IterativeTR for large transformation graphs
1. Input: P: The initial plan, K: Number of iterations;
2. Output: P: The refined plan;
1. for all j=0 to k do
2. Ni= SelectNode(P);
3. RefinePlan(P,Ni);
4. return P;
RefinePlan


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


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 throughput

Input 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


Transformations Graphs
cell-to-polygon
walking mph-to-km/h user
C28
1 speed speed
C30 cell-to-polygon LTESim smoke-to-level
Drillsim 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-cell
Drillsim
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
TranSim
Drillsim

C9
cell-to-node 66 Distributed Systems Middleware Group

Transformations Results
Transformation 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


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)


Experiment Results


Outline






Group

HLA and Multisimulations
Criterion HLA Multisimulations
Objective ─ Interoperability ─ Semantic Interoperability, Reusability, Flexibility
─ Reusability [24]
Formal
─ DEVS/HLA ─ Maude [27]
Specification
Domain ─ 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]
interoperability
Time 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 regions
Separation of ─ Merges domain-specific and
─ Separate concerns related to simulation domain to
Concerns 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
Group

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 Experience

Group

Thanks

jalalil@uci.edu


Back-up slides


Checkpoiting protocol


Back to main slide

Group

Checkpoiting protocol (cont.)

Back to main slide

Group

Rollback using checkpoints

 Restart from a checkpoint • S2 restarts from t=0
log • 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

Group

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 incoming
log
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

Group

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

Group

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

Group

Data Transformations in concurrent
execution


Back to main slide

Group

 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)

Group

Using Formal Specifications
b. System analyzer
a. 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
Group

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 slide

Group

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 slide

Group

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

Group

Using FS to choose a simulator
2. 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 an
aggregate level, usually by speed-density relationships
and 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 very
great detail, including interactions among vehicles, lane time consuming and tedious
because of the detailed nature of
changing, response to incidents, and behavior at
the models, the preparation of
merging 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
11/28/2012 Leila Jalali networks with dynamic traffic
Group

Using FS to add a relationship
 Modeling the relationships between
rl[FS] :
existing simulators
=> [fs : FS | syn: asyn, smoke: n, temp: t] smokeLevel(fs,syn,n,t) .  Analyze the parameters sending

Meta level
rl[SC] :
….
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

Group

Multisimulation configuration



Group

Configurations transitions


Back to main slide

Group

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 exchange91
i.e. granularity of data being
Group

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 to
the current state
Add a third simulator
rl[FS] :
 Develop a new simulator as
Meta level

rl[SC] : Traffic Simulator
….
an object in Maude
 Modeling the relationships
between existing simulators
Base level

and the new simulator using
Maude rules
Activity Fire roadBlock(syn,trans,n,t)
Simulator Simulator
(syn) (fs)
time-stamp

Num. of people

Back to main slide
smoke
time-stamp
Group

Abstract Data Type (ADT)
 ADTs are specified in Maude using functional modules
 Data type: elements + operations on these elements

fmod <modname> is
<imports> *** reuse, modularity
<sorts> *** data types and subtyping
<opdecls> *** names/and arities of operations
<eqns> *** how to compute functions
endfm

 Sort
 Kinds
 sort Animal .
 subsort Dog < Animal .

 sorts Terrier Hound Toy Sporting .
 subsorts Terrier Hound Toy Sporting < Dog .

Back to main slide

Group

Operator Declaration
 An operation can be thought of as a pathway between
sorts
op <opname> : <argSorts> -> <resultSort>
[<attributes>] .
 attributes
 assoc, comm, id: <term>, ctor

Back to main slide

Group

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 slide

Group

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 slide

Group

Modeling type of a simulator
 Modeling a simulator
sort Sim-Oid .
op ACS : -> Sim-Oid . *** Activity Simulator

 Type of a simulator: time-stepped or event-based
op 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 slide

Group

Modeling dependencies
 Using Maude messages
 Fire simulator sends the smoke level to the synchronizer
using a Maude operation to create a message
smokeLevel
rl[FS] :
rl[SC] :
[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

Group

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 slide

Group

(4) Hybrid Strategy (cont.)



Back to main slides
11/28/2012 Leila Jalali 100
Group

(4) Hybrid Strategy (cont.)


11/28/2012 Leila Jalali 101
Group

Correct strategy



Back to main slides
Group

Deadlock free strategy



Back to main slides
Group

Data Exchange Architecture

Wrappers
Convertors

Input
Input
Input
Inputs Output
Output
Data Exchange Output
Outputs Module
Geography
Models Geographies

Input
Input
Data Exchange entities
Policies
Output
Output
types
Base level
Simulators

Black Box

Concurrent simulation execution in RAISE Systems Middleware
104 Distributed
Group

Data Transformation in loosely
coupled 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.

Group

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 household’s 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 execution―step (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 household the latitude and
a travel time
longitude
Transportation matrix
of the household and
Demographic, Model store
Behavioral,
GIS data
sources for Household the choice of
Model grocery store
initialization of
models

Store Location
Optimization Output of
mash-up simulation

Eating and Exercise
Model
Group

Transformations Graphs

the latitude and
longitude
of the
1 household and
VISIM
store time
location C28
C30 Google-maps Household
Transportation
C29

the latest simpleConversion
store visited C28 calories
2
Household BMIConversion BMI

C29
age,
weight, etc.

Group

Well-formed Schedule


Group

Schedule



Group

Transformation Graph (cont.)
• How to construct the graph
Transformations
Runtime

C2
C1

C3

C5

C4

C7
C6

Transformation Pool
C8 C9


• How to construct the graph
Transformations
We assume that we have a
Runtime
transformation pool, each
transformation is a set of C2
convertors successively transforms C1
data from one simulator until it
produces a semantically C3
meaningful data for another
simulator: C5

C4

C7
C6

Transformation Pool
C8 C9



Transformations
Runtime
S
C2
C1
.
C3 .
.
dmj
C5

C4
d1 k Simulator k
C7
.
C6 .
.
dnk
C8 C9
Back to main slides Transformation Pool

Transformation Path in TG

Transformations
Runtime
S T1
C2
Simulator i D1 i D1 j Simulator j
C1
.
C3 .
.
D mj
C5

D1i Source data C4
D1k Simulator k
Intermediate data C7
.
D1j Target data C6 .
.
Directed edges:
C1 Convertors

Back to main slides Distributed Systems Middleware Group
113

An incorrect example
 A Schedule: a sequence of external actions (taken by one or
more simulators) interleaved with corresponding meta/wrapper
actions

Group

actions

Group

Pipeline simulation execution- loosely
coupled

 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 for Household
initialization of Model Output of
models mash-up simulation
Store Location
Optimization

Eating and Exercise
Model

Group

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 household’s 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 execution―step (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 household the latitude and
a travel time
longitude
Transportation matrix
of the household and
Demographic, Model store
Behavioral,
GIS data
sources for Household the choice of
Model grocery store
initialization of
models

Store Location
Optimization Output of
mash-up simulation

Eating and Exercise Back to main slides
Model
Group

An Examlpe: CFAST - Drillsim Interaction
Interaction between Fire simulation and Drillsim
smoke from fire can affect someone’s health
Agents Profile : Health
Harmful conditions in
Agents Actions : Tell
each space at any time
People

CFAST Drillsim

Group

Experimental setup
• Three machines (Intel(R) Core™ 2 Duo P8700 2.53 GHz, 4 GB, Pentium(R)4
3 GHz 1 GB, Intel(R) Core™ 2 Duo E8400 3.0GHz, 4GB) connected to each
other with a Gigabit Ethernet controller

interdependent-data

Group

Metamodels

11/28/2012 Leila Jalali Back to main
Distributed Systems Middleware slides
121 Group

Valid Transformation Plan



CV(Ni, Nj)
C1

Ni Nj
Ni
11/28/2012 Leila Jalali 122 Group

Transformation Description

Transformation descriptor: XML using two primitives: DEPENDECNY,
CONVERTOR

<?xml version="1.0" encoding="UTF-8"?>

<MetaTransformer>
<INPUT>1</INPUT>
<OUTPUT>2</OUTPUT>
<DEPENDENCIES>
<DEPENDENCY SOURCE="1" TARGET="2" />
</DEPENDENCIES>
<CONVERTORS>
<CONVERTOR ID="1"
PARAMS="(attName:smoke, attValue:value, depFun:toHelath(value,t))”
</ CONVERTOR >
</ CONVERTORS>
<QOS />
<CTXT />
</MetaTransformer>

11/28/2012 Leila Jalali 123 Group

End of Back-up Slides

THANKS

jalalil@uci.edu


Integrated Simulation Environments

More Related Content

Similar to Integrated Simulation Environments

Recently uploaded

Integrated Simulation Environments

Editor's Notes