A simulation modeling framework for multiple-aisle automated storage and retrieval systems

Transcription

1 DOI /s x A simulation modeling framework for multiple-aisle automated storage and retrieval systems Jean-Philippe Gagliardi Jacques Renaud Angel Ruiz Received: 1 February 2012 / Accepted: 9 August 2012 Springer Science+Business Media, LLC 2012 Abstract This paper presents a simulation model framework for unit-load automated storage and retrieval systems (AS/RS) able to cope with most of the features found in industrial settings like, for example, multiple aisles, non aisle-captive cranes or double-deep unit-load AS/RS. Although these features characterize most of the industrial applications, they have been simply neglected by most of the previously published research oriented papers, which explains at least partially the low impact of the research output in practice. To help mitigating this drawback, this paper first presents an upto-date chronological literature survey, which includes works that use any form of simulation in the modeling process. It then proposes an Object-Oriented Simulation Model for unitload AS/RS developed with a purely generic mindset. In this model, the physical design decisions are separated from the operational decisions, which makes it possible, first, to obtain a better understanding of AS/RS dynamics and, second, to increase the model s flexibility and generality, thus allowing many interesting scenarios to be represented. In particular, the simulation modeling framework has been used to develop a simulator and to conduct a preliminary study on a multiaisle AS/RS. Keywords Multiple-aisle automated storage and retrieval systems Unit-load End-of-aisle Discrete-event simulation Object-oriented simulation Warehousing J.-P. Gagliardi J. Renaud A. Ruiz (B) Interuniversity Research Center on Enterprise Networks, Logistics and Transportation (CIRRELT) Faculté des Sciences de l administration, Laval University, Quebec City G1V 0A6, Canada angel.ruiz@fsa.ulaval.ca Introduction It is a great challenge to match supply and demand in today s turbulent markets. Logistics and distribution play a dominant role in the success or failure of a firm (Hiremath et al. 2012) and therefore the research devoted to the design of efficient distribution systems has significantly increased during the last years. Automated storage and retrieval systems (AS/RS) and other advanced technologies as Automated Guided Vehicles, AGV,(Ito and Abadi 2002; Lin et al. 2006; Singh et al. 2011) are used in modern distribution centers (DC) as they provide fast, accurate and efficient material handling, 24 h a day. In its most basic depiction, an AS/RS consists of singledepth storage racks where loads are stored and retrieved automatically by specialized stacker cranes. This wide definition is representative of the large variety of possible system implementations, like for example, Flow rack automated storage retrieval systems (Bessenouci et al. 2012), where a storage machine and a retrieval machine are placed at the rear and the front of the rack, respectively. This paper focuses on a particular type of AS/RS, known as the unit-load AS/RS. Unit-load AS/RS are fully automated systems where a single storage or retrieval transaction involves only one unit-load. Although these systems are often seen in high-volume distribution centers where the unit-loads are finished goods pallets, they can also exist in production environments for work-in-progress storage. Figure 1 below illustrates the unit-load AS/RS under study in this paper. When implementing a system like the one shown in Fig. 1, numerous questions arise on both design and operational levels. Many of these problems have already been tackled in the literature, and a recent survey by Roodbergen and Vis (2009) wraps them up very well. From a design perspective, the system configuration is an immense challenge. Designers must first configure the storage racks (number, length,

2 Fig. 1 An industrial AS/RS height, depth, and spacing), which defines storage capacity and required floor space for the whole system. Also, the number of cranes and their degrees of freedom must be set. In some implementations, cranes may have the capacity to operate in several aisles, but in others, cranes are aisle-captive. Another crucial decision is the number and location of input/output (I/O) points for the cranes to interface with upstream and downstream links in the distribution supply chain. All these design decisions influence the implementation costs and later have a huge impact on the maximum throughput capability of the system. From an operational perspective, control decisions must be made in order for the system to achieve its maximum throughput capability for a given design. These problems include, among others, storage assignment, dwell-point positioning and request sequencing. Storage assignment refers to the assignment of unit-load storage requests to empty storage locations. The dwell-point is the designated location for an idle crane waiting for its next request. Request sequencing deals with the sequence in which storage and retrieval requests are processed by the cranes. AS/RS design and control problems are difficult to deal with because AS/RS evolve in highly dynamic, turbulent environments, in which demands (translated by retrieval requests) are frequently subject to change at short notice. Like in other logistics processes, demand is also stochastic and may be seasonal. In addition, the system state changes every few minutes. For instance, when sequencing requests at t 0, the set of available (i.e., empty) storage locations depends on the operations that have been executed previously. The same phenomenon holds true for retrieval locations, where the set of locations that contain product i depends on the operations that have been previously executed. These two factors tend to favor approaches trying to formulate robust guidelines instead of solution methods seeking the optimal solution. All design and control decisions in AS/RS are linked to some extent. For instance, the numbers of cranes or their capability to move from one aisle to another have a great impact on the request sequencing process. These interactions make the joint evaluation of more than one decision very difficult, which opens a door to AS/RS simulation studies, in which it is possible to compare many design and control combinations to assess their performance. As Gagliardi et al. (2012) have observed, in the papers in which simulation has been employed, the main focus was the results, and very little attention was given to the model. As a result, the models are not discussed explicitly. In addition, a great number of critical assumptions that can have a huge impact on experimental outputs of other scenarios have not been mentioned. The contribution of this paper lays on the proposition of an accurate, yet general, discrete-event simulation model for multiple-aisle unit-load AS/RS able to reproduce or anticipate AS/RS behavior in real settings. It also proposes some possible extensions of this model for managing configurations broadly used in practice, like non aisle-captive cranes or double-deep unit-load AS/RS. The model is positioned to complement the current literature and to fill the gap between the contributions of proposed theoretical models and the needs of managers in industry. The remainder of this paper is organized as follows. The second section surveys the literature on simulation used in AS/RS modeling. The third section presents our generic object-oriented simulation model. The fourth section extends our simulation model in order to study other configurations. The last section presents our conclusions and projects for future research. Literature review on simulation used in AS/RS modeling First, when modeling real-world applications, the systems are often too complex to allow realistic models to be evaluated analytically. To overcome this difficulty, strongly simplified assumptions are used for these models. For instance,

3 in order to evaluate the performance of a given implementation, some analytical models assume a random storage policy and single-aisle configuration, which does not reflect most real-world implementations. Second, taking stochastic phenomenon into account (e.g., demand process) is sometimes an issue in the purely analytical approaches. Simulation is a numerical analysis method designed to estimate the true characteristics of complex systems in which some components behave stochastically, so AS/RS conceptualization could certainly benefit from simulation analyses. This literature review focuses on modeling approaches that incorporate a form of simulation in the study of AS/RS systems. As mentioned above, the simulation models in the literature are not very detailed and give us the impression that they were developed for very specific scenarios. This section presents some of these papers, highlighting the lack of detailed models. In past research, simulation has been successfully applied to study AS/RS. Among the first academics to employ the technique, Schwarz et al. (1978) examined and extended the analytical models of Hausman et al. (1976) and Graves et al. (1977), using a simulation of a discrete rack in order to study storage assignment and the interleaving effect on travel-time performance. Their analysis used the same assumptions as their predecessors. They modeled a single aisle, then a twosided aisle of locations. Arriving unit-loads were placed in a storage queue of infinite capacity. At the moment of storage of an item i, the item length of stay (LOS) was generated. Using their model, the authors concluded that choosing an open location randomly or choosing the closest open location (COL) were equivalent at 90 % rack use when neither interleaving nor sequencing is allowed. This conclusion is representative of the type of conclusions found in the literature: a specific conclusion for a single configuration. In this case, it is legitimate to ask ourselves if these results are generalizable to other scenarios. In other cases, simulation was employed to optimize the AS/RS. For instance, Azadivar (1984) proposed a simulation model that made it possible both to test the effect of assignment policies and to optimize the system. His model s objective was to optimize the average round-trip time required by the crane to complete a storage task or a retrieval task under a given LOS distribution of the items on the storage racks. Stochastic approximations were used in a simulation-optimization algorithm that obtained optimum variable values. Using the continuous representation of a rack proposed by Hausman et al. (1976), the simulation-optimization algorithm was run with a targeted rack use of 90 %. The results confirmed those of Schwarz et al. (1978) since the same assumptions were used. This situation represents the importance of assumptions in AS/RS studies. Randhawa et al. (1991) employed simulation to evaluate single and dual I/O point configurations in unit-load AS/RS. They studied a unique single-sided aisle configuration. The authors proposed 3 performance criteria: system throughput, mean waiting time, and maximum waiting time. They assumed that storage requests could only be processed with first-in, first-out (FIFO) or COL rules. Retrieval requests were arranged to minimize travel time, either working on a block composed of the first K requests [e.g., similar to the approach presented by Han et al. (1987)] or dynamically maintaining the list each time a new retrieval request arrives. Their simulation model was based on a discrete-event engine. The configurations studied assumed a rack use of 75 %. Their results showed that the shortest-leg (SL) rule was better for all configurations studied. These results also showed that the dual-dock layout maximized throughput. Another interesting element in the conclusion of their study was that high rack use leads to reductions in throughput. The authors explained this result with the fact that, on average, the crane needs to travel longer to process requests. Nonetheless, the results from all rack use levels were similar. The conclusion was the same for mean storage waiting time and maximum waiting time. Knapp and Wang (1992) introduced Petri nets as a new technique for modeling AS/RS. It was implicitly assumed that the system under study was a unit-load AS/RS in which a random storage assignment policy was applied within all product classes. Single command cycles were also assumed, meaning that the crane always goes back to the I/O location after each processed request. In their paper, Knapp and Wang (1992) explained the Petri net principles extensively but drew few conclusions about their AS/RS model. Later, Chiccholar and Chetty (1996) used stochastic colored Petri nets to study the effect of 5 AS/RS control factors on 3 performance metrics: time to complete M requests, unproductive travel time and mean flow time. Their results showed that these 3 metrics were mostly affected by the crane scheduling rules and crane operation mode. Taboun and Bhole (1993) were among the first to develop a discrete-event simulation model that allows the study of multiple operation scenarios for an AS/RS. Among these possible scenarios, the authors were mainly interested in the study of the impact of storage assignment as well as item assignment and pallet configuration on the performance of the AS/RS. As a consequence, most of the model focuses on items to pallets assignment for different pallet dimensions. The model was implemented in Siman and aims at reproducing the real system behavior with a high level of detail. Model validation was performed by comparing the modeled system against a real AS/RS from a local distribution center. By experimenting on multiple scenarios, the authors show that using more than one pallet size may help achieve better space utilization and throughput. Eben-Chaime and Pliskin (1997) questioned the fact that most AS/RS studies focus on single-aisle systems, while

4 paying little attention to the other systems that interface with the AS/RS. These authors extended the integrative model proposed by Eben-Chaime (1996), composed of single-depth racks, cranes, storage and retrieval queues and a list of empty slot addresses. The authors were mainly interested in evaluating 3 crane operating modes: single command (SC), dual command (DC) and hybrid command (HC), which uses DC whenever possible and SC otherwise. They mentioned explicitly that the model can handle unit-load or mini-load operations. Their results indicated that the HC mode was an efficient strategy to adopt in order to reduce storage-request queue length and maintain good service levels. Van den Berg and Gademann (2000) presented one of the most complete simulation studies of AS/RS control policies. They compared several storage assignment policies, as well as the sequencing of storage and retrieval requests. The performance measure used throughout the study was the tradeoff between crane travel time and system response time. Item turnover was assumed to be known and constant, and the AS/RS was assumed to be composed of a single two-sided aisle in which the I/O point is located at the corner of the rack. The turnover rates, product mix and ordering policies were constant, and the number of available unit-loads at period t was approximated using a normal distribution (Van den Berg 1996). It was also assumed that the system was balanced (i.e., the storage and retrieval requests queues were of equal length, and so dual command cycles could be formed). The model of Van den Berg and Gademann (2000) allowed dynamic sequencing of the retrieval requests. However, in order to maintain good service levels, urgency rules were employed (Han et al. 1987). The simulation model was implemented in C++, but no other details were given related to its implementation, except for the fact that there is, at most, a single unit-load of each item at all times. When a retrieval request was generated, a storage request for the same item was generated at time t + TUNSi, where TUNSi is a variate that was randomly generated from a known probability distribution. In the same manner, when a storage request was generated, a retrieval request was generated at time t + TUNRi, where TUNRi is also a randomly-generated variate representing the time offset for the arrival of the next storage request. Extensive simulation results were presented. Meller and Mungwattana (2005) used a simulation to evaluate the benefits of various dwell-point policies. The focus of their study was the relationship between the dwell-point policy and system use. The main performance measures employed were the mean time in system of retrieval requests, and crane use. The authors assumed that distances were measured in normalized units, and if the crane received a retrieval request while travelling to its dwell-point, it completed the trip before it processed the request. Dual commands were formed, with each request type being processed according to the FIFO rule. The model was simulated for 100,000 time units, in addition to a warm-up period of 5,000 time units. Their results indicated that the dwell-point policy had low impact on system response time when the AS/RS was used a lot and also had low impact (<10 s) on the absolute response time for any use level. Fukunari and Malmborg (2008) proposed an innovative method for estimating travel times in a single-aisle, unitload AS/RS employing the queuing theory paradigm. They tested the 1-class Closest-Open-Location (COL) storage policy when the rack use was less than 100 %. For this case, the assumption of equiprobable access to any location used in Pure Random Storage (PRS) (Hausman et al. 1976) was not satisfied. In fact, applying the COL policy tended to maximize the use of storage locations closer to the I/O. It was assumed that, when the system was used less than 100 %, COL could yield shorter travel cycles than PRS. Their approach consisted of modeling storage locations as a M/M/N queuing model (Banks et al. 2000), where N is the number of locations in the aisle and M/M mean that exponential distributions are used to model inter-arrival and service times, respectively. The N locations were sorted in a non-increasing order of their distance from the I/O point. The queuing model state distribution was then used to approximate the probability that individual locations would be occupied. These probabilities were then applied to estimate the storage and retrieval transaction travel times under COL. In order to validate their approach, they compared the response of their model to a discrete rack simulation model and to Bozer s Adjusted PRS (APRS) model (2010). Their results indicated that their model s average response was closer to the discrete rack response than to the response of the APRS. This paper was among the first to focus on modeling approaches for AS/RS studies. Simulation has also been successfully applied to study other AS/RS implementations. For example, Ekren et al. (2010) were interested in the study of AVS/RS. Instead of relying on automated cranes to perform storage and retrieval tasks, AVS/RS use autonomous vehicles that usually only have the ability to move horizontally within an aisle tier. Changes in the elevation of a particular vehicle are made possible by the use of elevators usually located in front of each aisle. The main advantage of this approach is that the number of autonomous vehicles can be adjusted following throughput requirements. While throughput capacity can be adjusted, the elevators may tend to become the new bottlenecks of this type of technology (Ekren and Heragu 2010). Gagliardi et al. (2012) focused on the assignment of unitload AS/RS locations under the assumptions presented in Literature review on simulation used in AS/RS modeling section. To this end, the authors proposed a detailed discrete-event simulation model that allowed studying the performance of storage assignment policies under realistic conditions. They emphasized that their modeling approach

5 was generic enough to test a wide variety of scenarios. The system was balanced, meaning that each retrieval request performed would trigger a subsequent storage request later in time. In order to validate the model, these authors first replicated the specific settings of Hausman et al. (1976). Since the results produced were identical to the ones in Hausman et al. (1976), the validity of the approach cannot be challenged. These results suggested that a TBS storage assignment policy would yield shorter crane travel times than PRS. In addition to these results, Gagliardi et al. (2012) studied the situation in which the amount of storage space per product is superior to 1 (LTPR > 1). For this case, space allocation played a bigger role in performance. By using different values of s, the skewness parameter of the ABC distribution (e.g., Hausman et al. 1976), these authors showed that the same conclusions did not always hold true. In fact, their results showed that PRS can achieve a better performance than TBS in some settings. These conclusions demonstrate the dangers associated with models that use assumptions that are not necessarily consistent with typical warehouses, as well as showing that simulation models may give responses that are more precise than analytical travel-time models and are less restrictive concerning the necessary assumptions. The contributions of this paper are twofold. First, we propose and explain a generic model for unit-load AS/RS using discrete-event simulation. The conceptual relationships between physical aspects and decisional aspects are also explained. Second, this model can be qualified as generic because the approach uses the object-oriented programming model and doing so gives us the possibility to study more than one scenario quite straightforwardly. To support this assertion, we propose extensions that can be employed to study more than one scenario. The model proposed is especially useful for the case in which the system consists of more than one aisle and expected crane travel time is not a sufficient metric. To the best of our knowledge, multi-aisle systems have not been studied in the literature. The object-oriented unit-load AS/RS simulation model AS/RS are systems difficult to model analytically because they incorporate the interactions of many subsystems, in which more than one instance of some subsystems may exist. From this point of view, it is quite natural to adopt a systems approach and model AS/RS as a collection of interacting objects. Another element of complexity is the presence of random events. As mentioned above, simulation is a tool of choice when studying complex, dynamic and stochastic systems. Furthermore, since most events occurring in AS/RS are of discrete nature, discrete-event simulation seems like the best simulation modeling approach. In this section, we propose a discrete-event simulation model that employs the power of the object-orientation (OO) modeling paradigm (see Fujimoto 2000) in order to study almost any system configuration with very slight or no modifications. Object imbrication is a very useful feature of OO programming because it allows containing the instantiated objects into one another. See for example (Lee et al. 2000) a detailed study on OO modeling applied to real-time monitoring and control systems. This approach really mimics the true relations between real AS/RS components. For instance, since the proposed simulation model focuses on unit-load AS/RS, it is useful to model a single item object on each pallet container. In the eventuality where a pallet would contain more than one item, we could instantiate multiple objects of type item and store them (as a list of items) inside a unit-load container object. Using this approach, it is quite straightforward to know exactly the content of a pallet at a certain point in time or the state of the cranes contained in a specific aisle. OO programming can also help in that sense by allowing defining an object, its logic and memory once and then allowing to make multiple copies that can exist independently. Using this feature, it is now also quite straightforward to study a system with more than one aisle by instantiating multiple aisle objects at the beginning of the run and imbricate them inside their respective aisle. This section will mainly focus on unit-load AS/RS, while Possible model extensions section will discuss possible extensions of the model. The model can be used as is in a simulation study or can be paired to a decision model in a simulation-optimization process (see Rosenblatt et al. 1993). The model could also be implemented in any object-oriented language (e.g., VB, C#) or in any commercial simulation software that integrates the OO paradigm (e.g., Simio, Any- Logic). The model includes physical parts, decisional parts and inbound (production) and outbound (demand) interfaces. Separating the model into physical and decisional objects allows us to better understand AS/RS and also increases the flexibility and generality of the model. Figure 2 gives a macro view of the AS/RS object-oriented model. Our model combines a crane controller, a demand model that generates retrieval requests, and a supply model that generates storage requests. A request is dispatched to a specific crane, according to a set of rules implemented in the crane controller. The cranes are responsible for executing the requests, which, in turn, modify the state of the aisles by changing the content of the storage locations. In Fig. 2, informational transactions are represented by dotted arrows, while continuous arrows represent physical unit-load transactions. In the following sub-sections, we describe the nature of each component in further detail.

6 Fig. 2 Relationships between the main AS/RS components Physical components Items, unit-load containers and storage/retrieval requests (model entities) From an implementation perspective, the simulation model is composed of programming blocks, which represent entities and servers within an AS/RS using a set of properties and procedures. For example, the most basic object manipulated in an AS/RS is called an item. An item represents a stock keeping unit that is stored in unit-load containers and is present in a certain quantity in the AS/RS. AS/RS are designed to handle storage and retrieval requests for specific items. In order to differentiate the content of a unit-load container, each item is tagged with its stock keeping unit number. Since we use an Object-Oriented approach, more information can be stored in each item. This characteristic may be useful in some industrial contexts (e.g., the food industry), where it is mandatory to retrieve the oldest product first in order to maximize shelf life at the point of sale. From this perspective, an item s production date for each product can be recorded on each item. Retrieval requests are modeled as 5-tuples ( p, ζ, ξ, x, y), indicating the exact location where the retrieval request will be executed. p,ζ and ξ represent the item number, aisle number and pick face (i.e., pick side), respectively, while x and y represent the column and the row of the product location in the request. Storage requests are noted in the same format, but p (the item number) is replaced by an instance of the object to be stored. More parameters can be incorporated to the requests in order to measure, for example, request processing time from the moment the requests enter the warehouse to the time they are processed. Two major strengths of object-orientation modeling are of great use in our model. First, the fact that it is possible to imbricate objects allows the model, for example, to store a collection of items in a unit-load container and then to store this unit-load container in a specific storage location of an aisle. This logical imbrication is very close to the real interactions of an AS/RS. Figure 3 illustrates the imbrication of objects that compose our model. (We are only interested in the relationship between the objects; we will discuss the procedures later.) Arrows show the relationship direction and plurality (e.g., The AS/RS is composed of 1 to many aisles, where each storage location can hold a single unitload container.). The second strength of OO modeling is the ability to directly instantiate multiple copies of an object in the initialization phase. Each instance holds its own information while reacting to the same rules as the all objects of the basic class. This feature is particularly useful for modeling multiple-aisles AS/RS. Aisles and storage locations AS/RS aisles hold unit-load containers in fixed-size storage locations. In our model, a container may represent a pallet or a bin. Each container/bin can hold a single item (e.g., unit-load AS/RS) or a collection of items (e.g., end-of-aisle AS/RS employed to handle the storage small parts). Storage locations in an aisle can be modeled as two 3-dimensional arrays of unit-load containers, one for each side of the aisle, which allows a wide variety of storage configurations to be modeled, including multiple-depth storage locations. Using this approach, we assume that storage locations are the same dimensions and that any location is able to hold any unit-load

7 Fig. 3 Hierarchy of imbrication of AS/RS objects container. Storage aisles have one or more I/O points, which can be modeled by their unique coordinates in the rack. Decisional components Crane controller The crane controller models the decisional part of the AS/RS. Every request that is processed by the warehouse is handled by the controller. It is responsible for splitting the storage and retrieval requests into two independent queues and for sequencing these requests. It is also responsible for assigning requests to cranes. Storage tasks represent physical unitload containers. Changing the order (i.e., the sequence) in which storage tasks are processed usually requires a physical conveyor loop. Retrieval requests are decisional and can be sequenced without physical requirements. In order to sequence storage and retrieval requests, the controller has to communicate with each aisle to evaluate its available stock and the coordinates of the crane. A simple yet efficient rule for task sequencing is the shortest-leg rule, which looks for the closest location from a crane s present position in order to minimize travel time to complete a certain request. Transmission of requests may follow a push policy or a pull policy. The push policy implies that a block of requests is sequenced and then pushed to each crane queues. While this approach may require less computing, it is also likely to yield poor results in terms of travel time. As an alternative, it is also possible for the cranes to pull a new storage and/or retrieval request from the controller whenever they complete a cycle. Using a pull policy makes it possible to dynamically sequence requests, which will be more likely to yield shorter travel times. Since hybrid command is the best strategy in order to reduce travel time while maintaining good service levels (Eben-Chaime and Pliskin 1997), it seems appropriate to integrate this kind of logic in the crane model Stacker cranes Stacker cranes are considered as servers, whose function is to process the storage and retrieval requests received from the crane controller. Each crane has one inbound storage queue and one outbound retrieval queue. The storage queue lists the physical unit-load container objects to be stored in a given aisle, while the retrieval queue lists the information concerning loads to retrieve. From our modeling perspective, request sequencing is fulfilled by the crane controller only. Stacker cranes execute single or dual command cycles. A single command cycle concerns a single request, while a dual command cycle usually executes one storage request followed by one retrieval request in the same cycle, assuming that both storage and retrieval requests are available. The dual command cycle minimizes travel time by reducing the number of empty travel legs. Since storage and retrieval requests may not always be available, the hybrid command policy, which performs dual command cycles whenever possible and single command cycles otherwise, can be used. This type of command policy has been shown to minimize crane travel times (Eben-Chaime and Pliskin 1997). Figure 4 presents a model of the movements of an AS/RS crane. In this figure, the bold arrows indicate that the crane is loaded with a pallet, and the double-framed points (i.e., I/O point & Storage location) indicate possible standby locations. Each crane is independent and follows this pattern of movement. Without loss of generality, let s assume that a crane has just completed a retrieval request, and thus it is located at the I/O point. Depending on the availability of requests for this crane, two different paths are possible (Fig. 4). If requests of both types are available, the crane will first perform a storage request, moving a load from the I/O to the storage location. Once the storage operation is completed, the crane performs an empty move to an extraction location where it retrieves a unit-load and transfers it back to the I/O point. The advantage of using the dual command policy whenever possible becomes obvious because it takes less

8 Fig. 4 Model of the crane movements time to perform both tasks sequentially than to perform both tasks separately. Finally, the stacker cranes move between the AS/RS locations according to the tasks received from the crane controller. In unit-load AS/RS, cranes typically move simultaneously on both axes. Supply model and the inbound and outbound interfaces AS/RS are usually linked to other systems in the distribution environment by means of inbound and outbound conveyors. Inbound conveyors handle goods from the production system or the inbound docks. Outbound conveyors are used to carry goods from the AS/RS to the outbound docks, where shipments can be consolidated and loaded onto trucks. Conveyors are a crucial element to model when studying the performance of other systems around the AS/RS. In this case, it is often assumed that no congestion occurs on the conveyors, which is plausible if inbound and outbound conveyor networks are seen as separate entities. Another common assumption is that goods circulating on the conveyors travel at constant speed; thus, the conveyor travel time is computed as a linear function of the distance and travel speed. A loop in the inbound conveyor makes it possible to sort the storage requests. In real life scenarios, it also allows tackling errors in the automatic tag-reading system that identifies the content of arriving unit-load (e.g., errors caused by a torn barcode). Depending of the goals of the study, different supply models can be imagined upstream of the AS/RS. In most of the cases found in the literature, storage requests are viewed as a list of requests generated at the beginning of the simulation. This approach is valid when the focus is solely on the performance of the AS/RS as an independent entity. But, as Roodbergen and Vis (2009) observed, the total warehouse performance cannot be assessed by adding up the performances of all individual systems. It is necessary to include a supply sub-model that is responsible for generating storage requests dynamically over time. This approach makes it possible to model one or more production centers with different setup and cycle time settings. Using this configuration, it is also possible to model several alternatives according to the desired Order Penetration Point (OPP) location in the production/distribution facility (Sharman 1984). The OPP is defined as the point in the manufacturing value chain for a product, where the product is linked to a specific customer order. The OPP becomes therefore the interface between the push driven and the pull driven flow of materials in a production supply chain. Before this point the material flow is controlled by forecasts and plans, and afterwards as deliveries according to customer orders. Depending on the supply model chosen, many modeling challenges can appear. Among the various strategies used, we mention two extreme yet popular strategies. The first one is the pull policy, in which inbound and outbound flows are strongly linked. Unit-loads are generated by the supply model each time that a unit-load leaves the AS/RS. This strategy guarantees that no space shortages will occur and can be quite useful to manage storage request releases in time. Nonetheless, it does not seem to be appropriate for real-world situations because using an AS/RS usually means that a perfect pull policy is hardly feasible. The second strategy is the push policy, corresponding to the situation in which the AS/RS is the OPP location. Goods are produced according to a predetermined production plan and then pushed to the AS/RS. From the standpoint of an AS/RS simulation, this situation is more challenging because space shortages can occur, even more so as the size of the production lots increases. From a simulation perspective, the only element that changes between the two policies is the set of conditions to verify before launching a production batch. In the first case, stock levels are verified after any retrieval, while, in the second, lots are launched following the schedule. Discrete-event simulation engine Discrete-event simulation (DES) focuses on the asynchronous creation and execution of instantaneous events in a simulated system. The simulation is coordinated by a discrete-event engine. The simulation engine described in this paper is inspired by the one proposed by Pidd (1995), which

9 consists of a three-phase algorithm that allows the clock to be advanced asynchronously from one event to the next. The simulation engine works with a list of events sorted by their execution time. Each time an event is executed, the system state is modified accordingly, and the simulation clock moves to the following event in the list. Sometimes, the execution of an event does not change the state of the system, but rather generates new events to be added to the list. In this case, the time at which the event will be executed is calculated or simulated. Events are classified into bounded (B) and conditional (C). B-type events are those for which the execution date can be predicted (or simulated) by the system. For example, let t be the current time at which a particular event (e.g., travel from I/O to storage location ) is executed. The execution of this event implies the generation of a new event (e.g., unload the pallet at the storage location ), whose execution date can be stated as t + d, where d is the travel time between the I/O point and the selected location. Regardless of the approach followed to model travel times, which can be either deterministic or stochastic, d is a computed value during simulation. On the other hand, the execution date for conditional events cannot be determined in advance because they depend on the system state. For example, it is not possible to set the execution date of an event like Start storage operation in advance because the event can only be executed when the following two conditions are satisfied simultaneously: (1) a storage request is waiting to be processed in the queue, and (2) the crane is idle. By defining different condition sets for conditional events, it is quite straightforward to integrate specific behaviors, such as the hybrid command mode described above. In order to manage multiple objects (e.g., multiple parallel servers and entities), it is quite useful to store these objects in arrays. In this manner, it is possible to maintain references to objects by pointing to their array index. This approach allows much lighter data structures (e.g., a single event) to be developed. This is an important feature, since a typical simulation handles hundreds of thousands of events. For example, adding a crane number field in the event structure makes it possible to know which crane is involved in the execution of an event. The same holds true for a manufacturing simulator using multiple production centers that work in parallel. Table 1 shows some of the data structures required by the simulation model. These data structures are required because the discrete-event engine uses a process that doesn t have any memory. For the data structures in Table 1, we assume that all object instances are stored in arrays and are referenced by their ID so that all stored values are numerical. Each time an event occurs, the engine reads the event and advances the clock to the time of the event; since each event concerns a specific crane or production center, the reference is passed on at each bound event related to the same server. The same holds true for the storage/retrieval requests. These request structures transit from the controller to the cranes that execute them. Finally, production requests specify the item to produce and the required quantity. This information may depend on a push strategy (i.e., a pre-determined production plan) or a pull strategy, as mentioned above. The three-phase algorithm works as follows. In phase A, it seeks the first event in the time-sorted event list. When the algorithm finds it, the event becomes the current event, and the system clock is set to its execution time. In phase B, the current event is executed. The required changes to the system are applied, and new events are added to the list, if necessary. In Phase C, the algorithm verifies whether or not the system state makes it possible to execute C-type events by testing the necessary conditions given in Tables 2 and 3. After executing each A-B-C loop, the algorithm verifies whether or not the simulation stop conditions have been met. If so, the algorithm stops; otherwise, it moves back to Phase A. Tables 2 and 3 list the events of the system and their type. They describe the execution conditions for C-type events only, as well as the changes in the system state caused by their execution. New event creation rules are also provided. The equations in Tables 2 and 3 use the following notations: Vel x : Crane velocity on the horizontal axis Vel y : Crane velocity on the vertical axis t loading : Time required for the crane to load a unit-load t unloading : Time required for the crane to unload a unit-load t Now : Current simulation time ICL: Inbound Conveyor Length ICV: Inbound Conveyor Velocity We use a simple example to illustrate the algorithm s execution process. Let us assume that non-empty lists of retrieval and storage requests produced by the dispatcher are available at time t = 0, and that the event list is empty. An initialization process resets the system clock and places the idle crane at the I/O point. Without loss of generality, the initialization process also sets the crane s last activity to storage so it always starts with a retrieval task at the beginning of a simulation run. Since the event list is empty, the algorithm skips Phase A and Phase B and moves directly to phase C. For instance, the event Start retrieval operation is executed if the crane is idle and if there is at least one retrieval request in the queue. When this event is executed, the crane s state changes to idle = false, and a new B-type event, Crane Loaded for Retrieval, is added to the events list. The execution time for this new event is the current clock time, plus the expected travel time, which can be calculated using the distance between the I/O point and the targeted retrieval location chosen by the crane coordinator. Since the crane s state is idle = false, none of the other C-type events can be executed. Consequently, the algorithm moves back to phase A.

10 Table 1 Examples of data structures used in the discrete-event simulation model Event structure Requests structure Production request structure Time Request arrival time Request creation time Event ID Request ID Stock keeping Unit ID (SKU-ID) Event name Request type Quantity (Rq) Crane number Stock keeping unit ID (SKU-ID) Production center number Destination aisle number Destination location The next event in the list is the Crane loaded for Retrieval, which has just been generated. The algorithm selects this event, updates the clock to this event s execution time, and then executes the event, which creates the Retrieval Completed event. The current event can then be deleted from the events list. The algorithm moves on to Phase C but cannot meet the C-type conditions. When the Retrieval Completed event has been executed, the crane becomes idle again, and the C-type conditions will be verified in order to trigger another event. All events are executed in the same way until all the storage requests are completed. In order to avoid deadlocks, discrete-event engines must always have at least one event on their list. Possible model extensions Using the Object-Oriented modeling approach presented in The object-oriented unit-load AS/RS simulation model section, it is quite straightforward to implement extensions or variations to the model in order to study different system configurations. In this section, we give three examples to illustrate the possibilities of our model. Double-deep unit-load AS/RS Double-deep AS/RS are based on the same concept shown in Fig. 1, with the exception that storage racks are able to store two unit-loads in each location, one behind the other. This double-depth characteristic maximizes the use of space. However, like in conventional warehouses, it takes more work in order to store or retrieve unit-loads located in the second storage layer. It is possible to replicate double-depth AS/RS from the general single-depth model by performing three simple modifications. First, each rack must be modeled as a matrix with 3 dimensions (x, y, z), instead of the 2 dimensions (x, y) required for the single-depth operation. Second, requests must now contain an indication of the depth at which the request must be performed. Finally, the crane movement logic must be modified in order to manage double-depth requests, as described by Figure 5 and in the following paragraph. Let us suppose that a crane reaches a request location to perform either a storage or a retrieval operation involving the second layer of the rack. Let us also assume that the first layer of the location considered is occupied by a load i. Otherwise, there is no obstacle to access to the second layer, and there is no need to change to the standard storage/retrieval logic. In order to access the second layer, load i occupying the first layer must be moved to an empty relief location. Then, the storage or retrieval operation on the second layer can be completed. Next, decisions must be made concerning load i. Although leaving load i at its new location seems to be the most efficient strategy, bringing it back to its original position can be also considered. In some cases (e.g., highly saturated AS/RS where space allocation is done by zones), an interesting strategy could consist of reserving a specific slot in the rack as a relief location. However, this strategy would require returning load i to its original location once the operation on the second layer has been completed. As shown above, double-depth AS/RS provide an interesting challenge that can be tackled by analytic approaches only with difficulty because the time required to store or retrieve a product are dependent on the system state. However, it does not present a major difficulty for the model presented in this paper. Moreover, the model can be easily expanded to manage systems with 3, 4 or even n storage depth levels. The key to this ability is that the model and its underlying interactions are very close to a real AS/RS. Non aisle-captive cranes In some cases, AS/RS cranes can move freely from one aisle to another by using a rail system usually located at the end of the aisles. One of the major benefits to this approach is that it allows designers to design a system that has less cranes than aisles. Since a huge percentage of the initial investment and the maintenance costs are directly linked to cranes, substantial economies can be achieved by eliminating the cranes dedicated to slow-moving aisles that have low activity and sending a crane from another aisle only when required.

11 Table 2 Events linked to crane activities Event name Event type Execution conditions State changes New event New event execution date Real system behavior generated Start retrieval Conditional 1. Non-empty retrieval queue operation 2a. Last operation is storage OR 2b. Last operation is retrieval Crane is idle = false Crane loaded TNow + Max( x and storage queue is empty for retrieval 3. Crane is idle Velx, y Vely ) + t loading Crane loaded for Bounded Storage location is unoccupied Retrieval TNow + Max( x Velx, y Vely ) + t unloading Move from current location retrieval Available stock update completed to retrieval location Load the pallet to retrieve Retrieval Bounded Crane is idle = true Move from retrieval location completed Remove request from queue to I/O Unload the pallet to retrieve Start storage operation Conditional 1. Non-empty storage queue Crane is idle = false Storage completed 2a. Last operation is retrieval OR 2b. Last operation is storage and retrieval queue is empty 3. Crane is idle TNow +tloading + Max( x 1, y 1 ) Velx Vely +Max( x 2, y 2 ) + t unloading Velx Vely Storage completed Bounded Crane is idle = true Move from current location to I/O Remove request from queue Storage location occupied Load the pallet to store Available stock update Move from I/O to storage location Unload the pallet to store

12 Table 3 Events linked to production activities Real system behavior Event name Event type Execution conditions State changes New event generated New event execution date Start production center Conditional 1. Production center is idle For i = 1 to (Rq-1): TNow + SetupSKUid 2a. Monitoring stock levels OR Unit-load completed +(i cycleskuid) 2b. Pre-determined production Production center For i = Rq: plan is idle = false Production completed Unit-load completed Bounded Unit-load arrival at AS/RS TNow + ICV ICL A single unit-load exits the production system The produced unit-load arrives at the AS/RS Unit-load arrival to AS/RS Bounded Enqueue new storage at crane controller level Production system has completed the request Production completed Bounded Production center is idle = true In order to mimic this kind of configuration, one important assumption, stating that two cranes cannot use the same aisle at the same time, becomes very useful. To this end, we simply require that each crane s work queues (i.e., storage/retrieval) contain a maximum of one request at all times. In this way, when a crane goes idle, it queries the controller, which responds by sending back a request that a) minimizes the crane s travel distance to the work location and b) ensures that each aisle contains a single crane at one time. Since each request contains information on the destination aisle and location where the event should take place, no additional information is required. It is also necessary to modify the travel-time formula for this particular setting, by adding an additional time component, representing the time to transfer the cranes between the aisles. End-of-aisle AS/RS The end-of-aisle configuration is often used in the less-thanunit-load, product-to-picker AS/RS. For instance, this kind of configuration can be seen in automated libraries, where bins are retrieved from the system, then processed by operators, and finally stored back in the system. In order to reproduce this configuration, the general modeling approach presented in this paper may be applied without major changes to the framework. Conceptually, since crane travel time depends on the storage racks cell dimensions (a parameter of the model), crane travel time will be automatically adjusted according to the smaller locations typically found in end-of-aisle AS/RS. In addition, in order to mimic input and output operations, a few new components must be introduced into the model: post-retrieval events, one or more processing queues, and servers (i.e., pickers). In this context, when a retrieval request has been completed, the selected bin goes to a processing queue so that an operator picks the order or puts the bin away. In the first case, the bin goes back to the controller storage queue so that it can get stored back in the AS/RS. By using the object-oriented modeling approach, the content of a bin is modeled as a list of items, so it is quite straightforward to update the quantity of each item in a bin, in addition to their types. Many other particular settings observed in practice may be easily reproduced using our model. In fact, our modeling framework can be extended with little effort to model conventional unit-load warehouses, in which cranes are replaced by forklifts and drivers. Using the simulation model: preliminary results on multi-aisle AS/RS The goal of this section is to show the ability of the proposed modeling framework to cope with realistic AS/RS settings,

13 Fig. 5 Changes required in the crane movement logic for the double-deep unit-load AS/RS providing a worthwhile tool for both researchers and decision makers. To this end, it proposes specific experiments comparing the system performance in terms of the makespan (the total time to perform a given number of extraction and storage requests) when changing the number of aisles, the number of total storage cells being constant. Needless to say, anticipating the system performance is of the highest importance when designing an AR/RS, so this kind of experiment will certainly provide valuable insight to decision makers. Moreover, to the best of our knowledge this is an issue that has not been empirically studied by any previous work in the literature. We built an AS/RS simulator following the design principles proposed in the previous section. The simulator was implemented in VB.NET, a very flexible object-oriented language. Data concerning pallet requests as well as any other information on the AS/RS physical structure are inspired by the real setting of one of our industrial partners located in Quebec City, Canada. In particular, we considered 1,800 products and retrievals requests were generated using an ABC-type pattern, where the first 20 % of the fast mover products represented 52.4 % of the total demand. Experiments and results In order to estimate how the performance of an AS/RS evolves according to the system topology, we decided to compare three different two-side, single-depth, AS/RS configurations having, respectively one, two, and three aisles. Since we considered a system with 1,800 locations and a Locations- To-Product ratio (LTPR) of 1, the length (L) and the height (H) of each configuration need to be set adequately to keep the total number of locations constant for all the three cases while. Also, the choice of L and H is very important in order to reach a similar shape factor for all the three configurations. Therefore, assuming that the crane moves at 1 m/s. in both axes horizontal and vertical, we proposed a (L H) system for the single aisle configuration, a system for the two-aisles configuration, and a system for the three-aisles case. For 1,800 locations, these system configurations are those leading to the most similar shape factor (b = length/height). In order to assess the impact of storage location policy on the system performance, we also elected to evaluate three different zone configurations in which we apply the random storage assignment policy: 1-zone, meaning a pure random location assignment, 2-zones, meaning that the first 20 % of the fast moving products occupy the 20 % of locations closest to the I/O point, and the FTB (full turn-over based) strategy. Five replications containing 1,500 dual command cycles (storage + extraction) each were executed for each run after a warm-up period of 150 cycles (10 %). The results are given in Table 4. Columns TT report the total cranes travelling times in minutes. Columns Makespan report the total time in minutes (excluding loading and unloading operations) to complete the 1,500 command cycles. Clearly, TT corresponds to Makespan for the single crane configuration, but for the other two configurations, TT adds the travelling times of all the available cranes. Loading and unloading times have not been considered because they are generally assumed constant. The average and half-with (95 %), HW, over the five instances are also reported for each case and, as can be observed, they are sufficiently low in order to give us confidence that no more replications are required.