Optimizing Heat Treatment Schedules via QUBO Formulation

Abstract

Quadratic Unconstrained Binary Optimization (QUBO) is the problem of finding binary variable assignments that minimize a given quadratic objective function. Many combinatorial optimization problems can be transformed into equivalent QUBO formulations, and significant research efforts have been devoted to developing efficient QUBO solvers. This paper presents a method for converting a real-world, industrial-scale scheduling problem arising in the heat treatment process of metal parts into an equivalent QUBO formulation. In current operations, two experienced operators manually spend about two hours each day to create a 24 h schedule for two furnaces, considering various constraints and processing priorities. We have developed a C++-based scheduling system that automatically converts this problem into a QUBO instance and solves it using QUBO++, a high-performance toolkit we have recently developed and released. The experimental results on actual scheduling instances show that QUBO++ consistently produces high-quality solutions in a short time, leveraging the computational merits of the QUBO formulation. The system reduces the labor equivalent to two hours of expert work per day, indicating that automated scheduling via QUBO++ is a promising approach for improving efficiency and accuracy in factory operations.

1. Introduction

1.1. QUBO and the Heat Treatment Scheduling

A Quadratic Unconstrained Binary Optimization (QUBO) problem is a type of combinatorial optimization problem defined by a quadratic function over binary variables. The objective is to find values of the binary variables (i.e., 0s and 1s) that minimize the value of the quadratic function.

For example, consider the following quadratic function f with three binary variables $x_0, x_1, x_2$:

$$\begin{array}{cc}\hfill f(x_0, x_1, x_2)& ={(2x_0+3x_1+4x_2-6)}^2\hfill \\ \hfill & =36-20x_0-27x_1-32x_2+12x_0{x}_1+16x_1{x}_2+24x_1{x}_2.\hfill \end{array}$$

This quadratic objective function includes three linear terms and three quadratic terms. It attains its minimum value of 0 when $x_0=1$, $x_1=0$, and $x_2=1$, which represents the optimal solution to the QUBO problem.

Since many optimization problems can be equivalently formulated as QUBO problems [1], numerous researchers have dedicated efforts to developing efficient methods for such formulations. These include classic problems like the Traveling Salesman Problem (TSP) [2,3], the Quadratic Assignment Problem (QAP) [4], prime factorization [5,6], various graph problems [7], and applications in image processing [8], among others. Additionally, a wide range of QUBO solvers have been developed using different hardware approaches, including GPU [9,10], FPGA [11,12], ASIC [13], and optical computing technologies such as optical fibers [14,15]. In particular, D-Wave Systems has developed quantum annealers [16], which are capable of solving QUBO problems directly. Thus, tackling combinatorial optimization problems through QUBO formulations offers a promising alternative to developing problem-specific solvers. Therefore, it is crucial to advance techniques for effectively formulating such problems as QUBO instances.

This study focuses on a scheduling problem arising in the heat treatment process of metal parts (Figure 1) at the Tsukimi Factory of Nagato Co., Ltd., located in Hiroshima, Japan. While this problem shares similarities with the Job-Shop Scheduling Problem (JSSP), it is distinct in terms of the interdependencies between batch processing and the temporal structure of available slots. In this setting, multiple furnaces operate in parallel, each processing a sequence of orders, where each order consists of a single type of metal part. These parts are heated to high temperatures—approximately 1000 °C in our case—and then cooled using fans. Each metal part is characterized by the following three attributes:

• A group ID that categorizes the geometry of the metal part;
• A cooling parameter that specifies the fan rotation speed for cooling;
• A list of compatible furnaces capable of processing the part.

The scheduling process at the Tsukimi Factory of Nagato Co., Ltd. is managed using discrete time slots, with each slot corresponding to six minutes. Each order requires a fixed number of consecutive time slots, determined by the number of metal parts it contains. The objective is to assign each order to a time window within one of its compatible furnaces while satisfying a set of operational constraints.

If two consecutive orders involve the same type of metal part, they can be scheduled back-to-back without any idle time slots. However, when switching between different parts within the same group, at least one idle time slot must be inserted between them to prevent mixing or misidentification, which could compromise quality standards. Furthermore, transitions between different cooling parameters—i.e., fan rotation speeds—require between zero and four idle time slots, depending on the specific combination of source and target speeds. These transition periods are treated as idle time during which no orders can be processed.

In industrial-scale heat treatment, experienced operators typically create a 24 h daily schedule for all furnaces based on expert judgment—a task that often takes two hours each day. These operators consider factors such as order urgency, processing constraints, and, most importantly, their own intuition and heuristics, rather than explicit numerical indicators. Although order prioritization is performed implicitly through personal judgment, this experience-driven approach is time-consuming, heavily reliant on individual expertise, and lacks reproducibility.

1.2. Our Contribution

To overcome the aforementioned limitations, we address the scheduling problem inherent in the heat treatment process of metal parts using Quadratic Unconstrained Binary Optimization (QUBO). We formulate the problem as a QUBO model that incorporates all relevant constraints and propose an efficient method for generating high-quality, practically useful schedules.

We have also developed a decision support system that employs a QUBO solver to compute optimized schedules and present them to human operators. The system takes as input the list of orders for the next day, along with user-assigned priority levels, and automatically converts the problem into a QUBO formulation. If the generated schedule does not reflect the operator’s intentions, they can revise the priority levels and rerun the optimization, enabling a human-in-the-loop, iterative workflow that integrates field expertise with computational optimization.

This system is implemented using QUBO++ [17], a C++ library for formulating and solving QUBO problems. QUBO++ provides an expressive and efficient API for constructing QUBO instances programmatically and includes a lightweight solver, the Easy Solver, which is based on the positive min search algorithm [12]. This algorithm is a local search heuristic that selects a bit to flip based on the delta values of all bits, which represent the changes in the objective function. It identifies the minimum positive delta as a threshold, extracts all bits with deltas below this threshold, and randomly selects one of them to flip. This process is repeated iteratively. Unlike the well-known simulated annealing algorithm, the positive min search algorithm requires no hyperparameter tuning for temperature scheduling, which is often critical for solution quality.

In this study, we leverage QUBO++ to model and solve real-world scheduling problems in heat treatment processes and demonstrate its practical effectiveness using the Easy Solver bundled with the library. The source code of QUBO++ is publicly available (URL: https://abs2.cs.hiroshima-u.ac.jp/, accessed on 4 August 2025).

1.3. Job-Shop Scheduling Problem and Related Works

The scheduling problem addressed in this study can be considered a variant of the Job-Shop Scheduling Problem (JSSP). The classical JSSP has been extensively studied over the decades [18,19] and is typically formulated as a mixed-integer programming (MIP) model [20,21]. Numerous metaheuristic approaches have also been proposed to tackle the inherent computational complexity of JSSP, including Genetic Algorithms [22,23], simulated annealing [24,25], Tabu Search [26,27], Ant Colony Optimization [28,29], Particle Swarm Optimization [30], and Machine Learning techniques [31], among others.

Quantum annealing, originally proposed by Kadowaki and Nishimori [32] as a quantum-mechanical extension of classical simulated annealing, provides a theoretical framework for solving combinatorial optimization problems by exploiting quantum fluctuations. In particular, it is well-suited for solving Quadratic Unconstrained Binary Optimization (QUBO) problems, which offer a unified representation for a broad class of NP-hard problems. Since its introduction, QUBO-based modeling has attracted significant attention, leading to the development of various solvers—both quantum and classical. For instance, D-Wave Systems has built dedicated quantum annealers that solve QUBO problems natively, facilitating both theoretical exploration and proof-of-concept implementations.

However, in practice, the resolution and noise levels of current quantum annealers such as D-Wave Advantage 2.0 severely limit their performance. As noted in recent evaluations [10], these devices often fail to find even good approximate solutions for nontrivial problem instances, making them unsuitable for many real-world applications. Consequently, classical solvers implemented on CPUs, GPUs, or FPGAs remain the dominant and more reliable choice for solving QUBO problems at scale.

This practical shift has encouraged the formulation of JSSP and its variants as QUBO problems using solver-agnostic techniques. A key benefit of this approach lies in its development efficiency: traditional metaheuristics such as simulated annealing or Tabu Search typically require the manual design and fine-tuning of algorithmic components for each problem variant, which can be time-consuming and costly. In contrast, once a general QUBO formulation framework is established, adapting it to new instances—such as modifying objective functions or introducing additional constraints—often requires only changes to the QUBO model itself.

This flexibility makes QUBO-based modeling particularly attractive for industrial-scale scheduling problems, where complex, evolving constraints and objectives are common. Moreover, this approach facilitates rapid adaptation across a family of similar JSSP instances, avoiding the need to develop custom algorithms for each case. Whether solved using quantum annealers or classical solvers, the QUBO formulation serves as a unified abstraction that shifts development efforts from algorithm design to model construction.

Several studies have demonstrated the feasibility of applying QUBO-based methods to job-shop and flexible job-shop scheduling problems. Denkena et al. [33] formulated the classical JSSP as a binary quadratic model that captures precedence and machine-exclusivity constraints, and they solved it using conventional optimization techniques on benchmark instances. Carugno et al. [34] investigated the use of D-Wave’s quantum annealer to solve QUBO-encoded JSSP instances, employing problem relaxation and minor embedding to fit within the hardware’s connectivity limitations. Schworm et al. [35] proposed a QUBO formulation for the Flexible JSSP and demonstrated its effectiveness using quantum annealing on standard datasets, while their follow-up study [36] introduced a multi-objective formulation to optimize both makespan and workload balance via hybrid quantum-classical computation. Fu et al. [37] presented a QUBO model for the FJSSP and solved it using a coherent Ising machine (CIM), focusing solely on makespan minimization and reporting significant speedups compared to classical solvers.

While these studies confirm the general applicability of QUBO formulations to scheduling problems, they primarily target benchmark instances with simplified or standard constraints and objectives. In contrast, our work addresses real-world industrial scheduling in a heat-treatment context, involving domain-specific constraints such as thermal ramping, batch operations, and multi-furnace coordination. We introduce two objective functions directly reflecting factory needs—minimizing cost based on priority values and reducing idle time slots—and employ a scalable classical QUBO solver (QUBO++), allowing for practical deployment and easy adaptation to operational policy changes.

The remainder of this paper is organized as follows. Section 2 describes the types of metal parts and daily order data handled by the operators, along with the operational constraints of the scheduling problem. Based on these constraints, the objective function for the scheduling problem is formulated. Section 3 presents our QUBO formulation for the case of a single furnace. This formulation is then extended to handle multiple furnaces in Section 4. Section 5 reports the results of computational experiments conducted using real-world metal part data and a set of 10 daily orders. Finally, Section 6 concludes the paper.

2. Scheduling Problem Formulation for the Heat Treatment Process of Metal Parts

The primary objective of this section is to formulate the scheduling problem for the heat treatment process of metal parts. For clarity, we first consider the simplified case in which only a single furnace is available. This formulation will later be extended to handle multiple furnaces.

To aid reader understanding, we begin by defining several key terms in the context of the heat treatment process at the Tsukimi Factory of Nagato Co., Ltd.:

• Furnaces. The factory is equipped with multiple furnaces used for the heat treatment of metal parts. Time is discretized into 6-min slots, and each slot operates under a specific cooling parameter—one of these values: 0, 5, 8, 10, 15, 20, 30, 40, 50, or 60—which determines the required fan rotation speed during that slot.
• Orders. Each order, placed by a customer company, corresponds to a specific type of metal part and specifies the quantity to be processed. The number of consecutive time slots required for an order is proportional to the specified quantity.
• Parts. Each metal part belongs to a particular group, categorized according to its geometry, and is associated with a single cooling parameter.
• Idle time slots for cooling. When switching from one cooling parameter to another between consecutive orders, a specific number of idle time slots is required, depending on the pair of cooling parameters involved. These values are summarized in

  Table 1. Required number of adjustment time slots between parts with different cooling parameters.

  		Following Cooling Parameter
  		0	5	8	10	15	20	30	40	50	60
  Current cooling parameter	0	0	1	1	1	2	2	4	4	4	4
  	5	1	0	0	0	2	2	2	2	2	2
  	8	1	0	0	0	0	2	2	2	2	2
  	10	1	0	0	0	0	0	1	2	2	2
  	15	1	1	0	0	0	0	1	2	2	2
  	20	1	1	1	0	0	0	0	1	2	2
  	30	1	1	1	1	1	0	0	0	2	2
  	40	2	1	1	1	1	1	0	0	0	1
  	50	2	2	2	1	1	1	1	0	0	0
  	60	2	2	2	1	1	1	1	1	0	0

  .

When two orders are processed consecutively, the number of required idle time slots between such orders depends on the characteristics of their associated parts, according to the following rules:

Rule 1

No idle time slot is required if the two (consecutive) orders involve the same metal part.

Rule 2

If the two parts are different, the required number of adjustment time slots is determined by Table 1, based on the current and subsequent cooling parameters.

Rule 3

Even if the adjustment time is zero, at least one idle time slot is required if the two parts are different but belong to the same group.

Experienced operators at the Tsukimi Factory of Nagato Co., Ltd. currently create heat treatment process schedules for the following day on the preceding day. They implicitly prioritize orders based on their importance and urgency while also attempting to minimize idle time. To formalize this decision-making process, we assign a priority value to each order, with higher values indicating greater urgency and/or importance. Orders with higher priority are intended to be scheduled earlier in the day. To reflect this, we define a cost function over time slots, where the cost increases when a high-priority order is scheduled at a later time. It is important to note that the cost defined here is not a real cost but an artificial objective value introduced to help derive a desirable schedule.

Based on these considerations—priority and idle time—we define the following two objective functions:

• Total cost. Each time slot is associated with a cost, defined as the product of the slot number and the priority of the order assigned to that slot. The total cost is the sum of the costs across all scheduled time slots. Idle time slots are excluded from this calculation, as they are separately accounted for in the total idle time slots defined below.
• Total idle time slots. The total number of idle time slots that occur between consecutive orders.

The goal is to minimize both the total cost and the total idle time slots in order to obtain a desirable schedule.

We define these objectives formally as follows. Let m be the number of orders, each identified by an integer ID from 0 to $m-1$. Let $T_i$ ($0\le i\le m-1$) denote the number of time slots required to complete Order i, and let $P_i$ denote its priority value. Based on the properties of each part, we define $I(i, j)$ as the number of required idle time slots between Order i and Order j ($0\le i, j\le m-1$).

The m orders are assigned to m tracks, Track 0 through Track $m-1$, to represent their processing order. Let $o=\left[o\right(0), o(1),\dots , o(m-1\left)\right]$ denote the processing sequence, where Track t ($0\le t\le m-1$) processes Order $o\left(t\right)$.

Ignoring idle time slots for now, the start time $S\left(t\right)$ of Order $o\left(t\right)$ is given by

$$\begin{array}{cc}\hfill S\left(t\right)& =\sum _{i=0}^{t-1}{T}_{o\left(i\right)}.\hfill \end{array}$$

Order $o\left(t\right)$ then occupies time slots from $S\left(t\right)$ to $S\left(t\right)+T_{o\left(t\right)}-1$. Accordingly, the total cost $\mathrm{Cost}\left(o\right)$ of the permutation o is defined as

$$\begin{array}{cc}\hfill \mathrm{Cost}\left(o\right)& =\sum _{t=0}^{m-1}\sum _{i=0}^{T_{o\left(t\right)}-1}{P}_{o\left(t\right)}·(S\left(t\right)+i)=\sum _{t=0}^{m-1}{P}_{o\left(t\right)}{T}_{o\left(t\right)}\left(S\left(t\right)+{\displaystyle \frac{1}{2}}(T_{o\left(t\right)}-1)\right).\hfill \end{array}$$

Next, we define the total idle time. Since the idle time between consecutive orders $o\left(t\right)$ and $o(t+1)$ is $I\left(o\right(t),o(t+1\left)\right)$, the total idle time $\mathrm{IdleSlot}\left(o\right)$ is given by

$$\begin{array}{cc}\hfill \mathrm{IdleSlot}\left(o\right)& =\sum _{t=0}^{m-2}I(o\left(t\right),o(t+1)).\hfill \end{array}$$

We use Figure 2 to illustrate how the total cost and total idle time slots are computed. The first order $o\left(0\right)$ in Track 0 has priority $P_{o\left(0\right)}=3$, and its cost is $(0+1+2+3)\times 3=18$. The next order $o\left(1\right)$ in Track 1 also has priority $P_{o\left(1\right)}=3$, and its cost is $(4+5+6)\times 3=45$. The last order $o\left(2\right)$ in Track 2 has priority $P_{o\left(2\right)}=2$, and its cost is $(7+8+9)\times 2=48$. Thus, the total cost of permutation o is $\mathrm{Cost}\left(o\right)=18+45+48=111$. Clearly, orders with higher priorities should be assigned to earlier tracks to minimize the total cost. Additionally, the idle time slot between Orders $o\left(0\right)$ and $o\left(1\right)$ is $I\left(o\right(0),o(1\left)\right)=1$, and that between Orders $o\left(1\right)$ and $o\left(2\right)$ is $I\left(o\right(1),o(2\left)\right)=2$. Thus, the total idle time slots are $\mathrm{IdleSlot}\left(o\right)=1+2=3$.

Our goal is to minimize both $\mathrm{Cost}\left(o\right)$ and $\mathrm{Idle}\left(o\right)$. However, it may not be possible to minimize both simultaneously. Therefore, we introduce a weighting parameter $\lambda$ to balance the two objectives. Specifically, the overall objective function $\mathrm{Objective}\left(o\right)$ with respect to permutation o is defined as

$$\begin{array}{cc}\hfill \mathrm{Objective}\left(o\right)& =\mathrm{Cost}\left(o\right)+\lambda ·\mathrm{Idle}\left(o\right).\hfill \end{array}$$

For example, if $\lambda =10$, then the objective function corresponding to the above-mentioned example is obtained as follows:

$$\begin{array}{cc}\hfill \mathrm{Objective}\left(o\right)& =111+10\times 3=141.\hfill \end{array}$$

Clearly, when $\lambda =0$, the objective ignores idle time and minimizes only the total cost. Conversely, when $\lambda$ is sufficiently large, the optimization focuses on minimizing idle time at the expense of total cost.

However, in practice, there is no solution that satisfies $\mathrm{Idle}\left(o\right)=0$. Therefore, assigning excessively large values to $\lambda$ in an attempt to aggressively minimize idle time is not meaningful. Since there is no formalized priority between the two objectives, a practical strategy is to begin with a moderate value (e.g., $\lambda =1$). If the resulting solution exhibits an unacceptably high $\mathrm{Idle}\left(o\right)$, the operator can incrementally increase $\lambda$ and rerun QUBO++ to obtain a new solution with reduced idle time. This procedure can be repeated until a satisfactory trade-off is achieved. Thanks to the short solving time of QUBO++ (typically a few seconds), this tuning process is feasible in real-world applications.

Note that the other two parameters, $\mu$ and $\gamma$, do not require such adjustment. These parameters are used to enforce constraints rather than to balance objectives and can therefore be set to sufficiently large values—provided that they do not cause numerical overflows during QUBO computations.

3. The QUBO Formulation of the Scheduling Problem: Single Furnace

This section presents how the scheduling problem for a single furnace can be formulated as a QUBO problem.

Given a scheduling problem with m orders, we define an $m\times m$ binary matrix $X=\left(x_{t,i}\right)$ to represent a permutation o, where $o\left(t\right)=i$ if and only if $x_{t,i}=1$. That is, $x_{t,i}=1$ indicates that the i-th order is assigned to the t-th position in the schedule. Figure 3 shows an example of a $5\times 5$ matrix $X=\left(x_{t,i}\right)$ representing the permutation $[1, 3, 0, 2, 4]$.

To ensure that X represents a valid permutation, each row and each column must contain exactly one entry equal to 1—i.e., each row and column must be one-hot encoded. This constraint is captured by the following quadratic formula:

$$\begin{array}{c}\hfill \mathrm{Onehot}\left(X\right)=\sum _{t=0}^{m-1}{\left(1-\sum _{i=0}^{m-1}{x}_{t,i}\right)}^2+\sum _{i=0}^{m-1}{\left(1-\sum _{t=0}^{m-1}{x}_{t,i}\right)}^2\end{array}$$

Assume that X satisfies the one-hot encoding and represents a permutation $o=\left[o\right(0),o(1),\dots ,o(m-1\left)\right]$. In other words, $x_{t,i}=1$ if $i=o\left(t\right)$ and $x_{t,i}=0$ if $i\ne o\left(t\right)$. Given that $x_{t,o\left(t\right)}=1$, the number of time slots $T_{o\left(t\right)}$ required to process Order $o\left(t\right)$ ($0\le t\le m-1$) is given by

$$\begin{array}{c}\hfill T_{o\left(t\right)}=\sum _{i=0}^m{t}_i{x}_{t,i}.\end{array}$$

Using $T_{o\left(t\right)}$, the starting time $S\left(t\right)$ of Order $o\left(t\right)$ is given by

$$\begin{array}{cc}\hfill S\left(t\right)& =\sum _{k=0}^{t-1}{T}_{o\left(k\right)}=\sum _{k=0}^{t-1}\sum _{i=0}^m{t}_i{x}_{k,i}.\hfill \end{array}$$

The priority $P_{o\left(t\right)}$ of Order $o\left(t\right)$ is given by

$$\begin{array}{c}\hfill P_{o\left(t\right)}=\sum _{i=0}^m{p}_i{x}_{t,i}.\end{array}$$

The total cost $\mathrm{Cost}\left(X\right)$ is then given by

$$\begin{array}{cc}\hfill \mathrm{Cost}\left(X\right)& =\sum _{t=0}^{m-1}{P}_{o\left(t\right)}{T}_{o\left(t\right)}\left(S\left(t\right)+{\displaystyle \frac{1}{2}}(T_{o\left(t\right)}-1)\right)\hfill \\ & =\sum _{t=0}^{m-1}\sum _{i=0}^m{p}_i{t}_i{x}_{t,i}\left(\sum _{k=0}^{t-1}\sum _{j=0}^m{t}_j{x}_{k,j}+{\displaystyle \frac{1}{2}}\left(\sum _{j=0}^m{t}_j{x}_{t,j}-1\right)\right).\hfill \end{array}$$

Note that

$$\begin{array}{cc}\hfill P_{o\left(t\right)}{T}_{o\left(t\right)}& =\left(\sum _{i=0}^m{p}_i{x}_{t,i}\right)\left(\sum _{i=0}^m{t}_j{x}_{t,i}\right)=\sum _{i=0}^m{p}_i{t}_i{x}_{t,i}.\hfill \end{array}$$

Furthermore, from $x_{t,o\left(t\right)}=x_{t+1,o(t+1)}=1$, the idle time $I\left(o\right(t),o(t+1\left)\right)$ required between consecutive orders $o\left(t\right)$ and $o(t+1)$ is

$$\begin{array}{c}\hfill I(o\left(t\right),o(t+1))=\sum _{i=0}^{m-1}\sum _{j=0}^{m-1}l(i, j)x_{t,i}{x}_{t+1,j}.\end{array}$$

Thus, the idle time slots can be given as follows:

$$\begin{array}{cc}\hfill \mathrm{Idle}\left(X\right)& =\sum _{t=0}^{m-2}I(o\left(t\right),o(t+1))=\sum _{t=0}^{m-2}\sum _{i=0}^{m-1}\sum _{j=0}^{m-1}l(i, j)x_{t,i}{x}_{t+1,j}.\hfill \end{array}$$

The objective function for the scheduling problem is given by

$$\begin{array}{c}\hfill \mathrm{Objective}\left(X\right)=\mu ·\mathrm{Onehot}\left(X\right)+\mathrm{Cost}\left(X\right)+\lambda ·\mathrm{Idle}\left(X\right),\end{array}$$

(1)

where $\mu$ is a sufficiently large constant to enforce the one-hot constraint. Since $\mathrm{Onehot}\left(X\right)$, $\mathrm{Cost}\left(X\right)$, and $\mathrm{Idle}\left(X\right)$ are quadratic formulas of $X=\left(x_{i,j}\right)$, the resulting objective function $\mathrm{Objective}\left(X\right)$ is a QUBO formula.

4. QUBO Formulation for Scheduling with Multiple Furnaces

In practical factory settings, multiple furnaces are often available. We therefore extend the single-furnace scheduling problem to accommodate a multi-furnace environment. In this scenario, each order must be assigned to one of several furnaces, and the scheduling problem involves determining both the assignment of orders to furnaces and the optimal processing sequence for each furnace.

We now present a method for formulating the scheduling problem with multiple furnaces as a QUBO problem. Suppose there are n furnaces, identified by integer IDs from 0 to $n-1$. Recall that there are m real orders, identified by IDs from 0 to $m-1$. To facilitate the QUBO formulation, we introduce a dummy order with ID m, resulting in a total of $m+1$ orders. Since we have n furnaces and m time slots per furnace, there are $mn$ available tracks for scheduling. Among these, exactly m tracks must be assigned to real orders, and the remaining $mn-m$ tracks will be filled with dummy orders. To prevent real orders from being scheduled after dummy orders, we assign the dummy order a large processing time, $t_m=\gamma$, where $\gamma$ is a sufficiently large constant. This design ensures that dummy orders appear only after all real orders have been scheduled on each furnace. To represent the scheduling decisions, we introduce a three-dimensional array of binary variables $X=\left(x_{\alpha ,t,i}\right)$ with dimensions $n\times m\times (m+1)$, where

• $x_{\alpha ,t,i}=1$ if and only if Order i ($0\le i\le m-1$) is assigned to Furnace $\alpha$ at track t;
• $x_{\alpha ,t,m}=1$ if and only if the dummy order is assigned to Furnace $\alpha$ at track t.

Note that both the required time slots and the priority of the dummy order can be set to zero, provided that $\gamma$ is sufficiently large.

Since each furnace can process one order, including the dummy order, in each time slot, we include the following constraint for all furnaces $\alpha$ and time slots t:

$$\begin{array}{cc}\hfill \sum _{i=0}^m{x}_{\alpha ,t,i}& =1\hfill \end{array}$$

Moreover, each order, excluding the dummy order, must be assigned to one of the furnaces, and the following constraint must be satisfied for all Order i ($0\le i\le m-1$).

$$\begin{array}{cc}\hfill \sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-1}{x}_{\alpha ,t,i}& =1\hfill \end{array}$$

These constraints must be satisfied for the valid assignment of orders to the time slots of furnaces. The following QUBO formula $\mathrm{Onehot}\left(X\right)$ takes a minimum value of 0 if these constraints are satisfied:

$$\begin{array}{cc}\hfill \mathrm{Onehot}\left(X\right)& =\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-1}{\left(1-\sum _{i=0}^m{x}_{\alpha ,t,i}\right)}^2+\sum _{i=0}^{m-1}{\left(1-\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-1}{x}_{\alpha ,t,i}\right)}^2.\hfill \end{array}$$

Next, we define the objective functions corresponding to total cost and total idle time slots. The total cost can be computed by summing over the individual furnaces as follows:

$$\begin{array}{cc}\hfill \mathrm{Cost}\left(X\right)& =\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-1}{P}_{o\left(t\right)}{T}_{o\left(t\right)}\left(S\left(t\right)+{\displaystyle \frac{1}{2}}(T_{o\left(t\right)}-1)\right)\hfill \\ \hfill & =\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-1}\sum _{i=0}^{m-1}{p}_i{t}_i{x}_{t,i}\left(\sum _{k=0}^{t-1}\sum _{i=0}^{m-1}{t}_i{x}_{k,i}+{\displaystyle \frac{1}{2}}(\sum _{i=0}^{m-1}{t}_i{x}_{t,i}-1)\right).\hfill \end{array}$$

The total number of idle time slots is computed as

$$\begin{array}{cc}\hfill \mathrm{Idle}\left(X\right)& =\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-2}I(o\left(t\right), o(t+1))=\sum _{\alpha =0}^{n-1}\sum _{t=0}^{m-2}\sum _{i=0}^{m-1}\sum _{j=0}^{m-1}l(i, j)x_{t,i}{x}_{t+1,j}.\hfill \end{array}$$

Finally, the objective function for multiple furnaces uses the same structure as the single-furnace objective (Equation (1)).

Each order may have a specified set of furnaces by which it can be processed. If an order i cannot be processed by furnace $\alpha$, then the solution of the value of $x_{\alpha ,t,i}$ must be 0 for all t ($0\le i\le m-1$). This can be carried out by substituting such binary variables in $\mathrm{Objective}\left(X\right)$ with 0. The QUBO++ toolkit [17] has a replace function to perform these substitutions of binary variables with 0.

5. Experimental Results

This section presents the experimental results that demonstrate the feasibility of generating desirable heat treatment schedules using the QUBO formulations introduced in the previous sections.

We have developed a C++ implementation that generates QUBO formulations and solves them using the QUBO++ library [17]. Our program takes as input two types of data: fixed metal part specifications and daily order data, which vary for each instance. It constructs a QUBO formulation based on Equation (1) and then uses the Easy Solver included in the QUBO++ library to search for approximate solutions. The Easy Solver internally employs a heuristic based on the positive min search algorithm [12], utilizing multicore processors for parallelism. All data used in the experiments are provided in the Appendix, and the QUBO++ library is publicly available. Together, these ensure that the experimental results in this paper can be reproduced without difficulty.

5.1. Metal Part Data and Daily Order Data

We use real-world data from the Tsukimi Factory, which operates two furnaces with IDs 1 and 3. The dataset includes 98 distinct metal parts, each described by the following attributes:

• Part Name. A one- or two-letter string representing the name of the metal part.
• Compatible Furnaces. Specifies which furnace(s) can process the part. The values can be “1” (only Furnace 1), “3” (only Furnace 3), or “1, 3” (both furnaces).
• Group ID. An integer representing the group to which the part belongs. N/A indicates a unique structure for which no idle time slot is required between transitions, as there is no risk of mixing or misidentification.
• Cooling Parameter. An integer representing the required fan rotation speed. The possible values are 0, 5, 8, 10, 15, 20, 30, 40, 50, or 60.

The daily order data varies from day to day and consists of the following fields:

• Order ID. A sequential integer ID starting from 0.
• Part Name. A one- or two-letter string identifying the metal part being ordered.
• Time Slots. The number of consecutive time slots required to process the order.
• Priority. An integer value indicating the operator-assigned priority of the order.

5.2. The Resulting Solution for the Daily Data with 10 Orders

We use actual daily order data along with the corresponding metal part information as a representative example.

Table 2. An example of the daily order data with 10 orders for Day 0.

Order	Part	Time Slots	Priority
0	A	1	5
1	B	14	4
2	B	89	3
3	C	10	1
4	D	48	3
5	E	1	4
6	F	7	2
7	G	41	1
8	H	9	1
9	AM	20	1

shows a real-world daily order dataset consisting of 10 orders. The corresponding metal part specifications for these orders are presented in

Table 3. The metal part data for the daily order in Table 2.

Part	Possible Furnaces	Group ID	Cooling Parameter
A	1, 3	1	15
B	1, 3	2	10
C	1, 3	3	0
D	1	N/A	0
E	1	N/A	0
F	1	N/A	0
G	1	N/A	0
H	1	N/A	5
AM	3	3	10

. Note that Orders 1 and 2 involve the same part, B. These datasets are merged into a single table, as shown in

Table A1. Day 0 daily order data merged with corresponding product attributes.

Order	Part	Time Slots	Priority	Furnaces	Group	Cooling Param.
0	A	1	5	1, 3	1	15
1	B	14	4	1, 3	2	10
2	B	89	3	1, 3	2	10
3	C	10	1	1, 3	3	0
4	D	48	3	1	N/A	0
5	E	1	4	1	N/A	0
6	F	7	2	1	N/A	0
7	G	41	1	1	N/A	0
8	H	9	1	1	N/A	5
9	AM	20	1	3	3	10

in Appendix A.

We created the QUBO formulation based on Equation (1) using the QUBO++ toolkit [17], a domain-specific language (DSL) designed for constructing QUBO formulations and efficiently searching for solutions. All experiments were conducted on a Windows 11 PC running WSL 2 (Ubuntu 22.04.5 LTS). The system was equipped with an Intel Core i9-13900 processor (4 GHz) and 32 GB of RAM. The C++ program was compiled using g++ version 11.4.0 with the -O3 optimization flag.

The resulting QUBO instance comprises 160 binary variables, 160 linear terms, and 12,800 quadratic terms. We used the Easy Solver bundled with QUBO++ to solve the QUBO problem, using parameters $\mu =$ 100,000, $\gamma =1000$, and $\lambda =10$. A solution with $\mathrm{Cost}\left(X\right)=$ 26,734 and $\mathrm{Idle}\left(X\right)=3$ was obtained in just 1 s for most cases.

Table 4. Solution of $\mathrm{Cost}\left(X\right)=$ 26,734 and $\mathrm{Idle}\left(X\right)=3$ for the daily order in Table 2 with $\lambda =10$.

Furnace 1
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	0	A	5	0–0 (1)	0	15	1	1, 3
1	1	B	4	1–14 (14)	0	10	2	1, 3
2	5	E	4	16–16 (1)	1	0	N/A	1
3	4	D	3	17–64 (48)	0	0	N/A	1
4	6	F	2	65–71 (7)	0	0	N/A	1
5	7	G	1	72–112 (41)	0	0	N/A	1
6	8	H	1	114–122 (9)	1	5	N/A	1
Furnace 3
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	2	B	3	0–88 (89)	0	10	2	1, 3
1	9	AM	1	89–108 (20)	0	10	3	3
2	3	C	1	110–119 (10)	1	0	3	1, 3

presents the schedule derived from this solution.

Each row in the table corresponds to an order assigned to a track, with the following attributes: order ID, part name, priority value, time slot range, number of idle slots before the track, cooling parameter, group ID, and compatible furnaces. For instance, Track 6 of Furnace 1 is assigned Order 8, which processes Part H with priority 1, occupies 9 time slots from slot 114 to 122, has 1 idle slot before it, a cooling parameter of 5, group N/A, and is compatible with Furnace 1.

The orders are allocated across the two furnaces such that the workload is balanced. Moreover, higher-priority orders tend to be scheduled earlier. The total number of idle slots is 3, indicating that the obtained solution is of sufficiently high quality for practical use.

A solution with fewer idle time slots can be obtained by increasing the value of $\lambda$, which gives higher priority to minimizing $\mathrm{Idle}\left(X\right)$.

Table 5. Solution of $\mathrm{Cost}\left(X\right)=\mathrm{27,808}$ and $\mathrm{Idle}\left(X\right)=1$ for the daily order in Table 2 with $\lambda =1000$.

Furnace 1
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	0	A	5	0–0 (1)	0	15	1	1, 3
1	1	B	4	1–14 (14)	0	10	2	1, 3
2	8	H	1	15–23 (9)	0	5	N/A	1
3	5	E	4	25–25 (1)	1	0	N/A	1
4	4	D	3	26–73 (48)	0	0	N/A	1
5	6	F	2	74–80 (7)	0	0	N/A	1
6	7	G	1	81–121 (41)	0	0	N/A	1
7	3	C	1	122–131 (10)	0	0	3	1, 3
Furnace 3
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	2	B	3	0–88 (89)	0	10	2	1, 3
1	9	AM	1	89–108 (20)	0	10	3	3

shows the solution computed with $\lambda =1000$. This solution contains only 1 idle time slot, indicating an improvement in idle-time efficiency. However, the total cost increases, and the schedule no longer respects the priority order of the tasks. For example, Track 2 is assigned Order 8 with priority 1, whereas in the previous solution with $\lambda =10$, it was assigned to Track 6. This trade-off highlights the importance of balancing cost and idle time according to practical requirements. Operators can choose between such solutions, depending on their preferences or unmodeled constraints.

5.3. The Resulting Solutions for 10 Real Daily Orders

We executed our C++ program on 10 real daily orders using the parameter setting $\lambda =10$, with the computation time limited to 10 s for each instance.

Table 6. Solutions obtained for 10 real daily orders with $\lambda =10$.

Day	Orders	Variables	Linear Terms	Quadratic Terms	Cost (X)	Idle (X)
0	10	160	160	12,800	26,734	3
1	15	315	315	46,800	130,123	9
2	21	567	567	163,170	34,812	7
3	16	336	336	62,976	75,874	4
4	12	204	204	19,872	73,560	5
5	23	644	644	199,962	66,800	9
6	22	616	616	181,016	88,634	8
7	21	546	546	141,120	39,748	5
8	16	368	368	67,584	114,353	6
9	7	70	70	2156	78,036	2

summarizes the characteristics of the resulting QUBO formulations and their corresponding solutions. The number of orders ranges from 7 to 23, with the number of binary variables in the QUBO ranging from 80 to 644. The number of quadratic terms ranges from 2156 to 199,962. The table also reports the values of $\mathrm{Cost}\left(X\right)$ and $\mathrm{Idle}\left(X\right)$ for each instance.

While the objective values $\mathrm{Cost}\left(X\right)$ and $\mathrm{Idle}\left(X\right)$ provide a numerical assessment of solution quality, they do not capture the full picture. To better understand the scheduling behavior, we examine in detail the solution for the instance with 23 orders.

Table 7. Solution of $\mathrm{Cost}\left(X\right)=\mathrm{66,800}$ and $\mathrm{Idle}\left(X\right)=9$ for the daily order with 23 orders using $\lambda =10$.

Furnace 1
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	3	BT	7	0–4 (5)	0	0	6	1
1	1	BR	7	6–8 (3)	1	0	6	1
2	11	BZ	6	11–13 (3)	2	20	N/A	1
3	10	AB	5	15–20 (6)	1	40	N/A	1
4	9	BX	4	21–34 (14)	0	30	7	1
5	7	BV	3	35–55 (21)	0	30	N/A	1
6	8	BW	2	56–60 (5)	0	30	N/A	1
7	12	AY	2	61–102 (42)	0	40	2	1, 3
8	2	BS	2	105–123 (19)	2	0	N/A	1
9	4	G	1	124–156 (33)	0	0	N/A	1
10	0	G	1	157–169 (13)	0	0	N/A	1
11	5	BU	1	172–194 (23)	2	15	7	1
12	6	BU	1	195–228 (34)	0	15	7	1
Furnace 3
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	21	AR	4	0–13 (14)	0	60	1	3
1	18	BC	3	14–70 (57)	0	50	4	3
2	20	AO	3	71–80 (10)	0	60	N/A	3
3	22	AQ	2	81–89 (9)	0	50	5	3
4	16	AV	2	90–116 (27)	0	60	1	1, 3
5	13	BF	2	118–146 (29)	1	30	N/A	3
6	14	AY	2	147–154 (8)	0	40	2	1, 3
7	19	BG	2	155–162 (8)	0	50	4	3
8	15	BG	1	163–177 (15)	0	50	4	3
9	17	AQ	1	178–186 (9)	0	50	5	3

presents the resulting schedule obtained with $\lambda =10$. In this solution, 13 orders are assigned to Furnace 1 and 10 orders to Furnace 3. Although higher-priority orders are generally assigned to earlier tracks in both furnaces, the solution contains a total of 9 idle time slots.

Table 8. Time to solution (TTS) in seconds using the Easy Solver of the QUBO++ toolkit over 100 trials for each instance.

Day	Objective (X)	Min (s)	Average (s)	Max (s)
0	26,764	0.0011	0.3706	4.5952
1	130,213	0.0062	0.0365	0.2431
2	34,882	0.0294	0.2959	1.8084
3	75,914	0.0057	0.0249	1.0272
4	73,610	0.0014	0.5435	5.2337
5	66,890	0.0330	0.5726	4.9958
6	88,714	0.0358	0.4735	3.1102
7	39,798	0.0291	1.5510	13.1653
8	114,413	0.0144	0.2120	1.4590
9	78,056	0.0001	0.0007	0.0021

reports the time to solution (TTS) in seconds for each day using the Easy Solver of the QUBO++ toolkit, evaluated over 100 trials. Each TTS represents the time required to obtain a solution whose objective value matches the best value $\mathrm{Objective}\left(X\right)$. Since the solver is based on randomized heuristics, the time to reach the target value varies across trials. In most cases (Days 0–6 and 8–9), the average TTS remains below one second. For Days 1 and 9, even the maximum time is well under one second, indicating highly stable performance.

The only exception is Day 7, which showed a relatively large variance and longer average TTS (1.5510 s) when targeting the best-known value of 39,798. However, if we slightly relax the objective value to 39,808—corresponding to just one additional idle time slot—the average TTS drops significantly to 0.1419 s, with a minimum of 0.0185 and a maximum of 1.0566 s. This demonstrates that while exact optimal solutions may require a longer time in rare cases, near-optimal solutions of comparable quality can still be obtained rapidly, which is valuable for practical use.

If operators prioritize minimizing idle time over strictly following the priority order, they can increase the parameter $\lambda$ to assign greater weight to the $\mathrm{Idle}\left(X\right)$ component. To explore this trade-off, we re-executed the solver with $\lambda =1000$, and the resulting schedule is shown in

Table 9. Solution of $\mathrm{Cost}\left(X\right)=\mathrm{69,558}$ and $\mathrm{Idle}\left(X\right)=4$ for the daily order with 23 orders using $\lambda =1000$.

Furnace 1
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	3	BT	7	0–4 (5)	0	0	6	1
1	2	BS	2	5–23 (19)	0	0	N/A	1
2	1	BR	7	24–26 (3)	0	0	6	1
3	11	BZ	6	29–31 (3)	2	20	N/A	1
4	9	BX	4	32–45 (14)	0	30	7	1
5	10	AB	5	46–51 (6)	0	40	N/A	1
6	7	BV	3	52–72 (21)	0	30	N/A	1
7	8	BW	2	73–77 (5)	0	30	N/A	1
8	12	AY	2	78–119 (42)	0	40	2	1, 3
9	6	BU	1	121–154 (34)	1	15	7	1
10	5	BU	1	155–177 (23)	0	15	7	1
11	0	G	1	179–191 (13)	1	0	N/A	1
12	4	G	1	192–224 (33)	0	0	N/A	1
Furnace 3
Track	Order	Part	Priority	Time Slots	Idle	Cooling	Group	Furnaces
0	21	AR	4	0–13 (14)	0	60	1	3
1	18	BC	3	14–70 (57)	0	50	4	3
2	20	AO	3	71–80 (10)	0	60	N/A	3
3	19	BG	2	81–88 (8)	0	50	4	3
4	16	AV	2	89–115 (27)	0	60	1	1, 3
5	22	AQ	2	116–124 (9)	0	50	5	3
6	15	BG	1	125–139 (15)	0	50	4	3
7	17	AQ	1	140–148 (9)	0	50	5	3
8	14	AY	2	149–156 (8)	0	40	2	1, 3
9	13	BF	2	157–185 (29)	0	30	N/A	3

. In this solution, the total number of idle time slots is reduced to 4, but at the expense of a higher cost. For instance, Order 2, originally assigned to Track 8 in the previous solution, is moved up to Track 1, violating the priority order and contributing to the increased cost.

Operators can experiment with different values of $\lambda$ to generate multiple schedules and choose the most appropriate one based on their operational requirements. Additionally, by adjusting the priority values of specific orders, they can explore alternative scheduling outcomes and select the solution that best suits their preferences or hidden constraints.

5.4. Multiple Top Solutions for the Flexibility

The QUBO problem generated by QUBO++ may admit multiple top solutions. From a practical perspective, obtaining the single optimal solution is not necessarily essential; near-optimal solutions that are sufficiently close to the optimum are often acceptable in real-world applications. Moreover, certain implicit preferences or priorities may not be explicitly captured in the formal scheduling formulation. Therefore, it is reasonable to provide operators with several high-quality candidate solutions, from which they may select one based on domain-specific knowledge or latent constraints. The Easy Solver module included in QUBO++ supports the enumeration of multiple top-ranked solutions.

Table 10. The top 20 best solutions for the daily order data with 10 orders for Day 0 in Table 2.

Cost (X)	Idle (X)	Furnace 1	Furnace 3
26,734	3	A(5), B(4), E(4), D(3), F(2), G(1), H(1)	B(3), AM(1), C(1)
26,734	4	A(5), B(4), E(4), D(3), F(2), H(1), G(1)	B(3), AM(1), C(1)
26,734	4	A(5), B(4), E(4), D(3), F(2), G(1), H(1)	B(3), C(1), AM(1)
26,748	3	B(4), A(5), E(4), D(3), F(2), G(1), H(1)	B(3), AM(1), C(1)
26,734	5	A(5), E(4), B(4), D(3), F(2), G(1), H(1)	B(3), AM(1), C(1)
26,734	5	A(5), B(4), E(4), D(3), F(2), H(1), G(1)	B(3), C(1), AM(1)
26,735	5	E(4), A(5), B(4), D(3), F(2), G(1), H(1)	B(3), AM(1), C(1)
26,748	4	B(4), A(5), E(4), D(3), F(2), H(1), G(1)	B(3), AM(1), C(1)
26,748	4	B(4), A(5), E(4), D(3), F(2), G(1), H(1)	B(3), C(1), AM(1)
26,749	4	E(4), B(4), A(5), D(3), F(2), G(1), H(1)	B(3), AM(1), C(1)
26,763	3	B(4), E(4), D(3), F(2), G(1), H(1)	A(5), B(3), AM(1), C(1)
26,734	6	A(5), E(4), B(4), D(3), F(2), G(1), H(1)	B(3), C(1), AM(1)
26,734	6	A(5), E(4), B(4), D(3), F(2), H(1), G(1)	B(3), AM(1), C(1)
26,735	6	E(4), A(5), B(4), D(3), F(2), G(1), H(1)	B(3), C(1), AM(1)
26,735	6	E(4), A(5), B(4), D(3), F(2), H(1), G(1)	B(3), AM(1), C(1)
26,748	5	B(4), A(5), E(4), D(3), F(2), H(1), G(1)	B(3), C(1), AM(1)
26,749	5	E(4), B(4), A(5), D(3), F(2), G(1), H(1)	B(3), C(1), AM(1)
26,749	5	E(4), B(4), A(5), D(3), F(2), H(1), G(1)	B(3), AM(1), C(1)
26,763	4	B(4), E(4), D(3), F(2), H(1), G(1)	A(5), B(3), AM(1), C(1)
26,763	4	E(4), B(4), D(3), F(2), G(1), H(1)	A(5), B(3), AM(1), C(1)

presents the 20 best solutions identified for a scheduling instance involving 10 orders (as listed in Table 2). For each solution, the objective values $\mathrm{Cost}\left(X\right)$ and $\mathrm{Idle}\left(X\right)$ are shown, along with the sequence of assigned orders and their respective priority values on each furnace track. For instance, the solution with $\mathrm{Cost}\left(X\right)=\mathrm{26,734}$ and $\mathrm{Idle}\left(X\right)=3$ is the best among the candidates. Two additional solutions achieve the same cost value ($\mathrm{Cost}\left(X\right)=\mathrm{26,734}$) but incur a slightly higher idle time ($\mathrm{Idle}\left(X\right)=4$). One of these is obtained by swapping G(1) and H(1) on Furnace 1, while the other results from swapping AM(1) and C(1) on Furnace 3. Although these are suboptimal in terms of idle time, they may still be considered acceptable alternatives depending on operational preferences.

Providing multiple candidate solutions is beneficial, as it mitigates the need for manual adjustments in cases where the optimal solution fails to meet certain unmodeled requirements. The current implementation thus enhances the usability of the system by offering flexibility at the decision-making stage.

6. Conclusions

In this study, we propose a QUBO-based formulation for scheduling in the heat treatment process of metal parts, incorporating both order priorities and idle times between orders. We developed a dedicated C++ implementation and employed our publicly available QUBO toolkit, QUBO++, to efficiently construct and solve the resulting QUBO instances. QUBO++ includes the Easy Solver tool, which utilizes a lightweight metaheuristic based on the positive min search algorithm and is optimized for multicore execution.

We conducted experiments using 10 days of real production data, which include fixed product specifications and varying daily order sets. The results demonstrated that our approach can solve practical-sized instances in a matter of seconds per run, enabling the rapid generation of high-quality schedules. Additionally, the weighting parameter $\lambda$ allows operators to flexibly explore trade-offs between priority-based cost and idle time minimization, supporting context-aware decision-making.

Importantly, the solver can return not only the best solution but also a set of top-ranked near-optimal solutions, as specified by the user. This feature enables factory operators to evaluate multiple feasible schedules and choose the one most appropriate for their operational constraints and preferences. Operators especially valued this flexibility, noting that it aligns with real-world scheduling practices that often involve balancing competing priorities.

Although manually generated benchmark schedules were not available for the datasets used in our experiments, experienced factory operators reviewed the generated schedules. They confirmed that the proposed solutions met practical constraints and expectations, providing informal yet meaningful validation of our approach. Overall, our findings underscore the practical utility of QUBO-based modeling and the QUBO++ framework as a flexible and scalable tool for real-world industrial scheduling.

As a future direction, the integration of more advanced metaheuristic techniques—such as simulated annealing or evolutionary algorithms—into QUBO++ may further improve scalability, robustness, and solution diversity for large-scale optimization tasks.