Decreasing the loading time of a container ship at a terminal by swapping load orders.

(1)

Decreasing the loading time of a container ship at a

terminal by swapping load orders.

A. Tydeman

Delft, July 3, 2008

Master thesis Operations Research

(2)

Decreasing the loading time of a container ship at a terminal

by swapping load orders.

Anne-Jette Tydeman

Abstract

Recent growth in container transportation requires an efficient (un)loading process for ships at container terminals. This thesis deals with increasing the efficiency of the loading process by swapping containers in the loading sequence. This can prevent the schedule from delay, when a single container is delayed. Swaps will be performed at two moments during the loading process: while retrieving the container from the stack, and while transporting it to the ship by an Automated Guided Vehicle. Furthermore two types of swaps are performed. One swaps positions: a different container is loaded on the delayed containers’ position. The other swaps the sequence: a different container is handled first. Since deciding on the best possible swap is quite involved, the problem is written into a mathematical model and compared with a set of well known scheduling problems. In order to find proper solutions a self made heuristic, Simulated Annealing and Tabu Search are used.

Finally the best heuristic is incorporated into the TIMESquare simulation model made by TBA, a logistics and simulation consultancy company in Delft. TIMESquare simulates the entire (un)loading process at a terminal, and is used for various ports in the world. A couple of test runs are performed to evaluate the working of the swap algorithm and the results are summarized.

(3)

1 Introduction

Since the introduction of the container around 1960 maritime container transport has considerably increased. For example, global container turnover tripled between 1990 and 2003, see Figure 1. And even more increase is expected for the next decade by Baird (2006). According to G¨unter and Kim (2006), over 60% of the world’s deep-sea transportation consists of containers nowadays, and still the container ships grow. Recently the first 10.000 TEU (Twenty feet Equivalent Unit) container ship was produced.

Figure 1: Development of global container turnover 1985-2004 (in million TEU), from G¨unter and Kim (2006).

A container ship spends approximately 60% of its time lying in a port to be (un)loaded, see Kang and Kim (2002). And because in-port time is expensive (staff and energy still have to be paid), it needs to be minimized. Anticipating on changes during the loading process (delays) and thereby preventing the process from stagnation is a possible solution. In order to achieve this, a real time adaptation of the loading sequence is needed. In other words: a delayed container has to be replaced by another container such that no time is wasted. With our work at TBA we hope to contribute to this optimization study.

During the last decade, container terminal logistics and planning have received more attention in the academic literature. This emphasizes the importance of optimizing logistic operations at container terminals. An introduction to the working of container terminals is given in Vis and de Koster (2003), while descriptions of Operations Research in this field are treated in Steenken, Voß, and Stahlbock (2004), Stahlbock and Voß (2008) and Meersmans and Dekker (2001). The following sections contain an introduction to TBA, the company where the internship was done, an introduction to the working of container terminals, and a short summary on the structure of this thesis. A glossary is included at the end of the thesis.

1.1 TBA

(6)

time). Emulation comprises testing of software designed to work for a real terminal. The part of the terminal communicating with this software is then emulated by a virtual terminal. A set of input values is passed into the virtual terminal (destination per vehicle), which communicates with the existing software. The output of the existing software is then verified (driving directions). This way the existing software can be analyzed without using the real terminal.

An example of TBA emulation software is CONTROLS (CONtainer TeRminal Optimised Lo-gistics Simulation). Here the terminal itself is simulated, but the real control software (which decides on how vehicles will move) is used. This emulation model verifies if the control software works properly, so vehicles won’t collide. An example of simulation is the TIMESquare simula-tion model. TIMESquare stands for Terminal In-Depth Model for Evaluasimula-tion Studies. With this simulation model an investigation is possible on which terminal layout works best for a specific port or if planned extensions really improve performance. During the internship we will work with the TIMESquare model of TBA, and we will try to improve the performance of the terminal by implementing a swap possibility during the loading process. Detailed information on simulation and TIMESquare can be found in section 6.

Figure 2: A terminal seen from the ground, photo from a TBA brochure.

1.2 Container terminals

Container terminals are complicated networks of exchange points. When unloaded from the ship containers are stored in one of the stacks. From the stack they proceed to trains or trucks which transport them into the country, or they are stored and later loaded onto another ship.

A container terminal consists of some basic building blocks. There are several types of terminal layouts, but only the one used for our research is treated here. For information about other terminal layouts and when to choose which layout see Steenken et al. (2004). The terminal at TBA can be divided into three sections. The waterside, the landside and the transportation area. An overview of the terminal is given in Figure 3. The container ship is positioned at the waterside where a quay crane transports containers between ship and quay. The stack (depot to store containers) is situated at the landside where stacking cranes shift containers. For example, in Figure 3 a particular type of stacking crane, a Rail Mounted Gantry (RMG) is depicted. The area between the waterside and the landside is the transportation area. Here the containers are transported between the quay and the stack by transportation vehicles. One of the newest developments in the container terminal world is the Automated Guided Vehicle (AGV). Like its name says, this vehicle is driven by a computer and not by a human. The only two terminals already equipped with AGVs are ECT in Rotterdam and CTA in Hamburg. TBA expects that more terminals will change to AGVs, and more generally, to fully automated (or robotized) terminals. Our TIMESquare instance is equipped with AGVs, and is used for testing how a terminal performs with these new developments.

(7)

Figure 3: Overview of a terminal layout, from Steenken et al. (2004).

be cooled during the trip and therefore need a place with electricity. Container length (and height) does vary too, in TIMESquare containers of 20 and 40 feet long are used. A 40 feet container can not be placed on two 20 feet containers. For more container types see Steenken, Winter, and Zimmermann (2001). Thirdly the weight per container varies. There are several weight classes defined where each container fits in. To stabilize the ship it is important to place heavy containers as low as possible and to equalize the weight over the width of the ship. Finally rehandling has to be incorporated, which is an undesired container move, to free an underlying container, or to re-balance the ship due to recent load or unload jobs. Both for designing a loadplan and for swapping these restrictions have to be met. This topic will be treated in more detail in section 2.

1.3 Structure of the thesis

The next section (2) considers the problem of delayed containers. It starts with an explanation on how the loading process works exactly, followed by a detailed problem description. Subsequently a possible solution for this problem: swapping, is treated and explained with some examples. Following the situation overview we will continue with the research outline in section 3. Here the research objectives are posed, and a description of all investigated swap solutions is given. This section ends with a discussion on the complexity of finding a good swap.

As in one of these cases finding an optimal swap is rather complicated, this problem is written as a mathematical model. An attempt is made to fit it into a well known scheduling problem, which can be found in section 4. Some types of scheduling problems are described and the similarities and differences with our problem are appointed. We will then describe our mathematical model and give a numerical example.

In section 5 a review of the computational complexities of our problem is given, including an overview of the possibilities for solving it either exactly or by heuristics. The best algorithm or heuristic algorithm will be implemented into the TBA simulation model.

(8)

2 Situation overview

In this section a description is given of the situation as it is in the TBA simulation model and in many ports in the world. First, the details on loading a container ship are explained, followed by an explanation on the problem of delayed containers and how these delays are caused. Thirdly some swapping possibilities are treated as a solution method to our problem.

2.1 The loading process of a container ship

A container ship contains thousands of container slots. Each slot is uniquely determined by three characteristics: its bay, row and tier number. These three numbers indicate the place of the slot along the length, width and height of the ship, respectively. A bay consists of all containers with the same place along the length of the ship, see the left part of Figure 4.

Figure 4: Overview of a ship layout, from Kang and Kim (2002).

A row and tier can be explained similarly. Notice that a container ship is divided into a section below deck (hold area) and above deck (deck area). These sections are divided by a hatch cover; see the right part of Figure 4. Before the ship arrives at the terminal a loadplan is made: a list of containers to be loaded onto the ship and their positions (bay, row, tier). According to the loadplan a loading sequence is created, including an assignment of stacking cranes and vehicles.

Figure 5: Picture of an RMG, a stacking crane in TIMESquare.

(9)

part of the stack. So if a container is stored in one particular part of the stack, it can only be reached by two stacking cranes, namely the two corresponding to that part. The corresponding waterside stacking crane retrieves the container and places it on an AGV. The AGV then drives to the buffer, a parking place in the middle of the transportation area, and waits until it can approach the quay crane. The buffer is created to keep the quay quiet. Only one AGV at the time is allowed to approach the quay crane, the others have to wait at the buffer. When the quay crane is ready for the next container, the corresponding AGV can proceed and drives toward the quay crane. Here the crane picks up the container and loads it onto the ship, while the AGV drives back to the stack to pick up a new container to load.

2.2 Problem description

During the loading process several things can go wrong. Containers coming from the country can be delayed or the stacking crane can overrun its schedule. Another failure appears when an AGV is blocked by other vehicles crossing its way on the transportation area. All these situations cause delay in the delivery of containers, and as the loading sequence has to be followed, the entire process is delayed.

2.3 A possible solution: swapping

Notice that the above described problem can not be solved in advance so an online solution method is needed. In order to reduce the delay of the loading process caused by the delay of a single container we are going to include swapping possibilities into TIMESquare. Let’s give an example. Suppose that containers 1, 2, 3 and 4 have to be loaded onto the ship in the way depicted in Figure 6.

Figure 6: Possible arrangement of containers.

So container 1 is loaded first, then container 2, 3 and finally 4. Suppose container 1 to be delayed. Then there are two possibilities:

1. Try to load another container first and later load container 1 (sequence swap)

2. Try to find a container which can be loaded on the place where container 1 needs to be loaded, and load container 1 on the place where that container was originally planned (position swap)

2.3.1 Sequence swap

(10)

2.3.2 Position swap

Another possibility is to find a container with the same characteristics as container 1, such as sim-ilar length, destination and weight class. A list of these characteristics can be found in Appendix B. Suppose container 4 has the same characteristics as container 1. Instead of loading container 1 at the bottom-left slot container 4 can be loaded at this place. Then container 2 and 3 are placed at the slot they were planned and finally container 1 is placed at the upper-right slot. See Figure 7. We call this a position swap. By performing this swap the loading process is not delayed because the quay crane can now handle container 4 and later handle container 1.

Figure 7: New arrangement of containers after position swap.

2.3.3 When to choose which swap?

The choice which swap to choose depends on the (dis)advantages of both swap types, which will be indicated here.

• A quay crane driver receives a plan to load a container in a particular slot. When performing a sequence swap this plan will be changed and another container at a different slot has to be loaded. Therefore the crane needs to be relocated which will take extra time. This is a disadvantage of the sequence swap.

• A disadvantage of the position swap is that the loadplan will change, i.e. the overview of container locations needs to be adjusted. Any changes in the loadplan have to be passed on to the subsequent ports.

• One thing that is crucial when deciding for a sequence swap is that loading containers can become more difficult due to the swap. For example, see Figure 8. In the original situation container 1 was loaded first. This is not very difficult; the crane driver can put the container against the edge of the ship. Then container 2 is put easily against container 1, and only loading container 3 takes some time, as it has to fit exactly between the right edge and container 2. Now imagine that container 1 and 2 are sequence swapped, then container 2 has to be loaded first, which is difficult since it can not be put against container 1. Subsequently both loading container 1 and 3 will be difficult since they have to fit exactly between the edge and container 2. Therefore a sequence swap can deteriorate the loading process, when containers can not be put right against each other anymore. This causes delay too. See for the code to determine the delay of a sequence swap appendix C. We have to make one additional note on this topic, namely that the above mentioned deterioration only holds for containers on deck. Since the hold is already divided in individual boxes by piles, no extra delay is caused by changing the loading sequence here.

(11)

3 Research outline

As the situation so far and the opportunities to improve it are described, the research can be set up. First the research objectives are mentioned. After that a list of possible solutions and their complexity is given. In the next chapters all aspects of the problem and the solution methods are discussed in more detail.

3.1 Research objectives

The previous section stated which problems arise during the loading process of a container ship, and how swapping containers can be useful to solve these problems. The question remains how to use the swapping possibilities during the loading process, and how to implement these into TIMESquare. For these purposes a list of research objectives is set up:

• Design two ways of swapping opportunities for load containers: one for vehicles and one for stacks

• Find an efficient algorithm to solve the stack swap problem in reasonable time • Implement both swap opportunities into TIMESquare

• Test the performance of the swaps under different circumstances in TIMESquare These objectives will be treated one-by-one in the rest of the thesis.

3.2 Implementing swaps

There are two moments during the loading process where we are going to make the swap of containers possible: when the containers are still stored in the stack (stack swap), and when the AGVs are waiting with a container at the buffer to approach the quay crane (vehicle swap). Both kind of situations are described below.

3.2.1 Vehicle swap

First the vehicle swap is discussed. Suppose containers 1, 2, 3, 4, 5, 6, 7 and 8 need to be loaded (in that sequence). See Figure 9. Assume container 1 is loaded already, and the quay crane re-quests container 2, so it seeks for the AGV carrying container 2. Suppose this AGV is delayed and has not yet arrived at the buffer, so it is eligible for swapping. TBA prefers to search for a sequence swap first since this will not change the loadplan. If there is a sequence swap possible which causes no or very little delay (how much delay is accepted has to be specified later) this swap is executed. If not, a position swap is searched for (and possibly executed). Now look which AGVs have arrived at the buffer and therefore can be swapped with container 2. Suppose the AGVs with containers 3, 4, 6 and 7 have arrived at the buffer.

Figure 9: Possible arrangement of containers.

(12)

As there are sequence swaps possible without any delay, analyzing position swaps is not needed. However, if it was, all containers with the same characteristics as container 2 would be listed, and if there were any, the one closest in sequence to container 2 would be selected. Suppose that from the containers at the buffer containers 3 and 7 have the same characteristics as 2, then container 2 and 3 would be swapped.

In addition to the case of a quay crane requesting a container, a situation in which a vehicle asks to approach the crane is possible too. Once a vehicle (call it X) approaches the buffer it investigates the possibility to proceed to the crane. If the crane is waiting for the container car-ried by X, it can drive through the buffer and immediately approach the crane. If not, a swap could be performed. But: only if the crane is waiting for a container not present at the buffer. The same procedure is started as in the case that the quay crane asks for a swap, but with one difference: in this case only a swap between the container on X and the first one to approach the crane is considered. This is allowed since all other waiting containers are already checked (any container waiting in the buffer was at least checked once: when arriving at the buffer or while waiting at the buffer when the quay crane became idle). If a swap appears to be possible it is performed, otherwise nothing is done. The code to program the vehicle swap (for both situations) into TIMESquare can be found in Appendix D.

A third option to perform a vehicle swap was already programmed in TIMESquare, although it is currently not applied at TBA. This is the vehicle swap when departing from the stack towards the buffers. Call this the depart-swap. Once the container is loaded on the AGV it asks to leave the stack and drive towards the buffer. There is a pre-specified limit of AGVs which can travel between the stack and the quay crane, and if this limit is reached, the AGV is not permitted to go until the next container is cleared at the quay. However, an AGV is allowed to swap with AGVs that have not yet arrived at the buffer, but have departed from the stack. In this case, it could be possible that the other AGV has to drive a long way from the stack to the buffer, and is expected to reach the buffer later than the waiting AGV, if it would depart now. This opportunity to swap is only possible if enough buffers are free to accommodate the extra AGV. In that case, the swap is performed and the AGV is allowed to depart.

3.2.2 Stack swap

Secondly the situation at the stack is analyzed. When looking forward to the upcoming period, for example the next 15 minutes, an upcoming problem can be observed in an early stage and solved before it will occur. That is, if one stacking crane will be very busy in the near future and it can not deliver a container on time (for example because a container was delayed), it could swap this container with a similar container from another stack that is not so busy.

Figure 10: Initial schedule for the stacks.

(13)

Figure 11: Changed schedule for the stacks due to delayed container.

Lets study a small example again, to demonstrate the stack swap. Assume eight containers have to be loaded on the ship as arranged in Figure 9. The containers 1, 2, 3, 4, 5, 6, 7 and 8 have to be transported to the quay crane, in that sequence. Containers 1, 3, 6 and 7 are stored in stack A and containers 2, 4, 5 and 8 in stack B. Assume that 1 minute is needed to retrieve a container from the stack, irrespective of which container you take (this is not realistic but we keep it simple here). Furthermore let the due dates (the time the container has to be delivered to an AGV) be given as follows: (1, 2, 2.5, 3, 4, 5, 6, 6), so container 1 has a due date of 1 and container 8 has a due date of 6. The current schedule is as given in Figure 10.

Figure 12: Recovered schedule due to swap.

Suppose container 1 is delayed and accordingly stack A can not start with this container before time t = 1. The delayed container forces container 3 to be delayed too (see Figure 11). Assuming that containers 1 and 5 are interchangeable, it would be profitable to swap containers 1 and 5, which is allowed since stack A is available when container 5 should be retrieved, and stack B can handle container 1. Swapping containers 1 and 5 improves the schedule, as shown in Figure 12. By doing this swap, container 5 will be handled as if it is container 1 (with due date 1), and container 1 will be handled as if it is container 5 (with due date 4). The new arrangement in the ship is depicted in Figure 13. The code to program the stack swap into TIMESquare can be found in Appendix E. However, it is advised to read chapters 4 and 5 before examining this code.

(14)

3.2.3 Complexity of the problem

The two swapping types which will be implemented in the simulation model: the vehicle swap and the stack swap, differ a lot in complexity.

(15)

4 The stack swap problem

By the stack swap problem the issue of ‘finding a set of containers to swap between stacks’ is meant. In this section the problem is summarized into an objective and a set of restrictions, followed by a literature review on this and related problems. An attempt is made to rewrite the stack swap problem into a well known mathematical (scheduling) model, and the section ends with a formal mathematical representation of the stack swap problem and a numerical example.

4.1 Objective and restrictions

Looking to the current schedule, select the delayed containers in the upcoming 15 minutes, say. We aim to reduce this delay by swapping containers. However, to minimize the changes in the crane drivers schedule, the number of swaps needs to be minimized too. This problem can be written as a bi-criteria problem (where both objectives are minimized), or the objective of minimizing the number of swaps can be switched into a constraint, with a pre-specified limit of swaps. We have chosen to minimize both objectives, since we do not want to restrict the number of swaps to an exact number. In other words: performing ten or eleven swaps does not make a big difference, so we better not choose an exact limit.

These objectives have to be fulfilled while keeping eye on a set of restrictions. First of all: only containers of the same category (so: with the same destination, weight class, type) can be swapped. Secondly, two swapped containers can cause rehandles, since the sequence is changed in which the containers are retrieved from the stack. Thirdly, containers can only be retrieved by one crane, the one corresponding to that part of the stack (cranes can not move to other stacks). The final restriction is that every container in the old schedule should be scheduled in the new schedule: containers can not be added to or removed from the schedule. Summarizing, this comes down to: Objectives:

• Minimize the total delay of containers • Minimize the total number of swaps Restrictions:

• Only swap containers of the same category • Compute rehandles due to swaps

• Container can only be handled by their corresponding crane • No containers can be added to or removed from the schedule

4.2 Available literature on the stack swap problem

The stack swap problem is a very young problem, as only recently people started to think about swapping containers in a stack. For this reason not much has been published about the subject of stack swapping, but lets start with the stack itself. Recently the problem of how to stack containers and how to get them out such that the berthing time of a ship in the port is minimized, has earned more attention.

An overview of recent literature on stacking problems and strategies can be found in Dekker, Voogd, and van Asperen (2006) and Vis (2002). Dekker et al. (2006) call some publications but mention that not much has been published in this field. They concentrate on testing different stacking strategies (where to place a container into the stack). Vis (2002) introduces the problem of stacking and mentions what has been published on stacking strategies, stacking equipment, stack configuration and rehandling.

(16)

containers, stacking policies and the size of the stacking area. Two policies are explored: a random policy (store container at the nearest empty slot) and a policy which only stacks containers on each other if they are from the same category.

Research on simulation of stack operations and stacking strategies is carried out by Saanen and Dekker (2006) and Voogd, Dekker, and Meersmans (1999). These studies are closely related to our situation with simulation, but they only vary the stacking strategies (so the decision where to place a container in the stack), and not the schedule on how to get the containers out of the stack. The question how to get containers optimally out of the stack instead of into, is a more relevant question for us. Kozan and Preston (1999) and Ng and Mak (2005) treat this topic. The stacks have to follow the schedule of the quay crane, which states when every container has to be loaded onto the ship. This schedule indicates when every container has to leave the stack, to reach the quay crane on time. Kozan and Preston (1999) design a schedule on when to retrieve which container such that traveling and rehandling time is minimized. Part of this schedule is the determination which crane will handle every container, as there are more cranes available to handle a container. Ng and Mak (2005) do the same, but with the restriction that every crane is already assigned a set of jobs, and just the sequence of jobs has to be determined.

The drawback of the last two papers is that no variation is allowed in which container to deliver to the quay crane. The schedule is made such that the quay crane asks for one specific container in the sequence. This restriction can be loosened a little bit by not specifying the exact container to retrieve, but only the specifications of the container. For example: the schedule does not state that container 51 has to be delivered at 4:03:52 pm, but only that a container of weight class 2, length 40 feet and destination HBG has to be delivered at 4:03:52 pm. This gives the stacking crane more freedom in choosing a container to retrieve. This is where the categories come in. Due to a list of specifications all containers are assigned a category, such that the containers of the same category can be swapped. This problem is treated by Kim, Kang, and Ryu (2004), Lee, Cao, and Meng (2007) and Kim and Kim (1999). Here a schedule consists of a list with orders, where every order consists of a number of containers from one category that has to be retrieved. For example a list can be as follows: first 20 containers of type A, then 12 containers of type B, 9 containers of type C and 17 containers of type A again. (In our case we don’t have these large numbers of the same groups, but an order of 20 containers of type A can be replaced by 1 container of type A). The stacking cranes can now decide by themselves which containers they take, with the only restriction that the container falls in the right category. Lee et al. (2007) and Kim and Kim (1999) only decide from which part (bay) of the stacks the containers are retrieved and how many containers are retrieved from a bay for every order. Kim et al. (2004) furthermore decide which containers are exactly retrieved from every bay, for every order. There are only two major differences with our problem. First: the above three papers model a stack which layout is slightly different from our stack. This is shown in Figure 14. The stack layout we use is a front-end layout, in which AGVs pick up the containers at the front of the stack. The three papers use a different layout, where the AGVs pick up the containers at the side of the stack. In that case, the stacking crane does not have to drive back to the front (or end) to deliver every container, but can stay at one bay to retrieve several containers without driving back to the front every time. This makes the problem considerably different.

The second major difference is that all three papers treat a scheduling problem and not a re-scheduling problem, so they create an initial schedule instead of improving an existing schedule under the restriction that as few as possible changes are made.

(17)

Figure 14: Stack layout in our instance of TIMESquare (left) and in the three papers (right). Pictures based on Kim and Kim (1999).

Although this model comes very close to our problem, there are still some important drawbacks. First, this paper does not treat a mathematical formulation of the problem. The model is kept very simple, and hence no optimizing algorithms are needed, which could improve the solution. We intend to bring more intelligence in the choice which containers to swap, by using an algorithm or heuristic to choose the best containers. Secondly, it uses category stacking, which means that containers are placed in the stack according to category, which is not the case in TIMESquare. Thirdly, Dekker et al. (2006) restrict the set of swap candidates to containers standing on top of a pile. In other words: only stacks with containers of the same category that are on top of the pile are included, so no rehandles are needed to grab that container. We do not want to include this restriction and keep the possibility of selecting containers that do need a rehandle.

Although the model of Dekker et al. (2006) does not seems appropriate for our problem, it has lots of similarities. It can at least be applied for comparing results. Dekker et al. (2006) report very good results using their stack swap method. Their purpose was to reduce the number of quarters a stacking crane was extremely busy, and their results indicate that the percentage high workloads is reduced significantly by swapping containers! This is a promising result for our research, although our problem is slightly different.

4.3 Available literature on scheduling problems

The previous section treated research devoted to stacks, stacking strategies, categorizing contain-ers and swapping containcontain-ers in the stack. Non of these sources gave a mathematical representation of their problem which was directly applicable to the stack swap problem, mostly because of differ-ences between the models or because no mathematical representation was given. For this reason we will try to rewrite our problem into a well known mathematical model. Looking to the nature of the problem and the formulations of other stacking problems, the class of scheduling problems seems to be suitable.

(18)

Scheduling problems can be described by a well known α, β, γ structure. The α field represents the machine environment, β describes the job characteristics, and finally γ indicates the objective function. In this section some types of relevant scheduling problems will be treated, given this notation.

The most well known α indicators are single machine, parallel machines, unrelated machines, a job shop, flow shop or open shop. The stack swap problem is a parallel machines problem (PMP), since the machines (stacking cranes) are parallel, i.e. only one machine is needed to process a job. The most well known β indicators are for the pre-emptive case, precedence constraints, an online problem or due dates for every job. Pre-emption means that if a job is started it can not be taken over by another machine later on. This is the case in TIMESquare, as well as precedence constraints. The containers have due dates, since they have to arrive on time at the quay. The problem is not online, since all information regarding which jobs will be present during the up-coming period is known. Scheduling online with precedence constraints is treated by Azar and Epstein (2002).

Some important γ objectives are minimize makespan, minimize total lateness, minimize total completion time or balance the workload of all machines. Since the stack swap problem aims to minimize the delays of containers this problem best fits the minimize lateness case.

The α, β, γ structure is introduced by Chen, Potts, and Woeginger (1998), along with an extensive list of special kinds of scheduling models, where for every case the complexity, algorithms, and approximations for that case are treated. No mathematical models are given.

As already stated earlier, the stack swap problem is a rescheduling problem. That is: an exist-ing schedule is improved by makexist-ing a minimum number of changes. An extensive overview of rescheduling strategies, policies and methods is given by Vieira, Herrmann, and Lin (2003). Also a lot of related articles can be found here. On the other hand, Lambrechts, Demeulemeester, and Herroelen (2007) state that rescheduling has only been extensively studied for machine scheduling, whereas for project scheduling this subject is virtually void. Two practical examples of how to implement rescheduling in real life are found in Smith (1994) and Miyashita and Sycara (1994). Both describe a methodology to revise a schedule for a realistic problem. Although it is interesting to see how real life problems are tackled, these cases do not really serve our purpose since they are created for special cases and no mathematics is incorporated.

Furthermore, the stack swap problem is subject to restricted assignment, another well known term in scheduling theory. It means that a container can not be assigned to every stacking crane, but only to a restricted set of cranes (in this case just one).

(19)

Calhoun, Deckro, Moore, Chrissis, and Van Hove (2002) and Yu and Qi (2004). Talbot (1982) uses an RCPS model for minimizing the project completion time while using precedence con-straints and nonrenewable resources, but does not deal with rescheduling. Calhoun et al. (2002) use a multi-mode RCPS model for planning, re-planning and rescheduling with the objective of minimizing the makespan using precedence constraints, pre-emption and nonrenewable resources. Finally Yu and Qi (2004) give in chapters 5 and 10 of their book a detailed description of how to reschedule RCPSP problems, for machine and project scheduling, including some algorithms. Some scheduling problems only aim at scheduling the jobs in a sequence, but many problems also want to include the exact end times of all jobs. In the stack swap case it is important to know the exact end times, as the containers have to be delivered at the quay on the due date. Since the precedence relations are separated from the containers itself, a due date is now connected to a place in the sequence, and not to the container anymore. Only if a container is assigned a place in the sequence, it can be linked to a due date. The next problem is to compute when a job is completed, i.e. when a container is retrieved. Notice that the duration of the job (the time to get the container out of the stack) depends on the sequence. This is easily shown with an example: if, after a swap, a rehandle is needed to free container X, its duration will increase. However, the above scheduling models do not allow for inter-dependent durations. Durations can depend on the resource used or the processing time, but not on other containers. This is a major issue for the stack swap problem, which makes all found models unusable.

Concluding this section, we see that the stack swap problem has lots of similarities with well known scheduling problems, but mathematically an exact match is not found. Hence, in the next section no standard scheduling model is used for constructing a mathematical model of the stack swap problem. Instead of that a self made, unrelated model is created.

4.4 Mathematical formulation

In this section an exact mathematical model is determined to represent the stack swap problem. First all variables are introduced shortly.

There exist m stacking cranes, all with their own part of the stack where containers are stored. Call these stacks Sjwith 1 ≤ j ≤ m. Furthermore we have n containers, called Ciwith 1 ≤ i ≤ n. A parameter Lij indicates if container Ci is stacked in Sj or not (1 or 0 respectively). The transport time to retrieve container Ci from the stack is given by Tis. Every container has a set of characteristics, such as its destination, length, weight, type, its position on the ship and the name of the ship where it has to be loaded. Every combination of characteristics is given a specific category, such that every container falls within exactly one category. The category in which container Ci falls is called Cati.

In the current schedule every container Ci is assigned a place g in the sequence (and consequently a place in the ship). An indicator variable Xo

igstates if Ciis placed gth in sequence or not (Xigo = 1 or 0, respectively). The containers then have to be loaded onto the ship in this specific sequence, on a specified time: the sequence is indicated by the variable Sucf g (which indicates if number g is the successor of number f ), and the requested end time of number g is called the due date Edd

g . The time the quay crane needs to load the container onto the ship is called TQC

g . This duration depends on the position of the container in the ship, and therefore on g. The driving time of the AGV from the stack to the quay is given by TAGV

jg , which depends on the distance between the destination of the container and the stack. Subsequently the container with sequence number g has to leave the stack at time E_gdd− TQC

g − T

AGV

jg to arrive on time.

(20)

The container below Ch which is processed first is then assigned a rehandle penalty b (this is the container with the highest value of Rihgreater than zero). The variable Pihsubsequently assigns a rehandle penalty to that container for rehandling container Ch. The total time needed to retrieve container Ci from the stack, called Duris, is given by the sum of the transport time of driving container Ciout of its stack (Tis) plus the rehandle penalties bPihneeded to free container Ci. For ease of notation: let DurAGV

i be the AGV transport time, which is equal to TjgAGV with j and g corresponding to i.

In order to determine which container is the direct predecessor of the current container at the same stack an indicator variable P redih is introduced. This is 1 if container Ch was the last one processed on the same stack before container Ci, and 0 otherwise. To compute this variable P redih we introduce two more variables: Qih and Vih. The first variable indicates if container Ch has an earlier due date as Ci. In other words, ifP

n g=1E dd g Xign > Pn g=1E dd g Xhgn. The second variable, Vih, gives the due date of container Chif it is retrieved earlier than Ci and it is located in the same stack. If not, it has the value 0. This variable removes all containers that can not be a predecessor of Ci. Then P redih can be computed as follows: find the container Ch with the highest value of Vih> 0. This is the direct predecessor of Ci at the same stack.

Due to delayed containers the current schedule does not work properly anymore, resulting in containers leaving the stack too late. The actual time container Ci leaves the stack is Eis, and accordingly the actual time container Ci is loaded is called Eia. Ideally, Eia matches with the due date of its corresponding sequence number Edd

g , but in some cases the due date can not be met and the end time exceeds the due date. This is caused by a delay in the stack and can have two causes:

• The container itself is delayed, call this delay Di. In that case the container can not be retrieved before Di. The earliest time the container can then be finished at the stack (Eis) is the sum of the delay time (Di) plus the duration to handle the container (Dursi). • When the stacking crane is still busy with the preceding container while the next container

should start. The earliest time a container can be retrieved (Es

i) is then the end time of its predecessor (

n P h=1

Es

hP redih) plus the duration to handle the container itself (Duris). A container is never allowed to leave the stack earlier than planned. If this would be allowed, a situation could occur where all buffers are occupied by AGVs carrying a container that is not the first one to be loaded. Then, if the container is retrieved that is the first one to be loaded it can not proceed to the quay crane (since all buffers are occupied) and the loading process stagnates. For this reason Es

i should not be smaller than n P g=1

Edd

g Xign − DuriAGV − TgQC: its due date minus the AGV and quay crane handling time. The actual time Ci is loaded (Eia) equals the maximum of ‘the earliest finish time according to the stack’ and ‘the earliest finish time according to the quay crane’. The first one is equal to the stack finish time Es

i plus AGV and quay crane duration. The second one equals the end time of the predecessor (Ea

hX n

hfSucf g) plus the quay crane duration for Ci: TgQC. The quay crane itself can not cause any delay in our mathematical model, but a delayed container will be delivered too late at the quay which causes the crane to be finished later. Our purpose is to reduce delay of containers. Delay is measured by the variable Zi and can be described by the difference between the actual finish time Ea

i and the due date Eddg . By swapping two containers the workload of the busy stacking crane should be decreased such that due dates are met. That is: find a container of the same category in another stack which can be loaded instead of the container in the busy stack. The container in the busy stack can then later be loaded when the other container was planned. If all constraints are met these two containers are swapped. Swapping containers is nothing more than changing the assignment of containers to places in the sequence, hence a new schedule Xn _{is made, where X}n

(21)

time. Every time delay is reduced by swapping containers, although at the same time the number of changes per analysis is minimized to prevent the new schedule from deviating too much from the old one. Consequently, the number of swapped containers Yi is counted and penalized with a swap penalty a.

Now that all important parameters and variables are mentioned, they will be formally defined: Parameters:

n = total number of containers m = total number of stacks

b = rehandle penalty, extra duration if container has to be restacked a = weight assigned to every swap

Ci = container i, 1 ≤ i ≤ n Sj = stacking crane j, 1 ≤ j ≤ m

Cati = category in which Cifalls (destination, length, weight, ...) T_is = transport time for taking Ci out of the stack

TjgAGV = transport time between Sj and quay crane (which crane depends on g) TgQC = transport time between quay and ship (depends on g)

E_gdd = due date for container which is planned as gth in sequence, 1 ≤ g ≤ n Di = possible delay of container i

X_igo =

1 if Ci is planned as gth in old schedule 0 else Lij = 1 if Ci is stored in Sj 0 else Oih = 1 if Ch is stacked above Ci 0 else Sucf g =

1 if the quay crane will handle g just after f 0 else

Decision variables: X_ign =

(22)

DurAGV_i = m X j=1 n X g=1 LijTjgAGVX n ig Vih = n X g=1 E_gddX_hgn ! Qih   m X j=1 LijLhj   P redih = ( 1 if Vih= max k Vikand Vih> 0 0 else

E_is = max(value1; value2; value3) with value1 = n X g=1 E_gddX_ign − DurAGVi − T QC g

and value2 = Durs_i + Di and value3 = Durs_i +

n X h=1 Es_hP redih E_ia = max(value4; value5) with value4 = E_iS+ n X g=1 (Dur_iAGV + T_gQC) and value5 = n X g=1  T_gQCX_ign + X_ign n X f =1 Sucf g n X h=1 E_haX_hfn   Zi = Eia− n X g=1 E_gddX_ign

These are all parameters and variables used in the stack swap model. The meaning of the variables value1 − value5 can be further clarified:

• value1 is the due date for container i to leave the stack, it can never be retrieved earlier • value2 is the earliest moment container i can leave the stack, given that is has a delay Di • value3 is the earliest moment container i can leave the stack, given that the stack was

finished with its predecessor at Es h

• value4 is the earliest moment container i can be finished, given the total transport time (AGV-, quay crane- and in-stack time)

• value5 is the earliest moment container i can be finished, given that the quay crane was finished with its predecessor at Ea

h The model is defined as follows:

(23)

Here (1) is the objective: minimize the delay on the due dates while performing at least as possible swaps. (2) and (3) assure that the new sequence consists of the same numbers as the old sequence and that no number is defined twice. Finally (4) states that two containers can only be swapped if they have the same characteristics, so if they are in the same category.

The objective function can be clarified by writing it out:

min n X i=1 (Zi+ aYi) = n X i=1 E_ia− n X g=1 E_gddX_ign + aYi ! = n X i=1

(delay of container i + a ∗ swap of container i)

This model can be used for terminals with multiple ships too. In that case the sequence number g does not have any value regarding the moment that container Ci is loaded at a ship. This is caused by the fact that the variable g can only attain the values 1 to n, and in the case of multiple ships we need multiple sequences: one sequence per ship. Therefore the variable Sucf gis created. This variable will always indicate which ‘sequence numbers’ f and g are successors for the same ship. The value of the variable g can therefore not be used for determining which container is loaded first, it is just an indicator for container characteristics per position in the ship.

4.5 Numerical example

A numerical example will visualize how a stack swap problem can be translated into this mathe-matical model. Go back to the situation of section 3.2.2. This example incorporates two stacks, A and B, both containing four containers. Stack A holds containers 1, 3, 6 and 7 and stack B containers 2, 4, 5 and 8. Assume they are stacked as in Figure 15. The containers are stacked on each other, therefore container 1 has to be retrieved before container 3, otherwise a rehandle is needed.

Figure 15: Arrangement of containers in the stack.

Imagine the disrupted situation of Figure 12 where one swap was performed. This situation is depicted again in Figure 16, and will be rewritten into the mathematical model introduced above. Here, the number of containers n = 8 and the number of stacks m = 2. Subsequently, some assumptions have to be made. First assign a rehandle penalty b of 30 seconds and a swap penalty a of 0.25. Furthermore assume that containers 1, 3 and 5 are of category α, containers 2, 4, 7 and 8 are of category β, and container 6 is of category γ. Since we assumed that the time to retrieve a container was 1 minute, Ts

i = 1 for all i. However, container 1 is delayed a minute, therefore D1 = 1. Finally simplify this example by assuming that the transport time between stack and quay is negligible (i.e. TAGV

jg = 0 for all j and g), and the quay crane handling time is negligible too (TQC

g = 0 for all g).

(24)

matched with sequence number 1, 2 with 2, and so on. The old schedule matrix Xo _accordingly is the identity matrix, with ones on the diagonal. The due date for sequence number g = 7 equals 6, since container 7 was planned to be ready at time 6. This is indicated by Edd

7 = 6.

The (6,1)th entry of matrix L is 1, since container 6 is stacked in stack A (the first stack). And container 2 is stacked above container 4, hence the (4,2)th entry of the O matrix is 1.

Since all containers are loaded on the same ship the sequence 1-8 is the exact loading sequence for the ship. Therefore Sucf g= 1 for all f equal to g − 1, with f < 8 and g > 1.

The new schedule matrix Xn _{looks similar to the old schedule but with the ones on the first and} fifth row interchanged, since in the new schedule container 1 and 5 are swapped. Consequently penalty vector Y has a 1 on the first and fifth place.

Figure 16: Changed schedule after delayed container and swap.

The matrix Q indicates which of two containers has the earliest due date. For example, Q4,2= 1 since C2is retrieved earlier than C4. The matrix R is an all-zero matrix except for the entry (3,1), since due to the swap, container 3 is retrieved earlier than 1, but 1 is stacked above 3. This results in a rehandle matrix P of all zeros except entry (3,1), which gives a rehandle penalty to container 3. The stack duration matrix Dursconsists of mostly ones, but entry 3 equals 1.5, since container 3 incurred a rehandle penalty. The AGV duration matrix DurAGV consists of only zeros since all AGV driving times are equal to zero.

The matrix V contains the due date of all containers Ch which are retrieved earlier and from the same stack as Ci. This way the direct predecessor of Ci is easily found. The entry V8,2 equals 2 since C2 is retrieved earlier from the same stack as C8, and its due date is 2. The predecessor matrix P red states which container is the last one handled before the container corresponding to that row. For example, the entry (8,4) equals 1 since container 4 is the last one handled in stack B before container 8.

Since both the AGV and QC handling time are 0 zero here, the end time in the stack equals the actual loading time: Es

i = Eia. The stack end time is the maximum of three things: the due date, the earliest end time subject to delay and the earliest end time subject to the predecessors end time. For example: the stack end time of container 1 equals 4, since its due date is 4, its earliest end time due to delay is 1+1=2 (duration + delay) and its earliest end time due to its predecessor is 1+2.5=3.5 (duration + end time of container 3). Since all containers arrive on time in the new schedule, the lateness matrix Z consists of only zeros.

(25)

5 Solving the stack swap problem

The mathematical model for the stack swap problem is constructed and subsequently needs to be solved. However, first the computational complexity of this problem should be discussed. Given that, an overview of solution concepts for the stack swap problem is presented, from which one method is chosen to be used in the simulation study.

5.1 Computational complexity of the stack swap problem

The stack swap problem as modeled in the previous section is a mixed integer (linear) program-ming problem (MIP). The proof of its linearity is given in Appendix H. However, solving MIP problems is generally accepted to be NP-hard (see for example Hung and Hu (1998) or Ghosh and Hayward (2008)), that is, it can not be solved to optimality in polynomial time. And since the stack swap problem is a realistic, large scale problem we get the impression that solving it to optimality will cost too much time to be acceptable. We therefore have to state what is acceptable. Our instance of TIMESquare runs about two times real time (i.e. a run of eight simulation hours takes about four hours real time). During this run AGVs are assigned orders. Once an order is assigned swapping is not possible anymore, and consequently the stack swap is performed immedi-ately before the AGV assignment, so that the situation is up-to-date. Since the AGV assignment is done quite often, the stack swap algorithm is executed very frequently too, which restricts the algorithm to take only a few seconds processing time to obtain a solution. Otherwise the run time of a simulation will increase too much.

For large size NP-hard problems it is advisable to use an heuristic algorithm instead of an enumer-ative algorithm, since an enumerenumer-ative algorithm would not find the optimal solution in polynomial time. Heuristic algorithms work faster than enumerative algorithms but can not guarantee an op-timal solution. As a test the worst case performance of an enumerative algorithm for the stack swap problem is computed. This is simply the total number of possible schedules. In our case we have n containers which can be assigned to n different places in the schedule, hence the total number of schedules possible is n!. Since in our instance of TIMESquare the number of cate-gories is about 20 and the number of containers per category 8, an enormous number of schedules should be investigated. Already 10 categories with 1, 2, 3, ..., 9, 10 containers, respectively, create

P10 i=1i

! = 1.3 ∗ 1073 possible schedules. As our computer calculates the performance of one schedule in about 0.16 seconds, so 1.3 ∗ 1073_{schedules are analyzed in 6.4 ∗ 10}64_{years, we conclude} that an enumerative algorithm is not useful for our purposes.

Another reason is that most of the articles considering stacking- or scheduling problems use heuris-tic algorithms to find a reasonable solution. Moreover, a large set of scheduling problems is found to be NP-hard, which strengthens us in our decision. However, the NP-hardness of other schedul-ing problems does not guarantee anythschedul-ing on the complexity of the stack swap problem, it is only an indication.

5.2 Solving to optimality

Although an enumerative algorithm seems not appropriate for solving the stack swap problem, it is still interesting to test which instances can be solved to optimality within a few seconds. For this purpose the mathematical model is constructed in AIMMS optimization software, which makes it possible to create and solve all types of mathematical optimization problems. The stack swap problem is a Mixed Integer (linear) Problem. It is not linear in the form described in section 4, but can be linearized by introducing extra variables and constraints, which is done in Appendix H. Once the model is constructed, a data set can be incorporated to represent a specific instance. This instance is then solved by AIMMS.

(26)

be found in Figure 17. Already with an instance of 14 containers AIMMS needs more than 10 seconds for solving the problems to optimality. Since most instances in TIMESquare possess many more containers, stacks and categories, we conclude that our stack swap problem can not be solved to optimality in the time reserved for it. Consequently, an heuristic algorithm is used.

Figure 17: Computation times in AIMMS for solving to optimality.

5.3 Overview of heuristic algorithms

An heuristic algorithm is a good alternative for an exact algorithm, since it approximates the optimal solution in as short time as possible. A class of heuristics commonly used for NP-hard computational problems and furthermore frequently used in the articles on stacking- and schedul-ing problems is the class of metaheuristics. Metaheuristics are coverschedul-ing procedures which lead other (user given) heuristics to search for feasible solutions. A nice article about the use of meta-heuristics in combinatorial optimization is given by Hertz and Widmer (2003).

(27)

5.3.1 Simulated Annealing

Simulated Annealing was created by Kirkpatrick, Gelatt, and Vecchi (1983). It is based on the annealing procedure in metallurgy, where the temperature is increased and after that gradually lowered to bring the atoms in a favorable state. The Simulated Annealing procedure works sim-ilarly. At each iteration, a random neighbor is picked and the performance of that neighbor is calculated. If the performance is better, the neighbor is accepted as the new schedule, after which a new iteration starts. If the performance is worse, the heuristic will probabilistically choose if the new schedule is accepted or not. The chance at which the new schedule is accepted (the tempera-ture) decreases gradually as the number of iterations increases. This assures that the heuristic can get away from local minima in the beginning, when the temperature is high, but will accept only better solutions in the end of the procedure, when the temperature is low. In order to minimize the chance that the procedure will end up in a local minimum by coincidence, the heuristic can be restarted after a predetermined number of iterations, or if a predetermined number of schedules is rejected. The best schedule found is memorized and given as output of the procedure.

5.3.2 Tabu Search

Tabu Search was created by Glover (1990). It uses memory to remember recent changes (swaps). The most recent changes are put on the tabu list, which means that there is a taboo on all swaps on this list: returning to an earlier schedule will not be accepted. This pushes the procedure out of local minima. The tabu list has a limited memory, such that not all previous swaps are taboo, but only the most recent ones (the user has to decide on the length of the list). This enables the procedure to return to certain areas after a number of iterations, if these areas are still promising. The Tabu Search procedure searches for neighbors too, but in a different way than the Simulated Annealing procedure. Tabu Search investigates all neighbors and picks the best one, even if the best one is worse than the current schedule. The overall best solution found is memorized, and after a certain number of iterations the best solution is returned to the user.

Both Simulated Annealing and Tabu Search seem to be promising. The disadvantage of Sim-ulated Annealing is that it randomly chooses neighbors. Since the number of allowed swaps is limited, these swaps should be chosen carefully, which is not the case when using Simulated An-nealing. The most effective swaps are the swaps between containers which are delayed, because swapping two containers which are not delayed does not improve the schedule directly. Of course, indirectly they could make place for delayed containers to swap, but as time and number of swaps are limited, the Tabu Search method is intuitively preferred because it chooses the best swap, i.e. the swap which immediately improves the schedule. On the other hand, the disadvantage of Tabu Search is that it costs lost of memory. During every iteration, it has to calculate the performance of all neighbors, whereas Simulated Annealing just computes the performance of one neighbor. Since it is impossible to say on beforehand which algorithm will perform best, both methods are tested in TIMESquare for a number of situations. Moreover, for comparison a self made simple ‘heuristic’ is implemented, which solves the stack swap problem within a second. If Tabu Search and Simulated Annealing will both give unsatisfactory results in a few seconds, their results can be compared with this heuristic which always finds a (suboptimal) solution in time.

5.3.3 Simple heuristic

(28)

Figure 18: Flowchart of our self made heuristic algorithm.

The difference with the two metaheuristics is the following: our simple heuristic investigates a swap, and if found, performs it. That is: the swap is done in the actual schedule. The meta-heuristics can not immediately perform the swaps, as in a later phase another schedule could be preferred. Moreover, the metaheuristics sometimes start over and subsequently need to go back to the initial schedule. Because of this, the metaheuristics need to memorize the initial schedule, the overall best schedule, and the current schedule, including its performance. This costs lots of memory and computing power. On the other hand the simple heuristic is expected to produce worse solutions than the metaheuristics, since it just picks a set of moderate swaps without us-ing too much intelligence. Moreover, the simple heuristic only accepts a swap if both stacks are available to handle each others container, to assure that the swap will not increase the overall delay (a metaheuristic can first perform a swap which increases delay to make space for a swap which eventually reduces delay). For this reason the simple heuristic is more restricted than the metaheuristics and thus is expected to produce less good solutions. Summarizing, three different heuristics will be tested: a simple and fast heuristic which is not expected to perform very well, a Simulated Annealing procedure which iterates fast but uses not much intelligence to choose swaps, and a Tabu Search procedure which is slow but improves fast. Which one performs best?

5.4 Which algorithm or heuristic to implement at TBA?

(29)

First of all a penalty structure for the number of swaps is specified, because the adjustments to the schedule have to be minimized. Up to around ten swaps are allowed, but much more than that is not desired (this number is chosen by TBA, it is an intuitive choice). Some different penalty structures are tested, as shown in the following overview, where swaps stands for the number of swaps done:

structure 1: penalty = 5 ∗ swaps structure 2: penalty = 10 ∗ swaps structure 3: penalty =

0.5 ∗ swaps if swaps ≤ 10

5 + exp(0.2 ∗ (swaps − 10)) if swaps > 10 structure 4: penalty =

5 + exp(0.3 ∗ (swaps − 10)) if swaps > 10 structure 5: penalty =

5 + exp(0.4 ∗ (swaps − 10)) if swaps > 10

Intuitively we value one swap equal to 5 seconds of time gained, i.e. ten swaps are acceptable if they improve the schedule with at least 50 seconds. The most basic function is a linear function. Two linear functions are tested, one with factor 5 (equal to 5 seconds time gained) and one with factor 10, where the value 10 is chosen for comparison. However, a linear function is not very useful since more than ten swaps have to be punished harder than ten swaps or less. To assure that up to ten swaps are accepted easily (low penalty) but more swaps are punished hard, a penalty structure with an exponential distribution is selected (which increases rapidly and exponentially). We decide that a factor of around 0.3 looks good (the function increases rapidly but allows swaps of eleven to twenty to be accepted easily too: see Figure 19), and test three structures with factors around 0.3: the factors 0.2, 0.3 and 0.4.

Figure 19: Penalty structures 3 to 5 with factor f = 0.2, 0.3 and 0.4.

(30)

schedules is not accepted. The size of this number needs to be chosen too. Again a preliminary investigation was done and the procedure worked best with a restart after 250 to 700 unaccepted schedules. Three arbitrary values in this range will be tested. Two other parameters needed for the SA procedure are the maximum number of iterations and the maximum number of restarts. We have decided to fix these on 10000 and 10, respectively. These numbers seem intuitively large enough to enable the system to converge, but small enough to limit the runtime. Finally, the temperature decreasing scheme is fixed on tempi+1 = 0.99 ∗ tempi, that is, every iteration the temperature is decreased with 1 percent.

For the Tabu Search procedure we need to decide on the length of the tabu list (how many steps are remembered) and the maximum number of iterations. The length of the tabu list is varied as seen in the table below, the maximum number of iterations is fixed at 12. These numbers are chosen intuitively. The procedure also needs an aspiration criterion: a rule which overrules the tabu restriction. A common aspiration criterion is chosen: the overall lowest objective value. So if a solution is taboo but performs better than the current best solution found, it is still accepted.

Simulated Annealing Tabu Search

Initial temperature Number not accepted Length tabu list Check all

250 250 1 true

450 500 3 false

550 700 6

700

Table 1: Parameter values tested for the metaheuristics.

Finally, since the number of neighbors to be verified proves to be very large, we include an extra option: the ‘Check all’ option. In every iteration the Tabu Search procedure has to check all its neighbors and chooses the best. Notice that a swap of two non-delayed containers can not decrease the objective value, hence, the speed of the algorithm can be increased by first checking all swaps with delayed containers involved. Call this set of swaps with at least one delayed container: D. If checking the set D delivers a feasible swap which decreases the delay, all swaps outside D can be dropped, which decreases the search time considerably. If checking the set D does not yield a better solution, all swaps outside D should be checked. As this is very time-consuming, we incorporate an option into the Tabu Search procedure to stop the heuristic if no solution in D is accepted: the ‘Check all’ option. This seems like a compromise between the simple heuristic and the metaheuristics. Both the Tabu Search procedure with and without the ‘Check all’ option will be tested.

(31)

choice on the length of the Tabu List does not influence the results, therefore this length is fixed on 3. That is: the recent three swaps are taboo. Finally an analysis on the penalty structures is preformed. The linear structures generate solutions with far to many swaps, which makes them unfavorable. Which exponential structure to choose is hard to say. The Simulated Annealing procedure is not useful at all, and since the Tabu Search procedure generates only solutions with 11 or less swaps, the influence of the factor (0.2, 0.3 or 0.4) on the objective value is negligible. We decide to use penalty structure 4, since this is the center value.

Subsequently, a set of replications with the adapted Tabu Search procedure and the simple heuristic are ran. The Tabu Search procedure appears to be less fast than thought, which can be explained by the fact that when a simulation starts many containers are delayed (since the terminal does not start in a steady state) and consequently many alternatives have to be investigated. A moderate stack swap analysis takes already 1 minute and in some cases even several minutes. Overall the Tabu Search replication runs about 11

3 times real time (6 hours per run), while the replication with the simple heuristic equalizes a replication without swapping, around 2 times real time (4 hours per run). Because of this major difference the simple heuristic is preferred, which will be used from now on. The code for implementing the simple heuristic and Tabu Search procedure in TIMESquare can be found in Appendix E and F, respectively.

5.5 Comparing the exact algorithm with the heuristics

It is an interesting point to compare the performance of the heuristics and the exact algorithm regarding the stack swap problem. However, a couple of reasons make it impossible to compare these methods accurately:

• First: since the exact algorithm is used in AIMMS and the heuristics in eM-plant, the computation time is not comparable. Incorporating the exact algorithm into TIMESquare or the heuristics into AIMMS is very complicated, as not impossible.

• Furthermore, the model in AIMMS is linear and can therefore easily be filled with data to make a simple example. The heuristics in eM-plant are connected to the database used in TIMESquare to plan the container deliveries. Since this database is far more complicated than the simple linear model, it is hard to create a similar situation in both programs. • Finally the possibilities in TIMESquare regarding swapping are more advanced than we

initially incorporated into the mathematical model. These differences are treated in section 7.3.

All these differences between AIMMS and TIMESquare make an accurate comparison impossible. Nonetheless, we do know that solving the stack swap problem to optimality is not possible in a time acceptable to TBA, therefore the heuristics are incorporated. Heuristic algorithms work much faster, although the quality of the solutions related to the exact method can not be determined. The simulation runs in TIMESquare will reveal if the heuristic solutions still improve the schedule.

Decreasing the loading time of a container ship at a terminal by swapping load orders.

Decreasing the loading time of a container ship at a

terminal by swapping load orders.

A. Tydeman

Decreasing the loading time of a container ship at a terminal

by swapping load orders.

Anne-Jette Tydeman

Contents

1

Introduction

1.1

TBA

1.2

Container terminals

1.3

Structure of the thesis

2

Situation overview

2.1

The loading process of a container ship

2.2

Problem description

2.3

A possible solution: swapping

3

Research outline

3.1

Research objectives

3.2

Implementing swaps

4

The stack swap problem

4.1

Objective and restrictions

4.2

Available literature on the stack swap problem

4.3

Available literature on scheduling problems

4.4

Mathematical formulation

4.5

Numerical example

5

Solving the stack swap problem

5.1

Computational complexity of the stack swap problem

5.2

Solving to optimality

5.3

Overview of heuristic algorithms

5.4

Which algorithm or heuristic to implement at TBA?

5.5

Comparing the exact algorithm with the heuristics

5.6

Sensitivity analysis