Multi-product scheduling through process mining: bridging optimization and machine process intelligence

Abstract

Small and medium enterprises (SMEs) may not have the maturity to put forward and unfold all the benefits from an ERP based system, a vital tool for production planning. Manufacturing ubiquitous trends, however, are more approachable to SMEs, and even the more affordable tools could be of great advantage. In this paper we propose an algorithmic framework that uses process mining tools to extract the underlying industrial process via Petri nets, and then retrieve all product tree necessary information to perform the multi-level scheduling. A faster solution decoding is proposed, for algorithms that uses random-keys. Computational experiments show that the new decoding is faster than the usual, leading to promising new paths on its future uses.

Appendices

A Appendix: Random key decoding example

In this Appendix we show an example of the RK decoding process. As expected, in a production scheduling, there may exist more than one product that needs to be allocated on machines, therefore, we build a decoding example for 2 products, on a set of machines that has already some parts being processed.

As we are decoding 2 products, there must exist 2 RKs, one for each product. It is important to note that the order of decoding of the RK may change the schedules; we start by decoding products with earlier due-dates. In this case, as both products are due to time period 9, we choose randomly between then. The RKs for the example are:

Note that the values for products A, B and C were set to 0 on RK$_C$, as they are not used, but for implementations purposes we choose to have the RKs as a square matrix. Assuming a demand of 1 unit of product A (of Fig. 11) and also 1 unit of product C. The delivery deadline for both products is on time period 9, and there is one remaining part already scheduled on machine $m_1$ on time period 8.

As mentioned, the decoding is carried out on a sequential manner. Figure 14 shows the decoding process of product A and Fig. 15 of product C.

The process starts with product A (following the product tree), to be processed on machine 1 starting on time period 8. Note that here, only the integer part of the RK was used, since there is no decision (the only part that can be loaded, according to the precedence relations, is A). After A is scheduled on machine $m_1$, both sub parts B and C can be loaded (14d, 14e, 14f), sorting the fractional part of both RK elements, we see that B $\le$ C (0.57 $\le$ 0.98), so the first part loaded is B and then C (14g, 14h, 14i). The two sub parts are loaded in machine $m_2$, according to the integer part of the RK. Finally, after C is scheduled, both D and E can be chosen, similarly to the last step, the sorting of the fractional parts dictates that E is loaded (14j, 14k, 14l) before D (14m, 14n, 14o).

Now, the same process is applied to RK$_C$ on Fig. 15; the first allocated part is C, using only the integer part of the key (15a, 15b, 15c). To decide what is the next loaded part, we sort the fractional part regarding subparts D and E. We see that D $\le$ E (0.05 $\le$ 0.30), so the first part loaded is D (15d, 15e, 15f) and then E (15g, 15h, 15i)

The next appendix demonstrate how to perform the upper and lower bounds.

B Appendix: Due dates lower and upper bounds

In this Section we perform the lower an upper bounds of product A (the decoding process depicted in Fig. 14) In Fig. 16 we present the $T_l$ and $T_u$ for the product of Fig. 11.

Note that, when calculating the $T_l$ in Fig. 16a, it is not considered only the permissible set of machines, instead, all products are allowed to be processed on all machines (and there may exist infinite machines). That yield a $T_l = 4$ (MRP calculations - 1), which is clearly infeasible, since the production should start on period 0. The $T_u$, on the other hand (Fig. 16b) is calculated as if only one machine were available, and stating from the last period with loaded parts, in this case, there is a loaded part on period 8, which yield a $T_u = 18$.

If the client due date for the product were to be on time period 2, it would be a waste of computations trying to decode the solution starting from that point; as it is now know by the $T_l = 4$, on the best case scenario, the first feasible decoding was due to period 5. So, only by knowing a priori the $T_l$ would save at least 4 unnecessary random key decoding. Also, there is no need to try to decode the solution on a period further than $T_u$, as it is certainly feasible, and the best decoding should be before it.

With this information we infer that the first feasible decoding is not before the $T_l$ and also not after $T_u$.