1. Introduction
The permutation Flow Shop Scheduling Problem (or FSSP) with makespan minimization is one of the oldest [
1] classic discrete optimization problems. In the problem, there are
n jobs processed in a system made up of
m machines. and each job is processed on each machine in the same, predefined order. The task is to find an order in which the jobs are fed into the system that minimizes the time required to process them all (makespan). FSSP is commonly used to model and optimize various real-life manufacturing processes in industry or even other non-manufacturing multi-stage processes.
Since its introduction, FSSP have been extended and modified in many ways to model specific restrictions found in real-life production processes [
2,
3,
4]. One of its most popular and earliest (see, e.g., a paper by Johnson [
1]) extensions is considering setup times. Setups are meant to model additional activities performed on a machine between processing subsequent jobs. Such activities can include cleaning, re-fueling, inspection, change of machine settings (including different tool tips, etc.) or simply removal of the processed item and insertion of another.
Usually [
5,
6], it is assumed that setups can be performed independently, i.e., in the
m-machine system, and up to
m setups can be performed at the same time, provided each is conducted on a different machine. This is generally because either the machines are maintenance-free or there are separate crews for each machine available. However, in some production processes encountered in practice, it is not possible to perform setups simultaneously. This leads to a class of problems referred to as
single-server problems [
7], where a single server performs all setups in the system.
An example of such a restriction was found in a production process in a company located in Poland. The process involves metal-forming parts for various home appliances with the use of large hydraulic presses. Due to the size of the presses, heavy specialized carts are required to reconfigure them for different product types. The company owns only a single cart (server), due to its costs and the crew required to operate them. As a result, only a single machine can undergo a setup at any given time, i.e., the setups are disjoint.
We consider a special case of FSSP with sequence-dependent setup times, where only one setup crew is available (called hereinafter
a full problem), and, at most, one setup can be performed in a system at a time (hence the setups are
disjoint, or in other words—there is a single server). The motivation to tackle this problem is that despite the fact that disjoint setups are a practical constraint in the context of FSSP, they have not been adequately researched in the literature. Most of the previous work focused on theoretical complexity analysis, lacking a dedicated solving method or problem properties (see review in
Section 2). The full problem can be dissected into two levels: (1) finding the order in which jobs are processed in the system (the upper level); and (2) finding the order of setups (the lower level). Such a decomposition into upper and lower problems is an existing literature practice when tackling complex scheduling problems (see, for example, Pongchairerks [
8] or Bożejko et al. [
9]). The full problem is relatively complex, as its NP-hardness has been proven even for several simplified cases (refer to the paper by Brucker et al. [
10]). Thus, we decided to focus exclusively on the part introducing new constraints compared to relatively well-researched FSSP. Therefore, in this paper, we consider only a second level of the full problem, i.e., the order of jobs is fixed and only the order of setups is to be determined. We aim to identify problem properties and introduce new solving methods that can be used later to tackle the full problem, e.g., using a two-level approach.
The main objectives of this paper are to: (1) introduce a formal model of the researched problem; (2) formulate properties concerning the solution space of the problem: its size and methods of limiting the portion of the space that needs to be examined; (3) use the properties to propose solving methods that can be used in a two-level algorithm for the full problem. We achieved the goals by building a lattice path representation of a solution and identifying problem properties that allow us to explore the solutions space more efficiently. The main contributions of this paper are as follows:
Proposing a mathematical model for the researched problem, i.e.,
finding the order of setups in FSSP with a single-server (see
Section 1). The model can be easily extended to describe the full problem.
Showing a relation between the number of feasible solutions and Catalan numbers for
machines (see
Section 4.2) and providing a method based on Dynamic Programming for counting feasible solutions for any
.
Formulating an elimination property that allows us to quickly disregard the majority of the problem solution space (see
Section 4.5), without losing optimality (see
Section 4.3).
Formulating a refinement procedure, based on the rearranging of continuous blocks of setups performed on the same machine. Such a procedure can improve some solutions in a time required to calculate an objective function (see
Section 4.4).
Introducing a Mixed Integer Linear Programming (MILP) formulation and a dedicated, heuristic solving method for the researched problem (see
Section 5) that can be used in a two-level algorithm for the full problem. The experiments demonstrated that the heuristic algorithm (using the proposed problem properties) outperforms the MILP formulation for larger instances (see
Section 6).
The remainder of this paper is structured as follows. In
Section 2, we present a related literature, with the main emphasis on the FSSP and setup times. In
Section 3, we formally define the researched problem and introduce a compact solution representation. Then, we follow with several problem properties in
Section 4. The solving algorithms are described in
Section 5 and tested in
Section 6. Finally, the concluding remarks are in
Section 7.
Notation
Throughout the paper, we will adopt the following notation. Boldfaced lowercase letters (
,
) denote vectors (or sequences), with the
k-th element of
denoted
, and
0 being the zero vector. Ordinary letters, especially lowercase, usually denote scalars. Sets are generally denoted with calligraphic type (
) with the exception of
and
. Symbols
i and
j are used to refer to jobs (e.g., when iterating). Similarly,
a and
b are used to refer to machines, while
k and
l are used to refer to setups. The most important notation is summarized in
Table 1.
3. Problem Formulation
In this section, we will formally state the researched problem, and formulate its mathematical model. We will discuss different solution definitions and point to the one that limits the size of a search space.
The problem is based on the classic FSSP with setups. Each job from the set must be processed on each machine from the set . We assume that the order of jobs is fixed. The processing of a job on a machine is called operation and takes time. Between each two consecutive jobs performed on the same machine , a setup must be performed. The setup also cannot be interrupted and takes time. The constraints on the systems can be summarized as follows:
Each job is processed on each machine in a natural order .
Each machine processes jobs in a natural order .
Between each two consecutive operations on each machine, there is a setup.
Operations and setups cannot be interrupted.
Each machine can process at most one job at any time.
At most one setup can be performed in the system at any time (the system has single-server or, equivalently, setups are disjoint).
Thus, at any given time, a machine is in one of three possible states: (1) processing a single operation, (2) undergoing a single setup, or (3) idling. The total number of disjoint setups in the system is (there are setups on each of m machines). To shorten various equations, we also define an auxiliary set as , which is used to enumerate data structures and notation related to setups in different contexts later on.
The solution of the problem can be represented by a
schedule. A schedule is a set of starting and completion times for all operations and setups. By
and
,
, we will denote the starting and completion time of the operation of the job
i, being processed on the machine
a. Analogously, by
and
,
, we will denote the starting and completion time of the setup performed on the machine
a, after the job
i. With the introduced notation, the problem constraints can be formalized as
where “⊻” is an exclusive OR. Constraints (
1) and (2) guarantee that operations and setups cannot be interrupted. Constraint (3) represents the sequential processing of a job (technological constraints). Constraints (4) and (5) guarantee that setups and operations performed on the same machine do not overlap and are performed in a predefined order (machine constraints). Finally, Constraint (6) assures that at most one setup can be performed in the system at any time. A schedule is called
feasible if it satisfies all the Constraints (
1)–(6). The problem is to find such feasible schedule, so that the
makespan is minimal. Without losing generality, we can fix the time the first job starts being processed; thus, we set
:= 0. This simplifies the computation of the makespan as
.
A schedule representation of a solution leads to an infinite set of possible solutions. Therefore, usually representing the solution by precedence constraints is better suited for both theoretical analysis and solving algorithms. Even though the order in which the jobs are processed is fixed, the order of the setups is not. Let
describe an order in which setups are performed, where
,
, denotes the
k-th setup performed in the system and
is a set of all possible setup orders. Setups are identified by a pair of numbers
, where
is the machine on which the setup is performed on and
is the job the setup is performed on afterwards. The number of all possible setups orders
is equal to
. We say that an order of setups is feasible if it describes at least one feasible schedule. Since the order of setups on each machine is fixed, each feasible order of setups can be described unambiguously by the order of machines on which setups are performed
, where
,
is the machine on which the
k-th setup is performed. When describing a setup order, we will refer to one of the two representations:
or
, depending on the context. In order to transform any feasible
into a unique
, one can simply disregard a job number from each pair describing a setup. The reversed procedure is also possible, by assigning consecutive jobs to the setups performed on the same machine (refer to Example 1). Interestingly, sometimes an infeasible
can be transformed by this method into a feasible
(as observed in the example). The number of different
, denoted
, is smaller than
, and equals
The set of all feasible
is denoted by
.
Example 1. Consider a setup order for instance with and :The setup order is infeasible, e.g., is scheduled to be the first setup, while operation 1 of job 3 cannot be performed yet, as the setup is not completed. Now, consider the setup order , that was built from . This setup order is feasible and can be transformed into a feasible setup orderNow, consider an infeasible setup orderIts corresponding setup order is also infeasible. For a given setup order
to become a solution representation, a quick method for transforming a feasible
into a unique feasible schedule is required. We will limit our discussion to
left-shifted schedules, that is, the schedules where no setup or operation can be performed earlier, without changing the order of setups. It can be easily demonstrated that each feasible solution
describes exactly one feasible, left-shifted schedule, and each left-shifted schedule is described by exactly one
. This schedule can be built similarly to how a schedule is built based on an order of operations in the Job Shop Scheduling Problem (e.g., in a paper by Nowicki and Smutnicki [
49]), since Constraints (
1)–(6) can also be represented as a sparse, acyclic, weighted graph. Thus, for any
, the corresponding schedule can be built in
time. We define that the makespan of
is the makespan of the corresponding left-shifted schedule, and denote it by
. Since each optimal schedule can be transformed into a left-shifted one without affecting its makespan, the considered problem can be rewritten into finding an optimal setup order
, such that
Hereinafter, unless otherwise stated, we will only use the setup order representation
.
Example 2. Consider the instance with , and processing times and setup times from Table 2. The order of setups is feasible for that instance. A left-shifted schedule for solution , with , is shown as a Gantt chart in Figure 1. Note that is not an optimal solution. For example, the first setup on machine 2 could be performed earlier (during the third operation on machine 1). 4. Problem Properties
In this section, we will formulate several problem properties, particularly the ones regarding the solution space. We start by demonstrating the solution representation using mathematical concepts of lattice paths. We then discuss the number of feasible solutions and the ways to compute it. We formulate two theorems that can be employed in solving methods: an elimination property for skipping certain solutions and a refinement procedure that can improve solutions. Finally, we discuss what portion of the solution space can be skipped by use of the formulated properties.
4.1. Lattice Path Solution Representation
As it was demonstrated in the previous section, some orders of setups are infeasible. To better illustrate the nuances of the solution feasibility in the researched problem, we will introduce the lattice path representation of a solution.
Formally, a lattice path is a sequence of points in , where the difference between any pair of consecutive points , is in a predefined set. Elements of the set are called steps. Here, the set is a standard basis and . One can associate each step , with an act of a setup being performed on machine a. Consider lattice path L from to , consisting of steps in . Each point in this path can be interpreted as a state of a production system with setups already performed on machine a. Then, since there are steps to be performed on each machine, each L represents a unique sequence of setups.
Example 3. Consider a problem size , and a setup order . The transformation from to the corresponding L can be performed as follows. Start building the path from (the number of dimensions ). Then, for each element in , build sequentially a new point in L by adding 1 to the coordinate given by value of of the previous point. Refer to the equations below:The reasoning can be reversed to calculate the corresponding to L. The introduced lattice paths can describe not only feasible setup orders, but also infeasible ones. The problem Constraints (
1)–(6) can be directly translated into the domain of lattice paths, by limiting admissible paths to ones consisting of elements in
The interpretation of Equation (
13) is that, at any time, the number setups performed on machine
a cannot be greater than the number of setups performed on previous machines
plus one. Note that
does not put direct constraints on a maximum and a minimum number of setups performed on any machine (i.e., constraint
). Such constraints are represented in the set of feasible steps, as well as in the described lattice paths’ start- and endpoints.
4.2. Counting Feasible Solutions
With the lattice path solution representation introduced, one can easily calculate the number of different solutions for a given
n and
. The following Lemma 1 was first demonstrated by Gnatowski et al. [
42]. Here, however, we will show a proof that will be derived from the general case described in (
13).
Lemma 1 (Number of feasible solutions,
[
42]).
Consider a problem instance with machines and operations. The number of different feasible setup orders is given by the n-th Catalan number Proof. The relation between Catalan numbers and the number of feasible setups can be explained in multiple ways. One can use an analogy to the problem of finding the number of possible legal sequences of parentheses; to several different Dyck words-related problems; or to more or less general lattice paths’ analysis (see, for example, a paper by Stanley [
50]). Here, we will explore on the last mentioned possibility, as it also provides some insight into the multi-machine variant of the problem.
For
, Equation (
13) becomes
Equation (
15) limits the admissible lattice paths from
to
in
, to the ones weakly below line
. Such paths will be called
paths (as shown in
Figure 2).
Consider lattice paths
from
to
, with steps in
, staying weakly under
. In any
, the first and the last step are fixed (bold arrows in
Figure 2). Therefore, the number of different
paths is equal to the number of different
paths. Now, by translating the first axis by 1, the
starts in
and ends in
, staying weakly under
. The problem of finding the number of different paths defined as such is well known, and has a solution of
. For the proof of this fact, as well as other occurrences of Catalan numbers in mathematics, refer to [
50]. □
While for
, the number of different feasible solutions can be computed using (
14), the case of
is much harder. The reasoning from the proof of Lemma 1 cannot be trivially applied for any
, even though generalizations for multi-dimensional Catalan numbers exist (see, for example, papers by Haglund [
51] or Vera-López et al. [
52]).
The constraints on lattice path defined by
are relatively complex and—to our knowledge—cannot be addressed by lattice path analysis methods (refer to e.g., a paper by Krattenthaler [
53]) to obtain a useful closed-form expression for computing
. On the other hand, recursive formula can be easily obtained and used as a basis for a Dynamic Programming (DP) algorithm, calculating the number of feasible solutions for any
.
An outline of the proposed DP method is shown in Algorithm 1. A subproblem given by any
is defined as finding a number of different lattice paths from
to
, satisfying (
13). Observe that it is equal to the number of different paths from
to each point
, where
is any point in
that can be
stepped back from
(i.e.,
). For example, for
, admissible
. Different candidates for
are created in line 7, while in line 8, it is determined whether they are in
. Lastly, a degenerate subproblem
has solution of 1, and constitutes a stop criterion for the recurrence (line 3).
Property 1. Algorithm 1 runs in time, using memory.
Proof. First, let us count the number of recursive calls of
CountSolution. Since the result for each unique
is eventually stored in
mem, the number of calls and the memory complexity of
mem cannot be greater than a cardinality of
where the latter set reflects origin and destination points for the lattice path
L. In another words,
mem must be able to store solutions to the subproblems corresponding to each point that can appear in
L. A simple upper bound for such is obviously
, which is the cardinality of the latter set. This allows
mem to be a continuous block of
memory registers, since it takes
to initialize them (line 1). The memory block can then be indexed similarily to
C++ arrays, i.e.,
mem(
) is understood as
mem(
), where
Equation
(17) is a simple one-to-one mapping of all possible nodes of the considered lattice paths to numbers
. The mapping is analogous to a flat array index for multidimensional arrays. The index notation is used to accelerate some computations, taking advantage of an unbounded capacity of a single memory cell (each memory cell of an assumed abstract machine can hold any integer). In a constant time, one can not only access or modify any element of
represented by
, but also copy
, which is not possible for
directly.
Algorithm 1: Counting feasible solutions |
Data: , a point in . Result: : number of feasible solutions (paths from to in ). |
Next, let us derive the computational complexity of a single CountSolution call. Lines 3–6 can be conducted in time. Although the computation of the index of takes time, any change in a constant number of elements in can be reflected in in constant time. Therefore, lines 9 and 15 take time. Line 10 can be conducted in time, by using cumulative minimum from line 6. Memory access in lines 11 and 13 can also be conducted in time, using precomputed index —resulting in an overall time complexity of . Memory complexity of a single CountSolution run is .
Overall, the computational complexity of the proposed algorithm is
The memory complexity is
□
A tighter bound can probably be demonstrated for the cardinality of (
16) (by a factor of
). Then, however, one could not use a simple index
to access memory, leading to a potentially worse computational complexity.
Because of the time and memory complexities, Algorithm 1 performs best when
. Such an assumption is usually realistic. Even then, the algorithm can only be used to compute
for small and medium instances.
Table 3 summarizes the differences between
and
for several
n and
m combinations. In particular, for
, the
can be calculated directly
Clearly, the number of feasible solutions is significantly smaller than the total number of solutions.
4.3. Elimination Property
In this section, we will discuss the elimination property, which can be used for a quick detection of suboptimal solutions or to potentially improve a solution (as shown in
Section 4.4). The property relates to the consecutive setups performed after the same job—constituting a
block.
Definition 1. For solution , let be a k-th node of the lattice path corresponding to , i.e., denotes how many setups were performed on machine a after setup was completed. Let be an h-element subsequence of subseqeuent setups from starting at element k. Subsequence will be called a block of setups in solution (in short, a block) if and only if:
- 1.
All setups in are performed on a different machine: - 2.
All setups in are performed after the same job: - 3.
The length h of the block is maximal i.e., of length starting at k is not a block.
- 4.
Blocks partition the sequence , i.e., each element belongs to exactly one block.
We will illustrate the above definitions with an example.
Example 4. Consider the following solution:We start with lattice path node . We then perform . All setups are on different machines and after the same job (, thus is the first block. Note that we cannot define the first block as , because setups are not on different machines. We are now on lattice node . The next block cannot be , because . Thus, , leading to . Similarly and not because . This leads to node . Next, the block cannot be because , but it can be , leading to node . Next, we cannot have a block (machines are not different) or (; thus, the next two blocks will be and leading to nodes and then . Finally, we have , as all elements are different and , leading to . Thus, solution contains seven blocks, as marked by the brackets below. With the blocks defined, the elimination property can be formulated. The property is a generalization of the result presented by Gnatowski et al. [
42], for any
.
Theorem 1 (Elimination property).
Let be a feasible solution, with two consecutive setups , , in a block of job ; such that . Then, a solution , where the order of the setups is reversed,is feasible and . Proof. The proof is based on an analysis of left-shifted schedules build from both
and
. The elements of the schedule build from
are denoted with hats (
,
, etc.). Moreover, let
denote the completion time of setup
, which is unaffected by the swap. The notation is presented in
Figure 3.
First, let us identify elements of schedule not affected by the change in the order of setups. Since
k-th setup in the original solution is performed on machine
b, then by the time the setup can start, the first
b operations of job
j must be already performed before the setup is started (marked in bold in the figure). Therefore,
and
remain constant for both setup orders. As a result, the completion time of setups in
performed after job
j on machines
, can only be affected by a change in completion time of
-th setup. The change can be expressed as
, where
Then,
Since
, we have
and the completion time of
-th setup cannot increase in
. As a result, the operations in job
preceding operations on machines
a and
b cannot be delayed, thus
and
. Therefore, if also operations in job
performed on machines
a and
b can only start earlier, then makespan also can only decrease. We check that further.
Let us discuss the change in completion time of job
on machine
a,
Knowing, that
, we only need to calculate
Since
, then the value of (
28) is non-negative and therefore
and
.
Next, let us discuss the change in completion time of job
on machine
b. Since
, we have
Since we know that and , then also .
To sum up, it was proven that in the left-shifted schedule build for , completion time of jobs on machines can only decrease compared to the schedule build for . The same can be said about completion time of -th setup. Therefore, all further jobs and setups can only be performed earlier, resulting in . □
Theorem 1 allows to detect potentially suboptimal solutions. Since the described transformation cannot lead to an increase in makespan, any that fulfills conditions of Theorem 1 (i.e., satisfies the elimination property) can be safely eliminated from the solution space, without the risk of removing all optimal solutions.
4.4. Refinement Procedure
Theorem 1 provides tools for reducing the size of the solution space. However, it can also be observed as a way to potentially improve a solution, by applying a swap move on the setups satisfying the elimination property. A single solution can contain multiple such setup pairs. Moreover, the swap can create a new pair of setups satisfying the elimination property, as shown in Example 5.
Example 5. Consider a problem size of and . Solution is feasible; however, two setup pairs: and , satisfy elimination property. By applying the swap move to the first pair, we obtain solution —now containing a single, new pair satisfying the property. By applying the swap move, we obtain . Once again, the solution contains a pair , . Finally, the swap move can be applied a third time to obtain . The setup order does not satisfy the condition from Theorem 1 and cannot be eliminated. The procedure can be summarized as follows: The observation above is a basis of a
refinement procedure. Given a solution
, the procedure performs setup swaps until Theorem 1 cannot be applied anymore. The resulting solution
is said to be refined and
Of course, there exist solutions that do not contain any setup pairs satisfying the elimination property. In such a case, no swaps are performed. In Example 5, the solution
is the result of refining the solution
.
A few questions arise with regards to the refinement procedure, namely, how to detect which swaps should be performed and in what order. Moreover, we would like to know how fast could this procedure be performed. We will answer those questions in the following theorem, using the fact that the procedure resembles the bubble sort algorithm.
Theorem 2 (Block property). For any feasible solution σ, the refinement procedure can be completed in time.
Proof. First, observe that rearranging setups within a single block does not change the total number of blocks or contents of other blocks. Therefore, the refinement can be applied for each block separately. Consider a block with a length of
l. There is only a single order of setups, for which no pair of setups in the block satisfy the elimination theorem—setups ordered increasingly by the machine on which they are performed. The block can be sorted by applying at most
swap-moves, chosen according to the elimination theorem (refer to bubble sort results by Cormen et al. [
54] (p. 40)). As a result, the worst case time complexity of the procedure would be
. However, the sorting can be performed quicker in
by using Algorithm 2, which sorts all blocks simultaneously. □
Algorithm 2: Refinement procedure |
Data: : solution to be refined. Result: : refined solution. |
The refinement procedure can be utilized to potentially improve the quality of solutions as a part of larger solving algorithm (e.g., similarly to the individual learning procedure in memetic algorithms proposed by Moscato [
55]). The computational complexity of
is equal to the complexity of calculating the objective function; thus, the refinement procedure can be used frequently.
4.5. Counting Eliminated Solutions
In order to estimate how much of the solution space can be eliminated, we first discuss the number of setup orders that
cannot be eliminated (preserved solutions). For
, the number is given by a known, closed-form expression, first proposed in the lemma by Gnatowski et al. [
42] (without a proof). Here, we present a proof for the lemma.
Lemma 2 (Number of preserved solutions
[
42]).
Consider a problem size , . The number of feasible solutions not eliminated by Theorem 1 is given by the -nth Catalan number Proof. For the elimination property to be applied, two consecutive setups must be performed after the same job, but on different machines. For , it means that the first setup must be performed on machine 2, and the second on machine 1. For that to be possible, all the setups between previous jobs must already be performed. Such a condition corresponds in the domain of lattice paths to the points on line. Then, step (setup performed on machine 2, against elimination property) moves the lattice path above , and step keeps the lattice path below . Therefore, the elimination property limits the admissible lattice paths from to , to stay weakly below the line. The number of such paths is given by . □
The Lemma 2 allows one to easily obtain the number of preserved solutions for , and thus the number of eliminated solutions.
Theorem 3 (Eliminated solutions for
[
42]).
Consider a problem size , . Theorem 1 eliminates 50% to 75% of feasible solutions. The proof will be omitted, as it was demonstrated in [
42].
Since even for calculating and , a closed-form expression is not known; to compute the number of preserved solutions, we will resort to the DP approach again. Algorithm 1 must be modified to check both the elimination property condition and the feasibility. For the modified procedure, refer to Algorithm 3.
Algorithm 3: Counting preserved solutions |
Data:: potin in . Result:: number of unique preserved solutions. |
To allow for checking the elimination property, the machine on which the last setup was performed must be added to the definition of a subproblem. For example, for and , the last setup could be performed on any of the three machines (1, 2 or 3). In the Algorithm 3, the machine the last setup was performed on is stored in .
Property 2. Algorithm 3 runs in time, using memory.
Proof. The proof is similar to the proof of Property 1. However, now the number of subproblems is m times larger, since each can be potentially matched with any . It results with both computational and memory complexities greater by a factor of m. □
The Algorithm 3 was used to compute the number of unique preserved solutions, denoted by
, for
and
. Then, an elimination ratio
was calculated. The results are demonstrated in
Figure 4. For
, only a single setup order is preserved, resulting in high elimination ratios that can be calculated from Equation (
14). For
,
increases with the increase of
n, eventually overtaking the value for
. For instances with a larger number of machines, the elimination ratio continues to increase steadily, reaching almost
for
.
6. Experimental Results
In this section, we describe the computer experiments on the effectiveness of the proposed solving methods on different instance types.
6.1. Experimental Setup
We conducted tests on the following three algorithms described earlier:
- MILP
a commercial solver using the MILP formulation of the problem from
Section 5.2;
- TabuA
TS method from
Section 5.3, that does not use elimination property to reject neighbors, but uses refinement procedure to improve the best neighbor;
- TabuB
TS method from
Section 5.3, that uses elimination property to reject neighbors.
The TabuA and TabuB algorithms were written in C++ programming language and compiled using g++ version 9.3.0 (with -O3 compilation flag). The MILP formulation was written in Julia programming language version 1.5.3 and employed the Gurobi solver version 9.1.1.rc0 with the default parameters and presolver turned on.
The experiments were run on a machine with 64-core AMD Ryzen Threadripper 3990X processor with 2.9 GHz clock and 64 GB of RAM. Each algorithm used only one CPU core. The experiment was run under a Windows 10 Pro operating system with Windows Subsystem for Linux.
6.1.1. Test Instances
We prepared 120 test instances by the use of a modified version of the FSSP instance generator proposed by Taillard [
62]. We use the same random number generator as Taillard, which is meant to provide integer numbers from uniform distribution
. Both operation processing times and setup times were drawn from this distribution. We first generated
processing times, identical to Taillard. Then, we generated—without reseeding the random generator—all
setup times, starting with the first machine. We generated setup times for each possible job pair; however, only a single pair is used, as the order of jobs is fixed. We generated 10 instances for each of the following size groups (
):
,
,
,
,
,
,
,
,
,
,
,
. All instances were given identifiers from 1 to 120. All generated instances are available in the
Supplementary Materials to this paper.
6.1.2. Evaluation Method
To measure the quality of the solutions provided by the algorithms, we calculated the percentage relative differences between their quality and the quality of reference solutions—called short gaps. In other words, the gap for a solution
is defined as:
where
is a reference solution. Generally, we chose
to be the best known solution in a given context.
6.2. Width of the Neighborhood
First, we investigated how the width of the neighborhood
W affects the performance of the TS algorithm. We ran the TabuA algorithm with
for all 120 instances. For each instance, the algorithm was run 100 times, and each time
W was set to a different value, equal to a given fraction of the maximum possible neighborhood width. For example, for
and
, the value of
W is in
. Then, a 50% width corresponds to
W = 145. The reference solution for computing the gap was the best among all 100 runs for each instance. The resulting gaps, averaged over all instances, are shown in
Figure 6.
Higher values of W provided considerably worse results, i.e., a larger neighborhood size does not compensate the larger time required to evaluate it. Thus, lower values of W are preferred. However, a very small neighborhood size also leads to a larger gap. Such results are to be expected, as in high quality solutions, most setups are close to their initial positions in the order generated by the starting procedure, and wide inserts are rarely required. On the other hand, a very narrow neighborhood requires multiple TS iterations to perform any significant change in . Based on this observation, we set W to 10% of the maximum neighborhood width in the following experiments.
6.3. Performance of the Algorithms
In this experiment, we have evaluated the performances of the MILP formulation and the TabuA and TabuB metaheuristics, which utilize the problem properties. In order to correctly compare such different solving methods, we opted to use the same stopping condition—a time limit. Since we intend for the solving methods to be applicable as sub-procedures for solving a two-level problem, the short running time is crucial. Thus, we decided to test several short time limits
seconds. Although the times
are the most practical in the context of a two-level problem, we considered times up to 100 s to better evaluate how the solving methods converge. For each instance, the reference solution was the best one found by any algorithm in 100 seconds (the makespans of the reference solutions can be found in the
Supplementary Materials). The results obtained are shown in
Table 4.
For smaller instances (up to 3 machines, under around 60 operations), the MILP formulation is consistently better or on-par with any TS algorithm, regardless of the time limit. In fact, the solver frequently reported for the returned solutions to be optimal and therefore unbeatable by TS. However, for larger, industry-size instances, the TS algorithm performs better than MILP. Once again, this effect is consistent over all time limits.
Comparing the two TS algorithm variants, TabuB (which makes a wide use of Theorem 1) is consistently better or on-par with TabuA (which uses only the refinement procedure). For larger running times (), both TS algorithms start to provide similar results. This demonstrates that, given enough running time, both versions of the TS algorithm converge to solutions of a similar quality. However, the TabuB variant is superior in convergence speed, outperforming TabuA for and staying on-par with it for . This is easily observed in the last rows of the table, showing the difference (gain) between and time limits. For TabuB, the values are close to 0, meaning the algorithm does not benefit from a higher running time, while still equaling or outperforming TabuA.
Finally, to better visualize the improvements each method makes within the 100 s, we shown in
Figure 7 and
Figure 8 the relation between the best solution found and time for 6 exemplary instances. The performance of MILP was recorded for seven different time limits (see (
47)) set within the solver, while for TS algorithms, a timestamp of each improvement was recorded. The plots confirm that TabuB method converges much faster than TabuA, while the MILP formulation still makes improvements when both TS algorithms have almost converged. Moreover, for some large instances (e.g., instance 78, refer to the figure), even 100 s is not enough for a MILP formulation to improve its starting solution, while TS algorithms converge in under 2 s. On the other hand, in several cases all algorithms failed to make any significant improvements. This, however, mostly happened for smaller instances, where the initial solutions are near-optimal.
7. Conclusions and Future Work
In the paper, we considered a single-server permutation Flow Shop manufacturing process. We divided the full problem into two levels and tackled the second level, i.e., finding an optimal order of disjoint setups for a given, fixed order of jobs.
We presented a mathematical model of the considered problem, including a compact solution representation. Then, we formulated several problem properties. We demonstrated an interesting connection between Catalan numbers and the number of feasible solutions for two machines. We also discussed the challenge of generalizing this result for more machines, despite several generalizations of the Catalan numbers existing. With a lack of a closed-form expression, we proposed a Dynamic Programming algorithm for the task, with a time complexity of . Furthermore, we formulated an elimination property that allows to detect and skip suboptimal solutions. For 10 jobs and 6 machines, the property allows one to disregard almost 99.9% of the solution space. This property was then used to develop an efficient refinement procedure, which can be applied to potentially improve any feasible solution in a time as short as a time required to evaluate it.
To solve the problem, we proposed three algorithms: a Mixed-Integer Linear Programming (MILP) formulation and two variants of the Tabu Search (TS) metaheuristic, implementing the identified properties. The solving methods were then tested empirically on instances based on Taillard’s generation scheme. The MILP formulation was the best for smaller instances (up to 50–60 operations), allowing to obtain optimal or near-optimal solutions. For larger, industry-size instances, the TS algorithms outperformed MILP (which was sometimes unable to improve the starting solution at all). Between the two TS variants, the one utilizing elimination property converged faster than the variant that used only the refinement procedure, usually finding good solutions in under 1 s. A good performance together with short running time proved the usefulness of the proposed method as a part of a larger, two-level heuristic for a full problem.
For future work, we consider three research directions. First, we want to tackle the full, two-level problem, optimizing both the order of setups and the order of jobs. Second, we want to generalize the problem shown in this paper, by allowing for a fixed number of setups to be performed at the same time (multi-server). Third, we want to extend our research concerning the connection between the number of feasible setup orders and lattice paths, in order to obtain a closed-form formula for the size of the solution space.