Automated storage and retrieval systems have become increasingly popular in modern supply chains due to their significant advantages over traditional warehousing systems. Due to the high complexity of these systems, simulation approaches can be used to generate accurate performance measures for a specific system configuration. Simulation models are also the cornerstone of digital twins, one of the latest technological innovations that can further improve warehouse operations. Therefore, the aim of this research is to describe an approach for the development of a discrete event simulation model of an automated storage and retrieval system with a perspective towards the implementation of a digital twin. To be consistent with the objectives of the digital twin, the proposed model represents both the physical system and the overarching information technology architecture, such as the warehouse management system and the warehouse control system. In addition, this paper describes a methodology to validate such a simulation model by setting up an experimental campaign based on the principles of design of experiment. The experiments conducted in a logistics laboratory were used to iteratively calibrate the model until its performance accurately reflected the functioning of the real system. The results obtained demonstrate the effectiveness of the proposed method. Finally, this work contributes to the literature on warehouse digital twins by highlighting new variables to be considered when defining travel time models and their stochastic nature.
Notes
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Research motivations and objectives
Automated storage and retrieval systems (AS/RSs) have gained widespread adoption in recent years as a storage and retrieval technology for goods [1]. These computer and robot-assisted systems are capable of storing and retrieving items without human operator intervention [2]. Compared to traditional warehousing systems, AS/RSs offer significant benefits such as higher space utilisation rates, lower labour costs, shorter retrieval times, and improved inventory control [3]. AS/RSs are particularly effective in operational contexts with a high density of small and medium-sized components or raw materials, enabling better operational efficiency [4].
Most studies in AS/RS literature focus on optimising storage/retrieval operations and reducing cycle times via analytical models [5, 6]. However, in large, complex, and dynamic material flow systems the analytical evaluation may be complex [7]. Particularly, in AS/RS this limitation is more stringent since they incorporate interactions of many subsystems [8]. Scholars can thus adopt simulation approaches to generate precise performance measures for a specific system configuration [9].
Advertisement
Simulation models are also one of the cornerstones of digital twins (DTs), which are defined as computerised models that represent the network state for any given moment in time [10]. DTs are simulation-based virtual counterparts of a physical system, exploiting real-time data synchronisation to optimise the actions undertaken by the physical system [11]. In order to unlock the predicting performance of a DT, simulation models should be validated with real data from the physical system they are replicating [12]. However, most AS/RS simulation models do not provide clear indications of a validation process. Furthermore, the scope of a DTs is significantly larger than the scope of a simulation model, as it includes multiple layers such as network structure and information flows from and to external systems and databases [13]. For a logistics system this implies including warehouse management systems and enterprise resource planning systems in the picture [14]. Hence, it can be argued that, in order to be consistent with the goals of a DT, AS/RS simulation models should depict not only the physical system but also the overarching architecture that connects all the information and physical flows. Furthermore, systematic approaches to their validation should be adopted to ensure that simulation models faithfully represent the physical system of the DT.
The objectives of this work are thus to propose a system architecture for an AS/RS simulation model and to validate the simulation model via a design of experiment (DoE) approach, which is a suitable quantitative method for verifying and validating simulation models [15]. The development of a full-fledged DT is, however, out of the scope of this paper. Therefore, the remainder of this paper is structured as follows. In Section 2 we explore two streams of literature, namely simulation in AS/RS and DT applications to the warehousing context. Then, we present the physical and information technology (IT) infrastructure of the chosen AS/RS configuration. In Section 4 we highlight the simulation model architecture, and in Section 5 the validation process is depicted, together with the results. Finally, conclusions are drawn in Section 6.
2 Theoretical background
2.1 Simulation modelling for AS/RSs
Lee et al. [16] used computer simulation models to examine the operational logic of AS/RSs with rail-guided vehicles as material handling tools. By doing so, these scholars have determined the optimal number of vehicles, the utilisation of narrow-aisle cranes, and the maximum throughput of the system. Another study by [17] focused on analysing the sequencing rules for retrieving parts from an AS/RS servicing a production line. In the context of automated warehousing, models based on discrete event simulation (DES) are commonly employed, as they can accurately represent the operational level of a system [18]. For instance, DES was used to analyse storage assignment policies for a unit load (UL) crane configuration by [19]. Furthermore, in [20] DES and analytical formulation were combined to explore the impact of different rules for transferring ULs blocking the one being retrieved in a double-deep AS/RS with cross-aisle transfers. Another simulation model examined the same configuration but with the objective of optimising energy consumption [21]. Finally, object-oriented programming concepts were integrated into the DES model in one study [8].
2.2 Simulation-based warehouse DT
DTs have been applied in several industrial contexts, such as predicting aircraft fatigue and damages [22] or aiding cyber-physical production systems [23]. Recently, the DT literature has been focusing on warehousing contexts as well. The more advanced implementation involves optimisation models coupled with simulation engines capable of emulating the warehouse in real time. For instance, the DT implemented in [24] consisted of a joint optimisation model verified via a semi-physical simulation engine and is applied on a case study consisting in a traditional stacker crane AS/RS. Similarly, [25] focused on using machine learning models to optimise replenishment operations and order picking in the context of urban logistics. However, in this case, the DT was limited to the order-picking process and did not extend to the entire physical system. Braglia et al. [26] proposed a slightly different take on the DT concept, whereby a discrete-event simulation was used to run scenarios using data retrieved from the physical system via radio frequency identification sensors. However, the paper focused mostly on the network communication protocols between the data collection and data analysis tools rather than on the simulation model. A similar perspective was shared in [27], where a laboratory system to test a DT for tracking the activities of an unmanned aerial vehicle was used. Finally, [12] proposed a simulation-based decision support tool for an in-house logistics DT, covering logistics activities such as receiving, storing, order picking, cross-docking, and shipping. The simulation model was validated by comparing the results from the computational model and the information collected at the companies involved in the study.
Advertisement
2.3 Research gap and main contribution of this study
As previously mentioned, DTs incorporate more components than the simulation model. However, it is paramount to their success that the underlying simulation model is validated and represents a depiction of the real-life system, including not only the physical architecture but the IT systems one as well. This is in line with [28], which states that the service system is one of the essential dimensions in the DT.
Fig. 1
The multi-level shuttle
×
In this sense, available simulation models are presented as black-box models that replicate the operations of a specific AS/RS configuration without considerations for the information architecture that guides those operations. We propose to bridge this research gap by providing a Unified Modelling Language (UML) representation for the AS/RS simulation model including the overarching IT systems architecture.
Finally, most AS/RS simulation models do not present clear indications about the validation process. We propose a model validation on a real-life AS/RS, which is an industrial application often overlooked by DT literature [26]. For the validation campaign, we compare the test run results from the simulation model and the physical system. The experimental test runs used in the validation are designed according to the DoE principles [29], which aim is to design rigorous experiments to test how a system responds to changes of its independent variables (i.e. factors), considering different values or settings that each independent variable during the experiments (i.e. levels).
3 System description
The main components of an AS/RS are storage racks, handling machines, input/output (I/O) points, and conveyors [30]. The most widespread real-world setting is represented by an automated stacker crane operating in an aisle and performing both horizontal and vertical movements [3].
The configuration under analysis, defined as multi-level shuttle (MLS) system, is therefore a specific application of the above-mentioned stacker crane configuration (Fig. 1). The MLS has been designed and developed for the management of automated warehouses that require performances that cannot be achieved with a traditional mini-load stacker crane system, due to the additional vertical and horizontal spaces that characterise these warehouses. It can also be used in industrial contexts where it is not possible to have storage racks that are too high. In fact, the MLS allows the handling of materials by means of a single multi-level shuttle and is easily adaptable to installation in reduced spaces, thanks to its small size and the weight of its structure.
Typical AS/RS design decisions include the number of tiers, columns and aisles, rack dimensions, type of UL handled, and deep positions of each storage location. From a design point of view, the handling machine (HM) is able to move ULs such as plastic totes or trays along three axes. The horizontal and vertical movements occur simultaneously. The system is also able to manage different types of ULs. Two ULs of the same type can be loaded onboard of the shuttle simultaneously. The MLS is able to load more than one UL only in the retrieval and relocation process, while in the storing procedure, it loads only one UL at a time. The MLS is aisle-captive, meaning that the HM only works in one aisle of the storage rack and cannot change aisles. The rack has a double front, with storage locations designed to host multiple ULs. The AS/RS is also equipped with an I/O roller conveyor system. The input and output conveyors can be also located at different positions of the rack.
From an operational point of view, AS/RS can be defined according to storage assignment rules, dwell points for vehicles, and command type [9, 31]. The MLS follows a priority-based inventory policy (PB). This policy associates a priority to each storage location, which determines the preference with which that storage location is chosen for a storage operation. It is calculated as the normalisation of the inverse of the sum of the average times from each input point to that storage location and the sum of the average times for that storage location to all the possible output points of the warehouse. Therefore, PB policy determines a sort of centre of gravity between the input and output points of the warehouse. The retrieval of ULs instead is managed with a first-come-first-served policy (FCFS). In case the UL to be retrieved is blocked by other ULs, the ULs stored in front of it are reallocated based on a nearest neighbour policy (NN). This means that the machine searches for the nearest storage location where it is possible to store the blocking ULs. Additionally, the HM operates either on single command (SC), dual command (DC), or multiple command (MC) type. The dwell policy is the point-of-service-completion (POSC), meaning that the HM machine remains at the position of the last operation when it completes the backlog of storage/retrieval missions to be performed.
The IT infrastructure supporting the MLS AS/RS is based on two main systems: a warehouse management system (WMS) and a warehouse control system (WCS). The WMS is a computerised IT system used to prepare, monitor and execute business-related warehouse activities. In fact, the WMS focuses on orchestrating warehouse processes by incorporating product information, purchase orders, and stock levels. Therefore, one of the main objectives of the WMS is to organise and store orders and similar tasks. However, it does not usually control the automated equipment. Instead, the WCS is a software application that manages the real-time activities of the AS/RS. It manages the functioning of the material handling technologies by translating the tasks coming from the WMS into storage or retrieval orders for the MLS. It essentially acts as a layer between the WMS and the automated equipment.
4 The digital model
According to [32], to ensure a successful implementation of the DT it is essential to develop an appropriate model, which must take into account the goals of the specific DT application [33].
4.1 Model conceptualisation
To achieve the objectives of this research, it is necessary to create a model able to replicate the functioning of the real system with a high degree of accuracy and minimal abstraction. In order to do this, a UML class diagram was created, as this type of diagram can be used to effectively describe the various entities of a system and the various connections between them [34]. The model was built using a modular approach, meaning that the main components of the AS/RS were identified and modelled separately as an object class of the UML class diagram. Representing the individual elements of the real system as independent objects is useful for modelling specific functionality, rules, and exceptions, and for achieving a high level of detail in the representation of the system. Figure 2 shows the developed UML model.
Fig. 2
The conceptual model of the AS/RS
×
The diagram is divided into three groups of classes, each of which is coloured differently:
1.
Blue classes refer to physical entities of the system at issue, i.e. the environment, the UL, the aisle composed of the storage locations, the conveyors, and the MLS;
2.
Green classes represent the IT infrastructure of the system, i.e. the WMS and WCS,
3.
Yellow classes involve the logic entities of the system, i.e. the WMS tasks, the missions, the sessions and the WMS locations.
The diagram shows the structure, attributes, and characteristics of each entity in the system and their interactions. The general environment aggregates one or more aisles, a WMS, and several ULs. The aisle in turn contains the MLS, the storage locations, and the conveyors. In addition, a module of the WCS is assigned to an aisle. The ULs can be stored in the storage locations, moved by the conveyors, or transported by the MLS. The WMS manages the WMS locations, which are logical areas of the MLS system. The WMS does not know the exact location of each UL, such as which location it is in, but it does know that it is stored somewhere within the aisle. So for the WMS, the UL is contained within a logical WMS location that is specifically coded. The WMS locations are also mapped to the aisle to associate logical locations with physical locations. When a UL arrives at the end of the input conveyor, an input task is created. A task can be seen as a logical transfer of a UL from one WMS location to another. In the case of the storage process, the WCS sends a message to the WMS, which generates a task to logically transfer the UL from the WMS location associated with the input conveyor to the WMS location associated with the rack. This task is then passed back to the WCS, which generates a group of missions to control the MLS and complete the task. The missions associated with one or more tasks and generated together are grouped in a session. In the case of an input task, the session is composed of a retrieval mission of the UL from the input conveyor and a storage mission of the same UL in the assigned storage location. Once generated, the group of missions is passed to the MLS and added to a queue. Each time each individual mission is completed, the MLS class sends feedback to the WCS class. When a mission is completed, the MLS is released. If there are other missions in the queue to be executed, the process is restarted. The WCS class sends a message to the WMS class declaring that the associated task has been completed as soon as the session is completed.
Some of the classes contain only attributes, as they do not perform any actions. For example, the storage location class, which represents each storage location of the rack, consists of a number of attributes that uniquely identify each instance of the class. Some of these attributes are the id, the front, the column, the tier, the number of deep positions available, the 3D coordinates, and the storage priority. Another class with only attributes is the unit load, described by the id, the type, the physical dimensions, and the number of deep positions occupied. On the other hand, there are some classes that also have methods, such as the WCS. The WCS has two attributes, an identification code and the matrix with the times needed to move at each coordinate of the rack. In addition, the WCS class has the method generate_missions, which takes as an input parameter the tasks created by the WMS and generates the missions to control the MLS. The MLS class also has both attributes and methods. Attributes are the maximum speed, acceleration, and deceleration. Methods are, for example, calculating the time required to complete a mission and moving the MLS to the storage location associated with the mission. There are also methods for loading/unloading the UL and updating the mission status.
4.2 Discrete event simulation model
Starting from the model structure and functioning described in Section 4.1, a digital model (DM) based on DES was built to achieve an effective DT implementation. AnyLogic, a Java-based multi-method simulation software, was chosen as the platform for building the DM. It provides an integrated modelling environment that streamlines the entire modelling process by providing a unified workspace where modellers can easily create, modify, and analyse their simulations. In addition, the extensive collection of built-in libraries greatly accelerates the modelling process. These libraries include a wide range of pre-built components such as sources, queues, delays, and resources. Finally, the versatility of AnyLogic is a key factor in its selection over other commercial simulation software options. The object-oriented approach allows the construction of different types of models, whether simple or complex, flat or hierarchical, replicated or dynamically changing structures. This feature allows a model to be built to any desired level of detail, depending on the problem to be solved [35]. The model developed focuses only on the storage process of the MLS system.
The following list summarises the notation used for the variables and parameters considered:
x, y, z
Horizontal, vertical, transverse axis
ax
Axis
conv
Conveyor
v
Maximum velocity
a
Acceleration
d
Deceleration
sv
Space to reach the maximum speed
[t
Travel time
tt
Total mission time
s
Space to travel on x axis
\(\Delta {st}\)
Delta storage time between the LL and the model
stl
Storage time laboratory
stm
Storage time model
lul
Length of the unit load
vtransf
Velocity for on board transferring
ttransf
Transferring time
ls
Length of the shuttle
fsl
Rack front of the storage location
fin
Rack front of the input conveyor
tmeas
Travel time measured in the laboratory
tdep
Time to store/retrieve at a specific depth position
tcin
Time to load a UL from the input conveyor
tro
Time to calculate the route
tst
Time to start the storage process once in front a location
T
Matrix of travelling times
c
Number of columns in the rack
r
Number of tiers in the rack
tin
Time to reach the input points
nin
Number of input points
avgtin
Average time to reach the input points
tout
Time to reach the output points
nout
Number of output points
avgtout
Average time to reach the output points
p
Priority
pmin
Minimum priority
pmax
Maximum priority
pn
Priority normalised
sl
Storage location
SL
Set of storage locations
ultype
Type of unit load
For each travel axis, that is x-axis for horizontal movement, and y-axis for vertical movement, it was calculated the space needed to reach the maximum speed as
Then, in line with [36], we can consider acceleration and deceleration equal and constant, and thus the total travel time can be calculated as follows:
Since the MLS was designed in order to have space for two UL on board, if a UL needs to be transfer from front 1 (storage front of the input conveyor) to front 2, it is necessary to take into account also the transfer time ttransf. The UL can be also be moved on board in the storage location selected is in front 1. This happens for the types of UL that do not occupy entirely half the dimension of the HM. As a consequence, the transfer time can be calculated as follows:
$$\begin{aligned} ttransf={\left\{ \begin{array}{ll} \frac{\frac{ls}{2}-lul}{vtransf}, &{} \text{ if } fsl = fin\\ \frac{\frac{ls}{2}}{vtransf}, &{} \text{ if } fsl \ne fin \end{array}\right. } \end{aligned}$$
(4)
The MLS stars transferring the UL on board simultaneously while moving in the direction of the selected storage location. Therefore, the travel time t can be updated as follows:
$$\begin{aligned} t = {\left\{ \begin{array}{ll} t, &{} \text{ if } ttransf \le t \\ ttransf, &{} \text{ otherwise }\end{array}\right. } \end{aligned}$$
(5)
In addition to the travel and transfer time, there are other times when the MLS needs to perform other processes. After successfully completing the loading process, the MLS needs some time to perform post-processing activities, such as verifying the correctness of the operation, performing subsequent tasks, and calculating the next set of routes. Then, once the MLS has completed the movement to a storage location to perform a successive storage operation, it waits for a period of time to accurately adjust its position and check the correspondence between the expected status and the actual status of the storage location. The MLS then requires a certain amount of time to place the UL into a specific depth of a storage location. If the mission requires a UL to be loaded from the input conveyor, this time must be taken into account. Therefore, the total time to store a UL can be calculated as follows:
$$\begin{aligned} tt = tcin + tro + t + tst + tdep \end{aligned}$$
(6)
Since the MLS follows a PB inventory policy, each storage location is associated with a priority value determining the sequence followed to store the boxes within the warehouse. In order to calculate it, the matrix T(r, c), in which each element \(t_{ij}\) correspond to the time needed to move of i tiers and j columns, is generated. The values of each \(t_{ij}\) are calculated according to Eq. 3.
Then, the priority associated with each storage location, which determines the degree of preference in selecting that storage location, is calculated as the inverse of the sum of avgtin and avgtout, that is
For each storage location, the priority previously calculated priority is normalised, meaning a scaling transformation is applied so that the maximum priority value is 1 and the minimum priority value is 0, as
When the WMS sends a message to the WCS containing the task to be carried out, Algorithm 1 is executed. It first generates the mission to retrieve the UL from the input conveyor. Successively, it searches for an available storage location for the UL to be stored. If a storage location is found, the mission to store it at the specific AS/RS location is created. On the other hand, if no storage location is found, a mission to move the UL to the output conveyor is generated.
Algorithm 1
Generate missions algorithm
×
5 Model validation
5.1 The case study
The model previously illustrated in Section 4 was validated testing its performance with a case study. Specifically, an AS/RS installed in the the Logistics Laboratory (LL) of the Politecnico di Torino was considered. Figure 3 depicts the layout of the LL AS/RS. The system has a total surface of 68,6 m\(^2\) (2.795 m height) and it is equipped with a MLS.
Fig. 3
The layout of the laboratory AS/RS
Table 1
Different type of unit loads used in the laboratory
Type
Description
Length [mm]
Width [mm]
Height [mm]
Deep positions
1
Small short
300
400
120
1
2
Small high
300
400
220
1
3
Big short
600
400
120
2
4
Big high
600
400
220
2
×
The AS/RS of the LL has a single-aisle double-front storage rack composed of seven tiers and eight columns. In order to store the various types of UL handled (Table 1), the storage rack is designed with storage locations of different sizes. Half of them is 225 mm high and the other half 338 mm high. A further aspect to consider is that 22 of the storage locations are quadruple-deep (up to 2 ULs of type 1 and type 2, or up to 4 ULs of type 3 and type 4) and 68 are double-deep (up to 1 ULs of type 1 and type 2, or up to 2 ULs of type 3 and type 4). Finally, each storage location can store only one specific ULs at the same time. The AS/RS is also equipped with an I/O roller conveyor system. The I/O conveyors are perpendicular to the aisle and located in columns four and eight, respectively. The system is also provided with two working stations installed within the storage rack with gravity flow racks for parts-to-picker operations. The working stations are adjacent to the AS/RS and thus all parts are accessible from a single front, a design configuration deemed to be beneficial for reducing order times [37]. Moreover, the working stations are equipped with pick-to-light systems for parts-to-picker operations. Nevertheless, the picking process is not considered in this study.
All the technical specifications and parameters of the AS/RS are here summarised:
\(v_x\) = 4 m/s
\(v_y\) = 0.8 m/s
\(v_z\) = 0.5 m/s
\(a_x\) = \(d_x\) = 1.5 m/s2
\(a_y\) = \(d_y\) = 1.6 m/s2
\(a_z\) = \(d_z\) = 1.5 m/s2
\(v_t\) = 0.12 m/s
Command type = SC, DC, MC
Dwell policy = POSC
ULs on board = 2 (same type)
Tiers = 7
Column = 8
Deep positions = up to 4
\(v_{conv}\) = 0.5 m/s
\(a_{conv}\) = \(d_{conv}\) = 0 m/s2
Storage policy = PB
Retrieval policy = FCFS
Relocation policy = NN
The AS/RS installed in the LL and replicated in the AnyLogic environment is shown in Fig. 4.
5.2 Validation methodology
This research aims at validating the storage process of the DM to test its reliability in replicating the real system’s functioning and performance. To accurately structure the validation campaign in the LL, the DoE principles were adopted, selecting total storage time (ST) as the dependent variable, and UL type (ULT), total number of ULs (NUL), and starting storage capacity used (SSCU) as independent variables (as shown in Table 2). Considering multiple factors and multiple levels for each factors, a wide range of possible cases can be traced and thus demonstrate the reliability of the model.
Fig. 4
The MLS system in the AnyLogic environment
×
The factor ULT identifies the different types of ULs and it was considered since the warehouse handles the various types of ULs differently. The factor is subdivided into four levels (Type 1, Type 2, Type 3, Type 4), that is the four types of ULs that can be handled in the LL. The factor NUL determines the number of ULs inserted in the warehouse during each experiment, in order to test the performance of the model with simulations of different durations. Three different levels were chosen, that is 6, 13, and 20 ULs, respectively. The maximum level of 20 ULs was chosen as the maximum availability of Type 1 ULs in the LL amounts to 20. On the other hand, the minimum level of 6 ULs was selected arbitrarily. Finally, the intermediate level of 13 ULs was used as an average value between the maximum and the minimum levels. The factor SSCU defines the filling level when each experiment begins. This factor was included in the validation process since it has largely demonstrated its effects on the warehousing processes [38]. Three levels were selected, that is 0%, 27.5%, and 55%. The maximum level was chosen so that the total capacity of the warehouse would not be totally saturated once the locations were occupied at the end of the experiments. Specifically, it was considered to reach a maximum of around 90% of storage capacity occupied at the end of the experiment involving 20 ULs. The 0% level represented the exact opposite situation, that is a completely empty warehouse. The 27.5% level identifies an intermediate status where the warehouse is partially occupied. For each combination of factors, a replication of the experiment was performed.
Table 2
Design of experiment structure
Factors
ULT
NUL
SSCU
Levels
1
Type 1
6
0%
2
Type 2
13
27%
3
Type 3
20
55%
4
Type 4
\(-\)
\(-\)
Considering all the possible combinations of the levels of the factors (one factor with four levels and two factors with 3 levels) and the number of replications, a total of 72 experiments were conducted. Each experiment consisted in the following steps:
1.
The ULs to be used during an experiment were selected and prepared to be inserted in the warehouse;
2.
If not already, the MLS was moved in correspondence of the interface point with the output conveyor;
3.
The first UL was put on the input conveyor and the time measurement started;
4.
The other ULs were introduced in the warehousing guaranteeing always the presence of a UL to store;
5.
The time measurement ended at the instant when the MLS completes the storage of the last UL;
6.
Both the total ST taken to run the experiment and the information relating to the sequence of the storage locations selected by the MLS were recorded;
7.
The ULs used were retrieved to return the system to a state equivalent to the initial one.
Table 3
Validation parameters
Parameter [s]
Iteration 1
Iteration 2
Iteration 3
Iteration 4
\(tdep_{1}\)
5
\(\sim N(5.38, 0.16)\)
\(\sim N(5.38, 0.16)\)
\(\sim D1\)
\(tdep_{2}\)
6
\(\sim N(6.72,0.25)\)
\(\sim N(6.72,0.25)\)
\(\sim D2\)
\(tdep_{3}\)
7
\(\sim N(8.21,0.2)\)
\(\sim N(8.21,0.2)\)
\(\sim D3\)
\(tdep_{4}\)
8
\(\sim N(9.58,0.31)\)
\(\sim N(9.58,0.31)\)
\(\sim D4\)
\(tcin_s\)
4.5
\(\sim N(4.6,0.32)\)
\(\sim N(4.6,0.32)\)
\(\sim IS\)
\(tcin_b\)
4.5
\(\sim N(4.23,0.33)\)
\(\sim N(4.23,0.33)\)
\(\sim IB\)
tro
3
\(\sim N(3.28,0.43)\)
\(\sim N(3.28,0.43)\)
\(\sim RO\)
tst
\(-\)
\(-\)
0.8
0.8
Once all the experiments were conducted in the LL, they were exactly replicated in the simulation environment using the DM. At the end of a simulated experimental campaign, the results obtained were compared with the data from the physical experiments. Therefore, it was possible to calculate the \(\Delta {st}\) as
Then, some statistics on the \(\Delta {st}\) where calculated. In particular, the mean, the standard deviation, the inter-quartile range (IQR), the minimum and the maximum where considered. If the values of the statistics did not reflect the desired accuracy value, the worst experiments were identified, i.e. those with the highest and lowest \(\Delta {st}\) values. For these experiments, a deeper analysis was performed, in order to identify the issue generating the high values of \(\Delta {st}\). Specifically, the deviations between the times at different process steps were evaluated. It was measured the time elapsing from the moment when the last section of the input conveyor was activated, which allows the box to be loaded on the MLS, until the machine started moving (Step 1). Then, it was considered the time elapsing from the moment the MLS started to move until it was in front of the storage location, in order to validate the travel time calculated with Eq. 5 (Step 2). Furthermore, the time for completing the storage operation in the storage location was considered (Step 3). Finally, the time from the ending of the storage operation to the arrive of the MLS at the input conveyor was measured, also in this case to validate Eq. 5 (Step 4). This process allowed to identify discrepancies between the physical AS/RS of the LL and the simulated one. Once having identified the issues, the DM parameters were adjusted and the simulation campaign was entirely re-run and the \(\Delta {st}\) was recalculated. This procedure was done iteratively until the performances of the DM could be considered sufficiently precise in relation to the ones of the LL.
5.3 Validation results
A total of four iterations were completed. The differences between the model parameters set, the values of \(\Delta {st}\), and the statistics of the variable st for each iteration are summarised in Table 3, Fig. 5, and Table 4, respectively.
Fig. 5
The validation campaigns
Table 4
Descriptive statistics of storage time
Variable
stl [s]
\(stm_1\) [s]
\(stm_2\) [s]
\(stm_3\) [s]
\(stm_4\) [s]
Mean
275.7
254.5
267.2
277.5
277.3
Standard deviation
119.9
110.6
116.4
120.6
120.7
Minimum
124.2
113.6
116.7
123.1
122.9
1st quartile
134
125.8
130.7
135.5
133.8
Median
275.1
252.1
263
275.1
274.1
3rd quartile
414.4
381.4
399.2
419.6
418.1
Maximum
442.1
406.7
425.9
438.1
438.4
Range
317.9
293.1
309.2
315
315.6
IQR
280.5
255.6
268.4
284
284.4
×
The DM at iteration 1 was completely deterministic, with all the parameters set to fixed values. This choice relies on the fact that parameters of AS/RS model are generally considered as constant by academics [38, 39]. The values of \(tdep_1\), \(tdep_2\), \(tdep_3\), and \(tdep_4\) were calculated based on \(v_z\), \(a_z\), and \(d_z\), and by adding 3 s due to positioning movement made by the MLS when it is in front the storage location. Specifically, the MLS, once positioned in front of the storage location, slightly lifts the HM, moves the forks with the UL into the storage location, lowers the HM, return the forks, and finally lift again the HM. \(tcin_s\), \(tcin_b\), and tro were estimated according to plausible values. tst, that is the time elapsing from the arrival of the MLS in front of the selected storage location and the beginning of the storage process, was considered negligible. iteration 1 was the one with the lowest \(\Delta {st}\) median value and dispersion of values. In fact, the range went from \(-\)12.3% up to around \(-\)4.42%. Moreover, this result is also supported by the aggregate statistics shown in Table 4, where it can be noticed a general tendency of the DM in underestimating the total storage time. Additionally, by comparing the values of stl and stm, it was noticed that the DM was not able to replicate the variability of the system since it was completely deterministic.
Starting from iteration 2, it was decided to include some stochasticity within the DM. In order to do that, \(tdep_1\), \(tdep_2\), \(tdep_3\), \(tdep_4\), \(tcin_s\), \(tcin_b\), and tro were considered. A sample of 50 occurrences per fixed time was measured in the laboratory in order to estimate the probability distributions of the parameters. As shown in Table 5, an Anderson-Darling test was conducted to check the normality of the data. The results of the test, with all the p-values greater than the 5% threshold, demonstrate the possibility to approximate the values of the parameters to a normal distribution with known mean and standard deviation. Moreover, from the analysis of the single process steps of iteration 1, it emerged that the DM was consistently slower than the MLS in the LL at Step 2. This was confirmed by the laboratory measurement, which demonstrated that the MLS takes longer to perform the storage process.
After these modifications were implemented in the DM, iteration 2 was performed. The dispersion of the \(\Delta {st}\) slightly decreased, achieving a range between \(-\)7.1 and \(-\)0.52%. Nevertheless, the median value was equal to \(-\)3.13%. By observing the descriptive statistics of stl and stm, it was possible to notice a relevant improvement both in the mean, median, and standard deviation of the variable. Nevertheless, by analysing the trials at the extremes of the range of \(\Delta {st}\) values, it emerged that the MLS, once positioned in front of the location selected, delays a few instances before starting the storage process. Therefore, tst was introduced in the model.
After that, iteration 3 was performed. The median value of \(\Delta {st}\) settled at 0.66%, with a range from \(-\)3.75 to 3.55%. In addition, all the statistics of stm calculated showed small differences compared to stl.
In order to simulate the variability of the system as much accurately as possible, in iteration 4 it was decided to use the empirical distribution functionality provided by AnyLogic. It allows to not approximate the variables with known statistical distribution but to obtain random values based on the occurrences of that value in a dataset or a sample. Figure 6 depicts the empirical distributions of the model parameters. The results of iteration 4 showed limited improvements in \(\Delta {st}\), reaching a range from \(-\)2.71 to 3.38%, with median value equal to 0.49%. By observing Table 4, iteration 4 showed no relevant differences with iteration 3.
It can be finally stated that, after the iterative adjustments of the DM parameters, it was possible to build a DM accurately replicating the performance of the MLS in the laboratory. Moreover, it was demonstrated that is substantially equivalent approximate the values of the variables to known distributions and using the empirical distributions of data.
After each iteration it was also recorded the sequence of the storage locations selected by the MLS in the DM to store the ULs. This process was necessary to validate Algorithm 1. In the totality of the trials executed, the storage locations chosen in the DM and in the LL correspond.
6 Discussions and conclusions
This work provides a contribution to the existing literature on simulation modelling for DTs of AS/RS applications via the development and validation of a DES model of a MLS system. The simulation model is shown here in all its main components, including the IT systems architecture connecting the different parts of the AS/RS as well as the operational parameters and functioning algorithms. The validation of model is carried out by building an experimental campaign based on the DoE principles and comparing the output of the simulations with the performance of an existing AS/RS installed in a logistics laboratory.
Table 5
Normality test of parameters
Parameter
Sample size
Anderson-Darling
P-value
Mean
Standard deviation
\(tdep_{1}\)
50
0.255
0.716
5.38
0.16
\(tdep_{2}\)
50
0.262
0.689
6.72
0.25
\(tdep_{3}\)
50
0.214
0.843
8.21
0.2
\(tdep_{4}\)
50
0.194
0.889
9.58
0.31
\(tcin_{s}\)
50
0.404
0.342
4.6
0.32
\(tcin_{b}\)
50
0.475
0.231
4.23
0.33
tro
50
0.229
0.799
3.28
0.43
Fig. 6
Custom distribution of parameters
×
This work engenders some theoretical and practical implications. In terms of theoretical implications, this work has made some progress in one of the main research gaps of DT application of AS/RS, namely the lack of validation of the underlying simulation model. To bridge this research gap, this paper shows that AS/RS simulation models should be built around more detailed definition of the time functions of the AS/RS machine, both in terms of (i) breadth (i.e. the number of different time variables) and (ii) accuracy of the formulation. For the former, new variables are clearly defined as part of the travel time of the AS/RS, mostly referring to the idle times when the AS/RS is making decisions on the routing or adjusting its position with respect to the storage locations and I/O points. Hence, the proposed analysis facilitates the identification of parameters to be taken into account when developing DT-oriented simulation models that faithfully replicate the operation and performance of an AS/RS real system. For the latter, our work leads to some reflections on the use of AS/RS simulation models, as it shows that the assumption of deterministic and constant times compromises the accuracy of the model, in line with more recent developments in the field of simulation modelling of logistics processes [12].
The simulation model proposed in this study has also practical implications as it can assist logistics companies in assessing their operational requirements dynamically. This can lead to improvements in their warehousing operations by optimising storage allocation policies, order picking, and better process synchronisation. For instance, the model might support the synchronisation of arrivals and departures of a fleet of autonomous mobile robots connecting with the AS/RS operations. Furthermore, companies could use the proposed model to introduce variations in the underlying processes of the AS/RS, such as for instance dynamic UL allocation policies synchronised with the final customers’ orders, finalised to the reduction of the cycle time and maximisation of the throughput rate.
Finally, future research will point towards achieving a full-fledged DT application by enhancing the simulation model and the overarching DT architecture. With this regard, the simulation model will be integrated with the algorithm for UL retrieval, which will be focused on minimising total travel times and energy consumption. This algorithm will be validated following a similar approach as the one presented in this paper. Furthermore, the process of piece-picking will be added to the simulation model. This addition will entail the development of a sequencing algorithm for selecting the UL to be retrieved for the picking process. In terms of DT application, the current WMS and WCS infrastructure will be redefined and restructured to ensure two-way communication between the simulation model and the physical system. Only when data flows between a physical system and its digital replica in both directions, the full extent of a DT application is reached and the virtual system will have the ability to control the physical one [11].
Declarations
Conflict of interest
The authors declare no competing interests.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
