Job Shop Scheduling Problem Optimization by Means of Graph-Based Algorithm

: In this paper we introduce the draft of a new graph-based algorithm for optimization of scheduling problems. Our algorithm is based on the Generalized Lifelong Planning A* algorithm, which is usually used for path planning for mobile robots. It was tested on the Job Shop Scheduling Problem against a genetic algorithm’s classic implementation. The acquired results of these experiments were compared by each algorithm’s required time (to ﬁnd the best solution) as well as makespan. The comparison of these results showed that the proposed algorithm exhibited a promis-ing convergence rate toward an optimal solution. Job shop scheduling (or the job shop problem) is an optimization problem in informatics and operations research in which jobs are assigned to resources at particular times. The makespan is the total length of the schedule (when all jobs have ﬁnished processing). In most of the tested cases, our proposed algorithm managed to ﬁnd a solution faster than the genetic algorithm; in ﬁve cases, the graph-based algorithm found a solution at the same time as the genetic algorithm. Our results also showed that the manner of priority calculation had a non-negligible impact on solutions, and that an appropriately chosen priority calculation could improve them.


Introduction
Nowadays, graph-based algorithms are a popular tool for solving various optimization problems. However, most optimization methods are only used for solving one type of task. On the other hand, methods for optimization of several problems, in most cases, lack sufficient computing power. There are a wide variety of different algorithms available for the optimization of scheduling problems. One of the most well-known is the genetic algorithm (GA).
In this article, we introduce the draft of a graph-based algorithm for scheduling optimization problems. The proposed algorithm aims to have the flexibility and scope of application of advanced optimization methods-such as genetic algorithms-and to retain most of the positive characteristics of advanced graph algorithms.
We researched the literature carefully and paid great attention-though the references contained mainly general literature reviews. Our proposed algorithm appears unique; we could not find any other reference with comparable results for the given problem.
There are many different methods, algorithms and modifications, some of which already contain some of the required properties. Their structure allows for further adaptation. Additionally, some algorithms are directly intended for further development into new algorithms. From various graph-based algorithms, the Forward Version of Generalized

Job Shop Scheduling Problem
The job shop scheduling problem (JSSP) is about allocating limited resources to a variety of tasks for the purpose of obtaining optimal scheduling solutions. These optimized scheduling solutions are important for achieving an efficient and orderly production process [4]. The JSSP is one of the most well-known problems in the fields of production management and combinatorial optimization. The classical n-by-m JSSP can be described as the flow shop problem generalization or the open shop problem specification: scheduling n jobs on m machines with the objective of minimizing the scheduled completion time (makespan) of all jobs. Each of n jobs consists of several operations on m specified machines, which need an uninterrupted processing time of a given length. Operations of the same job can be performed only on one machine at a time and each job must be processed on each machine exactly once [5].
In order to increase production efficiency, reduce cost and/or improve product quality, efficient methods for solving the JSSP are required. Additionally, the JSSP is acknowledged as one of the most challenging NP-hard problems-and no algorithms that can solve the JSSP consistently, even on small scale problems, are known to exist [5].
However, each of these methods comes with their own drawback. Simulated annealing has the tendency to generate poor designs that have a high chance of missing local minima; its convergence is also quite slow. The taboo search uses the serial search method and is low-efficiency. Particle swarm optimization has the tendency to become trapped in local minima. Exact techniques, such as branch and bound (described in [25,26]) and dynamic programming (see [27,28]) can be used to solve only modest-scale problems, because of the complexity of the JSSP [5].
As the genetic algorithm can search efficiently through large search spaces and does not explicitly require additional information about the objective function in order to be optimized, it has been applied to many combinatorial problems, including scheduling [29]. Moreover, its architecture makes it well suited for parallel computation. On the other hand, the GA considers only one new solution at a time [4].

Algorithm Description
The proposed algorithm was developed based on the Generalized Lifelong Planning A*, which is the forward algorithm and framework that generalizes Lifelong Planning A* (LPA*) (described in detail in [30]) and its non-deterministic version of the Minimax LPA* (described in detail in [31]). Additionally, it is designed to allow further development of efficient versions of LPA* and Minimax LPA*, including versions that use inconsistent heuristics or good tiebreaking. That is described in detail in [32].
There are only two differences between LPA* and GLPA* algorithms-and those differences are the reason why GLPA* was chosen over the classical implementation of LPA*. One difference is that GLPA* generalizes the calculation of RHS values and priorities, which enables a considerable amount of adaptability in determination of the optimization criterion and the order in which new states are expanded. Another difference is that the priority queue of GLPA* does not contain all locally inconsistent states-only locally inconsistent states that have not yet been expanded as overconsistent during the current run of the function ComputePlan(). This difference can considerably speed up a search [32].
The first major modification made was the change in data representation. This change was heavily inspired by the genetic algorithm. Although the data representation in GLPA* is very suitable for solving path planning problems, it is less effective for other types of optimization-and for some problems, it is completely useless. For this reason, data of the proposed algorithm is now represented by the usage of bit strings. In most cases, this means that numerical parameters are represented by integers. When solving complex problems, a representation using Gray code can be used, which causes even greater changes in data of possible solutions when expanding new states and further reduces the possibility of converging on local extremes. Real numbers usage is not recommended, because it tends to cause problems for the expansion of new states [3].
The second significant change we made stems from the first; since the algorithm uses a different data representation, the values of newly acquired states may no longer depend on the values of their predecessors. Furthermore, the calculation of the RHS value may now vary depending on the problem-meaning the old way of calculation is not always possible. Therefore, a new function-StateEvaluation() [2]-was introduced, which calculated the RHS value of the given problem. This is basically an objective function used to determine how close the obtained solution is in order to achieve the goals of optimization. In order to prevent the algorithm from converging on an unsuitable solution or even not converging at all, the function must be appropriately chosen and must correlate with the goals of optimization. Additionally, this function must be rapidly calculated, because the calculation must be repeated many times in order to generate useful results for nontrivial problems. Therefore, the speed of calculation is very important [3]. The priority K(u) of the state u in the priority queue is a two-element vector: K(u) = [K1(u); K2(u)]. For basic application, K1(u) = rhs(u) and K2(u) = g(u) can be used. However, for better performance, more appropriate priority calculations can be chosen.
The method of calculating priorities K(u)-especially in the context of makespan-has a significant impact on the result. Making the appropriate choice in priority calculation will improve the result, and choosing inappropriately will impair the result. This further improved the performance of our algorithm.
Pseudo-code excerpts from our proposed algorithm are shown in Algorithms 1. The first difference is that the optimization of logistic problems may have more than one initial state, which is represented in {04-05}. Additionally, this type of optimization problem does not usually have a defined target state, represented by the while loop removal in ComputePlan(). Main() now continuously calls ComputePlan(), and therefore the algorithm tries continuously to improve the solution. However, we can easily add a new termination condition by replacing the forever loop in Main() by a while/until loop that terminates the optimization algorithm when a predetermined amount of time has elapsed, or after a certain number of repetitions of the procedure [2]. Also, the new state of the parameter ssol was introduced, see line {02} which represents the best-found state {13} and contains the current solution of the given optimization problem.

Algorithms 1:
The pseudo-codes use the following functions to manage the priority queue: U.Insert(s, k) inserts state s into priority queue U with priority k. U.Remove(s) removes state s from priority queue U. U.Update(s, k) sets the priority of state s in the priority queue to k. U.Remove(s) removes state s from priority queue U. U.Pop() deletes the state with the smallest priority in priority queue U and returns the state. Insert(s, k) inserts state s into priority queue U with priority k. The predicate NotYet(s) is shorthand for "state s has not been expanded yet as overconsistent during the current call to ComputePlan()." Finally StateEvaluation() returns the value of optimized logistic problem. {10} else if (u / ∈ U and g(u) = rhs(u) and NotYet(u)) U.Insert(u,K(u)); for all s ∈ Succ(u) ∪ {u} UpdateState(s);

Computational Result
The algorithms were implemented in C# language on a personal computer with Intel Core P7550.
For these experiments, a variation of operation-based representation was chosen, wherein all operations for a job are named by the same symbol in the sequence and interpreted according to the order of occurrence in the given sequence. Therefore, each job appears in the sequence exactly m times and each repetition refers to a unique operation, which is dependent on the context and does not indicate a predetermined operation of the job. This way, any permutation of elements in a sequence always yields a feasible schedule [33].
Although the values of newly acquired states may no longer depend on their predecessors, the position of symbols in the sequence of the newly acquired states does. As for this problem, we changed the symbols position in the sequence only if it was not changed in one of their predecessors.
Experiments performed by means of the graph-based algorithm used three different methods of calculation of priority K(u). The results of experiments marked α were obtained by using the basic calculation of priority K(u): K1(u) = rhs(u) and K2(u) = g(u). For β, priority K(u) consisted of K1(u) = h(u) and K2(u) = rhs(u). Results for experiments marked γ used K1(u) = h(u) and K2(u) = −rhs(u), where rhs(u) represents the makespan and h(u) is the sum of completion times of all machines, calculated by the function StateEvaluation() as a byproduct.
Experiments solved by the genetic algorithm were performed using roulette wheel selection, one-point crossover with the corresponding repair process and reciprocal exchange mutation. All tests used the same crossover rate (0.8) and population size (100). The mutation used was relatively low (1/n), where n represents the number of genomes in a chromosome. These parameters were chosen because they showed the best results for this problem type.
Instances of problems for the job shop scheduling problem were commonly used as benchmarking instances [34] and were taken from the database of scheduling problems, OR-Library [35]. One hundred tests on each instance were performed for each algorithm. For a better variation of results, starting states of the graph algorithm were randomly generated.
These experiments were compared by several factors: the time taken to find the best solution, makespan, the average value of makespans found and the average time taken to find these makespans. The results of these tests are summarized in Table 1, which also lists number of jobs, number of machines, instances [36], the best-known solution and the overall time of optimization for the given problem.
We did not test the problem of limiting the proposed algorithm with respect to the number of jobs or machines. Limiting the algorithm by comparison through the most well-known makespans was sufficient enough for the given application area. An example of Gantt graphs for the instance la09 can be found in Figures 1 and 2. Thank you for your changes. The purpose of the performed experiments was not necessarily to reach the bestknown makespan, but rather to show what makespan could be found by our proposed algorithm in an allocated time; to how fast it performed and compare it to results reached under the same conditions by an unmodified GA. For this reason, we let each of the tested algorithms run for a certain amount of time-unless the best-known makespan was found.
The results of comparative experiments showed that our proposed graph-based algorithm was able to find the same or better solutions compared to the genetic algorithmand managed to find them faster. The graph-based algorithm also managed to find the same average makespan as the GA on eight benchmarking instances, and a better average makespan on eighteen instances. However, detailed examination of the experimental re- Thank you for your changes. The purpose of the performed experiments was not necessarily to reach the bestknown makespan, but rather to show what makespan could be found by our proposed algorithm in an allocated time; to how fast it performed and compare it to results reached under the same conditions by an unmodified GA. For this reason, we let each of the tested algorithms run for a certain amount of time-unless the best-known makespan was found.
The results of comparative experiments showed that our proposed graph-based algorithm was able to find the same or better solutions compared to the genetic algorithmand managed to find them faster. The graph-based algorithm also managed to find the same average makespan as the GA on eight benchmarking instances, and a better average makespan on eighteen instances. However, detailed examination of the experimental results showed that with an increase in the number of parameters and iterations, the time The purpose of the performed experiments was not necessarily to reach the bestknown makespan, but rather to show what makespan could be found by our proposed algorithm in an allocated time; to how fast it performed and compare it to results reached under the same conditions by an unmodified GA. For this reason, we let each of the tested algorithms run for a certain amount of time-unless the best-known makespan was found.
The results of comparative experiments showed that our proposed graph-based algorithm was able to find the same or better solutions compared to the genetic algorithmand managed to find them faster. The graph-based algorithm also managed to find the same average makespan as the GA on eight benchmarking instances, and a better average makespan on eighteen instances. However, detailed examination of the experimental results showed that with an increase in the number of parameters and iterations, the time required for the execution of each iteration will gradually start to rise; under those conditions, the proposed algorithm will perform its iterations slower than the tested genetic algorithm. Table 1 shows that some of the operations sequences are not similar in order, but are very similar in calculation time. At times, the time to find the best makespan was the same as the time to test various best-known makespans ( Table 1, fourth column). We did not discuss this fact in detail, but we do not expect a significant reason.
Despite this fact, the tested graph-based algorithm converged on the optimal solution quickly and obtained better results than the tested genetic algorithm, proving that the behavior shown on several travelling salesman problems in [2,3] can apply to different types of scheduling problems as well.

Conclusions
In this article, we proposed a graph-based algorithm that can be used for schedulingrelated optimization problems. It was based on the Generalized Framework for Lifelong Planning A*. This algorithm was then tested against the classic genetic algorithm on forty benchmarking instances for the job shop scheduling problem.
The experimental results on the JSSP showed that our proposed algorithm reached the best known makespan in thirteen instances while the genetic algorithm did so only in twelve. The graph-based algorithm found a better solution than the genetic algorithm on twenty-two tested benchmarking instances, found a solution with at least the same makespan as the GA on another twelve instances, and ended in optimality in eleven of these instances. The best-known makespan's average deviation from the best makespan acquired by the graph-based algorithm was 4.7% for α, 5.05% for β and 5.08% for γ; the genetic algorithm had an average deviation of 5.19%, and on all but fourteen instances, the proposed algorithm managed to find the solution faster (on average, about 200-300% faster) than the genetic algorithm. Additionally, on all remaining instances, the graph-based algorithm managed to find a solution in the same time frame as the GA.
The average makespan's average deviation from the best-known makespan was 9.63% for the genetic algorithm, while the graph-based algorithm's variations had an average deviation of 9.22% for α, 10.39% for β and 10.48% for γ. Additionally, on all but six benchmarking instances, the proposed algorithm managed to find a solution faster (on average, about 100%-200% faster) than the genetic algorithm; on five of these instances, the graph-based algorithm managed to find a solution in the same time frame as the GA.
Therefore, we can state that our proposed algorithm generally gives the same or better results-in comparison with the genetic algorithm's basic implementation-on the job shop scheduling problem. The practical consequences of the identified improvements (in makespan and calculation speed) are economic; these improvements will bring a price reduction.
The manner of priority calculation has a nonnegligible impact on solutions. An appropriately chosen priority calculation can improve results, and an inappropriately chosen priority calculation can worsen them. Therefore, the proposed algorithm's performance can be further improved by proposing new methods of priority calculation.