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 realworld 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 ResourceConstrained 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 TLSPS.
The investigated problem has several features of previous project scheduling problems in the literature, but also includes some specific features imposed by the realworld 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 nonstandard 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 TLSPS 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 reallife 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 TLSPS. 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 schedulingspecific features of that solver.

We propose a new hybrid VLNSbased 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 realworld data from an industrial test laboratory and randomly generated instances that are based on the realworld 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 ResourceConstrained 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.
MultiMode 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 CPModel 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 multiproject 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 multiobjective 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 TLSPS is MultiSkill 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 TLSPS, 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 TLSPS, 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 (TLSPS). 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 TLSPS 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 properties^{1}^{1}1In 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 TLSPS.:

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 TLSPS 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 solverindependent 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.
(1)  
(2)  
(3) 
(4)  
(5)  
(6)  
(7)  
(8)  
(9)  
(10)  
(11) 
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 Timeindexed approach
The probably most straightforward way to model the nonoveruse of any resource at any given time is captured by the following constraints.
(12) 
(13)  
(14) 
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 timeindexed 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 socalled 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.
(15) 
Just like with the timeindexed 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 nonoverload of any resource we need three constraints (one for each resource type).
(16)  
(17)  
(18) 
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 TLSPS, 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 realworld 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.
(19) 
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.
(20)  
(21)  
(22) 
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.
(23) 
(24)  
(25) 
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 :

[label=()]

ps_startFirst_aff

ps_startFirst_ff

ps_modeFirst_aff

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:
(26)  
(27)  
(28)  
(29)  
(30) 
(31)  
(32)  
(33)  
(34)  
(35)  
(36)  
(37)  
(38)  
(39)  
(40)  
(41)  
(42) 
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 (2931) 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 (3336) enforce the same for workbenches and equipment. In order to make sure that only available resources are assigned to the jobs, we need constraints (3740). 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.
(43)  
(44)  
(45) 
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:

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

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.

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 i78550U (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 reallife 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 realworld scenarios. Half of the instances are modelled very closely to a realworld 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 https://www.dbai.tuwien.ac.at/staff/fmischek/TLSP/. Since those instances were generated with the full TLSP in mind and in TLSPS 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 reallife 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^{*} 
^{*}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 

(111),(1618),(1925)  Default  13  8  –  – 
(111),(1618),(1925)  ps_modeFirst_ff  30  14  46529  20.806s 
(111),(1618),(1925)  ps_modeFirst_aff  30  14  46530  20.878s 
(111),(1618),(1925)  ps_startFirst_ff  30  14  45534  13.728s 
(111),(1618),(1925)  ps_startFirst_aff  30  14  44202  13.177s 
(111),(1618),(2025)  ps_startFirst_aff  30  14  44103  13.496s 
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 modelsearch 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 userdefined and activitybased 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 (2025) 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 

hotStartProb  
jumpProb 
6.4 Comparison
#  SA  VLNS  Chuffed  CPO  CPLEX  

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 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 et.al [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 singlethreaded mode.
Chuffed on the contrary could find solutions for all instances and even found optimal solutions for one more instance with the longer timelimit (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 realworld 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 realworld 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 metaheuristic. 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 realworld instance.
For the future, we plan to investigate exact and hybrid techniques to solve both stages of the TLSP including grouping and scheduling simultaneously.
Acknowledgments
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.
References
 [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, CDTR 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 (PATAT2018), Vienna, Austria, August 28–31, 2018, pages 465–467, 2018.
 [3] S. DauzèrePérès, W. Roux, and J.B. Lasserre. Multiresource 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 multiskill 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 multimode resourceconstrained project scheduling. In Principles and Practice of Constraint Programming  22nd International Conference, CP 2016, Toulouse, France, September 59, 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 LouisMartin 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 2327, 2007, Proceedings, pages 529–543, 2007.
 [9] IBM and CPLEX. 12.8.0 ibm ilog cplex optimization studio cp optimizer user’s manual. https://www.ibm.com/analytics/cplexcpoptimizer, 2017.
 [10] Peter Brucker, Andreas Drexl, Rolf Möhring, Klaus Neumann, and Erwin Pesch. Resourceconstrained 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 resourceconstrained 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 timedependent 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 zeroone programming approach. Management Science, 16(1):93–108, 1969.
 [17] Nudtapon Nudtasomboon and Sabah U. Randhawa. Resourceconstrained project scheduling with renewable and nonrenewable resources and timeresource tradeoffs. Computers & Industrial Engineering, 32(1):227 – 242, 1997.
 [18] Odile Bellenguez and Emmanuel Néron. Lower bounds for the multiskill 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. ORSpektrum, 22(4):501–524, 2000.
 [21] Mireille Palpant, Christian Artigues, and Philippe Michelon. Lssper: Solving the resourceconstrained 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. Solutionbased phase saving for CP: A valueselection heuristic to simulate local search behavior in complete solvers. In Principles and Practice of Constraint Programming  24th International Conference, CP 2018, Lille, France, August 2731, 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. https://www.ibm.com/analytics/cplexoptimizer, 2017.
 [26] Christian Schulte, Mikael Lagerkvist, and Guido Tack. Gecode 6.10 reference documentation. https://www.gecode.org, 2018.
 [27] Florian Mischek and Nysret Musliu. A local search framework for industrial test laboratory scheduling. under submission, 2019.
Comments
There are no comments yet.