# Sensors and Communication Simulation for Unmanned Traffic Management
## 6 Validation
### Drone Trajectory in Presence of Contingencies  
The first scenario (depicted in Figure 11(a)) was built to show the results of the proposed drone control and navigation models, trajectory changes in presence of contingencies, and the generation of programmed contingencies. It consists of a single flight plan, defined to be flown manually by the pilot. Regarding the simulation of the control error caused by the pilot, we can see in Figure 11(b) that the simulator is able to generate different drone trajectories, deviating from the predicted path (in blue) by using the proposed model. The graph shows correlated deviations from the expected path (5 different realizations in red).  
Using the previous scenario as a base, a forced LOL contingency (loss of ground / air communications link) was scheduled after 60 s of flight. As a result, we can see in Figure 13 the simulated drone trajectory. Initially, the drone follows the associated flight plan slightly deviating from it due to the manual control model. However, after the second waypoint the expected operation suddenly halts, and a RTH maneuver is started. This is caused by the programmed LOL contingency. As expected, the GCS agent received from the action bus the forced contingency and has stopped the simulated C2 link. This was detected by the drone who automatically started a RTH maneuver with automatic control (now, the simulated trajectory deviates very little from the expected one which is a straight line to the takeoff position, as the autopilot is controlling the drone). However, in the course of the operation back home, the simulated drone battery level drops below a minimum threshold (30%, see Figure 13(a)) set within the drone model. A LOB contingency arises, which implies that the drone must land immediately. Thus, the automatic maneuver is stopped and a new one is initiated, which makes the drone land on the same position it is in that moment, without reaching the takeoff point.  
Figure 11: Box plots showing relative CPU and memory usage of the all simulator microservices during real-time simulation encompassing 10, 50, 100, and 200 drones. CPU usage limit is 200% as two cores are available. Average values are shown in green.  
Figure 14: (**a**) Distance to the takeoff point and battery level time evolution. (**b**) Comparison of the simulated flow trajectory with the UTM-received positions.  
Figure 12: (**a**) Flight plan simulated in the proposed scenario. (**b**) Trajectory followed by the drone (in red) in five different realizations using manual control model.  
Figure 13: Comparison of the expected trajectory and the flown trajectory. The location where both contingencies happened is annotated on the left figure.  
In parallel to what has already been explained, the GCS sends telemetry information to the UTM system periodically until the C2 link stops. Figure 14 shows the trajectory actually flown by the drone, which differs slightly from the telemetry information received by the UTM system. This is due to the fact that the real position of the drone and estimated position in telemetry messages differ, due to navigation error, as explained in Section 5.2.