## 6 Discussion  
### Integration of the Methods  
This paper illustrates that anomalies can be caused by multiple sources. If an AGV simply stops moving, the behavior can be based on hardware or software failures in the AGV, obstacles on the factory floor, cyber-attacks or adversarial attacks. In order to address the anomaly, it is necessary to identify the source. Several methods to identify the source of the anomaly (Section 5.1) were presented, which jointly can provide a holistic view of anomaly detection. Depending on the source of the anomaly, different mitigation methods can support the fleet in overcoming the effects of the anomaly or preventing similar anomalies in the future. Figure 6 summarizes the anomaly detection and mitigation methods described in this paper. During the operation of the provided use-cases, the fleet of AGVs and the components of the factory, such as machines and MES, produce data (e.g., communication data and monitoring data), which are collected in a central data warehouse or data lake. The various anomaly detection methods request the type of data that is relevant for the specific method. For example, for the identification of a cyber-attack (Section 5.1.2), the network communication data is analyued, whereas the process anomaly identification method (Section 5.1.1) is fed with data on transport tasks and AGV status  
Figure 5: This figure represents the reconstruction of the image with patches. monitoring data. If one of the anomaly detection methods identifies an anomaly, an alarm and information on the detected anomaly are sent to the data lake. This triggers the various presented mitigation methods. Depending on the anomaly at hand, one or more mitigation methods start to calculate mitigation measures. For example, an identified cyber-attack or adversarial attack can trigger the reconfiguration of AGV services (Section 5.2.1), the global reconfiguration method (Section 5.2.2) and the cyber-attack mitigation method (Section 5.2.3), leading in combination to a proposal for how to make the factory less vulnerable to this kind of attack (e.g., using additional firewalls) and how to mitigate the effect of the attack immediately. If it is possible to identify a new service configuration that enables the attacked AGV to become operational again, this configuration is deployed in the AGV. If this is not possible, the global reconfiguration serves as a fallback solution, e.g., by removing the attacked AGV from the fleet and reconfiguring the remaining fleet to cope with the new situation. Figure 7 illustrates the anomaly detection and mitigation approach for the use-case with the non-moving robot in more detail. The considered causes for the interrupted robot (broken robot, cyber-attack, adversarial noise) have different effects: if the AGV is the target of a cyber-attack, the network traffic would be different from usual; an adversarial attack will affect the availability and outcome of services. In the case of a defective drive engine, only certain KPIs such as distances covered will be affected. Hence, the AGV's KPIs, the services and the traffic data are the kinds of data that must be monitored by the anomaly detection methods from Section 5.1. Depending on the source of the anomaly, different detection methods will raise an anomaly alert, as each technique has dedicated data parts to monitor. A mitigation decision plan is used to select one of the possible mitigation methods (cf. Figure 6), where each mitigation candidate is checked sequentially for application. Assuming that, for instance, a driving engine of one AGV is broken and the _failure in AGV_ detection is triggered, then, the _Global AGV Reconfiguration_ and the _Reconfiguration of AGV Service_ are possible mitigation candidates. In this case, the _service oriented reconfiguration_ will fail, because another AGV could not replace the service provided by the broken driving engine. As there is no adversarial attack, the _Adversarial Attack Mitigation_ is not applicable.