The need to define an appropriate set of UAS requirements for base UAS Traffic Management capabilities.
By: Andy Thurling, NUAIR Chief Technology Officer
We (the UAS industry) have defined what a UAS Traffic Management (UTM) system does, and how it works… but not how well it should do anything.
NUAIR and The New York UAS Test Site’s experience with UTM to date has provided enough insight into what these requirements should be for us to describe the path toward fielding an initial system.
Step One begins with the belief that we do not have to define the perfect system, but rather one that is useable, commercially relevant, and evolvable – much like the development and evolution of manned air traffic control.
The first airport traffic control tower was erected in the early 1930s, with relatively low air traffic – “Step One”, establishing a starting point for air traffic control. It may not have been a perfect system or have every “what-if” figured out, but it gave the industry the ability to evolve into the highly advanced and safe air traffic control system we have today, managing over 43,000 flights a day.
If we envision a future where drones are conducting routine daily operations, we need to establish our own first step toward a deployed UTM capability which we call “Local BVLOS”.
Below is a more in-depth paper discussing our Local BVLOS concept and implementing a commercially viable UTM system. I hope you will join me (virtually) at DRONE ENABLE 2021, happening in April, to listen in live and discuss these on-going issues.
Herein we address the greatest need in the area of UA Performance Requirements in a UTM Environment. More broadly, we contend the lack of performance requirements for all elements of the UAS/UTM ecosystem and industry consensus standards detailing a means of compliance with these requirements impedes the establishment of an appropriate certification basis for UAS operating in a UTM environment. These deficiencies inhibit fielding UTM services that could support widespread civil commercial UAS applications.
We describe, at a high-level, a solution to this problem statement that could be implemented by any State.
The concept described allows for a technology agnostic and flexible implementation while adhering to a basic framework of minimum performance requirements. The flexibility afforded in the technology agnostic performance requirements means that infrastructure and technology requirements needed to achieve the proposed solution may be readily achieved with technology and capabilities already demonstrated.
NASA started the UTM project back in 2014 with a “Build a Little, Test a Little” philosophy and progressed over the next several years through four technology capability levels. NASA and the FAA established a UTM Research Transition Team (RTT) in 2016 to transition the technology from NASA research into the field. Unfortunately, the “Build a Little, Test a Little” philosophy wasn’t followed by “Field a Little”. The FAA Integration Pilot Program (IPP) and UTM Pilot Program have yet to yield results which are broadly applicable and fieldable in a commercial context.
Civil Aviation Authorities (CAAs) around the world want to use UTM/U-Space services as mitigations to the risks inherent in UAS operations. But, without requirements and standards that define the level to which these services are effective, it is impossible to quantify the amount of risk mitigation achieved when using a UTM/U-space service. More than five years into the program and despite many top-level strategic discussions on the topic of what UTM and U-space are intended to provide, there are currently no requirements defined and no published standards documenting the expected level of performance for any services in the proposed ecosystem.
We defined what UTM does, and how it talks, but not how well it, its components, or the aircraft operating within it should do anything.
The NY UAS Test Site’s experience with UTM to date has provided enough insight into what these requirements should be for us to describe the path toward fielding an initial system. Our “Step One”, begins with the belief that we do not have to define the end-state or perfect system, but rather one that is useable, commercially relevant, and evolvable as commercial operational experience provides deeper insight into future UAS and UTM system requirements . In short, we need to define an appropriate set of UAS requirements for integration into the “initial tranche” of UTM capability.
A civil BVLOS operation will require an “appropriately airworthy” system– and this will have some risk-based level of performance requirements attached to it. Thus, we need technology agnostic performance-based requirements across the “ecosystem”- e.g., aircraft performance, navigation accuracy, datalink (C2) performance, as well as UTM services such as flight planning, surveillance, weather, etc. which are appropriate for the airspace in which operations are being approved.
In such a “fielded” UTM ecosystem as we are describing, Operators with verified system performance may be granted a flight authorization. Thus, a set of validated “initial” performance requirements is essential to moving the UAS and UTM ecosystems past the “demonstration” phase.
Manned aviation now enjoys precise navigation allowing for highly accurate approaches enabling large increases in airspace efficiency – and we want that for UAS. But manned aviation did not start there, in fact, it started with a succession of concrete arrows on the ground spaced out every few miles from New York to San Francisco and lit by revolving lights on top of 60-foot towers.
These primitive “navigational aids” helped pilots find their way more safely. We are not suggesting we go all the way back to concrete arrows, but we need to stop being fixating on the “perfect” solution. We need to focus on a first tranche of UTM capability that is both safe and “good enough” to get performance authorizations to do civil commercial BVLOS work. To achieve this, we must define the minimum performance requirements expected of the unmanned aircraft system that will integrate into this UTM.
This, in a nutshell, is our strategy at the New York UAS Test Site and NUAIR. We are working jointly with the UAS commercial industry, standards developing organizations (SDOs) and the FAA in establishing and validating performance requirements that can be used to move UAS and the UTM ecosystem into the field.
The overarching goal of the team is to field a commercially viable UTM ecosystem not only in Upstate New York, but in any location that can meet the set of performance requirements described.
NUAIR and partners to date have built, integrated, and/or demonstrated many UTM technologies, however none of these have translated into routine, commercial UTM operations. Our Performance Requirements Working Group is bridging that gap by focusing on enabling a well-defined, bounded use case that uses this “first fielded tranche” of UTM capability.
In enabling such a use case we are undertaking the following tasks:
- Development of Communication, Navigation, and Surveillance (CNS) requirements
- Establishing test methods and approaches for the assessment of UTM capabilities and technologies against requirements developed above
- Execution of test and data collection activities for the validation of these CNS requirements in the context of the chosen operational concept
- Use test and evaluation results in the development of a safety case to be submitted for one or more public aircraft operations Certificates of Waiver or Authorization as well as civil waivers to 14 CFR Part 107.31 or similar international regulatory construct such as a performance authorization under a SORA standard scenario or Pre-defined Risk Assessment (PDRA).
The foundational use case, or “Standard Scenario”/PDRA, being developed is referred to as “Local-BVLOS” (L-BVLOS). The concept of L-BVLOS involves the conduct of a remotely operated BVLOS UAS operations (“drone-in-a-box”), but within the confines of an explicitly defined, appropriately constrained, well-understood operational environment. L-BVLOS is designed to rapidly field an acceptable UTM solution to support remote operations of compliant UAS in the defined “local” context.
Rather than waiting for SDSPs that can support “full” and unconstrained BVLOS operations, e.g. surveillance, C2 coverage, and obstacles over the broad area of operations; we can field an initial capability by constraining operations to well defined and understood local “bubbles” of operation. For example, there is no need for an obstacle SDSP when all obstacles at the L-BLVLOS location can be precisely surveyed when the local site is established!
Thus, L-BVLOS is not a prescribed technical solution but rather a set of flight-test validated minimum requirements that may be used anywhere to establish the remote operations with different airborne platforms, C2 and surveillance sources.
We are currently collecting data in accordance with disciplined flight test methodologies in which system requirements define the measures of performance and suitability to be evaluated. The team is using the newest data collection methodologies refined by the FAA UTM Pilot Project Phase 2 Data Management Plan but we are also collecting data from day-to-day test operations such that we can refine what the expected operational requirements for UAS CNS accuracy should be.
Accurate position reporting will become increasingly important, especially if drone-to-drone separation is reduced to levels as “tight” as suggested by the SESAR-JU Concept of Operations for U-Space, i.e., 200’ horizontally and 150’ vertically. Vertical excursions of more than 200’ have been seen in the NASA flight tests and illustrate the importance of establishing, not just requirements for position reporting accuracy, but also for UA autopilots such that there is assurance as to the vehicle’s ability to maintain a commanded course or altitude within well-understood bounds. Accurate understanding of drones positioning capabilities will become increasingly important as UTM flight planning services begin to require knowledge of UAS performance to assign appropriate buffers.
The issue is knowing how big a buffer to put into the operational volume or around an obstruction during flight planning, so understanding the bounds on error is more important than meeting a specific accuracy number.
The tighter the statistical bound, the less safety margin will need to be applied allowing more efficient use of airspace. For L-BVLOS, we do not want these requirements to be too difficult to meet. However, for the safety analysis, we needed to set the initial bar somewhere and thus we chose the accuracy requirements established by Transport Canada in Standard 922.04 Operations in Controlled Airspace for which dozens of UAs have already been declared compliant.
The need for a common altimetry solution was a lesson learned from early NASA tests and discussed in a recent Eurocontrol white paper on a Common Altitude Reference System. UAS compliant with the draft ASTM UTM standard reference use GPS Height Above Ellipsoid (HAE) when communicating altitude across the USS network, but there are still several “translations” taking place. US Part 107 requires sUA to stay below 400 AGL, and the EASA requirement for direct remote identification also specifies that altitude be referenced in height above the ground or the launch site. Airspace restrictions and obstructions are commonly defined in AGL as well. While it is easy to calculate the AGL value given the HAE and the latitude/longitude of the UA, errors inevitably enter the calculation. For instance, if Operators use different databases from which to make the calculation, differences between databases, e.g. accuracy, resolution, grid spacing, etc. contribute to errors. So, the problem is not “solved” because we agreed on WGS84.
In the area of C2, we are assuming that LTE can be an acceptable datalink given its widespread deployment and generally good performance. We are therefore conducting airborne testing to determine what parameters drive the C2 Link performance for aerial LTE users. For example, we know that cell utilization is large driver in performance, which is listed under the “Utilization” KPI. Other parameters might be tower-to-tower cell handoff or switchover times, etc. These are just a few that need exploring. We are accomplishing data collection on numerous projects to determine the critical network-based parameters we need to expose for C2 link performance predictions – essentially an LTE to Minimum Aviation System Performance Standards “Rosetta Stone”.
NUAIR is also investigating to what extent a UTM components are required to be certified and, if so, to what requirements and/or a target level of safety will the system be held. These are active research topics at the NYUASTS as part of the FAA UTM Pilot Project Phase 2 and our self-funded research programs establishing L-BVLOS requirements and approval mechanisms. The New York UAS Test Site (NYUASTS) is equipped to collect desired data travelling on the inter-USS network. These data will be analyzed, and data products evaluated and compared to the proposed UTM Service performance requirements.
In conclusion, aviation functions may be broken down into “Aviate”, “Navigate”, and “Communicate”. UAS specific functional breakdowns add the “Operate” function to encompass some of the functions normally accomplished by an in situ human pilot such as collision avoidance, and contingency management. UAS performance required for integration with UTM can be broken out along similar lines:
- Aviate – “How well do I maintain course and altitude?”
- Navigate – “How accurately can I determine my position?”
- Communicate – “How reliable is my datalink?”
- Operate – “How well do I avoid collisions and adverse weather?”
We have architected, configured, and resourced the NY UAS Test Site and UTM Corridor to verify UAS meet the requirements to Aviate, Navigate and Communicate appropriate for each increment of evolving UTM capability. By laying down a roadmap for disciplined flight test evaluation, we are ready to validate the performance requirements envisioned in each tranche of fieldable UTM capability starting with the L-BVLOS use case discussed previously and will be ready to verify compliance of UAS, USS, and SDSPs to future industry consensus standards defining such requirements.