This page serves as an archive of a resource posted on the office course's Learning Management System. It provides assistance in understanding the meaning of common terms used in Discrete Event System simulation modeling – resource, activity, entity, attribute, event, state, state variable, input, input modeling, and output/performance metric. It starts with a resource-centric perspective on the definitions of each, and then it pivots to a concrete example applying each term to a tour-bus modeling problem.
Basic Guide for Identifying Discrete-Event-System Model Components
When building a discrete-event-system simulation model, it is best to start to by identifying the resources of a the real-world system that is being modeled. Once the resources are identified, how all other components contribute becomes clearer. Try using this guide to identify each of the discrete-event-system vocabulary terms in a model. An EXAMPLE is given in the next section below.
RESOURCES: What are the limiting resources in the system that might cause delays when they are unavailable?
- ACTIVITIES: How long will a resource be unavailable at one time? This duration of time (and the probability distribution that describes it) is an activity.
- ENTITIES: The entities of the system are those that move from resource to resource and either wait for resources to become available (delay) or wait within a resource for completion of the activity associated with that resource when combined with that entity. Note that within a simulation model, resources are fixed parts of a process and entities move from resource to resource.
- ATTRIBUTES: The expected length of an activity may only depend upon the resource type as well as attributes of the entities within the resource during the activity. Some entities will require more processing time than others. Some entities will require special processing based on their individual history (e.g., some entities might receive prioritization based on the attribute of the time they entered the system).
- The length of the activity does not depend upon the state of the system outside of that resource. This is why activities are sometimes called "unconditional waits" – the waiting time distribution can be known without "conditioning" on other parameters in the system.
- In contrast, a delay is sometimes called a "conditional wait" because the delay depends upon what is going on elsewhere in the system. For example, in order to guess the time an entity is going to wait in a queue, it is important to know all of the details about every entity ahead of it in the queue. So waiting in a queue is a delay while being serviced by the server at the head of the queue is an activity because the average service time depends only upon the server (the resource) and the entity being served.
- EVENTS: The instants that mark the beginning and ending of an activity (such as the instant a resource becomes busy and the instant the resource becomes available again) are called events. When we program discrete-event-system simulations, the programming logic that executes to evolve the system forward in time is always triggered by an event; the simulation jumps from one event to another, skipping all time in between.
- In a queueing system, the end of service for one entity might also be the start of service to the entity waiting in a queue behind the first entity. We still consider the instant in between the two service durations as an event that separates one activity (the first entity's time being served) with the immediately following activity (the second entity's time being served). A resource that is never idle is still moving from one activity to another; it is not simply processing one large activity.
- STATE: At each event, the system may change its state. In fact, state changes can only occur at events. The state is a quantified snapshot of the system at any particular time (e.g., "5 resources are being used and 30 customers are waiting for service").
- STATE VARIABLE: Within the program of the simulation, we keep track of the system state using a state variable. A group of state variables together is sometimes called a state vector.
- These state variables are discrete (or discrete-time) because they only change at countable instants of time (the events of the discrete event system).
- STATE VARIABLE: Within the program of the simulation, we keep track of the system state using a state variable. A group of state variables together is sometimes called a state vector.
INPUTS and INPUT MODELING: Note that the same simulation model can have very different outputs if the probability distributions associated with each activity change (e.g., if some activities are made to be slower or faster than others or even if the distribution of times changes its shape). For this reason, the probability distributions of the activities are called the inputs of discrete-event-system simulation models, and the choice of probability distribution to best match reality is known as input modeling.
OUTPUTS and PERFORMANCE METRICS: To determine the total amount of delay that an entity will have to experience during its lifetime while waiting for resources to become available, the system must be simulated. Whereas activities can be estimated from data about individual components of a system running in isolation, delays have to be studied experimentally by running a system with different strings of entities entering and leaving the system. So activities are inputs (i.e., determined by technical information known before the simulation) and delays are outputs. Furthermore, to estimate how well a system is performing, statistics must be taken across a large number of entities and/or over an ensemble of simulation runs. During a simulation run, data may need to be aggregated over simulation time in order to calculate a performance metric (e.g., average delay experienced by all entities during the simulation run). The variables in the program that aggregate this information over time may look superficially like state variables, but they are not considered to be state variables because they are not a snapshot at any instant of time; instead, they are a compressed record of data from all time before. For example, in order to calculate the average time spent in a system for an entity type in a queueing system simulation, it may require adding up the time spent in a system over all entities as they exit the system; that summation variable will have to be stored in the program and accessed each time an entity leaves the simulation, but it does not capture the state of the system and it will not be used to guide simulation logic. State variables can trigger simulation logic whereas performance metrics only keep track of information that can be used later to assess how well the simulated system is performing.
SPECIAL NOTES: Real DES models are complex connections of multiple resources together, with entities potentially flowing back through resources that have previously been used. Furthermore, although activity durations are generally determined only by the resource type, entity type, and entity attributes and not by the state of the system, real-world operations may require introducing some state-dependence into the activity distributions. For example, each individual cashier may work more quickly when it is clear that many customers are waiting in a queue. The key point is that the activity duration is determined by statistically consistent properties local to the resource. The major difference between an activity and a delay is that an activity can be programmed ahead of time whereas a delay can only be measured after a simulation is run.
EXAMPLE: Discrete-Event-System Modeling of a Tour-Bus Operation
RESOURCES: The city touring company only has two tour buses. When customers arrive, they have to wait on a tour bus to be available. So the tour buses are the resources (and the customers are the entities).
- ACTIVITIES: The two resources are used in slightly different ways. Bus 1 is used for 1-hour tours of a small section of the city (each bus-1 tour activity is roughly one hour long). Bus 2 is used for longer 2-hour tours and special events where customers can rent the tour buses for longer periods of time (bus-2 tour activities are 2-hours long for some customers or, in the case of a special set of customers, as long as the customer would like).
- ENTITIES: The customers who arrive to take tours are the entities because they are the ones who potentially have to wait for the resources to become available, and they will move to use a resource (take a tour) and then move on to other things (leave the system). They move from resource to resource while the resources (the buses) stay within the system to become available for new entities later.
- ATTRIBUTES: The desired tour type is an attribute of the customer (an entity). A customer might come for a 1-hour tour, a 2-hour tour, or be part of a special party. In the case of a special party, where the numerical value of the tour duration is an attribute of the customer.
- EVENTS: A tour (an activity) could potentially start when a customer arrives. Even if a tour has already started and no buses are available, the number of customers waiting will change when a new customer arrives. So customer arrivals are events. Likewise, the instants when tours end are also events because they mark the end of activities.
- STATE: At a given instant of time, the state of the system might be that there are 5 customers waiting for 1-hour tours, 2 customers waiting for 2-hour tours, and a special party waiting on a 5-hour tour, all while both buses are currently busy providing other tours.
- STATE VARIABLE: When we simulate the tour-bus system, we would have variables that keep track of the number of customers waiting for 1-hour tours, and the number of customers waiting for 2-hour tours, and the number of customers waiting on special tours, and the number and type of buses that are busy. Knowing these state variables would allow us to program the logic that must be triggered at each event.
- STATE: At a given instant of time, the state of the system might be that there are 5 customers waiting for 1-hour tours, 2 customers waiting for 2-hour tours, and a special party waiting on a 5-hour tour, all while both buses are currently busy providing other tours.
INPUTS and INPUT MODELING: The inputs to the tour-bus system are the probabilistic models of the activity durations – the distribution of durations in between customer arrivals of each type, and the distribution of how long each tour type actually takes (because there will be variance around the average tour duration). Choosing these distributions so as to match a real tour-bus system is the process of input modeling.
OUTPUTS and PERFORMANCE METRICS: Each customer who arrives at the touring company has to wait in line for their preferred tour type, take the tour, and then exit the system. Whereas the length of the tour (once on the bus) is known ahead of time, the length of the wait before getting on the bus can only be known from simulating a system with a potentially long line of customers before the focal customer. So that customer's waiting time (or that customer's total time) can be viewed as an output of the system because it can only be known after simulating (whereas the tour duration activity is an input because it can be predicted without knowing how many customers are waiting in line). The operator of the touring company might care about the average (or maximum) waiting time across all customers. This average is a performance metric as it uses data accumulated over multiple customers within a single simulation run (where the customers arrive at random times and have a random preference of tour type). Calculating this performance metric may require introducing variables into the simulation programming that accumulate information from customers as they leave the system. Performance metrics can also be taken across ensembles of simulation runs where each run produces a different string of outputs because the activity durations are drawn randomly (although each activity duration comes from a consistent statistical distribution).
SPECIAL NOTES: In a real-world tour-bus system, some fraction of customers who leave one tour might immediately wish to wait for a new tour (e.g., after a 1-hour tour of one part of the city, a customer might want to start a 2-hour tour of another part of the city). So even a system as simple as a tour-bus operation might realistically be modeled as a network of multiple kinds of resources with different entities following different routes. The key performance metrics could be the average (or maximum) amount of time that any customer waits for a bus, or possibly the average (or maximum) amount of time that any customer spends in the system while both waiting for a bus and on a tour. These performance metrics cannot be calculated without simulating the delays incurred while waiting for resources to be available. That's the key difference between activities and delays – the duration of a tour can be estimated without running a simulation, but the time for one customer to wait on a tour bus to become available depends upon the customers that arrived before, and thus it requires executing the simulation. Activities are inputs, while delays are outputs. Performance metrics aggregate delay information across many customers and/or many simulation runs (where each simulation run has a different random set of delays as outputs).
No comments:
Post a Comment