eugene syriani * † hans vangheluwe * ‡ amr al mallah * † * ‡ tuscaloosa, al montreal, canada...

M&S-based Design of a Distributed DEVS

SimulatorEugene Syriani*†

Hans Vangheluwe*‡

Amr Al Mallah*

† * ‡

Tuscaloosa, AL Montreal, Canada Antwerp, Belgium

M&S Design of a Distributed DEVS Simulator

2

OUTLINE

Context– Motivation: Model-Driven Engineering

– Purpose: Distributed discrete-event simulation

Model of a DEVS simulator– Main entities

– Distributed & Fault-tolerance entities

Synthesis of a DEVS simulator– Code generation

– Calibration & Optimization

Conclusion


3

MODEL-DRIVEN ENGINEERING (MDE)

Problem Domains

(Domain-Specific) Modeling Languages

Represent the System

…

Low-Level Software Artifacts

Generate the Code

How to bridge the gap?


4

MULTI-PARADIGM MODELING• Model everything

– at the most appropriate level of abstraction(s)

– using the most appropriate formalism(s)

– to reduce accidental complexity

• Techniques:– Meta-Modeling

– Model Transformation

– Model Checking


5

MOTIF[1]

• Designed our own transformation language

• But need to model all aspects of the language– Syntax:

Meta-Model

– Semantics:

Mapping onto DEVS

– Execution:

DEVS simulator

[1] E. Syriani, H. Vangheluwe. A Modular Timed Graph Transformation Language for Simulation-based Design. Journal of Software and System Modeling: 11, pp.1-28. Springer (2011).


6

NEED FOR DISTRIBUTED EXECUTIONModel transformation is a resource-intensive activity

• Handle industrial-scale models with > 1,000,000 elements

• Inter-operability with other tools

Distributed execution of the transformations

Distributed DEVS simulator

Model distributed DEVS simulator


7

2-FOLD ADVANTAGE• For modeling & simulation

– Explicit model of algorithms rigorous analysis & re-use

– Automatic synthesis of distributed simulation architecture

– Systematic way of comparing performance between simulators

– Execute distributed simulations without the physical expensive infrastructure

• For model transformation– Can handle large-scale models and time-intensive transformations

– Support for geographically distributed users & resources


11

THE FORMALISMWhich formalism should we use to model a DEVS simulator?

• Why not DEVS itself! It is an ideal candidate for– Modeling complex systems

– Modularly composing sub-systems

– A single DEVS model can be simulated on many different platforms

– Efficient simulators already exist


12

DEVS simulator entities DEVS model entities

• Atomic Solver• Coordinator• Root Coordinator• Messages• Communication

• Atomic DEVS• Coupled DEVS• Ports• Events• Channels

DEVS MODEL OF A DEVS SIMULATOR


13

EVENTS• Simulators exchange 4 types of messages:

– INIT (s0, source, target, t): initial state of model & simulation time

– * (source, target, t): internal transition due at specific time

– X (x, source, target, t): external input information at specific time

– Y (y, source, target, tN): output information & next time advance

– DONE (source, target, tN): acknowledge that a message has been handled

• Events for distributed management:– Reallocation

– Control

– Logging

– Failure

– RETURN


14

ATOMIC SOLVER

• State– Typical from a DEVS atomic solver

– Active ports

– Activity

• Where is the model stored?– Each atomic DEVS model lies in the state of the Atomic Solver

– Safe since no other simulator will ever interact with another atomic DEVS model

Syntax


15

ATOMIC SOLVER

• ext

– Reacts to each message received (INIT, *, X, REALLOC, CTRL)

– Main algorithm from standard DEVS simulator

• int: Clear some state variables (e.g., output mapping)

• : Output message to outport mapping: Y, DONE, RETURN, LOG

• Time advance– Simulated time vs. actual computation time

– 0 if tN-tL

– if inactive

Semantics


16

COORDINATOR

• State, same as atomic solver +:– Typical from a DEVS coordinator

– Active ports, activity: same as atomic solver

– Coupled DEVS model

– Active children

– Local event list

Syntax


17

COORDINATOR

• ext

– Reacts to all messages received Select function is called upon receiving * message Transfer function upon receiving X or Y

– Main algorithm from standard DEVS simulator

• int: Clear some state variables (e.g., output mapping)

• : Output message to outport mapping: *, Y, X, INIT, DONE, LOG

• Time advance– 0 if active and there is a message to output

– otherwise

Semantics


18

ROOT COORDINATOR

• State:– Active ports, activity: same as atomic solver

– Active children

– Current simulation time

– Termination condition

Syntax


19

ROOT COORDINATOR

• ext

– Reacts to each message received (INIT, DONE, REALLOC, CTRL) Upon receiving DONE: update simulation time

– If termination condition not satisfied: send *

• int: Clear some state variables (e.g., is initial)

• : Output message to outport mapping: *, INIT, LOG

• Time advance– 0 if DONE received

– otherwise

Semantics


20

MODEL OF A DISTRIBUTED ENVIRONMENT

• Each simulation entity runs on a machine– Channels from simulator to each machine

– 1 active channel at a time


21


• Local Coupling Table: atomic DEVS– Models the intra-machine communication

of simulators

– Maps each simulator runningon machine to a unique port (active ports)

– Queues messages received

– Local search: delaysampled from uniform distribution (ms)

– If target simulator not in LCT, send remote

– No concurrency assumed on single machine: LCT waits for call-back (RETURN) from currently processing simulator before sending the next message in the queue

Machine: Coupled DEVS


22


• Activity: atomic DEVS– Modal state: ACTIVE/INACTIVE

– Generates failures

– May generate revival message

– Passivates the LCT

Machine: Coupled DEVS


23


• Remote Coupling Table: atomic DEVS– Similar behavior as LCT

– Keeps a mapping of each simulator in cluster to the machine it is running on

– Remote search: delay sampled from uniform distribution (10-100 ms)

– No waiting for call-back to process next message in queue

Network: Atomic DEVS


24

FAULT-TOLERANCE COMPONENTS

• Monitors each machine to detect failures

• Pings for activity status at regular interval times– Broadcast activity message

– Waits until all machines respond

– After timeout, notifies the Master which machines are alive and which are not

• Master-Monitor communication delay

Monitor: Atomic DEVS


25


• Check pointing mechanism for state restoration

• Receives messages from each simulation entity– Simulator id, last message received, resulting state

• Cleanup mechanism– For every 3rd message received from the same simulator, the 1st one is

removed

• Master-Log communication delay

Log: Atomic DEVS


26


• Overall view– Communicates directly to simulators & machines

– Receives failure notifications

– Requests for logs

• Controls simulation execution– Initialize

– Pause/ Resume

• Re-partitioning– Re-allocates which simulator should run

on which machine

– Delay sampled from uniform distribution

Master: Atomic DEVS


27

OVERALL (META-)MODEL


28

IMPLEMENTATION

• Generic instantiation and parameterization

• Input of the simulation:– DEVS model to simulate

– Termination condition (model-specific)

– Initial partitioning on the machines (set of tuples)

• Simulator model generated at instantiation time– Code generation techniques

– Reflexion

• Re-partitioning modelled with active/inactive channels– Random algorithm

Problem: DEVS does not support variable structure


29

PARAMETERS OF SIMULATION EXPERIMENT


30

DEPLOYMENT• Over a cluster of 32 machines

• PythonDEVS implementation

• Using Python Remote Object[2] middleware (RMI)

• Architecture synthesis– Input: simulation model + original

DEVS model

– Master, Monitor and Log are all on 1 machine, distinct from simulators

– Instantiation through Factory pattern

– Asynchronous broadcast simulation protocol

[2] http://irmen.home.xs4all.nl/pyro/


31

CALIBRATION• Metrics

– Performance

– Failure detection

• Parameters– Timeout duration

– Number of machines


32

CONCLUSION


33

FUTURE WORK

?• Work on time performance

• Completely automate the synthesis of simulators

• Optimize partitioning– Specific to the model transformation

– Detect common “structural patterns” and evaluate if distributing their components results in a more time efficient transformation overall

Matching & Rewriting

eugene syriani * † hans vangheluwe * ‡ amr al mallah * † * ‡ tuscaloosa, al montreal, canada...

Documents

devs simulator slide

s t s s

single devs model

devs execution

atomic slide

atomic devs behavior

devs simulator main

t x ext s