1. Introduction
Industry 4.0 has significantly reshaped manufacturing system paradigms, emphasizing the move toward the complete automation of the production process [
1,
2]. In this transformative context, where the goal is to fully exploit the capabilities of machines, the precise planning of all production
tasks becomes imperative, aiming to minimize machine idle time. Consequently, the scheduling problem has been the subject of extensive study in recent decades [
3,
4,
5]. In its simplest form, this scheduling challenge is commonly referred to as the job shop scheduling (JSS) problem [
6]. Given a set of
machines and a set of
jobs, where each job comprises a set of
tasks to be processed in a specific order by different machines, the objective is to find a task assignment that minimizes an objective function, such as the total completion time or
makespan.
The above problem formulation assumes that the time is divided into slots (e.g., each day is a time slot): the job requests are collected during a time slot and scheduled for the next one. By relaxing this assumption, we can insert the jobs as they arrive into the schedule. This scenario is usually referred to as
dynamic JSS (DJSS). With the evolution of manufacturing technology, in which a single machine may perform multiple task types, we can further extend JSS to include this flexibility; in such a case, we have the flexible DJSS problem (FDJSS or simply FJSS). The FJSS problem has been particularly interesting in recent years in the context of
Industry 4.0 [
7], in which the production lines include advanced features that allow the machines to communicate and be reorganized and reconfigured to meet the increasingly challenging production constraints.
A crucial aspect that is not fully explored in the existing literature is the automation of job transfers between machines. While task execution on machines can be characterized by processing times, the transfer process involves various settings, including (i) the means of transportation, such as automatic guided vehicles (AGVs) or conveyor belts, and (ii) input and output buffers at the machines, determining their ability to store jobs for processing (e.g., while finishing another task). The store processed jobs (while awaiting the availability of the transport system) (Our definition of transfer pertains to the time between the end of one task and the start of the next for a given job).
Certain combinations of transport systems and buffers may be modeled using constant time [
8], as is the case when the transport facility is always available, and the machines have sufficiently large input and output buffers. In such scenarios, incorporating transfer time into the processing time is straightforward, and numerous solutions proposed in the literature [
4] can be applied. In other cases, transfer time depends on the availability of the transport system and the destination machine [
1,
9,
10]. Overall, no single model can cover all alternatives, necessitating ad-hoc modeling for specific combinations.
In this study, we consider a scenario inspired by a
fully automated production line, incorporating a conveyor belt as a means of transportation and no buffer at the machines. In this setup, once a task is completed, the job is immediately placed on the belt to free the machine. If the next machine is occupied, the job remains on the belt until the destination machine becomes available. The JSS problem is well-known to be NP-hard [
11], and the variant considered here is at least as challenging [
12]. In order to address this complexity, we propose a heuristic named
Sched-T, which falls under the
stochastic local search (SLS) approach [
13]. SLS encompasses well-known algorithms such as simulated annealing and tabu search.
A primary challenge is evaluating potential moves when exploring the solution space. A slight change in the scheduling sequence has a cascading effect on the remaining tasks, as the sequence depends on transfer times, which, in turn, depend on the execution sequence. While existing solutions rely on an approximate evaluation of each move (e.g., the computation of the critical path), we adopted a randomized approach, accurately assessing a few random neighbors. Given
Sched-T’s ability to quickly compute complex schedules, especially in the case of dynamic job arrivals, we employed the “total rescheduling” strategy [
14]. This strategy considers newly arrived jobs alongside those not yet scheduled, resulting in a new schedule that integrates with the current one. This approach is versatile, accommodating events beyond job arrivals, such as scheduled machine maintenance [
15].
Here, we evaluate
Sched-T on a set of instances publicly available without transfer times [
16]. In such cases, our heuristic achieves results comparable to those of the previously proposed versions. Subsequently, we analyze instances generated from a production line where the transfer times are available. Although the problem can be modeled using mixed linear integer programming (MILP) approaches, standard MILP solvers fail to find a solution in a reasonable time. Consequently,
Sched-T emerges as the only viable approach. Our results demonstrate that when applying the schedule found by
Sched-T to a real-world production line, the predicted makespan closely aligns with the actual outcome. Conversely, using a schedule derived without considering the transport system, as seen in the literature, results in a makespan that is up to 30% larger than that achieved using
Sched-T’s schedule.
In our approach, we consider dynamic arrivals and compare the total rescheduling strategy using clairvoyant scheduling, i.e., a scheduling type wherby future job arrivals are known in advance, and show that the total rescheduling strategy produces close-to-optimal scheduling.
This article builds upon the findings presented in [
17] in several ways. Specifically, we delve into the scenario of dynamic arrivals, where the schedule must be recalculated, which is in contrast to the static case examined in [
17], where all jobs were available at the onset of the scheduling period. This necessitated a redesign of the scheduler to manage partially processed, waiting, and newly arrived jobs. Consequently, this updated definition encompasses the static case as a special instance, thus representing a generalization of the problem. Furthermore, we present a clear system model and problem formulation, along with an expanded comparison of our heuristics. This comparison includes additional instances, additional performance metrics, such as the running time of our scheduler, and diverse layouts for real-world experiments.
In summary, the contributions of our work are the following. We provide a heuristic for the JSS problem that takes into account the transport system based on a conveyor belt and no buffers at the stations. We consider a dynamic scenario where jobs continuously arrive while we managed the partially processed jobs and the newly arrived jobs, making for a total rescheduling strategy. We tested our solution in a real-world production line to show that if transport times are not considered, the scheduler produces results that may contain large errors.
In summary, the contributions of our work are as follows:
We propose a heuristic for the Job Shop Scheduling (JSS) problem that incorporates a transport system based on a conveyor belt and no buffers at the stations.
We address a dynamic scenario where jobs continuously arrive while we effectively manage partially processed jobs and newly arrived jobs by adopting a total rescheduling strategy.
We validated our solution through experimentation on a real-world production line, demonstrating that neglecting transport times can lead to substantial errors in the scheduler’s results.
The paper is structured as follows. In
Section 2, we present the case study that serves as the motivation for our work. Specifically, we examine a production line where machines are interconnected through a conveyor belt. We then delve into the existing body of related work and highlight their limitations.
Section 3 is dedicated to formalizing the problem, introducing a model that defines the key variables. This formalization enables us to cast the problem as a minimization challenge. Given the impracticality of finding an exact solution within a reasonable timeframe,
Section 4 outlines our proposed heuristic,
Sched-T. This heuristic belongs to the class of
randomized iterated improvement algorithms tailored to address the nuances of the specific problem. In
Section 5, we conduct a comparative analysis of the solutions obtained with
Sched-T against those generated by state-of-the-art heuristics. We explore scenarios involving the transport system that were previously unsolvable with tools available in the literature. Finally,
Section 6 encapsulates the key findings and draws conclusions from our study.
2. Background and Related Work
Production line with a conveyor belt: The manufacturing system, taken as a reference, consists of a set of machines dedicated to specific tasks disposed in a general
layout. Each machine is connected with the others through a transport system that moves the materials between the machines circularly. Both raw and finished materials are stored in a vertical warehouse. The production line available at our research facility,
the ICE Laboratory [
18], follows the same layout.
Figure 1 shows the plant configuration. It is composed of a set of “production cells”, specifically tailored to a specific manufacturing process. Starting from the right, the laboratory includes a multi-tool milling machine, a robotic assembly station, a quality control cell, and a vertical warehouse. The conveyor belt moves materials on top of 10 pallets across various
belt segments. Each pallet is identified by an RFID tag, which is detected by RFID sensors located near the switching mechanisms (blue squares in
Figure 1). In particular, the belt segments can be differentiated into the following:
The four machine segments: These are in charge of loading and unloading materials from the machines (i.e., moving pallets toward and away from the processing area). Since these segments are the only access route to the machines, they can contain only one pallet at a certain time instance;
The main belt segments: These are in charge of moving a pallet near the machine when it is ready to process a new task. The pallets waiting for a machine to become free must loop near the destination machine, implementing a circular buffer, while free pallets loop along the long main segments. The main belt is composed of two long belts running in opposite directions. Along these main segments, it is possible to traverse from one to the other by exploiting the switching mechanisms placed in certain positions.
The two types of belt segments differ in terms of their control policy. Machine segments are activated in the desired direction to perform loading or unloading pallet operations, and the main belt segments are always active, pushing in the same direction. A switching mechanism can move a pallet by choosing one of the following directions: (1) forward, following the direction of the actual belt; (2) backward, changing direction by switching onto the opposite conveyor; and (3) towards a machine working area. If two pallets must move in the same direction at the same time, the pallet exiting from an unloading segment or moving forward along the main belt has precedence.
Literature review: In the last decades, the JSS problem has been extensively analyzed by the research community, along with the different variants, such as DJSS and FJSS. The solutions that have been proposed over the years are summarized in [
4,
5] and [
19]. Our work differs from the standard problem because it specifically addresses the transport time between machines and the impact of this on the schedule. Therefore, we concentrated our analysis of the related works on this specific topic.
The transfer time between two machines is a variable delay that depends on the distance between the two machines and the availability of the destination machine. A solution proposed in [
20] handles variable delays as sequence-dependent setup times. However, this solution considers the machines busy during the setup time, whereas, in our case, the destination machine can process other tasks while the materials of the next task are moving toward the machine.
The authors in [
10,
21,
22,
23] proposed a solution for the problem of job scheduling combined with transport time, but they consider only automated guided vehicles (AGVs) as a means of transportation. The limit of considering AGVs is that until a vehicle picks up a task from a machine, the machine itself cannot execute other activities. Similarly, when an AGV is waiting to perform a pick operation from a machine, it wastes transport resources. Moreover, if the machine is completing the previous task when the AGV reaches the destination, it must wait until the machine completes the task, freeing its working area. This is not a valid scenario in our case study, in which the machine immediately unloads the task to the conveyor belt once the task is completed. Another difference is that the jobs waiting to be processed by a machine do not impact on the unloading and loading capabilities of the tasks of other machines.
The aim of the different heuristics proposed in the literature is to find the best schedule that optimizes an objective function [
12,
20,
24]. These state-of-the-art solutions are based on graph-based representations of the execution sequence. By evaluating the graph properties, such as dependencies and the critical path, it is possible to infer the feasibility of a solution by also approximating the objective function. In our case, these approaches cannot be applied due to the inter-dependency between transfer time and the execution sequence. There are also solutions, such as [
16], based on MILP optimization models, which minimize the objective function. A major drawback of these approaches consists of the execution time. In fact, by modeling the constraints of our transport system, solving even small instances cannot be carried out in a reasonable amount of time.
In summary, none of the existing works take into account the influence of a transport system on comprehensive scheduling when machines lack input and output buffers. In this specific setup, the sequence of jobs affects the transport times, and conversely, the transport times impact the job sequence. This intricate circular dependency necessitates specialized tools that are currently absent in the literature.
4. Exploring the Solution Space
4.1. Overview
The general framework for any heuristic based on stochastic local search comprises the following steps [
13]:
Construct a solution and compute the objective function;
Explore the neighborhood, assessing the objective function for each neighbor;
Choose the neighbor based on a specified criterion;
Repeat all steps starting from step 2 until a stop condition is satisfied.
In addition, given a solution, we must define (i) how we can explore its neighborhood (i.e., new solutions); (ii) how the objective function is computed (i.e., what are the parameters that we want to optimize); (iii) the policy used to choose the next solution; and (iv) when the exploration should terminate (i.e., stop conditions). The computational complexity of these approaches depends on the neighborhood size. For instance, given a task sequence () containing n elements, we may define (as a neighbor) any sequence () that differs from for the position of two tasks (the minimum possible change). This would imply that the number of elements in the neighborhood is at least equal to .
Given the high number of neighbors used to explore each solution, a common procedure consists of limiting the exploration to the subset of the most significant neighbors. This set is composed of all the neighbors except those that are less likely to improve the current solution, e.g., all the neighbors that swap two tasks belonging to the same job since they have dependencies that limit the time interval in which they can be allocated.
The cost function must be computed for each explored neighbor. Therefore, its complexity heavily impacts the execution time. A cost function should be a trade-off between precision and complexity, exploring a wide range of neighbors in a certain time slot and choosing the most promising one. In our case, the complexity of the cost function is given by two main factors. The first one consists of the inner dependencies between tasks of the same job. This implies that small changes in one task can cause cascading effects on the subsequent portion of the schedule. The second factor is related to the transfer time between two machines. This transfer time is strictly dependent on both the availability of the destination machine (see Equation (
1)) and the task execution order. While the first problem can be addressed by exploiting graph-based representations, the circular dependency between execution order and transport time makes it difficult to precisely or approximately compute the objective function.
As such, we are forced to compute the objective function for each neighbor explored from scratch, making the selection of the most promising neighbors to explore a critical step.
4.2. Randomized Approach
Given a set of jobs to schedule, the number of possible solutions increases exponentially as the number of jobs increases. Therefore, an entire exploration of the solution state space could require hours or could be unfeasible in a reasonable amount of time. For this reason, the exploration is always guided by heuristics that reduce the number of evaluated solutions. An idea inspired by the results proposed in [
25,
26,
27] is to explore a set of neighbors chosen randomly. This is indeed a variant of the stochastic local search approach called
probabilistic random improvement.
A random neighbor (i.e., solution) is described by the sequence of jobs. For each neighbor, we compute the allocation of tasks on the machines and evaluate the objective function. Given a solution, we consider its set of randomly selected neighbors. Then, we choose the best neighbor that improves the current solution. This process is repeated to increase the exploration’s precision. Thus, we can also tune the precision of the exploration by increasing or decreasing the total number of random neighbors to explore.
During the exploration, we must avoid being stuck in a local minimum. We can do that by adopting known techniques used in tabu search or simulated annealing, in which a new solution is accepted with a certain probability and without considering the optimality degree of the solution. Instead, we adopt another methodology based on sampling, which is inspired by the fisheye view [
28] and fisheye routing [
29]. These techniques sample solutions at different distances to check if there are other
valleys that exist to explore. In our context, a distant neighbor is obtained with more complex changes in the task execution order. In addition, for each remote neighbor, we perform a limited local exploration to test if such a remote neighbor could indeed improve the current solution.
Figure 2 shows an example of the exploration process.
4.3. Detailed Solution
Our scheme for the exploration of the neighborhood uses a two-level hierarchical approach. At a higher level, we have jobs, while at the lower level, we have tasks.
Initialization: In the case of a cold start, in which the system is completely unloaded, and a set of jobs has been collected and are ready to be executed (e.g., during the night, the production line does not work and arriving orders are collected), we initialize the order of the jobs according to the
longest processing first policy since it has been shown to improve the makespan compared other policies [
30]. We define the processing time of a job as the sum of the processing time of its tasks. If a task (
) can be processed by more than one machine, then we consider the minimum (
) (see Algorithm 1, procedure
InitTaskOrder, and parameter
BySize set to
True). In the case of a running system, the order is given by the output of the previous schedule (considering only the jobs not yet launched), with the newly arrived job placed at the end.
We then establish the order of tasks within each job by grouping tasks with the same precedence and randomly arranging the tasks within each group. The final output is an ordered sequence of tasks, denoted as . The makespan value is computed based on this sequence (refer to Algorithm 1 and procedure EvalSolution). We allocate each task to a machine, considering machine availability and dependencies for previous tasks. If multiple machines can perform a task, we choose the machine where the task terminates earlier, including the transportation time.
Neighborhood: For a given sequence () of tasks, we define a close neighbor as the feasible solution where we work at a low level. In other words, we switch tasks to obtain a new sequence () for evaluation. A random neighbor is obtained by (i) uniformly selecting a task ( in ) and (ii) uniformly selecting another task (). The latter must belong to the same job () or to a job that comes before or after job i in the ordered set J. If the tasks belong to the same job, our choice is limited to tasks with no dependencies on task (such a subset can be pre-computed upon job arrival).
We define a
remote neighbor as a new solution in which jobs are swapped in the ordered set
J (i.e., higher-level permutations). Thus, remote neighbors allow for the exploration of new solution areas, and close neighbors can be used to fine-tune the current solution.
Algorithm 1: Initialization and Evaluation |
|
Exploration: The number of close and remote neighbors (solutions) explored during an iteration is governed by the budget, B. At each iteration, we update the current solution with a new one if it improves the current one (see Algorithm 2). The exploration starts by considering the current solution and as close neighbors, chosen uniformly at random among the feasible close neighbors (lines 6–12). The parameter is given as input, with . The exploration continues by evaluating R remote neighbors (lines 13–14), selected uniformly at random. For each of them, it explores its neighbors locally uniformly at random with a budget (lines 15–21).
The exploration stops when one of the following conditions is reached: (i) the maximum number of iterations ; (ii) no improvements are found for iterations (not shown in Algorithm 2).
Figure 3 shows a high-level view of the processing flow.
Algorithm 2: Sched-T |
|
Complexity: When evaluating a single solution, since we build it from scratch, we run through the ordered list of tasks and assign the task to the available machine. Each task may be executed in more than one machine, but we assume that the number of alternative machines is bounded. The complexity of each evaluation, therefore, is
, with
total number of tasks considering all the jobs to be scheduled. We perform
iterations, and we evaluate
B possible solutions; therefore, the complexity of
Sched-T is
. In
Section 5, we show the running time for different instances.
4.4. Discussion
When considering dynamic job arrivals, there are different approaches for integrating the new job into the existing scheduling. For instance, one can exploit the gaps in the current schedule and run the newly arrived job during such gaps, with little or no impact on the other jobs. When we take into account the transport system, it is not easy to understand if the gaps can be fully exploited. In fact, even a small change in the current scheduling, such as shifting a task to accommodate the new one, results in a cascading effect that disrupts the whole scheduling.
Such interdependence between the job execution and the transport system is the reason behind our randomized approach to the exploration of the solution space. Every time we evaluate a possible solution, we need to compute the schedule from scratch. The solutions in the literature that adapt the current schedule to accommodate the new arrivals can not be easily extended when we consider the transport system, and the only available option is to recompute the whole schedule.
The use of a heuristic allows us to trade accuracy with speed, i.e., we accept sub-optimal solutions (with an error of less than 5%) that are obtained in a few seconds; in
Section 5, we show the running time for different instance sizes. Compared to the job processing time (e.g., tens of minutes), the scheduling processing time is very small, and therefore, the approach based on total rescheduling is justified. In case of high job arrival rates, rather than recomputing the scheduling at every arrival, it is possible to collect some new jobs before running
Sched-T. As a rule of thumb, if the scheduling processing time is
seconds, and the average arrival rate (estimated considering the last arrivals) is
jobs/s, then the new scheduling can be computed once
jobs have arrived, with the parameter
that controls the trade-off between the delay and processing load.
Alternatively, at every job arrival, it is possible to consider only a subset of jobs waiting to be processed (e.g., the last W jobs in line) as part of the set of jobs that are included in the new schedule computation so that the other subset can be used to feed the production line during the computation.
5. Experimental Results
In this section, we demonstrate the validity of our proposed heuristic Sched-T. First, we compare our heuristic with state-of-the-art approaches for solving the FJSS problem, using public benchmarks without the transport system. Then, we apply our heuristic to both a real-world scenario and a simulated scenario to evaluate its performance when the transport system is present.
5.1. Experimental Methodology and Settings
In order to compare
Sched-T with other heuristics, we consider the set of publicly available instances described in [
12,
16]. These instances have been created using the instance generator available at [
31]. The generated instances contain information regarding the jobs, assuming that transportation is part of the task-processing time. We use these instances to evaluate the performance of our proposed scheduling heuristic with respect to the state-of-the-art. In all the comparisons, we use a cost function based on the
makespan, i.e., the latest completion time of the entire set of scheduled tasks. The built-in parameters that guide our heuristics are (i) the number of iterations and (ii) the available budget at each iteration, divided between the budget dedicated to the exploration of local and remote neighbors. We analyzed the impact of these parameters on the makespan with a sensitivity analysis.
As for the transport system, unfortunately, public instances that include this aspect, such as the one used in [
32], consider different means of transport (AGVs rather than conveyor belts). Therefore, they cannot be used in our comparison. Therefore, we consider a real-world use case related to our ICE lab, in which we were able to create a set of instances that include a transport system.
Finally, we consider the case of a sequence of arrivals. We assume, as is carried out in the literature [
14], that a set of jobs is present at time zero and that another set randomly arrives. We evaluate the makespan in such a dynamic case (updated at every arrival), and we compare it with the makespan computed by an ideal clairvoyant scheduler, i.e., a scheduler that knows all the future arriving jobs and provides a single, optimized schedule.
Sched-T is implemented in Python, and the experiments are carried out on a 3.3 GHz Intel Core i7 (Intel, Santa Clara, CA, USA) with 16 Gb of RAM (Microchip Technology Inc., Chandler, AZ, USA).
5.2. Instances with No Transport System
We compared
Sched-T with a set of heuristics that were presented in [
12], in which authors applied iterated local search, genetic algorithms, differential evolution, and tabu search on a set of 50
large instances defined in the same paper, along with another set of 50
large instances proposed by the same authors in [
16]. Each instance differs in the number of available machines (up to 97) on which tasks can be allocated, the number of jobs (up to 200), and the number of total tasks (up to 2000). None of these heuristics outperformed the others in all the instances: for some instances, differential evolution was better than the others, and for other heuristics, tabu search provides the best makespan. Rather than listing the values of each heuristic, we consider, for each instance, the best and the worst makespan obtained by these heuristics: we used such values to represent an interval for which the gap is much more narrow than the one found with the CP approach. Within this range lie the results of the four heuristics cited before (iterated local search, genetic algorithm, differential evolution, and tabu search). Therefore, we consider such a gap as a reference with which to compare. Instead of showing the absolute values for each instance, we can normalize the maximum makespan with respect to the minimum makespan so that the gaps of the different instances are comparable and can be put in a single graph. We also normalize the makespan obtained by
Sched-T so that it is simple to understand if it falls in the gap provided by other heuristics.
Makespan: In
Figure 4, we compare the makespan obtained on the set of instances by
Sched-T with the one obtained with the other reference heuristics. The results show that
Sched-T is able to find a makespan within the gap defined by the other state-of-the-art heuristics. In some cases, it outperforms the other heuristics by 2%, whereas in two cases, it finds a larger makespan by 3%. We notice that every heuristic proposed in the literature, including our solution, provides an approximate solution, and there are no guarantees on the error bound. Therefore, we can only observe how well these heuristics perform on real datasets.
Figure 4 shows that the approximate solutions have a 4–12% gap; therefore, such an error can be considered acceptable. From these results,
Sched-T performs similarly to other state-of-the-art heuristics on instances without considering the transport time.
Running time:
Figure 5 shows the running time (in minutes) required to find the solutions of the 50 instances in [
16]. The instances are ordered by increasing the number of tasks (shown at the top of the graph), e.g., instance 50 has almost 1000 tasks. Even with a large number of tasks,
Sched-T is able to obtain a solution that is comparable to the results found in the literature in less than 10 min.
Sensitivity analysis: Sched-T has a set of parameters that tune the depth of the exploration phase. At the task level, we can exchange tasks belonging to the same job or to the next or previous job by considering the current scheduling order. At the job level, we can exchange jobs. During our tests, we noted that switching jobs provides most of the gain, while at the task level, the impact of changing the order on the makespan is less significant.
Therefore, the two main parameters we consider are the number of moves we explore
and the number of neighbors we evaluate in each iteration,
R. These parameters influence the time required to compute the solution.
Figure 6 shows two views for analyzing the impact of these parameters on the normalized makespan, i.e., the makespan found with a combination of
and
R divided by the makespan found with the highest values of
and
R used in our test. If we maintain
as fixed and we increase
R (
Figure 6, left), when
R is sufficiently large (
), no additional improvement is observed. However, even for smaller values of
R, the makespan only slightly increases (2–5%) with respect to the best makespan found. This is also confirmed if we keep
R fixed and vary
(
Figure 6, right); the two figures refer to two different instances, and they are representative of the general behavior that we observed for all the instances.
Therefore, the two main parameters we consider are the number of moves we explore, denoted as
, and the number of neighbors we evaluate in each iteration, denoted as
R. These parameters influence the time required to compute the solution.
Figure 6 provides two views for analyzing the impact of these parameters on the normalized makespan. In other words, it shows the makespan found with a combination of
and
R divided by the makespan found with the highest values of
and
R used in our test. If we keep
fixed and increase
R (
Figure 6, left), when
R is sufficiently large (
), no additional improvement is observed. Even for smaller values of
R, the makespan only slightly increases (2–5%) compared to the best makespan found. This observation holds even if we keep
R fixed and vary
(
Figure 6, right). The two figures represent different instances but are indicative of the general behavior observed for all instances.
Overall, Sched-T is not extremely sensitive to parameter settings and provides good results across a wide range of values. In terms of computational time, using small and R allows for obtaining a solution in less than 30 s, while larger and R may take up to 10 min. However, since large and R do not significantly improve the results, the use of a small and R is appropriate, especially in dynamic contexts where scheduling is recomputed when new jobs arrive.
In any case, the tuning process can be performed in a simulated environment where data collected from the production line is replayed, and different values of and R are tested. If the production load does not vary much from one day to the next, this offline analysis should provide an indication of the best parameter settings for that specific production line.
ICE instances: In order to test
Sched-T in a real test case, we generated six instances that can be executed within our research laboratory (described in
Section 2). The number of tasks and jobs for each instance are summarized in
Table 2. Without considering the transport time, we were able to solve the problem using a MILP model and compare the results with
Sched-T (
Table 2, column
Opt).
By using
Sched-T, we are able to find a solution in less than 30 s. The difference between the local optimal and the global optimal solution is less than 5% (columns
Sched-T and
Err. of
Table 2). As mentioned earlier, the literature deems an error gap of up to 10% acceptable, acknowledging the trade-off between accuracy and computational speed provided by the approximate solutions. Regarding the variability in error, we were unable to pinpoint any specific job characteristic that might influence such variability. It can be regarded as an inherent variability intrinsic to the considered problem.
5.3. Instances with the Transport System
Introducing a transport system increases the complexity of the MILP model exponentially. In fact, a MILP formulation given to standard MILP solvers, such as IBM CPLEX, cannot be solved after hours of computation. As such, we do not have any values that can be used as a global optimal comparison reference to our results. The results presented in
Table 3, column
Sched-T of
Experim.-I, report the makespan found by
Sched-T. Next, we describe the test we performed on a real-world testbed to validate such results.
5.4. Real-World Experiments
We consider the set of instances described in
Table 2, and we run them on an actual production line built in our lab (described in
Section 2). The production line is governed by service-oriented manufacturing (SOM) software architecture similar to the one presented in [
33,
34], which automatically manages the production line, interacting with both the manufacturing execution system (MES) and the machines. On top, we have developed a module that implements our proposed scheduling heuristic, and the execution is forwarded to the SOM architecture. For each instance’s job, we have fixed the task execution time. This allows for a fair evaluation of the accuracy of
Sched-T, removing processing time variability. The case of a stochastic execution time will be considered in future works.
Given the schedule returned by
Sched-T, we ran the jobs on the production line and recorded the makespan. The results are shown in
Table 3, columns
Experim.-I, and
Actual.
Sched-T is able to predict the actual makespan obtained from a real-world production line with an error smaller than 5%. Additionally, in this case, there is no specific job characteristic that might influence the small variability for the different instances.
Then, in column Experim.-II, we consider what happens if the scheduler does not take into account the transport system, as most of the schedulers in the literature do. In this case, they would produce a schedule that is not optimal. In particular, we run Sched-T by setting all the transport times to zero and we obtain a schedule that is fed to our production line. We record the makespan obtained in this case and compare the error obtained with the one computed in columns Experim.-I. If the scheduler does not include the transport times, the resulting schedule contains an error of up to 23%, which is 18% greater than the one obtained by the schedule considering the transport times. Thus, the makespan obtained using the real system by considering the transport time improves the makespan by up to 14% with respect to the one found without considering the transport time.
Table 4 shows the results obtained by applying
Sched-T to a different plant configuration depicted in
Figure 7. This new configuration consists of a modified version of our real-world case study: we added a bay and a machine of the same type on the opposite side of each existing one to implement production redundancy. We built this new configuration by exploiting Tecnomatix Plant Simulation, a commercial state-of-the-practice discrete event simulation tool. The simulation allows for testing our proposed algorithm on a different scenario, enabling the calculation of simulated production times (e.g., makespan) and demonstrating that
Sched-T can also be applied to different plant configurations. We executed the same test using
Table 3, generating new instances of the same size. The results show that when considering transport time,
Sched-T allows for reducing the error of the estimated makespan, keeping it within 5% and lowering it by 17% when not considering transport time.
To sum up, our proposed solution allows us to estimate the makespan within a reasonable time frame with high precision. By correctly estimating the transfer times time, we are able to build a more precise schedule.
5.5. Multiple Arrivals
The results discussed above focused on the efficiency of the solution at each single job arrival. In this section, we evaluate how the schedule changes as new jobs arrive. We consider the same set of instances without the transport system (
Section 5.2) and with the transport system (
Section 5.3). We remove
p% of the jobs, compute the initial makespan without these jobs, and uniformly spread the arrival of the removed jobs at random between zero and the initial makespan. For each arrival, we update the schedule and the makespan.
In order to evaluate the quality of the final makespan obtained in this way, we consider an ideal scheduler that knows all the jobs (the initial ones and the future ones, with their arrival times) in advance and computes a single optimize schedule; we call this scheduler clairvoyant.
Figure 8 shows the difference (in percentage) between the final makespan obtained after updating the initial makespan at every job arrival and the makespan obtained with the clairvoyant scheduler for different percentages of dynamic jobs (jobs removed from the instances).
In both cases (with and without the transport system), updating the schedule at every arrival provides a solution that is comparable to an ideal scheduler that has all the information in advance. The case with the transport system shows a higher deviation since the instances have a lower number of jobs. Overall, the total rescheduling strategy provides near-optimal solutions with a limited use of the processing resources.