A Simple Discrete-Event Simulation: Part 19

I needed to put some more thought into design before dashing off any more code, so here are more requirements and ideas.

  • The drawing model will be based on performing complete scene redraws. This may happen after every event, after every specified number of events, after specified simulated or real time intervals, after some kind of user action, according to some sort of scale factor, or based on a combination of these or other factors.
  • The first pass will involve graphics and status information.
  • Each object must know how to draw itself graphically. Each will be called upon to do so once per screen draw.
  • Each object must know how to draw associated status information. Some of this may be associated with the standard graphic draw while some may show information used for debugging or state changes.
  • The user should be able to (right?) click on an object and do things like see a context menu or view or modify parameters.
  • The components that make up the simulated environment should be connected by some kind of link element. These link elements will represent valid paths by which entities can move from component to component. Assume the links will be one-way only. In the future these can be enhanced to show animation or complex path features. At the start they need only allow components to reference downstream components. If an upstream link is needed for status it will be created as needed, possibly based on the type of component.
  • The user should have to ability to single-step through events, run at some constant speed in terms of events per second or animation frames per event, pause or freeze the simulation, and reinitialize the simulation.
  • Later, the ability to take and restore snapshots of the simulation should be added.
  • Elements will update their status based on events having to do with them, explicitly, but may also update counters and elapsed time clocks on other redraw events.
  • Elements updating statuses automatically will not cause pauses to wait for users; only events involving entity transitions will do so.

With those general ideas in mind, let’s think about what might be needed for every type of component and entity.

Arrival Component

  • Displays:
    • Component ID
    • Component Name
    • Interval Start Time
    • Current Time
    • Interval End Time
    • # Entities Generated
    • # Entities Remaining
    • Entity ID
    • Activity
  • Updates status when it generates new entities
  • Updates status when it forwards entities to other components

Entry Component

  • Displays:
    • Component ID
    • Component Name
    • Current Time
    • Entity ID
  • Updates status when it receives an entity from the Arrival component and forwards it to a downstream component
  • Clears status after specified delay (unless a new entity is received) or when user steps

Queue Component

  • Displays:
    • Component ID
    • Component Name
    • # Entities in Queue
    • Average Wait Time
    • Longest Wait Time?
    • Entity ID
    • Activity
  • Updates status when it receives a entity
  • Updates status when an entity leaves it (by being pulled, by timing out, or for some other reason
  • Tallies up total wait time and entity count (for entities that exit the queue) for each time interval

Process Component

  • Displays:
    • Component ID
    • Component Name
    • Start Time
    • Elapsed Time
    • Cycle Time
    • Entity ID
    • Activity
  • Updates status when an entity arrives for processing
  • Updates status when the (timed) process completes (may show countdown)
  • Updates status when an entity leaves

Exit Component

  • Displays:
    • Component ID
    • Component Name
    • Arrival Time
    • Entity ID
    • # Exit Events
  • Updates status when an entity arrives
  • Tallies residence time and #entities per interval

Link Component

  • Displays:
    • Component ID?
    • Component Name?
  • ?

Basic Entity

  • Displays:
    • Entity ID
    • Entity Name?
    • System Entry Time
    • System Elapsed Time?
    • Component Entry Time
    • Component Exit Time
    • Current Component Name
  • Entity records its total residence time
  • Entity records the processes and queues it visited
  • Entity records entry and exit time in each queue (or possibly only current queue)

This list is still a bit loose but still greatly clarifies what we’re trying to create.

More properties for each element may be needed beyond what must be displayed (e.g., location, size, color, name, intermediate variables). Given the amount of information to be displayed in some cases the updated information may have to be displayed separately from the graphic representation of the element. Alternatively, there can be a terse mode and a verbose mode depending on whether we’re trying to show basic status or detailed trace and debug information.

This entry was posted in Simulation and tagged . Bookmark the permalink.

Leave a Reply