Eugene Syriani * † Hans Vangheluwe * ‡ Amr Al Mallah * † * ‡ Tuscaloosa, AL Montreal, Canada Antwerp, Belgium

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 2

MODEL-DRIVEN ENGINEERING (MDE) 3 Problem Domains (Domain-Specific) Modeling Languages Represent the System … Low-Level Software Artifacts Generate the Code How to bridge the gap?

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 4

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 5 [1] E. Syriani, H. Vangheluwe. A Modular Timed Graph Transformation Language for Simulation-based Design. Journal of Software and System Modeling: 11, pp Springer (2011).

NEED FOR DISTRIBUTED EXECUTION Model transformation is a resource-intensive activity Handle industrial-scale models with > 1,000,000 elements Inter-operability with other tools Distributed  Distributed execution of the transformations DEVS simulator  Distributed DEVS simulator Model  Model distributed DEVS simulator 6

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 7

DISCRETE EVENT SYSTEM SPECIFICATION (DEVS) [1] Atomic DEVS – Timed automata – Independent from other models – Reacts to events – Interruptible 8 [1] B. P. Zeigler. Multifacetted Modelling and Discrete Event Simulation., Academic Press, ATOMIC

ATOMIC DEVS BEHAVIOR 9 S t  (s) (s,t 0 ) s s'' s' Y t tyty y1y1 (s)  int (s) X x1x1 txtx t txtx (s,t x )  ext ((s,e),x 1 ) (s 0,0) s0s0 0 (s',t y ) (s'',t x ) e

DISCRETE EVENT SYSTEM SPECIFICATION (DEVS) Coupled DEVS – Modular composition of sub-models – Select function: conflict serialization 10 C A1 A2 A3

THE FORMALISM Which 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 11

DEVS simulator entitiesDEVS model entities Atomic Solver Coordinator Root Coordinator Messages Communication Atomic DEVS Coupled DEVS Ports Events Channels 12 DEVS MODEL OF A DEVS SIMULATOR

EVENTS Simulators exchange 4 types of messages: – INIT (s 0, 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, t N ) : output information & next time advance – DONE (source, target, t N ) : acknowledge that a message has been handled Events for distributed management: – Reallocation – Control – Logging – Failure – RETURN 13

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 14

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 15

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 16

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 17

ROOT COORDINATOR State: – Active ports, activity: same as atomic solver – Active children – Current simulation time – Termination condition Syntax 18

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 19

MODEL OF A DISTRIBUTED ENVIRONMENT Each simulation entity runs on a machine – Channels from simulator to each machine – 1 active channel at a time 20

MODEL OF A DISTRIBUTED ENVIRONMENT Local Coupling Table: atomic DEVS – Models the intra-machine communication of simulators – Maps each simulator running on machine to a unique port (active ports) – Queues messages received – Local search: delay sampled 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 21

MODEL OF A DISTRIBUTED ENVIRONMENT Activity: atomic DEVS – Modal state: ACTIVE/INACTIVE – Generates failures – May generate revival message – Passivates the LCT Machine: Coupled DEVS 22

MODEL OF A DISTRIBUTED ENVIRONMENT 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 ( ms) – No waiting for call-back to process next message in queue Network: Atomic DEVS 23

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 24

FAULT-TOLERANCE COMPONENTS Check pointing mechanism for state restoration Receives messages from each simulation entity – Simulator id, last message received, resulting state Cleanup mechanism – For every 3 rd message received from the same simulator, the 1 st one is removed Master-Log communication delay Log: Atomic DEVS 25

FAULT-TOLERANCE COMPONENTS 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 26

OVERALL (META-)MODEL 27

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 28

PARAMETERS OF SIMULATION EXPERIMENT 29

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 30 [2]

CALIBRATION Metrics – Performance – Failure detection Parameters – Timeout duration – Number of machines 31

CONCLUSION 32

FUTURE WORK ? 33 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