## 5 An Illustrative Example of Our Reactive Approach  
This section describes a simple example that illustrates how the proposed reactive algorithm solves the problem, in an iterative way, as new data is updated in the system at the end of each round trip (i.e., each time the AGV returns from a station to the depot). Figure 4 shows a toy case with 2 products and 2 workstations. Let us denote by \(f_{ij}(t)\) a function that provides an estimate of the real round trip time associated with assigning product \(i\) to station \(j\) at time \(t\in[0,t_{f})\), \(t_{ij}^{t}\), where \(t_{f}\) refers to the end time of a working day. The main concept here is: (i) we will use \(f_{ij}(t)\) to design an initial assignment plan based on estimated travel times; and (ii) every time the AGV returns to the depot, since the actual times might be different than the estimated ones, the remaining assignments will be recomputed using \(f_{ij}(t)\) again. In other words, each time we pass through the depot (and while the list of pending assignments is not empty), the current time \(t_{c}>0\) will be registered and the previous assignment plan will be re-adjusted (from \(t_{c}\) to \(t_{f}\)), taking into account the estimates provided by \(f_{ij}(t)\). Hence, the figure shows a first assignment plan (E1) where: (i) product 1 (P1) is first sent to station 2 (S2) and then returned to the depot (0) once processed; (ii) product 2 is taken to station 1 and then returned to the depot; (iii) product 2 is taken to station 2 and returned to the depot; and (iv) product 1 is taken to station 1 and returned to the depot. Would the estimated travel times be perfectly accurate (i.e., without delays), this plan would finish by time \(t_{E1}\). Unfortunately, as we put this plan in action, we might experience changes in the estimated travel times (usually in the form of delays), as shown in the real execution plan R1, which might lead to a new estimated makespan \(t_{R1}\). At this point in time, when product P1 has just returned to the depot, we cannot do anything to change the fact that product 1 has already been processed in station 2. However, we can re-adjust our initial plan taking into account the current time \(t_{c}\) and \(f_{ij}(t)\). This is how plan E2 emerges. Notice that plan E2 is able, at least in theory, to enhance the makespan associated with R1. This process of comparing the estimated travel times with the real ones, and then re-adjusting future trips if convenient, is repeated until all products have been processed by all stations. In our case, this leads to a final makespan \(t_{R3}\), which is not as good as \(t_{E1}\) but definitively better than \(t_{R1}\) thanks to our ability to reactively adjust the plan according to the current system conditions (current time every time the AGV visits the depot and the estimation function, which depends on the time \(t\) at which a trip is launched). One should notice that this is just a toy example, but in a situation in which the number of products \(n\) is large, and the number of stations \(m\) also grows, the size of the possible solutions space is vast and the problem suffers from combinatorial explosion. In addition, when several AGVs and depots are considered, the problem becomes even more challenging.  
Figure 4: An illustrative description of the proposed algorithms.