How to Build a Safety Case for BVLOS and Autonomous Drone Operations

The next phase of drone operations will not be unlocked by aircraft capability alone. It will be unlocked by trust.

Beyond visual line of sight operations, usually shortened to BVLOS, require operators to prove that the whole system can manage risk when the aircraft is no longer being watched directly by a person standing nearby. That system includes the vehicle, sensors, software, command and control links, detect-and-avoid capability, operating procedures, training, maintenance, data services, airspace coordination, and human decision-making.

This is why a safety case matters.

A safety case is the structured argument that an operation is acceptably safe for a defined mission, environment, and level of complexity. It does not simply say, "The drone works." It explains how the operation works, what can go wrong, how risk is controlled, what evidence supports those controls, and how the organization will keep learning once flights begin.

For BVLOS and increasingly autonomous drone programs, that is the difference between a technology demonstration and an operational capability.

Why BVLOS Needs a Stronger Safety Argument

Visual line of sight operations keep one major safety layer close to the human pilot: direct observation. The remote pilot can see the aircraft, scan the area, notice nearby obstacles, and react when something changes.

BVLOS changes that relationship.

The operator may rely on surveillance data, weather services, route planning tools, onboard sensors, UAS traffic management services, automation, and procedural controls. The human is still responsible, but the human is now supervising through systems. That creates a different safety problem.

The Federal Aviation Administration's BVLOS rulemaking direction reflects this shift. The proposed Part 108 framework is built around scalable BVLOS operations, performance-based requirements, and third-party services that support operations such as UAS Traffic Management. NASA's UTM work also points in the same direction: safe low-altitude drone access depends on coordinated services, shared intent, weather awareness, separation management, and operator responsibility.

The lesson for engineering leaders is simple: the aircraft is only one part of the approval story. The operation is the system.

Start With the Exact Mission

The first mistake in a safety case is trying to prove that a drone is safe in general.

No aircraft, autonomy stack, or operating team is safe in every environment. Safety is always tied to a mission and context.

A serious BVLOS safety case should begin with a clear mission definition:

• What is the aircraft doing?
• Where is it flying?
• How far is it operating from the pilot or control station?
• What altitude, speed, payload, and route structure are expected?
• What airspace is involved?
• What people, property, infrastructure, and other airspace users may be affected?
• What data services or ground systems are required?
• What conditions stop the mission before launch or require termination in flight?

An infrastructure inspection route over a controlled corridor is not the same risk problem as package delivery across a dense urban area. Agricultural survey flights are not the same as emergency response near temporary flight restrictions, helicopters, smoke, and ground crews.

Define the mission tightly before trying to defend it.

Tie the Safety Case to the Operational Design Domain

Operational design domain, or ODD, is where the safety case becomes specific.

For a BVLOS drone operation, the ODD may include geography, airspace class, altitude band, route limits, population density, obstacle environment, weather, lighting, link coverage, GPS quality, aircraft configuration, payload, and operator staffing.

The ODD should not be treated as a marketing description. It is a safety boundary. It says where the system is intended to work and where it is not.

That boundary should connect directly to go/no-go criteria. If wind exceeds the aircraft limit, the mission does not launch. If GPS quality degrades beyond the defined threshold, the aircraft transitions to a contingency behavior. If command and control link quality falls below minimum performance, the system follows a documented lost-link procedure. If traffic density or weather changes in a way the operation cannot support, the route is delayed, modified, or terminated.

Good ODD discipline keeps autonomy honest.

Identify Hazards Across the Whole Operation

Hazard analysis should cover more than aircraft failure.

For BVLOS operations, common hazard families include:

• Loss or degradation of command and control
• Navigation error or GPS interference
• Detect-and-avoid failure or limited sensor coverage
• Unexpected crewed aircraft activity
• Weather changes, wind, turbulence, icing, precipitation, or visibility limits
• Battery, propulsion, flight control, or payload failure
• Route conflict, geofence error, or obstacle database mismatch
• Cybersecurity or data integrity issues
• Human workload, complacency, poor handoff, or delayed intervention
• Maintenance gaps, configuration drift, or software update errors
• Emergency landing site unavailability

The point is not to produce a long risk register for its own sake. The point is to understand the operation as a chain of dependencies. A BVLOS mission can fail because the aircraft fails, but it can also fail because a data feed is stale, a route assumption is wrong, a pilot is overloaded, or a procedure does not match the real environment.

Build Risk Controls That Are Testable

A risk control is only useful if it can be verified.

"The operator will maintain awareness" is not enough. What information will the operator see? At what update rate? With what alerting logic? What training supports that role? What happens if the display freezes or the aircraft behaves unexpectedly?

"The aircraft will avoid traffic" is not enough. What detect-and-avoid capability exists? What traffic types can it detect? What are the range, field of view, latency, false alarm, and missed detection assumptions? What maneuvers are authorized? What happens when the system is uncertain?

"The command link is reliable" is not enough. What coverage analysis supports the route? What link performance is required? How is link quality monitored? What lost-link behavior is programmed? How was that behavior tested?

The best safety cases translate broad claims into measurable controls. That is where engineering discipline shows up.

Treat Human Factors as a Core Safety Layer

Autonomy does not remove human factors. It changes them.

In BVLOS operations, the human may be supervising multiple systems, interpreting alerts, monitoring mission progress, coordinating with other people, and deciding when to intervene. The risk is not only that the automation fails. The risk is that the automation creates a situation the human cannot understand quickly enough.

Human factors questions belong in the safety case:

• What is the operator expected to monitor?
• How many aircraft or missions can one operator manage safely?
• Which alerts require immediate action?
• How are nuisance alerts controlled?
• What information is shown during abnormal conditions?
• How is authority transferred between automation and human decision-making?
• What training and recurrent evaluation are required?
• How are fatigue, workload, and procedure compliance managed?

This is especially important for highly automated systems. A human "in the loop" is not a safety control unless that human has time, information, training, authority, and a practical action to take.

Prove the Contingency Plan

Every BVLOS operation needs a credible answer to one question:

What happens when the system is no longer inside the plan?

Contingency planning should cover lost link, degraded navigation, low battery, propulsion fault, unexpected traffic, weather deterioration, route blockage, emergency landing, flyaway prevention, and post-incident reporting.

The plan should identify decision points, automated behaviors, human responsibilities, communication steps, and recovery options. It should also identify what evidence proves the plan works.

Simulation can help. Ground tests can help. Controlled flight tests can help. Tabletop exercises can help. But the safety case should make clear which contingencies have been tested, under what conditions, and with what results.

Untested contingency plans are assumptions. Tested contingency plans become evidence.

Use Evidence, Not Confidence

Advanced technology programs often fail when confidence moves faster than evidence.

A strong BVLOS safety case should include evidence from multiple sources:

• Requirements and traceability
• System architecture and interface descriptions
• Hazard analysis and risk assessments
• Verification and validation results
• Flight test data
• Simulation results
• Maintenance and reliability records
• Training records
• Software configuration controls
• Operational readiness reviews
• Incident, anomaly, and corrective action logs

The goal is not to bury decision-makers in documents. The goal is to make the argument inspectable. If a program claims the aircraft can handle a defined route, weather envelope, link environment, and contingency set, the evidence should support that claim.

This is where program leadership matters. Engineering teams need a culture where unresolved risk is visible, not hidden inside optimistic schedules.

Keep the Safety Case Alive

A safety case is not a one-time approval artifact.

BVLOS operations change over time. Routes expand. Aircraft configurations change. Software updates are released. Operators gain experience. Maintenance trends emerge. Weather patterns surprise the team. New hazards appear.

The safety case should be maintained as a living program asset. When the operation changes, the safety case should change. When incidents or anomalies occur, the safety case should absorb the lesson. When automation improves, the evidence should be updated. When the ODD expands, the risk argument should be rebuilt for the new domain.

This is how an organization avoids the trap of treating safety as paperwork.

The Leadership Lesson

The leaders who succeed in BVLOS and autonomous drone programs will not be the ones who simply push for more automation. They will be the ones who connect automation to accountable operations.

That means asking practical questions early:

• What operation are we actually trying to approve?
• What risks are unique to this route, airspace, aircraft, and team?
• What assumptions are we making?
• Which assumptions have evidence behind them?
• Where do humans still carry safety responsibility?
• What happens when the system exits its approved operating conditions?
• How will we learn after deployment?

Those questions may feel slower than a demo, but they are what allow a program to scale.

BVLOS is not just a regulatory milestone. It is an engineering leadership test.

Final Thought

Autonomous drone operations will mature when safety cases become as important as flight demos.

The future belongs to teams that can define the mission, bound the operating domain, analyze hazards, verify controls, design for human oversight, prove contingency behavior, and keep learning from real operations.

That is how BVLOS moves from permission to performance.

Sources And Further Reading

• FAA: Beyond Visual Line of Sight (BVLOS): https://www.faa.gov/newsroom/beyond-visual-line-sight-bvlos
• FAA: Beyond Visual Line of Sight (BVLOS) Fact Sheet: https://www.faa.gov/newsroom/fact_sheets/Fact_Sheet_BVLOS.pdf
• FAA: Normalizing Unmanned Aircraft Systems Beyond Visual Line of Sight Operations NPRM: https://www.faa.gov/newsroom/BVLOS_NPRM_website_version.pdf
• FAA: Unmanned Aircraft System Traffic Management: https://www.faa.gov/uas/advanced_operations/traffic_management
• NASA: UAS Traffic Management Project: https://www.nasa.gov/directorates/armd/past-armd-projects/utm-project/
• FAA and NASA: UAS Traffic Management Concept of Operations v2.0: https://www.faa.gov/sites/faa.gov/files/2022-08/UTM_ConOps_v2.pdf