# Unmanned Aerial Traffic Management System Architecture for U-Space In-Flight Services
## 5 Experiments
### Results  
In this section, we present results of the experimental tests for the two proposed use cases (an illustrative video with the use cases can be seen at [[https://grvc.us.es/downloads/videos/UTM_System.mp4](https://grvc.us.es/downloads/videos/UTM_System.mp4)]([https://grvc.us.es/downloads/videos/UTM_System.mp4](https://grvc.us.es/downloads/videos/UTM_System.mp4)), accessed on 26 April 2021), with all the modules in our UTM system working together. It is important to highlight that the experiments were carried out in real time, with the UTM system monitoring the operations and managing the unexpected  
Figure 12: Setup for the experiments. The computers running the RPS for the two UAS and the UTM system were placed at remote locations and communicated through the Internet via the MQTT protocol. Figure 13: Screenshot of the graphical user interface developed by SATWAYS running on the RPS Client Application. events properly. Moreover, the proposed solutions to solve the conflicts were executed in an automated manner by the simulated UAS, and supervised by human safety pilots. Figure 14 shows a timeline for the experiment of the use case 1. Both UAS were supposed to start their operations simultaneously (\(t=0\) s) according to their pre-flight generated plans, without conflicts. However, we simulated a delay of 3 s in the start of the UAS\({}_{1}\) operation. The Tracking module received periodically positioning information from both UAS and it updated the DB accordingly. The Monitoring module checked for conflicts periodically using the updated tracks from the DB and, at \(t=24\) s, it detected a future loss of separation conflict between the UAS. This was communicated to the EM, which ran an automated decision-making process (supported by the TD) to propose the optimal conflict resolution. In this case, an alternative flight plan was sent to UAS\({}_{1}\) through the USM module. Figure 15 shows the initial flight plans for the UAS and their reserved Operational Volume. Despite not having conflicts initially, the delay in the UAS\({}_{1}\) operation provoked an eventual loss of separation in the last part of its operation, which was resolved with an alternative flight plan. Figure 16 depicts the three options generated by the TD module and the optimal solution (in terms of risk and traveled distance) selected by the EM. In the experiment, the conflict was detected by the UTM system well in advance, and the total time between the detection and the communication of a solution to the USM took 0.13 s.  
Figure 14: Timeline of the experiment of the use case 1, where a loss of separation event is resolved. Single arrows indicate isolated interactions between modules, whereas double arrows indicate periodic communication. Figure 15: A top (**left**) and a perspective view (**right**) of the initial flight plans in the use case 1. The Operational Volumes are shown for both UAS. There are no conflicts given the UAS 4D trajectories. Figure 17 shows a timeline for the experiment of the use case 2. Both UAS started their operations simultaneously (\(t=0\) s) following pre-flight plans without conflicts. The Tracking module received periodically positioning information from both UAS, and it updated the DB accordingly. The Monitoring module checked for conflicts periodically using the updated tracks from the DB. We simulated a jamming attack over UAS\({}_{1}\) (\(t=12\) s) that was notified by the USM to the EM, which ran an automated decision-making process. In this type of threat, due to the involved risks, the EM decided to suspend the UAS\({}_{1}\) operation (notifying the USM) and to create a geofence around (updating the DB). Then, the Monitoring module detected (\(t=15\) s) a future geofence conflict with the UAS\({}_{2}\) flight plan, which was resolved by the EM (with the support of the TD) with an alternative plan avoiding the geofence.