P RACTICAL W ORST C ASE : TIME FAILURE DETECTION THROUGH DT SYSTEM

The worst practical case is the scenario that occurs when, in the model run in the real system, the time failure that occurs is detected by the Digital Twin system and consequently changes are implemented to the behavior of the model in order to minimize the negative consequences.

This scenario has been proposed in the laboratory following the logic introduced in the previous chapter: in fact, it will be observed that, following the failure, the speed of Robot 2 will be approximately 2.5 times less than that of Robot 1, which will instead remain unchanged with respect to the conditions predicted a priori.

Thanks to the operation of the Digital Twin explained above, the results of this practical case shown below will confirm the initial hypothesis, i.e. that although it is impossible to obtain results equal to those of the best-case, the variables obtained at the end of the experiment, obviously considering time failure conditions, will be better than those of the theoretical wort-case.

Table 4-1 Collected process times and average process times in milliseconds

unit 1 unit 2 unit 3 unit 4 unit 5 unit 6 unit 7

Robot 1 11784,6681 13296,7121 13599,8162 13395,6975 13905,3247 14617,7153 13307,4644

Robot 2 27875,739 30806,8568 24039,2658

Avg process time

Robot 1 13452,3426 Robot 2 27573,9539

In Figure 4-5 it can be noticed how the scheduling changed due to the real-time detection of the change in the physical system. The scheduling shown in the picture is representative of the data collected during the launch of the test in the laboratory, shown in Table 4-1. It can be seen that in this case the critical resource is Robot 1, which determines the total process time of 93.907,3983 milliseconds.

What can be seen from the various tests carried out in the laboratory, however, is that the variability of process times for each individual task is rather high for both, but particularly for Robot 2. Analyzing the average process times, it can be seen that the average time related to the machine two is the one that deviates the most from the values predicted a priori. In this case, in fact, the process time related to Robot 2 is not 2.5 times that of Robot 1, but only 2,06 times.

Figure 4-5 Flexible scheduling obtained by applying the DT to the model

4.3.1 FlexSim Dashboard for the Practical Case

The process dashboard on FlexSim, which collects the data received from the physical system, will now be illustrated. This data collection will have to be analyzed more specifically as it is certainly error-prone due to the structure of the system. As introduced earlier, the replication of the physical process on the platform is delayed by a whole process time; this problem cannot be solved as it is necessary for the physical robot UR3e to make a whole movement before transmitting the time taken. An a priori estimate would in fact render the entire project a mere simulation, and not an emulation of the real system.

Figure 4-6 Output console on FlexSim with the values received during the process

Figure 4-7 Dashboard on FlexSim

The final dashboard will then provide values that deviate slightly from those observed in Node-Red, merely because the reception of delayed values of an entire process time, relative to each robot, means that on FlexSim the process does not start at the same time for both machines, thus leading to idle times for one of them that do not correspond exactly to the real ones. These results will be taken up in one of the next sections, so that they can be compared with those collected on the Node-Red platform to verify their accuracy.

4.3.2 Node-Red Dashboard for the Practical Case

Node-Red's dashboard, unlike that of FlexSim which has just been introduced, should not be subject to errors (except for the intrinsic margin of error due to measurement, which is in any case negligible) as it receives the values directly from the real system, and thus from the two robots at the end of each task completed.

On Node-Red's platform, as the real system proceeds with the execution of the process, the times associated with the completion of a task, start signals when Robot1's intervention is required, and stop signals when a total of 10 processed units is detected, are evaluate through the use of the timer function, and then transmitted.

Node-Red, differently from FlexSim, which was created for the purpose of analyzing and simulating industrial processes, does not have a predefined set of process variables.

Hence, while on FlexSim there is a palette of output visualizers, which by default includes the Throughput and Cycle-Time graphs of the process, on Node-Red the entire calculation must be programmed.

• Throughput

Figure 4-8 Composite Throughput per Hour

Composite Throughput per Hour

The throughput calculation consists of obtaining the number of items that, on average, are produced by the system in a unit of time; In this case, both throughput per hour and throughput per second will be shown in Table 4-1, the first one to ensure an effective comparison with FlexSim, and the second one because it is more consistent with the system's timing.

The first throughput calculated is for each machine, based on the process times received. For Robot 1, the average process time is 13415,3426 milliseconds, while for the Robot 2 the average process time is 27573,9539 milliseconds. Thus, the volume produced in one hour by each machine will be equal to:

Table 4-2 Throughputs related to each robot

items per hour items per second

Robot 1 268,35 0,0745

Robot 2 130,56 0,0363

Consequently, deriving the compound throughput per hour, it is equal to 398,9075 items per hour.

• Cycle Time

By analyzing the data collected on Node-Red at the end of the process, it is possible to derive not only the average and relative stay times of each individual machine, but also the cycle time of the complete system, which is useful for describing the time taken (on average) by the ten units of the batch to be processed.

Table 4-3 Staytime of the two robots

Staytime in seconds

Robot 1 13,415

Robot 2 27,574

4.3.3 Comparison of results

In order to prove that the model is a coherent representation of what happens in the real system, it must be verified that there is a correspondence between the number and order of task execution, and between the system variables.

Beginning with task execution, it was confirmed that the processing order of the items on FlexSim, despite the delay, is consistent with the order of execution in the physical system; indeed, both models show seven units processed by robot 1, and 3 by robot 2, in the same chronological order at the end of the process.

As previously mentioned, the performance results of the entire system in terms of Throughput and Cycle Time will now be compared to verify that, despite the interference caused on the data by the structure of the FlexSim model, the results are still consistent and contained within a tolerable margin of error.

Table 4-4 Comparison between FlexSim and Node-Red

Node-Red FlexSim

Throughput [item/s] 0,1108 0,1104

Cycle Time [s] 90,55 90,64

The data shown in Table 4-4 are for the specific system, which processes ten units. As can be seen, the model shows slight differences in total performance, attributable to the reasons listed above such as the delay in receiving the process time, which creates a time lag between the two models. More specifically, there is a variation of 0.09 seconds for every 10 units processed, which corresponds to the 0,1 percent of the Cycle Time. This absolutely negligible value demonstrates a certain consistency of the model.