Simulation Modeling in Arena for BU385

Simulation Modeling & Analysis with Arena ® A Business Student’s Primer

FIRST EDITION: JUNE 2005

SELECTED CONTENT FOR BU385

School of Business & Economics, Wilfrid Laurier University

Justin Clarke

Simulation Modeling & Analysis with Arena ®: A Business Student’s Primer Justin Clarke Copyright © 2005 This work is licensed under a Creative Commons License

Attribution-NonCommercial-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor.

Noncommercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a licence identical to this one.

For any reuse or distribution, you must make clear to others the licence terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair dealings and other rights are in no way affected by the above. The full license can be viewed here: http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode

School of Business & Economics, Wilfrid Laurier University 75 University Avenue West Waterloo, ON, N2L 3C5

Warning and Disclaimer This book consists of various basic and intermediate level simulation modeling examples in Arena® 7.01. All examples have been devised using the Basic Edition of Arena® 7.01 and are intended for academic purposes only. This book and its components are provided to enhance knowledge and encourage progress in the academic community and are to be used only for research and educational purposes. Any reproduction or use for commercial purpose is prohibited without the prior express written permission of the primary contributors. The author and the contributors make no representation about the suitability or accuracy of the examples provided herewith for any specific purposes and also make no warranties, either express or implied, or that the use of this book will not infringe any third party patents, copyrights, trademarks, or other rights. The examples and constituent data are provided "as is". The author, contributors, and School of Business shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the examples and models that may accompany it. The opinions expressed in this book belong to the author and are not necessarily those of the School of Business, Wilfrid Laurier University.

Feedback Information The author and the reviewers of this book have created and tested the examples and models in this book with care and precision. It is our goal to create a primer of the highest quality and value, and your feedback as a reader will be a natural continuation of this process. If you have any comments on how we can improve the quality of this book, or otherwise alter it to better suit your needs, you can contact the author and/or the editor. We greatly appreciate your assistance. Author -- Justin Clarke: [email protected] Editor -- Umar Ruhi: [email protected]

Trademark Acknowledgements All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. The author and reviewers cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. • • •

Microsoft®, Microsoft Excel®, and Microsoft Word® are registered trademarks of Microsoft Corporation. Arena® is a registered trademark of Rockwell Software Inc. Mr. Lube® is a registered trademark of Mr. Lube

About the Author Justin Clarke is currently a fourth year business student at Wilfrid Laurier University in the Honours Bachelor of Business Administration (BBA) program. He is specializing in Marketing and is pursuing a minor in Computer Science. Justin has served as President of PRISM, an information technology business that operates within Wilfrid Laurier University providing IT solutions to over 2500 members. He also runs a consulting business, WebArt Promotional Services, providing IT consulting to small businesses specializing in e-business solutions.

About the Reviewers Alan Marshall is a Lecturer in Finance in the School of Business and Economics, where he has also frequently taught Business Decision Models and Operations Management. He has also taught at Atkinson College, where he was for 16 years, and the Schulich School of Business, both at York University. Mr. Marshall's professional experience has included three years at General Motors and running his own consulting firm, which has engaged with institutes, multi-national firms and a foreign government. He has also been a Provincial Examiner for the Society of Management Accountants and an instructor for both the Institute of Canadian Bankers and the Canadian Securities Institute. Umar Ruhi is a member of the Operations and Decision Sciences Area and he lectures in Management Information Systems, Operations Management and e-Business at the School of Business & Economics. A software engineer by profession, Umar holds a B.Sc. degree in Computer Science and an M.B.A. in e-Business & Knowledge Management. With over six years of experience in e-Business consulting, Umar has managed operational technology projects through the design to the deployment stages, and consulted for multinational organizations such as General Electric, and Cisco Systems. His professional qualifications include various industry endorsed certifications including those from IBM, Cisco, Novell and Sun Microsystems. Additionally, Umar has lectured in various information systems and eBusiness courses at the college and university level around Canada, and he has also been a visiting research scholar at Johns Hopkins University in the U.S. Umar’s research interests include Management Information Systems, Knowledge Management, Mobile Technology Applications, Community Informatics, and Supply Chain Management Information Systems.

Simulation Applications in Queuing Theory

Simulation Applications in Queuing Theory: Operationalizing Fundamental Waiting Line Models

Page 76


Table of Contents 1.0 2.0 3.0 4.0 5.0 5.1 5.2 6.0 6.1 6.2 7.0 7.1 7.2

Warnings .................................................................................................... Prerequisites ............................................................................................... Special Functions ......................................................................................... Counters..................................................................................................... Balking ....................................................................................................... Balking if more than X in entire system ........................................................ Balking if more than X in queue .................................................................. Separated Waiting Lines................................................................................ 2 Separated Waiting Lines.......................................................................... N Separated Waiting Lines ......................................................................... Additional Resources .................................................................................... Previous Arena Workbooks ......................................................................... Arena Manuals..........................................................................................

78 78 78 80 83 83 85 88 88 89 93 93 93

Page 77


1.0 Warnings Do NOT save your Arena models on floppy disks. Floppy disks are a very fragile media and are bound to become damaged no matter how carefully you take care of them. Save your work frequently onto a more stable source such as a hard drive, network drive, or a USB key. It should be noted that USB keys aren’t without their own problems – but they are much more reliable than floppy disks. Do NOT save documents directly on the hard drives of public computers as those files are often deleted every time you reboot the computer. If the computer crashes and reboots, you will lose any files on the hard drive. Do NOT save Arena models deep within the folder structure of your computer. There is a limitation in Crystal Reports (the reporting mechanism of Arena) that cannot handle exceptionally long file paths. In newer operating systems (Windows 2000 or Windows XP) if you save your Arena models under My Documents or the Desktop you may have problems. This is because the actual path to these folders is already quite long. For example, the path to the My Documents folder in Windows XP is “C:\documents and settings\user name\My Documents”. If you were to save your model within a few folders under My Documents, it is likely you would run into this problem. A safe location to save these models is to create a folder called “Arena” directly on the C:\ drive and then create a folder for each model inside this folder. Arena will not display reports if you run your simulation from a non-writeable media (such as a CD or a write-protected floppy/USB key), as it cannot write the reports. Also, Arena will not display reports if you run the simulation from inside a compressed folder (zip) for the same reason. Save your model to the hard drive or a writeable media before running the simulation.

2.0 Prerequisites This module assumes you have working knowledge of building models in Arena, running simulations, and analyzing results. If you haven’t used Arena in awhile (or have never used it at all) it is highly recommended that you work through some of the resources identified in the “Additional Resources” section.

3.0 Special Functions Arena has several special functions that are used in gather information on the status of entities, queues, and resources. This information is useful when calculating conditions. Some of these functions will be defined in this section (according to the Arena help files) and will be referred to later in this module. EntitiesWIP (Entity Type) — Number of entities in process. This variable stores the total number of entities of the specified type that are currently in the system (Work In Process). NQ ( Queue ID ) — Number in queue. NQ returns the number of entities in queue Queue ID.

Page 78

Simulation Applications in Queuing Theory NR ( Resource ID ) — Number of busy resource units. Each time an entity seizes or preempts capacity units of a resource, the NR variable changes accordingly. NR is not userassignable; it is an integer value.

Page 79


4.0 Counters Counters can be used in Arena to measure and report a specific statistic. For example, you may wish to count the number of entities that pass through the TRUE and FALSE paths of a condition. Examine the following model:

The situation shown above is a movie theatre where, after buying tickets, customers have a 50% chance of continuing to also buy concessions. This is modeled using a condition module with a 50% 2-way by chance. When you run the report on a model like this, you are able to obtain numbers on the number of entities who left the Buy Tickets process, and the number of entities who left the Buy Concessions process, but to determine those who did not enter the Buy Concessions process would require subtracting the difference between those two numbers. While this is a fairly trivial task, it would be preferable if those counts could be ready in the report after you run it. That is where counters come in. In this example, we will add two counters (or record modules) after the TRUE and FALSE points of the decision module. These counters will increment every time an entity passes through them, and these statistics will be displayed at the end of the report.

Page 80

Simulation Applications in Queuing Theory The following is an updated flow chart with the two record modules:

You must simply add the record modules in the appropriate part of the flow chart (where you want the increment to happen) and name them accordingly. Num Buy Concessions Properties:

Num Skip Concessions Properties:

Page 81

Simulation Applications in Queuing Theory Result from report:

As you can see, you now have an accurate picture of the number of entities which bought and skipped the concessions process. Counters can be used in many other similar circumstances.

Page 82


5.0 Balking Balking is an event whereby an entity decides against entering a queue because of its size. An example of this would be a person deciding against using an ATM machine because there are 3 people in line. Simulating balking is likely handled in the following two ways: 1. An entity will not enter the system if there are more than X entities in the entire system OR 2. An entity will not enter a specific queue if there are more than X entities waiting in the queue

5.1 Balking if more than X in entire system When to use this method: This method is the easiest way to simulate balking, however it is only applicable when balking is based on the number of people in the entire system, not the number of people in only one queue of one process. Situation: You are to model a walk-in clinic. Arrivals are 2 patients per hour in a Poisson distribution. First, a patient must register with a nurse before seeing the doctor. There is only one nurse on duty with service time being exponentially distributed at 3 minutes. Next, a patient must enter a queue to see the doctor. The doctor takes 18 minutes in an exponential distribution to see each patient. Patients arriving will balk (choose to go home / go to another clinic) if there are more than 5 patients in the entire system (i.e. waiting to register with the nurse, being registered by the nurse, waiting to see the doctor, being seen by the doctor). The following is a flow chart of this system (before modelling balking):

Note: We are assuming at this point that you are familiar with creating entities, resources, and processes, setting their arrival/service times, and setting up the simulation run time. In order to simulate balking, we must do the following: 1. Create a condition called “Balk?” before any of the processes (i.e. just after the create module) that, when TRUE, will continue with the process, and when FALSE, will dispose the entity without entering any of the processes. a. TRUE links to the Register with Nurse module b. FALSE links with the next module 2. Add a Balked Patients dispose module that links to the FALSE path of the condition 3. Add a counter (record module) to count the number of patients served (placed just before the Patients Served dispose module) 4. Add a counter (record module) to count the number of patients that balked (placed just before the Balked Patients dispose module)

Page 83

Simulation Applications in Queuing Theory The following is a flow chart of the updated system:

Adding the record modules is done in order to create a statistic that can be analyzed in the report to determine how many balked and how many were served. These two numbers should add up to the NumberOut variable in the report. As this was covered earlier, we will not go into detail on setting these modules up. Furthermore, creating the dispose module is fairly simple as well, so it won’t be covered. The “Balk?” Condition: The following is the properties of the balk condition:

Under Type, choose “2-way by Condition”. This means that a condition expression will be provided that will determine the path the entity will take. This is opposed to “2-way by Chance” where the path of the entity is based solely on a percentage (i.e. TRUE = 90% of the time) Under IF, choose “Expression” (as we are building an expression) Under Value, type “EntitiesWIP(Patient) <= 5”. You may notice EntitiesWIP from an earlier section. It is a function that will count the number of entities in the entire process. You must provide the name of the entity between the parentheses ( and ) (in this case the entity has been named “Patient”, the default entity name is “Entity 1” if you have not changed it). When this condition is evaluated (i.e. whenever an entity is created), it will count the number of entities in the system, and if the count is less than or equal to five, it will

Page 84

Simulation Applications in Queuing Theory evaluate the condition to TRUE and continue the entity on the normal path. If FALSE (i.e. more than five entities in the system), the entity will balk and be disposed early.

5.2 Balking if more than X in queue When to use this method: This method is a more difficult way to simulate balking, however it is more flexible than the previous method. For example, only this method works if you are modelling a multi-stage (multiple process) system and balking can happen before each individual process (i.e. the entity could balk upon entering the first process, but if it continues, it could also choose to balk before entering the second process). In that example, balking is based on the number in the queue that the entity is entering, not on the number of entities in the entire system (across all processes). Situation: You are to model an ATM machine. Arrivals are Poisson distributed at 8 per hour. ATM service time is exponentially distributed at 4 minutes. People will balk (choose to not use the ATM) if there are more than 3 people in the queue (and being served). Note: We are assuming at this point that you are familiar with creating entities, resources, and processes, setting their arrival/service times, and setting up the simulation run time. The following is a flow chart of the system (before modelling balking):

In order to simulate balking, we must do the following: 1. Create a condition called “Balk?” before any of the processes (i.e. just after the create module) that, when TRUE, will continue with the process, and when FALSE, will dispose the entity without entering any of the processes. a. TRUE links to the Use ATM module b. FALSE links with the next module 2. Add a Balked People dispose module that links to the FALSE path of the condition 3. Add a counter (record module) to count the number of patients served (placed just before the People Served dispose module) 4. Add a counter (record module) to count the number of patients that balked (placed just before the Balked People dispose module)

Page 85

Simulation Applications in Queuing Theory The following is a flow chart of the updated system:

As mentioned in the previous example, adding the record modules is done in order to create a statistic that can be analyzed in the report to determine how many balked and how many were served. These two numbers should add up to the NumberOut variable in the report. The “Balk?” Condition: The following is the properties of the balk condition:

Under Type, choose “2-way by Condition” as in the previous example. Under IF, choose “Expression” (as we are building an expression) Under Value, type “NQ(Use ATM.Queue) + NR(ATM) <= 3”. You may notice NQ and NR from an earlier section. NQ is a function that will count the number of entities in a queue. You must provide the name of the queue between the parentheses ( and ) (in this case the process module has been named “Use ATM” – you must add “.Queue” after the name of the process module). NR is a function that will count the number of utilized resources (i.e. the number of people being served in the process, usually one or zero). You must provide the name of the resource that is used by the process between the parentheses ( and ) (in this case the resource was named “ATM”). Note: This not only counts the number of people waiting in line but also includes the person actually being served. Therefore, if the question/problem/situation dictates that an entity will balk if there are more than three people waiting (excluding any being served), then you would exclude the “+ NR(ATM)” portion of the expression. Page 86


When this condition is evaluated (i.e. before the entity enters the process), it will count the number being served and waiting, and if the count is less than or equal to three, it will evaluate the condition to TRUE and continue the entity on the normal path. If FALSE, the entity will balk and be disposed early.

Page 87


6.0 Separated Waiting Lines So far, you have been taught how to simulate waiting lines by having entities line up before a process in a single line and when a spot becomes available in the process, an entity moves out of the queue and enters the service area. This applies if there is one or more resources. However, you haven’t learned yet how to allow a multi-channel (i.e. multiple server/resource) process to have its own line.

6.1 2 Separated Waiting Lines Situation: You are to simulate a Bank Teller system. Arrivals are Poisson distributed at 12 per hour. There are always two tellers on duty at any given time. Teller service time is exponentially distributed at 7 minutes. When customers arrive they see two lines, one for Teller #1 and a separate one for Teller #2. When they arrive, they must choose which line to enter (and they are not allowed to switch lines once they have chosen one). A customer will choose Teller #1’s line if the number of people in line #1 is less than or equal to the number of people in line #2 (includes person being served by teller). The following is a flow chart of the process:

Everything here is fairly standard – there are two process modules (and each process module has a unique resource: Teller #1 and Teller #2). The only tricky part to this model is the condition underlying the “Which Line?” condition module. We must program a condition such that entities will evaluate the line length of both modules and choose lower of the two. Since a condition module always has a TRUE and a FALSE connection, we must write the condition such that when TRUE, the entity will continue along to Teller #1, and whenever FALSE, will travel to Teller #2. “Which Line?” Condition Module Properties: Name: “Which Line?” Type: 2-way by Condition If: Expression NQ(Teller 1.Queue) + NR(Teller Resource 1) <= NQ(Teller 2.Queue) + NR(Teller Resource 2) Value: Page 88


As shown previously and NQ counts the number of entities in a queue, NR counts the number of a resource being utilized (in this case the value will be 0 if no one is being served, 1 if someone is being served). This formula will check to see if the total number in the Teller #1 line is <= the total number in the Teller #2 line. After running a report, you can see the number of people served by Teller #1 and Teller #2 (shown below). It’s important to realize that if the service times are the same for both processes, the first process will most likely serve more entities than the second process because people will enter it first if there is a tie. Report:

6.2 N Separated Waiting Lines The previous example showed how to create two separated waiting lines. However, you may run into situations where you require more than two. This is done similarly with a Condition Module, however, it requires the use of a “N-Way by Condition” type. First, set up your model without the decision module. In this case, we will add another teller to the system:

Next, we must add a decision module:

Page 89


Now, we must add the conditions to the decision module. Instead of choosing “2-way by Condition”, we must choose “N-Way by Condition” and add 2 conditions. The first condition will, when TRUE, send the entity to Teller #1, the second condition, when true, will send the entity to Teller #3. A third condition isn’t needed because if the first two conditions aren’t met, then the FALSE path will be connected to Teller #3. This example can be expanded to accommodate as many tellers as possible. The important point to note is that you need to define N - 1 conditions where N is the number of separate paths. Adding Conditions to N-Way Condition Module: To add a condition to an N-Way Condition Module, double click the module, and choose “NWay by Condition” under type.

Next, click ADD and type the expression in the box shown below:

Page 90


After typing your condition, you will click OK twice to go back to the model and you must then connect that condition to the next appropriate module. Condition #1: - Is the line for Teller #1 shorter than the line for Teller #2? AND - Is the line for Teller #1 shorter than the line for Teller #3? - Arena Expression: (one line) ( NQ(Teller 1.Queue) + NR(Teller Resource 1) <= NQ(Teller 2.Queue) + NR(Teller Resource 2) ) && ( NQ(Teller 1.Queue) + NR(Teller Resource 1) <= NQ(Teller 3.Queue) + NR(Teller Resource 3) )

The first part of this expression (before the && symbol, which means AND) takes the number in queue of Teller #1 plus the number being serviced by Teller #1 and compares it with the same for Teller #2. The second part of this expression compares the same values against Teller #3. After adding this condition to the decision module, link that condition to the Teller #1 path:

Condition #2: - Is the line for Teller #2 shorter than the line for Teller #3?

Page 91

Simulation Applications in Queuing Theory - Arena Expression: (one line) NQ(Teller 2.Queue) + NR(Teller Resource 2) <= NQ(Teller 3.Queue) + NR(Teller Resource 3)

After adding this condition, link it to Teller #2:

ELSE Condition: Finally, link the Else condition to Teller #3:

Page 92


7.0 Additional Resources 7.1 Previous Arena Workbooks It is highly recommended that you review the BU275 module of the Arena Workbook if you haven’t used Arena in awhile. It covers discussion on the different types of systems you will encounter, problem analysis, arena modelling, data collection & curve fitting, reviewing reports, and making recommendations.

7.2 Arena Manuals Arena 5. 6. 7. 8.

comes with a series of manuals that are very helpful. Open Arena Click Help Click Product Manuals Choose “Arena Basic Edition User’s Guide”

Page 93

Simulation Modeling in Arena for BU385

Recommend Documents