# Implementing and Testing a U-Space System: Lessons Learnt
## 6 Discussion  
The development of the U-space prototype, and especially testing it in different use cases, provided valuable knowledge of the needs of final users, operators and pilots, limitations and capabilities of the drones and challenges of the environment and missions. The experience showed that, to facilitate different kinds of operations, the system must provide flexibility, both to design the plan and to modify the ongoing flight. The implementation must be able to adapt its services to the heterogeneity of UAV platforms with different capabilities, especially with regard to the differences between VTOL and fixed-wing. Concretely, the versatility and performance of the path planning sub-service will have a great impact on the system, from allowing the operators the definition of trajectories that fit to their needs to, depending on the way the separation is managed, the capacity of the airspace. The decision to automatically optimize the paths, receiving from the operators drafts of plans that could be as simple as origin and destination, and returning a detailed 4D trajectory, fitted perfectly with the needs of users like first responders, since sometimes they need to rapidly design and submit a plan during critical situations when a slow manual optimization is not an option. If a definition of the messages between U-space and the drone/GCS was agreed upon, with the expected information, units or format, manufacturers could provide tools or functionalities oriented to ease the integration of their drones. An example is the case of the capability to execute a 4D trajectory. INTA used their own implementation to comply with the speed constraint in the waypoints, since the M600 did not have this capability. The new DJI Onboard Software Development Kit (OSDK) version 4.1.0 for the M300 drones acquired during the project already provided this functionality (\"M600 and A3/N3 only support OSDK 3.9 or below; [...] M300 RTK only support OSDK 4.0 and above.\" [33]); the new firmware not only makes it possible to associate constraints to the waypoints but also actions [34]. However, since INTA used the same software to control all drones, it was fitted  
Figure 32: Megaphone used in the Matrice 600 to guide a mass of people to escape from a danger. to the case of the M600, preventing it from taking full advantage of the new capabilities of the SDK 4.1. To implement the 4D capability, the position of the drone was monitored and, when it reached one of the waypoints of the flight plan, the speed was adjusted to that expected. One feature leveraged, already present in the version 3.9, was the auto-landing. And another to remark in the last version is the possibility to modify the home-point during the flight, which provides flexibility for the design of contingency plans. A pending work regarding tactical deconfliction is considering the battery level to avoid sending instructions to the drone that could result in an emergency procedure. Another request was a clear definition of the responsibilities related to actions and decisions in the event of contingencies: when and how can one expect support or coordination from U-space? When should you act unilaterally, even if it would imply a risk due to some lack of information? Also guidance to design the contingency plans during the flight plan creation is needed. If the operator wants to determine a safe landing point in case of failure, they could only use the clues of an orthophoto, which could be outdated. And the picture does not provide information of elements like the presence of cables or if it is an area where people can be present. An emergency management service should meet these needs. In the current implementation, given a contingency, the traffic around is considered affected and re-routed only when its trajectory conflicts with the generator of the event. Future work could consider a more preventive separation if a problem in the area is reported.