Simulation of A Food Industry Using Arena

Project Report for M6205

Group Members 1) Ramanathan 2) Muthukumar 3) Leong Hon Wai 4) Liu Jianing

G1101248A G1101249J G1101245K G1101288D

Abstract
AFI (a food industry in Singapore) has been engaged by the nation to provide meals (breakfast, lunch and dinner) for the staffs (varies from 100 to 800 pax) in a local camp. The AFI provides three types of cushiness: Muslim, non-Muslim and vegetarian. There are limited resources such as utensils, seats and AFI is only open daily from 1130AM to 1.30PM to provide meals. Here a AFI which provide three types of meals was modeled in ARENA Simulation Software to study the entity queuing, reneging and balking. While modeling the system, the time to recook, the time to wash the utensils, balking limit and reneging time for three queues were considered. The model is run for time. The results were analyzed and suggestion was also made to improve the system.

CONTENTS 1. Introduction 2. Problem Environment 3. ARENA Model 4. Results 5. Improving the System 6. Conclusion Reference

CHAPTER 1 INTRODUCTION
Simulation tools are often used to model / imitate some real situations or behaviours available in a conditional working environment / system, especially involving with different kind of machines, people, transfer devices and storage limits. The key benefits in using simulation modeling can able users to understand and analyze (1) the characteristics and behaviours of the modeled system, (2) the use of simplifying approximations and assumptions within the simulation, and (3) the fidelity and validity of the simulation outcomes. AFI (a food industry in Singapore) has been engaged by the nation to provide meals (breakfast, lunch and dinner) for the staffs (varies from 100 to 800 pax) in a local camp since year 2004. AFI has been assigned to operate their serving of the meals in a cookhouse, which is situated within the camp vicinity. The resources such as tables, chairs, and eating utensils (bowls, plates, forks and spoons), serving counters, cooking equipment and washing equipment for the eating utensils are provided by the camp. The resources that AFI eventually need to provide are (1) the manpower to cook, wash and serve at the counters and (2) the groceries for the preparation of all the meals. The number of people required to be serve varies for each meal and each type (i.e. muslim, non-muslim and vegetarian) but a rough estimation of the weekly forecast of the eating capacity required for all meals will be provided by the camp (one week ahead).

CHAPTER 2 PROBLEM ENVIRONMENT

2.1 PROBLEM STATEMENT However from the year 2011 onwards, the camp size has been enlarged and thus the number of people needs to be served increased significantly (varies from 200 up to about 1200 pax). With this increment, problems such as (1) mentioned resources provided by camp are currently not enough to turnover, thus causing the staffs have to wait for eating area or eating utensils to be washed, and (2) long queues at the counters of more than 30 minutes will be expected especially for the lunch, which AFI will normally start serving from 1130 hrs to 1330 hrs (duration of 2 hrs). Due to this long waiting, some of the staffs will choose to (1) balk and eat elsewhere, (2) renege due to their work commitments, even though the camp policy has directed all staffs have to consumed their lunch in the cookhouse (since it has been catered for everyone free-of-charge) or (3) the staffs sometimes will switch queue to other meal types, i.e. for non-muslim to vegetarian since vegetarian always has the shortest queue, which this is not allow under the camp policy. Furthermore, there is also occasionally wrong estimation of weekly forecasts by the camp which will lead to over-eating or under-eating. Over-eating will cause AFI to cook more foods which will lead to longer waiting at the queue since there is no food to be served at the counters, whereas under-eating will cause wastage of foods. This assignment aims to simulate the cookhouse situation, typically for the lunch period from 1130 hrs to 1330 hrs by using the ARENA software package. See the floor plan in Annex A. It would be simulated for one month of operations. 2.2 ASSUMPTIONS These assumptions were made during modeling the system. The groceries provided by AFI are assumed to be unlimited. The cookhouse will not stop serving even after 1330 hrs as long there are queues at the counters. Eating utensils are not to be shared by different meal types and they are allocated individually for each meal types (due to religion). All eating to be taken place at the eating area of the cookhouse only. There is no malfunction to the cooking and washing equipment.

2.3 OBJECTIVE OF THE PROJECT The following statistics are of interest: Flow Time

Utilization The objective of the project is to model the AFI in ARENA Simulation Software and find Gear Flow Time (by Type) ii. Gear Delays at operation locations iii. Utilization of Resources iv. Suggest an improvement
expo

CHAPTER 3 ARENA MODEL

3.1 MODELING THE SYSTEM The given system is modeled in ARENA Simulation software. Figure 3.1 depicts the Arena model for the gear shop, consisting of three main segments: 1. Gear Job Arrivals 2. Gear Transportation 3. Gear Processing 4. Gear Departure A segment-by-segment walkthrough of the model follows next:
R ecor d N on M usl m i R eneges D pose or i i al s i gn N M usl on m i cust om er af t er r enegi g n

R emove f r om Q ueue

O r i i al gn

D i at e N upl c on M usl cust om er m i R oved em

Re m o v e d En t i y t

0
D pose s i dupl at e good c i posi i n i queue to n N M usl on m i

Assi n J g var i bl a e

0
S ay Zone O K t

Tr u e

0
D ay f or el R enege Ti e m N Musl on m i S ch N ear on Musl ser ver m i Q ueue

Fa l e s

Assi n Sear ch # g

Fo u n d

C om er N ust ot f ound dur i g n sear ch i t he n N M usl on m i queue

No t

Fo u n d

N M usl on m i C om er ust Ar r i i g vn

Assi g N n on M usl at t r i ut es m i b

D i at e N upl c on M usl m i

0
O r i i al gn

Q ueue
Ser ver Q ueue N M usl on m i

S ze ei

0 0
Du p l a t e c i

N M usl on m i cust om er s ser vi g n

R ecor d N on M usl ser ved m i

N M usl on m i sear chi g f or a n seat

N M usl on m i Dig n in

R ecor d N ber um of N M usl on m i exi i g tn

N M usl Space on m i

0
N M usl on m i cust om eer exi i g tn

D i at e N upl c on M usl m i C om er ust

0
O r i i al gn

0 0

Du p l a t e c i

Bat ch N on M usl U ensi m t i s l

Washi g N n on M usl ut ensi m i s l

Seper at i g N n on M usl U ensi m t i s l

R ease el U ensi t s l

D pose f or N s i on M usl U ensi m t i s l

0 0
D pose Bal ed s i k N M usl on m i C om er s ust

0
R ecor d Bal ed k N M usl on m i C om er s ust

Veget ar i n a C om er ust ar r i i g vn

Assi ni g g n Veget ar i n a cust om er s at t r i ut es b

Veget ar i n a cust om er s ser vi g n

R ecor d Veget ar i n a cust om er s ser ved

Veget ar i n a sear chi g f or a n seat

Veget ar i n a Dig n in

R ecor d N ber um of veget ar i ns a exi i g tn

Veget ar i n a cust om er s exi i g tn

R ecor d M usl m i R eneges

D pose or i i al s i gn M usl cust om er m i af t er r enegi g n

R emove f r om Q ueue Musl m i

O r i i al gn

D i at e M usl upl c m i cust om er R oved em

Re m o v e d En t i y t

0
D pose s i dupl at e good c i posi i n i queue to n M usl m i

Assi n J g var i bl M usl a e m i

0
S ay Zone O K t M

Tr u e

0
D ay f or el R enege Ti e m Musl m i
Assi n Sear ch g M usl # m i

Fa l e s

S ch Musl ear m i ser ver Q ueue

Fo u n d

C om er N ust ot f ound dur i g n sear ch i t he n queue M usl m i

No t

Fo u n d

M usl C om er m ust i Ar r i i g vn

Assi g M usl n m i at t r i ut es b

D i at e upl c M usl m i

0
O r i i al gn

Q ueue
Ser ver Q ueue M usl m i

S ze ei

0 0
Du p l a t e c i

M usl m i cust om er s ser vi g n

R ecor d M usl m i ser ved

M usl m i sear chi g f or a n seat

M usl D i g m in i n

R ecor d N ber um of M usl exi i g m i tn

0
M usl Space m i

0
M usl m i cust om eer exi i g tn

D i at e upl c M usl m i C om er ust

0
O r i i al gn

0 0

Du p l a t e c i

R ease el U ensi M usl t s l m i

Bat ch M usl m i U ensi t s l

Washi g n M usl ut ensi m i s l

Seper at i g n M usl U ensi m t i s l

D pose f or s i M usl U ensi m t i s l

0 0
R ecor d Bal ed k M usl m i C om er s ust

0
D pose Bal ed s i k M usl m i C om er s ust

3.1.1 Non-Muslim Customers Arriving This part includes the arrival section of Non-Muslim Customers. The segment is shown in Figure 3.2.

Non-Muslim entities are created in the Create module, called Non-Muslim Customers Arriving, whose dialog box is displayed in Figure 3.3. The Entities per Arrival field indicates that non-Muslim customers arrive individually, and the Time Between Arrivals section specifies customers inter-arrival times to be exponentially distributed. Following arrival, each incoming customer entity proceeds as a separate entity.

An arriving non-Muslim customer entity next enters the Assign module, called Assign Non Muslim Attribute, whose dialog box is displayed in Figure 3.4. Here, the attribute that the time non muslim customer attribute enter the system is assigned the value of the simulation clock, Tnow, for later use in computing the non muslim customer entitys flow time. The Arena attribute Renege Time Non Muslim is assigned the value of 20 minutes. And the attribute Stay Zone Non Muslim is set as 5. The two attributes are used when we consider the balking and reneging scenarios in the queue. In addition, we set the variable Server Queue Capacity Non Muslim as 500, and the variable Total Customers to record the total numbers of the non muslim customers enter the system. Finally, the attribute Non Muslim Customer # is assigned the value of the numbers of non muslim customers enter the system.

3.1.2 Entity Balking and Reneging Entity balking occurs when an arriving entity or customer does not join the queue because there is no room, but goes away or goes someplace else. Entity reneging occurs when an entity or customer joins a queue on arrival but later decides to jump out and leave, probably regretting not having balked in the first place. After assigning the attributes, we send the new arrivals to a Separate module called Duplicate. This module allows us to make duplicates of the entering entity.

The process for the original entity (customer) is displayed in the following Figure.

First the original entity is sent to a Queue-Size module sequence (from the block panel), where it tries to enter queue Server Queue to wait to be served, then precedes the Seize to the variable Server Queue Capacity.

The entity (customer) proceeds to the process module, first seize a seat and then seize the utensil. The parameters are set as below.

We use a Record module called Record Non Muslim served to record the number of the non muslim customers have been served. It is set as below.

After the customers served, they need to find a seat to have their meals. We use Process module to represent the process. Process times are given as below.

Finally, we use the Record module to record the non muslim customers exiting the system after eating.

As we can see, after the Record module there is still a branch out. Here, we use the Duplicate module once more, thus we can use the number of the non muslims exited the system to represent to number of the utensils used. In the next segment, we consider the washing process. The process is displayed in the figure below.

The used utensils are sent to the return counter, they will be sent to the washing area until the batch size reaches 50. Here we use the holding and batching methods to simulate the process.

Then we set the process time for washing the utensils.

At last we will separate the batch and release the utensils.

Now lets consider the process for the duplicate entity.

The duplicate entity is sent to a Delay module where it is delayed by the renege time that was assigned to the attribute Renege Time.

After the delay, the entity enters an Assign module. The customer is then sent to the following Search module, from the Advanced Process panel. It allows us to search a queue to find the queue position. In our model, we want to find the original customer who created the duplicate entity performing the search. That customer will have the same value for its Non Muslim Customer # attribute as the variable Search # that we just assigned in the Assign module. The search will be over the entire queue, from 1 to NQ. The parameters and search condition are set as below.

For our model, we want to search over the entire queue range, from 1 to NQ, for the original entity that has the same Non Muslim Customer # value as the duplicated entity initiating the search. If the original customer is no longer in the queue, the customer will exit via the Not Found exit point and be sent to the following Dispose module called Customer Not found during search in the Non Muslim queue. If the original customer is found, its rank in the queue will be saved in the variable J. The entity is then send to the Decide module. The check at this module is to see if the value of J is less than or equal to the value of the attribute Stay Zone. If this condition is true, it implies that the position of the customer in the queue is good enough that he chooses to remain in the queue. In this case, we dispose of the duplicate entity. If the condition is false, we want to renege the original customer. Therefore, we send the duplicate entity to the following Remove module. The model for this segment is displayed in the following figure.

The Remove module allows us to remove an entity from a queue and send it to another place in our model.

So far so good, we have done a completed process route for the non muslim customer. Similarly, using the above methods, we can easily model the process for muslim customers and vegetarian customers. The segments are displayed as below.

3.2 SIMULATING THE MODEL The ARENA AFI model was simulated for 2 houors. Parameters like Replication Length and Hours Per Day etc. are given in Run Setup. The Figure 3.20 shows it. While simulation, we can see the movement of entities through different processes and servers, waiting for processing and transferring. After completing the simulation, report will be generated automatically. From the generated report, we can find Customer flow times, and resource utilizations etc.

CHAPTER 4 RESULTS

CHAPTER 5 IMPROVING THE SYSTEM

5.1 SUGGESTION FOR IMPROVEMENT 5.2 COMPARISON OF RESULTS

CHAPTER 6 CONCLUSION

Reference