Case Study: Modelling Requests to a Courier Service

Submitted: 9 Aug 2009

Operations Research Topics: SimulationModelling

Application Areas: Logistics

Contents

• Problem Description
• Problem Formulation
• Computational Model
• Results
• Conclusions
• Extra for Experts

Problem Description

A courier company offers two services: an Inner City delivery service that delivers packages within the Inner City area in under an hour; a Metropolitan delivery service that delivers packages within the Metropolitan area in less than 4 hours.

An Inner City courier leaves the distribution centre if EITHER there are 10 deliveries to make OR it has been 15 minutes since the "oldest" delivery request arrived, i.e., the first request that arrived after the last delivery run departed. A Metropolitan courier leaves the distribution centre if EITHER there are 30 deliveries to make OR it has been 30 mins since the oldest delivery arrived. The courier company works for 8 hours a day and starts each day with no deliveries to make.

The courier company has collected data on the time between requests for both Inner City and Metropolitan deliveries as well as the time to make Inner City and Metropolitan deliveries. They want to know how many deliveries their Inner City and Metropolitan couriers make each day and also how long they are on the road during a day.

Return to top

Problem Formulation

To simplify the modelling we will abstract 4 sections of the problem:

1. Requests for Inner City deliveries;
2. Requests for Metropolitan deliveries;
3. Delivery runs for Inner City deliveries;
4. Delivery runs for Metropolitan deliveries.

We start by assuming we can model these accurately using random variables, so we can concentrate on the remaining logic in the system. Figure 1 shows a flow diagram for the Inner City deliveries (note that a flowchart for the Metropolitan deliveries would be similar).

Figure 1 Flow Diagram for Inner City Deliveries

The way to implement this flow digram will differ depending on the simulation modelling tools used.

Return to top

Computational Model

To model the flow digram from Figure 1 we first abstract the delivery requests and request runs as Arena submodels. The submodel for requests only generate requests, so a single submodel with only an exit point is needed. The submodel for a delivery run has the load of deliveries as input and outputs the load of deliveries after the delivery run finishes, so it has a single entry and exit point. The following flash tutorial shows how to add the appropriate submodels in Arena:

Adding submodels for Courier Model

Next, we want queues that store delivery entities until a delivery run occurs. The next flash tutorial shows how to add a Hold module and a Variable to implement this queue for Inner City deliveries:

Adding waiting queue for Courier Model

Next, we want to create logical entities to take care of triggering delivery runs if the oldest delivery request has waited long enough. Each time a delivery request comes in and there are no other deliveries waiting we note down its arrival time and create a timing entity using a Delay module. When the timing entity leaves the system a calendar event will be generated. We will see how this calendar event is used later. The following flash tutorial shows how to create the timing entity for the Inner City deliveries:

Adding timing entity to Courier Model

Next, we create logical entities to trigger a delivery if:

1. The amount of time since the oldest delivery arrived has reached the maximum time;
2. The number of deliveries waiting has reached the maximum load.

The arrival of a new delivery creates a calendar event, as does the disposal of the timing entity created just before. Hold modules will scan the simulation state each calendar event, so we can use one of these to trigger a delivery. We will use a second Hold module to delay the logical entity until the deliveries have been loaded, it will then wait until the next trigger event:

Adding trigger entity to Courier Model

Now that we can trigger the loading of a delivery run, we want to combine all the deliveries into a single load, finish loading and make a delivery run. Once the run is finished we want to separate the deliveries and let them leave the system:

Adding deliveries to Courier Model

Now the logic of the model is complete except for the arrivals and delivery runs. You complete model should look like that in Figure 2.

Figure 2 Courier Model with complete logic

To start off with we will try some simple distributions. Use exponential interarrival times with mean 10 minutes and 20 minutes for Inner City and Metropolitan delivery requests (make sure to use EXPO(10) and EXPO(20) for the first arrival times too). We will use triangular distributions with min, mode and max of 10, 15, 20 and 25, 45, 90 for Inner CIty and Metropolitan delivery runs respectively. Add the appropriate Create and Process modules to your submodels. Connect them to the appropriate entry and exit points. Finally, make sure you have an infinite number of couriers by editing the capacity of your Resources.

Now run your model for 50 replications. Each replication should run for 8 hours (i.e., 1 day of the courier operation) and the Base Time Units are minutes.

Debugging

You should notice that your model appears to "stall". If you look carefully you will see the logic entity that triggers Inner City delivery runs in an infinite loop. This happens because our hold condition is not quite correct. We rely on a request arriving and resetting the oldest delivery time. However, this does not happen before the truck is loaded, so the initial trigger hold does not work. We need to wait for a delivery after we load the truck. By adding an extra condition to the timing trigger, we can fix the problem. Figure 3 shows this extra condition, that the delivery queue must have at least one delivery AND that the oldest delivery has been there for too long for a delivery run to take place.

Figure 3 Extra condition for timing trigger

After debugging and re-running you model you should get some output such as 0.5782 Inner City couriers being used on average and 18.84 Inner City delivery runs on average. However, we are just using some very crude estimates of input data to verify our model.

You can also use animation to check your model, such as animating queues and times to make sure the maximum load and maximum time restrictions are enforced. You can visualise the utilisation of the couriers and the number of each type of courier on the road at any one time:

Adding animation to Courier Model

Finding Input Distributions

As discussed previously, the courier company has recorded data on their delivery requests and delivery runs. This data is given courier.xls.

We can use Arena's built-in Input Analyzer to determine distributions that fit the data well. First, we need to break the data up into separate text files as shown in Figure 4.

Figure 4 Splitting data into text files

Then, we can use the Input Analyzer:

Analysing Inner City delivery requests

The Input Analyzer uses the Chi Square and Kolmogorov-Smirnov goodness-of-fit tests to determine which distributions fit best.

Once you have determined the best distributions, you can cut-and-paste their expressions into the appropriate submodels and run your simulation model again. Some results are shown in Figure 5.

Figure 5 Results after input analysis

Using the Data

IMPORTANT You should save your model file under a new name before adding the empirical distributions as shown below. In the Results section we will compare the 2 model files.

Instead of using the Input Analyzer to estimate distributions, we can use the empirical distribution. The empirical distribution uses the histogram of the data to create a cumulative distribution function which it then uses to generate either discrete or continuous observations. In this example we will use the continuous distribution to generate interarrival times and processing times, i.e., the time taken for a courier run.

Determining the Empirical Distribution

Once you have changed the generation of delivery requests and the time taken to do courier runs to use empirical distributions, you can run your model again. However, you may get ant error complaining about using a value of 0.00 for an interarrival time. The first entry of your empirical distrubutions is (0.00, 0.00, ...), i.e., there is a very small (0.00 to 3 significant figures) chance of an observation of 0.00. If this happens an infinite number of times for an interarrival time (very small probability, but theoretically possible), then there may be an infinite loop, so Arena does not allow this. Simply remove the first 2 0.00 entries (thus removin the possibility of a 0.00 interarrival time, a reasonable assumption) and your Arena model will run.

Return to top

Results

Now we have finished building simulation models with different input distributions, we will compare our models. We can compare two simulations by creating data files giving output for each replication and comparing them in Arena's Output Analyzer.

First, add a Statistic to both models that records the average utilization of the Inner City Courier and the Metropolitan Courier.

Adding Output Statistics to Courier Model

Repeat this for your simulation model that uses the fitted distributions, but make sure to give your output files different names. Next, we can use the Output Analyzer to compare the different models.

Comparing Courier Models

Figure 6 shows the confidence intervals generated by Output Analyzer. They measure the difference of the mean values, i.e., average number of busy couriers, for the inner city couriers and the metropolitan couriers. The difference is the mean from the fitted distribution model (input) minus the mean from the empirical distribution model (empirical). Notice that both confidence intervals span 0, so there is no evidence of any difference between the means. We can reduce the size of the confidence intervals by reducing the variance, i.e., running more replications.

Figure 6 Results after input analysis

Return to top

Conclusions

The simulation model of the courier company provides different measurements of several aspects of the courier service. In this case study we looked mainly at the average number of couriers needed for both inner city and metropolitan deliveries.

We considered this statistic when using a couple of different models, one that estimated distributions for the data and one that use the empirical distribution of the data, i.e., it modelled the data explicitly.

The simulation results showed that there was no evidence to reject the hypothesis that both distributions gave the same mean, i.e., average number of couriers busy, for both the inner city and metropolitan couriers. This means that we could use either approach and our results would be statistically equivalent.

Return to top

Extra for Experts

Arena enables you to be more selective about how random numbers are used in your simulations. This may allow you to get more accuracy in your estimates with less replications. It can also allow you to improve accuracy when comparing simulations.

First, you need to add a SEEDS element to your model. Then, you add the seed to your random number expressions. The following flash movie shows how to do this and also uses the SEEDS element so that common random numbers are used across replications. Be sure to save a copy of your model before making changes.

Using a SEEDS element

Figure 7 shows the results for courier usage when using the empirical distribution and random numbers as usual, common random numbers and antithetic random numbers.

Figure 7 Courier Usage (Empirical Distribution) with different random number utilisation

• Using random numbers as usual
  

• Using common random numbers
  

• Using antithetic random numbers

In this case the common random numbers improved the estimate, but the antithetic random numbers did not.

Using the same random numbers in the same way in two models reduces the variance when comparing models. Comparing the courier model with fitted distributions to the model with the empirical distribution when both models are using random numbers in the same way, even without Common or Antithetic, gives a comparison with less variance. Figure 8 shows the Output Analyzer results for the previous models (without the SEEDS element - the first and third confidence intervals) and the new models (with the SEEDS element without Common or Antithetic turned on - the second and last intervals).

Figure 8 Output Analyzer Results

Return to top