Presentation: Vigilant Aerospace CEO presents on Integrating Detect-and-Avoid at XPONENTIAL 2023

I’m Kraettli Epperson, CEO and co-founder of Vigilant Aerospace Systems, and I’m going to be talking about how to integrate detect-and-avoid systems into UTM as a way to distribute those services to the largest number of users and use them as part of a coordinated airspace management system, particularly in support of advanced air mobility.

We are very interested in this topic. There have been a lot of advancements and new technologies that we have been able to bring forward to support it.

A little background on us. Vigilant Aerospace Systems is the company name. FlightHorizon is our product. We are focused on building automatic detect-and-avoid systems and airspace management systems. Some of these are onboard systems and some are ground-based systems, built on two licensed NASA patents.

The technology has been used in projects with NASA, the FAA, and UAS test sites throughout the United States, and now increasingly by the U.S. Air Force and a variety of civilian programs, particularly for corridor development and drone port development. We are encouraged to see the advancement of these technologies in the U.S. right now.

It is a fully integrated multi-sensor system, which is part of what makes it unique. As I mentioned, we have both ground and onboard systems, and they use both local sensors, such as local radar and local ADS-B in receivers, as well as other sensors and online data. I’ll be talking about that and showing some diagrams.

Our agenda today is to talk about key elements of safety required for advanced air mobility, some of the technical requirements that have emerged and are becoming very apparent, and the FAA’s new UTM CONOPS version 2.0, which was just announced and includes some important insights. We will also touch on technical requirements and standards, which we believe are essential to enabling the industry, briefly discuss the process we use to design a safe system, and then spend most of our time on actual components and an implementation example using our FlightHorizon system. Finally, we will look at some of the component details, the user interface, and a few example projects, and hopefully leave time for questions.

When we talk about key elements for safety in uncrewed aviation, we are really talking about an interlocking set of technologies that create multiple layers of safety and coordination. It is about having multiple layers of safety.

We believe that the rules and regulations clearly indicate that multiple interlocking systems will be needed to make all of this work. That is because safety has to be provided at at least three different levels and in three different ways.

One of these is strategic. This has to do with certification, the choices about where and how you fly, what you fly, your operating procedures, airspace decisions, and flight authorizations. Then there is the tactical layer, which is what we are especially focused on as a company because it is one of the more difficult problems to solve: the ability to perform air traffic surveillance, maintain situational awareness, and understand what must be avoided in order to prevent collisions.

This is a diagram from the new FAA UTM Concept of Operations, version 2.0. They published one in 2020, and this updated version came out just a few days ago. It is very interesting.

There are a couple of things I want to point out in this diagram. I know there is a lot going on and it is fairly complex, but what the FAA is showing is a set of interlocking systems that allow UAS, advanced air mobility vehicles, and traditional air traffic to coexist safely in the same airspace, coordinate efficiently, and, most importantly, rely on services and automation in order to scale and create a more efficient and economical future for aviation in the United States. That direction is important, and it is what we are focused on right now.

Some key technical requirements become clear when you look at this diagram, the rules, and the emerging operations. You have to be able to detect, track, and avoid both cooperative and non-cooperative traffic. Cooperative traffic means aircraft equipped with a transponder that is transmitting into the air traffic control system. Non-cooperative traffic is traffic that is not transmitting, often because it is operating at lower altitude, is a smaller aircraft, or is not in controlled airspace, so it has to be detected another way.

We believe private sensors will be necessary, particularly at locations such as drone ports, vertiports, and corridors. Those will be crucial for enabling the use of the facility, especially for landing, authorizing takeoff, and coordinating both onboard and ground-based surveillance and sensor systems.

The distribution of shared sensor data is also extremely important. There is an emerging concept of the Supplemental Data Service Provider, or SDSP, within UTM and the UTM CONOPS framework. The idea is to distribute that data efficiently so that operators can subscribe to another party’s radar or other information. That opens the possibility of a real business around shared infrastructure, similar to how airports rely on shared infrastructure today to support operations, and that model can support lower-altitude AAM and UAS flights.

Data distribution and coordination are merging with the broader UTM and extensible traffic management, or XTM, model. That allows operators to make reservations in the airspace so that not all deconfliction is tactical. Instead, some of it is procedural. At low altitude, coordination becomes especially important, particularly drone-to-drone and drone-to-aircraft coordination. That is where tactical capability becomes critical.

There are also technical standards involved. I will not spend a lot of time on those, but I serve on the ASTM F38 committee and working group, and there are strong industry standards emerging and maturing that help enable this work. Those standards are important because they provide certainty for developers like us. If we can meet the standard, then we know we can bring a product to market, address a real marketplace, and eventually achieve compliance with regulatory requirements.

ASTM F3442 is a detect-and-avoid standard. Version 2.0 has just been published, and version 3.0 is already in development. That working group is doing important work, particularly for lower-risk, lower-altitude UAS, with lessons that may eventually carry over into other categories as well.

RTCA DO-365B provides minimum operational performance standards for detect-and-avoid for larger aircraft, and we implement an ACAS Xu model in order to align with that. There are also standards for ADS-B and software verification. All of these help create momentum and certainty in the industry.

Our approach to safety is based on a process that may differ somewhat from what others do. We take a holistic view and understand that a successful system has to support all of these different levels of safety.

We begin by determining the mission goals: where you are going to fly and what you are going to fly. Then we identify the risks. That step is very important. It is called out in the rules, in the standards, and throughout the waiver process. You look at your operating choices and determine how to reduce the need for mitigation in the first place.

For example, avoiding flight over people is a common mitigation. You may determine that you can fly from point A to point B, but if you route it differently, you do not have to fly over people, which reduces risk. Then you determine what mitigations are required for the remaining risks, and then you test and validate, and test and validate again. That is our approach, so you can achieve one goal safely and then incrementally build toward the next one.

Now we come to the heart of the presentation. This is our implementation of the FlightHorizon system. There is a lot on this diagram, so I will just go through a few of the pieces.

The orange box in the middle is the core of our software. Fundamentally, we are a software company, and we develop standards-compliant airspace management and detect-and-avoid software. All of the surrounding systems and modules support that process.

We pull in information from registered aircraft directly from the flight controller, either through a UTM process, through a direct connection to the ground control station, or directly from the flight controller itself. We pull in radar data, often from portable radar, although the system scales and can use larger terminal radars as well. We pull in ADS-B in data locally, and we also pull in real-time FAA data subscriptions, which can be especially useful in controlled airspace.

We are building models that will allow us to pull in SDSP data as that becomes available, so we will be able to incorporate data and sensors from other providers. We also currently pull in Remote ID data where it is available, and there are some good projects underway in that area.

On the UTM side, for coordination, we communicate with a Flight Information Management System, or FIMS, which allows sharing of flight information upward and discovery and synchronization across USS companies. Down at the bottom of the diagram is the USS, or unmanned system service supplier, interface. That is the display the remote pilot uses, and it is the interface into the UTM system.

That is how our system currently works. I am going to show a little more practical information on how it is used in the field and on active projects, but this is the diagram I use to explain the fundamentals. There is also a photo here of a NASA airspace manager using our system during supersonic flight testing in Florida to track aircraft and their deconfliction.

Here are some implementations. On the left is a ground-based system, similar to the one you just saw with the NASA airspace manager. It uses portable radar, portable ADS-B in, a direct connection to a ground control station, and other radios and systems. It is fully independent and runs on a laptop, which is important for some projects because it is portable.

On the right is the same system adapted to run on a single-board computer installed onboard the aircraft, connected to onboard radar, onboard ADS-B in, and onboard telemetry. This was part of an FAA project in which we flew beyond visual line of sight along the Trans-Alaska Pipeline with the Alaska UAS Test Site. That was an important project for us. It was really the first multi-sensor detect-and-avoid system of its kind flown along the Trans-Alaska Pipeline.

The user interface places the ownship aircraft at the center. In the example shown, the white aircraft is your ownship. Around it is a loss-of-clearance ring in yellow and a near mid-air collision ring in red. There is also a detected aircraft that is approaching. The system automatically provides a loss-of-clearance warning and gives an instruction such as “descend, slow down, turn left within 25 seconds.” It also provides an audible warning, and the green line extending from the aircraft icon shows the instruction in three-dimensional space.

Here is the same system operating with multiple aircraft. In this example, the system is tracking more than one ownship aircraft and providing warnings for encounters involving both of them and another approaching aircraft. Because the system is typically hosted in the cloud, we can scale it to the number of aircraft the operation needs, potentially dozens and eventually perhaps hundreds.

To say a little more about the UTM functions we have integrated, the image on the left shows some of the configuration used when connecting to a FIMS server to share flight information. On the right, you can see a reservation in a corridor. We also support multiple integrated systems at the same time, including multiple radars, different radar types, multiple receivers, FAA data, and other telemetry sources.

I want to briefly mention a few projects.

These photos are from our flights in Alaska, flying beyond visual line of sight under one of the most advanced waivers in the United States, operated by the Alaska test site and sponsored by the FAA. We used multiple radars, and the project provided valuable information to us and to the test partners. One image shows Zach operating in very cold weather with one of the larger radars that we were testing for the FAA. Another shows a takeoff on a clearer day using the onboard radar system.

We have also been operating for several years with Oklahoma State University using small UAS, multiple sensors, and multiple aircraft. We do a great deal of active testing in that environment to create encounters, observe the system live, and carry it through the full detect-and-avoid process to demonstrate how it works. That has been very successful for us.

We also have an Air Force project, and in fact we now have three Air Force projects. One of the previously announced efforts involves tracking training MQ-9 Reapers out of Holloman Air Force Base. In that case, the system can run in the cloud, pull in the relevant data, and show exactly where those aircraft are in relation to other tracked aircraft in the surrounding airspace. That has been a strong ongoing project for us.

In summary, we believe that safe advanced air mobility will require coordination of multiple data sources. Some of those will come from third parties, some will be self-provided, and some will be local. We want to support all of those to make the system work.

UTM and associated elements are important. The FAA has issued guidance describing a roadmap for certifying and using associated elements of third-party services that will support beyond visual line of sight flight testing and, ultimately, routine cargo deliveries and other operations. That work is in progress now, and we pay close attention to it.

We believe standards can create certainty and ensure interoperability, which is extremely important. The UTM features I showed are based on NASA’s UTM concept, the FAA’s concept, and ASTM UTM standards. Those are the foundations we use to make sure our UTM system and our USS interface are interoperable with other systems.

It is like a cell phone network. Everyone has to be able to talk to everyone else in order for the system to be useful. Even if users are on different systems, using different hardware, or on different networks, they still have to interoperate.

We also believe that active detect-and-avoid requires consideration of both air risk and ground risk, along with appropriate sensors and surveillance. We have built our system around those major risks and the mitigations that must be part of a comprehensive safety architecture.

Finally, we believe that active detect-and-avoid requires multiple data sources so the system can correlate them and improve the baseline level of safety in a UTM environment. In other words, we believe tactical detect-and-avoid should be part of UTM, in addition to the coordination that UTM already provides. That is why we built the system the way we did.

Thank you very much.

All right. I’m Kraettli L. Epperson, CEO and co-founder of Vigilant Aerospace Systems, and I’m going to talk about how to integrate “detect-and-avoid” (DAA) systems into UTM as a way to distribute those services to the largest number of users and use them as part of a coordinated airspace management system, particularly in support of advanced air mobility (AAM) and urban air mobility (UAM).

We are focused on this topic because of the rapid advancement of new technologies that can support these systems.

A little background on us. Vigilant Aerospace Systems is the company, and FlightHorizon is our product line. We are focused on building automatic detect-and-avoid systems and airspace management systems. Some of these are onboard systems and some are ground-based systems, and they are based on two licensed NASA patents.

It has been used in projects with NASA, the FAA, and UAS test sites throughout the United States, and now increasingly by the U.S. Air Force and a variety of civilian programs, particularly for corridor development and droneport development. We are encouraged by the advancement of these types of technologies in the United States right now.

It is a fully integrated multi-sensor system, which is part of what makes it unique. As I mentioned, we have both ground-based and onboard systems, and the software uses both local sensors, such as local radar, local ADS-B in receivers, and other sensors, along with online data. I’ll talk more about that and provide some diagrams.

Our agenda today is to discuss the key elements of safety required for AAM, some of the technical requirements that have emerged and are becoming very apparent, and the FAA’s new UTM Concept of Operations Version 2.0, which was just announced and includes some important technical insights. We will also touch on technical requirements and technical standards, which we believe are essential to enabling the industry. Then I’ll briefly discuss the process we use to design a safe system, followed by the actual system components, which will be the heart of the presentation, using our FlightHorizon system as an example. I’ll also review the user interface, the UTM interface, and a few example projects. Finally, we will hopefully have time for questions.

When we talk about key elements for safety in UAM, we are really talking about an interlocking set of technologies that create multiple layers of safety and coordination. It is fundamentally about multiple layers of safety. We believe, and the rules and regulations increasingly indicate, that multiple interlocking systems will be required to make this work. That is because safety has to be provided at at least three different levels and in three different ways.

One of these is strategic. This includes certification decisions about where and how you fly and what you fly. It also includes operational procedures, airspace decisions, and flight authorizations that allow you to fly. Finally, the area we are especially focused on as a company, because it is one of the more difficult problems to solve, is tactical safety: the ability to have air traffic surveillance, maintain situational awareness, and know what must be avoided to prevent collisions.

This is a diagram from the new FAA UAM Concept of Operations, Version 2.0. They released a Version 1.0 in 2020 and just released this new version a few days ago. It is very interesting. There are a couple of things I want to point out in the diagram. I know it contains a great deal of information and is fairly complex, but what the FAA is showing is a variety of interlocking systems that allow UAS, AAM vehicles, and traditional air traffic to safely coexist in the same airspace and coordinate efficiently. Most importantly, it is built around the idea of relying on services and automation in order to scale and create an efficient, economical future for aviation in the United States. That is an important direction, and it is something we are paying close attention to.

There are several key technical requirements that become apparent when you study that diagram, the rules, and the emerging operational concepts. You have to be able to detect, track, and avoid both cooperative and non-cooperative traffic. Cooperative traffic is traffic with a transponder that is broadcasting into the air traffic control system. Non-cooperative traffic is traffic that is not broadcasting, either because it is at lower altitude, is a smaller aircraft, or is operating outside controlled airspace, and therefore has to be detected another way.

We believe private sensors will be necessary, particularly at locations such as droneports, vertiports, and corridors. Those systems will be crucial for enabling facility use, especially for landing authorization and takeoff approval. We also believe coordination between onboard and ground-based surveillance and sensor systems is essential.

The distribution of shared sensor data is also extremely important. There is an emerging concept of a supplemental data service provider, or SDSP, within the UTM framework. This would make it possible to distribute that data efficiently so that operators can subscribe to someone else’s radar or other surveillance information. It also creates the opportunity to build businesses around shared infrastructure, much like airports rely on shared infrastructure today to support lower-altitude AAM and UAS flights.

Another important area is the distribution and coordination of data through UTM and the more extensible traffic management, or xTM, model. That allows operators to make reservations in the airspace so that not all deconfliction has to happen tactically. Some of it can happen procedurally in advance. Then, especially at low altitude, coordination between drones and between drones and crewed aircraft becomes particularly important, which is where tactical systems become critical.

There are also technical standards that support this work. I will not spend too much time on this, but I serve on the ASTM F38 committee and working groups, and several industry standards are emerging quickly and maturing in ways that can help enable this industry. Those standards are important because they provide certainty for developers like us. If we know we can meet the standard, then we know we can bring a product to market, support a viable marketplace, and move toward eventual regulatory compliance.

ASTM F3442 is a detect-and-avoid standard. We have just published Version 2.0, and Version 3.0 is already in development. That is an active and important working group, especially for lower-risk, lower-altitude UAS operations, and its work may eventually influence other operational categories as well.

RTCA DO-365B is the minimum operational performance standard for detect-and-avoid in larger aircraft, and we implement an ACAS Xu model in support of that. There are also standards for ADS-B, which we use, and software verification standards. All of these contribute to momentum and certainty in the industry.

Our approach to safety is holistic. We believe you have to support all of these levels of safety together. We start by determining the goals of the operation, where you are going to fly, and what aircraft you are going to fly. Then we identify the risks. Risk identification is called out in the rules, the standards, and the waiver processes.

Next, we look at operational choices that can reduce the need for mitigation. For example, you may determine that you can fly from Point A to Point B without flying over people, which immediately reduces risk. Once those choices are made, you determine which mitigations are still required based on the remaining risk. Then you test and validate, and continue testing and validating. That is our approach: achieve one goal, then incrementally achieve the next.

Now I’ll move to the core of the presentation, which is our FlightHorizon system implementation. There is a lot on this diagram, so I’ll focus on the main components. The orange box in the middle is the core of our software. We are fundamentally a software company, and we develop standards-compliant airspace management and detect-and-avoid software. All of the surrounding systems and modules support that process.

We pull in information directly from registered aircraft through the flight controller. Aircraft can register either through a UTM process or through a direct connection to the ground control station or the flight controller itself. We pull in radar data, often from portable radar, although the system also scales to support larger radars, including terminal radars. We pull in ADS-B data locally, and we also pull in real-time FAA data subscriptions, which can be particularly useful in controlled airspace.

We are also building the capability to ingest SDSP data as that ecosystem matures, allowing us to bring in data from third-party sensors. We currently ingest Remote ID data where available, and those projects are advancing quickly.

On the UTM side, for coordination, we communicate with the Flight Information Management System, or FIMS, which allows upward data sharing, and with a discovery and synchronization server that allows data sharing across USS companies. At the bottom of the diagram, USS refers to the unmanned system service supplier interface. That is the display used by the remote pilot, and it is the interface that connects into the UTM system. That is the basic operating model of our system.

I’ll show a few examples of how this works in the field. You can see in one image a NASA airspace manager using our system for supersonic flights in Florida to track aircraft and support deconfliction.

Here are additional implementations. One is a ground-based system using portable radar, portable ADS-B, a direct connection to a ground control station, and other radios in a fully independent configuration. It runs on a laptop, which is important for some projects because portability matters.

On the right is a similar system running on a single-board computer installed onboard the aircraft, connected to onboard radar, onboard ADS-B in, and onboard telemetry. It runs directly with the software on the aircraft. This configuration was part of an FAA project in which we flew beyond visual line of sight (BVLOS) along the Trans-Alaska Pipeline with one of the FAA test sites. That was an important project and, to our knowledge, one of the first multi-sensor detect-and-avoid systems of its kind deployed in that environment.

The user interface centers on the ownship aircraft, shown in white. Around it are the well-clear distance ring in yellow and the near-air-collision region in red. The display also shows detected aircraft that may present an encounter. In this example, the system is automatically issuing a loss-of-well-clear warning and directing the operator to descend, slow down, or turn left within a specified time window.

The system also provides audible alerts. The green line extending from the aircraft symbol shows the suggested maneuver in three-dimensional space. In another example, the same system is tracking multiple aircraft and providing warnings for more than one ownship aircraft simultaneously. Because the system is typically hosted in the cloud, it can scale to handle the number of aircraft an operation may require, potentially dozens and eventually perhaps hundreds.

We have also integrated UTM functions. On one side is a screenshot of some of the configuration used to connect to a FIMS server in order to share flight information. On the other side is an example of a reservation and corridor displayed within the system. We also support multiple radars, different types of receivers, FAA data, and several forms of telemetry.

To conclude, I’ll briefly mention a few projects. One is our work in Alaska under one of the most advanced BVLOS waivers in the United States, in partnership with the Alaska FAA test site. That effort involved multiple radars and was sponsored by the FAA. It gave us and the broader test site community valuable operational data.

We have also operated for several years with Oklahoma State University using small UAS, multiple sensors, and multiple aircraft in active testing. Those tests involve creating live encounters and observing the detect-and-avoid process end to end. That work has been very successful for us.

In addition, we have several U.S. Air Force projects. One previously announced project involves tracking MQ-9 Reaper training operations out of Holloman Air Force Base. In that case, the system runs in the cloud, ingests the relevant data, and allows operators to see the aircraft in relation to nearby traffic. That has been an important ongoing effort.

In summary, we believe safe AAM will require coordination across multiple data sources. Some of those data sources are provided by third parties, some are self-provided, and some are local. We want to support all of them.

We also believe UTM and associated elements will play a major role. The FAA has issued guidance on a roadmap for certifying associated elements, meaning third-party services that support BVLOS flight testing and, ultimately, cargo delivery and broader operations. We are watching that closely.

We believe standards can create the certainty the industry needs. The UTM features I showed are based on NASA’s UTM Concept 2.0, the FAA concept, and ASTM UTM standards. That is how we ensure our system is interoperable, including interoperability at the USS interface. That is critical. Like a cellular network, everyone has to be able to communicate across systems for the network to be useful.

Finally, we believe active detect-and-avoid requires consideration of both air risk and ground risk, along with the appropriate sensors and surveillance. That is why we built our system around major operational risks and mitigations. We also believe that tactical detect-and-avoid should be included within UTM, in addition to the coordination UTM already provides, and that is why we have built the system the way we have.

Thank you very much.