3.1. Urban UTM: Problem Definition and Research Questions
Current regulations for operating unmanned aircraft systems (UAS) in a low-level flight environment are quite restrictive. In Ireland, similar to other countries, these include restrictions on drone flight operations in controlled airspace surrounding airports, as well as restrictions to remain below 400 ft and not fly further than 300 m outside of one’s direct line of sight with the aircraft [46
]. It makes perfect sense for a human operator to have control over the drone when the drone is operated in the visual line of sight, since the operator can see the drone as well as other objects, such as buildings, a nearby powerline or a group of people on the ground or, indeed, any other drone operating in the vicinity. However, there is an increasing demand for additional services and benefits by enabling drones to operate beyond the visual line of sight (BVLOS) and carry out a range of data gathering, logistical and specialist commercial services. However, as soon as the physical visual connection between operator and drone is broken, there needs to be a way of assessing and controlling where the drone is, where it can go and what it can do and to do this in a safe, responsible and regulated manner. These systems also need to be able to handle not just single BVLOS drone flights but potentially multiple drones in relatively close proximity. There is a pressing requirement for a comprehensive system to handle the overall management of BVLOS drone traffic in environments, including over cities and towns. The U-Flyte high-level conceptual overview of an Urban UTM, as shown in Figure 2
, includes foundational, operational as well as regulatory and governance layers. The main focus of this paper will revolve around the operational layer shown in Figure 2
The required operational capabilities and functions of a modern day urban UTM platform are manifold. One key requirement is a knowledge of the very low level (VLL) urban airspace with a clear indication of where drones can or cannot fly at any particular time. The UTM needs to know the location of all current airspace users at any one time, as well as examining planned and real-time journeys in order to be able to organise traffic and manage any potential conflicts. The UTM needs to be able to monitor the progression of traffic and communicate with the airspace users all of the time. The UTM needs be able to intervene in an emergency event and to handle such a situation in real-time whilst minimising the impact on the rest of the un-affected airspace. In short, the UTM needs to understand all relevant environmental information and dynamic inputs in order to be able to manage traffic and enable the safe and responsible operation of drones over cities and towns.
Key challenges associated with developing an urban UTM platform:
Understanding the key risk characteristics associated with an urban UTM;
Ground and air risk;
Designing an airspace model that will support urban UTM operations;
Architecture and structure;
Developing urban drone traffic management;
Ability to carry out deconfliction, optimisation and emergency event handling in real-time 4D;
Development of a configurable, computationally scalable, highly automated UTM system that can be adapted for any city or urban environment.
Other key aspects underpinning urban UTM include; training and qualifications, drone registration, weather information, micro-climate models, as well as a dependable onboard detect and avoid (DAA) system, ground-based VLL airspace monitoring, auto-landing/take-off systems, ATM integration, communication network and navigation services, which are also required but will not be explored in this paper. These challenges provide the rationale underpinning the research described in this paper, which can be grouped under three headings:
Environment and Operational Data: Identifying, collating and analysing relevant data inputs that can be used to design airspace architecture.
Airspace Architecture: This is the multi-dimensional map or graph indicating where drones can or cannot fly, how airspace is structured and how drones can navigate through this space.
Drone Traffic Management: Drone traffic management comprises three core dynamic traffic features: safety tube for drone trips, optimised pathfinding incorporating strategic/tactical deconfliction and emergency event handling. All of these activities need to be capable of operating in 3D airspace in real-time (i.e., 4D environments).
These challenges are formulated into three broad research areas: urban VLL environment characteristics; airspace architecture; traffic management systems. Each of these three areas comprises a number of topics, as shown in Figure 3
, each of which is explored and presented in more detail in the following sections. The initial results of U-Flyte’s urban prototype UTM platform simulator, which was constructed and tested using the concepts developed from this research work, are also presented.
3.2. Pragmatic Approaches to Addressing Risk Aspects Associated with Urban UTM Operations
The fundamental characteristics underpinning any UTM airspace architecture are the digital geospatial representations of the VLL real-world environment and the set of rules and protocols that govern all dynamic operations and activities in order to maintain the integrity and safety of the airspace. Secondary concerns include the privacy, nuisance and environmental issues associated with drone activity, but these aspects will not be addressed in this paper. The main source of risk revolves around flying several unmanned aircrafts simultaneously over a busy, populated and built-up environment. This overall risk can, in turn, be classified into two main risk sources, namely:
Risk modelling for drone operations over urban environments has not been adequately investigated nor have any suitable protocols, standards or methodologies, that address the highly complex environment of dense drone traffic operations over cities, been developed. Computing ground risk for urban drone operations can be challenging, since many variables, such as infrastructure and human activity, have to be taken into account. These variables are usually present in one form or another throughout the metropolitan area and one extreme might be to identify all vulnerable zones on the ground (e.g., residential areas, industrial sectors, schools, shopping districts, sports-fields, recreational parks, etc.) and apply strict or indeed gradated no-fly zones. However, this is not practical, since it is likely that this approach will result in the entire city or a significant part of the city being de-marked as non-flyable.
Air risk is somewhat easier to understand, since this relates to how drones can travel without colliding into obstacles or other aircraft. Urban drone operations are likely to be characterised as comprising trips that are short to medium distance (1–25 km in length). Drone traffic numbers in urban UTMs are projected to vary from between hundreds to thousands of movements per hour within relatively compact urban areas (e.g., 20 km × 20 km). Sensing, navigation and computational technologies, both onboard as well as on the ground, will provide redundant monitoring systems, ensuring the safe operation of numerous drone journeys over these populated urban environments.
At the heart of issue is the safety and reliability performance of the drone itself in the context of the unique ground and air risk characteristics of urban operation. It is proposed that drones should be required to conform to a minimum level of operational and flight performance. A special urban “certificate of airworthiness” should be required that sets out the minimum operating and flying standards of the drone, including flight performance (airframe, propulsion, payload), system redundancy (navigation, communication, DAA) and special safety features (in the event of ground impact), before that drone is cleared to operate in an urban environment. This process could follow the EASA’s recent Proposed Means of Compliance for (people-carrying) eVTOL [47
3.3. Data Inputs Underpinning Urban Airspace Architecture
The objective of any urban UTM platform is to ensure that the maximum urban airspace can be made safely available, based on an in-depth and comprehensive understanding of the underlying VLL aerial environment. This same digital platform will need to handle changes in national legislation and local municipal regulation, as well as address the concerns of a local residential association or, indeed, a citizen. Ground risk comprises all objects and activities which are located on the ground—some of these objects and activities can pose risk and act as a hazard to drone operations overhead and, conversely, drone operation can pose hazard to these same objects and activities on the ground below. Topography, infrastructure, buildings and human activity will generally have a multi-dimensional spatial–temporal attribute in the form of a 3D buffered polygon, which represents how these objects affect and are affected by drone operation. A simple example is a tall church spire, which extends into the air but only presents a hazard to the maximum dimensions of the spire (width, length and height) and, unless identified and clearly demarked, may pose a hazard to overflying drones, as shown in Figure 4
a. In the converse scenario, a large, flat and busy recreational park in the city centre is vulnerable to overflying drones and may need to be represented by a buffered 3D polygon which extends vertically to the maximum altitude of the urban airspace, as shown in Figure 4
a. This 3D polygon may also have additional temporal attributes, indicating when it may be open to the public and active. Modelling risk in terms of ground objects that pose hazards to drones is usually straightforward, since most times their location and dimensions are known. However, the modelling risk of vulnerable ground-based areas and activities across cities and urban spaces is problematic, since a drone will never have to fly far without overflying these locations. Additionally, vulnerable, real-time human activity is not always easy to locate precisely across a metropolitan area.
The research team has taken a pragmatic approach here, based around the premise that only certified drones cleared for operation over urban areas will be allowed to fly over cities and towns. A different approach to addressing ground risk is proposed, which still involves collating relevant datasets, such as topography, airspace, property classification, etc., as shown in Figure 4
b. These geospatial datasets are stored on a collaborative cloud-based urban airspace platform, designed by the U-Flyte research team, which enables hazards to drones (e.g., hilly terrain, tall buildings) to be located and identified. Other zones that require permission due to some security or safety concern can also be identified. This digital platform enables all relevant stakeholders, including aviation authorities, municipal councils, city managers, UTM service providers and commercial drone fleet operators, to visualise the VLL airspace and use this collaborative platform, perhaps initially primed with some legislative rules and guidelines, to ultimately decide where/when drones should and should not fly.
The university town of Maynooth (location of the U-Flyte research team) in Ireland, was used as an initial urban UTM test-site. This town is located 25 km west of the capital Dublin, has a population of almost 15,000 and is approximately 3.5 km × 3.5 km in extent, with a train station and busy roads, as well as business-parks, industry hubs and a retail shopping centre. A first step towards developing a model of the airspace that is available and not physically occupied is a high-resolution digital representation of the ground. A digital elevation model (DEM) with a resolution of 1 m was used to build a sufficiently detailed picture of the ground and its permanent features, as shown in Figure 5
Most of the buildings in Maynooth are <10 m in height, with some extending up to 20 m; however, the spire of the university chapel (south campus) extends 83m above ground level. Some aspects to consider when choosing a DEM include the cell dimension, which ideally should be <10 m, and ensuring that the height in that cell represents the highest point within that cell. Some part of the urban DEM may require greater spatial resolution, such as busy take-off/landing zones or more congested downtown areas. The DEM should have been recently acquired (within 1 year) and incorporate additional data sources, such as low-level obstacle databases, usually available from aviation authorities. It is likely that the drones themselves, operating within an urban UTM, will play a key role in updating accurate ground-based data, similar to the concept of self-healing maps proposed for autonomous vehicles. European Copernicus 10 m resolution Sentinel-2 satellite data were acquired and processed to produce a recent Normalised Difference Vegetation Index (NDVI) image-map, as shown in Figure 5
b. This image-map distinguishes between vegetated (green) and non-vegetated (yellow, red) areas and is very useful in highlighting open green areas, built environments, water features and road networks.
Additional GIS datasets (e.g., administrative boundaries, land-use, ownership, etc.) can be acquired and, together with DEM and NDVI data, analysed to classify and categorise the urban area into different ground or more detailed land-use classes, as shown in Figure 6
a, such as residential, educational, recreational, retail, industrial and transportation. Some of these classes can be further sub-divided (e.g., a residential zone can be further sub-divided into housing and green areas and streets), as shown in Figure 6
One relatively new data layer that will play an increasingly important role in urban UTM is near real-time human activity. Although demographical data, such as census datasets, are useful, these data are static, representing a single snapshot in time and do not necessarily reflect the patterns of daily activity or what citizens are doing in real-time. The U-Flyte team are currently collating general data protection regulation (GDPR) compliant data from third-party data providers, including mobile phone (e.g., Call Data Records) and personal devices companies, such as the sport and activity tracker Fitbit. These human-activity datasets, some of which are available in near-real time can be aggregated into anonymised, GDPR-compliant activity indicators, that provides very useful spatial-temporal information of human behaviours and patterns associated with typical day-to-day work, school, recreation, sports, retail and travel activities across the city. This aggregated, anonymised activity can be fused with other datasets (e.g., public event databases) to highlight vulnerable zones (e.g., busy outdoor sports venues which might be active in the evenings). Figure 7
details human recreational activity (walking and cycling) around the town of Maynooth and the Maynooth University north campus (in more detail).
3.4. Fundamental Building Blocks of Urban Airspace
It is reasonable to expect that most drone trips in urban airspace environments will be at least 1 km in length, overflying tall buildings, infrastructure and trees. It seems more sensible to compute the shortest path for planned drone trips, maintaining level flight wherever possible and avoiding the need to climb or descend in order to avoid obstacles. For this reason, a minimum flying altitude for horizontal flight of 50 m above the chosen vertical datum is proposed. This minimum flying altitude should also help support societally friendly and non-invasive operation, reducing potential privacy concerns and noise pollution. Below this 50 m cut-off plane (base of travel layers), only vertical movement (climb or descend) for take-off and landing is permitted, as shown in Figure 8
. This base height value may vary between different cities. This altitude needs to be fixed to an accepted standard vertical height datum, such as barometric QNH, since ground level topography can vary over relatively large city and urban extents. This base-layer altitude can be viewed as a geometric plane that separates the more undulating topography and buildings on the ground from the open airspace higher up. Note that some taller buildings will penetrate this base-layer and 50 m has been initially chosen as a compromise between maximising horizontal flight airspace whilst safe-guarding drones from multi-story buildings, as well as helping address privacy and nuisance concerns.
A cloud-based, collaborative urban airspace platform has been developed by the U-Flyte team that enables all relevant static and dynamic datasets to be collated, ingested and analysed. A more pragmatic approach has been adopted by the U-Flyte research team concerning ground risk, as outlined in preceding Section 3.2
, since it is pervasive within urban environments with real challenges in monitoring and measuring real-time human activity. The emphasis on mitigating risk should switch to ensuring that any drones flying over cities have a high level of operational and safety performance, which can be implemented through a similar process, such as acquiring a certificate of airworthiness, but adapted for urban BVLOS drone operations. Nevertheless, there are still locations or zones on the ground which will have varying levels of permissions in terms of accessibility and operation. Three zone categories have been identified: no fly zones (NFZ); prior permission zones (PPZ); temporary reserved zones (TRZ). These three airspace zones, together with the vertical flight and travel flight layers (base-layer and top-most altitude limit), make-up the accessible airspace over the metropolitan region, as shown in Figure 8
No Fly Zones (NFZ):
In most cities few buildings reach higher than 50 m and a minimum height thus removes most permanent physical structures from interfering with the space for horizontal travel. At the same time, it is true that 50 m is not high enough to exclude all buildings. In this case there still will be zones which physically obstruct the airspace (i.e., it is impossible for a drone to fly through that space and those zones need to be stored as strict no-fly zones within the UTM database), as shown in Figure 8
. The DEM layer can be used in conjunction with land-use and property-class data layers to identify NFZ features. It is also worth noting that there are NFZ features that are of a temporary nature, which also potentially pose an obstruction above the 50 m limit. For instance, cranes at a construction site can easily reach a height of 70 to 80 m. Urban airspace NFZ databases will need to be updated on a daily basis or, indeed, as soon as the new obstacle appears on the skyline, a process which could be carried out by the drones themselves.
Prior Permission Zones (PPZ):
The drone also poses a risk and is a hazard to everything on the ground in terms of the probability of exposure, vulnerability and severity as it flies above. Prior Permission Zones (PPZ) are zones where, unlike a physical tall building, it is possible to fly into the space, but it may not be desirable, so prior permission is required. Reasons could include safety, security or, indeed, privacy or nuisance concerns. The data layers on this UTM platform, such as property type and human activity can be queried. For example, selecting all green areas that are >1 ha, classified as recreational and have high levels of human recreational activity, can be highlighted. These could then be examined by a UTM airspace designer to determine whether this area is a potential PPZ or not, based on current regulations and guidelines. PPZs could include areas over hospitals which have active helicopter landing pads, prisons or large sports stadiums. So, in the example of the hospital PPZ, general drone traffic would not be allowed to pass through this zone, since it is reserved for Medical Helicopter emergencies by default. However, a drone delivering blood or medical supplies specifically to this hospital could be granted permission to enter the PPZ by the hospital management team. Other examples of PPZs include the airspace over sensitive infrastructure, such as power plants or government buildings where drone traffic could be prohibited for security reasons, but also over vulnerable zones where drone operations could result in substantial damage to valuable infrastructure and injury/fatalities (e.g., airports, pedestrianised streets, large recreational parks or sporting events), as shown in Figure 8
Furthermore, PPZ can be temporary in nature. For instance, a PPZ could be activated for the duration of a concert at the weekend but then deactivated during weekdays. Different stakeholders and inputs are required to help decide which zones should be designated PPZ in an open and fair manner. The U-Flyte team has developed an online “Mark-up” tool, shown in Figure 9
, that enables registered users to search for specific locations and facility types (e.g., “large schools”) overlain on the latest high-resolution satellite or aerial image of the city. The user can then confirm the extent of the PPZ, as well as temporal restrictions (e.g., school only active on weekdays between 8:00 a.m. and 5:00 p.m.).
This ground-based polygon can then be extruded, using the Mark-up tool functions, into a three-dimensional object that covers the airspace above the ground feature, which it aims to protect. The 1-to-1 rule, can be applied in this case, as outlined in the SORA (Specific Operations Risk Assessment) guidelines, which stipulate that, for a drone operating at an altitude of 100 m above the ground, the ground risk buffer should be at least 100 m. This process should be carried out using an intuitive collaborative platform with ready access to relevant geospatial data layers together with national legislation and city regulations, (e.g., a housing association could decide that they do not want high volumes of drones flying over their location, and so establish a PPZ over their housing estate). The initial choice and design of PPZs could be conducted by the appointed UTM service company prior to inviting the wider stakeholder group to participate.
Temporary Reserve Zones (TRZ):
Conversely, Temporary Reserve Zones (TRZ) are locations or zones where the exposure and vulnerability on the ground is particularly low, with little or no vulnerable infrastructure and very low levels of human activity on the ground. Examples include enclosed industry zones, brown fields and waste field sites, as shown in Figure 8
. TRZs are, therefore, zones where drones could be directed to hover or orbit over, in order to free-up space during an unforeseen external event or in the case of an emergency or malfunction to land. TRZs can be treated in a similar fashion to PPZs but are more likely to be left as open accessible airspace and only flagged as restricted in the event of an emergency. TRZs can be identified and stored using the same online collaborative Mark-up tools, protocols and methodology, as for PPZs.
U-Flyte’s UTM airspace mark-up tool has been developed using scalable cloud-based intuitive interfaces, based around an open source database and geospatial tools, enabling large numbers of stakeholders and users to collaborate and identify candidate NFZs, PPZs and TRZs, check suitability, discuss concerns and find solutions. A key role of this mark-up tool is to ensure that urban airspace, comprising these UTM zones (NFZ, PPZ and TRZ) can be constructed efficiently, as well as in a fair, transparent, democratic manner.
3.5. Urban Airspace Architecture
An urban UTM needs to be able to understand and manage all aspects within the airspace, as these relate to ensuring safe and efficient drone operation. Overall, drone traffic management is influenced by a number of inputs, including assigned mission or aerial task, accessible airspace, existing traffic, as well as overall drone operational performance. The UTM needs to be able to determine an optimum path for a requested trip, assign that track to the drone, track the drone’s progress and intervene in real-time, if necessary, in order to quickly adapt or possibly change the drone’s itinerary. The available or accessible airspace is determined by the operating lower and upper urban airspace limits, together with the three UTM zones—NFZ, PPZ and TRZ. Aspects that need to be considered include the spatial and temporal separation of drones, which should strive to balance safety requirements with operational efficiency. Involving human operators to control drones is not advisable for urban UTM scenarios, which may have to deal with tens and hundreds, if not thousands, of drone movements in an hour over densely populated, high-activity city areas. Having a human operator assigned to each drone on the ground, as well as potentially multiple UTM service providers and associated traffic coordinators, handling or overseeing various requests and instructions, will result in a slow and in-efficient traffic management system or, even worse, possible collisions and serious accidents, as shown in Figure 10
. Does the drone operator send a request to one or more UTM service providers for flight slots? Are instructions issued from the UTM service provider to the drone operator who, in turn, manoeuvres the drone?
It is more advisable to take the human out of the loop—not only the drone operators but also the air traffic coordination function—since it will be more efficient and safer for a machine or digital UTM system to collate all relevant data, consider all inputs, analyse options, compute paths and handle real-time issues, such as potential traffic conflictions, as these arise. These instructions can be issued directly to the drone platform. In effect, the urban UTM platform operates the drone on behalf of the drone operator, but under the watchful eye of the drone operator/fleet managers. In this case the UTM needs to be able to compute a suitable path that avoids all NFZs and PPZs within the system. Secondly, the UTM needs to have a mechanism to avoid paths that have already been allocated to other drones, which may intersect the proposed path at various locations and possibly at the same time. Hence, in order to manage air risk effectively, it is essential that the UTM has full knowledge of all airspace users at any one time. A strategic deconfliction approach is required where the path-finding algorithm is computed for the new drone prior to taking off, to minimize the possibility of interference with other existing flight trajectories. This path is computed and uploaded to the drone before take-off. The path comprises a set of vertices or nodes, along which the drone has to travel, passing through key nodes at pre-set times. This route calculation needs to take into account the drone’s speed profile and current weather conditions, such as head or tail winds.
Note that this process has to handle several competing interests in terms of safety, economy, flexibility and computability that need to be addressed. Safety refers to the spatial separation of the airspace users, economy is choosing the most cost and time efficient routes, flexibility is the ability of the system to make full use of the available airspace and to not be confined by a small number of fixed, predefine routes or corridors, whilst computability means that the system is not overly complex and solutions can be computed in a relatively short time. The spatial nature of the paths should be computed, not only to ensure that these are as direct as possible and without unnecessary heading changes, but to ensure that they are also optimised in terms of travel distance, travel time, arrival time and departure time.
A natural approach to the problem is through the use of a graph network of nodes and edges. Nodes are locations or points where drones are allowed to change direction, while edges are the lines along which drones travel from one node to another. This is akin to the model of a road network comprising streets and crossroads. Nodes and edges can be flagged as un-available at times when they are known to be occupied by a drone or blocked by a NFZ or PPZ, in which case they become unavailable in the path-finding process for the next drones that wish to enter the system. Then, a variation of Dijkstra’s algorithm or an A* algorithm, with respect to the preferred optimisation criteria, can be used to identify an optimal path. The restrictive structure of such a network supports the safety aspect as it introduces an immediate separation between the edges—that is, the places where drones are allowed to travel. Additionally, a pre-defined network structure ensures that the path-finding process is more deterministic and predictable. However, there are obvious drawbacks with a graph network with various advantages and disadvantages in terms of flexibility in path-finding and computational efficiency that will not be detailed here. U-Flyte research has found that key graph requirements of an urban UTM include:
Efficient pathfinding: the ability to construct a path between any two points in the airspace that is as direct as possible, given the NFZ, PPZ;
Spatial–temporal separation: any computed path needs to be adequately spatially and temporally separated from all other drones throughout its entire journey;
Use of the third dimension for deconfliction: given that the possibility of paths intersecting in a busy urban UTM is quite high, the ability to utilise the third dimension is required (i.e., for one of the drones to climb or descend) in order to avoid a traffic conflict.
So, the UTM airspace structure solution proposed by the U-Flyte research team is to create a number of layers (15 m in height) to be stacked vertically from the minimum 50 m lower-level cut-off plane. Assuming an initial urban UTM maximum height of 150 m, this results in three pairs of layers, as shown in Figure 11
. Each pair of layers comprises a travel layer for standard transit and a deconfliction layer, which enables a drone to jump over a potential existing path and avoid a traffic conflict.
The length and duration of a drone’s planned trip determines which layer pair the drone is assigned, so short trips are allocated to the lowest of the three travel layers, while medium-distance and long-distance trips are allocated to the middle and upper travel layers, respectively. The aim here is to distribute traffic as much as possible across the layers from the outset and thereby reduce the likelihood of conflict.
3.6. Urban Drone Traffic Management
Four key features of urban drone traffic management, which have been investigated and developed by the U-Flyte research team, are presented in the following sections, including safety tube, strategic deconfliction, tactical deconfliction and emergency event handling
3.6.1. Safety Tube
A drone’s path is a sequence of spatial–temporal nodes, comprising latitude–longitude–altitude coordinates, which the drone has to fly through at a prescribed time. This path is uploaded to the drone prior to take-off and it is the responsibility of the drone to adhere to this path, flying through each given node at the given time. However, drones may not always be able to adhere exactly to the given itinerary. It is apparent that delay is more likely to occur than reaching points ahead of schedule, since it is easier to correct the latter by slowing down if necessary. Delays may be more difficult to correct since these could be caused by a strong headwind, not picked up in an earlier forecast and the drone propulsion’s system may be insufficiently powerful to correct this lost time. Additionally, it is highly probable that a drone will never fly the exact path down to decimetre or, indeed, metre accuracy. Therefore, a spatial and temporal safety margin, or tube, is required for drones to handle these spatial–temporal inconsistencies. An initial examination, based around typical drone dimensions (3 m × 2 m × 2 m), suggests a tube with a radius of 10 m. Furthermore, the tube should be active for at least 15 s before and 60 s after the drone’s scheduled passing. This means, assuming a speed of 20 m/s, the length of the tube is 1500 m, comprising a leading segment of 300 m and a rear segment of 1200 m, as shown in Figure 12
This safety tube cocoons the drone and travels dynamically with the drone as it moves along its path, creating a safety margin of up to 75 s for any point along the planned path. The drone’s ideal location within this safety tube should be in the upper 20% segment (or in the first 15 s of the total 75 s) of the tube. The planned path and real-time location of the drone, together with the accompanying safety tube is logged and it is this dynamic real-time drone safety tube that is treated in a similar fashion to a NFZ. The progress of each drone is monitored by the drone itself, using its onboard flight-controller, and the drone will only alert the UTM if it is in danger of falling behind and exiting this safety tube. The benefit of this approach is that the drone can be left unsupervised if it remains within its safety tube. So, even if the drone were to fall behind by 30 s during its journey, it would not matter to the safety integrity of the system, and so minimal resources need to be spent on constantly checking on the drone’s progress or adjusting its itinerary. The final dimensions of the safety tube are subject to further testing and ultimately depend on characteristics of the Urban UTM and individual drone performance, which are linked to the likelihood of drones being delayed and causes of the delay.
3.6.2. 4D Path-Finding and Strategic Deconfliction
Requests for drone paths may be submitted by drone service providers who have a current approval for Urban UTM operations and suitably certified drones that are registered with that Urban UTM. These requests may be ad-hoc for a one-off trip or scheduled for a later time during the day. Each request is dealt with sequentially and on a first-come-first-served basis. The only exception here might be drones which carry out medical or emergency support functions, which may be pushed-up to the top of the list. In any case, every request is examined with respect to the existing NFZ and PPZ and all other drone journeys, which have been accepted and assigned by the UTM system.
Every request for a new path must contain a start point, an end point and a start time. The distance between the start and end point is used to determine the travel layer the drone is allocated to. Short trips are assigned to the lowest layer, while longer trips are moved further up. So, the first part of the drone’s path is the vertical connection from the take-off point up to the relevant layer. Note how this part of the journey cannot involve any NFZ or PPZ. However, drones that are scheduled to fly right above the take-off point may have to be circumvented. If this is not possible, the departure has to be delayed. At the core of the pathfinding process, we aim to find a suitable path within the relevant layer. We use a classic A* algorithm on an expanding network of possible paths. Initially this network only consists of the direct line from start to end point—as projected into the layer. Next the heuristically most promising path is examined in the current network, with respect to the existing NFZ and PPZ and all other drone journeys which have been accepted and assigned by the UTM system. If no conflict is found, then the path can be accepted as the most suitable path. If, for instance, the direct line from start to end point shows no conflict, then a suitable path has been found, as depicted by the green line in Figure 13
If a conflict is returned, then the path is rejected and replaced with alternative paths. The network grows and develops in this way, resulting in more elaborate paths until a trip solution has been found which offers a conflict-free journey from the start to end point. Travel distance is the main cost function, however other heuristics are possible, such as arrival time or travel time, or a more elaborate weighted combination of different indicators.
Two questions remain: “How do we check whether a path is conflict-free?” and “What are the proposed alternative paths if conflict is found?” Recall that a path is a sequence of nodes, beginning with the start point and concluding with the end point. A node in a path is classified as confirmed if the portion of the path from the start point to that node has been established as conflict-free. In this sense the starting node is always confirmed and a path is sought in which the end node is confirmed.
At any stage during the A* process, the heuristically most promising path contains n nodes, where n ≥ 2, and the first i ≥ 1 nodes are confirmed. Given such a path, the pathfinding process aims to confirm the (I + 1)-st node—that is, the edge Ei between nodes i and i + 1 is checked to ensure that it is conflict-free. It is a simple geospatial operation to check whether Ei intersects any of the polygonal NFZ and PPZ of the relevant layer. Furthermore, as the start time and speed of the drone are known, the time the drone is expected to reach node i can be determined. Likewise, the drone’s temporal progression along the edge Ei is known. The database can be queried to check whether Ei intersects the path of any other drone and, if so, whether this spatial conflict is also a temporal one—that is, whether the other drone’s safety tube is active at the relevant time. If no conflicts with the NFZ, PPZ or other drones are found, then node (i + 1) is confirmed and the next subsequent edge is considered. If, on the other hand, conflict is found, then edge Ei and the rest of the path are dismissed.
Conflicts associated with NFZ and PPZ:
If the conflict arose from a NFZ or PPZ, then the drone has to be routed around this zone, either to the left or the right of the obstruction. In the case of a building, a third option of flying above the obstacle by climbing temporarily to a higher layer is also available. In the database NFZ and PPZ are stored together with their respective convex hulls. There are at least two ways in which to connect the confirmed portion of the path—that is, the segments from the start node up to node i, with the end node, while also avoiding the NFZ or PPZ. This sequence of edge construction and testing, in order to find an efficient path around the NFZ or PPZ, is detailed in Figure 14
Conflicts associated with existing drone trajectories: If the conflict arises from another drone in the same layer, then a new node is introduced before the conflict followed by a bridge segment that leads up to the deconfliction layer and descends back down to the travel layer after the other drone’s path has been jumped. Depending on how long the other drone’s safety tube remains active, an alternative path that passes behind, or indeed ahead of the other drone, may be worth considering. Another option, though not currently part of our implementation, is that the speed profile or departure time of the first drone may be adapted to resolve the current conflict in this way. Finally, if a bridge segment cannot be confirmed due to traffic already in the deconfliction layer then nodes that lead around this area of contention are introduced, similar to the NFZ/PPZ case discussed above.
An additional step that checks whether new paths are not unnecessarily circuitous has proven beneficial. Finally, for each new path, the cost function is calculated, and the path is added to the ordered list of all proposed paths, which is then available for the next A* cycle. This algorithm then runs until a path with a confirmed end node has been found. It may not always be possible to end up right above the landing point, due to existing traffic. So, additional pathfinding may be required to ensure that the drone reaches an overhead point which is as close as possible to the target landing zone. Thereafter, it is a more localised problem to ensure the descent circumvents any existing traffic. The final computed path comprises a spatial–temporal sequence of nodes which the drone has to fly through at a prescribed time. The path is uploaded to the drone prior to take-off and it is the responsibility of the drone itself to adhere to this path and timetable. Simultaneously, the path is logged in the UTM database, where it is then available in any subsequent path-finding request.
3.6.3. Tactical (Real-Time) Deconfliction
Real-time traffic conflicts can occur when drones do not remain inside their safety tube whilst traveling along their designated path. This can easily happen if a drone travels slower than expected. Using the example in the preceding section, if the drone only manages a ground speed of 15 m/s, instead of the original 20 m/s, then it falls behind its schedule by 5 m per second. Hence the safety margin provided by the tube’s tail of 1200 m will be exhausted after 240 s, or 4 min, at which point the drone falls out of its safety tube. This causes an immediate problem, since there is now the potential that the slower flying drone inadvertently enters the safety tube of another nearby drone. This gives rise to a potential real-time traffic conflict, so a tactical deconfliction function needs to be triggered in order to handle this situation. This triggering can be instigated by the drone itself, which has been charged to monitor its own progress, but it is likely that the central UTM may also run a secondary drone progress status monitoring process. In this example, the drone monitors its progress and alerts the UTM once its onboard journey monitoring unit records a delay of at least 45 s. At this point the drone is still well within its 60 s tail section and has up to 15 s to remain within the boundary of its safety tube. However, this 15 s period provides a buffer for the UTM to deal with a potential future conflict and issue an updated path with deconfliction instructions. If the drone’s slower progress does not cause a traffic conflict, then the drone’s path can remain unchanged and only its schedule needs to be updated within the UTM. This means the safety tube is delayed by 45 s to ensure that the drone is placed again at the desired 20% position from the front end of the tube. If, on the other hand, the newly computed safety tube is to interfere with another drone’s trajectory, then the UTM must now reroute this drone. This rerouting can be carried out by applying the path-finding algorithm, as described in the previous sub-section, to the remaining part of the journey. The new deconflicted route is then uploaded to the drone as its new itinerary, as well as the UTM central database. The three-image sequence, shown in in Figure 15
, describes a simple tactical deconfliction scenario and associated process. In this case, the deconfliction layer is used to jump over the other drone and so resolve the potential traffic conflict.
Requests for real-time deconfliction will also sequentially have to be dealt with by the UTM, and these requests should always be permitted to skip the queue and be processed as soon as possible, given that one key objective of the UTM is to avoid any potential collisions. There should only be a minimal number of requests for real-time deconfliction. However, if this is not the case then the UTM’s pre-flight pathfinding and allocation process requires examination and improvement. The safety tube spatial–temporal dimensions may also need to be adjusted, depending on drone performance, trip durations, as well as the unique characteristics associated with the Urban UTM (e.g., particular daily traffic patterns). The right balance needs to be struck between ensuring safety whilst maximising overall operational efficiency of the urban airspace.
3.6.4. Emergency Event Handling
Emergency events can be classed as either internal or external in nature. Internal emergencies are associated with the drone itself (e.g., engine failure), whilst external events are due to other external factors (e.g., a localised severe weather event which may affect a number of drones over one part of the city).
An internal event might be a situation whereby a drone’s own system experiences a malfunction, which makes it unlikely or impossible for the drone to continue its journey safely. Usually, an emergency of this type will only affect the drone itself, but this depends to a large degree on the type and extent of the damage affecting the drone’s operation. Only licensed drones carrying a current certificate of airworthiness with proven flight performance, together with redundant critical systems, as well as additional on-board safety systems, such as a parachute, should have permission to carry out BVLOS operations within urban airspace. So, the risk of malfunction should be low or, in case of not being able to maintain controlled flight, activate a backup propulsion system or deploy a parachute to support an emergency landing. If the drone is capable of flight, the most expedient route from its current location to a near-by landing zone or Temporary Reserve Zone (TRZ) can be calculated—similar to the tactical deconfliction process, described in sub-Section 3.6.2
—and the onboard flight-controller updated with direct itinerary.
External Event: An example of an external event might be a localised weather event or medical emergency helicopter which needs immediate access to the same airspace, occupied by one or more drones, in order to land at a nearby hospital helicopter landing pad. This external emergency event can potentially affect a single drone, or a number of drones, at various locations within the urban airspace volume for differing lengths of time. In the case of an external event involving manned flight, it coordination with conventional Air Traffic Control (ATC) would be required to determine the spatial volume and temporal limits of the emergency airspace that may be required by the medical emergency helicopter. A drone that is already within the emergency zone will need to be given the necessary time to exit along its given route, or if this is deemed too long, be made to return or provided with holding or landing options. Drones which are due to enter the declared emergency zone need to be identified by the UTM and rerouted since this emergency zone is treated as a NFZ for as long as it is active. The UTM will prioritise the affected drones according to their proximity and reroute each one in decreasing order of priority. It might again prove expedient to use a nearby TRZ, clear of the temporary emergency airspace, to reroute the affected drones in order to either hover or land before authorising the drones to resume their journey after the medical emergency helicopter has passed through. Again, all computational aspects of this emergency handling can be dealt with within the above tactical deconfliction framework.