5.1.1. Transition Schemes and Their Implementation
In line with the findings presented in the literature, intensification and diversification shall both be realized in a heuristic search procedure by appropriate moves. When solving general sequencing problems, interchanges and shifts of elements in permutations constitute generic operators which are widely used, cf. [45
]. The interchange-based moves applied here to the BJSPT and their implementation in the permutation-based encodings are defined as follows, see [15
An API move denotes the interchange of two adjacent operations and of different jobs requiring the same machine in the machine-based representation of the schedule. Adjacency is defined in a strict sense. A pair of operations and is called adjacent if there is no idle time on machine between the preceding operation leaving the machine and the start of the processing of the succeeding operation.
A TAPI move denotes an interchange of two adjacent operations and of different jobs requiring the same machine with in the machine-based representation of the schedule, where strict adjacency is given and the job is currently tardy.
The limitation to pairs of operations, which are strictly adjacent in a schedule, can be made without loss of search capability, cf. [15
]. An idle time between two consecutively processed operations of different jobs on a machine may only occur due to
In the first case, there always exists a sequence of applicable API moves that eliminates the idle time and enables an interchange of the considered pair of operations. In the second case, an interchange of the considered pair of operations will only result in postponing the starting time of the initially preceding operation, since the succeeding operation cannot be processed earlier. If such a postponement is beneficial, this will also be indicated by an applicable API at another point in the schedule. Otherwise, postponing the preceding operation can never be advantageous with regard to total tardiness.
These operators are intended to construct close neighboring solutions with a desired distance
. Small steps are supposed to intensify the search and make a heuristic search procedure nicely tractable towards locally optimal schedules. The advantageousness of restricting the set of potential API moves based on the objective function value, namely considering only TAPI moves, shall be closely investigated in the computational experiments. Figure 3
shows all applicable API moves (solid arrows) and TAPI moves (dashed arrows) for a small BJSPT instance with three machines and three jobs. It can be observed that, referring to the same schedule, the set of TAPI moves is a subset of the set of API moves. Note that there is an idle time occurring between three pairs of consecutively processed operations on the machines
, while there is no blocking time on any machine in the given schedule.
To avoid redundancy in the neighborhood structure on the one hand, API moves are applied to the machine-based representation of a schedule. To check the feasibility of the constructed neighboring schedule on the other hand, the applied API move needs to transferred to the operation-based representation of the schedule, cf. [16
]. Since the interchanged operations are not necessarily directly adjacent in the permutation, this can be done by a left shift or a right shift transformation, respectively. First, consider the API move
in the schedule given in Figure 3
and the following permutation encoding this schedule:
The API move can be implemented either by shifting operation
to the right together with its job successor
to preserve the processing sequence or by shifting operation
to the left together with its job predecessor
. In both cases, the following permutation
It appears that the permutations generated by implementing API moves are infeasible with regard to blocking constraints. Here, operation
cannot be scheduled on machine
, since this machine is blocked by operation
. Thus, the given list needs to be repaired. After applying the BRT to
, the following feasible neighboring schedule
, which incidentally turns out as a permutation schedule, is constructed:
Considering the second applicable API move
in the schedule of the
-instance in Figure 3
, the left shift of operation
and the right shift of operation
generate two different permutations
Applying the BRT to
constructs a feasible neighboring schedule
which is displayed in Figure 4
. This schedule features a swap of the jobs
on the machine
and two periods of blocking time on the machines
indicated by the curved lines.
Applying the BRT to
reveals a major difficulty of using permutations, interchange-based operators, and repairing schemes in solution approaches for BJSPs. After the first three operations have been added to the partial permutation
, the operation
is considered. It requires machine
, which is blocked by operation
. Thus, the job successor
must be scheduled prior to operation
, and the BRT reverts the given API to regain the feasibility of the schedule. A graphical representation of the critical step is given in Figure 5
It can easily be seen that the operation sequence given in the first part of the permutation and the operation sequence resulting from the API cannot be implemented together. Additional changes in the schedule are necessary to construct a feasible solution involving the desired ordering . Preliminary experiments have shown that a reversion occurs in 80 to 90% of all generated and repaired neighboring schedules. Therefore, an enhanced repairing scheme is required to find feasible solutions that contain given orderings while featuring as few changes as possible compared to the initially given ones.
The desired operation sequence can be interpreted as a partial schedule with exactly two elements. While the decision problem on the existence of a completion of an arbitrarily large partial schedule is NP-complete for the BJSP, cf. [17
], the generation of a feasible schedule with a given ordering of exactly two operations is always possible. Nonetheless, the challenging task is to find a structured and commonly applicable procedure, which returns a feasible neighbor from an initially given schedule and a desired operation sequence resulting from an API. The subsequent section deals with this issue in detail.
It is indicated by previous studies on BJSPs that a diversification strategy is beneficial to reach promising regions of the search space, see [32
]. Therefore, a randomized and objective function-oriented transition scheme is defined. It is applied to the operation-based representation of a schedule and relies on shifts of operations in the permutation as generic operators, see [15
A TJ move is defined by applying random leftward shifts to all operations of a tardy job in the permutation-based representation of a schedule, while preserving the processing sequence of the job.
The resulting permutation might be infeasible with regard to blocking constraints, and the BRT is used to construct a feasible neighboring schedule. Since a TJ move creates desired partial sequences for every shifted operation, it is not guaranteed that a solution involving all of these orderings simultaneously exists. Thus, no fixation can be applied and the BRT is potentially able to revert all shifts. To avoid neighboring schedules which are equivalent to the initially given ones, sufficiently large shifts are executed.
5.1.2. Generating Feasible API-Based Neighbors
As mentioned in the previous section, the generation of feasible neighboring schedules for BJSPs involving a given API-based ordering is a critical issue. Since potentially required additional changes in the schedule are not contained in the BRT, an Advanced Repair Technique (ART)
is proposed, cf. [15
]. This method takes the operation-based representation of a schedule s
, and a desired sequence of two operations
and returns the operation-based representation
of a neighboring schedule
, which involves the given ordering. All additional APIs necessary to transform the schedule s
follow a basic rule. Instead of reverting a given pairwise sequence
, the initial permutation is adapted by leftward interchanges of an operation of the job
and the repairing scheme is restarted. Figure 6
gives a schematic illustration of the ART in total.
It can be observed in the left part of the chart that the BRT constitutes the foundation of the ART. The operations are iteratively taken from the list , requiring machines are checked for idleness, and blocking operations are determined, if necessary. The first important difference is indicated by the ellipsoid node printed in bold face. An operation is defined to be fixed, if it acts as the successor operation in a given pairwise sequence. The corresponding predecessor is denoted as the associated operation. In the general example stated above, operation is fixed with the associated operation . In case a fixed operation shall be added to the queue and its associated operation is already scheduled in the feasible permutation , no reversion occurs and the procedure continues in the basic version. In case the associated operation is not yet scheduled, the given ordering would be reverted by adding operation to the queue. To avoid this, the ART follows one of four modification paths in the gray box, the initial list is adapted, and the whole procedure is restarted.
illustrates the four possible cases of adaptation by means of Gantt charts. Assume that
is a given ordering and operation
, shown in striped pattern, is the operation currently considered by the ART. Irreversible pairwise sequences are given by bold rightward arrows connecting adjacent operations on a machine, and the required additional APIs are indicated by leftward arrows with case-corresponding line patterns, see Figure 6
. Let the feasible partial schedule
already contain operation
in the cases 1, 2, and 3, and operation
in case 4. The consideration of operation
to be scheduled next requires the following blocking constraint to be fulfilled:
. Since the associated operation
is not yet included in the list
, the fixed operation
cannot be positioned at the next idle list index prior to operation
. To resolve the situation, the basic strategy is to shift or interchange the associated operation
further to the left on its machine, so that it will be scheduled before the required repairing shift of operation
occurs in the next run of the procedure. Therefore, the machine predecessor list of
excluding operations of job
is determined, see Figure 6
, and the adaptation of the initial permutation is conducted according to one the following cases:
If there exists a machine predecessor
, an additional API move is performed and the ordering
is defined to be fixed additionally, see part (a) of Figure 7
. The API is implemented in the list
by a left shift of operation
If there exists no machine predecessor of operation
and there exists no other operation associated with operation
, the currently considered operation
might itself be a job predecessor
of the associated operation
. If this is true, an API move is performed with its machine predecessor
, see part (b) of Figure 7
. Note that, for this situation to occur, the machine predecessor necessarily needs to exist and belong to job
Assume that there exists no machine predecessor of operation
and no other operation associated with operation
, and, furthermore, the currently considered operation is not a job predecessor of operation
. Then, the associated operation is shifted leftward in the permutation
to the position prior to the currently considered operation
, see part (c) of Figure 7
. This shift does not implement an API move but is sufficient to satisfy the given blocking constraint.
This situation differs structurally from the other three cases. It involves at least three machines, and it can only appear with operations of recirculating jobs after one or more additional APIs have already been performed. In part (d) of Figure 7
, besides the initially given ordering, the pairwise sequences
are exemplarily fixed. After the machine predecessor list of the associated operation
has been determined as empty, a second operation associated with the fixed operation
can be found, namely operation
. Dependent on the existence of a machine predecessor
, the ART proceeds according to Cases 1, 2, or 3 with an adaptation of the list
. In the depicted Gantt chart, a shift following Case 1 is shown as an example.
After the permutation is adapted according to one of the four cases, the ART is restarted involving one additionally fixed pairwise sequence. The following observation can be made regarding the operations moved during adaptation.
While executing the ART, the operation interchanged or shifted leftwards when adapting the permutation is always the associated operation defined by the initially given fixed sequence or one of its job predecessors.
Based on this, arguments indicating the correctness of the ART can be derived as follows, cf. [15
The ART terminates and returns a permutation encoding a feasible schedule for the BJSP involving a predefined ordering of two operations of different jobs requiring the same machine.
It is equivalently assumed here that the initially given list is feasible with regard to the processing sequences of all jobs . The ART proceeds like the BRT until there is a fixed operation to be scheduled prior to its associated operation . According to Proposition 1, the BRT terminates and returns a feasible encoding of a BJSP schedule from a given permutation. Consequently, the adaptation of the permutation and the restart of the ART are the only critical aspects to regard here in detail.
It needs to be shown that
an adaptation does not violate the processing sequences of the jobs,
an adaptation can never be reverted,
the number of possible adaptations is finite and
there exists a sequence of adaptations leading to a feasible schedule for the BJSP including the predefined pairwise sequence .
When an adaptation is performed, an operation of job is shifted leftwards in the permutation. The processing sequence of this job is the only one potentially affected and it may only get violated, if the operation is moved prior to one or more of its job predecessors. This situation is checked during the adaptation and job predecessors are additionally shifted, if necessary. Thus, (1) is always true.
The set of irreversible orderings is extended by one pairwise sequence in every execution of the adaptation procedure. Thus, the incorporated BRT mechanisms can never reverse an adaptation. A consecutively required API or shift can only result from a fixed ordering with , where the currently regarded operation features a list index prior to in . This means that a consecutively required adaptation does always appear at a position prior to the previous adaptation causing the fixed sequence . As a consequence, the operation or one of its job predecessors is moved to a list index smaller than , for which holds. Thus, an implemented adaptation can never be reverted by an ART mechanism. (2) is true.
Since the list contains a finite number of elements, and the set of shifted operations is restricted to all operations of a job , see Observation 1, and (2) is true, the number of possible adaptations is finite. (3) holds.
The strategy of the ART can be summarized as shifting the operations of a job iteratively leftwards in the operation sequences on the required machines. This is repeatedly applied until the given pairwise sequence is realized in a feasible schedule for the BJSP constructed by BRT mechanisms only. Following from Observation 1 and statement (2), all moved operations may end up at the first positions in the operation sequences on their machines in the extreme case. Thus, the job involving operation is scheduled prior to all other jobs involved in the problem and is guaranteed. (4) is shown. □
Considering that the total number of operations is given by
and, furthermore, taking this measure as a worst case estimate for the number of operations requiring a certain machine, the ART determines a feasible schedule involving a given pairwise sequence in
steps, cf. [15
]. This method enables the usage of APIs as generic operators in neighborhood structures for BJSPs.