Leveraging problem-independent hyper-heuristics for real-world test laboratory scheduling

The area of project scheduling problems has seen a tremendous amount of different problem variations. Traditionally, each problem variant requires custom solution approaches in order to produce high-quality solutions. Developing and tuning these methods is an expensive process that may have to be repeated as soon as the requirements or problem structures change. On the other hand, research into hyper-heuristics has produced general heuristic problem-solving techniques that were developed to achieve good results on multiple diverse problem domains. They work with a set of comparatively simple low-level heuristics and dynamically adapt themselves to each new problem variant. In this paper, we investigate hyper-heuristic approaches for a real-world industrial test laboratory scheduling problem and develop a new problem domain for the HyFlex hyper-heuristic framework. We propose a diverse portfolio of low-level heuristics that can be dynamically selected during the search process by hyper-heuristics to solve the problem. We evaluate and compare the performance of several problem-independent hyper-heuristics on this domain and show that they are able to match, and sometimes even exceed, the performance of state-of-the-art solution techniques that were developed and tuned specifically for this problem.


INTRODUCTION
Project scheduling problems appear in countless different variants across many areas.The quality of such schedules can have a tremendous impact on costs, time, service quality, and employee wellbeing.At the same time, the typically large number of activities to schedule and complex constraints makes manual scheduling time-consuming and error-prone even for experts, indicating the need for automated solutions.Here, the large variety in requirements between different settings or even across different instances of otherwise similar settings poses a big challenge, as solution methods are often specific to a single problem formulation.Adapting methods to new variants frequently requires expensive development work and tuning.
One such variant is a complex real-world project scheduling problem that arises in industrial test laboratories.The Test Laboratory Scheduling Problem (TLSP) was first introduced in [15].It is an extension of the well-studied Resource-Constrained Project Scheduling Problem (RCPSP), where the solver has to group atomic tasks into larger units called jobs in addition to scheduling those jobs.Further aspects include several additional constraints, some of which are unique to the TLSP such as the requirement that some tasks have to be performed by the same employees, and a nonstandard objective function which is a combination of multiple individual objectives.
Different solution methods have been proposed for the TLSP.Mischek and Musliu [14,15] described metaheuristic approaches, using a combination of different neighborhood structures.Initially restricted to a subproblem with a fixed and predetermined task grouping, these methods were later extended to the full TLSP [17,18].For both problem versions, Simulated Annealing (SA) found the best results.An exact approach using Constraint Programming (CP) was proposed by Danzinger et al. [10,11], based on an earlier model for the subproblem [12].That work also includes a Very Large Neighborhood Search (VLNS), which repeatedly solves restricted subproblems consisting of one or a small number of projects, while the rest of the schedule remains fixed.Finally, Geibinger et al. [13] developed another exact solution method based on Constraint Answer-set Programming (CASP).While the CP and CASP solvers provide good solutions for small instances, their performance is not competitive on larger and practically sized instances compared to heuristic approaches like SA and VLNS.Both SA and VLNS are deployed in an industrial test laboratory, where they are successfully used to create and update the work schedules of the lab [10].
Something all previously proposed heuristic solution approaches have in common is that they underwent extensive parameter tuning based on the characteristics of the available benchmarking instances.On the one hand, this tuning enabled them to find highquality solutions for these and similar instances.On the other hand, tuning is time-consuming and the resulting configuration may not be a good fit for future instances with different properties or potential newly arising variants of the problem.
In this paper, we follow a different approach: We investigate the use of problem-independent hyper-heuristics to solve the TLSP, which are a class of high-level heuristic problem solving techniques that are able to automatically adapt to new and unseen problem domains.Towards this end, we develop a new problem domain for the HyFlex hyper-heuristics framework, which is the de-facto standard framework for selection hyper-heuristics in the literature.Besides efficient implementations of several other components, such as instance and solution representation, we propose a diverse portfolio of modular low-level heuristics for the TLSP.This allows us to employ several state-of-the-art hyper-heuristics on the new TLSP domain.We perform a thorough evaluation of these hyperheuristics and compare their results to those of the best available problem-specific approaches (SA and VLNS).Our experimental results show that even without any kind of problem-specific tuning, hyper-heuristics are able to compete with and sometimes even improve upon the best problem-specific methods.
The paper is structured as follows: In the next section, we provide an overview of hyper-heuristics in general and the HyFlex framework, followed by a description of the TLSP in Section 3. We introduce a new HyFlex problem domain based on the TLSP in Section 4, which also includes a description of the low-level heuristic portfolio.Our experimental evaluation of several state-of-the-art hyper-heuristics on this domain is described in Section 5, including a comparison with other problem-specific algorithms for the TLSP.Finally, we give concluding remarks in Section 6.

HYPER-HEURISTICS
Hyper-heuristics are a class of high-level problem solving techniques that operate over a portfolio of so-called low-level heuristics (LLHs).Instead of directly moving through the space of potential candidate solutions to a problem, hyper-heuristics instead select and apply these LLHs to one or a population of solutions.This indirection enables hyper-heuristics to have a high degree of adaptability and generality, as switching out the available LLHs can allow a hyper-heuristic to solve a completely different problem.Most hyper-heuristics also include adaptive components, which automatically adjust their behaviour towards LLHs that are beneficial for the current problem, instance, or even state of the search.For the purpose of this work, we consider only selection hyper-heuristics, for which the available LLHs are given as a discrete set of operators, in contrast to generation hyper-heuristics which try to generate new LLHs from basic algorithmic components [6].
Research on hyper-heuristics experienced a big boost in 2011 due to the Cross-Domain Heuristics Search Challenge 2011 (CHeSC 2011) [5], an international competition where participants had to develop hyper-heuristics that could perform well on multiple different domains.Specifically, the submitted hyper-heuristics were evaluated on the maximum satisfiability problem (MaxSAT), bin packing (BP), the flow-shop problem (FS), personnel scheduling (PS), the travelling salesman problem (TSP) and vehicle routing (VRP), six diverse and well-studied academic problem domains.Of these, the first four domains where announced in advance, while the TSP and VRP domains were hidden from the competitors until the final evaluation.Similarly, the hyper-heuristics were also evaluated at least in part on previously unknown instances.This required participants to develop hyper-heuristics that would work well on different problems, but also generalize to unseen instances and even completely new problems.
In total, there were 20 competing hyper-heuristics submitted for the challenge.They were scored based on their relative rank on each instance, inspired by the Formula 1 scoring scheme [5].
The competition was won by Mısır et al. [19].Their algorithm AdapHH (sometimes also referenced as GIHH) combines several adaptive mechanisms: A subset of active LLHs with promising performance characteristics is managed and periodically updated using an adaptive dynamic heuristic set (ADHS) strategy.At each iteration, one of the active LLHs is selected and applied to the current solution with probabilities based on their previous performance.The search parameters of each LLH are maintained by a separate component employing a reward-penalty scheme.Alternatively, the algorithm may choose to apply a pair of LLHs in direct succession, if that pair has proved successful earlier in the run (relay hybridisation).The acceptance of the resulting solution is determined by an Adaptive iteration limited list-based threshold accepting (AILLA) mechanism, which can also decide to restart the search from from a new randomly generated initial solution if necessary.
All hyper-heuristics for the competition had to be implemented in the software framework HyFlex [20], which was developed for the competition.One important concept in HyFlex is the domain barrier, which guarantees the problem-independence of the hyperheuristics.It is visualized in Figure 1.All problem-specific information of a domain, such as instance and solution representation, objective function, or LLHs, is hidden from the hyper-heuristic.The hyper-heuristic only knows the number and a high-level type of each available LLH, as well as the current objective value of each solution in memory.It interacts with the problem domain by instructing it to apply one of the LLHs (ℎ  ) to a solution (  ) and store the result in memory (  ).The problem domain then returns the new objective value of the solution ( (  )) 1 .
The LLHs are partitioned into four types: Mutation (MU) operators apply random changes to a candidate solution, without regard for objective values.Ruin-and-recreate (RR) operators destroy a part of a solution and attempt to rebuild or repair it afterwards.Local search (LS) heuristics attempt to improve the solution, typically via small and iterative changes.While finding such an improvement is not guaranteed, the resulting solution will never be worse than the original.Crossover (CO) operators combine two solutions to produce a new solution that contains assignments of both parents.

Domain barrier
Figure 1: Structure of HyFlex.The domain barrier separates hyper-heuristics from the problem domain implementations and hides problem-specific information.Figures source: [16].
The hyper-heuristic has to select both parents, instead of only one solution as for the other operators.In addition, LLHs can support either of two numerical parameters.The depth of search (DoS) parameter is intended to determine the number of steps performed by incremental improvement heuristics, while the intensity of mutation (IoM) parameter affects the strength of the perturbations applied by both mutation and ruin-and-recreate heuristics.Both parameters take values between 0.0 and 1.0, which can be set by the hyper-heuristic.
Since 2011, HyFlex has become the de-facto standard framework for selection hyper-heuristics.Several authors have developed new hyper-heuristics, such as FS-ILS [1], GEP-HH [21], MCTS-HH [22], QHH [7], FI [9], TS-ILS [3], and many more.Something most successful hyper-heuristics have in common, including all those mentioned above, is that they include some sort of adaptive component to adjust their behavior according to the performance of the LLHs on the current instance.Often, these components borrow concepts from online machine learning strategies, such as reinforcement learning [6,7].Many of the top hyper-heuristics also follow the general structure of iterated local search (ILS), alternating cycles of diversification and intensification, or perturbation and search [1,3,7].
Other authors have extended HyFlex with additional problem domains, including the knapsack problem (KP), quadratic assignment problem (QAP), and maximum-cut problem (MAC) [2].

PROBLEM STATEMENT
The TLSP is an extension of the Resource-Constrained Project Scheduling Problem (RCPSP).We give here a summary of the problem description, the full formal definition is provided as supplementary material and can also be found in [15].
In the TLSP, the goal is to find a schedule for multiple projects, each containing several tasks.Each task requires different kinds of resources (employees, workbenches, and several types of equipment) and must be executed in one of several modes, which affects both its duration and its resource requirements.Further, only a subset of all units of a resource is suitable for performing any particular task.Additional constraints include release dates and deadlines, precedence constraints between tasks of a project, fixed assignments, restrictions on which tasks can be grouped together into a job, and finally linked tasks, which are sets of tasks that must all be assigned the same employees.
The solver has to determine a partition of the tasks into jobs, and then assign a mode, discrete time slots, and resources to each job.The properties and requirements of a job are determined by those of the tasks it contains.Within a job, tasks are executed sequentially, but their order is not defined2 .As a result, the job must fulfill the requirements of all tasks for its whole duration, which is the sum of the durations of its contained tasks plus an additional setup time.For example, resource requirements of a job are the maximum required number among all its tasks for each resource type, and the set of available resource units that can be assigned is the intersection of the available units of its tasks.Similarly, an execution mode can be assigned to a job only if that mode is available for all its tasks.
The quality of a feasible schedule is determined as a linear combination of several objectives: In contrast to typical variants of RCPSP, we do not aim to minimize the makespan, but instead the total duration of each project, from the start of its first job to the end of its last scheduled job.Other objectives include minimizing the number of jobs, the number of different employees assigned to each project, and the assignment of non-preferred employees to jobs.Finally, the last objective aims to finish each job already by a certain target date, which is typically several time slots before the deadline.The relative weights of these objectives depend on the preferences and goals of individual laboratories in practice.In line with previous work, we have used uniform weights of 1 for the purpose of our evaluations.This makes our results comparable to those of previously described methods.

HYPER-HEURISTIC PROBLEM DOMAIN MODEL
To enable problem-independent hyper-heuristics to work on the TLSP, we needed to provide several problem-specific components.
Here, the goal was to use flexible and modular components, such that they can easily be switched out and supplemented to deal with variations of the TLSP.Previously published solution approaches for the TLSP (e.g.[11,17]) serve to provide inspirations and baseline implementations for useful building blocks towards this goal.A more detailed description of our problem domain implementation is provided as supplemental material.For instance and solution representation, we reused the data structures developed for the metaheuristic approaches in [17].These also provide us with methods to evaluate the objective function, including efficient delta evaluation after applying changes.Initial candidate solutions are created by first grouping tasks into as few jobs as possible, and then assigning random modes, time slots, and resources to the jobs.
Regarding the solution evaluation, we had to make a further adjustment to ensure compatibility with the HyFlex framework, which assumes that candidate solutions produced by construction heuristics and LLHs are always feasible.For the TLSP, finding any feasible solution is already an NP-hard problem, so we cannot guarantee this property.While both construction heuristics and all LLHs respect grouping constraints, time windows, precedence constraints, mode and resource availability as well as resource requirement constraints, the linked tasks and single assignment constraints can be violated.We allow such infeasible candidate solutions during search, but add a high penalty of 10000 for each remaining conflict.This provides a strong incentive for the hyperheuristic to prioritize the search for feasible solutions at first and nearly guarantees that feasible solutions are evaluated as better than any infeasible ones3 .

Low-level heuristics
The portfolio of LLHs is the most important part of the problem domain.For most successful hyper-heuristics to work well, we need a selection of LLHs of each of the four types, with variety both in their complexity and the affected aspects of a solution.This enables hyper-heuristics to detect and apply the most useful LLHs for each instance and at any given moment in the search.In total, we developed 6 mutation operators, 13 local search heuristics, 2 ruin-and-recreate operators, and 3 crossovers (see Table 1 for a comparison with other HyFlex problem domains).The high number of operators compared to the other domains is explained by the TLSP's real-world complexity, with multiple aspects handled by different operators.
The first six domains are from the original competition [5], while the LLH portfolios for KP, QAP, and MAC were introduced in [ The number of moves is proportional to the DoS parameter, with a maximum of 100 moves at DoS = 1.0.
The ruin-and-recreate (RR) operators all follow the same principle: They delete assignments from a subset of all jobs and then greedily restore them one job at a time.The order in which the assignments will be restored is always the same: First, fixed assignments are added, then projects are selected in order of increasing release date of their earliest task.Within a project, jobs are selected in an arbitrary topological order.

Greedy reconstruct (multiple projects) Affects all jobs in a
subset of all projects.Leaves the task grouping unaffected.Greedy regrouping (single project) Affects all jobs of a single project, including their task grouping.A new grouping of tasks into jobs is also built greedily, assigning tasks to existing matching jobs wherever this is possible without conflict.
The local search (LS) heuristics mostly perform one or several moves of a local search procedure with different neighborhoods.Those search heuristics that allow worsening moves return the best solution found at any point during the search, not necessarily the last solution.Three different search heuristics are considered: Hill climbing selects the locally best move across all jobs, which is expensive but also guarantees to find local improvements if they exist.MinConflict selects a random job and applies the best possible move for that job.This scales well with increasing numbers of jobs, but may miss potential improvements in unselected jobs.Finally, stochastic hill climbing performs random moves and uses the Metropolis criterion to decide whether to accept them: Improvements or solutions of equal quality are always accepted, while worsening moves may still be accepted with probability  −Δ/ , where Δ is the difference in objective value and  is a fixed parameter called temperature.At higher temperatures, worse solutions are accepted with higher probability.
Hill climbing (mode, timeslot) Selects the best change in either mode or time slot for any job at each move.Hill climbing (resources) Selects the best change of a single assigned resource unit for any job at each move.Hill climbing (JobOpt) Selects the best (re-)assignment of mode, time slot and all resources for any job at each move.This corresponds to the changes available in the JobOpt neighborhood of [17].
Hill climbing (regrouping) Selects the best regrouping option for any job at each move, with the same options as for the Random regrouping move LLH.MinConflict (mode, timeslot) Selects the best change in either mode or time slot for a randomly chosen job at each move.MinConflict (resources) Selects the best change of a single assigned resource unit for a randomly chosen job at each move.MinConflict (JobOpt) Selects the best (re-)assignment of mode, time slot and resources for any job at each move.MinConflict (regrouping) Selects the best regrouping option for a randomly chosen job at each move.Stochastic hill climbing (high temperature) Performs a large number of random moves, using the Metropolis acceptance criterion at a temperature of 100.Possible moves include all options for reassignments of mode, time slot and resources, as well as the regrouping options described earlier.
The weight of hard constraint violations is set to 50 for the purpose of the Metropolis criterion.At this high temperature, moves that add no more than one or two hard constraint violations will likely be accepted.Stochastic hill climbing (low temperature) Performs random moves with the Metropolis acceptance criterion as the previous operator, but at a temperature of 5.At this low temperature, only moves that do not result in additional constraint violations have a realistic chance to be accepted.Stochastic hill climbing (minimal temperature) Performs random moves with the Metropolis acceptance criterion as the previous two operators, but at a temperature of 1.At this minimal temperature, moves are unlikely to be accepted if they increase the penalty at all, although there is a chance for very small increases.
All the above LLHs use the DoS parameter to determine the number of moves performed in a single LLH application.Those using hill climbing perform at most 100 moves at DoS = 1.0, those following the MinConflict-based search perform at most 500 moves and those based on stochastic hill climbing perform up to 50000 moves (as selecting random moves can be done very fast).The remaining two local search heuristics follow a different structure: Single project CP Uses a Constraint Programming solver to find the optimal solution for a single, randomly chosen project, while the rest of the schedule is kept fixed.The CP model used is the one described in [11].If the optimum cannot be found within a given time, the best solution found is returned instead.The available time is determined by the DoS parameter, with a maximum of 30s at DoS = 1.0.As a CP solver, we used Chuffed [8].Job-wise greedy Iterates over all jobs and replaces each job's assignments with the locally best ones, relative to the current assignment of all other jobs.Jobs are ordered according to their project's earliest release date, and within a project in an arbitrary topological order.
Incorporating the Single project CP required extending the HyFlex framework itself due to the call to the external CP solver, which the timekeeping module was not equipped to handle correctly.Our extension allows problem domains to keep track of time spent waiting on external processes in addition to their own processing time.
Finally, the crossover operators take two parent schedules as input and produce as offspring a new schedule that contains assignments of both parents.
Random project Randomly selects for each project whether the offspring should take the assignments of the first or the second parent schedule.Single point Randomly selects a time slot.Assignments for all projects starting before that point are taken from the first parent, the remaining assignments are taken from the second parent.Two point Randomly selects two time slots.Assignments for all projects starting before the first or after the second slot are taken from the first parent, the remaining assignments are taken from the second parent.
The LLHs described above were newly developed for the TLSP problem domain, although some reuse components of previously published methods.In particular, the MU operators (except Randomize) as well as the Hill climbing, MinConflict, and Stochastic hill climbing LS operators use the neighborhood relations described in [17], while the Single project CP operator uses the CP model described in [11], as mentioned.

EVALUATION
We evaluated our implementation on a set of state-of-the-art hyperheuristics available for HyFlex: We compare TS-ILS [3] 4 and FS-ILS [1] 5 , the first and third place hyper-heuristics6 of a recent comparison [16], plus RL, a hyper-heuristic based on reinforcement learning described in that paper 7 .The authors of TS-ILS also published a new hyper-heuristic just this year, EA-ILS [4]8 , which was not yet available for the previous comparison.Finally, we also included AdapHH [19] 9 , the competition winner of 2011.
The selected hyper-heuristics were run on a benchmark server with 224GB RAM and two AMD Opteron 6272 Processors each with a frequency of 2.1GHz and 16 logical cores (the same machine used for the evaluation of SA and VLNS [10,17]).Each hyper-heuristic was executed 15 times on each of the 33 benchmark instances used in [17], with a timeout of 10 minutes per run.This instance set consists of 30 randomly generated instances of various sizes and properties, plus 3 real-world instances taken from our industrial partner.Notably, we did not perform any problem-specific tuning or adaptation for any of the evaluated hyper-heuristics.
The results of these evaluations are listed in Table 2.For comparison we also included results of the current state-of-the-art solvers for the TLSP, SA [17] and VLNS [10] 10 .
Table 2: Results for the five evaluated hyper-heuristics on the TLSP problem domain, plus results for SA [17] and VLNS [10], under a time limit of 10 minutes.For each hyper-heuristic, the table lists the number of feasible solutions found (Feas), the average objective value among feasible solutions (Avg), and the best solution found (Best).The best objective value found by any method within this time limit for each instance is marked in bold.The five hyper-heuristics managed to find feasible solutions for between 73% (RL) and 83% (AdapHH) of all runs, as shown in Table 3.Despite being proposed already in 2011, AdapHH clearly managed to find solutions of better quality in general than the other more recent hyper-heuristics (see Figure 2) in addition to finding the most feasible solutions.
The three real-world instances seem to be particularly hard to solve across all methods except VLNS, and particularly so for the evaluated hyper-heuristics.According to an analysis of these instances in [17], an important factor in making them more challenging to solve than the randomly generated instances of comparable size seems to be inclusion of employee vacations and other absences.Modeled as additional blocker tasks with a fixed employee  and time slot assignment (and no other resources required), these absences split the available periods of each employee into several smaller fragments, making it more difficult to fit the remaining tasks around the blocker tasks.Given that VLNS uses a CP solver to produce the initial (already feasible) solution, it is not impacted as much by these more tightly constrained instances.
The comparison with SA and VLNS is shown in Figure 3.Even without any problem-specific tuning, AdapHH was able to find solutions that match the quality of those produced by the specialised algorithms, although it did find slightly fewer feasible solutions.AdapHH managed to find the best known solutions under that time limit for 13 instances, 8 of which are better than the best results produced by SA and VLNS.After scaling the objective value of each feasible solution by the best objective value found for that instance, median results for AdapHH, SA, and VLNS are 1.043, 1.068, and 1.022, respectively.Overall, AdapHH produced better results than SA (one-sided Wilcoxon rank-sum test,  = 70159,  < 10 −8 ), though it is beaten by VLNS ( = 24151.5, = 0.002).Looking at small (≤ 20 projects) instances separately, one can see that SA struggles with finding the best solution on small instances, strengthening the advantage of AdapHH on those instances ( = 16825,  < 10 −14 ).Conversely, VLNS falls behind on larger instances to the point where it is overtaken by AdapHH ( = 4440,  = 0.048).

Usage of low-level heuristics
Finally, we also investigated the use of the different LLHs we introduced for the TLSP.For this purpose, we logged the number of calls to each LLH made by AdapHH during a single run over all instances.The results are displayed in Figure 4.While this distribution of course depends on the behavior of the hyper-heuristic, particularly with respect to difference between different LLH types, we can still gain some interesting insights from it.Overall, AdapHH clearly favored fast LLHs over slower and more expensive ones.This affects mostly LS heuristics, except for LS:OneByOneGreedy and to a lesser extent MinConflict with the two smaller neighborhoods, but can also be seen in the MU heuristics where those that change only a single assignment are used more often.
An interesting difference can also be seen between large and small instances: The weaker MU operators (MU:Random[Mode/ Timeslot/Resource]Move) were chosen far more often on small instances.A potential reason for this behavior is that smaller perturbations are already sufficient to reach new areas of the solution space on these instances, while stronger perturbations destroy too large parts of a solution.On larger instances on the other hand, AdapHH placed more emphasis on LS heuristics, particularly those that can be applied quickly, and the RR:Regroup operator.We observed that in general, runtimes of each operator increase with instance size, although some scale faster than others, particularly those that have to examine all jobs in each iteration.Accordingly, fewer operators can be applied within the time limit for large instances, while the number of potential sites for local improvements increases.This allows a larger number of initially successful LS applications and by the time the solution quality reaches local optima that would require more exploration to allow further improvements, the time limit is already reached.
This trend can also be observed when looking at the percentage of successful applications of each LLH (Figure 5), i.e. those that resulted in a new best solution for the run.As expected, most improvements were found by LS and RR heuristics, particularly those searching more complex neighborhoods.Here it can be seen that success probabilities are consistently higher on larger instances, indicating that the search on smaller instances spends most of its time in regions of the search space that are already close to optimal, such that further improvements are difficult to find.

CONCLUSIONS
In this paper we have investigated the use of problem-independent hyper-heuristics to solve a real-world industrial project scheduling problem.To be able to apply general purpose hyper-heuristics to this problem, we proposed a new problem domain for the TLSP as an extension to the well-known hyper-heuristic framework HyFlex.In doing so, we developed a diverse portfolio of LLHs of all four types supported by HyFlex, which have different characteristics and affect different aspects of the problem.They can be selected and applied by hyper-heuristics during the search in order to find high-quality solutions.
We experimentally evaluated our approach on five state-of-theart hyper-heuristics.In particular the hyper-heuristic AdapHH, the winner of the CheSC 2011 hyper-heuristics competition, proved to be very successful on this new problem domain.Also compared to the currently best problem-specific algorithms for the TLSP, SA and VLNS, AdapHH could provide very good solutions, including 13 best known solutions for the given time limit.Moreover, it achieved this level of performance on instances of all available sizes, while both SA and VLNS excel only on particularly large, respectively small instances.
Our results clearly show that general and problem-independent hyper-heuristics, using an appropriate set of modular and complementary LLHs, can compete with specialised methods even without any problem-specific tuning.
Of particular note is that due to the constraints of the HyFlex framework, each run of a hyper-heuristic started out without any knowledge of problem domain or LLH performance characteristics, a major drawback compared to previous approaches which include problem-specific knowledge already in their design and tuning.Storing the information gained during earlier runs and using it to boost hyper-heuristic performance on repeated runs on the same problem domain could lead to even better results.
In the future, we also intend to build upon these results by analyzing the impact of individual LLHs on the performance of different hyper-heuristics, as well as their interaction with each other and the parameter values chosen by hyper-heuristics for those LLHs.This includes an investigation of the suitability of the LLH portfolio for similar project scheduling problems, including potentially additional operators to deal with new aspects of those problems.
We also plan to integrate our problem domain implementation into the existing real-world scheduling system, so that hyperheuristics can be used in practice next to the existing solution methods.

Figure 2 :
Figure 2: Comparison between results of different hyperheuristics on the TLSP problem domain.Results for each instance were scaled by the best result achieved on that instance.

Figure 3 :
Figure3: Comparison of results for the RL and AdapHH hyper-heuristics with those achieved by SA[17] and VLNS[10].Results for each instance were scaled by the best result achieved on that instance.Results are shown separately for all instances, for small (≤ 20 projects) instances only, and for large (> 20 projects) instances only.

Figure 4 :Figure 5 :
Figure 4: Relative usage of each LLH by AdapHH.Shown are average statistics over all instances, only small instances, or only large instances.

Table 1 :
Comparison of LLHs in different problem domains.
2].The mutation (MU) operators apply random changes to a given schedule: Random mode move Randomly changes the assigned mode of a job to different one.Replacement modes can be selected only if this would not introduce conflicts regarding precedences or time windows.If this changes the number of required employees, randomly chosen employees are added or removed.Random timeslot move Randomly moves a job to a different time slot.Random resource move Randomly replaces a single workbench, employee, or device assigned to a job by a different one.Random regrouping move Performs a single random move that alters the task grouping.This can be either a transfer of a task to a new job, merging two existing jobs into, or splitting off a subset of a job's tasks into a new job.If this move changes the resource requirements of any involved job, resources are added or removed randomly.Otherwise, existing time slot, mode, and resource assignments are kept if possible.Randomize A larger mutation that selects a subset of all projects and randomizes the assignments of all jobs, leaving only the grouping intact.The IoM parameter determines the fraction of projects randomized.Random walk Performs multiple moves of a random walk procedure, using a combination of all scheduling and regrouping neighborhoods employed by the first four LLHs.

Table 3 :
Percentage of feasible solutions found by each hyperheuristic within 10 minutes, as well as SA and VLNS.