A new constraint programming model and solving for the cyclic hoist scheduling problem

The cyclic hoist scheduling problem (CHSP) is a well-studied optimisation problem due to its importance in industry. Despite the wide range of solving techniques applied to the CHSP and its variants, the models have remained complicated and inflexible, or have failed to scale up with larger problem instances. This article re-examines modelling of the CHSP and proposes a new simple, flexible constraint programming formulation. We compare current state-of-the-art solving technologies on this formulation, and show that modelling in a high-level constraint language, MiniZinc, leads to both a simple, generic model and to computational results that outperform the state of the art. We further demonstrate that combining integer programming and lazy clause generation, using the multiple cores of modern processors, has potential to improve over either solving approach alone.


Introduction
Hoist scheduling is an abstraction of a real-life scheduling problem. In the hoist scheduling problem we must specify the operation of an industrial hoist which moves along a linear track above a set of tanks. The problem originally arose in automated electroplating lines, but applies to any process where robots transfer items between the process tasks.
Mathematically, hoist scheduling is interesting because at its heart is a complex disjunctive constraint involving three temporal variables, as well as resource variables. Variants of the problem have features such as time windows for how long an object may dwell in each tank, optional tanks, multi-capacity tanks, classes of objects, multiple hoists, multiple tracks, slippage in movement, etc. [3,7]. We use the term hoist rather than robot, and

Problem formulation
The basic form of the cyclic hoist scheduling problem is as follows. A single hoist operates on a single track above a sequential line of N tanks. A number of identical jobs are placed at the initial stage (0) of the line. Each job is to be processed through the tanks according to a fixed scheme of treatments, and finally be placed at the far end of the line (stage N + 1).
Hoist scheduling is distinguished from classical scheduling problems, such as flowshop or jobshop, in that a job under process is either in a tank or held by a hoist. It cannot be left idle until a resource is available. Second, travel times of an operation are not negligible. In addition, to reflect the industrial situation, it is typical for the prescribed processing times in the tanks to be bounded in a time window.
Let the number of treatments be T , and the sequence of treatments be i, i = 1, . . . , T . For the ith treatment, a job must be placed into tank S(i) and removed within the time window of the treatment. Let the minimum and maximum times in the tank S(i) for treatment i be m(i) and M(i) respectively.
The time the hoist needs to move a job from tank S(i) to tank S(i + 1) is denoted F (i) 1 while the time the hoist needs to move unloaded (empty) from tank n to m is denoted E(n, m). 2 Note that an earlier job can be still under process in a later treatment, when a new job is picked up by the hoist from stage 0 for its first treatment. However the number of jobs being treated in the same tank at the same time is limited by the tank capacity. Let the capacity of the tanks be C(n), n = 1, . . . , N. In the unit-capacity case, C(n) = 1, ∀n.
It suffices to have as decision variables the removal time upon completion of each treatment, which we denote R(i), i = 0, . . . , T , a variable B(i), i = 1, . . . , T for the number of jobs in each treatment i at the end of the cycle, and the cycle period P .
This definition exploits an important fact about a cycle. During a single cycle exactly one new job is introduced, and one job is completed. Therefore in each cycle each treatment i is completed for just one job. If no job is removed from treatment i, then the tank S(i) would collect all the jobs, and if more than one job was removed then eventually the tank would starve -because only one job arrives in each cycle.
We observe however that almost all previous models have used many additional variables: often a variable for the completion of each treatment for each job under process during the cycle, as well as multiple binary variables. For this reason most models require the maximum number of jobs under treatment in a single cycle, J , to be given as an input. Our model does not require such a maximum.
The CHSP objective is to maximise throughput, i.e., to minimise P while satisfying constraints about hoist movement, tank capacity, treatment sequence and processing time windows.
For simplicity, we will assume sequential treatment. This means S(i) = i, i = 0, . . . , N. Thus the sum (which is the time required for a hoist to move a job from S(i) to S(i + 1) plus the time to move empty from S(i + 1) to the tank S(j ) for treatment j ) can be shortened to Figure 1 gives a numerical example. A straightforward schedule has a cycle of period 50 minutes, whereas the optimal schedule has a cycle of period 20 minutes.
1 F (0) is the time to move a new job from stage 0 to tank S(1), and F (N) is the time to move a completed job from tank S(N) to stage N + 1 2 E(n, 0) is the time for the hoist to travel from tank n to stage 0, and E(N + 1, m) is the time for the hoist to travel from stage N + 1 to tank m

A compact model for hoist scheduling
We first present a simple model for the problem with unit capacities and one hoist. We call this the CUC1H model. In the following sections we generalise the model and compare it to existing models.

Constraint for fixed number of jobs, J
Symmetry breaking constraint

Bounds computation
We compute static initial lower (P lb ) and upper (P ub ) bounds on the period variable P thus: The upper bound covers the worst case where the hoist simply follows one job from start to end. The lower bound sums all the necessary full hoist movements and the subsequent minimum empty movements (except if the empty move is to wait at the next tank, necessarily for the minimum tank processing time). In this model the time of every movement is relative to the start of the current period. The constraint (1) requires all removals to occur within the cycle period.
The constraint (2) enforces the minimum and maximum soak times in each tank. The expression R(i − 1) + F (i − 1) represents the time the job is placed in tank i. If the job is removed from tank i at a time R(i) later in the cycle than it was put in, then R(i) lies between R(i − 1) + F (i − 1) + m(i) and R(i − 1) + F (i − 1) + M(i). In this case there will be no job in the tank at the end of the cycle, so B(i) = 0. However if the job is in the tank i at the end of the cycle, then B(i) = 1, so R(i) ≤ R(i − 1) + F (i − 1) (by constraint 5) which means that after a job is entered in tank i (at time R(i − 1) + F (i − 1)) it stays in the tank until removed (at time R(i)) in the next cycle.
Another important fact about hoist movements underlies constraint (3). The time required to go directly from tank i to tank j is always less than the time required to go from tank i to some other tank and from there on to tank j . 3 This the usual triangular inequality saying a straight line is the shortest distance between two points. Figure 2 shows a feasible cycle for a hoist to remove jobs from tank 0 at time t0, tank 2 at time t1 and tank 1 at time t2. The empty movements ma, mb and mc need enough time for the hoist to be ready for the next removal.
The constraint (3) ensures that the hoist is never scheduled to do two things at once. Consider any two removals R(i) and R(j ). Assuming R(j ) occurs after R(i), then if these are successive removals then R(j ) ≥ R(i)+F (i)+E(i +1, j). If the hoist does other removals (from tanks k 1 , k 2 , etc.) in between, then the triangular inequality and the constraints on R(i) and R(k 1 ), on R(k 1 ) and R(k 2 ) etc. will ensure R(j ) > R(i)+F (i)+E(i +1, j). The other alternative is that R(j ) occurs before R(i) and the same argument applies. Constraint (4) extends constraint (3) to preclude an overlap in the case where R(i)+F (i)+E(i+1, j) ≥ P . In this case potential clash would be between R(i) and R(j ) + P .
The next constraint (5) is the one that enforces B(i) = 0 in case a job is removed from tank i after one has been loaded into the same tank earlier in the cycle, i.e., R(i) ≥ R(i − 1) + F (i − 1). In this case, constraint (2) On the other hand, if the removal occurs earlier in the cycle than the loading of tank i, i.e., R(i) ≤ R(i − 1) + F (i − 1), then constraint (2) entails that B(i) = 1.
The equality can only happen if the job is removed from the tank at the same time it is entered. Informally there are three ways this could happen: (1) If the same hoist dips the job in the tank for zero time which makes no sense (2) The same hoist removes a job which started one (or more) period(s) before at the same time as dropping the original job in the tank (3) Two hoists handle two jobs exactly one period apart (2) and (3) involve two jobs being in the tank (for zero seconds) while the hoist drops the first and picks up the second.
The constraint (6) ensures that the end of the cycle (and the entry of the next job in tank 1) occurs after the previous job has been removed from the last tank, N . The constraint on the number of jobs concurrently in process, in case it is specified in the input, is enforced by constraint (7). (For models that do not need to constrain the number of concurrent jobs, this can be omitted.) The final constraint is redundant, but since we can always set the time to zero when a new job enters the system, constraint (8) does so, and removes all the symmetrical cycles which begin at other times.
In short this model CUC1H comprises just six essential constraints.

Previous models
There are over 20 research papers on the basic unit capacity single hoist problem, and it is surprising that none have devised as simple a model as presented here.

IP models
The most recently-published IP model for the basic hoist scheduling problem is by [5]. This builds on the previously-published models repairing shortcomings in earlier work with IP, and eliminating redundant constraints. The model requires eight constraints to impose the soak times, expressed in our model by constraint (2). The first two of these are: where BigM is some sufficiently large number. The binary variable W (i) indicates whether move i goes across the cycle. The remaining six constraints enforcing soak times capture different combinations of minimum and maximum, and combinations of the job remaining in the tank over a cycle or not, and the move i − 1 crossing the cycle or not.
Dealing with this additional array W of variables requires additional constraints on the period P : Ultimately this 'improved' model deploys over 20 constraints to express the basic hoist scheduling problem.

CP models
The previous models of hoist scheduling in CP [1,17,18] all consider the whole period that a job is in process. If there are, for example, 5 jobs in process at any time, this period is 5 times the duration of a cycle (implying the number of jobs must be an input in such models). As a result the constraints become larger the more jobs in process -hence the constraint (7) which typically occurs in CP models but not in IP models. Indeed the central constraint in [18] is equivalent to our constraint (3) but must be applied to every k ∈ 1 . . . J :

Comparison
The IP models in the literature are complicated to understand, and complicated to adapt for new constraints as will become clear in the next section. Their performance when handled by an IP solver could prove to be better than the CUC1H model, since these models are tailored for the IP solver. We examine this empirically in Section 6. By contrast, the previous CP models are easier to read and extend than IP models, but suffer from performance problems when there are multiple jobs in process at any time.

Multiple hoists and larger capacity tanks
The extension to the CUC1H model to cope with the extended CHSP problem is straightforward. We call this the CECnH model. The constants and data are as described in Section 2. In addition, H denotes the number of hoists, A the number of tracks, and C(i) ≥ 1 the capacity of tank i. Either A = H in which case each hoist runs on its own track, or A = 1 and all the hoists run on one track. 4

Additional decision variables
The handling of capacities is simply done by increasing the bound on B(i), so that it is an integer-valued rather than 0, 1. If, for example, B(i) = C(i) then there are C(i) jobs in tank i at the end of the cycle, which is the maximum possible. Constraint (9) replaces (5), which it generalises.

Additional constraints
If there is only one hoist, it starts the first action (removing a job from tank 0) at the start of a cycle, so no action continues across the end of a cycle. However, as evident from Fig. 3 (left), only one hoist has a treatment starting at time t0. For the other hoist a constraint is needed to ensure time for the empty movement md over the end of the cycle. The constraint (10) extends constraint (4) to handle this case.
The constraint (11) is an extension of constraint (3) in the CUC1H model. This is the model for A = 1, where all the hoists are on the same track.
The interesting case illustrated in Fig. 3 (right) has the thick hoist 'below' the thin one on the track, but the thin hoist removes from tank 1 which is 'below' tanks 2 and 3. In this case the time needed for the dotted 'virtual' empty moves are enforced by (11) giving time for the thin hoist to get out of the way of the thick one.
By contrast to the CECnH model, many new constraints and variables are required to extend the IP model. We give one of the four 'collision avoidance' constraints: is a further binary variable indicating whether hoist k removes jobs from tank i. Although easier to extend than IP models, previous CP models are also more complex to extend than our model -for example requiring various auxiliary boolean variables. Researchers tackle many minor variations of a particular CHSP problem. One difference between the CECnH model and [5]'s IP model is accounting for the time p(i) required to unload a part from a tank -while the hoist stays at the same location -and the time q(i) required to load the tank. This prevents one hoist loading a tank when another is unloading it. It is handled by three further IP constraints: The modification required to the CUC1H model to ensure it returns precisely the same solutions is simply to extend constraint (5) thus:

Global constraints
CECnH does not use global constraints. An option is to introduce the cumulative constraint to the model. However, for each of the hoist tasks, its duration depends on where is the next task. This is because there is no variable in the model representing the successor task. Thus cumulative only has a lower bound on the duration and is unlikely to achieve substantial additional pruning to justify its overhead. In order to assess the value of cumulative, we study two variants of CECnH with cumulative constraints in Section 6.

Empirical analysis
We implemented the extended model of Section 5 in the high-level constraint language MiniZinc [14]. In this section we report empirical results on benchmark CHSP instances. To be compatible with previous benchmarks we adopt the one-track option (A = 1), and set p = q = 0.
As solvers we first compare the constraint programming ('CP') solver Gecode version 6.2, the integer programming ('IP') solver Gurobi version 9.0.1, and the lazy clause generation ('LCG') solver Chuffed version 0.10.4. We later introduce a straightforward hybrid IP-LCG approach. Default settings were used for each solver , i.e., solvers could ignore any model-specified search heuristics if they wished. We used no specific search or symmetry-breaking annotations.
Experiments were performed on a machine with a 12-core Intel Core i7 processor at 3.2GHz, and 16GB memory. The model was implemented in MiniZinc version 2.4.3 and compiled for each of the solvers using the standard MiniZinc settings and optimisation flag 'O1'. The models and datasets are available at: https://doi.org/10.4121/12912413. 5 Linearisation for the IP solver was done automatically by MiniZinc [2]. Research on MiniZinc model linearization has ensured even CP MiniZinc models generate good IP models -as proven on MiniZinc benchmark set. Note that IP models in MiniZinc simply map to the same IP model in the underlying solver, so solving time is unaffected.

Benchmarks
First we take two standard benchmarks from the literature, 'P&U' [16] and 'BO1' [12]. Both datasets originate from real-life industrial lines. Since these benchmarks are not considered difficult for the single-part single-degree CHSP [5], we study extended benchmarks in which the line and treatments are multiplied, as follows.
For each benchmark with tanks 0, . . . , N and multiplier M ≥ 1, we create a benchmark with tanks 0, . . . , N · M. For 1 ≤ k ≤ N , the properties of the k th tank are copied on to M further tanks, and similarly the value of F (k). For the empty movements, we want a non-zero time to travel between different copies of the same tank. We do this by adding 5 between the first and second copy, 10 between the first and third copy, etc. These numbers were chosen to be of the same order of magnitude as the other empty movements E(i, j ) in the benchmarks. Specifically, let i m1 be the m1 th copy of tank i, and let j m2 be the m2 th copy of tank j . Then E(i m1 , j m2 ) is set to E(i, j ) + 5 · |m1 − m2|.
In addition to these extended benchmarks, we also study random instances, generated according to the specification of [5]. We emphasise that no previous model has been benchmarked on instances with a multiplier M > 1.

Results and discussion
Global constraints with Chuffed First, in a preliminary experiment, we study our CECnH model with the Chuffed LCG solver. As noted earlier, the global constraint cumulative can be added to the model as a redundant constraint as follows in MiniZinc: Schutt et al. [19] defined specific LCG explanations for cumulative: both for cumulative's time-tabling and time-tabling edge finding. 6 Thus the following MiniZinc annotations can yield more powerful propagation: For the problem P&U, Table 1 reports the results of Chuffed on CECnH with no cumulative constraint (column 3). Column 'Instance' shows the tuple Multiplier -Hoists -Capacity; column 'Optimum' shows the optimal period P . Times are shown in seconds.
Adding the cumulative constraint (column 4) brings a little gain on smaller instances but is a little worse on larger instances, whereas also using the time-tabling annotations (column 5) does bring a consistent gain.
In order to fairly compare across models and solvers, we use the base version of CECnH, with no cumulative constraint, in the remainder of the experiments below. Table 2 shows the results of the three models: our model CECnH, the IP model of [5] (re-implemented in MiniZinc), and the CP model of [17] (also re-implemented). Times are shown in seconds. We solve all models with an IP solver, and the two CP models also with a CP solver. Time limit 1 hour. 1 core. Times are shown in seconds. If the solver could not find and prove the optimum within the time limit, the upper bound obtained is shown in italic. '*' indicates the model proves a sub-optimal solution for the instance. '-' indicates the model cannot solve the instance Note that [5]'s model does not take account of non-unit tank capacities, and so, while it finds solutions for such instances, the period is sub-optimal. These entries are marked by an asterisk.

Models compared on real-world instances For the problem P&U,
From the table we see that our model is faster, overall, than the IP model from the literature by a factor of 1-2, and is faster than the CP model from the literature by up to an order of magnitude when the problem size grows (M > 1) -whether the CP or IP solver is used as the solving backend. Indeed, without search guidance the previous CP model cannot find any optimal solution within the timeout when a CP solver is used on it. Tables 3 and 4 show the results of the three solvers on our model. Overall, the best performance of solvers using 1 core is by LCG. Below we discuss use of multiple cores, but already from the tables we see that the best performance overall is either from IP with 4 or 8 cores, or from LCG. For P&U, for example, IP is best for the small (Multiplier 1) instances, but struggles in comparison with LCG for the medium instances (Multiplier 2); for the largest instances IP again has the edge. As also seen in Table 2, we observe that the pure CP solver has uniformly inferior performance. Table 5 shows results on 360 random instances (10 for each parameter setting), generated with the same parameters as [5]. In this table we show [5]'s IP model in addition to our model CECnH. Table 6 shows results on 100 random instances of larger size, generated as described earlier.

Solvers compared on random instances
As before we compare CP, IP and LCG solvers. The instances of [5] are not difficult for any solver. When using IP, our model (when linearised) is also faster by an order of Time limit 1 hour. If the solver could not find and prove the optimum within the time limit, the bounds obtained are shown in italic. '-' indicates no (sub-optimal) solution or bounds information returned by the solver Effect of multiple cores for IP solving Since the version of Chuffed available to us exploits only a single core, for fair comparison we focused on solvers running on a single core in the experiments so far. However we are interested in exploiting multiple cores, and so  we studied Gurobi's performance with 2, 4 and 8 cores. These results are also included in Tables 3 and 4, columns 'IP-ncore'. The literature suggests that IP "parallelism efficiency decreases for more than 4-8 threads" [9] (see also [4]). We find a similar pattern. The tables' columns 'IP', 'IP-2core', 'IP-4core' and 'IP-8core' indicate that increasing the number of cores for Gurobi up to 4 almost always decreases the runtime (or gives tighter bounds within the time limit). However, when we increase the number of cores further, performance sometimes improves and sometimes declines. Increasing the number of cores to 12 was only neutral or negative to performance.

Exploring IP-LCG hybridisation
That neither IP and LCG dominate each other on the real-world CHSP benchmarks points to the value of exploring hybrids of the two. We consider two hybrid approaches exploiting the multiple cores of modern processors. The first is a simple portfolio approach, while the second hybrid communicates lower bounds between the solvers.
Consider a machine with n > 1 cores. The simple hybrid ('SH') uses n − 1 cores for Gurobi and 1 core for Chuffed. Both solvers run on the problem instance, and whichever finishes first gives the solution. If neither prove the optimal solution within the time limit, we take the tightest bound information from the two. In the experiments below, we take n = 4 and use 3 cores for Gurobi.
The second hybrid approach runs Gurobi with g < n cores and runs n − g separate parallel Chuffed solver instances with (different) fixed period P , i.e., with the constraint P = p for a given p which differs between the Chuffed instances; we called these fixedchuffeds. We call this the parallel hybrid ('PH') approach. The idea is that the fixed-chuffeds improve the lower bound of the overall search. In particular, let be the current lower bound of Gurobi. Then in the parallel hybrid, the fixed-chuffeds have as their periods P = , + 1, . . . , + n − g − 1.
The Gurobi instance and the n − g fixed-chuffed instances are coordinated through the current bounds on the period. We implemented this approach using Gurobi's callback functionality and lazy constraints. Whenever Gurobi increases its lower bound , any fixedchuffed instance that is thus rendered obsolete (because its p < ) is terminated. 7 On the other hand, whenever a fixed-chuffed of period p completes, there are two possibilities. For simplicity, suppose the fixed-chuffed of period p = terminates. Either it has proved that P = p is infeasible, in which case we can increment by 1; or it has found a solution of period P = p, which must be the optimal solution since p is the current lower bound. Table 7 Results on P&U instances  Time limit 1 hour. Times are shown in seconds. If the solver could not find and prove the optimum within the time limit, the bounds obtained are shown in italic. The 'SH' and 'PH' columns are parameterised by a pair (a, b), the number of cores for LCG (a) and IP (b) respectively Should a fixed-chuffed of period p > + 1 finish, a little more book-keeping tells us when we can push up the lower bound or declare the optimum found -or neither as yet. Table 7 gives the results of the simple and parallel hybrids over 4 cores, compared to 1core Chuffed and 4-core Gurobi. The table shows selected easy and hard instances from the first real-world dataset. It is worth emphasising that LCG's performance is on 1 core while the other solvers all use 4 cores.
As seen earlier in Table 3 for this problem, LCG and IP perform differently on different instances, while we now see that the hybrids can perform robustly. Only on very easy instances (i.e., M = 1, not shown in the table) the overhead of the parallel hybrid dominates its performance.
The parallel hybrid performs well on the M = 2 instances, and the simple hybrid on M = 3 and M = 4 instances. Note that instances 3-2-2 and 3-3-1 are examples of a problem where Gurobi does better with fewer cores than more (i.e., 3 instead of 4). The best combination of core usage, overall, for the parallel hybrid is 3 cores for fixed-chuffeds and 1 core for Gurobi. On instances where the parallel hybrid has a poorer optimum (upper bound) than the other solvers, i.e., M = 3 and M = 4, it has a better lower bound due to it putting more search effort there.
Taken together, the exploratory results suggest that there is potential in hybrid IP-LCG approaches, as we discuss further at the end of the article.

Related work
The problem addressed in this article is cyclic hoist scheduling with identical parts and single-degree schedules [16]. The most popular exact methods for this problem are (mixed) IP (i.e., branch-and-cut) and custom branch-and-bound, such as [22]. The first constraintbased approach was by [1]. Meta-heuristic approaches were proposed by, for instance, [13] who developed a genetic algorithm, and [21] who developed a tabu search and repair procedure.
The same pattern of IP, custom branch-and-bound, or meta-heuristics is found in the literature for variants of the basic CHSP, including for multi-part lines with multi-degree cycles, or systems with multiple lines [3,7,20]; a typical example is [8].
Hybrid methods for the CHSP also deserve more attention than in the literature to date. [18] introduced the idea of modelling the generic CHSP with a single, parameterised CP model, and solved it using a loosely-coupled CP-IP hybrid. Other works adopting hybrid methods consider specific CHSP settings. For instance, [6] propose a two-stage approach for two hoists consisting of a custom heuristic followed by IP, while [23] hybridise two forms of evolutionary algorithm.
The HSP is related to but distinct from the problems of (un)loading ships in a container terminal with port and yard cranes [10,11], and of scheduling cranes in a factory. For the latter problem, [15] present a dynamic decision tree approach, which would be interesting to consider for the HSP.

Conclusion and future work
This article re-examined modelling of the cyclic hoist scheduling problem and proposed a new and more simple model. At its heart this constraint programming model has only six constraints, and is easily extended to variants such as multiple hoists and tracks. We applied state-of-the-art IP and LCG solvers with the new model on a range of benchmarks, including new larger benchmarks than before studied in the literature. Besides presenting the first application of LCG to the CHSP (to our knowledge), we showed that by using MiniZinc we can model the CHSP more simply, compactly and extensibly than previous modelling approaches, and can run IP and LCG solvers on any model instance.
Empirical results show, first, that our model has better computational properties than previous CP-based or IP-based models, and, second, that IP and LCG solvers have different strengths in solving effectiveness. We further presented a parallel hybrid of IP and LCG that coordinates between solvers using lower bounds on the period in a simple way. The results show that hybridisation has potential on more difficult problem instances. The next step in our work is to extend to more variants of the CHSP, such as problems with multiple parts. Second, we would like to experiment further with modelling using interval constraints, since our models with these constraints (not reported here) are uncompetitive to date. It will also be interesting to explore the possibilities for global constraints in such a representation, especially for LCG solvers [19]. Third, we think there is ready potential to further explore forms of hybridisation that bring together the complementary performance of IP and LCG, for instance through communicating upper bounds, and logic-based Benders decomposition.