IE603 Project

Team Group No.33 Digvijay Boob - 100100008 Debajyoti Nandy - 100100073 Praful Giriya - 10D110028 Railway Station Project Problem Statement: Simulation of a Railway Station Ticket Counter with multiple types of customers and different operation time for every counter Assumptions: 1. Each customer goes to the smallest queue available and does not give any preference to its remaining operation time. 2. After any counter gets closed and if two counters are open then each customer randomly occupies a counter. 3. The rate of peak of long distance customers is additional effect, i.e. next departing train has additional effect on long distance customers arrival rate apart from a constant rate which might or might not be for immediate next train. 4. We are not giving any preference to customers based on their types. Our Approach: To simulate different types of customer, we are creating a new entity java class with additional parameters which considers, the type of customer such as First class, long distance etc. To compute different statistics such as Time in Queue, time in system, etc. we have added another set of parameters in the customer class. To incorporate the randomness of arrival of suburban customers, we have used the math.random function in java to generate a random number between 0 and 1 and we have assigned a type variable to designate the type of the customer using the random number generated. After generation of a new customer, we check the size of the queue and we direct the customer to the smallest sized queue. To accomplish this, we have used enter-exit modules. We have 3 counters having different opening times and we have used a global variable to identify the status of the counters. Values of these global variables are assigned by occurrence of events which are based on the operation time of the corresponding counters. When one of the counter gets closed, we direct the existing queue to the open counters. If 2 counters are open, we direct one customer to one of the counter with probability 0.5 and achieved this by using select output module. To address the situation of getting frustrated due to the long waiting time in the queue, we have included a timeout condition in the service module having different timeout criteria based on the customer type. To include the peak arrival of long distance customers before the departure of a long distance train, we have used a rate table in the source, which takes care of the

corresponding rate of arrival of customers, depending on the time left for the train to depart. A separate source module generates long distance customers at a constant rate given in the problem statement. Model Explanation:

As you can see from the picture above, we have used 3 different sources for generation of different types of customers. The source named Suburban generates the first class, second class and season class customers. Assignment of distinct class of the customers is being done by checking the random number generated. We have used a separate entity class My Customer which generates random number to assign customer types, captures arrival time of the entities, computes time in queue& time in system for each entity etc. The probability of assigning a specific type to a customer is done according to the problem statement. We have used two source modules to generate long distance customers. One of them generates at a constant rate specified in the problem statement. Another module generates the long distance customers according to the peak hours before departure of a train, we have used a table which dictates the arrival rate according to the time prior to the departure of the next train. Using the enter-exit module, we are directing a customer to the counter having smallest queue size. For that we are keeping track of customers in each queue by updating them whenever a customer enters that queue or exits that service counter. The status of the counter which depends on the operation timings, are being controlled using global variables and events. When some counter closes (a specific event occurs) with some non-zero queue size, we make the service time of the counter 0, and used the select output module to direct the existing queue to the currently operational counters. When more than one counter is operating, we direct the customer to one of the counter with 0.5 probability using another select output module. While doing this we are

actually passing the customer through one service counter to another service counter. This situation might create two potential problems. Difficulties: One problem is that if we calculate time in system statistics at this end of service counter then is a false reading as we are not giving any service to the customer yet. We are just shifting them to another queue or counter. To address this we are calculating time in system for customers at true end of select output. So we are sure that any customer leaving that end is actually being provided with service and is directly going to sink. Another problem is that calculation of time in queue. Whenever a customer leaves existing queue due to closure of a counter and enters another queue, we might calculate the time in queue in on enter delay field of service module. This is wrong as is customer is still going to another queue. To avoid this problem, we are going to check the status of that counter while calculating the statistics. We are incorporating the possibility of people leaving the queue due to high waiting time, by Timeout in the service module which checks the type of the customer and decides the timeout accordingly. These frustrated customers are forwarded to sink 2. Calculation of statistics: We are calculating total of 12 statistics in this simulation. 1. Time in queue for first class customers 2. Time in queue for second class customers 3. Time in queue for seasonal or additional customers 4. Time in queue for long distance customers 5. Time in system for first class customers 6. Time in system for second class customers 7. Time in system for seasonal or additional customers 8. Time in system for long distance customers 9. Frustrate first class customers 10. Frustrate second class customers 11. Frustrate seasonal or additional customers 12. Frustrate long distance customers We are running a total of 500 simulations. Each time we calculate a statistic we add it to the sequence of that statistic. For e.g. each customers time in queue is added to the statistic TimeinQ<Class of that customer> to make a sequence of that statistic. Then after each simulation run, inside simulation parameter, we add the mean of the sequence (approximately normal distribution) to another statistic called TimeinQ<Class of that customer>avg. From this statistic, we can predict the CI of the time in queue for each class. Similar process is followed for another statistics. As suggested earlier, time in queue is calculated in on enter delay field of service counter based on its status. Time in system is calculated at on exit field for the counter that runs for 24 hrs. For other counters, time in system is calculated at true end of select output when customer is forwarded to sink. Frustrated customers are calculated in timeout field of the service counter. Here also we check the customer flag in order to get the true numbers of customers of each class which are not satisfied with services.

Output Data Analysis: (All time are in hrs.) Time in queue for each type of customers:
500 Simulations Mean Min Max Deviation Mean Confidence Time in Queue First Time in Queue Second Time in Queue Long Time in Queue Class Class Distance Seasonal 0.003 0.011 0.066 0.011 0.002 0.004 0.0004158 0.00003645 0.009 0.014 0.000893 0.00007827 0.042 0.099 0.01 0.0008624 0.007 0.017 0.002 0.0001489

Time in system for each type of customers:

500 Simulations Mean Min Max Deviation Mean Confidence Time in System First Time in System Time in System Long Time in System Class Second Class Distance Seasonal 0.01 0.018 0.125 0.07 0.009 0.016 0.101 0.064 0.011 0.021 0.157 0.076 0.0004215 0.0008942 0.01 0.002 0.00003695 0.00007838 0.0008781 0.0001855

Customer leaving the queue because of high waiting times:

Frustrated First class 106.85 Frustrated Second class 450.67 Frustrated Long distance 12.3 Frustrated additional 28.48

Time in queue for 1. First class customer: 2. Second class customer: 3. Long distance traveler: 4. Seasonal: sec Time in system for 1. First class customer: 2. Second class customer: 3. Long distance traveler: 4. Seasonal: sec

sec sec min

sec sec min

Scope of Improvement: We can give a preference to the customers based on their type. For e.g. first class customer is not willing to wait in queue for longer time as he is paying high amount of

money. So we can cater to them by giving a priority service to such customers. For that we use preemption and give first class customers priority one and all other customers priority zero. Resulting values are as follows:
Frustrated First class 66.73 Frustrated Second class 458.96 Frustrated Long distance 13.22 Frustrated additional 28.91

Time in queue for each customer type:

500 Simulations mean min max Deviation Mean Confidence Time in Queue Time in Queue Time in Queue Long Time in Queue First Class Second Class Distance Seasonal 0.003 0.012 0.068 0.012 0.002 0.008 0.043 0.007 0.004 0.015 0.095 0.017 0.0002932 0.0009395 0.01 0.002 0.0000257 0.00008235 0.0008864 0.000153

Time in system for each type of customer:

500 Simulations mean min max Deviation Mean Confidence Time in System Time in System Time in System Long Time in System First Class Second Class Distance Seasonal 0.01 0.018 0.126 0.07 0.009 0.015 0.102 0.064 0.011 0.022 0.154 0.077 0.0002962 0.0009392 0.01 0.002 0.00002596 0.00008233 0.0008979 0.0002

Conclusion: 1. It is evident that there is very little change in result of time in queue and time in system values when we modify the simulation for priorities. 2. Only significant change occurs in number of first class customers leaving queues because of high waiting times. It comes down from average of 106.85 to average of 66.73. 3. Also it is noted that, even if we give priority to the first class customers, average number of other suburban customers leaving queue due to timeout are still in close proximity to earlier values. This suggest that we can implement this priority without loss of other type of customers. 4. To further decrease the number of customers leaving, we either need to reduce processing times or increase number of counters