Successfully reported this slideshow.
Summer Solstice 2013 / Warszawa 1/22
Jiří Fišer, Jiří Škvára
ETOS
discrete event simulation framework
focused on easier te...
Summer Solstice 2013 / Warszawa 2/22
SimPy
[phase 1] student project (2011)
● simple simulations of e-car (transport, refu...
Summer Solstice 2013 / Warszawa 3/22
SimPy – problems
[phase 3, disillusion] disadvantages and limits of SimPy
●
SimPy use...
Summer Solstice 2013 / Warszawa 4/22
SimPy – problems II
● typical SimPy design patterns (e.g. reneging) are both
extremel...
Summer Solstice 2013 / Warszawa 5/22
Solution
[phase 4] search for solution
● using a more abstract formalism together wit...
Summer Solstice 2013 / Warszawa 6/22
Design objectives
separation of simulation code into (at least) two
levels of abstrac...
Summer Solstice 2013 / Warszawa 7/22
Implementation objectives
● simplified and integrated support of basic SimPy
construc...
Summer Solstice 2013 / Warszawa 8/22
Design of ETOS library
PyYAMLPyYAML
SIM-DSL
parser
SIM-DSL
parser
SimPy
process
SimPy...
Summer Solstice 2013 / Warszawa 9/22
SIM-DSL
●
SIM – domain specific language
●
abstract structural notation for structure...
Summer Solstice 2013 / Warszawa 10/22
(ETOS) Simulation
simulation as a whole (global states)
declarative (SIM-DSL) repres...
Summer Solstice 2013 / Warszawa 11/22
Actor
simulated object with attributes during its
lifetime
declarative (SIM-DSL) rep...
Summer Solstice 2013 / Warszawa 12/22
(ETOS) Transaction
task executing actions from (part of) lifetime of an
actor (actor...
Summer Solstice 2013 / Warszawa 13/22
(ETOS) Entity
basic building block – individual executing step of
transaction
A) sim...
Summer Solstice 2013 / Warszawa 14/22
Entity representation
declarative (SIM-DSL) representation
SIM-DSL node encapsulatin...
Summer Solstice 2013 / Warszawa 15/22
Class diagram (UML)
Summer Solstice 2013 / Warszawa 16/22
XValue – value within context
●
values in simulation are often related to simulation...
Summer Solstice 2013 / Warszawa 17/22
<transaction>
<counted_loop count=“#5“>
<work>
<duration>
<normal mu="30600" sigma="...
Summer Solstice 2013 / Warszawa 18/22
class Person(Actor):
def __init__(self, simulation):
super().__init__(simulation)
se...
Summer Solstice 2013 / Warszawa 19/22
Transfer of control
(sub-transaction)
Summer Solstice 2013 / Warszawa 20/22
Conclusions I
Separation of roles
key roles:
● specifiers of actors
(input, global s...
Summer Solstice 2013 / Warszawa 21/22
Conclusions II
New challenges
●
SIM-DSL representation of directional graphs
(for mo...
Summer Solstice 2013 / Warszawa 22/22
Thank you for your attention.
Dzi kuj za uwagę ę ę.
Upcoming SlideShare
Loading in …5
×

ETOS discrete event simulation framework focused on easier team cooperation

1,269 views

Published on

Presentation of ETOS disrite event simulation framork on Summer Solstice 2013 conference

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

ETOS discrete event simulation framework focused on easier team cooperation

  1. 1. Summer Solstice 2013 / Warszawa 1/22 Jiří Fišer, Jiří Škvára ETOS discrete event simulation framework focused on easier team cooperation this contribution is supported by grant from company Severočeské doly a.s. Chomutov (http://www.sdas.cz)
  2. 2. Summer Solstice 2013 / Warszawa 2/22 SimPy [phase 1] student project (2011) ● simple simulations of e-car (transport, refueling, parking&shopping) [phase 2: enthusiasm] selecting a usable tool for discrete event simulation SimPy ● Python programming language (modern, simple, effective) ● clear design and reasonable complexity
  3. 3. Summer Solstice 2013 / Warszawa 3/22 SimPy – problems [phase 3, disillusion] disadvantages and limits of SimPy ● SimPy uses coroutines based on generators by providing a central dispatcher on top of active coroutines – trampoline ⇒ dispatch requests are propagated by re-yielding ● nested coroutines are not directly supported ⇒ large single level coroutines ● the separation of developer's roles is almost impossible – simulation modelers and specifiers (engineers) – low level Python programmers
  4. 4. Summer Solstice 2013 / Warszawa 4/22 SimPy – problems II ● typical SimPy design patterns (e.g. reneging) are both extremely error-prone and almost non-reusable ● problematic post-modifications and extensions (code is not stackable) ● behaviour of Python exceptions in SimPy is undefined or esoteric ● very difficult debugging (some types of failures do not abort simulation) ● slightly surprising GeneratorExit exception (called in generators after leaving of iterator)
  5. 5. Summer Solstice 2013 / Warszawa 5/22 Solution [phase 4] search for solution ● using a more abstract formalism together with a high-level framework (if possible in Python) ● DEVS (Discrete Event System Specification) and DEVSimPy - relatively complex formalism, different from SimPy model - almost non-existent documentation (DEVSimPy) ● design and implementation of new framework on top of SimPy + utilization of SimPy framework and our know-how + early involvement of student in the project
  6. 6. Summer Solstice 2013 / Warszawa 6/22 Design objectives separation of simulation code into (at least) two levels of abstraction: ● declarative description of parametres and lifetime of simulated objects by high level structured language (e.g. XML) ● procedural representation of actions by extended SimPy code in the form of generator coroutines ● the maximal expressivity of declarative code (declarative notation is preferred) ● relaxed and extensible structural notation (elimination of deeply nested „matryoshka“ constructs)
  7. 7. Summer Solstice 2013 / Warszawa 7/22 Implementation objectives ● simplified and integrated support of basic SimPy constructs (especially yielding arguments) ● re-usability of repetitive code by object oriented inheritance or by Python metaprogramming ● time and memory efficiency ● re-usability of auxiliary objects (goal: one instance of auxiliary objects per simulation) ● optimization of slow operations (multiple re-yielding, creation of coroutines)
  8. 8. Summer Solstice 2013 / Warszawa 8/22 Design of ETOS library PyYAMLPyYAML SIM-DSL parser SIM-DSL parser SimPy process SimPy processcontrol entities control entities transaction engine transaction engine simulation entities simulation entities SIM-DSL model of simulation SIM-DSL model of simulation SimPy objects (queues, resources, signals, etc) SimPy objects (queues, resources, signals, etc) executes use checkpointscheckpoints executes use collect data from extends reads by XValue (context) XValue (context) ETreeETree existing Python libraries ETOS code end-user simulation code
  9. 9. Summer Solstice 2013 / Warszawa 9/22 SIM-DSL ● SIM – domain specific language ● abstract structural notation for structured simulation data and simulation code ● unification of declarative and procedural code as in Lisp (homoiconicity) ● SIM-DSL supports: ● hierarchical tree of nodes with complex attributes ● specification of random numbers with specific distribution ● time dependent values
  10. 10. Summer Solstice 2013 / Warszawa 10/22 (ETOS) Simulation simulation as a whole (global states) declarative (SIM-DSL) representation set of interlinked SIM-DSL documents procedural (Python) representation instance of class Etos.Simulation derived from class SimPy.Simulation ETOS supports multiple simulation instances which can be executed in multiple threads or processes (e.g. in simple cluster based on Python multiprocessing package)
  11. 11. Summer Solstice 2013 / Warszawa 11/22 Actor simulated object with attributes during its lifetime declarative (SIM-DSL) representation explicit declarative representation of an actor is optional defines attributes with initial values procedural (Python) representation instance of class Actor or derived class
  12. 12. Summer Solstice 2013 / Warszawa 12/22 (ETOS) Transaction task executing actions from (part of) lifetime of an actor (actor's carrier) declarative (SIM-DSL) representation ● SIM-DSL node with child nodes describing individual actions ● transaction can be nested (auxiliary constructs) procedural (Python) representation ● instance of the class Transaction (derived from SimPy.Process class) ● main method -- action: generator based coroutine
  13. 13. Summer Solstice 2013 / Warszawa 13/22 (ETOS) Entity basic building block – individual executing step of transaction A) simple activity of actor = end user entities B) interface to shared services (resources, storages, etc.) C) control statement loop, exception handler, block, etc. D) subtransaction independent SimPy process, which execute part of transaction e.g. body of loop
  14. 14. Summer Solstice 2013 / Warszawa 14/22 Entity representation declarative (SIM-DSL) representation SIM-DSL node encapsulating several types of subnodes: ● attributes of given entity ● common attributes of shared service ● subentities (control entity and subtransactions) procedural (Python) representation instance of class inheriting from ETOS.Entity class shared service entity manages a shared object referring to shared service (Resource, Level, Store) cooperation or competition of several transaction
  15. 15. Summer Solstice 2013 / Warszawa 15/22 Class diagram (UML)
  16. 16. Summer Solstice 2013 / Warszawa 16/22 XValue – value within context ● values in simulation are often related to simulation time, actors or they are bound to single action (entity) example (e-car, cash of recharge): cash = price ∙ (capacity - ttravel ∙ power) ● x-value type and its context are specified only in declarative code <power context=“actor“><normal mu=“2500“ sigma=“100“/></power> Python code is quite simple with minimum of explicit context function of sim.time function of actor's time random for every action = simulated travel random for every actor = e-car
  17. 17. Summer Solstice 2013 / Warszawa 17/22 <transaction> <counted_loop count=“#5“> <work> <duration> <normal mu="30600" sigma="3600"/> </duration> <hourly_wage context="transaction"> <lognormal mu="1.73" sigma="0.57"/> </hourly_wage> </work> <transport> <distance context="transaction"> <lognormal mu="8.0" sigma="1.5"/> </distance> <fare_per_km>0.09</fare_per_km> </transport> <checkpoint> <measure property="a.balance" type="log"/> </checkpoint> </counted_loop> </transaction> hourly-wage is randomly set only once per transaction (explicit context) duration is randomly set for each loop iteration (implicit context: entity) control entities model entities attribute with fixed logging to stderr checkpoint = collects data from simulated system SIM-DSL XML
  18. 18. Summer Solstice 2013 / Warszawa 18/22 class Person(Actor): def __init__(self, simulation): super().__init__(simulation) self.balance = 0.0 class Work(SimpleEntity): tag = "work" def __init__(self, transaction, xmlSource): super().__init__(transaction, xmlSource) self.attributeSetter(("duration", float), ("hourly_wage", float)) def action(self): income = self.duration * self.hourly_wage / 3600.0 self.actor.balance += income yield self.hold(self.duration) registerModule(SummerSolstice) sim = Simulation() sim.start(xmlFile, actor = Person(sim)) registration of entity attributes (name and type) SIM-DSL node name registration of external names from entire Python module Python
  19. 19. Summer Solstice 2013 / Warszawa 19/22 Transfer of control (sub-transaction)
  20. 20. Summer Solstice 2013 / Warszawa 20/22 Conclusions I Separation of roles key roles: ● specifiers of actors (input, global states, SIM- DSL) ● entity implementors (activity specification, SimPy programming) ● transaction editors (high level model, SIM- DSL) ● final processing (statistics, vizualization, ...)
  21. 21. Summer Solstice 2013 / Warszawa 21/22 Conclusions II New challenges ● SIM-DSL representation of directional graphs (for more complex inputs and graph controlled simulations) ● automatic optimization of subtransactions and re- yielding overheads ● documentation with examples ● active software project project is hosted on Google Code http://code.google.com/p/etos
  22. 22. Summer Solstice 2013 / Warszawa 22/22 Thank you for your attention. Dzi kuj za uwagę ę ę.

×