M&S-based Design of a Distributed DEVS Simulator

1. M&S-based Design of a Distributed DEVS Simulator Eugene Syriani*†Hans Vangheluwe*‡Amr Al Mallah* † * ‡ Tuscaloosa, AL Montreal, Canada Antwerp, Belgium

2. 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 Represent the System (Domain-Specific)Modeling Languages How to bridge the gap? Generate the Code Low-Level Software Artifacts …

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 execution Model 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

8. 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

9. DEVS model of a DEVS simulator DEVS simulator entities DEVS model entities • Atomic Solver • Coordinator • Root Coordinator • Messages • Communication • Atomic DEVS • Coupled DEVS • Ports • Events • Channels

10. 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

11. Atomic solver Syntax • 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

12. Atomic solver Semantics • 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

13. Coordinator Syntax • 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

14. Coordinator Semantics • ext • Reacts to all messages received • Selectfunction is called upon receiving * message • Transferfunction 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

15. Root Coordinator Syntax • State: • Active ports, activity: same as atomic solver • Active children • Current simulation time • Termination condition

16. Root Coordinator Semantics • 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

17. Model of a distributed environment • Each simulation entity runs on a machine • Channels from simulator to each machine • 1 active channel at a time

18. Model of a distributed environment Machine: Coupled DEVS • Local Coupling Table: atomic DEVS • Models the intra-machine communicationof 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

19. Model of a distributed environment Machine: Coupled DEVS • Activity: atomic DEVS • Modal state: ACTIVE/INACTIVE • Generates failures • May generate revival message • Passivates the LCT

20. Model of a distributed environment Network: Atomic DEVS • 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

21. Fault-tolerance Components Monitor: Atomic DEVS • 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

22. Fault-tolerance Components Log: Atomic DEVS • 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

23. Fault-tolerance Components Master: Atomic DEVS • 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 runon which machine • Delay sampled from uniform distribution

24. Overall (meta-)model

25. implementation Problem: DEVS does not support variable structure • 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

26. Parameters of simulation experiment

27. Deployment • Over a cluster of 32 machines • PythonDEVSimplementation • UsingPython 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/

28. Calibration • Metrics • Performance • Failure detection • Parameters • Timeout duration • Number of machines

29. Conclusion

30. 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