NetLogo User Community Models

(back to the NetLogo User Community Models)

Download If clicking does not initiate a download, try right clicking or control clicking and choosing "Save" or "Download".(The run link is disabled for this model because it was made in a version prior to NetLogo 6.0, which NetLogo Web requires.)

## WHAT IS IT?

Customers arrive at an order counter. Interarrival Law: exp(lambda = 10 min)

A single clerk accepts and checks their orders and process payments;
service law: unif (8,10)

Upon completion this step, orders are assigned randomly to one of 2 available stock-persons; service law : unif (16,20)

Customers then leave the system.

Develop a model and experiment 5,000 min. Describe the experience of customers in terms of total time in the system.

A kaizen-team proposes to improve by changing the assignment policy of the stock-person following a FIFO PULL rule: each one of stock-persons pulls next order from a FIFO line.

Verify the improvement.

## HOW IT WORKS

(1) There is a breed of events to represent the future event list. Next customer arrival to the system has always one event; as soon as it is due, this event is re-scheduled, and another event is created to represent the current customer arrival to the system now.

Each time a servant is still providing service to her customer at this tick of time (system clock), a "next departure" event is created.
Once the current customer on a servant reaches her departure time, then it is created a new event to represent that now this clerk or teller (the servant who has completed her service to her customer) is ready to start another piece of work now.

Once the work to do in the go procedure is completed, the FEL (future event list) is recalculared using this breed of events.

Each time a new run of the go procedure starts, the FEL is cleaned, except the next customer arrival event.

(2) There is a breed of mechanisms to represent the active agents that carry out job (value adding stations) of the system.

The final VA (value added) received by each customer is given to her by one of the tellers. It depends on what has done the clerk (former work station). The clerk may have assigned the customer a teller or she may have not. When the clerk assigns the teller to the customer, the customer queues for this concrete teller. When the clerk does not assign a teller to the customer, the customer works in a single queue from which any teller picks next customer when she becomes idle.

Mechanisms work like finit-state machines. They schedule its next task each time the go procedure runs.

(3) There us a breed of entities to represent customers in any phase of the process. The label of the customer entity represents the phase this customer is having now; she may have just arrived to the system and is queueing in front of the clerk; she may be serviced now by the clerk, she may be queueing to receive a teller service, she may be at a teller station receiving service, or she may habe left the system. Notice that entities traverse the systmen horizontally from left to right.

The worksflow os customers is managed using a list that represents the sequence of phases; this list matches the servant (workstation) that corresponds to this phase.

(4) There are exception turtles; its purpose is to manage exceptions; they form the 'police' of the model.

Each procedure takes care of implementing controls in order to have early detection of a potential system malfunction.

## HOW TO USE IT

On the left side of the UI (user interface) we see the classical setup and go buttons.

Before using these buttons, you must select if you want the clerk to be the one who routes the customer to one teller or another, or if you want to work with a single coomon queue of customers waiting for a teller.

Each queue in the model uses FIFO policy.

You can select how many tellers you want to have in the system. (The clerk is always unique).

You will see that the clerk is placed on the left side and all tellers are spread on the same column, to the right of the clerk.

You can decide to set the verify model ON, and in this case instead of using the sthocastic laws mentioned in the specifications (interarrival law, clerk service law, tellers service law), fixed constants are used. This option is interesting in order to verifiy system behavior in a tied-controlled conditions.

You can also decide to use the to select if you want to use the FEL apprach (the system runs faster) to manage the simulator-system-clock, or if you want it to move with a fixed time interval in each tick advance. This feature is also important to verify the model.

On the right side of the window you can see a set of monitor gadgets to to see what is going on on the queues (queue lenght). You see also several monitors with the purpose to clarify idle versus busy time of the servants. You see a capacity plot (time series plot) that shows the % of occupations of the staff, and the lenght of the customer queuing in the system.

And you can see one histogram to verify the distribution of service time.

Finally, you see what the model is required to show: one histogram with the customers lead time (time that customers spend to traverse the system).

## THINGS TO NOTICE

It is important to see if the system reaches or not a steady-state condition. For instance, the lenght of the WIP (num.customers queueing in the system) might be continuously growing, which is a signal of not being in a steady state. The same consideration about the busy time of the value-adding stations.

Have a look to the service time data. It should adhere to the service law said in the specifications.

And, of course, look the result "mean lead time" in order to see if it stabilizes to the voisinage of some value.

## THINGS TO TRY

Experiment with more tellers in the system (use slidebar).
Experiment using the FEL versus not using it. Do you get comparable results?

## EXTENDING THE MODEL

You may try to change the model in order to attend different kind of customers. Try to use a priority for VIP customers. Compare VIP and regular customers in terms of their experience of total lead time in the system.

## NETLOGO FEATURES

(1) traversing a list (sequence of phases) using the item and position commands.

(2) making associations between items of different lists: assing a teller based on the customer phase in the system.

(3) run task command feature to manage the activity of each teller and clerk.

(4) advancing the system-clock by using a FEL implemented with a special breed of turtles; part of this agentset is stationary and part of it is renewed at each run of the go procedure.

## RELATED MODELS

Review literature about queing theory.

## AUTHOR

Jose Costas.
April, 2013

## REFERENCES

David Kelton. Simulation with ARENA. Mc-Graw Hill, 2004.