Flightops Integration

Andi Lamprecht ·2026-05-11· 6 min read· Accepted

FlightOps Integration

Context

UTM-1910

What is FlightOps?

FlightOps is a service currently used by our hubs to plan, track, and execute drone missions.

• No commitment to planned routes: Routes can change mid-flight at a moment’s notice.
• No commitment to time: No information is provided about when a drone will take off, land, or exist at a given point in the route.

Why are we integrating?

We currently have two methods of avoiding drones from other operators:

1. Calling their operators to coordinate
2. In-flight, visual line-of-sight “see and avoid” maneuvers

These methods do not scale. By sharing flight plans between operators, we can strategically plan to avoid each other. DroneUp signed an agreement, known as the Shared Airspace agreement, to do exactly this in early 2024. We now have an obligation to share flight plans for all hubs that have overlapping operations with other drone delivery providers.

With FlightOps currently in service at our hubs, UTM must inform both FlightOps and other industry operators about what the other is doing.

• Industry Operators: UTM communicates flight intent through a
  Discovery and Synchronization Service (DSS), a system designed to coordinate flights between drone operators. In order to communicate DroneUp flight intentions, we must turn FlightOps’ missions into something the DSS will acknowledge.
• Hub Operators: The other side to this is informing FlightOps about where other operators are flying. The way this is done in FlightOps is by creating No-Fly Zones (NFZs), disallowing our flights from intersecting with other operators’ flights.

How are we integrating?

Discovering FlightOps Flights

The way we currently discover DroneUp internal flights from FlightOps by listening for messages via a WebSocket connection to each FlightOps server.

To prevent WebSocket reads from blocking one another, a separate thread is be spawned for each FlightOps server we integrate with. This means if there are 10 FlightOps servers, then we will have 10 threads dedicated to reading from its own WebSocket connection.

As mentioned above, FlightOps does not commit to a route or a time. This means UTM needs to make a pessimistic guess as to when and where a drone will be flying. Based on this as well as some assumptions made about the flight, we must create and submit a flight intent to the DSS.

Some of these assumptions include:

• Start Time: FlightOps does not tell us when a mission starts. Currently, we assume the start time is the moment we discover mission takeoff.
• Return Path: FlightOps only provides the route to a destination, but not the path back. Currently, we assume the drone will take the same path back that it took to its destination.
• Ascending/Descending: FlightOps does not include the ascending or descending coordinates. We must assume the drone will always ascend and descend vertically, and that the start point of the flight is the drone’s current location upon discovering mission takeoff.
• Airspeed: Because we are not given any times from FlightOps, we must assume that drones will travel at some constant speed to estimate the mission’s end time. This can be different for each: ascension, descension, and horizontal travel.

Creating No-Fly Zones (NFZs)

The new UTM service will notify FlightOps of external operators’ flights from the DSS using NFZs.

FlightOps provides REST endpoints which allow us to manage the creation and deletion of NFZs for a given FlightOps server.

• Creation: NFZs cannot be scheduled, so UTM must wait until a flight begins before creating an NFZ. When a flight begins, UTM must submit an NFZ described by the volume of the flight intent.
• Deletion: NFZs do not expire; once they are created, we must request its deletion. To do this, UTM must wait until a flight has finished and delete the NFZ at that point in time.
• Applicability: Hubs in Virginia don’t need to know about flights in Texas, and flights in Dallas don’t need to know about flights in Huston. In order to minimize the load on our FlightOps servers, we only create NFZs for flights that occur within a hubs operational boundaries.
• Redundancy: FlightOps does not need NFZs created for its own flights. It already knows where its flying and creating NFZs where they are flying would make it impossible for them to fly anywhere. This means UTM must not create NFZs for missions sent by FlightOps.
• Operational Overlap: Because FlightOps servers are independent of one another, and because each has its own operational boundaries, it is therefore possible that two ore more FlightOps servers may have operational overlap. This means UTM must notify FlightOps servers of missions created by other FlightOps servers that exist within its boundaries. To do this, UTM must associate missions created by a flightops server with that server, so that we don’t create NFZs on that server that created it, but do create NFZs for other FlightOps servers that mission overlaps with.

Why a separate service?

Separating this communication between FlightOps and UTM into its own service decouples this communication from all other API functions.

Additionally, there are roughly 40 FlightOps servers that we know about. Because of this large and potentially growing number of servers we need to communicate with, keeping this in its own service will help keep our API service from becoming overburdened.

Lastly, there is a network dependency necessary for any service communicating with FlightOps that the rest of our API doesn’t need.

Consolidating all these things into a single service means it can be more easily managed and torn down when necessary.

Decision Drivers

• separation of concerns
• scalability
• network dependency

Decision

A separate service will be created for communicating with FlightOps, and the functionality previously in the API service will be extracted and moved to the new service.

FlightOps Service

Invalid Image Path

UTM’s FlightOps service will be responsible for managing communication between the UTM API and all FlightOps servers:

• Notifying FlightOps about flights from other operators (using NFZs)
• Notifying the UTM API (and consequently, other operators) about flights from FlightOps

No Database Connection

The UTM FlightOps service will not have a direct connection to the database.
This means that the new service will instead need to leverage the UTM API’s REST endpoints as its data source.

Managing NFZs

Without a database, it’s unclear what the best approach would be for managing NFZs. One approach is to use FlightOps as a data source for NFZs. Another approach is to create FlightOps-specific NFZ endpoints on the UTM API and use that as a data source.

Problems

With so many FlightOps servers to communicate with, the question of scalability arises.

For now, we will be moving forward with the existing approach of having a communication thread to each FlightOps server.

If and when scalability starts becoming an issue, we will restrategize.

Alternate Approaches

• Listening for flights from a Pub/Sub
• Share load across multiple pods

Consequences

• Another service to maintain
• No database connection