EVALUATION OF ALTERNATIVE SCHEDULING SYSTEMS USING SIMULATION

Developed by Gürsen ATAMAL for Ms Seminar



ABSTRACT

This study has been carried out in a company which produces paper and board packages. The study focuses on scheduling in the shop-floor. In this study, the current performance of a package manufacturing plant on predicting future completion dates of the orders was evaluated. At first, some observations were made for the input data. Then some assumptions were made to establish a model. Then a software which represents for the model is developed by using Visual Basic 5.0. At last some certain number of scenarios were generated to have better predicts on the completion dates of the orders


ÖNSÖZ

Bu çalışma kağıt ve karton ambalaj üretimi yapan bir işletmede gerçekleştirilmiştir. Bu çalışma atelyedeki iş çizelgelemesi üzerinde durmaktadır. Bu çalışmada, işletmenin siparişlerin tamamlanma günlerini tahmin etmedeki performansı değerlendirilmiştir. Bunun için öncelikle modelde kullanılacak değişkenlerin tipini belirlemek için bazı gözlemler yapılmıştır. Daha sonra model için bazı varsayımlar yapılmıştır. Daha sonra modeli sanal ortamda temsil edecek simülasyon yazılımı Visual Basic prodramlama dili kullanılarak geliştirilmiştir. Son olarak siparişlerin tamamlanma günlerini daha iyi tespit edebilecek bir kaç senaryo üzerinde çalışılmıştır.



CONTENTS

  1. Introduction
  2. Problem Definition and Objectives
  3. System Definition
    1. Assumptions
    2. Definition of the System
    3. Working Principles of the System
    4. The Software Developed in This Study

  4. Input Data
  5. Development of the Model and the Software
  6. Verification and Validation
    1. Verification of the Model
    2. Validation of the Model

  7. Experimental Design
  8. Analysis of the Results
  9. Conclusion

 

 

 

 

 

1. INTRODUCTION

This study has been carried out in a company which produces paper and board packages. The study focuses on scheduling in the shop-floor. The study includes observations on the system and a software developed in Visual Basic 5.0 to simulate the current system and some certain alternatives to the system to get answers to what-if questions.

 

2. PROBLEM DEFINITION AND OBJECTIVES

The problem that takes place in this plant is that engineers have some difficulties to predict the due dates of orders with a high accuracy. So sometimes the due dates of orders are delayed, and the customers are informed about this situation. But this happens before a couple of weeks that the customers expects to get what he has ordered. Of course this is an unwilling situation for both the customer and the producer.

The target that was aimed in this study is to predict the due dates of the orders with more reliable methods. And perform some certain preventive actions, if any delays seems to takes place. In order to do that, some certain performance criteria must be determined.

    The delay for each order,

    The total delays that take place in a period of time.

 

3. SYSTEM DEFINITION

3.1. Assumptions

    The system is a non-terminating system.

    Jobs are processed on first come first go basis.

    The machines used are not identical.

    The orders cannot be divided into parts to be processed in two of the machines.

    The orders cannot be divided into parts to be processed at different times.

3.2. Definition of the System

In the system there are two non-identical machines called Lemanic and ATN. The number of products of this firm is twenty. And these products can be grouped into two categories. Any of these products can be processed in any of the machines in different standard times. It is enough for a product to be processed in a machine to be ready to be delivered to the customer.

Table3.1. The products of the plant

Category I

Category II

HLB-MLB

DC-MLG

DC-CGG

HLB-MLX

DC-MLG IMAGE

DC-PLD

HLB-CGF

DC-MLX

DC-LMG IMAGE

HLB-CGG

DC-PLH

DC-LMD IMAGE

HLB-LMG

DC-PLH IMAGE

DC-LMH IMAGE

HLB-LMD

DC-CGF

DC-LMZ IMAGE

HLB represents for Hingdle Lid Boxes (means small packages) DC represents Display Cartoon (means big packages)

In the manufacturing department, it accepted that 1 unit of DC is equal to 5 units of HLB. Because the standard time to process one unit of DC is six times greater than the standard time to process one unit of HLB. After this part of the study, one unit of HLB will be called a piece.

3.3. Working Principles of The System

Customers inform the plant about their orders via phone or fax. And these orders are arranged in an order usually in FİFO basis. And when one of the two machines becomes available, the first order is loaded to this machine. After being processed in a machine, the orders becomes ready to be delivered to the customer.

The machine ATN runs 24 hours a day, 7 days in a week. The processing capacity of the machine ATN is 100.000 pieces per hour.

Also the machine Lemanic runs 12 hours a day, 5 days a week. The processing capacity of the machine Lemanic is 62.500 pieces per hour.

3.4. The Software Developed in This Study.

As it was said before, the aim of this study is to make more reliable predicts for the due dates of the orders. To achieve this, a new approach to this system is designed and this approach is transferred to codes in Visual Basic 5.0 to build up a software.

In this approach, the actual production flow is simulated. If we start from the arriving of an order to the plant, the on-going events are as follows.

The plant has a different type of ordering system. In this system customers inform the plant about their actual orders. The actual orders are the orders that the customer want to be completed in one or one and a half month. Also the customers inform the plant about prospective orders for the following five or six months. Of course these orders loose their accuracy, if the completion date gets far from now. (Figure 3.1.)

The arriving order joins a virtual FIFO queue to be processed in any of the machines. When it is time for an order to be processed in a machine, the staff working in the shop-floor is informed about this event. Every order needs a setup time for the machine that it will be processed. The setup time for an order depends on the category of the order which was processed before it on the same machine. For example if the next order that will be processed is in Category I (HLB) and the previous order that was processed is in Category II (DC), then this situation may be called changing from HLB to DC. There are two categories that means four different setup times for a machine. All these are also the same for the second machine. So there are eight different setup type. While processing these orders, some downtimes occurs. These downtimes are caused by the machine or by the nature of the order. Also these two downtimes have different values for two machines.

According to these data it is obvious that, the production time of a certain order depends on these factors:

    The type of the machine in which the order will be processed.

    The setup time of the order in the machine.

    The production capacity of the machine.

    The downtimes that will occur during the processing.

And also the time that an order arrives to shop-floor depends the production time of the orders that have been processed before it.

The logic of the software developed in this study is to simulate this production activities in a virtual environment and to see what can happen in the future.

The first module of the software is about the orders. In this module, there are three processes for the orders:

    Entering an order

    Deleting an order

    Updating an order

All orders have seven attributes:

 

OrderID

The number that represents the order (all orders have different OrderIDs given by the software)

 

Material Name

The name of the product that has been referred in the order.

 

Category

Number that represents for the category that the product belongs. (1 represents for HLB, 2 represents for DC)

 

InDate

The arriving date of the order to the plant

 

DueDate

The date that the customer wants the order to be completed.

 

Quantity

Number that represents the quantity of the ordered product.

 

Order Type

Symbolizes the accuracy of the order (1 represents for the actual orders, 2 represents for the prospective orders)

The second module of the software is about the parameters of the system. In this module, it is possible to see and update the setup times, down times and working days for each machine. (As we said the machine Lemanic runs 5 days a week. But if we want to make overtime in this machine on some certain days, it is possible to reflect this situation to the model in this module)

The most important module of the software is the simulation module. This module simulates the production process and computes the values related to the production. At the end of a replication we get these data related to the system.

 

The arriving date of an order to the job-shop

 

Name of the machine in which the order is being processed

 

The completion date of the order

 

The difference between the due date defined by the customer and the completion day of the order

This simulation is run more than one times. By this way it possible to get different scenarios of the production process. For example we can see if there are any delays for the due dates in the system or not. Also it is possible to see the when the plant has idle time to accept new orders in certain period of time.

If there are any delays for any of the orders there are two ways for the plant. To inform the customer abut this situation, or try to make some changes in the production process and try to predict what can happen. This means to search answers to the what-if questions. The software lets the user to make some changes on the conditions and helps the user to find answers to this type of questions. For example the user can modify the workdays for machine. As we said the machine Lemanic works 5 days a week. The user can make the machine work on the days that he chooses. By this way some delays can be reduced by overtime.

Also some general and fundamental changes may be made on the parameters of the model. Setup times may be reduced by using cross-training stuff in the plant or by using extra staff responsible for setup. Also some improvements may be achieved on downtimes. The downtimes related to machine may be reduced by preventive maintenance, and the downtimes related to the nature of the job may be reduced by using more qualified and experienced stuff. Or the things go bad and the setup times and the downtimes may increase. No matter what happens to these parameters, the changes can be reflected to model by the updating module of the software. By this way the user can find answers to his problems about what happens if these parameters change.

Also it is possible schedule the days-off for the staff using the software. When the orders are less then the capacity for a period of time, some consecutive days can be made off-days. The software is run and the outputs are get under these conditions.

Another useful part of the software can be explained as follows. When we run the software we have the chance to see the future for five or six months. We can try to schedule the orders in different types and by this way we can find an optimum strategy to complete the orders in minimum period of time. And we can suggest this strategy to the customer. For example we can say "if you accept to get your orders in this sequence, there will be no delay or at least minimum delay".

 

4. INPUT DATA

The tables below gives the whole information about the input data that are used in the model.

Table 4.1. Setup times for Lemanic

INPUT DATA

DISTRIBUTION

CHARACTERISTIC

From HLB to HLB

Triangular(2,4,5) hours

Experimental

From HLB to DC

Triangular(3,4,5) hours

Experimental

From DC to HLB

Triangular(3,4,5) hours

Experimental

From DC to DC

Triangular(2,4,6) hours

Experimental

Table 4.2. Setup times for ATN

INPUT DATA

DISTRIBUTION

CHARACTERISTIC

From HLB to HLB

Triangular(1,3,4) hours

Experimental

From HLB to DC

Triangular(2,4,5) hours

Experimental

From DC to HLB

Triangular(2,4,5) hours

Experimental

From DC to DC

Triangular(1,3,5) hours

Experimental

Table 4.3. Downtimes for Lemanic

INPUT DATA

DISTRIBUTION

CHARACTERISTIC

Downtimes Caused by the Machine

Triangular(3,5,9) min.

Observational

Downtimes Caused by the Job

Triangular(1,2,4) min.

Observational

Table 4.4. Downtimes for ATN

INPUT DATA

DISTRIBUTION

CHARACTERISTIC

Downtimes Caused by the Machine

Triangular(3,5,9) min.

Observational

Downtimes Caused by the Job

Triangular(1,2,4) min.

Observational

Table 4.5. Capacities of the Machines

MACHINE

CAPACITY

CHARACTERISTIC

Lemanic

62.500 pieces/hour

Theoretical

ATN

100.000 pieces/hour

Theoretical

The input data about the setup times are experimental. Because the plant has not enough data to analyze. There are eight different type of setups. If we accept that a setup occurs one times in four days, and also if we accept to make analyzes minimum with thirty data, then the number of the days we need to inspect become 8 x 4 x 30 = 960. And the plant has not records related to three years ago. The triangular distribution is used to represents the distributions. By this way the random setup times stays in the limits defined by the engineers. And the probability of having meaningless setup times is reduced.

The input data for the downtimes are observational. In this data ARENA input data analyzer is used to analyze the data. Also the downtimes are represented by the triangular distribution to prevent the meaningless downtimes. The downtimes for each downtime type have accepted to be the same. The details of these data are in Table 4.6 and Table 4.7.

The capacity of the machines are theoretical values.

 

Table4.6. Distribution Function for the Downtimes Caused by the Machine
5 4 5 5 5
4 3 7 4 3
5 4 6 5 5
9 5 4 8 4
3 4 4 4 3
5 5 6 5 3
4 5 5 4 5
5 7 3 5 6
5 7 6 5 6
5 3 3 7 5

 

Distribution Summary
 
Distribution: Triangular
Expression: TRIA(2.5, 5, 9.5)
Square Error: 0.058509
 
Chi Square Test
 
Number of intervals = 5
Degrees of freedom = 3
Test Statistic = 16.8
Corresponding p-value < 0.005
 
Data Summary
 
Number of Data Points = 50
Min Data Value =3
Max Data Value =9
Sample Mean = 4,86
Sample Std Dev =1,34
 
Histogram Summary
Histogram Range = 2,5 to 9,5
Number of Intervals=7

Grafik Nesnesi Chart 1

Int no No of x Probabilty Density Cumulative Distr
  Data Pnts   Data Function Data Function
0 8 3 16 0,0571 0,16 0,0571
1 11 4 22 0,171 0,38 0,229
2 20 5 4 0,263 0,78 0,492
3 5 6 1 0,222 0,88 0,714
4 4 7 0,08 0,159 0,96 0,873
5 1 8 0,02 0,0952 0,98 0,968
6 1 9 0,02 0,0317 1 1

 

 

Table4.7. Distribution Function for the Downtimes Caused by the Job
3 2 1 3 1
2 1 2 3 3
2 2 2 2 2
2 2 1 2 3
2 2 2 1 2
2 2 2 2 3
3 2 1 2 2
2 1 2 1 2
2 2 2 3 1
1 2 2 3 1

 

Distribution Summary
 
Distribution: Triangular
Expression: TRIA(0.5, 2, 3.5)
Square Error: 0.002963
 
Chi Square Test
 
Number of intervals = 3
Degrees of freedom = 1
Test Statistic = 0.4
Corresponding p-value < 0.539
 
Data Summary
 
Number of Data Points = 50
Min Data Value =1
Max Data Value =3
Sample Mean = 2
Sample Std Dev =0.6
 
Histogram Summary
Histogram Range = 0,5 to 3,5
Number of Intervals=3

Grafik Nesnesi Chart 1

Int no No of x Probabilty Density Cumulative Distr
  Data Pnts   Data Function Data Function
0 8 3 16 0,0571 0,16 0,0571
1 11 4 22 0,171 0,38 0,229
2 20 5 4 0,263 0,78 0,492

 

5. DEVELOPMENT OF THE MODEL AND THE SOFTWARE

The model is developed according to definitions given for the system. And the software is developed based on this model.

 

6. VERIFICATION AND THE VALIDATION

6.1. Verification of the Model

In order to verify the model, some techniques were used. These are;

 

Breakpoints are placed in some certain points of the software to stop the simulation and to examine some certain variables.

 

All variables are examined after the simulation by the watch property of Visual Basic 5.0

 

A certain part of the simulation is made by hand using the same random numbers that the software uses to see if the software runs as intended.

As a result, there is not any interruption or unknown situation which prevents us from running the model.

6.2. Validation of the Model

An idealistic goal in validation is to ensure that the simulation model is good enough so that it can be used to make decisions about the system. This can be done comparing the real system and the output data. In this I had no chance to compare the outputs with the real system. The model represent for approximately six months. And also completion of an order changes from one day to ten days. And if we want to have an idea about an order, we must observe a certain times. In such a dynamic system it is hard to this at least takes a lot of time. So we can only compare the outputs with the experiences of the people familiar with the system. And this process shows us that the simulation model is good enough to represent the system.

 

7. EXPERIMENTAL DESIGN

The simulation is run after verifying and validating the model. As indicated before the system is a non-terminating one. And the simulation stops after all the orders are completed.

The simulation is run for eleven times. The delays for each order is calculated and the expected delay time for an order is the average of these eleven delays.

Current Strategy

If we run the software in these conditions, we get the following results.

Table7.1. Delayed orders in current strategy

OrderID

Material

Order Type

InDate

ProDuteDate

Delay (day)

Machine

No. Delays

1

HLB-MLB

Actual

25.05.2000

29.06.2000

7,45

A

11

4

HLB-MLX

Actual

15.05.2000

29.06.2000

1,64

A

11

6

HLB-LMG

Actual

25.05.2000

25.06.2000

2,73

L

7

20

HLB-MLB

Forecast

15.05.2000

30.07.2000

9,45

A

11

40

HLB-MLB

Forecast

15.05.2000

30.08.2000

4,73

A

10

41

HLB-MLX

Forecast

15.05.2000

30.08.2000

17,18

A

11

51

HLB-MLB

Forecast

15.05.2000

30.09.2000

11,91

A

11

52

HLB-MLX

Forecast

15.05.2000

30.09.2000

5,00

A

8

62

HLB-MLD

Forecast

15.05.2000

30.10.2000

1,36

A

6

63

HLB-MLX

Forecast

15.05.2000

30.10.2000

10,64

A

11

75

HLB-MLB

Forecast

15.05.2000

30.11.2000

12,09

A

11

76

HLB-MLX

Forecast

15.05.2000

30.11.2000

22,45

A

11

81

DC-MLG

Forecast

15.05.2000

30.11.2000

3,64

A

9

86

HLB-MLB

Forecast

15.05.2000

30.12.2000

4,91

A

11

87

HLB-MLX

Forecast

15.05.2000

30.12.2000

11,82

A

11

In the output, OrderID represents for the order number of the order, Material represents for the name of the product, Order Type represents for the type of the order, InDate represents for the arriving date of an order to the plant, ProDueDate represents for the proposed due date, Lateness represents for the excepted delay for an order, Machine represents for the machine that the order has the biggest probability to be processed in, No. Delays represents for the number of delays for an order in 11 replications.

We see that there are 15 delays in 85 orders. The total of these delays is 127 days. The total delays for the months.

Table7.2. Details of delays in current strategy
 

06

07

08

09

10

11

12

# Delays

3

1

2

2

2

3

2

Total Time

11.82

9.45

21.91

16.91

12.00

38.18

16.73

Total times represents for days

Strategy I

In current strategy the first delay in the machine Lemanic is in the order with the OrderID 6. The due date for this order is 25.06.2000 and it has approximately two days delay. Now let's see what happens if we make overtime in two Saturdays before 25.06.2000.

Table7.3. Delayed orders in Strategy I

OrderID

Material

Order Type

InDate

ProDuteDate

Delay (day)

Machine

No. Delays

1

HLB-MLB

Actual

25.05.2000

29.06.2000

7,45

A

11

4

HLB-MLX

Actual

15.05.2000

29.06.2000

1,64

A

11

20

HLB-MLB

Forecast

15.05.2000

30.07.2000

9,45

A

11

40

HLB-MLB

Forecast

15.05.2000

30.08.2000

4,73

A

10

41

HLB-MLX

Forecast

15.05.2000

30.08.2000

17,18

A

11

51

HLB-MLB

Forecast

15.05.2000

30.09.2000

11,64

A

11

52

HLB-MLX

Forecast

15.05.2000

30.09.2000

4,82

A

7

62

HLB-MLD

Forecast

15.05.2000

30.10.2000

1,00

A

6

63

HLB-MLX

Forecast

15.05.2000

30.10.2000

9,45

A

11

75

HLB-MLB

Forecast

15.05.2000

30.11.2000

10,82

A

11

76

HLB-MLX

Forecast

15.05.2000

30.11.2000

22,00

A

11

81

DC-MLG

Forecast

15.05.2000

30.11.2000

2,45

A

9

86

HLB-MLB

Forecast

15.05.2000

30.12.2000

3,64

A

10

87

HLB-MLX

Forecast

15.05.2000

30.12.2000

9,73

A

11

We see that with two days of overtime in the machine Lemanic, we eliminate the delay in the order with the OrderID 6. By this way we have 14 delays in 85 orders. And the total delays degreases from 127 days to 116 days.

Table7.4. Details of delays in Strategy I
 

06

07

08

09

10

11

12

# Delays

2

1

2

2

2

3

2

Total Time

9.09

9.45

21.91

16.46

10.45

35.27

13.37

Total times represents for days

Strategy II

Let's think that the engineers of the plant wants to change the working policy of the machine Lemanic. They want the machine to work 6 days a week. Before implying this let's try to see what happens to the delays.

Table7.5. Delayed orders in Strategy II

OrderID

Material

Order Type

InDate

ProDuteDate

Delay (day)

Machine

No. Delays

1

HLB-MLB

Actual

25.05.2000

29.06.2000

7,45

A

11

4

HLB-MLX

Actual

15.05.2000

29.06.2000

1,64

A

11

20

HLB-MLB

Forecast

15.05.2000

30.07.2000

9,45

A

11

40

HLB-MLB

Forecast

15.05.2000

30.08.2000

4,73

A

10

41

HLB-MLX

Forecast

15.05.2000

30.08.2000

17,18

A

11

51

HLB-MLB

Forecast

15.05.2000

30.09.2000

11,64

A

11

63

HLB-MLX

Forecast

15.05.2000

30.10.2000

9,45

A

11

75

HLB-MLB

Forecast

15.05.2000

30.11.2000

10,82

A

11

76

HLB-MLX

Forecast

15.05.2000

30.11.2000

22,00

A

11

87

HLB-MLX

Forecast

15.05.2000

30.12.2000

9,73

A

11

In the second strategy we degreased total delays from 14 orders to 10 orders by taking the first strategy as the reference point. And the total delays degrease from 116 days to 104.09 days

Table7.6. Details of delays in Strategy II
 

06

07

08

09

10

11

12

# Delays

2

1

2

2

2

3

2

Total Time

9.09

9.45

21.91

16.46

10.45

35.27

13.37

Total times represents for days

Strategy III

In this strategy, it is assumed that some improvements have been developed and the downtimes are degreased by one minute. So there must be some changes in the system.

Table7.7. Delayed orders in Strategy III

OrderID

Material

Order Type

InDate

ProDuteDate

Delay (day)

Machine

No. Delays

1

HLB-MLB

Actual

25.05.2000

29.06.2000

7,45

A

11

20

HLB-MLB

Forecast

15.05.2000

30.07.2000

9,45

A

11

41

HLB-MLX

Forecast

15.05.2000

30.08.2000

17,18

A

11

51

HLB-MLB

Forecast

15.05.2000

30.09.2000

11,64

A

11

76

HLB-MLX

Forecast

15.05.2000

30.11.2000

22,00

A

11

Table7.8. Details of delays in Strategy III
 

06

07

08

09

10

11

12

# Delays

1

1

1

1

0

1

0

Total Time

7.45

9.45

17.18

11.64

0

22,00

0

Total times represents for days

We see that the number of the delayed orders is only 5. And the total delays degreases from 104.9 days to 67.72 days. and there is no delay in December.

Strategy IV

In the previous situation we saw that there is no delay in December. As the last strategy let's make two days-off on the New Year Event, 31.12.2000 and 01.01.2001.

Table7.9. Delayed orders in Strategy IV

OrderID

Material

Order Type

InDate

ProDuteDate

Delay (day)

Machine

No. Delays

1

HLB-MLB

Actual

25.05.2000

29.06.2000

7,45

A

11

20

HLB-MLB

Forecast

15.05.2000

30.07.2000

9,45

A

11

41

HLB-MLX

Forecast

15.05.2000

30.08.2000

17,18

A

11

51

HLB-MLB

Forecast

15.05.2000

30.09.2000

11,64

A

11

76

HLB-MLX

Forecast

15.05.2000

30.11.2000

22,00

A

11

87

HLB-MLX

Forecast

15.05.2000

30.12.2000

1,36

A

8

In this strategy having two days-off at the end of the December made the order with the OrderID 87 delay for 1.36 days. also total delays increased from 67.72 days to 69.08 days.

Table7.10. Details of delays in Strategy IV
 

06

07

08

09

10

11

12

# Delays

1

1

1

1

0

1

1

Total Time

7.45

9.45

17.18

11.64

0

22,00

1.36

Total times represents for days

 

8. ANALYSIS OF THE RESULTS

As a result of the experimental design, we have seen that

 

Any improvement in the model of the system is directly causes improvements in the output of the system.

 

Also any unwilling situation causes the unwilling outputs.

 

Total Number of Delays

Total Delay (Days)

Current Strategy

15

127

Strategy I

14

116

Strategy II

10

104.09

Strategy III

5

67.72

Strategy IV

6

69.08

 

9. CONCLUSION

In this study, the current performance of a package manufacturing plant on predicting future completion dates of the orders was evaluated. At first, some observations were made for the input data. Then some assumptions were made to establish a model. Then a software which represents for the model is developed by using Visual Basic 5.0. At last some certain number of scenarios were generated to have better predicts on the completion dates of the orders.