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

Abstract

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.

1 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 treatment rather than task, to remain consistent with the literature. We refer to an object that undergoes a series of treatments as a job.

The cyclic hoist scheduling problem (CHSP) assumes a fixed sequence of jobs to be processed. The challenge is to allow the processing of successive jobs to overlap, so that (different) treatments on different jobs may be carried out at the same time. The schedule of treatments for one job is repeated for subsequent jobs, giving the problem its cyclic nature. The length of a cycle is the time between the start of processing for a job and that of its successor. (Observe that in the absence of overlap the cycle time is the whole process duration for one job.) The usual aim is to minimise this cycle time by maximising the overlap – and for a large overlap there may be many treatments in process simultaneously.

When many treatments are simultaneously in process, the hoists have to be available to complete all the moves between treatments. Moreover, each hoist must itself travel from the end of the last move that it performed to the start of the next move. Thus hoist availability is a complex resource constraint. The challenge is to find a feasible schedule that minimises the cycle time, which is termed its period. The central disjunctive constraint in the CHSP connects the period with the temporal decisions about hoists [18].

Given its practical and mathematical importance, an impressive role call of solving techniques have been brought to bear on the CHSP. As surveyed by [3, 8], the techniques include (mixed) integer programming (IP), constraint programming (CP), evolutionary algorithms, bespoke branch-and-bound and heuristics, and many meta-heuristics. With a few exceptions, the literature develops complex, custom models for the particular CHSP variant under study. Despite the wide range of solving techniques applied to the CHSP and its variants, the models have remained complicated and inflexible and have failed to scale up with larger problem instances. To our knowledge no methods have been applied to problems with more than 20 tanks.

This article presents two contributions. First, we re-examine modelling of the CHSP and propose a new constraint programming formulation. This new model is significantly simpler than those in the literature while being able to accommodate several variants of CHSP with minimal modification.

Our second contribution is to solve our model with different optimisation approaches using single and multiple cores: integer programming, lazy clause generation, and an example hybrid which combines both approaches. To support this flexibility our model is implemented in a generic modelling language, MiniZinc [14]. We compare its performance on standard and new benchmark problems against results reported in the literature. We show that, with our model, current state-of-the-art IP and LCG solvers can be used off the shelf to obtain computational results that outperform models from the literature.

The next section introduces the CHSP. Section 3 explains our basic model and Section 4 discusses how it differs from previous models. Section 5 extends the model to more complex CHSP instances. Section 6 performs an empirical study. Section 7 discusses related work and Section 8 concludes the article.

2 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,\dots ,T$. For the i th 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)¹ while the time the hoist needs to move unloaded (empty) from tank n to m is denoted E(n,m).²

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,\dots ,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,\dots ,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,\dots ,N$. Thus the sum

$$F(i)+E(S(i+1),S(j))$$

(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

$$F(i)+E(i,j).$$

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.

Fig. 1

Example of a simple cyclic hoist scheduling problem

3 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.

Decision variables

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} R(i) & i=0,\dots,N & \text{removal times} \end{aligned}\\ &&\begin{aligned} B(i) & i=1,\dots,N & \text{$B(i)=1$ iff there is a job in tank \textit{i} at the end of the cycle} \end{aligned}\\ &&\begin{aligned} P & \qquad\qquad\qquad\quad & \text{cycle length or \textit{period}} \end{aligned} \end{array} $$

Initial bounds

$$ \begin{array}{@{}rcl@{}} 0 \leq R(i) \leq P_{ub} &\quad i=0,\dots,N \\ B(i) \in \{0,1\} &\quad i=0,\dots,N\\ P_{lb} \leq P \leq P_{ub} \end{array} $$

Objective

$$ \min P $$

Required constraints

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} R(i) \leq P \quad\qquad\qquad\qquad\qquad\qquad\qquad \forall i \in [0,N] \end{aligned} \end{array} $$

(1)

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} R(i-1) + F(i-1) + m(i) &\leq R(i) + P \cdot B(i) \\ &\leq R(i-1) + F(i-1) + M(i)\\ & \quad\qquad\qquad \forall i \in [1,N] \end{aligned} \end{array} $$

(2)

$$ \begin{aligned} R(i) + F(i) + E(i+1,j) \leq R(j) &\vee R(j) + F(j)+ E(j+1,i) \leq R(i)\\ &\qquad \forall i \in [0,N-1], j \in [i+1,N] \end{aligned} $$

(3)

$$ \begin{aligned} R(i) + F(i) + E(i+1,j) \leq R(j) + P & \forall i \in [1,N], j \in [0,N], i \not= j \end{aligned} $$

(4)

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} R(i) \leq R(i-1) + F(i-1) + P \cdot (1-B(i)) &\quad\qquad\! \forall i \in [1,N] \end{aligned} \end{array} $$

(5)

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} P \geq R(N) + F(N) \end{aligned} \end{array} $$

(6)

Constraint for fixed number of jobs, J

$$ \underset{i}{\sum} B \leq J $$

(7)

Symmetry breaking constraint

$$ R(0)=0 $$

(8)

Bounds computation

We compute static initial lower (P_lb) and upper (P_ub) bounds on the period variable P thus:

$$ \begin{array}{@{}rcl@{}} P_{lb} &=& F(N)+\sum\limits_{k = 0}^{N-1} F(k)+\min(\{m(k+1)\} \cup \{E(k+1,j) | j \neq k \in 0..N\})\\ P_{ub} &=& F(N)+\sum\limits_{k=0}^{N-1} F(k)+m(k+1) \end{array} $$

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.³ 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.

Fig. 2

One hoist and two tanks

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₁,k₂, etc.) in between, then the triangular inequality and the constraints on R(i) and R(k₁), on R(k₁) and R(k₂) 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) enforces that R(i − 1) + F(i − 1) + m(i) ≤ R(i). 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.

4 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.

4.1 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:

$$ \begin{aligned} R(i)-(R(i-1)+F(i-1)) \leq M(i) + BigM\cdot(B(i)+W(i-1)) \quad \forall i \in [1,N] \\ R(i)-(R(i-1)+F(i-1)) \geq m(i) - BigM\cdot(B(i)+W(i-1)) \quad \forall i \in [1,N] \end{aligned} $$

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:

$$ \begin{aligned} &R(i) \leq P &\quad \forall i \in [1,N]\\ &R(i)+F(i) \leq P + BigM\cdot W(i) &\quad \forall i \in [1,N] \\ &R(i)+F(i) \geq P - BigM\cdot (1-W(i)) &\quad \forall i \in [1,N] \end{aligned} $$

Ultimately this ‘improved’ model deploys over 20 constraints to express the basic hoist scheduling problem.

4.2 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 \in 1{\dots } J$:

$$ \begin{array}{@{}rcl@{}} &\begin{aligned} & R(i-1)+F(i-1)+E(i,j)+k\cdot P \leq R(j) \vee\\ & R(j-1)+F(j-1)+E(j,i) \leq R(j) + k\cdot P\\ &\qquad \forall i,j \in [1,N], k \in [1,J] \end{aligned} \end{array} $$

4.3 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.

5 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.⁴

Additional decision variables

$$ H(i) i=1,\dots,N \text{hoist that performs treatment } i$$

Initial bounds

$$ \begin{array}{@{}rcl@{}} 1 \leq H(i) \leq H &&\quad i=1,\dots,N \\ 0 \leq B(i) \leq C(i) &&\quad i=1,\dots,N \\ \end{array} $$

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

$$ \begin{aligned} R(i) \leq R(i-1) + F(i-1) + P_{ub} \cdot (C(i)-B(i)) &\quad\qquad\! \forall i \in [1,N] \end{aligned} $$

(9)

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} &H(i) > H(j) \vee \\ &(R(i) + F(i) + E(i+1,j) \leq R(j) + P \wedge R(j) + F(j) + E(j+1,i) \leq R(i) + P )\\ & \qquad \forall i \in [1,N], j \in [0,i-1] \end{aligned} \end{array} $$

(10)

$$ \begin{array}{@{}rcl@{}} &&\begin{aligned} &H(i) > H(j) \vee \\ &R(i) + F(i) + E(i+1,j) \leq R(j) \ \vee \ R(j) + F(j)+ E(j+1,i) \leq R(i)\\ & \qquad \forall i \in [1,N], j \in [0,i-1] \end{aligned} \end{array} $$

(11)

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.

Fig. 3

Left: Two hoists and three tanks. Right: Two hoists and four tanks: avoiding collision on a single track

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.

If each hoist has its own track (H = A), we replace H(i) > H(j) by H(i)≠H(j) in (11) and (10).

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:

$$ \begin{aligned} &R(i)+F(i)+E(i+1,j)-R(j) &\leq \\ &BigM\cdot (3 - Y(i,j)-Z(i,k)-\sum\limits_{h=k}^{K} Z(j,h))\\ & \qquad \forall i,j \in [1,N],j<i,k \in [1..K] \end{aligned} $$

Here, Y (i,j) is a binary variable indicating which removal is earlier, R(i) or R(j). Z(i,k) 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:

$$ \begin{array}{ll} R(i)+p(i)-(R(i-1)+F(i-1)-q(I)) \leq BigM\cdot (1-B(i)+W(i-1)) \\ \quad \forall i \in [1,N] \\ R(i)+p(i)-(R(i-1)+F(i-1)-q(I)) \leq BigM\cdot (1-W(i-1)+B(i)) \\ \quad \forall i \in [1,N] \\ R(i)+p(i)-(R(i-1)+F(i-1)-q(I)-P) \leq BigM\cdot (2-B(i)-W(i-1)) \\ \quad \forall i \in [1,N] \end{array} $$

The modification required to the CUC1H model to ensure it returns precisely the same solutions is simply to extend constraint (5) thus:

$$ \begin{aligned} R(i) \cdot B(i) \leq R(i-1) + F(i-1) - (p(i)+q(i)) & \quad \forall i \in [1,N] \end{aligned} $$

5.1 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.

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.⁵

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.

6.1 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,\dots , 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]. These instances have H ∈ [2,3,4] and N ∈{8,10,12,14}, and the time windows uniformly [0,0], [0,50] or [0,100]. We further generated larger random instances with Multiplier M ∈ [1,5] and C(i) ∈ [1,3],∀i.

We emphasise that no previous model has been benchmarked on instances with a multiplier M > 1.

6.2 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.⁶ 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.

Table 1 Results on P&U instances with CECnH and the Chuffed LCG solver

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.

Models compared on real-world instances

For the problem P&U, 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.

Table 2 Results on P&U instances with different models

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.

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.

Solvers compared on real-world instances

For problems P&U and BO1 respectively, 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 3 Results on P&U instances

Table 4 Results on BO1 instances

Solvers compared on random instances

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.

Table 5 Results on random instances generated as [5]

Table 6 Results on harder 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 magnitude than [5]’s IP model. The larger random instances are more difficult, especially for higher values of the Muliplier parameter. The most robust performance is the LCG solver, although for the instances it solves, the IP solver is the fastest.

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-n core’.

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.

6.3 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 fixed-chuffeds. 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 = \ell , \ell +1, \dots , \ell + 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 fixed-chuffed instance that is thus rendered obsolete (because its p < ℓ) is terminated.⁷ 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. 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 1-core 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.

Table 7 Results on P&U instances

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.

7 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 constraint-based 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.

8 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.