Improving the Traﬃc Performance of Automated Guided Vehicles at Automated Container Terminals

(1)

Improving the Traffic Performance of Automated Guided

Vehicles at Automated Container Terminals

A simulation study at TBA B.V.

R. van den Hof

Delft, July 10, 2008.

Master Thesis Econometrics, Operations Research and Actuarial Studies. Specialization Operations Research.

University of Groningen. Supervisors:

(2)

(3)

Abstract

(4)

(5)

1 Introduction

State-of-the-art container terminals at major ports are currently fully automated. These ter-minals contain very complex technology, such as Automated Guided Vehicles (AGVs). AGVs are unmanned vehicles which convey containers from a storage area to vessels and vice versa. As stated in Egbelu and Tanchoco (1984), AGVs are more flexible and capable than manned vehicles. However, they require a more sophisticated operational control system, so that the extra flexibility is utilized at best. The automated equipment at a terminal is relatively new and improvement of its performance is required. One aspect of improving the equipment is to reduce the technical disturbances (Stahlbock and Voß, 2008b). Breakdowns occur sometimes and performance that is technically possible is mostly not obtained in practice. Another aspect is the operational control system that should be optimized (Stahlbock and Voß, 2008b). The focus of this thesis will be on the latter aspect and on only one segment of the terminal equip-ment: the AGVs. But before improvement on the performance of an Automated Container Terminal (ACT) can be made, a measure of its performance must be defined. As a rule of thumb, Steenken et al. (2004) state that an overall objective for a terminal is the minimization of time a ship is at berth. To relate this with AGV performance, it implies that if AGVs travel more efficient, an AGV will be earlier at its destination, which implies that the quay cranes (QCs) have to wait less longer for vehicles. This saves time and thus a ship is earlier finished. Of course, this is only true if the travelling of AGVs is the bottleneck. In Section 5.1 we will see that the travelling of AGVs is indeed a bottleneck. Efficient driving will usually mean an increase in traffic density. As a consequence, the degree of congestion will increase as well, which, applied to current routing methods, could result in lower QC performances. This thesis will try to deal with this problem of increasing the driving efficiency while not getting stuck in highly congested areas. The research will be mainly on improving the performance of AGVs by improving scheduling and routing techniques.

This thesis is written on the basis of an internship at TBA B.V. This company consults its customers about their logistic business processes. In order to give an appropriate advice, TBA uses simulation tools. Their main application is the ACT, in which TBA has already done a lot of work. However, the simulation models could still be improved. One of their simulation models is TIMESquare (Terminal In-depth Models for Evaluation Studies). TIMESquare gives answers to questions that arise when a new terminal is set up or an existing terminal is renewed. Different types of system designs can be tested in order to get the best possible layout for this terminal. For more information on TIMESquare, see TBA B.V. (2008). The intended solutions for the problem introduced above will be implemented and tested in this simulation model.

2 Introduction to automated container terminals

(8)

The size of a container is either 1 or 2 TEU. There is only one exception: a container could be 45 ft, but those containers are called 2 TEU as well. Due to the fixed sizes, automation is easier: the storage area in a ship gets a fixed layout, terminal vehicles and carriers get a standard length and thus they are able to carry all types of containers, storage areas get fixed dimensions, et cetera. No wonder that since the sixties worldwide container turnover increased continuously and still grows (G¨unther and Kim, 2006). For more facts and figures about this trend, see Marcadon (1995). Marcadon did an extensive survey to global container traffic flows. The article is a bit outdated, but as can be read in G¨unther and Kim (2006) the trend continued. Figure 1 shows an image of this worldwide trend.

Figure 1: Growing worldwide container turnover (source: Hafen Hamburg (2007)). Containerization made automation easier, but the question remains: why? As Saanen (un-dated paper I) explained robotized equipment works steadier, is thus more predictable and controllable, and is less expensive in the long run than the relative expensive labour costs, especially in the northwest of Europe. Robotized equipment is therefore already standard in manufacturing. Another reason put forward in Saanen (undated paper I) is that it could save space, a scarce good in North-West Europe. And last but not least, a cause of the automation process is the pressure to achieve the best performances. The competition between terminals is in fact very strong, especially in North-West Europe: the Hamburg–Le Havre Range. This competition is investigated in Marcadon (1999). As described in that article, ports have to get the best out of their terminals to remain profitable. And if their own port has reached its limit, then they have to look elsewhere and join forces with other terminals. However, ports should not only hold on in staying the cheapest; it is not as easy as that. Ports have to invest in their service, their accessibility, infrastructure of the hinterland, reliability, flexibility and so on. A more complete list and a description can be found in Hoste et al. (2006).

(9)

Rotterdam’s major terminal operator ECT was purchased by Hutchinson Port Holdings group, which is also the owner of European terminals in for example Felixstowe, London, Barcelona and Gdynia (Poland).

In 1993, ECT (Europe Container Terminal) opened the doors of the first ACT in the world in the port of Rotterdam. Nowadays, there are already 265 AGVs travelling on the quay of ECT with a total length of 3.6 kilometre (Europe Container Terminals, 2007). Hamburg fol-lowed in 2002 and has currently 74 AGVs and a quay length of 1.4 kilometre (Hamburger Hafen und Logistik AG, 2008). This year, a second ACT will be opened officially in Rotterdam: the Euromax Terminal (as a part of ECT). The first ships however, have already arrived. Without doubt, many more ACTs will show up in the future, especially if automated equipment has proved to be solid and robust in practice.

2.1 The terminal

In this section, the ACT is introduced in more detail. Its layout can differ from terminal to terminal. Therefore, only the main equipment will be discussed and some more detailed infor-mation of equipment will be given when it will be used more often in this thesis. Figure 2 gives a schematic overview of a terminal. We can divide a terminal into three parts: a landside, a waterside and a storage area in between. At the landside a stacking crane picks up containers from hinterland transport (or delivers containers for hinterland transport). The truck driver can drive its truck as far as the stacking crane, where he can, at the new terminal of ECT, place the container on his truck by himself. This is only the last few centimeters, the rest is done entirely automatic. Meanwhile, manned terminal trucks transfer containers from the storage area (the stack modules) to the trains (and vice versa). At the other side of the stack modules another stacking crane loads and unloads vehicles from the waterside transport. Furthermore, both the stacking crane on the landside and the waterside reorder containers such that other moves in peak hours might be done quicker: the so-called housekeeping moves. These moves include also the transport of a container from the landside of the stack to the waterside of the stack. The waterside transport consists of conveying the containers from the stack modules to the quay (or gantry) cranes and vice versa. QCs load and unload containers onto or from the vessel. At ACTs, waterside transport is done by fully automated equipment and stack cranes

(10)

are also completely automated. An example of such an Automated Stacking Crane (ASC) is a Rail Mounted Gantry (RMG). RMGs are gantries that are stuck to a railway system and thus RMGs can solely move in two directions. The only manned equipment at an ACT is the QC. This is because of the difficulties of, for example, determining the exact positions of the containers on board and the positioning of containers into the vessel. Due to the swelling of the water the vessel will never be on the exact same position.

The layout of the transport area on the waterside of an ACT is similar at different termi-nals, although the realization of the details is quite different. AGVs cannot drive freely around: the routing is restricted to give structure and to make routing and scheduling easier. For a schematic overview of the road network, see Figure 3. The layout is as follows: in front of the stacks lie a number of highways. These highways are directed to either the left or the right. Above the highways there are several buffers. These buffers serve as a waiting location for vehicles if they cannot reach a QC immediately or whenever they have delivered their container at a QC and do not have a new order. Above the buffers lie a couple of quay lanes. Usually, all quay lanes are headed in the same direction. To complete the road network the end point of an AGV beneath a QC (and ASC) is called its transfer point (TP). It is possible to assign more than one TP to each QC. Each ASC has about four or five TPs. These TPs in front of the ASC could serve as buffer as well: idle vehicles wait here too for new orders.

Figure 3: Schematic overview of the infrastructure on the waterside of a container terminal.

(11)

and a QC needs some space to lay down ship parts like hatch covers and lashing equipment. When working in backreach those units are laid down beneath a QC. The unavailable buffers are close to a QC, thus if those are blocked it implies that AGVs have to travel more.

2.2 Description of an AGV system

An AGV system contains everything to manage all AGVs operations. The general structure of an AGV system is described below.

As mentioned, vehicles do not travel randomly around. One measure is putting structure in the road network. However, this will not be sufficient to avoid a big chaos. Some coordinating system should keep track of a lot of information about all vehicles. But this still is only a part of it. Before a vehicle could execute any order a lot of choices should be made. All these choices that are involved with AGVs, are part of the AGV system. As in all systems that require decision strategies, there are three levels: a strategic, tactical and operational level. Le-Anh and De Koster (2004) summarizes the decisions that should be made in an AGV system on each decision level as follows:

• Strategic level:

– guide-path design decision. • Tactical level:

– vehicle requirement decision; – vehicle scheduling decision; – battery management decision; – vehicle parking policy decision. • Operational level:

– vehicle routing decision; – conflict resolution decision.

The guide-path design affects the layout of a terminal and is therefore a decision taken before a terminal is built. The question is how to guide AGVs to their destinations and which locations are connected to each other? And how are they connected, with more than one path? And are the connected in both directions or in only one direction? That is respectively, which flow topology is chosen, how many parallel lanes and how is each lane directed? Table 1 gives a selection of the different options for each of these questions.

Flow topology Number of parallel lanes Flow direction Conventional Single lane Unidirectional flow Single-loop Multiple lanes Bidirectional flow Free-ranging

Table 1: Different characteristics of guide-path designs (Le-Anh and De Koster, 2004, Table 1).

(12)

same, however AGVs are not guided by fixed paths. They seek their own way using sensors or other high-tech devices. In a single-loop guide path, pick-up and delivery locations are indirectly connected by a large single loop. At ECT they started with the single-loop setup (Meersmans, 2002). The loop consists of multiple lanes which come along all QCs and all stack modules. The guide-path design of ECT is illustrated in Figure 4. In order to cut the travel distances of AGVs, the guide path design consists currently of multiple loops: each cluster of QCs has its own loop (Kim et al., 2006).

Figure 4: The guide path design of ECT (Meersmans, 2002, Fig. 4.1).

(13)

At tactical level there are a number of choices that should be made before the AGVs are going to drive, such as:

• which type of AGVs to use; • the number of AGVs needed;

• decisions involved with recharging the batteries of an AGV or refuelling; • choices that are concerned with idle AGVs;

• doorturn handling.

Those choices can, contrary to the guide-path design, also be changed after the design of a ter-minal; if after several years of research and experience it turns out that another strategy might be more efficient, it is possible to change. The scheduling decision requires more brainwork. It strongly affects the routing decisions and vice versa. The general method to calculate the schedules can be decided in advance. The scheduling itself is an operational decision and thus takes only place during the execution of an AGV system. The operational scheduling decisions are primarily concerned with when, where and how to do which tasks an AGV receives from the scheduling system. The routing component of the AGV system should give instructions to a vehicle so that it can reach its destination. If there are conflicts, they should be solved eas-ily and smart. The routing and scheduling of AGVs is elaborated in more detail in Section 2.2.3. Another choice to be made is how to deal with doorturns. Containers have a door at only one side and the direction of the door is strict in the stack, but not throughout the vessel. Due to intermediate calls at several ports, with at each port different routing strategies and not always mooring with the same side at the quay, standardizing the direction of the doors in the vessel is difficult. Though each row of containers separately must have the door at the same side, since containers upon each other and beside each other are secured, which is only possible with the door at the same side. Hence, AGVs in both directions, the QC and ASC, should arrive with the door at the correct side, since most QCs and ASCs are not able to turn the container themselves. So, if the door is not at the correct side, the AGV should turn: a doorturn. This increases the complexity with respect to routing and scheduling techniques. Another article, in addition to Le-Anh and De Koster (2004), about designing an AGV system is Vis (2006). Its author elaborated the possibilities in above decisions in more detail. An extensive example and evaluation of terminal design is performed by Saanen (2004).

2.2.1 The vehicle

(14)

The specialist in automated equipment at ACTs is Gottwald. They offer two kinds of AGVs: a diesel-hydraulic and a diesel-electric AGV. Both AGV types are almost 15 meters long and 3 meters wide and weight without container about 25 ton; for more details see Gottwald (2007). It can travel at most 6 m/s, but a turn can only be driven with 3 m/s. However, in case of a loaded AGV with a 40 ton container the probability of turning on its side is too high when it travels a curve with 3 m/s. So, in practice the maximum curve speed is limited to 2 m/s, even when the AGV is unloaded. Because of the length of an AGV, it needs a lot of space to make a turn. Nearby vehicles should therefore be highly alert and should keep a safe distance of the turning AGV in order to avoid collisions. The turning behaviour of an AGV is technically thus a complex movement. Not only for the AGV itself, but also for the coordinating system that alerts other vehicles. In Figure 5, an example of a turning AGV is illustrated. The grey area is approximately the space needed to avoid that the AGV grazes a nearby AGV. As a consequence AGV2 and AGV3 should stop outside the grey area and AGV4 should slow down to approximately 2 m/s.

Figure 5: Turning of an AGV.

2.2.2 Collision and deadlock avoidance

The worst thing that could happen in an AGV system is a collision of vehicles. In order to avoid collisions, the easiest solution is that AGVs claim their route first and then drive only on their claimed paths. Other vehicles are then prohibited to drive on or to claim these claimed paths. If collisions are avoided, the next bad situation that could happen is a deadlock. As a simple example see the left-hand side of Figure 6. Since AGV1 wants to the opposite direction of AGV2, both AGVs cannot continue their route. In order to avoid deadlocks, claiming could be a solution. The deadlock situation at the left-hand side of Figure 6 is avoided at the right-hand side of Figure 6, in which AGV2 has claimed its route partly. However, claiming is not sufficient to avoid deadlocks. In the example of Figure 6, AGV2 requests the whole route part at once including the turn. If AGV2 would not, then both AGVs claim a section and the result is again the left-hand side of Figure 6. Another deadlock avoiding strategy is to fix the direction of each highway, so that it is impossible to have two vehicles driving towards each other on the same highway.

(15)

Figure 6: At the left a simple example of a deadlock. At the right a solution by claiming.

AGV with the existing schedules. The AGV reserves certain blocks, so that no other vehicles can claim the reserved blocks before the AGV has passed them. TIMESquare, to the contrary, uses the characteristics of certain route parts. Because highways are one-way directed, driving straight on a highway cannot result in a deadlock. As a consequence, those AGVs only have to claim (at least) the required distance to brake. Deadlocks could only occur when AGVs want to merge onto or exit the highway. Therefore, those route parts are claimed at once as a non-stop claiming section. In this way, it is ensured that an AGV can reach the highway or its next stopping point: the buffer or a TP beneath an ASC. However, it is too simple to state that granting non-stop claims solves all deadlock situations. Deadlock avoiding strategies in TIMESquare are further discussed in Section 4.2.2.

2.2.3 Routing and scheduling of AGVs

(16)

system; the changes during the execution have too much impact to neglect. For the on-line case there are basically two approaches to calculate the routing schedules: a decentralized or a centralized control system. In a decentralized system each AGV decides for itself. It uses only local information and cannot interact with other vehicles nor other equipment. Some applications are simple enough to work with such a system. However, the AGV system in a container terminal is certainly not suitable for a decentralized system. First of all, there should be a centralized control system that keeps track of all movements of all AGVs to avoid deadlocks. Secondly, the system should communicate between the AGVs and their destinations, so that the AGVs arrive in the correct sequence under the QC. Finally, a central control system should give instructions to the AGVs so that inefficient travelling is minimized. In order to instruct the vehicles the control system could work with three kinds of methods (Le-Anh and De Koster, 2004):

• Using dispatching rules; this is the most easiest method to use and to implement in practice. Dispatching rules just give instructions to each vehicle (and other equipment) separately telling them exactly what to do in which situation.

• Using an exact algorithm; an exact algorithm gives several instructions to more than one vehicle (or other equipment) simultaneously for a given period of time. An exact algorithm optimizes the schedule(s) by a predefined objective function. The outcome is the optimal schedule.

• Using a heuristic; a heuristic gives also several instructions to more than one vehicle (or other equipment) simultaneously for a given period of time. A heuristic approaches the optimal solution as close as possible in as short time as possible.

The advantage of using an exact algorithm is that the outcome is for sure an optimal solution. However, not in all cases an optimal solution will be found or it might be found too late. In those cases, a heuristic could be a good alternative, if it approaches the optimal solution sufficiently. Dispatching rules are the quickest and they are easier and more flexible, since exact algorithms and heuristics calculate a solution for a given period of time. If there are too much changes in this period, the schedule could become useless. The disadvantage of dispatching rules is that they are in general too simple and it will not always result in the best choices. One of its causes is that dispatching rules look only at one AGV simultaneously. It is also possible to have combinations of above list. An exact algorithm could as well calculate optimal schedules for each AGV separately. Then, the objective for trying to achieve the best QC performances changes to calculating quickest paths for each AGV. Using such algorithm would generally result in a better QC performance, though not optimal. Dispatching rules can also dispatch instructions to more than one vehicle. However, it is more difficult and revisions are then inevitable. 2.2.4 Operational control

(17)

order, this will take a few seconds. See Figure 7(a) for a flow chart.

(a) Receiving an order. (b) Claiming and driving.

Figure 7: Flow charts of the operational control of an AGV.

(18)

Figure 8: An example of a route an AGV could take to reach its destination.

Note that the description of receiving a route in above example, is a collection of simple dis-patching rules. Choosing a buffer, the rule is to get the closest to the QC available free buffer. During travelling the rule is that an AGV tries to claim a part of the route when it reaches a certain threshold. Whenever this road section is occupied the claiming fails and the AGV brakes and waits until the road section is free. AGV-MS returns the shortest route as possible, but all routes via the same buffer are equally long. That is, for the length of the route it does not matter which highway will be picked. Hence, AGV-MS returns a route dependent on start-ing location and destination. Thus, for equivalent startstart-ing location and destination types, the routing will be the same. In above example, routes from an ASC module to a buffer located more to the right, will always be done via the most upper highway. This is an example of static routing: AGV-MS always makes the same choice between two locations. An elaboration of route choices in TIMESquare is done in Section 4.3.

2.3 Literature review

(19)

After publication of that article, publications in traffic control at ACTs were very rare for a few years. However, the proposed method is not really satisfying yet. As argued in Meers-mans (2002), the proposed method is performing better than the methods used before, but the model is too simplistic. For scheduling the AGVs, which was not discussed in Evers and Koppers (1996), there is more than guiding AGVs fluently over the transfer area. Furthermore, the sequence at the QC is strict, which was not modelled in the model of Evers and Koppers (1996). Meersmans (2002) therefore suggests an integrated scheduling of AGVs with ASCs and QCs. The traffic control of AGVs was not studied in detail.

After the installation of the second ACT, scientific interest grew due to the practical relevance and the complex challenges. Publications of various overview papers followed and soon after those publications also research papers were published. For a complete introduction in container terminals see for example, Lehmann (2006), G¨unther and Kim (2006), Vis and De Koster (2003) and Meersmans and Dekker (2001). The latter introduced the use of Operations Research in container terminals. At that time, only Rotterdam had automated transport vehicles. It was noticed in Meersmans and Dekker (2001) that AGVs were not as flexible as Egbelu and Tan-choco (1984) stated, because unmanned vehicles lack the insight and experience of drivers: for AGVs is overtaking another (blocking) vehicle very complex, for manned vehicles rather easy and can be done quickly. According to Meersmans and Dekker (2001), Operations Research could do a lot of improvement in the scheduling and controlling of AGVs and other equip-ment. The work of Lehmann (2006) is a very extensive study with a mathematical approach to AGV problems at ACTs. However, the study only includes assignment of orders to AGVs and deadlocks therein. For another introduction in container terminals, including accompany-ing photographs, terminology, processes, literature review, decision problems et cetera, see the website of Vis (2008).

Stahlbock and Voß (2008b) and Steenken et al. (2004) did a research of terminal processes together with an extensive literature review for each process. The former article had a look at vehicle routing problems specifically, which was applied to a broader sphere than routing of AGVs. Also routing of other vehicles at the landside can be modelled as VRP and so can the scheduling of berth allocation and QC scheduling. According to its authors, the handling of AGV traffic is crucial for obtaining good QC performances. Suggestions for improvement were made more specific on deploying the AGVs rather than routing them. A very extensive liter-ature review is done in Stahlbock and Voß (2008a). The research publications after 2002 were focussed on several aspects of the terminal processes. Specific on traffic control there is actually only one that deals with this problem, namely Gawrilow et al. (2007), who came up with a real-time exact algorithm for CTA. Its authors were the first that succeeded in taking time as a new variable into account. The proposed method is also further discussed in Section 3.2.

3 Problem formulation

3.1 Description of the problem

(20)

delay for all of them. Another cause is that other handling equipment, like ASCs, are busier and thus an AGV has to wait longer for its container, or for unloading its container. Delays are not a problem if QCs can keep working continuously, that is the AGV is in time at the QC anyway. But if this is not the case, a QC has to wait, which means a direct performance loss for a terminal.

Figure 9: A waiting AGV for merging onto the highway.

The objective for a terminal in general is to optimize its performances, which boils down to maximizing total throughput. In order to obtain maximum throughput, the time of berth for a vessel should be as short as possible. That is, the terminal should work as efficient as possible to load and/or unload a vessel as quickly as possible. Besides, for a company it is very attractive if their vessel is as short as possible at one port. Hence, low times of berth will attract more companies, resulting in more profit. To be as efficient as possible the QCs should operate at capacity; if it is impossible to improve the performances of a QC, it is impossible to improve the performances of a terminal in the sense of maximizing total throughput; except for an extension of a terminal: more QCs, a longer quay, et cetera. Hence, maximizing the number of moves per hour of a QC is optimizing a terminal’s objective. One move is defined as loading or unloading one container. A component of obtaining the maximum number of moves per hour for a QC is that the handling of a QC should be optimized. That is, a QC should minimize inefficient moves. Another component is to make sure that all AGVs are in time at the QCs to receive or drop their container. That is, an AGV should have arrived before a QC has to wait for it. Several factors have their impact on the time of arrival of AGVs. A list of the major factors:

• claiming behaviour of AGVs; • routing of AGVs;

• scheduling of AGVs;

• duration of interchange at ASCs;

• time of assignment of the order and the position of the vehicle at that moment; • total travel distance to fulfill the order;

• number of active orders (AGVs currently executing an order).

(21)

take some time before an AGV joins the traffic. In peak hours a lot of vehicles have to merge onto the highway, which is difficult on a highly congested highway. And if it could, it causes a delay for a lot more vehicles than in regular times. Clearly, if there is a way to manage this efficiently, a better performance will be the result.

The routing of AGVs is currently done in a static way, see Section 2.2.4. This means that if a large part of the active routes is of a particular type, then the corresponding highway should absorb a lot more traffic. As a consequence, traffic jams occur on one or more areas on the transport area, while on other areas there might be hardly any vehicle. Hence, routing of vehicles could rather be managed in a different way. However, as a condition, TBA stipulated that the pattern of routing may not change. In other words, it is not possible to change the idea of using the highways, buffers or quay lanes.

It is for sure optimal to implement an exact algorithm that returns an optimal schedule for all AGVs. The question is whether such algorithm or heuristic exists. If not, scheduling will be more difficult, since dispatching rules are usually only short-term decisions and scheduling is by definition not. Additionally, scheduling is less effective without incorporating the interaction with other equipment as described in Meersmans (2002). Furthermore, Gawrilow et al. (2007) already developed a scheduling and routing algorithm and the aim of this thesis is not to redo that research.

Thus, the first three components of above list will be investigated in more detail in this thesis. An investigation to determine the bottlenecks of the AGV system is done in Section 5.1. Upon the other components in the list it is harder, or even impossible, to have influence. Therefore, those components will not be discussed further in this thesis.

3.2 Routing methods in the literature

In order to have more insight in current and previous developments in routing of AGVs at ACTs, the literature is investigated first. There were only two methods found that are focussed on routing automated vehicles. One of them is Evers and Koppers (1996). Evers and Koppers (1996) has chosen to use a decentralized model. It is impossible to have no central coordinating system, but the central system in Evers and Koppers (1996) gives only marginal instructions to the AGVs. Furthermore its authors used a zone control system. In a zone control system the transportation area is subdivided in several zones. Each zone has an internal control to control the movements within each zone and each zone communicates via an overall control to interact with neighbouring zones. Simulation studies showed an improvement by using the concept of semaphores. Semaphores are, as defined in Evers and Koppers (1996), non-negative integer-valued variables with the interpretation of free capacity. A semaphore with its roots in computer science works as follows. Let S be a semaphore. The initial value is the maximum capacity of the area (note that no vehicle is in the area). Whenever an AGV enters the area, set S := S − 1; analogously if an AGV leaves the area, set S := S + 1. AGVs are permitted to enter the system if and only if S > 0, otherwise if S = 0, that is there is no free capacity, arriving AGVs should wait. In order to avoid deadlocks, a few dispatching rules control the traffic within each zone. As Evers and Koppers (1996) concludes, this concept meant that the traffic density could be increased without having collisions and deadlocks.

(22)

approaches. First of course, Gawrilow et al. (2007) uses an exact algorithm instead of dispatch-ing rules. Secondly, a centralized control is used and finally, it schedules whole routes at once, which was not tried previously due to its complexity. What is most different is actually a con-sequence of the combination of using an exact algorithm and scheduling whole routes at once: the proposed method takes time as a new variable into account. In order to deal with practical implications, safety margins for distance and time deviations are implemented. Even re-routing is possible if the schedule will be messed up during travelling. According to Gawrilow et al. (2007), the test results were in favour of this routing system: the exact algorithm is suitable for real-time computation and this routing system is better than the benchmark of static routing. The advantages are clear: the algorithm takes collision and deadlock situations into account before the travelling of an AGV starts, the algorithm calculates the quickest path for each AGV, and travel time is known approximately. However, there are also drawbacks and shortcomings of this method. Although safety margins are built in, those safety margins also mean a loss of valuable space. Safety margins are inevitable, but the amount of space lost will depend on the risks there can be taken. Less risk means a larger safety tube around the expected arrival of an AGV at a certain position. A larger safety tube on its turn means a lower density of traffic on the transport area. When using this method, scheduling is done more in advance than when using dispatching rules. So, there is also more uncertainty about the time of arrival of an AGV at each point. Hence compared to using dispatching rules, larger safety tubes are necessary to avoid collisions. Subsequently, it is easier to increase the density of traffic with dispatching rules than with this method. If deviations from the computed schedule frequently occur, re-routing could be necessary too often, which means a loss of some of the advantages: such as calculating the travel times and thus the expected arrival time. However, the advantage over static routing remains that with re-routing a new route could be quicker, where an AGV in a static routing approach would continue its way with maybe more or new conflict situations. An improvement of this algorithm would be if it does not calculate a quickest path for each AGV separately, but rather an optimal schedule for all AGVs simultaneously. The basis of this method, as all current methods, is thus still first-come-first-served. While in calculating optimal schedules for all AGVs simultaneously, urgent orders will get more priority and thus arrive earlier at their destination. The proposed method by Gawrilow et al. (2007) is for sure an improvement, although practical results are not available yet, since CTA still has to decide whether the algorithm will be implemented. The question is whether there exists an exact al-gorithm that could take actions of other vehicles more into account, in particular those vehicles that still have to depart.

3.3 Research direction

In the previous sections the focus of this thesis has been mentioned briefly. To summarize, this thesis will try to improve the scheduling and routing of AGVs by changing the routing and claiming behaviour as described in Section 3.1. Questions that should be answered to reach improvement are:

• What are the bottlenecks in the current model? That is, what is exactly the problem? • What is the impact of a highly congested traffic area?

• Can we find an exact algorithm for routing all AGVs as efficient as possible? • If not, applying which dispatching rules will result in better QC performances?

(23)

which will be described in the next section. Finally, the results are given and recommendations are presented. But before continuing the problem is demarcated.

3.3.1 Demarcation and assumptions

We will consider an AGV system that uses a centralized traffic control system. In this way, we can keep track of information of all movements, planned movements and orders of all AGVs simultaneously. This implies that we have more information and thus we are probably able to dispatch better instructions to the vehicles. The intended solutions will be implemented in TIMESquare and tested by means of simulation. As a benchmark, we will consider the current version of TIMESquare. As mentioned before, when there is not a lot of traffic on the waterside transport area of a terminal, performances are good. In order to get a clear picture of what the impact of congestion and our solutions is, we assume that all other equipment works fine. If even then AGVs are not the bottleneck of the terminal equipment, it will never be and research can better focus on other areas. Moreover, we assume only a highly congested traffic area. In other words, we only simulate the peak hours.

4 Simulation modelling

In Saanen (2004) an extensive study to the design of ACTs was done. To this end, its author used simulation techniques to test his design. As argued in his thesis, he used simulation since this powerful tool could help in all of the following stages of his study:

• Functional design; determination of the problem, the objectives and the purpose of the project and the type of system that has to be implemented.

• Technical design; how to implement the functional design specifications. • Implementation; the development and building of the system.

• Commissioning/operations; the testing, use and evaluation of the developed system. In this way, he only needed one simulation design model for the whole process. Our study comprehends the second item in above list and successful solutions could be implemented in software design and put into operation. A more important reason for us stated in Saanen (2004), is that most of the processes at an ACT are too complex and too large for (known) mathematical models. While a simulation model can easily be extended and processes can more easily be implemented, since in a simulation model, the dynamics of the processes can explicitly be taken into account.

4.1 Mathematical model

According to Saanen (2004), known mathematical models which can be solved exact, cannot capture all stochastic events at an ACT. To check if this is true for our specific problem, the routing of vehicles, we will set up a mathematical formulation of our problem. The overall objective is that the QCs execute as much moves per hour as possible. Or equivalently, maxi-mizing Qqh, the number of moves in hour h at QC q. Within nh ∈ N hours and using nqc∈ N

(24)

The moves per hour Q can be calculated as follows: Qqh(N ) = N X i=1 Iqi(h, t) q = 1, . . . , nqc, h = 1, . . . , nh, with, Iqi(h, t) =

1 if QC q finished its order i at time t ∈ [h − 1, h), 0 else.

The maximum number of moves per hour that can be obtained depends on several factors. Firstly, each move costs the QC a certain amount of time, which is not fixed for each container. The duration of handling order i at QC q is denoted by DU Rqi. Secondly, we have the waiting

time on late orders. The arrival time of order i at QC q is expressed as: ARRqi. The waiting

time can then be expressed as: Wqi = ARRqi− (ARRq(i−1)+ DU Rq(i−1)). Note that the AGV

cannot arrive earlier at the QC than the end time of the previous order. Hence, the time QC q finished its order i can be expressed as:

tqi = i X j1=1 DU Rqj1 + i X j2=1 Wqj2 = DU Rqi+ ARRqi.

Specific to our problem, we would like to have all AGVs arriving in time at the QC. That is we would like to minimize late orders by changing the routing schedules. Our decision variable, x, represents such schedule in which AGVs are instructed how and when to go where. We define an order as late if the QC has finished its previous order and the order is not arrived yet. Hence,

min x nqc X q=1 N X i=1 Lqi(x), with, Lqi(x) = 1 if ARRqi(x) > tq(i−1)(x), ∀q, i, 0 else.

It is also possible to minimize the time that orders are too late, which is in fact minimizing the idle time of the QCs:

min x nqc X q=1 N X i=1 Wqi(x).

Regardless of the minimization problem, the arrival time of orders should be calculated. The time an order arrives, depends on several factors. For load orders, the order is subdivided in two stages: a vehicle first has to drive to the container’s pick-up location, say l and secondly it conveys the container to its destination location, say m. This costs time: T Tqi, the travel time

for order i of qc q. Another factor is the start time of order i (STqi). An AGV receives an order

i, when the AGV has finished its previous order i−∈ N ∪ {0} at q−∈ {0, 1, . . . , n_qc}. So, i− and q−are the direct predecessors of i and q. If there are no predecessors, i−and q−are set to zero. A third factor is the interchange time at an ASC module, say at location a: ITqi(a). The last

factor is the total waiting time, W T Tqi: the sum of several waiting times (W Tqi(·)) at several

(25)

is a bit different. The second stage of the travel order does not affect the time of arrival at the QC. Analogously, the interchange time and the waiting time at an ASC module do neither. The start time of the next order of the AGV is only later: the AGV should travel first to its destination and wait until the ASC has lift up the container. To distinguish between unload and load orders: let Uqi be the indicator variable that equals one if order i at QC q is an unload

order and zero if it is not. To summarize, we have with start location k, pick-up location l and delivery location m, for all q and i:

ARRiq(·) = STqi(·) + T Tqi(·) + (1 − Uqi) · ITqi(·) + W T Tqi(·), (1) STqi(x, l, m) =    ARRq−_i−(x, k−, l−, m−) + DU R_q−_i− +U_q−_i−· (y_l−_m−(x) + W T_q−_i−(x, m−) + IT_q−_i−(m−)) if i−6= 0, 0 if i−= 0, (2) T Tqi(x, k, l, m) = ykl(x) + (1 − Uqi) · ylm(x), (3) W T Tqi(x, l, m) = W Tqi(x, l) + (1 − Uqi) · W Tqi(x, m). (4)

Locations k−, l− and m− are the start, pick-up and delivery locations of the predecessor of order i at QC q. yab is the time it averagely costs to drive from location a to b. However, an

AGV conveying this container will be delayed by congestion, which is caused by other vehicles travelling on the same area at the same time as this AGV. Thus, yab is written as:

yab(x) = T imeDistab+ nA

X

j=1

δj(x, a, b) + ϕqi,

with T imeDistab the time needed to travel from location a to b without any kind of delay,

δj(x, a, b) the amount of delay caused by AGV j during the travelling from a to b and ϕqi a

random disturbance factor for order i at QC q. Finally, nAis the number of AGVs.

The only restrictions in this model are that an AGV can only perform one order at the time and so can a QC and ASC. The restriction with respect to the AGV is already included in the definition of its start time STqi: the AGV can not start earlier than its previous order is

finished. Thus for the QC we have,

tq(i−1) < tqi− DU Rqi, ∀q, i > 1.

For the ASC, we have to define new variables. Let i− ∈ N ∪ {0} be the previous order of the

ASC, which has destination or had pick-up location QC q− ∈ {0, 1, . . . , nqc}. Both i− and q−

are zero if the current order i at QC q is the first order of this ASC module. Then, the moment the interchange at an ASC is finished, ICqi of order i belonging to QC q, is restricted to:

ICqi− ITqi > ICq−i−, ∀q, i.

The stochasticity in this model is by their definition present in DU Rqiand T Tqi(x), for all q and

i. As a consequence, tqi(x) and ARRqi(x) are stochastic as well and thus also STqi(x). Since the

arrivals of the AGVs at a stack module are also stochastic, ICqi is it too. Pure analytically this

will not be solvable. Taking only expectations of the random variables DU Rqi and ϕqi into

(26)

solution for this part, however, it also affects equations (1)–(4). And, moreover, the effect for all q and i simultaneously is less clear.

Another direction of research can be stochastic modelling, as described in Klein Haneveld and Van der Vlerk (2006). However, the model above seems to be too complex for the described models in Klein Haneveld and Van der Vlerk (2006) as well.

4.2 The simulation model

Analytically, the problem will thus not be solved, hence the proposed solutions will be tested in a simulation model. At TBA, the simulation model is built into the commercial software package eM-Plant. A general image of (a part of) the model is depicted in Figure 10.

Figure 10: Image of a part of the used simulation model in the software package eM-Plant.

eM-Plant applies discrete event simulation. The events are generated by means of methods, which are stored in the Eventlist. eM-Plant will call the methods in the Eventlist chronologi-cally. Once a method is called, it executes the code it contains, which consists of instructions for equipment or events that take place. The code can also consist of calling another method. Other methods can be called either directly or indirectly. Indirect calling occurs when a method puts another method in the Eventlist. eM-Plant will call this method later, thus if the prescribed time has elapsed. Direct calling means that when a method calls another method it will first run through the called method. When it finished this method, eM-Plant returns to the call-ing method and finally it will return to the Eventlist. Usually, eM-Plant uses object oriented modeling. However, TIMESquare only uses graphical representations of objects and methods ‘move’ these ‘objects’ by changing their x- and y-coordinates.

(27)

TIMESquare is a very detailed model. In order to study all types of processes at an ACT, all kind of processes are implemented. For example, the detailed level with respect to the AGVs has already been described in Section 2.2.4. Other processes are for example the landside trans-port and the operation of a QC or ASC. As a consequence of the detailed model, the simulation model is not very fast. Using the configuration that will be described in Section 4.3, eight hours of simulation will take about three to three and a half hours real time. Implementing the solutions, we thus have to take care of efficient programming.

4.2.1 Validation and verification

The model TIMESquare has been built in several years and in these years several experts in port technology have had a thorough look at it. Of course, a model is by definition a simplified representation of reality, hence the model omits certain components. However, as mentioned before, our aim is to test our solution concepts in peak hours. Therefore, breakdowns of any equipment, moving of QCs to another position, shifts of QC personnel et cetera, are not relevant to take into account. Not even the breakdowns of AGVs: it will not influence the performance of each solution concept, since all concepts and the benchmark model will solve the situation the same. The functioning of the simulated AGVs is similar to real AGVs, although they are faster. Since the AGVs in the simulation model are faster on the position they are instructed to be, while real AGVs do need some time to be exactly on that position. The uncertainty concerning the travel time of an AGV is not taken along in the simulation model. If dispatching rules are applied this is not really a problem: AGVs can then react every split second. However, if an scheduling algorithm would be developed, that computes a schedule for a given period of time, then it does matter, since AGVs in the simulation model would do exactly as has been scheduled, which is not the case in reality.

The duration of QC handling is variable in reality. In TIMESquare, this is simulated by means of a random variable. The average time a QC needs to perform one move is set to 90 seconds. This means a QC is able to perform on average 40 moves per hour (mvph). Technically, cranes are currently able to perform 55–60 mvph. However, real data show only 22–30 mvph, see Stahlbock and Voß (2008b). But in fact, in our study, it is not of a big importance whether the durations are similar to the real durations. The only important factor is that they are not constant and that they are consistent. We assumed TIMESquare did this correctly, since evidence to the contrary was not observed.

4.2.2 Preventing deadlock situations

(28)

Figure 11: Example of a deadlock, although the non-stop claiming strategy has been applied.

In TIMESquare such situations are solved by sending the vehicles over particular highways dependent on the origin and destination of the vehicle. In this way, situations as depicted in Figure 11 could be avoided: vehicles turning upwards may only use the upper three highways and vehicles turning downwards only the lower three. However, the model is then more restricted: the routing will be static.

4.3 The benchmark model

The current version of TIMESquare will be the Benchmark model. TIMESquare assumes static routing, using six highway lanes. See Table 2 for a complete list of the choices the AGV-MS in TIMESquare makes whenever an AGV requests a route. Note that each highway only allows traffic to either the right or the left.

From: To: Direction: Via: Buffer Buffer right Highway 1 Buffer Buffer left Highway 2 Buffer Stack right Highway 3 Buffer Stack left Highway 4 Stack Stack right Highway 5 Stack Stack left Highway 6 Stack Buffer right Highway 1 Stack Buffer left Highway 2 Table 2: The highway choices using static routing.

Other essential settings in the Benchmark model are the dispatching rules concerning claiming and the choice of a buffer. As explained in Section 2.2.4, AGV-MS in TIMESquare returns the nearest to the AGV’s destination, available buffer. Concerning the claiming of AGVs, the rule is first-come-first-served.

4.4 Experimental design

(29)

as the AGV enters a buffer, it requests permission to approach the QC. It will get permission from AGV-MS if this AGV is the next in sequence and the TP beneath the QC is free. If serial buffering is applied the AGV will also get permission if there is space behind this TP, although the TP itself may be occupied. In this way, AGVs enqueue behind the TP. The maximum length of a queue depends on the position of the corresponding QC. The closer the QC is to the available buffers, the smaller the maximum length of the queue. As an example, consider a lay out as depicted in Figure 8 on page 18. In this case, QC1 has the smallest maximum queue length and QC4 the largest. If there is no place available or the AGV is not the next in line, the AGV will wait in a buffer. Using this strategy implies that each QC needs its own lane: therefore there are five quay lanes. Since each cluster works independent of other clusters, it is not necessary to have twelve quay lanes.

In real-life situations, it is possible that vessels do not moor on their initial planned posi-tion. Consequently, containers are not situated directly across the vessel. Another consequence is that other vessels, that still have to arrive, should be relocated as well. See Figure 12 for an example of wrongly located vessels. Here, Vessel 3 has to get their containers mainly from the grey shaded stack area. Vessel 1 should obtain their containers from the dotted stack area and Vessel 2 from the white stack area.

Figure 12: An example of vessels who are relocated due to a wrong mooring.

(30)

There are 40 RMGs on the waterside and 40 RMGs on the landside. Hence, there are 40 stack modules with two RMGs each. Considering the situation of wrongly moored vessels in above example, the situation in our simulation is similar. Sixteen RMGs at the right of the terminal provide containers for a cluster of five QCs situated in the middle of the terminal. Seven RMGs in the middle provide containers for the cluster of two QCs at the left of the terminal. Finally, the other seventeen RMGs at the left provide the cluster of five QCs at the right side. See also Figure 12, note that in this case the grey shaded area actually consists of seventeen stack modules, the dotted area of seven and white stack area of sixteen stack modules. AGVs with an order to grab a container at a QC can be dispatched to any stack module. Unloading operations are thus not restricted by locating the container in a stack module.

To complete the list of equipment, 84 AGVs are considered. Also the landside of the terminal is simulated by TIMESquare, but a steady operation on this side of the terminal is assumed. It is not possible to omit the landside, since if one of the RMGs at either the landside or the waterside has temporary no order, it could help the other RMG with housekeeping moves. This will affect the performance of the RMG at the waterside of the terminal and thus the AGV’s waiting time in front of this RMG.

A summary of the used equipment and specifications of other parameters is given in Table 3.

Object: Amount: AGVs 84 QCs 12 Quay lanes 5 TPs per QC 1 RMGs 80 Stack modules 40 TPs per RMG 4

Table 3: Summary of the parameter specification.

4.4.1 Warm-up period

Before a simulation run could start, the length of the warm-up period should be determined. The initial position of AGVs is a position on a random TP at a stack module. Unloading QCs can directly dispose of some AGVs, however loading QCs should wait for RMGs that first have to drop the container upon an AGV. Hence, a warm-up period makes sense. To determine the length, 30 replications were made in TIMESquare using the above described configuration. In Figure 13(a) the results are shown. The exact data can be found in Appendix A, Table 24. What can be seen is that the average number of performed moves per QC in the first half hour is much lower than in the second. In order to show significance, a 95% confidence bound around the averages is constructed. The average of the first half hour is X = 14.43, the average of all other half hours is µ = 16.88. If no warm-up period would be necessary, we would expect that E(X − µ) = 0. To test whether this is correct, we have:

X − µ

(31)

(a) Moves per half hour (b) Moves per hour

Figure 13: Graphs of the average moves per half hour (left) and per hour (right), which are measured per QC and over 30 replications.

with n the number of replications, S2 the sample variance and with tn−1(·) the cumulative

density function of a t-distribution with n−1 degrees of freedom. The sample standard deviation of the first half hour is 0.95 (see Table 24). We get as confidence bound around µ, with significance level α: X − tn−1(α/2) · S/ √ n , X + tn−1(α/2) · S/ √ n . Substituting, we get for n = 30 and α = 0.05:

14.43 − t29(0.05) · 0.95/ √ 30 , 14.43 + t29(0.05) · 0.95/ √ 30 , [14.43 − 2.05 · 0.17 , 14.43 + 2.05 · 0.17] , [14.43 − 2.05 · 0.17 , 14.43 + 2.05 · 0.17] , [14.08 , 14.79] ,

which does not contain µ = 16.88. Hence, the difference between the two sample means is significant. And indeed, the corresponding t-statistic (5) is:

14.43 − 16.88

0.95/√30 = −14.12,

resulting in a p-value of 0.0000, which is lower than α and thus significant. The confidence bounds around the average moves per half hour are depicted in Figure 13(a). The confidence bound of the first half hour is completely outside all other confidence bounds. The third half hour is not completely outside all other confidence bounds, that means, the third half hour is not significantly lower than the other half hours, although this value seems to be too low as well. To ensure that the third half hour does not affect the average too much, we also had a look at the average moves per hour, see Figure 13(b). Then, the first hour is lower again, due to the low performance in the first half hour, but the second hour does not seem to be different from the other hours. Hence, a warm-up period of 30 minutes is chosen to be sufficient. 4.4.2 Run length

(32)

Appendix A, Table 25. The default setting in TIMESquare is seven hours of simulation after the warm-up period. In Figure 14 it could be seen that the cumulative average is hardly varying after one hour. Therefore, we see no reason to change the default setting.

Figure 14: Cumulative averages per half hour per QC over 30 replications.

4.4.3 Number of replications

The number of replications per experiment should be determined as well, in order to average out the random factors as the interchange time and the load and unload plans. For that purpose, the average moves per QC per simulation run were cumulated in Figure 15, see also Appendix A, Table 26. After fifteen replications the number of performed moves by each QC was per replication approximately 235.9, which is close to the long run (30 replications) average of 236.3. Note that the standard error is fluctuating around 3.2 after replication fifteen. After eight replications the cumulative average is not far from the long run average as well, but a bad performance like in replication eleven, had quite some impact on the cumulative average. These fluctuations should be averaged out, so that we are for, say 95%, sure that the outcome is within a certain bound. Since we expect only an increase in the performance by implementing the solution concepts, we performed a one-sided test. In Law and Kelton (2000) the following test is recommended: the number of replications required n∗_α(β) for a maximum accepted absolute error of β is, based on n replications with sample variance S2(n),

n∗_α(β) = min ( i ≥ n : ti−1(1 − α) r S2_(n) i ≤ β ) , (6)

with ti−1(1 − α) a t-distribution with i − 1 degrees of freedom and probability level 1 − α. For an

absolute error of 1.5, based on n = 3 replications, we could conclude that fourteen replications is enough (see Table 27 in Appendix A). However, based on n = 14 replications, the test shows that i = 15 is enough to obtain an absolute error of less than or equal to 1.5. Based on n = 15, the test indeed shows that i = 15 is enough. The sample standard deviations S(n) after each replication n can be found in Table 26, Appendix A. Hence, it is for 95% certain that one QC in an experiment of fifteen replications would not do more than 1.5 moves than the average of µ = 235.9. Therefore, fifteen experiments is chosen to be sufficient to average out the fluctuations.

(33)

Figure 15: Cumulative average of performed moves per QC over 30 replications.

than in the Benchmark model. In Table 4, ti−1(1 − α)

q

S2_(n)

i is given for these experiments on

the basis of a one-sided test with a 95% confidence level. Note that i = 15 and n = 15. Hence, we can conclude that fifteen replications for other experiment settings is sufficient as well.

Model t14(0.01) q S2₍₁₅₎ 15 Benchmark 1.43 Density 1.17 Order 1.18 PriorityRules 1.37 SwapBuffer 1.18

Table 4: The expected maximum absolute error for different experiments.

5 Solutions

(34)

5.1 Analysis of the current situation

In order to formulate simple, but clear rules that would be most effective, there should be a clear picture about what is important. Therefore an analysis is done on the basis of the simulation model used at TBA, see the Benchmark model in Section 4.3. The most important statistics can be found in Appendix A, Table 28. At first glance, it is notable that the AGVs are hardly without orders. Apparently, we succeeded in creating peak hours. The performance of a QC is on average 33.7 mvph, which is 84% of what is technically possible in TIMESquare. Having a closer look at the performances of an AGV, it seems that an AGV spends a lot of time in waiting for claim, namely 14.6%. Hereby, we note that an AGV should stand completely still in order to get this status. The question is then where AGVs stand still and for how long. From Table 28 (Appendix A) we see that half of the delays occur on the highway (49.2%). However, being a bit more specific, Table 5 and Table 6 below show more detail. Fortunately, the long durations of over one minute waiting occur mostly not on the highway. Those are in 70% of the cases just a few seconds. Merging onto the highway seems to be more problematic: the longer durations occur more often at these waiting locations. Particularly, AGVs situated in the buffer have to wait in almost 10% of the cases for more than one minute and two-thirds of all waitings above one minute are AGVs that are trying to merge onto the highway from a buffer location. However, those AGVs are mostly not going to a QC, which thus does not affect directly the performances of the QCs. Another conclusion that can be drawn from Table 28 is that the traffic over the highways is not equally distributed. About two-third of total traffic is travelling to the right and more than half of the AGVs travel over the first and third highway. The best five buffers, that is for each large QC cluster, the five buffers that are closest to the QCs, are only used in 46% of all cases. For the small cluster of two QCs, the best two buffers are taken into account.

Duration: Buffer, upwards Buffer, downwards RMG Highway

0–10 sec. 8.3% 24.7% 10.8% 56.3% 10–20 sec. 20.4% 18.4% 6.8% 54.4% 20–30 sec. 26.1% 27.2% 10.2% 36.5% 30–40 sec. 24.3% 43.0% 13.7% 19.0% 40–50 sec. 28.2% 53.2% 12.0% 6.6% 50–60 sec. 26.6% 55.6% 14.3% 3.5% ≥60 sec. 20.2% 66.4% 11.5% 1.8%

Table 5: Distribution of waiting locations in percentage per duration class.

Duration: Buffer, upwards Buffer, downwards RMG Highway

0–10 sec. 36.6% 56.2% 65.1% 69.8% 10–20 sec. 30.2% 14.0% 13.6% 22.6% 20–30 sec. 14.6% 7.9% 7.8% 5.7% 30–40 sec. 6.2% 5.6% 4.8% 1.4% 40–50 sec. 4.2% 4.1% 2.4% 0.3% 50–60 sec. 2.6% 2.8% 1.9% 0.1% ≥60 sec. 5.6% 9.4% 4.3% 0.1%

(35)

In order to see whether there is room for improvement, the most important statistic is the idle time of a QC. In the Benchmark model a QC is waiting 10.8% of its time. It seems that there is some room for improvement. To test this, we made an Upperbound model. In the Upperbound model we assume that there is no congestion on the waterside area of the terminal. As a consequence, AGVs always receive their claim immediately, regardless of the proximity of other AGVs. AGVs thus can always accelerate to full speed and continue this speed until the next curve, which can be taken in maximum speed that is allowed in curves. In the Upperbound model are further the same strategies assumed as in the Benchmark model described in Section 4.3. However, claiming strategies as first-come-first-serve are irrelevant: the claim will be given anyway. Analogously, the strategy of static routing is also irrelevant: the shortest path is chosen, which is also the quickest path, since there is no congestion which could delay the AGVs. Hence, considering only routing and scheduling strategies, it is not possible to do better than the Upperbound model. The results of this model are shown in Table 29 in Appendix C. The QC performance is 36.0 mvph, which is an improvement of 6.8%. The idle time is reduced to 4.7%. Apparentely, with this setup of the terminal it is neither possible to approximate the technical possible performances of 40 mvph, nor it is possible to reduce the waiting time to zero. For some orders the RMGs are a new bottleneck: the AGV’s waiting time for interchange is doubled, although the waiting time for an RMG is relatively reduced. For other orders the reason is that assignment is done too late: due to the larger travel distance, the model should actually assign AGVs earlier. However, earlier assignment is not possible, since the idle time of AGVs with respect to orders is still zero. Hence, an extension of the AGV fleet is required, then RMGs can be assigned earlier as well (which is done at the moment an AGV receives an order), so that the waiting time of RMGs for vehicles can be reduced as well. Hence, if we want to improve the performance even further another look at the performance of the RMGs is necessary and secondly, a part of the problem might be solved by an extension of the AGV fleet. The waiting time for interchange at a QC is, not surprisingly, dramatically increased, hence AGVs are more often in time. Neither surprising is the increment of the average speed of the vehicles: from 2.4 m/s to 3.5 m/s. A little bit surprising is that the number of full speed durations has not been increased, they only last longer than in the Benchmark model.

5.2 Solution concepts

In the previous section we noticed the following problems with respect to AGVs and AGV routing in the Benchmark model:

• difficult merging onto a highway;

• an AGV makes many stops on a highway; • bad distribution of traffic over the highways; • low usage of the best buffers;

• QC is waiting too long for vehicles due to congestion problems.

(36)

first-come-first-serve principle as described in Section 2.2.3. However, the most urgent orders are the most critical: thus, if the travel time on those orders can be shortened somehow, then the AGVs are more likely to arrive in time. Instead of first-come-first-serve, we rather see a ‘most-urgent-first-serve’ policy. Hence, the vehicles with the most urgent orders should get priority over vehicles with less urgent orders. The problem of low buffer usage should be tackled as well. Due to static routing, the buffers are claimed before an AGV starts travelling. In this way, if too many AGVs are travelling, newly assigned AGVs will receive buffers that are further away from their final destination: the QC. If the assignment would be done dynamically, then the AGVs could claim buffers that have become available in the meantime, which will consequently save travel distance. Summarizing, we want to tackle above problems using the following three solution concepts:

1. dynamic highway picking; 2. using priority rules;

3. dynamic assignment of buffers.

Each solution concept and its implementation in TIMESquare will be elaborated in more detail in the upcoming sections. Further, we will test each solution concept separately in order to measure its own effect.

5.2.1 Dynamic highway picking

The aim of dynamic highway picking is a better utilization of the available space. As the Benchmark model showed, the first and third highway are far more used than the other high-ways: nearly 52% of the traffic uses one-third of the available highways. A better distribution should expectingly result in a better circulation of traffic: AGVs are likely to drive faster and have less delays on the highway, because there are less AGVs driving in front of him that could affect his speed. Furthermore, merging and leaving the highway can be done faster as well: blocking AGVs on the highway will travel faster and thus the claiming section is earlier avail-able. As a result of the better circulation, we would expect that AGVs arrive earlier at their destination, thus the QC performances should increase.

The best distribution of AGVs over the available space would be the following dispatching rule:

Dispatching rule 1 Assign AGV to the least occupied highway section at this moment and bounded by the area the AGV needs to travel horizontally.

(37)

be waiting for a long time. Furthermore, AGVs with a route from buffer to buffer or from an RMG to another RMG are preferably on the highest and lowest highway respectively. Those requirements will also have its impact on the distribution of vehicles over the transport area. We will refer to this model as the Two-way track model. The corresponding dispatching rule reads as follows:

Dispatching rule 2 Assign AGV to a highway so that the AGV’s travel distance is minimized. If not possible, or if several highways result in equally long routes, assign AGV to the highway that is least occupied, and which is not in conflict with the current direction of the intended part of the highway. Give a penalty to those highways that result in a longer route for the AGV. Considering the second option, it is possible to distribute the AGVs over these highways, so that the dispatching rule is taking the restrictions of Section 4.2.2 into account. However, the possi-bility of two-way tracking should be dropped. We considered three different methods to choose the best highway and we considered three different designs for the direction of the highways. Due to the restrictions, the highway choices for traffic from the stack to the buffer are restricted to the upper three highways. Analogously for traffic from the buffer to the stack, the choices are restricted to the lower three highways. However, it is possible to apply a small trick. Either one of the middle lanes can also be assigned by the other type of routes. Then, it is still not possible to obtain situations like depicted in Figure 11 on page 28. We decided to allow both route types on highway 3, because there is more traffic travelling to the right. Hence, it seemed to us more useful to have more possibilities to differentiate in the highway choices in this direction. The first method is to base the highway choice on the density of the highways: the Density model. This is the most obvious choice in trying to distribute the traffic over the highways as equal as possible. The possibilities are listed in Table 7, which result in the following rule: Dispatching rule 3 Assign AGV to a highway so that the AGV’s travel distance is minimized, except for RMG to RMG routes to the right that are longer than 56.8 metres and buffer to buffer routes to the left. If the type of AGV’s route is one of the latter two, assign AGV to the second best choice. If several highways result in equally long routes, pick the highway that is least occupied, restricted to choices given in Table 7.

The 56.8 metres exactly equals the length of two stack modules. However, it might be that this rule is not the best choice, since a real equal distribution cannot be made due to the deadlock restrictions. Therefore, another suggestion is to distribute traffic on the basis of the demand of the QCs: the Order model. See Table 8 for the highway choices. We get the following dispatching rule:

Improving the Traﬃc Performance of Automated Guided Vehicles at Automated Container Terminals

Improving the Traffic Performance of Automated Guided

Vehicles at Automated Container Terminals

Abstract

Contents

1

Introduction

2

Introduction to automated container terminals

3

Problem formulation

4

Simulation modelling

5

Solutions