Working with the FAA: What We’ve Learned From More Than a Decade of Advanced and BVLOS UAS Operations

Some of the most interesting unmanned aircraft missions begin with a sentence that sounds something like this:

We know what we want the aircraft to do. We just aren't sure the FAA will let us do it.

We have heard some version of that for years.

Flying higher than 400 feet. Operating closer to clouds. Going beyond visual line of sight. Testing new detect-and-avoid technology. Using ADS-B Out in a specific approved configuration. Operating an advanced aircraft in an environment that simply does not fit neatly inside standard Part 107 limitations.

These are rarely just regulatory problems.

In our experience, they are usually engineering, operational and regulatory problems all at once. And the strongest path to approval starts by treating them that way.

Applied Aeronautics has spent more than a decade supporting advanced UAS operations, including BVLOS work, high-altitude operations, operations closer to clouds, detect-and-avoid development and testing, and approvals involving ADS-B Out.

Along the way, we have learned quite a bit about what makes an operation easier to explain, easier to defend and, ultimately, safer to fly.

Start With the Mission, Not the Waiver

One of the easiest mistakes to make is beginning with the regulation.

“We need a BVLOS waiver.”

“We need to fly above 400 feet.”

“We need relief from cloud-clearance requirements.”

Those statements may all be true, but they are not really the beginning of the problem.

The better place to start is: What are we actually trying to accomplish?

Where does the aircraft need to go? How high? How far? For how long? In what airspace? What other aircraft might reasonably be there? What happens if a communications link fails? What happens if weather changes? What information does the remote pilot have available, and what decisions will that pilot need to make?

Once those questions are understood, the regulatory requirements become much easier to frame.

A strong waiver package has to do more than describe what you want permission to do. It has to show that you understand the risk you are introducing and that the mitigations you are proposing actually address that risk.

That sounds obvious.

In practice, it changes the entire way a program should be designed.

Crawl, Walk, Run

We are big believers in a crawl-walk-run approach to advanced operations.

If the eventual goal is to operate six miles away at 6,000 feet AGL, there is usually very little value in making the first test flight look exactly like the final mission.

Start closer.

Start lower.

Reduce the operating area. Validate the communications architecture. Build flight hours. Test lost-link behavior. Understand actual endurance with the payload installed.

Collect data on climb performance. Exercise emergency procedures. Add complexity deliberately rather than all at once.

Then move the boundary.

This does something important beyond making the flight-test program safer: it creates evidence.

There is a meaningful difference between saying, “We believe this communications system should work at this range,” and being able to show flight-test data demonstrating how it performed across progressively larger operating areas.

The same is true of detect and avoid, aircraft reliability, endurance, altitude performance and almost every other mitigation in an advanced operation.

We have found that the strongest programs build toward the difficult mission rather than beginning by asking everyone, including the FAA, to take the biggest possible leap on day one.

See and Avoid Doesn't Disappear Because the Pilot Is on the Ground

Aviation has always depended heavily on the idea of seeing other aircraft and avoiding conflicts.

Unmanned aviation makes that considerably more complicated.

The remote pilot is not sitting in the cockpit looking out the window. Once the aircraft moves beyond visual line of sight, the traditional visual picture becomes even less available. Yet the responsibility to safely share the airspace remains.

That is why detect and avoid has been such an important part of our work.

Through FAA ASSURE research with the University of North Dakota, University of Kansas and Embry-Riddle Aeronautical University, Applied Aeronautics did more than provide the aircraft. Our team helped build the detect-and-avoid system around Albatross and supported the flight testing used to evaluate cooperative and noncooperative traffic encounters and right-of-way concepts for BVLOS operations.

That work mattered because it forced us to look at detect and avoid as part of a complete operational system rather than as a single sensor.

The aircraft, avionics, communications, pilot interface, procedures and DAA technologies all had to work together. And once you begin testing those systems in the real world, you quickly see where theory ends and operational reality begins.

That experience still informs the way we approach BVLOS today.

We do not think of DAA as something you simply bolt onto an aircraft and call the problem solved. It has to be considered alongside command and control, aircraft behavior, the CONOPS, operating area and the decisions available to the remote pilot.

There is rarely one piece of technology that suddenly makes an operation “BVLOS capable.”

The capability comes from the way the system is designed, integrated, tested and operated as a whole.

Communications Need the Same Level of Attention

Command and control is another area where a specification sheet only gets you so far.

A radio may advertise an impressive range, but the more useful question is:

What happens when it doesn't work?

We spend a lot of time thinking about that.

Primary and secondary links. LTE and IP-based communications. Terrain masking. Antenna placement. Link quality monitoring. Failover. Lost-link behavior. What the aircraft does autonomously. What the pilot sees. How long the aircraft remains without communications before a contingency procedure begins.

Those details matter because redundancy alone is not enough.

Two communications links that fail for the same reason are not especially useful redundancy.

Likewise, a beautifully written lost-link procedure does not mean much if the aircraft has never actually demonstrated the behavior on which that procedure depends.

This is where engineering, flight testing and regulatory strategy have to stay connected.

The CONOPS should describe the system you actually built.

The test program should validate the assumptions in the CONOPS.

And the waiver application should tell the same story.

High Altitude Creates a Different Airspace Problem

Some of our most unusual approvals have involved operating well above the normal Part 107 ceiling.

Going higher means entering airspace where interaction with conventional aviation becomes a much more important part of the safety case.

We have supported high-altitude operations reaching thousands of feet above the launch point, and those missions require us to think well beyond whether the aircraft itself can climb that high.

What traffic is likely to be present? How will it be detected? What communications coverage exists throughout the climb? What weather will the aircraft encounter? Where are the airports and common traffic routes? What happens if the aircraft needs to descend unexpectedly?

We have also obtained approvals for operations closer to clouds than standard Part 107 limits would normally permit.

That kind of operation adds another layer of complexity around visibility, weather monitoring, traffic awareness and decision-making.

The lesson for us has never been that these rules are obstacles to overcome.

The lesson is that the reason behind the rule should tell you what problem your mitigation needs to solve.

Don't Add Technology Just Because It Sounds Safer

Advanced operations have a tendency to accumulate equipment.

Another radio.

Another receiver.

Another display.

Another sensor.

At some point, teams can begin equating more technology with more safety.

It doesn't necessarily work that way.

We have worked through approvals that included ADS-B Out transmission, for example, but that does not mean ADS-B Out should simply be added to every small UAS.

Its use has to make sense within the specific approval, airspace and operating concept.

The same principle applies to detect-and-avoid systems and communications redundancy.

A mitigation is valuable when it addresses an identified hazard.

The exercise should be:

Hazard → consequence → mitigation → validation.

Not:

Technology → justification for why we installed it.

That distinction sounds small, but it produces much better system design and much stronger regulatory applications.

Make It Easy to Understand the Operation

This may be one of the least technical lessons we have learned, but it is one of the most important.

Clarity matters.

An advanced UAS operation can involve aircraft performance, airspace, RF links, autonomy, human factors, weather, detect and avoid, emergency procedures and dozens of other details.

It is very easy to produce hundreds of pages of documentation and still leave the person reviewing it unsure about how the operation actually works.

A good package should make the story easy to follow.

What are you doing?

Where are you doing it?

What could go wrong?

How will you know when something is going wrong?

What prevents that situation from becoming unsafe?

What has been tested?

What will the pilot do?

What will the aircraft do?

Complex operation. Clear explanation.

That is the goal.

Engage Early Enough to Change the System

Another lesson: regulatory strategy should not begin after the aircraft has already been designed.

Sometimes customers come to us with an essentially finished system and ask for help getting a waiver.

We can do that.

But it is much easier when the regulatory requirements were considered earlier.

Perhaps the communications system needs redundancy. Perhaps the proposed operating area introduces unnecessary risk. Maybe the detect-and-avoid approach does not support the operation being requested. Perhaps a slightly different mission geometry makes the regulatory case substantially stronger without meaningfully changing the customer's objective.

If those conversations happen early, we can still change things.

That is one of the reasons our work increasingly spans the entire program: aircraft architecture, DAA integration, command and control, ground infrastructure, flight-test planning, risk assessment, CONOPS development and the waiver submission itself.

We do not believe those should be separate conversations.

The Goal Isn't the Waiver

This may be the biggest lesson of all.

The goal is not to get a piece of paper from the FAA.

The goal is to build an operation that deserves the approval.

When we approach advanced operations that way, the waiver stops being an exercise in convincing someone that the mission is safe and becomes an exercise in clearly documenting why it is safe.

That is a much better place to be.

It is also why we tend to work so closely with our partners through these programs.

We are an aircraft manufacturer, but by the time a customer is asking to fly BVLOS, operate thousands of feet above the ground, work closer to clouds or introduce new surveillance and detect-and-avoid technologies, the aircraft is only one piece of what has to work.

We help solve the rest of it too.

After years of FAA research programs, waiver applications, unusual operating envelopes and a lot of flight testing, our approach has become relatively simple:

Understand the mission.

Understand why the rule exists.

Design the system around the risk.

Test it progressively.

Collect evidence.

And only then ask to move the boundary.

That crawl-walk-run philosophy may not be the fastest way to get from an idea to the most ambitious version of an operation.