Investigating Constraint Programming and Hybrid Methods for Real World Industrial Test Laboratory Scheduling

11/12/2019 ∙ by Tobias Geibinger, et al. ∙ TU Wien 0

In this paper we deal with a complex real world scheduling problem closely related to the well-known Resource-Constrained Project Scheduling Problem (RCPSP). The problem concerns industrial test laboratories in which a large number of tests has to be performed by qualified personnel using specialised equipment, while respecting deadlines and other constraints. We present different constraint programming models and search strategies for this problem. Furthermore, we propose a Very Large Neighborhood Search approach based on our CP methods. Our models are evaluated using CP solvers and a MIP solver both on real-world test laboratory data and on a set of generated instances of different sizes based on the real-world data. Further, we compare the exact approaches with VLNS and a Simulated Annealing heuristic. We could find feasible solutions for all instances and several optimal solutions and we show that using VLNS we can improve upon the results of the other approaches.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Project scheduling includes various problems of high practical relevance. Such problems arise in many areas and include different constraints and objectives. Usually project scheduling problems require scheduling of a set of project activities over a period of time and assignment of resources to these activities. Typical constraints include time windows for activities, precedence constraints between the activities, assignment of appropriate resources etc. The aim is to find feasible schedules that optimize several criteria such as the minimization of total completion time.

In this paper we investigate solving a real-world project scheduling problem that arises in an industrial test laboratory of a large company. This problem, Industrial Test Laboratory Scheduling (TLSP), which is an extension of the well known Resource-Constrained Project Scheduling Problem (RCPSP), was originally described in [1, 2]. It consists of a grouping stage, where smaller activities (tasks) are joined into larger jobs, and a scheduling stage, where those jobs are scheduled and have resources assigned to them. In this work, we deal with the second stage and assume that a grouping of tasks into jobs is already provided. Since we focus on the scheduling part, we denote the resulting problem TLSP-S.

The investigated problem has several features of previous project scheduling problems in the literature, but also includes some specific features imposed by the real-world situation, which have rarely been studied before. Among others, these include heterogeneous resources, with availability restrictions on the activities each unit of a resource can perform. While work using similar restrictions exists ([3, 4]), most problem formulations either assume homogeneous, identical units of each resource or introduce additional activity modes for each feasible assignment, which quickly becomes impractical for higher resource requirements and multiple resources. Another specific feature of TLSP(-S) is that of linked activities, which require identical assignments on a subset of the resources. To the best of our knowledge, a similar concept appears only in [5], where modes should be identical over subsets of all activities. We also deal with several non-standard objectives instead of the usual makespan minimization, which arise from various business objectives of our industrial partner. Most notably, we try to minimize the total completion time of each project, i.e. the time between the start of the first and the end of the last job in the project.

In practice, exact solutions for this problem are desired especially in situations where it is necessary to check if a feasible solution exists at all. In the application that we consider, checking quickly if activities of additional projects can be added on top of an existing schedule is very important. In this paper we investigate exact methods for solving this problem. Although it is known from previous papers [6, 4] that constraint programming techniques can give good results for similar project scheduling problems, it is an interesting question if Constraint Programming (CP) techniques can also solve TLSP-S that includes additional features and larger instances.

The current work is an extension of our previous conference paper [7]. In particular, we introduce a new Very Large Neighborhood Search (VLNS) heuristic based on the CP models and show that this hybrid approach leads to improvements in solution quality. In addition, we provide a formal description of our CP model for the CP optimizer, and significantly extend our experimental section: We compare our results with those of a search heuristic that uses Simulated Annealing and apply our methods to a dataset taken from a real-life test laboratory.

The main contributions of this article are as follows:

  • We provide two different CP models for our problem by exploiting some previous ideas for a similar problem from [6, 4] and extending them to model the additional features of TLSP-S. This includes, for example, the handling of the problem specific differences discussed above but also new redundant constraints as well as search procedures tailored to the problem. Using the MiniZinc [8] constraint programming language we experiment with various strategies involving the formulation of resource constraints, the reduction of the search space, and search procedures based on heuristics. The second model is geared towards the IBM CP Optimizer ([9]) and leverages several scheduling-specific features of that solver.

  • We propose a new hybrid VLNS-based approach that internally makes use of the CP models. This heuristic iteratively fixes a part of the schedule and solves the resulting (smaller) instance to optimality. It also includes various strategies to compute lower bounds and avoid redundant computations or local optima.

  • We evaluate our approaches both on real-world data from an industrial test laboratory and randomly generated instances that are based on the real-world data. Our experiments show that constraint programming techniques can reach good results for realistic instances and outperform MIP solvers on the same model. Our results strengthen the conclusion of previous studies and show that CP technology can be applied successfully for solving large project scheduling problems. We also show that the hybridization of CP formulations with heuristics in the form of our VLNS approach is very successful in finding good solutions on instances of all sizes and further improves both upon the results of the CP models on the larger instances and those of a search heuristic based on Simulated Annealing.

The rest of the paper is organised as follows. In the next Section we give the related work. Section 3 introduces the problem that we investigate in this paper. A constraint model is given in Section 4, together with the alternative formulation for CP Optimizer. Section 5 contains a description of the VLNS procedure. Experimental results are presented in Section 6 and the last section gives conclusions.

2 Literature Overview

The Resource-Constrained Project Scheduling Problem (RCPSP) has been investigated by numerous researchers over the last decades. For a comprehensive overview over publications dealing with this problem and its many variants, we refer to surveys e.g. by Brucker et al. [10], Hartmann and Briskorn [11], or Mika et al. [12].

Of particular interest for the problem treated in this work are various extensions to the classical RCPSP.

Multi-Mode RCPSP (MRCPSP) formulations allow for activities that can be scheduled in one of several modes. This variant has been extensively studied since 1977 [13], we refer to the surveys by Wȩglarz et al. [14] and Hartmann and Briskorn [11]. A good example of a CP-Model for the MRCPSP was given by Szeredi and Schutt [6].

Many formulations, including TLSP, make use of release dates, due dates, deadlines, or combinations of those. An example of this can be found in [15]. Further relevant extensions deal with multi-project formulations, including alternative objective functions (e.g. [16]). Usually, the objective in (variants of) RCPSP is the minimization of the total makespan [11]. However, also other objective values have been considered. Of particular relevance to TLSP are objectives based on total completion time and multi-objective formulations (both appear in e.g. [17]). Salewski et al.[5] include constraints that require several activities to be performed in the same mode. This is similar to the concept of linked jobs introduced in the TLSP.

RCPSP itself and most variants assume that individual units of each resource are identical and interchangeable. A problem closely related to TLSP-S is Multi-Skill RCPSP (MSPSP), first introduced by Bellenguez and Néron [18]. In this problem, each resource unit possesses certain skills, and an activity can only have those resources with the required skills assigned to it. This is similar to the availability restrictions on resources that appear in TLSP. Just like for our problem, they also deal with the problem that while availability restrictions could be modeled via additional activity modes corresponding to feasible resource assignments (e.g. in [19, 16, 20]), this is intractable due to the large number of modes that would have to be generated [18]. To the best of our knowledge, the best results for the MSPSP problem have been achieved by Young et al. [4], who use a CP model to solve the problem.

Also variants of VLNS have been used to solve the RCPSP or extensions of it, such as in [21]. One of the main challenges in these approaches is the choice of a subset of activities that is selected for optimization at each step. In TLSP-S, we have multiple projects over which most of the constraints are evaluated. This makes single or multiple projects a natural choice for this subset, which we exploit in our heuristic.

Bartels and Zimmermann [19] describe a problem for scheduling tests of experimental vehicles. It contains several constraints that also appear in similar form in TLSP-S, but includes a different resource model and minimises the number of experimental vehicles used.

3 Problem Description

As mentioned before, we deal with a variant of TLSP [1], where we assume that a grouping of tasks into jobs is already provided for each project, and focus on the scheduling part of the problem instead (TLSP-S). Thus, the goal is to find an assignment of a mode, time slot and resources to each (given) job, such that all constraints are fulfilled and the objective function is minimized.

In the following, we introduce the TLSP-S problem.

Each instance consists of a scheduling period of discrete time slots. Further, it lists resources of different kinds:

  • Employees who are qualified for different types of jobs.

  • A number of workbenches with different facilities.

  • Various auxiliary lab equipment groups , where is the group index. These each represent a set of similar devices. The set of all equipment groups is denoted .

Further we have given the set of projects labeled , and the set of jobs to be scheduled . For a project , the jobs of this project are given as .

Each job has several properties111In TLSP, these are derived from the tasks contained within a job. Since we assume the distribution of tasks into jobs to be fixed, they can be given directly as part of the input for TLSP-S.:

  • A time window, given via a release date and a deadline . In addition, it has a due date , which is similar to the deadline, except that exceeding it is only a soft constraint violation.

  • A set of available modes , where is the set of all modes.

  • A duration for each available mode .

  • The resource requirements for the job:

    • The number of required employees depends on the mode . Each of these employees must be chosen from the set of qualified employees . Additionally, there is also a set of preferred employees .

    • The number of required workbenches . If a workbench is required, it must be chosen from the available workbenches .

    • For each equipment group , the job requires devices, which must be taken from the set of available devices for the group.

  • The predecessors of the job, which must be completed before the job can start. Precedence relations will only occur between jobs of the same project.

  • Linked jobs of this job. All linked jobs must be performed by the same employee(s). As before, such links only occur between jobs of the same project.

  • Optionally, the job may contain initial assignments.

    • An initial mode .

    • An initial starting time slot .

    • Initial resource assignments: For each employee , the boolean parameter indicates whether is initially assigned to . Analogously, and perform the same function for each workbench and each device , respectively.

    Some or all of these assignments may be present for any given job.

Out of all jobs, a subset are started jobs . A started job will always fulfill the following conditions:

  • It must have a preassigned mode.

  • Its start time must be set to 1.

  • It must have initial resource assignments fulfilling all requirements.

The initial assignments of a started job must not be changed in the solution.

A complete description of all constraints of the original model can be found in [1]. The hard and soft constraints that we consider for the TLSP-S will be described in the next section, where we will introduce the CP model.

The aim for this problem is to find an assignment of a mode, time slot and resources to each (given) job, such that all hard constraints are fulfilled and the violation of soft constraints is minimized.

4 Constraint Programming Model

We developed our model using the solver-independent modeling language MiniZinc [8]. Using MiniZinc we can easily compare different solvers. Furthermore, previous studies have shown that CP gives very good results for similar project scheduling problems. Most notably, the approaches by Young et al. [4] and Szeredi et al. [6] for MSPSP and MRCPSP respectively. MiniZinc also enables the use of user defined search strategies, which were shown to be very effective for MSPSP [4]. For both scheduling problems, the LCG solver Chuffed [22] was able to achieve very good results.

In order to provide an additional comparison, we also modeled our problem with the IBM ILOG CP Optimizer [9]. This model uses a different formulation of constraints and decision variables than the MiniZinc model and is described in Subsection 4.6.

In order to represent a solution for the scheduling problem we use the following decision variables. The start time variable assigns a start time to each job . Similarly, for each job , mode variable assigns it a mode. For resource assignments we need the following variables: For each job , the variable is set to 1 if employee is assigned to and 0 otherwise, the variable is 1 if is performed on workbench and 0 otherwise, and the variable is 1 if device is used by and 0 otherwise.

4.1 Basic Hard Constraints

The following constraints follow directly from the problem definition.


Constraint (1) makes sure that each job is executed in its time window, (2) enforces that the prerequisite jobs of a job are always completed before it starts. Constraints (3–6) ensure that assigned modes, employees, workbenches, and devices are available for the respective job. In order to make sure that each job has exactly as many resources as required, we have constraints (7–9). Furthermore, we need constraint (10) to make sure that linked jobs are assigned to the same employees and constraint (11) to fix the start time of jobs which are already started.

The above set of constraints is however not enough to ensure a valid solution. Additionally, we have to consider constraints which enforce that no resource (employee, workbench, or equipment) is assigned to two or more jobs at the same time. Like it was the case with MSPSP [4], the constraints used for modeling those unary resource requirements have a tremendous impact on the practicability of the model and in the next subsection we will present different options for modeling such constraints.

4.2 Unary Resource Constraints

We will now present three different approaches for modeling unary resource constraints, each of which is designed with CP solvers in mind. Two of those three quickly proved to be impractical for our problem.

4.2.1 Time-indexed approach

The probably most straightforward way to model the non-overuse of any resource at any given time is captured by the following constraints.


The number of constraints generated by MiniZinc based on (12–14) is of course directly dependent on the planning horizon and the total number of resources. Because of the long compilation time and the high computer resource consumption, it quickly became immanent that for our larger instances the time-indexed approach is not efficient. This is of course not surprising since Young et al. [4] came to a similar conclusion for MSPSP. Hence, we discarded this option after some preliminary testing.

4.2.2 Overlap constraint

For MSPSP, Young et al. [4] achieved their best results using a so-called order constraint. This constraint basically enforces that two activities cannot overlap in their execution when they use a common resource. During the initial modeling phase we tried a very similar approach. First, we introduced the new predicate :

In MSPSP, resources are assigned to activities with respect to the needed skill of the activity. For the overlap constraint it is not important which skill requirement the resource contributes to, so Young et al. [4] had to introduce an auxiliary variable to express that a resource is used by an activity. We on the other hand assign the resources directly and thus can model our overlap constraint without any new variables.


Just like with the time-indexed approach, it turned out that the overlap constraint produced too many constraints and was thus impractical for larger instances. This is interesting because Young et al. had no such problems, but their biggest instances only had 60 resources and 42 activities, whereas we have instances with more than 300 resources and jobs, respectively. It should however be noted that Young et al. [4] reduced the number of generated constraints by considering only unrelated activity pairs, i.e. activities which do not depend on the execution of each other via precedence constraints (related activities can obviously never overlap). We on the other hand generate constraints for all pairs of jobs which are allowed to overlap based on their release dates and deadlines. Comparing only unrelated jobs requires the computation of the transitive closure of the job precedence relation and because our instances have a lot of unrelated jobs, we don’t expect any significant improvement.

4.2.3 Cumulative constraints

Another way to model the unary resource constraints is to use a global constraint like . The constraint takes as input the start times, durations and resource requirements of a list of jobs and ensures that their resource assignments never exceed a given bound. This is of course a perfect way to enforce non overload of any resource and both MSPSP and MRCPSP have efficient models which make use of in some way [6, 4]. In order to enforce the non-overload of any resource we need three constraints (one for each resource type).


In difference to our first two modeling approaches, this one turned out to scale well. Since the others performed so poorly on large instances, the rest of our experiments were performed with the unary resource constraints.

4.3 Soft Constraints

There are several soft constraints in our problem definition [1].

MiniZinc has no direct support for soft constraints, hence we define them as sums which should be minimised. Those sums are given as follows.

The first soft constraint depends on the number of jobs. Since we consider the job grouping fixed in TLSP-S, it is reduced to a constant value. In order to achieve comparability with results for TLSP, we keep it as a constant term in the objective value.

We want to prefer solutions where the assigned employees of a job are taken from the set of preferred employees:

For each project, the total number of employees assigned to it should be minimised:

For each job, violating its due date should be avoided:

Lastly, project durations should be as small as possible:

The objective of the search is then given by .

At the moment, the values of the weights

() are being determined in correspondence with a real-world laboratory. Currently all these weights are set to .

4.4 Redundant Constraints

Finding good redundant constraints for our problem proved to be very hard since the search space is usually very big and at the beginning of the search there is little knowledge about the final duration of the jobs. To deal with this issue we introduced a relaxed constraint enforcing a global resource bound.


This enables the search to discard scheduling options which are impossible regardless of the chosen modes early on.

On top of that, we can also formulate more straightforward cumulative constraints which enforce the global resource bounds for each resource at any point in time.


Given the large search space, trying to restrict the scope of the decision variables seems like a worthwhile idea. We achieve this by using global cardinality constraints. Those constraints allow us to give tight bounds for the total number of resources which should be used.


Constraint (23) enforces that no more employees can be assigned than the sum of the highest possible employee requirements and no less than the sum of the minimum requirements. The other two constraints analogously ensure that the number of assigned workbenches and equipment is tightly bounded by the cumulative requirement of all jobs.

4.5 Search Strategies

During initial testing it quickly became immanent that the default search strategy of Chuffed (or Gecode) was not even able to find feasible solutions for most instances. This was not surprising since Young et al. [4] already had a similar issue with MSPSP. However, they were able to improve their results drastically by employing a new MiniZinc search annotation called priority_search which is supported by Chuffed [23]. Based on their research we have experimented with four slightly different versions of :

  1. [label=()]

  2. ps_startFirst_aff

  3. ps_startFirst_ff

  4. ps_modeFirst_aff

  5. ps_modeFirst_ff

All four search strategies branch over the jobs and their resource assignments. The order of the branching is the same for all strategies and is determined by the smallest possible start times of the jobs in ascending order. For each branch, searches (i) and (ii) initially assign the smallest start time to the selected job followed by assigning it the mode which minimises the job duration. Search procedures (iii) and (iv) start with the mode assignment and then assign the start time. Once the start time and the mode have been assigned for the selected job, all of the search strategies make resource assignments for the job. Searches (i) and (iii) start by assigning those resources to the job which are available and have the biggest domain, whereas (ii) and (iv) start with assignments which are either unavailable or have only one value in their domain.

4.6 Alternative CP model

We also modelled our problem with CP Optimizer [9]. In that model the decision variables are given by the following interval variables:

The intervals represents the jobs and are constrained to the time windows of the respective job. The second set of intervals are auxiliary variables representing the total duration of the projects. Those intervals enable an easy formulation of the project duration soft constraint. The next intervals are optional and the presence of such an interval indicates that job is performed in mode . For a job several employee allocations are possible depending on its mode. The presence of an optional interval represents the allocation of employee to perform job in mode . The last three sets of optional intervals are used to indicate resource allocation.

The hard constraints of the problem are encoded with the following constraints:


Constraint (26) allows us to easily formulate the soft constraints which depend on the length of a project. The job precedences are enforced through Constraint (27). The alternative constraints (29-31) make sure that each job is assigned enough employees for the selected mode, while (31) and (32) express that no employee can be assigned to two jobs at the same time. The constraints (33-36) enforce the same for workbenches and equipment. In order to make sure that only available resources are assigned to the jobs, we need constraints (37-40). Lastly, linked jobs are modelled using (41) and started jobs with (42).

Using pulse constraints we can also formulate redundant constraints which are similar to the constraints defined in Section 4.4.


Finally, the objective is to minimize the following formula which is just the sum of all soft constraints defined in Section 4.3.

5 Very Large Neighborhood Search

Utilising our CP model we implemented a Very Large Neighborhood Search. The basic idea is to start with a feasible but suboptimal solution and repeatedly fix most of the schedule except for a small number of projects and then try to find an optimal solution for the unfixed projects.

The basic steps of the search are the following:

  1. Find Initial Solution
    In order for the VLNS to work, we need a feasible schedule for the instance. Since our CP model approach finds feasible solutions fast, we used it to provide an initial solution. In particular, we use Chuffed and our MiniZinc CP model including with free search disabled. This approach usually yields feasible schedules within one minute, even for large instances.

  2. Calculate lower bound for each project
    In parallel to step one we use our CP approach to determine a lower bound for each project. This is done by solving each project once without regard for the other projects. The optimal objective is then a lower bound for the penalty of the project in the original problem. Since this can take a long time for bigger projects we define a runtime limit of 30 seconds for each project. If the limit is reached and no optimal solution could be found, we determine a heuristic lower bound for the project as follows: We add up the number of jobs (), the minimum number of different employees needed for the project (), and the minimal duration of all jobs on the longest path in the job dependency graph (). For and , 0 is used as the lower bound.

  3. Fix all but projects
    Once we have an initial solution and the lower bounds we can start the actual heuristic. We start by selecting at random a combination of projects (initially, ), with the following properties: All of them overlap in the current schedule (or, if there are no such combinations, have overlapping time windows) and at least one of the projects has potential for improvement i.e. the difference between the current penalty and the lower bound is bigger than zero.

    The projects which are not in the selected combination are then fixed. To achieve this, we modify the time windows and availabilities of each job contained in a fixed project. The release and due dates are changed to correspond to the current start and end dates, the available modes and resources are changed to only include the current assignments, and finally the resource requirements are restricted to equal the assignments.

    The resulting instance is then further reduced by cutting away the fixed jobs outside of the merged time window of the selected projects. These removed jobs cannot be changed or influence the result and reducing the size of the instance improves compilation time.

  4. Perform move
    After the preprocessing we try to find an optimal solution for the selected projects, where we again set a runtime limit of 30 seconds. The best assignment found within this limit is then applied to the current incumbent schedule if it does not increase the penalty of the solution. With a parameterised probability we hot start the CP solver. This means that the current assignment of the selected projects is given to the solver as an initial solution. The hot start functionality is based on work by Demirovic et. al [24] and has been integrated by us into the current version of the solver Chuffed. Hot starting the search however means that the search never accepts moves which change the schedule but do not decrease the penalty. This is why we only hot start with a given probability. If we do not hot start the solver, we additionally set up to assign resources not in input order but randomly. This further enhances diversification.

    After we have performed the move, we save the selected combination in a list. Combinations contained in this list (or subsets of a combination in the list) are not selected again unless there has been a change in a job overlapping the combination.

  5. Possibly change
    If is bigger than 1 and the incumbent schedule has been changed by the last move, then we set back to 1. Otherwise, if there are no more eligible combinations with size , we increase by one or – with probability – by two. If there no more combinations for any , we terminate.

    After this we check if the current solution is equal to the sum of all project lower bounds. Should that be the case, then we have found an optimal solution and can terminate. If not, we go back to step 3 or terminate if we have reached the time limit of the solver.

6 Experiments and Comparison

We ran our experiments on a benchmark server with 224GB RAM and two AMD Opteron 6272 Processors each with max. 2.1GHz and 16 logical cores. Since all of the solvers we experimented with are single threaded, we usually ran two independent sets of benchmarks in parallel. For the VLNS parameter experiments we used a Lenovo ThinkPad University T480s with an Intel Core i7-8550U (1,8 GHz). We used MiniZinc 2.2.3 [8] with Chuffed 0.10.3 [22] and CPLEX 12.8.0 [25]. Our VLNS which is described in Section 5 was implemented in Java 8. Furthermore, we also experimented with the ILOG CP Optimizer 12.8.0 [9] which was not run from MiniZinc but with the ILOG Java API. We have also tested Gecode [26] as an additional CP solver included in MiniZinc, but it quickly proved to be inferior to Chuffed on this model even when run with multiple threads. Regarding comparison to other approaches in the literature, to the best of our knowledge no solutions exist yet for the problem we consider in this paper.

6.1 Instances

We use a total of 30 randomly generated instances (based on real-life situations) of different sizes for our experiments. Those instances are listed in Table 1. The instances all have three modes: a single mode requiring only one employee, a shift mode which requires two employees but has a reduced duration, and an external mode that requires no employees at all. In general, jobs can be done in single mode or optionally in shift mode. Some instances however also include jobs which can only be performed in external mode. Initial assignments appear only for jobs which are already started or are fixed to their current value via availability restrictions and time windows.

While all of the instances were generated randomly, they are still modelled after real-world scenarios. Half of the instances are modelled very closely to a real-world laboratory, whereas the other half is more general and makes full use of the problem features. The details of how this generation works as well as the exact differences between the laboratory instances and general instances are given in [1]. Furthermore, our 30 instances are a selection from a total of 120 instances given in the report. We chose the first two instances of each size (scheduling horizon and number of projects) and two additional instances for the 3 smallest sizes. This selection was necessary, because of the long time it would have taken to experiment with all 120 instances. Those 120 instances as well as the 30 we selected for this paper can be found at Since those instances were generated with the full TLSP in mind and in TLSP-S we take the initial job grouping as fixed and unchangeable, the instances had to be converted. This is achieved by viewing the jobs as the smallest planning unit and assigning the job parameters – which are defined by the tasks contained in the job in TLSP – directly to the jobs.

In addition, we also include results for one real-life instance (Lab) taken directly from the lab of our industrial partner (in anonymized form). This instance covers a scheduling period of over one year, at a granularity of two timeslots per working day. It includes a reference schedule that is the manually created schedule actually used in the lab at the time the instance was created.

# Data Set ID
1 General 000 5 7 88 7 7 3 2.08 3.57 1.5
2 General 001 5 8 88 7 7 3 4.88 3.63 15.67
3 LabStructure 000 5 24 88 7 7 3 1.84 3.38 11.67
4 LabStructure 001 5 14 88 7 7 3 4.36 3.5 0.36
5 General 005 10 29 88 13 13 4 4.04 3.48 5.76
6 General 006 10 18 88 13 13 6 5.56 4.22 13.28
7 LabStructure 005 10 37 88 13 13 3 6.16 4.03 0.65
8 LabStructure 006 10 29 88 13 13 3 6.21 3.76 21.01
9 General 010 20 60 174 16 16 5 7.42 4.42 11.36
10 General 011 20 84 174 16 16 4 7.31 4.3 3.7
11 LabStructure 010 20 65 174 16 16 3 6.28 4.43 26.26
12 LabStructure 011 20 62 174 16 16 3 7.27 4.24 1.21
13 General 020 15 29 174 12 12 5 5.76 3.97 1.12
14 LabStructure 020 15 53 174 12 12 3 6.28 4.47 20.63
15 General 025 30 113 174 23 23 3 8.26 4.41 5.71
16 LabStructure 025 30 105 174 23 23 3 7.52 4.25 39.63
17 General 015 40 126 174 31 31 3 9.26 4.48 29.53
18 LabStructure 015 40 138 174 31 31 3 7.36 3.57 41.93
19 General 030 60 208 174 46 46 6 9.85 4.11 31.45
20 LabStructure 030 60 212 174 46 46 3 9.28 4.17 78.16
21 General 035 20 76 520 6 6 5 4.24 3.62 8.08
22 LabStructure 035 20 71 520 6 6 3 4.3 3.42 11.70
23 General 040 40 196 520 12 12 4 6.95 4.47 4.24
24 LabStructure 040 40 187 520 12 12 3 6.55 4.51 1.38
25 General 045 60 260 520 18 18 6 7.65 4.52 23.95
26 LabStructure 045 60 239 520 18 18 3 7.44 4.42 33.65
27 General 050 60 270 782 13 13 4 6.89 4.39 3.89
28 LabStructure 050 60 247 782 13 13 3 6.97 4.21 23.42
29 General 055 90 384 782 19 19 5 7.27 4.29 26.89
30 LabStructure 055 90 401 782 19 19 3 7.34 4.53 36.76
Lab - - 74 297 606 22 17 3 6.02 5.36 1*
Table 1: The set of test instances used for the experiments. Shown are the data set the instance is taken from and the ID within that set. The following columns list the number of projects, jobs and the length of the scheduling period, followed by the number of employees, workbenches and equipment groups. The last columns contain the mean qualified employees and available workbenches per job, as well as the mean available devices per job and equipment group (only over those jobs that actually require at least one device of the group, about 10% of all jobs).
*The discrepancy compared to the generated instances arises from the fact that several equipment groups were not yet considered for planning at the time this instance was created.

6.2 Search & Redundant Constraints Experiments

Constraints Search #sat #opt cum obj avg rt sat
(1-11),(16-18),(19-25) Default 13 8
(1-11),(16-18),(19-25) ps_modeFirst_ff 30 14 46529 20.806s
(1-11),(16-18),(19-25) ps_modeFirst_aff 30 14 46530 20.878s
(1-11),(16-18),(19-25) ps_startFirst_ff 30 14 45534 13.728s
(1-11),(16-18),(19-25) ps_startFirst_aff 30 14 44202 13.177s
(1-11),(16-18),(20-25) ps_startFirst_aff 30 14 44103 13.496s
Table 2: Priority Search Experiments (Runtime 30m)

Table 2 shows the comparison of search procedures described in Section 4.5. The column #sat shows for how many instances (out of the 30 generated instances) the model-search combination found feasible solutions, whereas #opt contains the number of instances solved to optimality. Furthermore, the values in the column cum obj show the cumulative objective value over all instances, and avg rt sat is the average time it took to find the first feasible solution.

Each model was run using Chuffed with free search enabled. Free search alternates between user-defined and activity-based search on each restart. The time limit was set to 30 minutes for each instance. It can be easily seen that any version of priority_search is vastly superior to the default search of Chuffed. priority_search strategies solve more instances to optimality and also found feasible solution for every instance. It should be noted that the fourteen optimally solved instances are the same over all search configurations. They all have less than or equal to 20 projects. The search strategy ps_startFirst_aff achieved the best cumulative objective value, which is why this strategy – albeit slightly modified to support random value selection – is also used in the VLNS.

While initial experiments showed that redundant constraints (20-25) have a high impact on the search, Table 2 shows that while constraint (19) has no positive impact on the solution quality, it does improve the time to the first feasible solution. However, we decided to drop the constraint for the comparison with the other solvers and approaches since we were mainly interested in solution quality and not in quickly found feasible solutions.

6.3 VLNS Parameter Configuration

As described in Section 5, we have 2 parameters for VLNS: There is the probability for hot starting a move called hotStartProb and there is the probability that if we have to change the neighborhood – i.e. the number of projects we modify in a single move – we increase it not by 1 but by 2. The latter parameter is called jumpProb. We manually tested different configurations and the trend in the experiments was that a high hotStartProb makes the search more stable and thus less reliant on randomness. However, by setting it to 1.0 the search would get stuck in local optima very often. A good compromise between those two extremes turned out to be 0.8. In other words, we hot start from the previously best solution 80% of the moves and in 20% of the time we do not hot start and start the search from a random assignment of timeslots and resources. Similarly, a very low jumpProb can lead to local optima out of which the search cannot escape, but if we set it too high then we might waste a lot of time in larger neighborhoods. In the end, the experiments showed that a jumpProb of 35% performed well. Table 3 shows the chosen configuration for the final experiment.

Parameter Value Range Chosen Value
Table 3: The chosen VLNS parameter configuration

6.4 Comparison

Best #Feas. Avg Best Avg
1 98 5 98 98 * 98 98 * 98 * 98 *
2 73 5 73 73 * 73 73 * 73 * 73
3 152 5 152.6 149 * 149 149 * 149 * 149
4 106 5 107 105 * 105 105 * 105 * 105 *
5 287 5 306.4 283 283 283 * 283 287
6 180 5 181.4 162 * 162 162 * 162 162
7 307 5 307 307 307 307 * 307
8 310 5 310 310 310 310 * 310 317
9 501 5 501 501 * 501 501 * 502
10 564 5 564 564 * 564 576 566
11 872 5 872.8 856 856.4 856 * 859
12 660 5 660 656 * 656 656 * 661
13 352 5 377.4 340 * 340 340 * 340 370
14 423 5 424.2 420 * 420 420 * 424
15 1085 5 1086.8 1084 * 1085 1646 1104
16 1141 5 1142 1138 * 1142.6 1560 1193
17 1195 5 1200.2 1194 * 1194.4 1254 1203 1242
18 1359 5 1362.2 1359 1378.2 1817 1404
19 2127 5 2168.6 1964 2000.8 2650 2099
20 2228 5 2242.2 2114 2140.8 2887 2284
21 685 5 689 679 * 679.2 679 * 722
22 766 5 768.4 765 765 765 * 770
23 2209 4 2319.25 2029 2104.2 3486 2207
24 1780 5 1817.2 1776 1798.6 2445 1863
25 2701 5 2836 2112 2165.8 3278 2551
26 2579 5 2599.8 2558 2573.8 3896 2799
27 2153 5 2155.2 2151 * 2151.8 3095 2338
28 2338 5 2351 2322 * 2322.6 2569 2402
29 3996 5 4192.6 3233 3297 4539 3718
30 4478 4 4544.75 4736 4779.4 5904 4995
Lab 3338 4 3366.75 3334 3400.6 5188 3444
Table 4: Comparison of different approaches with a timeout of two hours. Simulated Annealing and VLNS were run 5 times per instance with different seeds. Column Best contains the best solution found, #Feas. the number of feasible solutions found (out of 5) and Avg the average penalty over all feasible solutions. Solutions for VLNS, Chuffed, CPO and CPLEX marked with “*” indicate that the respective solver proved optimality. The best known solution for each instances is bold.

Table 4 shows our final experiment, which is a comparison between Simulated Annealing, VLNS, Chuffed, the MIP solver CPLEX and the CP solver CP Optimizer. The time limit was set to 2 hours for each instance. CP Optimizer was run with 8 threads and the parameter FailureDirectedSearchEmphasis was set to 4. For Simulated Annealing we used the implementation from Mischek [27], with the same parameter configuration.

It can easily be seen that CPLEX performed very poorly in comparison to the rest, although it should be noted that our model was developed with CP solvers in mind and thus might not be a perfect fit for MIP solvers. Also, CPLEX was only run in single-threaded mode.

Chuffed on the contrary could find solutions for all instances and even found optimal solutions for one more instance with the longer time-limit (instance 21, cf. [7]).

The results for CP Optimizer are particularly interesting. While it only the manages to prove the optimality of the 4 smallest instances, it generally finds better solutions for instances which cannot be closed by Chuffed. The fact that CP Optimizer has trouble proving optimality is the main reason why we chose Chuffed for VLNS instead of CP Optimizer.

Simulated Annealing managed to find feasible solutions in all runs but two and most of the time the found solutions are better than the ones found by Chuffed, and competitive to those found by CP Optimizer.

As for VLNS, the search always finds feasible solutions and for 29 of the instances it found a solution with the best known objective. Further, it could prove optimality using the custom lower bounds for 16 of the instances, including two large instances with 60 projects.

Results for the real-world instance can be compared to the reference schedule achieved via manual scheduling. Firstly, this reference schedule omits 90 required resource assignments (88 employee and 2 equipment assignments), and thus does not fulfill all constraints. Disregarding that, it achieves a penalty of 4074 under the same soft constraint weights as for the generated instances. All solvers (except CPLEX and one of the runs of SA) found a feasible solution for this instance in the given time limit. Both CPO, VLNS and SA (in 4 of 5 runs) even managed to find solutions with a markedly lower penalty than the reference schedule. For VLNS, we could show that the best solution found is within 5.97% of the optimum.

7 Conclusion

In this paper we have investigated different possibilities to model a complex real-world project scheduling problem. For some of the constraints, we first experimented with approaches which were already used in related project scheduling problems. To deal with this more complex problem and larger instances we introduced several extensions in modeling. Utilising this exact method, we then implemented a VLNS meta-heuristic. We have evaluated our exact approach as well as the VLNS on a set of 30 benchmark instances. Using CP techniques we could find feasible solutions for all considered instances and 15 optimal solutions. Furthermore, the VLNS achieved even better results for most instances and managed to provide 6 optimal solutions which could not be found using CP. VLNS also outperformed a local search procedure based on Simulated Annealing and found new best known solutions for several instances, including a real-world instance.

For the future, we plan to investigate exact and hybrid techniques to solve both stages of the TLSP including grouping and scheduling simultaneously.


The financial support by the Austrian Federal Ministry for Digital and Economic Affairs and the National Foundation for Research, Technology and Development is gratefully acknowledged.


  • [1] Florian Mischek and Nysret Musliu. The test laboratory scheduling problem. Technical report, Christian Doppler Laboratory for Artificial Intelligence and Optimization for Planning and Scheduling, TU Wien, CD-TR 2018/1, 2018.
  • [2] Florian Mischek and Nysret Musliu. A local search framework for industrial test laboratory scheduling. In Proceedings of the 12th International Conference on the Practice and Theory of Automated Timetabling (PATAT-2018), Vienna, Austria, August 28–31, 2018, pages 465–467, 2018.
  • [3] S. Dauzère-Pérès, W. Roux, and J.B. Lasserre. Multi-resource shop scheduling with resource flexibility. European Journal of Operational Research, 107(2):289 – 305, 1998.
  • [4] Kenneth D. Young, Thibaut Feydy, and Andreas Schutt. Constraint programming applied to the multi-skill project scheduling problem. In Principles and Practice of Constraint Programming - 23rd International Conference, CP 2017, Melbourne, VIC, Australia, August 28 - September 1, 2017, Proceedings, pages 308–317, 2017.
  • [5] Frank Salewski, Andreas Schirmer, and Andreas Drexl. Project scheduling under resource and mode identity constraints: Model, complexity, methods, and application. European Journal of Operational Research, 102(1):88 – 110, 1997.
  • [6] Ria Szeredi and Andreas Schutt. Modelling and solving multi-mode resource-constrained project scheduling. In Principles and Practice of Constraint Programming - 22nd International Conference, CP 2016, Toulouse, France, September 5-9, 2016, Proceedings, pages 483–492, 2016.
  • [7] Tobias Geibinger, Florian Mischek, and Nysret Musliu. Investigating constraint programming for real world industrial test laboratory scheduling. In Louis-Martin Rousseau and Kostas Stergiou, editors, Integration of Constraint Programming, Artificial Intelligence, and Operations Research, pages 304–319, Cham, 2019. Springer International Publishing.
  • [8] Nicholas Nethercote, Peter J. Stuckey, Ralph Becket, Sebastian Brand, Gregory J. Duck, and Guido Tack. Minizinc: Towards a standard CP modelling language. In Principles and Practice of Constraint Programming - CP 2007, 13th International Conference, CP 2007, Providence, RI, USA, September 23-27, 2007, Proceedings, pages 529–543, 2007.
  • [9] IBM and CPLEX. 12.8.0 ibm ilog cplex optimization studio cp optimizer user’s manual., 2017.
  • [10] Peter Brucker, Andreas Drexl, Rolf Möhring, Klaus Neumann, and Erwin Pesch. Resource-constrained project scheduling: Notation, classification, models, and methods. European Journal of Operational Research, 112(1):3 – 41, 1999.
  • [11] Sönke Hartmann and Dirk Briskorn. A survey of variants and extensions of the resource-constrained project scheduling problem. European Journal of Operational Research, 207(1):1 – 14, 2010.
  • [12] Marek Mika, Grzegorz Waligóra, and Jan Węglarz. Overview and state of the art. In Christoph Schwindt and Jürgen Zimmermann, editors, Handbook on Project Management and Scheduling Vol.1, pages 445–490. Springer International Publishing, Cham, 2015.
  • [13] Salah Eldin Elmaghraby. Activity networks: Project planning and control by network models. John Wiley & Sons, 1977.
  • [14] Jan Węglarz, Joanna Józefowska, Marek Mika, and Grzegorz Waligóra. Project scheduling with finite or infinite number of activity processing modes – a survey. European Journal of Operational Research, 208(3):177 – 205, 2011.
  • [15] L.-E. Drezet and J.-C. Billaut. A project scheduling problem with labour constraints and time-dependent activities requirements. International Journal of Production Economics, 112(1):217 – 225, 2008. Special Section on Recent Developments in the Design, Control, Planning and Scheduling of Productive Systems.
  • [16] A. Alan B. Pritsker, Lawrence J. Waiters, and Philip M. Wolfe. Multiproject scheduling with limited resources: A zero-one programming approach. Management Science, 16(1):93–108, 1969.
  • [17] Nudtapon Nudtasomboon and Sabah U. Randhawa. Resource-constrained project scheduling with renewable and non-renewable resources and time-resource tradeoffs. Computers & Industrial Engineering, 32(1):227 – 242, 1997.
  • [18] Odile Bellenguez and Emmanuel Néron. Lower bounds for the multi-skill project scheduling problem with hierarchical levels of skills. In Edmund Burke and Michael Trick, editors, Practice and Theory of Automated Timetabling V, pages 229–243, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.
  • [19] J.-H. Bartels and J. Zimmermann. Scheduling tests in automotive r&d projects. European Journal of Operational Research, 193(3):805 – 819, 2009.
  • [20] Christoph Schwindt and Norbert Trautmann. Batch scheduling in process industries: an application of resource–constrained project scheduling. OR-Spektrum, 22(4):501–524, 2000.
  • [21] Mireille Palpant, Christian Artigues, and Philippe Michelon. Lssper: Solving the resource-constrained project scheduling problem with large neighbourhood search. Annals of Operations Research, 131(1):237–257, Oct 2004.
  • [22] Geoffrey Chu.

    Improving combinatorial optimization

    PhD thesis, University of Melbourne, Australia, 2011.
  • [23] Thibaut Feydy, Adrian Goldwaser, Andreas Schutt, Peter J. Stuckey, and Kenneth D. Young. Priority search with minizinc. In ModRef 2017: The Sixteenth International Workshop on Con- straint Modelling and Reformulation at CP2017, 2017.
  • [24] Emir Demirovic, Geoffrey Chu, and Peter J. Stuckey. Solution-based phase saving for CP: A value-selection heuristic to simulate local search behavior in complete solvers. In Principles and Practice of Constraint Programming - 24th International Conference, CP 2018, Lille, France, August 27-31, 2018, Proceedings, volume 11008 of Lecture Notes in Computer Science, pages 99–108. Springer, 2018.
  • [25] IBM and CPLEX. 12.8.0 ibm ilog cplex optimization studio cplex user’s manual., 2017.
  • [26] Christian Schulte, Mikael Lagerkvist, and Guido Tack. Gecode 6.10 reference documentation., 2018.
  • [27] Florian Mischek and Nysret Musliu. A local search framework for industrial test laboratory scheduling. under submission, 2019.