# Implementing and Testing a U-Space System: Lessons Learnt
## 2 Interfaces
### The Application Programming Interface  
The Representational State Transfer (REST) API defined the way users--GCSs, UAVs and other clients--send requests or reports to the U-space, and how the information or instructions are received. Part of the calls defined in the API can be used to embed the communications requiring a visualization in the GCS if the Web app is not used. The rest is a reduced set that operators must use to integrate the GCS/UAV in the U-space environment (e.g., for position reporting). Figure 4 depicts the flow of messages between the different parts. The reporting of the position or status, like emergency warnings, could be sent to UTM by the drone, the GCS or both redundantly. The instructions arriving directly to the drone from UTM appear in italics because, following the ConOps guidelines, this was not supposed to happen; instructions should arrive to the GCS and be _wilcoed_ or rejected by the pilot. During the project, instructions were not sent directly to the drone, and the image only represents the possibility to do it. The UTM was also not sending  
Figure 3: INTA’s GCS posts: Pilot in command (**left**); U-space communications and payload (**right**, with Web app at bottom). Figure 2: Arquimea’s GCS embedded dialogs with the U-space. information to the drone, but in this case only because the platforms used during the project were not able to process it--an example would have been the presence of a sudden dynamic geo-fence. Requests could be sent from the GCS or the Web app, depending on the decision of the operators to integrate their system. Regarding reports, if only the GCS is used, its reports will include all kinds of them. If the Web app is used, the reports from it are only partially related to specific events like start or cancellation of the flights, or those that make sense to be performed by the pilot to add some specific information. But even if the Web app is used, position reports are expected to be sent from the GCS or the UAV automatically at least at a rate of one per second. The JavaScript Object Notation (JSON) [23] was chosen as the message format. In these data structures, one can add new fields as needed, not affecting the existing code, and any programming language has libraries to de-/serialize it. Its flexibility permits the use of different fields depending on the capabilities of the drone, or to refer to the same variable with a specific unit/format. It is human-readable and the logs can be easily processed to analyze the tests. To represent the trajectories, the GeoJSON standard [24] was selected. It allows for the definition of a sequence of mixed elements like points and polygonal or round areas that can be used to represent geo-fences or areas to scan. This versatile trajectory definition, rather than a classical flight plan containing a trajectory as a list of only waypoints, fits better to the flexibility that can be exploited when using drones. Another benefit of GeoJSON is the possible addition of several components to the coordinate vectors, which can be used to register the constraints or any other information related to a waypoint. During the flight plan request process, pilots would first send the trajectory they wanted to fly. On it, the coordinates of the waypoints would contain the components of longitude, latitude and altitude relative to the ground. The UTM would forward this trajectory to the path planner, which would return an optimized and deconflicted 4D trajectory based on the draft. In this new trajectory, the components of the waypoints would include sea level altitude, speed and time of arrival (ToA) (Figure 5). GeojSON was also used in the flight plan of the DACUS project [25], but in this case accepting only two plan types: trajectories as a list of waypoints or areas within which to fly freely. This format is not the first attempt to allow more flexibility in the definition of flight plans for drones; [26] proposes a flight plan specification to allow for the design of complex trajectories with repetitive and conditional sections.