Abstract
Storage allocation of outbound containers is a key factor of the performance of container handling system in automated container terminals. Improper storage plans of outbound containers make QC waiting inevitable; hence, the vessel handling time will be lengthened. A simulation-based optimization method is proposed in this paper for the storage allocation problem of outbound containers in automated container terminals (SAPOBA). A simulation model is built up by Timed-Colored-Petri-Net (TCPN), used to evaluate the QC waiting time of storage plans. Two optimization approaches, based on Particle Swarm Optimization (PSO) and Genetic Algorithm (GA), are proposed to form the complete simulation-based optimization method. Effectiveness of this method is verified by experiment, as the comparison of the two optimization approaches.
1. Introduction
Automated container terminals (ACT) are a category of container terminals with unmanned equipment, which detect their surroundings on their own, and execute the working actions in the right moment [1, 2]. In such terminal, containers are loaded onto or unloaded from vessels at quayside by Quay Cranes (QC) with double trolley, stacked into or retrieved out of blocks in storage yard by Automated Stacking Cranes (ASC), and transported between quayside and storage yard by Automatic Guided Vehicles (AGV). The QC, ASC, and AGV, all operated with no manpower, make up the container handling system of ACT, with a typical layout as shown in Figure 1. In this figure, QC are represented by two crossing rectangles, ASC are represented by rectangles with two edges popping out, and AGV are represented by small rectangles. Large rectangles are for blocks, strips of storage spaces laid perpendicular to the shoreline. Two ASC are bound to one block, one for the container stacking and retrieving at the seaside of the block and the other for those at the land side. Grey rectangles at both ends of the blocks are I/O points, in which containers could be stored temporarily.
Outbound containers are containers brought from inland area and are to be loaded onto vessels. Prior to vessel arrival, information of the outbound containers is sent to the terminal in EDI, including container numbers and stowage positions on the vessel. In the following days, these containers are brought in by container trucks, one after another in a random order. On the arrival of every outbound container, a block is allocated to it, and the landside ASC of that block is to stack the container into the block. Within vessel handling period, outbound containers are retrieved from block to the seaside I/O point by seaside ASC, picked up and transported to quayside by AGV, and loaded onto the vessel by QC, placed in their stowage positions according to EDI information.
Average QC efficiency, which means the average number of containers handled per hour per QC, is a main measurement for the performance of container handling system of ACT, while the upper bound of this measurement depends on QC capacity. Higher average QC efficiency leads to shorter container handling time; hence, vessels could depart earlier and finish their voyages in fewer days. The efficiency of a single QC reaches the maximum when it concentrates on container handling, with no time wasted in other actions such as moving itself or waiting for an overdue AGV. Consequently, to optimize the performance of container handling system of ACT, a key factor is to prevent QC from waiting; hence, the average QC efficiency could be maximized.
Unreasonable distribution of outbound containers among blocks is a fundamental reason for QC waiting. For every outbound container stacked in some block, the QC and ASC to handle it could be predetermined: the QC is determined since the stowage position of the container on the vessel is already known, while there is only one ASC in a block retrieving containers to the seaside I/O point. In handling containers, a QC works continuously on condition that there is always some loaded AGV at its foot every time the trolley moves back empty to the quayside. Owing to the fact that capacity of ASC is commonly lower than that of QC, the condition for continuous QC working is kept by receiving containers from multiple ASC. However, this condition could be failed in case that outbound containers of one QC are all stacked in the same block, and QC waiting is unavoidable. Still, time of QC waiting could be even longer in case that the ASC of that block is retrieving outbound containers for another QC at the same time.
This paper presents a research on the storage allocation problem for outbound containers in ACT (SAPOBA), which outputs a storage plan allocating storage spaces to outbound containers before they arrive at the terminal. It is intended that outbound containers are stacked following the storage plan, resulting in a container distribution that leads to minimal QC waiting; hence, the performance of the container handling system could be optimized. The rest of the paper is organized as follows. Section 2 presents a review of the related works and an introduction to the methodology used in this paper. A Timed-Colored-Petri-Net (TCPN) model is proposed in Section 3 for simulation of container handling system in ACT, and two optimization approaches, Particle Swarm Optimization (PSO) and Genetic Algorithm (GA), are proposed in Section 4. Experiments are conducted in Section 5, to verify the effectiveness of the simulation-based optimization method and to compare the two optimization approaches. A conclusion is driven in the last section.
2. Related Works and Methodology
2.1. Related Works
SAPOBA has received hardly any attention for the past few years. In the field of ACT, existing research is mainly on problems of inbound containers, which pass through container terminals in a reversed direction. Some works are on block selection problem, in which every inbound container is assigned to a block to when they are unloaded from vessel [3, 4]. Some others are on container stacking problem, in which every inbound container is assigned to a stacking position in a block [5–8]. Different from outbound containers that are already stacked in some block, in container handling inbound containers could be placed in either block in the storage yard; hence, the candidate ASC to handle an inbound container is not unique. Therefore, these research results are not applicable to SAPOBA.
As a counterpart problem of SAPOBA in another kind of container terminals in which cranes and vehicles are operated by human labor, storage allocation problem of outbound containers in manual container terminals (SAPOBM) is a hotspot in recent years [9]. The idea of SAPOBM is quite similar to that of SAPOBA. With storage space properly assigned to outbound containers before they arrive at the terminal, cycle time of storage yard operations could be reduced. Howbeit in manual container terminals yard cranes are not bound to blocks, and multiple yard cranes are allowed to work in the same block; hence, the SAPOBM is a bit different from SAPOBA. Moreover, a general defect of current research on this problem is that no clear description could be given of the impact of outbound containers’ storage plan on the performance of container handling system. Existing research propose mathematical models for their problem, in which objective functions are constructed for optimal storage plan. The aim of these functions could be minimizing total travel distance of vehicles [10–19], maximizing the balance level of workload among blocks [11, 14–17, 20–27], or maximizing the utilization of storage space [13, 15, 19, 24, 26]. Since none of these models is to minimize the QC waiting time, it could not be guaranteed that the optimal storage plans of these models will lead to best performances of container handling systems in the terminals.
It is not an easy work to describe the numerical relationship between QC waiting time and storage plan of outbound containers using mathematical models, while discrete event simulation (simulation hereinafter) is a suitable tool to achieve this purpose. In addition to the fact that QC waiting is a result of many factors related to QC, AGV, and ASC activities, AGV are dispatched in real-time and the AGV to transport each container is not determined before vessel handling starts. For the two reasons above, evaluation of storage plans by mathematical modeling in SAPOBA is quite a difficult task. In contrast, simulation is a process-based method which could go through the working process of the system to be modeled. Using this method, QC, AGV, and ASC in the container handling system are treated as individual objects, and the working process could be described as state changes in events. In this way, QC waiting could be expressed by time lags of some events, and AGV dispatching could be executed following dispatching rules implemented in the simulation model.
In consideration of the facts mentioned above, this paper is to solve the SAPOBA using simulation-based optimization method. This method is hybrid of simulation and optimization, in which simulation is used to evaluate candidates generated during the optimization procedure, while optimization is used to search for a best solution for the problem. The only difference between simulation-based optimization and pure optimization is the evaluation method of candidates. In simulation-based optimization, candidates are evaluated on the basis of simulation results, while in pure optimization, these evaluations are done by math expressions. Just recently, simulation-based optimization method has been successfully used to optimize ambulance fleet allocation and base station locations [28], to determine the best design and control factors of a paint shop production line in an automotive company [29], and to decide the best vehicle schedules for housekeeping in a container transshipment terminal [30]. To the extent of our knowledge, this method has not been used in ACT.
2.2. Methodology
Container handling systems in ACT are full of concurrency and asynchrony. Concurrency is a concept meaning that multiple independent processes in this system may go on simultaneously. In the container handling system consisting of multiple QC, ASC, and AGV, any two objects of them could operate concurrently, as long as they are not handling or transporting the same container. Asynchrony means that processes of different objects upon the same activity may occur in different times. For example, when transferring a container from an ASC to an AGV, the ASC just move to the I/O point and put the container down there, while the AGV just pick the container up once the container and the AGV itself are both at the I/O point. In this example, the ASC and AGV are for the same container (activity); however, they do not have to be at the I/O point at the same time.
Flowchart is a traditional formalism to describe the processes of a simulation model in concept, yet it is not suitable for simulation modeling of the container handling system in ACT. A flowchart describes a process by dividing it into subprocesses and connecting them with certain order. When a subprocess ends, the next subprocess according to order starts immediately. Thus, flowchart could only be used to describe sequential motions of one object as processes but not to express the concurrency and asynchrony among these processes and make up a model for the whole container handling system.
Known for the applicability to express asynchrony and concurrency, Petri Net is a modeling formalism for distributed parallel systems [31]. Basic Petri Nets consist of places, transitions, and directed arcs, signified by circles, rectangles, and arrows, respectively. An arc may run from a place to a transaction, or in a reversed direction form a transaction to a place. In the former case, the place is called the input place of the transaction, while, in the latter case, the place is called the output place. A number of tokens, signified by dots, may be located in some places, and move to some other places following regulations of the Petri Net. Suppose that there is a transaction and some input and output places connected to it. In case that there are enough tokens located in the input places of a transaction, this transaction fires, consuming a required number of tokens in the input places and creating new tokens in the output places. When used to build up a simulation model, places in a Petri Net indicate states of an object, while transactions indicate events of the system.
Petri Net is a formalism which is able to express the concurrency and asynchrony of a system in nature. Figure 2 is a simple example of Petri Net, consisting of five places (, , , , and ), two transactions ( and ), and five arcs. Three token A, B, and C are now located in , , and , respectively. In this figure, places and and transaction are in the same process, while places and are in two processes each. Tokens A and B are independent of each other in the process between and ; hence, the processes of the two tokens could go on concurrently. Tokens B and C are in two asynchronous processes, since it is not required that these processes should start or end in the same time. However, the following process of them () will not start till the two processes both end and the two tokens are in the input places of transaction .
Colored Petri Net (CPN) [30] and Timed Petri Net (TPN) [32] are two extensions of Petri Net. In a CPN, tokens have properties and data values attached to them, called token color, after which distinction between tokens is made possible [33–35]. In a TPN, transactions are no longer finished instantaneously. On firing of a transaction, required tokens in the input places are consumed immediately, while tokens in the output places are generated some time later [36, 37]. In simulating the container handling system in ACT, token colors could be used to distinguish different QC, ASC, AGV, and containers, while transaction times could be used to indicate the time length of equipment motions.
The possible contributions of this paper are listed as follows:(1)A simulation-based optimization method is proposed to solve the SAPOBA, which outputs a storage plan of outbound containers that leads to a best performance of the container handling system in ACT.(2)TCPN is used to build up the simulation model, which establishes directly the relationship between storage plans of outbound containers and QC waiting time of container handling system.(3)Two optimization methods, PSO and GA, are compared when used in a simulation-based optimization for optimal solution.
3. TCPN Model for Simulation
3.1. Model Assumptions
Assumptions of the model are listed below:(1)Only outbound containers are considered in this model.(2)Only 40 ft container are considered in this model. 20 ft containers could be converted into 40 ft ones in pairs.(3)The capacity of I/O points, as buffers between ASC and AGV, is fixed and is the same. No such buffer exists between QC and AGV.(4)Moving range of AGV could be divided into two-dimensional grids of equal square zones. Positions of AGV could be represented by coordinate of the grid which they are in, as positions of QC and I/O points.(5)Capacity of each grid is large enough to hold all the AGV at the same time, and traffic congestions are not considered in this model. All AGV move in a constant speed, and they always spend the same time in crossing a current grid.(6)AGV routes are decided step by step following rules. When travelling to a destination grid, at first an AGV tries to run into a next grid nearer the destination grid in a direction parallel to the shoreline. In case that no such grid exists, the AGV runs into a next grid nearer to the destination grid in a direction perpendicular to the shoreline.
Assumptions (4) to (6) could be illustrated in Figure 3, which shows a two-dimensional grid of 6 × 4 square zones. AGV could run into a neighboring grid crossing a dash line, while full lines are unbridgeable. There are 6 I/O points and 2 QC in these grids. Two AGV A and B are traveling to their destinations. Routes of the two AGV are shown as directed fold lines, intersecting at the same grid. Following the routes, the two AGV will run into the same grid simultaneously; however, their travelling times will never be lengthened:(7)Outbound containers are allowed to be retrieved in batches. Containers in the same batch get the same earliest time for retrieval, before which they are not allowed to be retrieved.(8)Travelling speeds of ASC and AGV are treated as constants in this model, while QC are assumed to stay in a fixed grid during handling process.(9)An AGV is always bound to some ASC. In case that an AGV gets no task at the moment, it runs back to the ASC it is bound to and waits there for a next task.(10)Storage spaces are allocated in slots (spaces in the same bay and same row of a block), and outbound containers are divided into stacks (a group of containers that could be placed in one slot). On this basis, storage plans are treated as one-to-one matching of slots and stacks.
3.2. Constraints of Storage Plans
Storage plan is an allocation of storage spaces to containers, a one-to-one matching plan in nature. Definition and constraints of these plans could be expressed by math formulas. Notations used in the formulas are listed below: : total number of stacks, indexed by or , . : total number of blocks in the storage yard, indexed by , . : total number of bays in a block, indexed by , . The smaller the bay number is, the closer this bay is to the shoreline : number of free slots in the th bay of block . : if stack is allocated to the slot in the th bay of block then ; otherwise, .
A storage plan could be described by a set of variables :
The constraints are shown in the equations below
Constraint (3) means that the total number of stacks allocated to the same bay in the same block should never exceeds the capacity of that bay:
Equation (4) means that each stack could be allocated only once. Outbound containers are to be stacked on their arrivals in locations as determined in the storage plan.
3.3. Overall Model
Notations used in the simulation model are listed below: : total number of QC. : total number of ASC. : total number of containers. : total number of AGV. : capacity of an I/O point. : total number of zones in the moving range of AGV. : total number of places, indexed by . In this model . : total number of transactions, indexed by . In this model, . : total number of containers to be handled. : a token in place . : a token that is fired from place to transaction . : a token that is fired out of transaction into place . CS: color set of tokens, an 8-tuple of integers as . cid: attribute of tokens indicating the container number. bid: attribute of tokens indicating the batch number. aid: attribute of tokens indicating the ASC number. qid: attribute of tokens indicating the QC number. aim: attribute of tokens indicating the destination zone number of an AGV. pos: attribute of tokens indicating the current zone number of an AGV. az: attribute of tokens indicating the zone number of I/O point of an ASC to which an AGV is bound. An AGV moves back to the zone az when it is free. qz: attribute of tokens indicating the zone number of QC joint point. : travel distance between two zones, written as and . : number of tokens in places as defined by expressions exp in the bracket. If there is no expression in the brackets, this natation means the total number of tokens in places . : the next zone of when running to zone . : average QC waiting time, as output of the model. : total number of containers handled by QC , indexed by . : start time of the th handling of QC , according to simulation. : end time of the th handling of QC , according to simulation.
The overall TCPN model is shown in Figure 4. Circles in this figure are for places, in which dashed circles indicate boundaries between different kinds of equipment. As for places with limited capacity, the maximal number of tokens allowed is marked at the upper left of the circle. Meanings of places in Figure 1 are listed in Table 1. Squares and rectangles are for transactions; the former fire instantaneously while the latter fire with some time. Square brackets are for firing conditions of transactions. In case that there is a square bracket over or under a square/rectangle, the transaction will not fire till the conditions are met. Arrows are for arcs, each with the number of tokens to or from a transaction marked. Marks of arrows could be divided into two parts. For arrows from a place to a transaction, the first part of the mark indicates number of tokens consumed by the transaction, and the second part is written as “,” with for the origin place and for the destination transaction, indicating every token going through the arc. The two parts are put together to be a whole mark, with a back single quotation set between them. Marks of arcs in an opposed direction are formed in a similar way, while in these marks the tokens are written as “” for distinction.
Meanings of places in Figure 1 are listed in Table 1, while the transactions and arcs are to be explained in partial models.
In the beginning, some colored tokens are scattered initially in some places in the TCPN model, which is called the initial marking of the model, as is shown in Table 2. Tokens located in are for containers to be handled. Each container gets a unique container number, and the batch numbers are known as well. In addition, the ASC and QC to handle the containers are known as well (.aid and .qid), as the zone number of QC joint point (.qz). The token in is used to allow container retrievals in batches, and no color is assigned to it. Tokens in are for ASC; hence, the ASC number of each token (.aid) is known and unique, as the zone number of I/O points (.az). Tokens in are used to indicate the residual capacity of I/O points; hence, tokens in this place all get an ASC number (.aid), and the amount of tokens that have the same ASC number is fixed. Tokens in are for the QC; hence, each of these tokens gets a unique QC number (.qid). Tokens in are for the AGV, which are always located in some zone (.pos) and bound to some ASC (.az). There is only one token in with no color, used to update the positions of AGV periodically. The TCPN model ends with a similar marking as in the beginning, yet no container is left in place .
When simulation ends, the total QC waiting time could be calculated as sum of time intervals between the time a QC finishes a current container handling and the time the QC starts a next container handling. As a result, the average QC waiting time, as the output of the simulation runs and the optimization objective of the SAPOBA, could be calculated following (1) as follows:
3.4. Partial Models
The overall TCPN model could be divided into three parts, with those dashed circles in Figure 4 as boundaries, corresponding to ASC, AGV, and QC, respectively. Partial model of ASC is shown in Figure 5. Notice that the position of is adjusted.
There are 5 transactions in this partial model. Transition is to allow a new batch of outbound containers to be retrieved by ASC, and transaction is the cool-down of this allowance. In case that the cool-down ends and a token is placed in , all the tokens (containers) in with the same batch number (.bid) as token are fired (), as token itself (). At the same time, one new tokens () are created immediately into for every , and a new token () is also created to . On this creation, transactions are fired, creating a new token () into after a fixed interval. With the help of , transaction brings periodically batches of containers that are allowed to be retrieved by ASC, following the handling schedule in a real ACT.
Transaction is fired when an ASC is ready for a next container ( not empty) and there is some container allowed to be retrieved by it already (token exists in with the same.aid). Considering that there may be multiple tokens in and they could go to different QC, an ASC always retrieve a container to the QC with minimum inventory, as shown in the firing condition. QC inventory means the number of containers which have been placed in the I/O point but not handled by the QC, equal to the number of tokens to the QC in . This strategy is also used in [38], in which it is believed that this strategy helps in preventing QC from waiting for AGV, leading to a good productivity of the terminal. On firing of this transaction, a token () is created into immediately, as an AGV task to be allocated. Moreover, another token () is also created into at the same time, as the next container to be handled.
Transaction is for the cycle time of ASC. When deciding to retrieve a container ( not empty), an ASC moves to its stacking location, pick it up, and carry it to the I/O point. Time length of this process could be calculated, since the stacking position of container and the moving speed of ASC are both known. On the arrival of ASC to the I/O point, a new token is created to . Notice that since stacking positions of containers are all different, firing time of is not fixed.
Transaction is to add a new container to the I/O point of some ASC. In case that an ASC is loaded at the I/O point ( not empty) and the I/O point is not filled (at least one token exists in with the same ASC number .aid), this transaction consumes a token in and , respectively. After a time, a token is created to as a container stacked in I/O point, and another token is also created to as QC inventory. Firing time of is fixed, which equals the time an ASC spends in putting a container down to the I/O point.
Color relations of tokens to and from the same transaction in this partial model are listed in Table 3. Notice that tokens from or to the same place always get the same color, while the color of tokens created in a firing is not always inherited from the consumed tokens. Attributes not involved in this partial model are excluded.
Partial model of AGV is shown in Figure 6. Positions of , , , and are adjusted.
There are in total 6 transactions in the partial model of AGV. Transaction is to allocate a container task to an AGV with no task. In case that there is some tasks to be allocated ( not empty) and some AGV are with no tasks ( not empty), fires to allocate a task to a nearest AGV, by consuming corresponding tokens in and and creating a new token into at once.
Transaction is used to simulate the travel time of an unloaded AGV with some task to the I/O point of the container. Firing time of the transaction equals travel time of AGV, which could be determined since the current zone and destination zone are both known for the AGV.
Transaction is for the process in which an AGV picks up a container at I/O point. In case that an AGV has reached the I/O point () and the container is placed there as well (), this transaction fires, consuming the tokens in and , and creating one new token in and after a fixed time interval, respectively; hence, the AGV receives the container (), and the number of containers that could be placed in the I/O point is added by 1 ().
Transaction is used to simulate the travel time of a loaded AGV to the foot of the destination QC. Firing time of this transaction is calculated as in transaction , after which a new token is created into .
Transactions and are used to update the locations of the AGV with no tasks periodically. They work in a similar way as Transactions and . For all the AGV with no task, they are moved in a fixed interval to a neighboring zone nearer to the ASC which they are bound to, if possible.
Color relations of tokens in this partial model are listed in Table 4. Attributes not involved in this partial model are excluded.
Partial model of QC is shown in Figure 7. Positions of are adjusted.
There are only 2 transactions in this partial model. Transaction is for the process that a QC picks up a container from an AGV. In case that a QC is ready for a next container loading ( not empty), and a loaded AGV has reached the foot of that QC (token with the same QC number in ), this transaction fires, consuming one token in , , and , following firing conditions as shown in Figure 7. In case that there are multiple loaded AGV at the foot of the same QC, the AGV carrying the container with a minimal container number will be consumed. Firing time of transaction is fixed. When the firing ends, a new token is created into as an AGV with no task allocated to it, and another new token is created into indicating that the QC has received the container.
Transaction is used to simulate the time a QC trolley spends in putting a container onto a vessel and turn back empty to the quayside. Firing time of is also fixed. When the firing ends, a new token is created to ; hence, the QC is ready for a next load.
Color relations of tokens in this partial model are listed in Table 5. Also, attributes not involved in this partial model are excluded.
4. Optimization Approaches
The TCPN model proposed in the last section could be used as fitness functions of optimization methods, evaluating the influences of candidate storage plans on the performance of container handling system. In this section, two intelligent optimization approaches, based on Particle Swarm Optimization (PSO) and Genetic Algorithm (GA), are proposed to complete the simulation-based optimization method.
4.1. Encoding
Intelligent optimization is a category of methods used to search for a solution of a problem as good as possible. These methods go through new candidate solutions continuously in a self-defined direction, till an end condition is fulfilled, and the best candidate solution found is output as the result. Encoding is a first step of intelligent optimization. Using some set of regulations, solutions of a problem could be expressed in a form convenient for optimization operations.
Storage plans are encoded as arrays of real numbers, as candidate solutions of the SAPOBA. Each number in the array is for a stack to be allocated, while the value of this number indicates a slot for the stack. For every real number in a code array, the integer part is for the number of block that the stack is to be allocated in, while the decimal part is for the priority of this stack to get a slot in the block. Stacks with a smaller decimal part tends to get a slot nearer to the ASC; hence, the ASC cycle time of containers in this stack could be shorter. In case that there is no slot left in a block, stacks to be allocated in this block will be reallocated to some other block, and the number of these stacks will also be changed.
Table 6 is a coding example of 7 stacks. Storage spaces are scattered in 2 blocks, as shown in Table 7. In this example, stacks 2 and 3 are allocated to the 1st bay in block 1, stacks 1 and 5 are allocated to the 2nd bay in block 1, and stacks 6 and 7 are allocated to the 1st bay in block 2. There are no slot left for stack 4; hence, it is allocated to the 2nd bay in block 2, and the value of this stack is to be changed into 2.66 accordingly.
4.2. PSO Approach
Particle Swarm Optimization works with a fixed number of particles (called swarm) iteratively. A particle moves to a possible solution in each iteration, while in a next iteration this particle moves to another. The best solution of the swarm and best solutions of particles are kept over iterations, which are used to guide the searching direction of particles. Notations used in the PSO approach are listed below: : scale of the swarm, total number of particles, indexed by , . : maximum number of iterations, indexed by , . : length of a particle, equal to the number of stacks to be allocated. : the th element of th particle in generation , real number. : the th particle in generation , an array of elements. : speed of the th particle in generation , an array of real numbers. : best historical solution of particle . : best historical solution of the swarm. : fitness value of candidate solution of particle in generation . : fitness value of best historical candidate solution of particle . : fitness value of best historical candidate solution of the swarm. : maximal fitness value of a satisfactory candidate solution. : maximum allowable number of successive iterations in which best solution is not changed.
Since candidate solutions are encoded as one-dimensional arrays of real numbers, a particle in iteration could be defined as in the following equation:
Notation is for the total number of ASC in ACT, which is already defined in Section 3.2. In the beginning of optimization, particles and their speeds are initialized in random. In each iteration, the current candidate solution of each particle is first evaluated by simulation output δ; then the best solutions and are updated in case that better solutions are found in the particles, as shown in the following two equations:
Iterations are used to generate new the candidate solution of all the particles. This operation is conducted following equations below:
Notations , , and in (7) are all coefficients, valued between 0 and 1. Three end conditions are set in the approach, as listed below. The PSO approach ends if that one condition is satisfied in an iteration, and the best candidate solution found is output as a result of PSO approach:(1)Fitness value of the best candidate solution found is no worse than .(2)Current iteration number reaches the maximum iteration number .(3)Best historical solutions has not been changed over the past iterations.
The procedure of simulation-based optimization method using PSO approach is shown in Figure 8.
4.3. GA Approach
In Genetic Algorithm, candidate solutions are treated as chromosomes, of which the basic units are treated as genes, just as the real numbers in the code of a storage plan. In the beginning, a fixed number of chromosomes are created and treated as the initial group. New chromosomes are created from current chromosomes by crossover and variation, after which a number of chromosomes are selected into a new group with the size unchanged in a next generation. Due to the fact that definitions of chromosomes in GA approach and candidate solutions in PSO approach are the same, notations for swarms and particles are used here for groups and chromosomes.
Crossover is executed between two chromosomes as parents. With the values of some genes in same positions changed in pairs, two new chromosomes are created from their parents. For example, chromosomes 1 and 2 in generation 1 crossover at the 5th gene to form two new chromosomes 3 and 4. This crossover could be expressed by formulas as follows:
Commas in the formulas above are used to separate digits of different notations in subscripts. Real numbers and are randomly generated, under constraints as in formula (10).
Variations are executed with single chromosomes. In a variation, values of some genes in a chromosome will be replaced by a random number; hence, a new chromosome is created.
Selection is executed to the whole group of chromosomes of which the fitness values are already known. In this paper, the best chromosome will always be selected, while the rest are selected following roulette strategy. The better the fitness value of a chromosome, the larger the chance it is selected into a next generation.
End conditions in the GA approach is same as in the PSO approach. The procedure of simulation-based optimization method using GA approach is shown in Figure 9.
5. Experiment
The simulation-based optimization method is applied for random examples in two scenarios. There are 4 QC, 10 blocks, and 10 ASC in the small scenario and 6 QC, 15 blocks, and 15 ASC in the large scenario. Three AGV are bound to the same ASC in both scenarios. A 15 × 4 grid of square zones, with side-lengths of 36 meters (with reference to the satellite photo of Maasvlakte Container terminal in Rotterdam), is established to hold the QC, AGV, and I/O points of ASC, as shown in Figure 4. QC 5 and QC 6 in this figure only exist in scenario 2, as ASC 11–15. Containers are stored in blocks in the same size of 20 bays, 6 rows, and 5 tiers each, yet the blocks are not included in Figure 10. ASC are all dedicated to one block. Containers in the same block are always retrieved by the same ASC, while containers in different blocks are not.
Equipment parameters used in the experiment are listed in Table 8.
Instances of outbound containers are generated as follows. In each scenario, there are 40 containers (divided into 8 stacks) to be handled by each QC per hour in the coming 12 hours. In case that the storage plan is properly made, QC waiting could be eliminated entirely, and the storage plan is considered satisfactory. Consequently, there are 384 stacks of containers to be allocated into 10 blocks in the small scenario and 576 stacks to be allocated into 15 blocks in the large scenario, as are the code lengths of them.
The simulation program of the TCPN model is realized in Tecnomatix Plant Simulation 11, a professional software for discrete event simulations. The PSO and GA approaches are realized in the same environment as well. When evaluating a candidate solution, the code of the solution is first converted into a corresponding storage plan. On this basis, simulation runs and QC waiting times are calculated as the fitness value of the candidate solution. For the PSO approach, parameters , , , , and in the algorithm are assigned to 0.9, 0.8, 0.8, 100, and 20, respectively. For the GA approach, scale of the group is set the same as the scale of swarm in PSO approach. Crossover is executed 5 times every generation, and the probability of a gene to be selected to cross is 0.8. The probability of a chromosome to be selected and varied is 0.15, as the probability of a gene.
Experiments are conducted separately in two scenarios. For each scenario, 20 instances are generated in random. Each instance is solved 5 times with simulation-based optimization method using PSO approach first and then solved another 5 times using GA approach. The best fitness values of the 100 optimization runs in every iteration/generation are recorded, and the mean values of average best fitness values in every iteration/generation (if not ended) of the two approaches are shown in Figures 11 and 12. Moreover, attentions are paid to the number of satisfactory solutions found in the 100 optimization runs using PSO and GA approaches (noted as ) and the average time span of simulation runs ().
Figure 11 is the average best fitness values in the small scenario, in which the -axis is for the iteration/generation numbers and the -axis is for the fitness values (in seconds). The figure tells that GA approach outperforms PSO approach in the earlier stage of optimization for fast convergence, while in the later stage PSO approaches are more likely to find a satisfactory storage plan.
Figure 12 is the results in the large scenario. It could be told form the figure that GA approach outperforms PSO approach in the earlier stage of optimization for fast convergence, while in the later stage PSO approaches are more likely to find a satisfactory storage plan, as found in the small scenario.
Number of satisfactory solutions () and average time span of simulation runs () are listed in Table 9. In the 100 optimization runs of the small scenario, PSO approach finds 89 satisfactory solutions, while GA approach only finds 73. In the 100 optimization runs of the large scenario, PSO approach finds 82 satisfactory solutions, while GA approach only finds 69. Average time span of simulation runs is 27.3 seconds in the small scenario and 38.6 seconds in the large scenario.
The following could be concluded from Table 9 and Figure 12:(1)Simulation-based optimization method could be used to solve the SAPOBA, while in this paper a satisfactory solution could not always be guaranteed.(2)Due to the fact that simulation is quite time-consuming in evaluating candidate solutions, fewer simulation runs are preferred for optimization runs.(3)PSO approach is more suitable than GA approach in simulation-based optimization for SAPOBA, since it is more likely to output a satisfactory storage plan.
6. Conclusion
This paper proposes a simulation-based optimization method for storage allocation problems of outbound containers in automated container terminals, which has rarely been mentioned in the literature. Considering that there are quite a number of concurrent and asynchronous processes in the container handling system, Timed-Colored-Petri-Net method is used to build up the simulation model, which is used to obtain the average QC waiting time in container handling in case that outbound containers are stacked according to storage plan. Two optimization approaches, using Genetic Algorithm and Particle Swarm Optimization, respectively, are proposed to form the complete simulation-based optimization method. Experiments are conducted to verify the effectiveness of the simulation-based optimization method proposed and to get the PSO and GA approaches compared. Results of the experiments shows that PSO approach is more likely to output a satisfactory solution, although GA approach converge faster in the early stage. Further work could be verifying the simulation model in real automated container terminals, shortening the time span of simulation runs and improving the performance of optimization approaches.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This research is supported by the Specialized Research Fund for the Doctoral Program of Higher Education of Ministry of Education of the People’s Republic of China (no. 20133121110005), the Innovation Projects for Graduate Student at Shanghai Maritime University (no. 2013ycx050), “Scientific Research Innovation Project” of Shanghai Municipal Education Commission (no. 14ZZ140), the “Ph.D. Innovation Program” of Shanghai Maritime University (no. 2014ycx040), and the “Yang Fan Plan for Shanghai Youth Science and Technology Talent” of the Science and Technology Commission of Shanghai Municipality (no. 15YF1404900).