Digital Twins Should Become the Test Range for Autonomous UAS Assurance

Digital Twins Should Become the Test Range for Autonomous UAS Assurance

Autonomous aircraft programs eventually run into a simple problem: the real world is too large to test one flight at a time.

That is especially true for unmanned aircraft systems moving toward beyond visual line of sight operations. A BVLOS drone may need to operate across changing weather, varied terrain, intermittent communications, evolving traffic conditions, different ground-risk environments, and unusual failure combinations that rarely appear during a clean demonstration flight.

Flight testing is still essential. But flight testing alone is not enough to prove that an autonomous UAS is ready for scale.

The better path is to treat the digital twin as part of the assurance system.

Not as a glossy animation. Not as a sales demo. Not as a generic simulator that produces impressive screenshots.

A useful digital twin is an engineering environment that connects requirements, aircraft configuration, operating conditions, autonomy behavior, telemetry, test cases, and safety evidence. It helps the team ask the question that matters most: how does this system behave across the conditions we cannot afford to discover casually in the field?

For autonomous UAS leaders, the digital twin should become the test range where the safety case is rehearsed, challenged, updated, and defended.

BVLOS Scale Creates Too Many Edge Cases for Flight Test Alone

The FAA's proposed Part 108 framework points toward more routine BVLOS operations for unmanned aircraft systems. That is a major step for the industry because it moves the conversation from isolated approvals toward repeatable operating models.

But routine operations do not make the engineering problem smaller.

They make it larger.

An aircraft that flies one route under close supervision has a limited assurance burden. A fleet that flies many routes, under different environmental conditions, with increasing levels of automation, has a much broader burden. The program has to understand normal behavior, degraded behavior, failed behavior, recovery behavior, and human-supervision behavior.

That creates more test combinations than a practical flight campaign can cover directly.

Consider a few variables:

• route geometry
• wind, visibility, and precipitation
• terrain and obstacle data quality
• command-and-control link performance
• navigation uncertainty
• detect-and-avoid assumptions
• aircraft weight and energy margins
• autonomy software version
• sensor degradation
• contingency procedures
• operator workload
• traffic encounter scenarios

Each variable matters. But the combinations matter even more.

A program can run selected flight tests to validate real-world performance. It cannot safely or economically fly every meaningful edge case. That is why digital engineering matters. The goal is not to replace flight test. The goal is to make flight test smarter by using simulation to explore the operating envelope before, during, and after field operations.

A Digital Twin Is Only Useful If It Is Tied to the Real Configuration

Many teams say "digital twin" when they really mean "model."

That difference matters.

A model can be useful. But an assurance-grade digital twin needs to stay tied to the system it represents. If the aircraft software changes, the simulation assumptions should change. If the sensor package changes, the performance model should change. If the route environment changes, the terrain, obstacle, airspace, and weather assumptions should be reviewed. If flight data shows behavior that differs from the model, the twin should be updated.

The digital twin becomes weak when it drifts away from the configured system.

That is a configuration-management problem, not just a simulation problem.

For autonomous UAS programs, leaders should be able to answer:

• Which aircraft configuration does this simulation represent?
• Which autonomy software version is under test?
• Which sensor models, vehicle dynamics, and communications assumptions are being used?
• Which route class or operational design domain does the scenario represent?
• Which requirements or hazards does the simulation support?
• Which flight-test results have been used to calibrate the model?
• Which assumptions remain unvalidated?

If those answers are unclear, the digital twin may still be useful for engineering exploration. But it should not be treated as strong assurance evidence.

The Digital Twin Should Attack the Safety Case

A safety case is not a collection of optimistic statements. It is an argument backed by evidence.

That evidence has to show that the system can operate within defined limits, respond to credible failures, and keep risk controlled when conditions change. A digital twin can help build that evidence when it is designed around the safety argument.

The program should use simulation to challenge claims such as:

• The aircraft remains inside its operational envelope under expected weather variation.
• The autonomy system detects and responds to route deviations within the required time.
• Lost-link behavior keeps the aircraft within acceptable risk boundaries.
• Detect-and-avoid assumptions remain valid under defined encounter scenarios.
• Operator alerts are presented early enough for useful human action.
• Energy reserves are sufficient for contingency routes.
• Terrain and obstacle data quality support the mission profile.
• Multiple aircraft can be supervised without overloading the human role.

This is where digital twins can provide serious value. They allow the team to run difficult scenarios repeatedly, change one variable at a time, and identify where the safety argument is thin.

The strongest programs do not use simulation to prove that everything works. They use it to find where the system is fragile before the field finds it for them.

Simulation Evidence Needs Verification Discipline

There is a trap here: a digital twin can create false confidence if the simulation itself is not trusted.

A high-fidelity environment does not automatically produce high-quality evidence. The model has to be verified and validated for the purpose it is being used for.

That means the program should distinguish between different uses of simulation:

• early concept exploration
• requirements development
• autonomy algorithm testing
• route-risk analysis
• operator training
• contingency rehearsal
• certification or approval evidence
• post-flight anomaly reconstruction

Those uses do not all require the same fidelity. A concept model can tolerate rough assumptions. Approval evidence needs tighter traceability. Training simulation needs realistic cues and timing. Anomaly reconstruction needs enough fidelity to explain what happened without inventing certainty.

NASA's autonomy verification and validation work has emphasized that autonomous aerospace systems create difficult assurance problems because behavior depends on complex interactions between software, environment, sensors, human roles, and operating context. That is exactly why simulation evidence must be managed carefully.

The question is not "Do we have a digital twin?"

The better question is: "Which claims can this digital twin credibly support?"

Telemetry Should Close the Loop

A digital twin becomes more powerful when it learns from operations.

Flight telemetry can show where the model was right, where it was wrong, and where the operating environment is changing. That feedback loop is what turns simulation from a planning tool into a continuous assurance tool.

Useful telemetry can include:

• route deviations
• navigation uncertainty
• command-and-control link quality
• alert frequency and timing
• operator response times
• contingency triggers
• energy margins
• wind and weather exposure
• sensor performance
• autonomy mode transitions
• manual interventions
• post-flight anomaly findings

The team should use that data to recalibrate assumptions, adjust scenario libraries, update limits, and refine training.

For example, if field data shows recurring communications degradation along a specific route segment, the digital twin should reproduce that condition and test the impact on lost-link procedures, energy margins, and operator workload. If a software release changes alert timing, the simulation library should help determine whether the human still has enough decision time in degraded cases. If a terrain model produces altitude-planning errors in certain environments, the route assurance process should change before the next expansion.

That is the real value: simulation and operations informing each other.

Program Leaders Need a Scenario Library, Not Random Demos

Digital twin work can become scattered if every team builds its own demonstration scenario.

Autonomous UAS programs need a controlled scenario library.

That library should include the normal missions the aircraft is expected to fly, the degraded states it must survive, and the edge cases that define the safety argument. Each scenario should map back to requirements, hazards, operational limits, or approval evidence.

A strong scenario library includes:

• nominal route operations
• weather boundary cases
• detect-and-avoid encounters
• lost-link events
• degraded navigation
• sensor dropouts
• energy-margin stress cases
• contingency reroutes
• geofence and route-conformance issues
• operator alert overload
• simultaneous fleet events
• post-maintenance regression tests

The library should also be version controlled. When the aircraft configuration changes, the program should know which scenarios must be rerun. When a requirement changes, the scenario set should reflect it. When a field anomaly occurs, the team should add or improve a scenario that captures the lesson.

This is practical engineering leadership. It turns simulation into a repeatable program asset instead of a one-time technical exercise.

Digital Twins Help Leaders Make Better Scale Decisions

The most useful digital twin outputs are not just charts. They are decisions.

A mature program can use simulation evidence to decide whether to expand a route, increase aircraft-to-operator ratios, approve a software release, adjust an operational limit, add a sensor requirement, change training, or delay deployment.

That matters because autonomous UAS programs often face pressure to scale before the assurance system is ready.

The digital twin gives leaders a disciplined way to slow down the right things and accelerate the right things. It can show where the system has margin, where evidence is strong, where assumptions are still weak, and where field testing should focus next.

The leadership value is not technical glamour. It is decision quality.

The Leadership Lesson

Autonomous UAS programs should stop treating digital twins as optional innovation theater.

They should treat them as part of the assurance architecture.

BVLOS scale requires evidence across more conditions than flight testing can cover alone. A well-managed digital twin can connect simulation, configuration control, telemetry, scenario design, human factors, and safety-case reasoning into one practical system.

The standard should be simple:

If the digital twin supports an operational decision, it must be traceable.

If it supports a safety claim, it must be validated for that claim.

If it reveals a weak assumption, leadership should act before the field exposes it.

That is how autonomous systems mature.

Not by replacing real-world testing, but by making every real-world test part of a stronger engineering loop.

Read Next

• Verification Credit Strategy Turns UAS Test Evidence Into BVLOS Approval
• Configuration Baselines Are the Discipline BVLOS Autonomy Needs Before Scale
• Continuous Assurance Keeps Autonomous UAS Approval From Going Stale
• Operational Telemetry Governance Is the Backbone of Scalable BVLOS

Sources

• Federal Register, "Normalizing Unmanned Aircraft Systems Beyond Visual Line of Sight Operations": https://www.federalregister.gov/documents/2025/08/07/2025-14992/normalizing-unmanned-aircraft-systems-beyond-visual-line-of-sight-operations
• FAA, "Drone Integration: Concept of Operations," May 2025: https://www.faa.gov/uas/resources/policy_library/Drone-Integration-Concept-of-Operations-May-2025.pdf
• NASA Technology Transfer, "Near-Real Time Verification and Validation of Autonomous Flight Operations": https://technology.nasa.gov/patent/TOP2-320
• NASA Technology Transfer, "Digital Twin Simulator of the National Airspace System": https://technology.nasa.gov/patent/TOP2-325
• NASA NTRS, "Autonomy Verification & Validation Roadmap and Vision 2045": https://ntrs.nasa.gov/citations/20230003734