This entry reviews public documentation for the technical integration of the flight stack, together with the necessary cooperation and collaboration with third parties, to operate in coordinated and controlled airspaces.
It will have a look in the UTM concept through the NASA-UTM and U-space initiatives, the main blocks that make up the proposed architectures, the UTM services identified and the role of the UAS service provider in these frameworks.
The UTM concept
As stated in the UAS Traffic Management Architecture document (pg. 4) of GUTMA, "UTM can be defined as a system of stakeholders and technical systems collaborating in certain interactions, and according to certain regulations, to maintain safe separation of unmanned aircraft, between themselves and from ATM users, at very low level, and to provide an efficient and orderly flow of traffic".
On the same document (pg. 2), GUTMA also highlights several aspects and challenges that need to be considered in the management of unmanaged air traffic. To highlight the following:
- It is expected that most of the unmmanned aircraft operations will take place at very low level, a part of the air space used by general aviation but also by infrastructure, people, animals, transportation, etc.
- Operations must comply with the safety standards that have already been established although additional standards may have to be developed too.
- At present there is no system to manage unmanned air traffic. Conventional air traffic management can not be applied to unmanned aircraft. It relies on voice communication between air traffic controllers and pilots, and on radar detection.
- The anticipated traffic density of drones is far beyond the capabilities of current air traffic management systems, which were never designed to handle large amounts of dense heterogeneous traffic with widely varying performance characteristics, size and autonomy.
The U-space model
The steadily increasing demand for drone services, with the potential to generate significant economics growth and societal benefits, was recognised in the 2015 EU Aviation Strategy, and more recently in the 2016 SESAR Drones Outlook Study and Warsaw Declaration on drones.
In order to realise this potential, the Declaration calls for "urgent action on the airspace dimension, in particular the development of the concept of U-space".
Defined by SESAR JU, the Single European Sky ATM Research Joint Undertaking, U-space is a set of UTM services and procedures designed to support safe, efficient, and secure access to airspace for drones.
U-space services rely on a high degree of automation and digitalization to ensure the smooth operation of all categories of drones on all types of missions in all operating environments.
U-space is a collaborative effort among industry and regulators to enable situational awareness, data exchange, and digital communication with the drone ecosystem as well as manned aviation, ATM service providers, and authorities.
U-space defines four distinct U-levels:
- U1 UTM Foundation services (2019 plus) e-registration, e-identification and geo-fencing
- U2 UTM Initial services (2022 plus) Flight planning, flight approval, tracking, airspace dynamic information and procedural interface with ATC
- U3 UTM Advanced/enhanced services (2027 plus) Capacity management and assistance for conflict detection
- U4 UTM full services (2035 plus) Additional new services and integrated interfaces with manned aviation
The NASA-UTM model
This model is being developed by NASA and the FAA, NASA-UTM is a collaborative research project with the goal of developing and demonstrating a possible UTM system that can safely enable drone operations in low-altitude airspace.
The Version 1.0 of the Ummaned Aircraft Systems (UAS) Traffic Management (UTM) Concept of Operations documents use cases development, insights on rulemaking and the evolution of Technology Capability Levels (TCL).
The model is defined in terms of four distinct TCLs (pg. 37):
With UTM, the FAA maintains its regulatory and operational authority for airspace and traffic operations; however, the operations are not managed via the ATM system. Rather they are organized, coordinated, and managed by a federated set of actors in a distributed network of highly automated systems via Application Programming Interfaces (APIs)
The resource contains a notional UTM architecture (pg. 7) that visually identifies, at a high level, the various actors and components, their contextual relationships, as well as high level functions and information flows.
It is interesting to highlight the role of the UAS Service Supplier (USS) as the main interface between UAS and operators in the framework.
Appendix B of the document also defines the concepts of controlled and uncontrolled airspaces (pg 38-39) as well as the different classes identified by the letters A, B, C, D, E and G.
According to the resource, we will consider controlled airspace as a generic term that covers the different classifications of airspace and defined dimensions within which air traffic control (ATC) is provided in accordance with the airspace classification. Controlled airspace consists of Classes A, B, C, D and E.
Uncontrolled airspace or Class G airspace is the portion of the airspace that has not been designated as Class A, B, C, D or E.
The following image (pg. 3) highlights the UTM operations in context of airspace classes.
Finally, Appendix C (pg. 40) identifies and collects 13 essential services in the model. These services provide the expected features and capabilities of the framework.
The list of UTM services is the following:
Depending on the level of coverage by the USS of the framework, these functionalities and capabilities can become part of the offer of digital products and services to operators and UAS with different level of implementation and support.
The UAS service supplier in UTM
As mentioned above, one of the responsibilities of the USS is to provide the appropriate interface between UTM and the operators / UAS that act as clients.
The flight stages identified by GUTMA (pg. 6) are four:
- Strategic phase, well before the time of operation, which addresses the airspace design, definition of strategic no-fly zones, regulations, etc.
- Pre-flight phase, before the time of operation but focused on the specific flight, mainly to address the operations planning.
- In-flight phase, which is the time of operation when the flight is performing its operations.
- Post-flight phase, which addresses the analysis of recordings aspects and other relevant post-flight business and obligations.
Taking into account the current list of functional use cases also identified by GUTMA (pg. 17-19) and filter them by those involving the operator or UAS, the next subset is obtained:
The subset facing the flight phases:
In the case of long-range flights, and once the aircraft is in the in-flight phase, we may be interested in making changes to the flight plan in response to the contingency information received, warnings of conflict, etc.
In these cases it might make sense to extend the scope of new operation and flight requests that update to the current ones, as well as the signaling of the end of operation or flight as shown in the following table in red.
The concept of UTM tries to collect a vision that responds to the necessary organization of large-scale drone operations in low altitude. The projected scenarios anticipate an increase in the density of drone operations and an increase in the complexity of air traffic impossible to manage with current resources and means.
It is in this context that UTM tries to extend and complement current ATM to support and integrate heterogeneous UAVs at low altitudes. It fundamentally seeks to balance three different needs such as the protection of key assets, the safe airspace integration and the scalable operations for economic growth.
This requires a new virtual, flexible and digital infrastructure that allows receiving and processing millions of flight plans to ensure that they do not violate static and dynamic restrictions of a geographical, regulatory, climatic, etc. nature. that could be applicable throughout the flight.
Two initiatives, NASA-UTM and U-space, work on realizing UTM through a roadmap that deploys functionality and manages complexity incrementally while increasing capacity progressively.
Currently there is a close collaboration between the public-private sector and given the nature of the problem everything seems to indicate a co-existence of multiple airspace service providers or suppliers.
The interface and functionality deployed by these service providers corresponds to the level of maturity and the milestones reached in the roadmap of the two main initiatives.
Currently the available proofs of concept cover the functionalities of registration, identification, issuance and updating of flight plans, flight management, reception of notifications/alerts, telemetry, etc. More complex cases such as urban environment interaction, manned traffic integration, etc. are not yet supported.
Mention also that the support of the companies of airspace management collaborating in these projects dedicate remarkable efforts of integration of the flight stacks directed to OEM and IS only. In many cases, the documentation and the reference source code are not available to freely integrate with the services.
It should also be noted that in the case of service suppliers that do publish documentation and reference source code, the APIs do not provide meta-information about the service (performance, costs, etc.), nor do they contemplate changing the service supplier, or the consumption of services from different suppliers.
It does not seem that there is a great technical risk in the incremental development of UTM technologies aligned with the two main projects (NASA-UTM and U-space), as well as the integration of these in the routine operations of the UAV.
- Open Source UAV, UTM, DEM and elevation profile
- Open Source UAV, SITL in Docker, Mission Planner and MAV tools
- Open Source UAV and survival analysis with R
- Open Source UAV and mobile cellular networks
- Open Source UAV API, DroneKit-Python and Geopy
- Open Source UAV Autopilot with Ardupilot and Pixhawk