## 3 Results and Discussion
### Computational Study on Benchmark Instances with CP Solvers  
Before going into detail about the solvers' performances per instance, we present the evaluation of the overall performance. The solvers achieved optimal results for 27% of the instances when given a time limit of 30 s and 43% of the instances after the extension of the time limit to 300 s for the JSSP. Regarding the FJSSP, the solvers calculated the optimum for 71.3% of instances with a 30 s time limit and 76.9% of instances with a 300 s time limit, as shown in Figure 4.  
After calculating the makespan with the introduced solvers, the results were compared (Tables 4 and 5). During the computational study, it became clear that there was no overall winner for all problem instances. The distribution of wins for FJSSP instances was balanced between both solvers compared to the JSSP results. When extending the time limit to 300 s for calculating the makespan, the results for JSSP differed compared to the previous experiments with a 30 s time limit. For the FJSSP, the results were similar to the results with a 30 s time limit. However, the results showed that the winning solvers sometimes changed for individual instances when changing the time limit. This means that, for instance, OR-Tools provided better results with the 30 s time limits for one instance, while CP Optimizer provided a better makespan with a 300 s time limit. Consequently, the time limit influenced the performance of an algorithm for a specific instance. Nevertheless, this was mostly applicable for equal makespan values calculated by both solvers but with different solving times. \begin{table}
\begin{tabular}{c c c} \hline \hline
**CP Solver** & **30 s** & **300 s** \\ \hline OR-Tools & 50 & 71 \\ CP Optimizer & 192 & 171 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Scoring points of CP Optimizer and OR-Tools for JSSP instances. Figure 4: Optimal results for JSSP and FJSSP. To evaluate the effects of the algorithm selection approach for industrial applications, the assessment of the makespan was important. For 54 instances of the JSSP with a 30 s solving time, both solvers achieved the same makespan. Based on a time limit of 300 s, the solvers calculated the same makespan for 72 instances. In addition, it was interesting to evaluate the impact on the makespan by extending the time limit. For JSSP instances, the extension of the time limit to 300 s achieved time savings of 2.5% over all tested instances. Moreover, the makespan improvements by selecting between two solvers achieved a 5.9% decrease in the makespan for the 30 s time limit and a 2.9% decrease in the makespan for 300 s (Figure 5). Consequently, the selection has the potential to strongly influence the improvement in the overall productivity of production. The smaller decrease when extending the time limit is not surprising because the longer solving time led to a convergence of solutions at the same time. For instance, with a 300 s time limit, the solvers achieved more equal values for the makespan compared to the 30 s solving time. Consequently, especially for use cases where a smaller calculation time is necessary, for example, dynamically reacting production systems, an algorithm selection can be useful and can increase production performance by up to 5.9%. Regarding the FJSSP, the extension of the time limit to 300 s achieved, over all instances, time savings of 0.18% compared to the winning makespan values for 30 s. Analyzing the minimization of the makespan by selecting the two solvers revealed a saving of 6329 time units for the 30 s time limit and 1245 time units for the 300 s time limit, calculated over all tested instances (Figure 6). This showed that the extension of the time limit did not substantially improve the overall performance regarding the makespan. Within 30 s of solving time, both solvers achieved the same makespan for 187 instances. With a 300 s solving time, both solvers calculated the same makespan for 219 instances.