A simulation model for automated container terminals
A SIMULATION MODEL FOR AUTOMATED CONTAINER TERMINALS
Mark B. Duinkerken and Jaap A. Ottjes,
Sub Faculty of Mechanical Engineering and Marine Technology, Fac. OCP
Delft University of Technology
Mekelweg 2, 2628 CD Delft, the Netherlands
e-mail: M.B.Duinkerken@wbmt.tudelft.nl, J.A.Ottjes@wbmt.tudelft.nl
Keywords
Automatic control, Control systems, Discrete simulation, Transportation.
Abstract
In order to accommodate the growing intercontinental container transport, port facilities have to be up-scaled drastically. The challenge is to develop facilities that can handle a new generation of ships, the jumbo container vessels, with a capacity of 8,000 TEU (Twenty-foot Equivalent Unit) or more. The total in-port time to serve these jumbos is set at 24 hours. This amounts to almost double the loading/unloading flows that can be achieved at present. These flows cannot be met by the present quay transport. In this study the modeling of a quay transport system which is carried out by automated guided vehicles (AGVs) is described. The model is applied to the current Delta Sealand container terminal (DSL) of ECT Rotterdam to obtain some degree of reference.
The developed model is used for extensive validation experiments and experiments to determine the sensitivity concerning a number of parameters like number of AGVs, maximum AGV speed, crane capacity and stack capacity. It can be concluded that the performance of the simulated model matches the performance of the actual terminal. Therefore, the model is suited for future research.
Model design
Description of the simulation model
The development of the model is based on TRACES, a routing and traffic control system reported earlier [Evers 1999-1, Duinkerken 1999]. TRACES uses so-called scripts to define all possible routings, while physical safety is guaranteed using semaphores [Dijkstra 1968, Ben-Ari 1990, Sommerhalder 1996]. Using the TRACES software as a basis, a complete terminal simulation model is build. This model contains the main objects for a container terminal, namely quay cranes, stacking cranes, automated guided vehicles, containers and the layout of the terminal.
Additionally, a system of order allocation and AGV-control has been developed and built into the model. These planning and control algorithms are based on the “pull” mechanism and the reduction of the complexity by uncoupling processes developed in a separate research project [Evers 1999-2]. Layout
The layout of the DSL terminal is shown in Figure 1. This information was supplied by ECT. It includes 7 quay-cranes (QCs), 32 automatic stacking cranes (ASCs), a stack for empty containers, and the current routing of the AGVs. On this terminal a maximum of 50 AGVs is in operation.
DSL
Figure 1Layout of the DSL terminal at the Maasvlakte
Rotterdam
The traffic between stack and quay follows a circular pattern. Typically, the vehicles travel along the entire length of the ship and turn back along the stack. In the quay area a fixed traffic lane is reserved for each quay crane. In the stack-area the traffic for two quay-cranes is combined to form a single traffic lane.
Stack and Automatic Stacking Cranes
A stack is used for storage of containers. Containers are transported between ship and stack by AGVs. Placing of containers in the stack, and retrieving the containers is done by automatic stacking cranes (ASCs). The stack itself is not simulated, but the 27 ASCs are. The interaction of the ASCs with the AGVs is simulated with regard to the location of the transfer point at the stack. There are four transfer-points for each ASC. These transfer-points can also be used by empty AGVs for parking.
The processes of loading and unloading AGVs by ASCs are simulated by taking ASC cycle times from a distribution given by the user. Because the emphasis in this research is placed on the determination of the performance of the quay transport system, a considerably greater capacity has been chosen for the stack system (all ASCs together) than the average QC loading/unloading capacity (all QCs together). In most cases the average movetime of an ASC is 180 seconds, from which 30 seconds is needed for the handling of the AGV itself.
To make allowance for the effect of correcting container orientation (doors) a slotting movement is simulated for an adjustable fraction of all containers leaving the stack (to be loaded). Which containers this involves is determined with the aid of a random draw.
Quay and quay cranes
The QCs stand in fixed positions on the quay so the travelling of the quay cranes along the quay is not simulated. This leads to a fixed length of the maximum waiting queue for the QCs. It is very well possible in TRACES to add the QC movements along the quay.
The process of loading and unloading AGVs by quay cranes is simulated by taking a handling time from a user defined distribution function. For this study, the QC-cycletimes as measured in the actual operation at the DSL-terminal are used. The average cycletime is 65,9 seconds. On top of this cycletime, there is a chance of 1% for failure of the crane. The average duration of a failure is 330 seconds, and the distribution function is also taken from the existing operation. In each cycle of the quaycrane, the AGV handling time is a fixed portion (30 seconds) of the total cycle time.
As consequence of using the distribution functions, the QC cycle times are not correlated, contrary to the actual situation. Because, in principle, it is also possible to read container data of a real ship from a file as input, in principle, it is also possible to measure the effect of the lack of correlation. Vehicles
Automated Guided Vehicles are used for the transport of containers from stack to quay, and vice versa. The maximum number of AGVs is user defined. The travelling speed of both loaded and unloaded AGVs is 3 m/s, although this can be adjusted by the user too. Furthermore, default the acceleration is 0.5 m/s2, and deceleration is -0.5 m/s2.
The movement of vehicles is modeled with a constant travelling speed. During the movement along a corridor there is no acceleration or braking. Part of this effect is compensated as follows. At the moment that an AGV has to stop because a permission to enter the next section is not granted, the vehicle immediately stops. The vehicle then remains passive for the duration of the remaining braking time. At the moment the driving permission is obtained the vehicle remains stationary for the duration of the acceleration time and then moves away at a constant speed.
The effect of this simplification will be that the measured performance is a little too optimistic. The reason for this modeling lies in the fact that in this first implementation of TRACES, the script-processes and the travelling processes are linked. In the newer versions of TRACES these are two different processes, in which information is transmitted with the aid of NEAR and PASSED events. Future research will therefore be more accurate.
Ships and containers
The ships themselves are not simulated. The quay cranes are the first link in the simulation. It is possible to simulate a specific ship by using a list of the handling times for containers as input. One large ship is simulated at a fixed position on the quay.
Four cranes are used to handle one ship. Thus the disturbing AGV traffic for other ships is not included. Moreover, the
autonomous traffic between the stacks themselves is not included. However, there is stack-to-stack AGV-traffic as a result from planning the AGV jobs.
At the start of a simulation run, a random generator generates a joblist for each quaycrane. The user can specify the number of batches, the number of unloadjobs and the number of loadjobs in a batch. Each job represents a container, to be unloaded from or loaded onto a ship. For each container, a stackposition is randomly drawn to determine the origin (load) or destination (unload) for that container. Each stackposition corresponds with only one stacking crane.
The number of batches determines the number of times the quaycrane has to switch from unloading to loading, and from loading to unloading. An unloadbatch has to be completed before the quaycrane can start loading, and vice versa. Each loadcontainer has an unique number which determines the loading sequence according to the loadplan.
Beside the randomgenerator, it is also possible to read the containers from a file. These files, one for each quaycrane, are the output of the normship generator, described in [Ottjes 1999]. This generator can create complete shiploads of containers with realistic stackpositions for the containers, quaycrane cycletimes that are correlated with the container position in the ship and batchsizes that matches the baysizes of a ship. The normship generator output also contains the duration's for handling hatch-covers and repositioning the quaycranes on the quay. With the randomly generated joblist, these times are not taken into account.
Planning and control
Order allocation
The order allocation procedure is based on the system “SERVICES” [Evers 1999-2]. Orders for the collection of new containers are carried out if the expected queue for a specific time ahead becomes smaller than a minimum value. The number of AGVs in the queue for this future period is calculated on the basis of the anticipated production of the quay crane, the current number of waiting AGVs and the expected number of arriving AGVs.
Each quay crane has a list of containers [1..N] that must be loaded. The ASC of origin for each container is known. At the moment that deltaT has elapsed since the previous plan, a new plan is made. For each container three values are calculated :?PlanTime quaycrane starts loading ?StartTravelTime AGV has leaves the stack ?StartMoveTime stackcrane starts retrieving The PlanTime is calculated as follows. First the moment in time is calculated when the current move of the quaycrane will finish. This expectation is based on the starttime of the current move and the average movetime for that crane. At that moment the next CL containers of the loading list are planned, where CL is the required, user defined level of workload for that crane. The containers following the CL st container in the loading list are planned at fixed intervals, being the average QC-movetime.
The StartTravelTime is derived from the plantime by subtracting the expected time an AGV will need for the connection between the quaycrane and the ASC handling the container. This traveltime is updated during the simulation with exponential smoothing.
The StartMoveTime is the StartTravelTime minus the average retrieval time for that automatic stacking crane.
A plan is made to the Horizon, defined by the user; the remainder of the loading list is not planned. The total number of planned containers per QC is thus easy to calculate. For the containers that are planned a StartTravelTime and a StartMoveTime are calculated; the former is the time at which a container may depart from the ASC, the latter is the time at which the ASC may start unloading the container.
For containers that are already en route, the re-planning has no further consequences. Containers that are already loaded on an AGV but are still standing at the ASC may only depart at StartTravelTime, so a delay at a QC can still hold up these containers. Containers that have not yet been loaded onto an AGV are sorted at every ASC according to StartMoveTime. These containers can be loaded onto an empty AGV if one is available, even if StartMoveTime is later then the current time. This advance working is bound to an upper limit (in time), specified by the user. The as yet unplanned containers can not be loaded.
For the TravelTimes from every ASC to every QC are given an estimate travelling time of the distance as starting times. For every completed trip these are adapted by means of exponential smoothing.
The PlanTimes for the containers which must be unloaded from a ship by the quaycranes are calculated in a similar way as the loadcontainers. Based on the average cycletime of the quaycrane, the containers are planned in the future, until the user defined value of ‘Horizon’. In this case the planned times need not to be corrected for the TravelTime between ASC and QC. The average cycletime of the stacking cranes is not needed either.
AGV job allocation
Each AGV which is unloaded, either by quaycrane or stacking crane, needs a new job. Unloaded AGVs at a quaycrane moves to the ‘empty pool’, the point (or a collection of points) where the decisions about the destination will be taken. In the reference case, this point, called 'EP', is were the AGV is crossing from the quay to the stack highways (see Figure 2).
EP
Figure 2Terminal layout in simulation model, showing
QCs, ASCs and EP
At the moment that an AGV calls for a new job, either at the empty-pool or on a transferpoint at the stack, the following algorithm is used to determine its destination:
Determine the most urgent ASC for loading:
Determine the StartMoveTime from the first
loadcontainer to be handled for each ASC
Calculate PlanTime (ASC) = StartMoveTime (ASC)
Correct PlanTime (ASC) with TravelTime from
position AGV to this ASC
Select the ASC with the shortest PlanTime, and still
free transfer positions
Determine the most urgent QC for unloading:
Determine the StartMoveTime from the first
unloadcontainer to be handled for each QC
Calculate PlanTime (QC) = StartMoveTime (QC)
Correct PlanTime (QC) with TravelTime from
position AGV to this ASC
Select the QC with the shortest PlanTime
Select ASC or QC based on urgency
If no ASC or QC has been selected, chose the ASC
with the fewest AGVs, and that still has free transfer
positions
Because the job allocation for the AGVs is based on urgencies, the number of AGVs working for a specific quaycrane is not fixed, but flexible.
Loading sequence
The loading sequence for a quaycrane is supposed to be known. Each container has a fixed loading number. The sequence control guarantees the loading sequence of the QC. In the case of the DSL-terminal layout an AGV may only depart from the ASC if its immediate predecessor in the loading sequence is departed and has passed. When the sequence control is active, every AGV in the simulation has a pointer to its predecessor, i.e. a pointer to the AGV that must arrive at the same quay crane before it does. At the moment that an AGV is about to start its trip, thus before the execution of the route script starts, it will first request permission from its predecessor, which will give its permission for the departure of the AGV as soon as it has passed his position.
This sequence-control is not regulated at script level but at a level lower, i.e. at AGV-level. Because of this it is not necessary to include anything about sequence control in the scripts so the scripts can remain generic and applicable to any AGV.
If the option sequence control is switched off, AGVs may depart from the ASC when the StartTravelTime of the container is reached. Although the plan has a preference sequence, this being that of the loading list of the QC, there is no guarantee that the containers will also arrive at the QC in this sequence.
Experiments and results
General
The experiments done with the simulation model can be divided in three categories. First, a large number of simulation runs were performed to validate the behavior of the model with different values for the control parameters. Then, a reference case is defined for the set of parameters which will best represent the actual situation at the current DSL terminal. Third the value of some important parameters are varied to
measure the effects of that parameter on the performance. Two of those experiments, concerning number of AGVs and AGV-speed, are reported here.
The most critical performance indicators are:
1.Moves per hour : average number of moves per hour per
quaycrane.
2.QC-utilization : percentage of time the quaycrane is not
waiting for AGVs.
3.Average trip duration ratio : the ratio between the actual
duration of a trip divided by the technical trip time
(distance/speed), averaged over all connections between
stack and quay.
Validation runs
These runs are performed to check the validity of the model under different, realistic circumstances, and to check whether the model will produce reasonable outcomes. The performance of the simulation runs are compared with the measured performance. Different settings are defined for container workload, number of AGVs, maximum speed of AGVs, loading sequence and slotting moves.
In all circumstances, the quaycrane utilization rate is between 50 and 100%. The key factor for the performance is the number of AGVs, then the speed of the AGVs. The loading sequence, slotting moves and the number of switches between unloading and loading is of less importance. The results match the experience of the terminal operators and the expert opinion. Reference run
After discussion of the results from the first runs, the parameter setting for a so called reference run are chosen. This setting will define the best model for the current operation at the DSL-terminal.
With these settings, 10 runs are performed with different values for the seeds of the randomgenerators. Run length is fixed on 4000 containers, being the size of a large container vessel.
Table 1 gives the performance for these experiments. The three main performance-indicators, defined earlier, are shown. In this results, the first and last hour of the simulation is neglected.
Runname Seed Moves per
hour
QC-utilization
(%)
Trip
ratio
Ref5_200.txt34541.079.81
1.21
Ref5_201.txt79942.081.10 1.21
Ref5_202.txt344541.379.53 1.20
ref5_203.txt222239.376.31 1.21
ref5_204.txt1241.479.48 1.21
ref5_205.txt876542.080.75 1.20
ref5_206.txt334241.379.02 1.20
ref5_207.txt800141.880.39 1.20
ref5_208.txt77741.680.99 1.20
ref5_209.txt2981941.879.47 1.20 Table 1Performance reference run with different values for the randomseeds
The average QC-utilization is 79.7%, the deviation is 1.32. A 95% confidence interval is thus given by [77.1, 82.3].
The trip duration ratio shows that on average 20% of the travel time of an AGV is caused by waiting for other AGVs.
The run length is sufficient for measuring a stable performance. These ten runs are enough for a small confidence interval. A longer run-length is not realistic, because of the physical dimensions of a container vessel.
Vehicle characteristics
The influence of the number of AGVs and the maximum AGV speed is investigated. The number of AGVs is varied between 24 and 72, the AGV speed between 2 and 8 m/s.
The results of these experiments are given Figure 3 and Figure 4.
50.00
60.00
70.00
80.00
90.00
100.00
243036424854606672
Number of AGVs
U
t
i
l
i
z
a
t
i
o
n
Q
C
s
(
%
)
Figure 3 QC-utilization at different number of AGVs
The number of AGVs has a great impact on the performance of the reference case. More then 40 AGVs does not give any significant improvement. Because the AGV planning is not
optimized for low numbers of AGVs, the performance in this
range might be improved.
50.00
60.00
70.00
80.00
90.00100.00
2
3
4
5
6
7
8
Speed AGVs (m/s)
U t i l i z a t i o n Q C s (%)
Figure 4 QC-utilization at different AGV-speeds.
The AGV speed follows a similar pattern. A maximum above 4 m/s does not give a significant improvement in performance.
Other experiments
Other experiments performed with the simulation model
concern the characteristics of the quaycranes and the automatic stacking cranes, the effect of a strict loading sequence versus a non-strict sequence, and the effect of a slotting move of a container before stacking. The influence of these parameters on the system performance appears to be of a secondary order.
Conclusion and future research
The general conclusion which can be drawn is that the
simulation results match the performance measurements at the actual DSL-terminal in Rotterdam. The results of the analyses for different parameters are explainable, and match with the experience of the operators at the terminal, and the experts at ECT.
From these and other experiments it can be concluded that the quay transport is one of the mayor bottlenecks for increasing the throughput at the terminal. The model can be used to
determine the boundaries for the validity of this statement. It is recommended that the model is used as a starting point for further research to improve the performance of this and future automated container terminals. Focus must be on more complex and dynamic routing of the AGVs.
In the future, several options are open for further research.First, the layout and routing on the quay must be improved drastically. Second, stacking policies must be developed and tested to speed up with the improved transport- and quaycrane-loading capacity. Finally, other modalities of transport, like rail, barge and trucks must be integrated.
References
Ben-Ari, M. 1990. Principles of Concurrent and Distributed Programming. Prentice Hall.
Dijkstra, E.W. 1968. Co-operating sequential processes. In F.Genuys (ed.) Programming Languages, Academic Press, New York.
Duinkerken, M.B.; Evers, J.J.M., Ottjes, J.A. 1999. TRACES:Traffic Control Engineering System. Proceedings 31st Summer Computer Simulation Conference. Chicago [SCS] 1999, pp.461-465.
Evers, J.J.M.; Lindeijer, D.G. 1999-1. The agile traffic-control and engineering system: TRACES.. TRAIL Research School,Delft University of Technology.
Evers, J.J.M.; L. Loeve; D.G. Lindeijer. 1999-2. The service-oriented agile logistic control engineering system :
SERVICES. TRAIL Research School, Delft University of Technology (Apr.).
Ottjes, J.A.; Kruse, J. 1999. FAMAS Normship Generator.TRAIL Research School, Delft.
Sommerhalder, R. 1996. A formalisation of structured traffic control networks using colored semaphores. TRAIL Studies,Delft University of Technology.