Implementing and testing a U-space system: lessons learnt

Within the framework of the European Union’s Horizon 2020 research and innovation program, one of the main goals of the Labyrinth project, which ended on May 2023, was to develop and test the Conflict Management services of a U-space-based Unmanned Traffic Management (UTM) system. The U-space ConOps provides a high-level description of the architecture, requirements and functionalities of these systems, but the implementer has a certain degree of freedom in aspects like the techniques used or some policies and procedures. The current document describes some of those implementation decisions. The prototype included, at least in a basic version, part of the services defined by the ConOps, namely e-identification, Tracking, Geo-awareness, Drone Aeronautical Information Management, Geo-fence Provision, Operation Plan Preparation/Optimization, Operation Plan Processing, Strategic and Tactical Conflict Resolution, Emergency Management, Monitoring, Traffic Information and Legal Recording. Besides, a web app interface was developed for the operator/pilot. The system was tested in simulations and real visual line of sight (VLOS) and beyond VLOS (BVLOS) flights, with both vertical take-off and landing (VTOL) and fixed-wing platforms, while assisting final users interested in incorporating drones to support their daily tasks. The three-year experience developing and testing the environment provided many lessons at different levels: functionalities, compatibility, procedures, information, usability, ground control station (GCS) integration and aircrew roles during the mission.


Introduction
A safe use of drones sharing the airspace, same as with manned aviation, requires a management of the separation.This separation cannot always rely on the skills of the pilots, since many of the operations are expected to be BVLOS.Besides, the use of human air traffic controllers does not fit well with the particularities of the small drones and the city environment.A better option is to automate a UTM system.To harmonize such UTMs in Europe, under the European Union's (EU) Horizon 2020 research and innovation program, the CORUS project developed and published the U-space Concept of Operations (ConOps) [1], which would be regulated and adopted in April 2021 as the EU's UTM ConOps, entering into force on January 2023.U-space does not only address drone traffic management, but also other relevant aspects like safety, privacy, security, social acceptance, or co-existence of all Very Low-Level airspace operations, and its architecture is aimed at facilitating the proliferation of an entire industry around the offer of services provided by and for unmanned aerial vehicles (UAV).This is EASN-2023 Journal of Physics: Conference Series 2716 (2024) 012082 IOP Publishing doi:10.1088/1742-6596/2716/1/012082 2 permitted by its modular architectural design, which can be seen as a system of systems.Part of these systems are called services, and represent specialized functionalities.Services can be dependent on or could make use of other services.For a single U-space, these can be provided by different companies or institutions -therefore the need for the harmonization for a compatible market -, and do not necessarily have to run in the same infrastructure.In the Labyrinth project, two of the key U-space services were developed and tested: Strategic and Tactical Conflict Resolution.These help to provide the drone operator with a deconflicted trajectory based on their flight intentions, needs and other existing constraints (e.g., geo-fences, other traffic, obstacles).The Robotics Lab research group at the University Carlos III of Madrid (UC3M) developed the algorithms [2] to find a feasible path, which was returned as a 4D trajectory.One of the main goals of the project was to test these services while supporting the activities of final users willing to integrate drones into their tasks to increase efficiency.The use cases included: bird shepherding, runway inspection in airports, sanitary supplies delivery, evaluation of an emergency area, support for the evacuation of a mass of people, monitoring of loading activities and surveillance in maritime ports, infraction detection of car drivers and speed measurement of ground traffic.
DLR was responsible for implementing the minimum set of services, at least in a basic version, necessary to test the deconfliction algorithms in real scenarios, namely e-identification, Tracking, Geo-awareness, Drone Aeronautical Information Management, Geo-fence Provision, Operation Plan Preparation/Optimisation, Operation Plan Processing, Strategic Conflict Resolution, Tactical Conflict Resolution, Emergency Management, Monitoring, Traffic Information, and Legal Recording.This document collects experiences, needs identified and lessons learnt after three years of implementation and testing of the Labyrinth's U-space system, which was based on the first version of the ConOps.
The exposition has been divided into the different pieces of the environment, starting with the interfaces with the system, followed by the description of the services, and ending with the developments of the operators to integrate their platforms in the environment.These two Spanish operators were the Instituto Nacional de Técnica Aeroespacial (INTA) and Arquimea.First one providing and operating the multi-rotors in the tests and second one doing the same with their fixed-wing.

Web app
This interface allows the operator to manage the flights and the pilots to visualize the information and instructions from and send requests to the U-space.These communications can be also done using the API provided, and operators can implement the display of dialogues and information in their GCS.Fig. 1 shows this option, chosen by Arquimea.For this, operators must have access to the source code of the GCS software, which is not always possible, and this integration can be expensive and take time.Besides, embedding more elements could result in a cluttered screen.Instead, if the web app is used, it requires a dedicated screen, something to which the flight crew was reluctant.However, a benefit is that one member of the flight crew can take care of the U-space communications while the pilot flights manually or monitors the flight status, reducing the cognitive workload of the pilot, which is important in the case of flying swarms.This was the option chosen by INTA (Fig. 2).

The Application Programming Interface
The API defines 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 can be used to embed in the GCS the communications.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).Arquimea's GCS embedded dialogs with the U-space.JSON [3] was chosen as the message format.It allows to 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 [4] was selected.It allows the definition of sequences of points and polygonal or round areas that can be used to represent geo-fences or areas to scan.Another benefit is the possible addition of many components to the coordinate vectors, which has been used to register the constraints or any other information related to a waypoint.Concretely, these values were: longitude, latitude, altitude relative to the ground, sea level altitude, speed, and time of arrival (ToA).

The U-space services
The ConOps defines different types of airspace volumes and these require a different number of services.It also determines four deployment phases, which gradually add services to allow each step more complex operations.For simplicity, and due to space limitations, will just be indicated that the environment developed was addressed to the most restrictive Zu volumes.However, about the phases, being a research prototype oriented to test only some services in controlled scenarios, not all of the services of each phase were implemented before developing the services of the following one.It must be noted that many of the services could deserve their own project.The description of the implementation of these services has been ordered following the categories for these specified in the ConOps.

Identification and Tracking
• e-identification Service.The system must maintain updated information on the flights and, if requested, provide the different users -authorities, citizens, and operators -with different details depending on their data access privileges.Concerning drone tags in the web app, which was focused on the pilot's view, and being important to provide a decluttered screen, only the drone's unique identifier and some telemetry chosen by the pilots were displayed.An important value of it is the timestamp that indicates the moment when the telemetry was measured.Position reports were expected once per second, therefore a timestamp much older than that could mean a loss link event.However, users received a warning when the reporting frequency was not met.
• Tracking Service.Tracking is dependent on the Position Report Submission subservice, which receives and handles the reports with the drone telemetry during the flight.On these, some fields were mandatory (drone and flight IDs, origin -UAV/GCS -, 3D coordinates, speed, timestamp, security token) and others optional (e.g., uncertainty of the values, or source, like altitude from GPS, barometry or infrared).It is important to allow flexibility in the fields, since different platforms can provide different data or in different units and formats.In some cases, it can be solved with a conversion in the GCS or the UAV, but that is not always convenient.An example experienced was the attempt to estimate programmatically in the GCS the altitude relative to the ground, which resulted in great inaccuracies on uneven grounds, leading to fatal errors of altitude when the U-space had to modify the trajectories during the flight based on those estimations.The issue of the altitude references was the topic of the project ICARUS [5], which was running at the same time as Labyrinth.The lesson learnt was that it is better to work with the existing reliable data and handle or mitigate any related limitation in the services rather than interpolate or estimate the missing values.
While it was requested a minimum of a report per second, it could be considered to increase/decrease the frequency based on the speed or the traffic nearby.That would help to reduce the workload in the server, of special interest with high densities.Each of the reports triggers a good quantity of checks in different services, and the updates are broadcast to all connected users.Reports could be sent by the UAV, the GCS or by both redundantly.In this last case, the coherence between them was checked, which can help to detect spoofing.

Airspace Management/Geo-awareness
• Drone Aeronautical Information Management Service.It is in charge of keeping the map of existing geo-fences, whether static or dynamic.Dynamic ones can be created/deleted using the API or the web app, and have an associated duration, name, description, and a specific bottom and/or top altitude.The duration can be specified as a number of minutes since its creation or as a date timespan, which is useful to define temporary corridors for priority flights.• Geo-awareness Service.When a user logs in, receives all active geo-fences so that can be seen while designing a flight plan, and will receive notifications of new ones created or terminated.Apart from its informative role, this service also monitors that the UAVs comply with geo-fence avoidance or that they do not leave a geo-cage.If this happens, pilots receive a warning, and tactical deconfliction is triggered if necessary.For geo-cages, a friendly warning is first sent if the UAV gets close to the its limits.This service included the Geo-fence Provision Service, to directly inform the UAV of any existing or new geo-fence.

Mission Management
• Operation Plan Preparation/Optimisation.Using this service, operators can submit flight plan approval requests or cancel already approved ones.The web app allows displaying one or more trajectories in a 2D/3D map view that can be rotated, tilted or zoomed over a clean topographic map background or an orthophoto (it was used the CesiumJS [6] open source library for geo-spatial visualization).The trajectories are rendered as a list of waypoints.If one is clicked, the 4D constraints on it are displayed.These features are extremely useful for research purposes, for example, to analyse the separation decisions of the path planner.• Operation Plan Processing.It handles the list of pending flights and processes new ones.
In Labyrinth, operators sent their flight requests as a draft of the desired trajectory and a set

EASN-2023
Journal of Physics: Conference Series 2716 (2024) 012082 of preferences, and, if found, they received a feasible flight plan based on it.The flexibility of the trajectory design and preferences was determined by the path planning subservice.Such flexibility will be key to satisfying the needs of the final users.Labyrinth's path planner calculated trajectories for drafts defined as origin-destination, origin-area to scandestination (the planner returned a pattern to scan the area), or origin-list of waypointsdestination.However, it was learnt, after the exercises with the first responders, that the option origin-geo-cage-destination should be added.Geo-cages were requested when trajectories in the area could not be decided beforehand since they depended on the needs of each situation.An example would be a drone arriving at an area of interest to follow the unpredictable movements of a mass of people.When this service receives a new request for flight permission, after successful syntactic and semantic checks, adds the geo-fences and traffic affecting the requested trajectory at the moment of the flight, the drone capabilities -max.and min.speed, climb/descend rate, type (VTOL/fixed-wing) -, and forwards the request to the Strategic Conflict Resolution Service, which subsequently calls the path planner subservice.The planner returns, if found, a feasible and optimized trajectory with the hard constraints applied and the soft ones when possible.Paths are really treated like a tube by the planner, providing a radius of separation along it to consider possible relatively light and unavoidable deviations due to navigation inaccuracies or wind.The resulting flight plan is sent to the operator, who must check if it fits their needs and accept or reject it.To ease this decision step, it is important to provide a clear and informative display of the plan returned.Besides, the number of waypoints returned by the planner should be as reduced as possible, since some drones have problems loading or managing trajectories with a high number of points.

Conflict Management
• Strategic Conflict Resolution This service is in charge of returning deconflicted 4D flight plans, where the fourth component can be given by the ToA at the waypoint or the speed on it.Some drones are able only to try to comply with one of these constraints.This service depends on the path planner subservice, whose capabilities and flexibility will have a substantial impact on this and other services.In Labyrinth, the trajectory was not only deconflicted from the traffic and geo-fences at the moment of the flight, but it was also considered the elevation map of the area -a Digital Surface Model -.The availability of these maps is key for optimized and safe trajectory planning.No distinctions between the airspace users were implemented during the project, in the sense that, for example, the airspace was not partitioned in areas or levels for different UAV capabilities, and it was assigned in a first-come, first-served basis.But, when existing, these policies should also be taken as input by the path planner.
There was a difference between the plans calculated for the fixed-wing and those for the VTOL UAVs.The first waypoint for the fixed-wing would be at a certain altitude, and the drone would autonomously calculate the maneuver to reach it.Therefore, in this case, two segregated volumes around the take-off and landing points were considered, big enough for the aircraft to execute its climbing/descend maneuver.• Tactical Conflict Resolution.Some events could have an impact on the ongoing flights; aircraft unable to comply with the expected 4D constraints, malfunctions or sudden geofences (Fig. 3) are some examples.When this happens, thanks to this service, the affected traffic automatically receives instructions to avoid the conflict.This service also makes use of the path planner, which, together with the new constraints, should consider which kind of instructions is the aircraft able to execute during the flight due to its capabilities or status.The importance of this was seen while testing with a drone connected to the U-space via satellite communications (satcom).Together with Telefonica I+D, and the Network Technologies research group from UC3M, part of the project was focused on identifying requirements and suggesting an infrastructure -both ground and airborne -to support a reliable connectivity of the drones.A smart link switcher was developed [7], and DLR studied the impact of satcom users in the environment and the need for any special measure for them.From the tests, it was learnt that it should be avoided to send large portions of data, e.g., an entirely new trajectory, to a satcom-linked drone.In this case, only simpler instructions like changes in altitude or speed were feasible.Also important is to include in the conflict resolution procedure the estimation of the time for the instruction to reach, be accepted and applied by the pilot.An example is illustrated by the instructions to overwrite the remaining trajectory: if the first new waypoints are close to the current position, while the instruction is wilcoed and loaded, the drone could have overflown already the first new points, forcing it to backtrack.One particular tactical deconfliction situation appears when the operator needs to abort and change the current flight plan.This capability was fundamental for missions like those of the first responders, who must adapt their support to the development of the events.In those situations, the procedure decided was the following.First, the pilot requested a cancellation of the current flight.The UAV should be then kept hovering until the end of the procedure.Automatically after the cancellation request, a safety dynamic geo-fence was created around the UAV and any traffic affected was deviated.In the case of fixed-wings, the geo-fence size was tailored to give room to the holding loop pattern required by the aircraft.Pilots could then design and submit the new requested plan.After a successful approval process (i.e., no conflicts found), and before start executing it, they had to send a start-of-flight message.When doing it, the geo-fence was removed and they could start the new plan.With little practice, the aircrew got used to this procedure and executed it quickly.If they forgot to send the start-of-flight message, they received a warning when the safety geo-cage was left, so they could immediately solve it.A similar procedure was provided for those cases where the need was to stop and fly manually in the area without a predefined trajectory.Here, after cancelling the ongoing plan, operators would ask for a geo-cage, broadcasted as a new geo-fence to the rest of the traffic.When the area was segregated, the operator could start working inside it freely.

Emergency Management
This service was not developed in depth since non-nominal situations were out of the scope of the project.However, warnings were included to inform the pilots of relevant events.Besides, a warning message type could be used by pilots or the UAV autonomously to report any problem.If sent, it was broadcast to the traffic nearby and the web app showed the drone surrounded by a red cube representing a wider separation to provide a margin of time for a tactical deconfliction of close traffic.In the current implementation, the affected traffic is only re-routed when its trajectory conflicts with the mentioned emergency geo-fence, but future work could consider to start a preventive separation when a problem is reported in the area.

Monitoring
• Monitoring.As mentioned, different drones are able to comply with different waypoint constraints, like speed, ToA, or none of them.This conformance monitoring service would consider this while checking if they were met.With respect to the 3D position, a light deviation warning was sent when the aircraft came notably apart from the planned route but still inside a deconflicted tube reserved by the path planner around it.If leaving this tube, a severe deviation warning was sent, traffic around warned, and the tactical separation service triggered if conflicts appeared.• Traffic Information.Users receive constant updates on the positions of the close traffic, warnings, or information like flight cancellations and reason.In the web app, the icons of non-nominal flights appear with a warning icon, together with the mentioned red shield box.Lost link events between the UAV and U-space or the GCS appear with different icons in the flight strip.• Legal Recording.Communications related to the flights, events, user requests, and errors, were registered in log files to allow later analysis.These would also be used by the partner Austrian Institute of Technology (AIT) to train the algorithms that would detect unexpected values and therefore possible spoofing [8].AIT also developed a methodology to analyse the information exchange in the environment, identify weaknesses and weigh the impact of a possible cyber attack [9].

GCS integration 4.1. Fixed-wing
The main reason for Arquimea to embed the communications with U-space in their GCS was related to the peculiarities of fixed-wing takeoff and landing manoeuvres.During takeoff, fixedwing aircraft heavily rely on the wind at the precise moment of the manoeuvre, making it challenging to plan its trajectory well in advance.Moreover, there exists a transition period after take-off, during which the aircraft reaches the desired altitude and then follows the planned flight path.Predicting this transition accurately is complex.Similarly, during the landing manoeuvre, there is a transition between the last point of the flight plan and the beginning of the descent orbit.This descent orbit may be performed multiple times to achieve the desired altitude and start the landing phase.The management of these peculiarities was addressed by the GCS software.There was no need or reason to delegate it to the path-planner.The GCS would add the necessary manoeuvres to the trajectory returned by the Operation Plan Processing service.The processing of the JSON messages was straightforward thanks to the existing libraries for C#, being the only problem the incompatibility between some JSON field names and the variable names permitted in C#, which prevented an automated deserialization.

Vertical take-off and landing
INTA's aircrew was formed by a Pilot-in-Command (PiC), an external pilot, two payload operators (one of them also in charge of the U-space communications), one visual observer, the subject matter expert of the exercise (the final user) and a platform engineer.At a given moment, the PiC was managing up to three drones at the same time flying BVLOS, including communications with air traffic control, since the drones took off from the aerodrome Rozas Airborne Research Center (CIAR).However, INTA concluded that an improved integration would allow the PiC to assume also the U-space communication tasks.Examples of that improvement would be to automatically load the plan in the drone when the PiC accepts the route suggested by the Plan Processing service, or the automated loading in the drone of the commands when an instruction is wilcoed by the pilot.

Conclusions
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.Some particular needs were identified.If a definition of the messages between U-space and the drone/GCS was agreed, with the expected information, units or format, manufacturers could provide tools or functionalities oriented to ease the integration of their drones.Another request was to clearly define the procedures and responsibilities in the event of contingencies.And an important pending work regarding tactical deconfliction is to consider the battery level, that way it could be avoided to send to the drone instructions that could result in an emergency procedure.
With respect to the graphic interface, its usability, flexibility and a clear display of the relevant information and events, will impact the mental workload of the flight crew and how quick can tasks be performed, which will be key in the case of operating swarms.In this regard, the feedback of users is fundamental.Therefore, a successful development should go hand in hand with operators, pilots, and GCS developers, being this the best way to identify needs and constraints at all levels.

Figure 3 .
Figure 3.The pilot receives a deconflicted trajectory if affected by a new dynamic geo-fence.