The mechanised car park problem

Parking shortage issues are not new. The mechanised car park concept, however, was a relatively new approach for tackling the issue at the time it was first considered in 2005 (Bekker & Viviers,2008). The concept was still in its design phase when a study was conducted as a simulation study to evaluate the effectiveness of the approach from a business standpoint. The study was successfully completed and its results are

documented inBekker & Viviers(2008). In 2016, a similar study was to be conducted, this time on a different and more modern simulation software package and with a new set of goals. The goals of the new study were essentially twofold: To solve the MCP problem again (i.e. find operational policies that would “optimise” the system’s outputs), and to demonstrate in the process the capabilities of the new simulation software. The study is the subject of this section and is briefly discussed below.

A mechanised car park is an automated parking system that provides parking ser-vices whereby the only request made to a client is to park and lock the car at an entrance parking lot on ground level. The car is then taken and stored by the main dynamic mechanisms of the system: a hoist and a vehicle transfer car (VTC). When the client returns, the system retrieves and delivers the car back to its owner using the same mechanism.

The system structure can be described as a parking garage consisting of shelves with closely packed cages (parking bays) where cars are stored. It is a multilevel structure that consists of m horizontal levels and three vertical layers, namely, the front, the back and the middle layer. The back layer is populated with parking bays (PBs). The front layer is similar to the back layer with the only exception that some of its PBs are lost in order to provide for n number of hoist shafts. The middle layer serves as a canal for VTCs and connects the front and back layers. Figure 3.1 illustrates the concept. The n PDs are park-drive areas where the cars are dropped off and retrieved from the MCP by clients whereas the n queue lanes are the different entrances to the MCP where clients wait should the PDs be occupied. (See Figure3.1.)

The MCP problem, thus, consists of finding efficient ways of operating the system such that the system’s outputs (i.e. the MCP problem objective functions) are opti-mised. This is achieved by effectively utilising the system’s resources (i.e. hoists and VTCs) through a set of operational policies. The goal is to maximise the system’s throughput (TR) i.e. the total number of cars stored in the MCP over a period of time, and minimise the system’s waiting time (W_T) i.e. the average time a client spends in a queue before being serviced. The MCP problem is complex. Its main modelling chal-lenge, for example, lies in the fact that the same resources must handle both storage and retrieval tasks, and must thus be capable of telling the difference between the two.

Moreover, the system is subject to the stochastic element, ξ, caused by clients’ random arrivals and returns to the MCP.

Figure 3.1: Schematic drawing of a mechanised car park (Bekker & Viviers,2008).

The system designs x in this problem are, therefore, the different set of policies to be generated by the analyst. x in this case is a decision vector such that x = (x₁, x₂, x₃) where x1 is the parking bay allocation (PBA) or storage policy, x2 is the entrance lane assignment (ELA) policy and x3 is the priority choice between arrival and departure service (PAD) policy. These policies are identified to be the main factors capable of influencing the MCP’s outputs (i.e. TR(x, ξ)) and WT(x, ξ)). Since only a relatively small number of system designs can be generated, the MCP problem can be considered as a small-scale SO problem. Furthermore, the set of decision variables in this problem is an example of categorical/qualitative decision variables (see Section2.2.1).

It is important to mention here that although this problem has two objective func-tions, it is not a multi-objective problem (as defined in Section 2.1) because the two objectives are not in conflict. In effect, maximising T_R(x, ξ) equates to minimising W_T(x, ξ) and vice versa.

3.1.1 Solving a small-scale SO problem with Tecnomatix

It is possible to do R&S with TPS using one of the software’s statistical tools for output analysis i.e. analysis of variance (ANOVA). The software itself does not, directly,

provide for an R&S procedure such as those presented in Chapter2. However, a simple procedure can be devised using TPS ANOVA. The procedure is briefly described below.

Once all system designs are identified, an initial number of replications r (e.g.

10) is used to run the simulation model with a confidence level of 95% (the default value in TPS). TPS then outputs results for all system designs (i.e. the estimated objective function values) with their respective confidence intervals (CI). If the analyst is satisfied with the largest CI half-width (h) observed, then the ANOVA results (which are provided automatically by the software) are used to select the best system design.

If, on the other hand, the analyst/user is not happy with h, they reduce it to a desired value h^∗. With this, a new number of replications r^∗can be calculated using the formula byLaw & Kelton (2000):

r^∗ = r h h^∗

2

. (3.1)

The simulation model is then run again and the ANOVA results are used to deter-mine the best solution. ANOVA (as done by TPS) does a pairwise comparison between all system designs of interest. The analysis is based on the hypothesis (H0) that the means of all r or r^∗ observations made on any two system designs (e.g. µi and µj, i 6= i) being compared are equal (i.e. H0 : µi = µj, i 6= j). A probability (p) is then calculated to indicate evidence against this hypothesis. If p is equal or smaller than a certain threshold value (often 5%) then this is considered strong evidence against the hypothesis and the two system designs being compared are said to differ statisti-cally significantly. Otherwise, they are said to be, statististatisti-cally-wise, identical. With this information, the analyst can then select the best solution with confidence. In cases where more than one objective function is being considered, a separate ANOVA is made for each. The result of ANOVA in TPS is presented in a table format containing all p-values, from which the analyst must make a selection based on the observed p-values.

3.1.2 Specifics of the MCP problem solved

In the MCP problem that was solved with TPS, the number of levels was l = 11 and the number of hoist shafts was n = 6. In total, the system had 440 PBs with 40 PBs in each level.

10 PBA, 3 ELA and 1 PAD (first come first served) policies were generated, amount-ing to an overall of 30 system designs that were evaluated for efficiency. It is important to note that during the study, it was found that PBA policies, in general, had way more influence on the system’s outputs than ELA policies. The approach that was used to generate PBA policies will now be discussed briefly.

It was discovered that the MCP could be viewed as a matrix (Figure3.2) with each cell representing a PB. Thus, various ways of searching this matrix for available PBs could be created with TPS, taking into account the limited number of resources (i.e.

hoists and VTCs). Ten search patterns were created to look for unoccupied PBs in the matrix (PBA1-PBA10). These were combined with three ELA policies (ELA1-ELA3) to generate a total of 30 system designs. All system designs used a first come, first served approach with regards to the PAD policy.

Figure 3.2: Schematic view of the MCP as a matrix.

3.1.3 Results and limitations

An extract of the actual results that were obtained for the problem is presented here and the current limitations of the software are discussed.

Table3.1presents the top nine results that were obtained. It can be seen that some of these results are very close to each other. This is, in effect, where R&S procedures draw their importance as these numbers are mere estimates. The closer their true values, the higher the chances that the observed better one is not the actual better one (Teng et al.,2010). For example, though System design 1 appears to be numerically the best, we learn from Table3.2 that actually, the difference between System designs 1 and 2 is not statistically significant. Thus, the analyst can either choose to go for a higher r (i.e. a lower h), or, because the desired h (i.e. h^∗) was already selected

Table 3.1: Top nine results for the MCP problem.

System design PBA Policy ELA Policy TR WT

1 3 1 5775 04:58.4

Table 3.2: TR ANOVA results.

System design 2 3 4 5 6 7 8 9

in this case, be indifferent in choosing between the two designs (with regards to TR).

Note that a similar table to Table3.2also exists for W_T and may give the analyst more information about Designs 1 and 2. For example, the W_T ANOVA results may indicate a significant difference between Designs 1 and 2, in which case, the analyst would no longer be indifferent in choosing between them but rather choose the better of the two.

A major drawback in this R&S procedure is that r^∗ replications are allocated to all system designs. Although this guarantees that all designs have h values that are within the desired h^∗, the approach is not efficient as it can be computationally expensive.

(This is an example of a procedure that uses the LFC assumption mentioned in Section 2.4.1.1). There are more efficient techniques in the literature (see Section 2.4.1) that

have the ability to intelligently allocate simulation replications among system designs while still maintaining the desired confidence level. Moreover, even though one may consider the results obtained here as good, it follows from the work done byBechhofer (1954) that ANOVA is not the ideal approach for R&S purposes. (See Section2.4.1.)

In the next subsection, the second problem is discussed. The problem demonstrates Tecnomatix Plant Simulation capabilities but also limitations in handling large-scale SO problems, especially those with multi-objectives.