Detect and avoid, or DAA, is not a single sensor that makes a civil drone legal to fly beyond visual line of sight. It is an end-to-end safety function: detect relevant aircraft, form and maintain tracks, predict a conflict, provide usable guidance, complete an avoidance response in time, and show that the whole chain works in the intended environment. The best architecture is therefore the one supported by the aircraft, airspace, traffic, terrain, weather, communications, operator model, and approval basis in a specific concept of operations.

For most low-altitude BVLOS projects, cooperative traffic data should be one layer, not the only layer. Ground-based surveillance is often the practical choice for a fixed corridor or campus; airborne sensing follows an aircraft across changing routes; and a hybrid can combine early cooperative tracks with radar, electro-optical or infrared, or acoustic detection of non-cooperative traffic. In the United States, 14 CFR 107.31 still requires visual line of sight, and the FAA says DAA used for BVLOS is evaluated with the operation when it processes a waiver or exemption. The agency's proposed Part 108 framework is important, but it remains a proposal rather than an operating permission.

What a DAA system actually has to do

DAA replaces more than eyesight. Under 14 CFR 91.113, vigilance and right-of-way duties are framed around seeing and avoiding other aircraft. A remote operation must translate that safety intent into measurable system behavior.

The chain normally includes:

  1. Surveillance: receive cooperative reports or sense an aircraft directly.
  2. Tracking: associate detections over time and estimate position, velocity, confidence, and identity where available.
  3. Conflict prediction: determine whether the encounter is moving toward a defined loss of well clear or collision hazard.
  4. Alerting and guidance: tell a remote pilot what matters, or send bounded guidance to an automated function.
  5. Avoidance: command and complete a maneuver the aircraft can actually fly.
  6. Recovery and assurance: return safely to the mission, monitor degraded modes, and preserve data for continued safety analysis.

This distinction matters because a sensor can detect an intruder and the system can still fail. A track may arrive late, oscillate, merge with clutter, drop during a handoff, or produce guidance the aircraft cannot execute before the boundary is crossed. A supplier's maximum detection range does not establish DAA performance.

"Well clear" and collision avoidance are also different layers. Remaining well clear is the planned outcome. Collision avoidance is the last protective layer when separation has already eroded. Procurement language should identify which function is being supplied instead of using DAA, traffic awareness, and collision avoidance interchangeably.

Start with the operational design domain

The productive first question is not "Which radar has the longest range?" It is "Which encounters and conditions must this operation handle?" Define the operational design domain before selecting hardware:

  • route geometry, altitude, speed, and proximity to airports or heliports;
  • expected crewed traffic, including aircraft that may not broadcast;
  • terrain, structures, vegetation, RF congestion, and sensor siting;
  • day, night, visibility, precipitation, temperature, and wind limits;
  • aircraft turn, climb, descent, braking, and contingency performance;
  • command-and-control and surveillance-link availability;
  • one-aircraft or multiple-aircraft supervision; and
  • the required response to sensor, positioning, compute, or link degradation.

That definition should produce an encounter set and a timing budget. As an editorial engineering model, usable warning time can be viewed as the time from a credible track to the predicted safety boundary, minus tracking, communications, decision, command, and maneuver delays. Every term needs bounds, not just an average. A slower drone can still need long-range surveillance because a faster crewed aircraft may close quickly while the drone turns or descends slowly.

Comparing DAA architectures

No row in this table is a blanket recommendation. The entries describe common engineering tradeoffs; performance still has to be demonstrated in the intended installation and environment.

ArchitectureTraffic it can observePractical strengthsLimits to resolveCommon fit
Cooperative surveillance, such as ADS-B In, Mode S, or approved traffic dataOnly aircraft represented by the selected sourceEarly tracks, comparatively low onboard burden, identity and altitude may be availableUnequipped, silent, failed, delayed, erroneous, or unavailable sources; coverage and cybersecurity assumptionsA baseline layer in most mixed architectures
Airborne radarNon-cooperative traffic within its installed coverageDirect range measurement, follows the route, less dependent on visible lightSize, weight, power, antenna placement, electromagnetic compatibility, clutter, precipitation, and low closing-rate casesMobile routes and aircraft with enough payload and power margin
Electro-optical or infraredNon-cooperative traffic visible to the sensorPassive, potentially compact, can support classificationBackground contrast, haze, cloud, sun angle, darkness for visible cameras, occlusion, ranging, and processing loadConstrained environments or a complementary confirmation layer
Passive acousticSound-producing non-cooperative aircraftPassive, broad field of regard, potentially low size, weight, and powerWind, ownship noise, terrain reflections, quiet aircraft, localization accuracy, and environmental variabilityLower-noise operating areas or a complementary low-mass layer
Ground-based surveillance networkCooperative and/or non-cooperative traffic, depending on sensorsKeeps mass and power off the aircraft, can serve a fleet, maintainable at fixed sitesTerrain shadowing, siting, backhaul, handoffs, coverage ownership, and site-specific revalidationCorridors, campuses, ports, utilities, and repeatable service areas
Hybrid sensor fusionMixed traffic across complementary sourcesCross-checking, graceful degradation, and better coverage of different encounter typesIntegration complexity, source correlation, conflicting tracks, latency, software assurance, and evidence costOperations whose risk and scale justify a full system case

Cooperative surveillance is valuable but incomplete

ADS-B In can provide useful early awareness of broadcasting aircraft. It does not make every low-altitude aircraft visible, and an ADS-B track should not automatically be treated as timely, accurate, or authentic. An FAA-hosted 2025 contractor report on Sagetech airborne omni-directional surveillance describes flight tests of ADS-B and active Mode C/S surveillance. The contractor reported expected functions alongside track drops, validation anomalies, rapid switching between surveillance states, and alerting issues that warranted more analysis. Those are results from one evaluated configuration, not findings about every cooperative system. They illustrate why source validation, track selection, antenna installation, and dense-traffic behavior belong in the evidence plan.

FAA Remote ID is a different function. It broadcasts identification and location information for compliance and situational purposes. Its defined role does not make it a DAA sensor or a substitute for approved traffic surveillance. Treating the two as equivalent is an integration error.

Non-cooperative sensing is installation dependent

Radar is attractive because it can measure range without relying on an intruder broadcast. Yet "radar range" depends on the target, aspect, antenna coverage, installation losses, clutter, interference, probability of detection, false-track criteria, and required update rate. RTCA DO-366B reflects this system context by including air-to-air radar classes tied to ownship speed and maneuverability. A quoted range without its target and test conditions is not a comparable specification.

Optical, infrared, and acoustic systems exchange some radar burdens for environmental ones. Camera performance depends on contrast and visibility; acoustic performance depends on the sound field and platform noise. Their passive operation and lower potential burden can be useful, but evidence should span the actual operating limits. An FAA-contracted PANCAS acoustic DAA report used flight test and test-anchored simulation for a specific sensor, Puma aircraft, and government mission set. The contractor found that a rapid descent maneuver fit that aircraft better than a lateral maneuver in the studied cases. That is a valuable systems lesson, not a universal endorsement of acoustic sensing or vertical avoidance.

Ground-based DAA shifts sensor burden off the aircraft, but it also turns geography into part of the system. A new radar location, terrain profile, urban clutter environment, backhaul path, or coverage handoff can change the safety case. The FAA's current DAA criteria worksheet explicitly identifies ground-sensor location, sensor type, operational airspace, supplementary sensors, and UTM integration as changes that may require heightened documentation or evaluation.

Standards are scoped tools, not interchangeable badges

The relevant standard depends on aircraft size, altitude, airspace, encounter risk, and intended function.

  • ASTM F3442-25 is architecture agnostic and addresses smaller aircraft below 100 knots in the lower-risk environments described by its scope. It covers mixed cooperative and non-cooperative traffic and connects detection range, warning time, and well-clear performance. ASTM states that it is not a minimum performance standard intended for reference by a Technical Standard Order.
  • RTCA DO-365C Change 1 covers DAA systems for operations through Classes B, C, D, E, and G and extended operations above 400 feet in specified airspace. Its published scope says it does not apply to small UAS in low-level environments below 400 feet or other segmented areas.
  • RTCA DO-396 defines MOPS for ACAS sXu equipment intended for surveillance and performance characteristics typical of smaller UAS.

The exact revision, equipment class, assumptions, and allocation of requirements matter. "Designed to" or "tested against" a standard is a manufacturer or integrator statement unless supported by the required evidence and accepted in the relevant approval process.

A Technical Standard Order also has a narrow meaning. The FAA explains that a TSO authorization is a design and production approval for an article, not approval to install and use it on a particular aircraft. Operators should ask separately about article approval, installation approval, aircraft integration, operational authorization, and any limitations.

Regulation and approval status in the United States

The FAA describes UTM as complementary to air traffic services and says crewed-aircraft collision risk for BVLOS can be managed with visual observers or a DAA system that the agency evaluates during a waiver or exemption application. An approval issued for one operator, configuration, route, and set of limitations is evidence of that case. It is not a universal approval of a product family.

The FAA and TSA's 2025 BVLOS notice of proposed rulemaking would create Part 108 and proposes a combination of strategic deconfliction, conformance monitoring, electronic conspicuity, right-of-way changes, and DAA requirements that vary with airspace and operating category. As of this article's update date, it should be used for planning, not represented as final law. Design teams should preserve flexibility around interfaces, logs, and software updates while the rulemaking and associated means of compliance develop.

Build evidence around the complete response

The current FAA DAA worksheet asks for the system description and concept of use, simulation and live-aircraft methods, cooperative and non-cooperative risk ratios, false alerts, closest point of approach, and response time from detection through maneuver execution. That list is a good procurement baseline even when the worksheet is not the chosen approval path.

Human response belongs inside the timing budget when a person must interpret and act. In a NASA simulation involving 21 professional UAS pilots, success was much lower when alerts arrived less than about 15 seconds before predicted loss of well clear than when warning exceeded 15 seconds. The NASA paper describes a particular simulation and should not be treated as a universal alert threshold. It does show why a display screenshot and sensor range are insufficient substitutes for end-to-end human-in-the-loop evidence.

Evidence should combine analysis, simulation, bench testing, flight testing, and continued monitoring. Flight tests anchor the model in observed behavior; simulation explores the much larger encounter space that cannot safely or economically be flown. The model should include sensor uncertainty, nuisance and missed detections, track initiation, weather or clutter degradation, link delays, command latency, aircraft dynamics, pilot workload where applicable, and failure transitions. Configuration control then connects every result to the exact sensor, antenna, software, aircraft, site, and procedure evaluated.

Questions to ask a DAA supplier or integrator

  1. What exact operational design domain and encounter set support each performance claim?
  2. Which traffic is cooperative, non-cooperative, or outside the claimed coverage?
  3. Which standard, revision, equipment class, and requirement set are used, and where is traceability documented?
  4. What target type, aspect, closing speed, background, weather, and detection probability sit behind each quoted range?
  5. How are false detections, dropped tracks, duplicate tracks, stale data, and conflicting sensor reports handled?
  6. What are the measured worst-case latencies for sensing, track formation, communications, alerting, command, and maneuver completion?
  7. Which avoidance maneuvers were modeled and flown with this aircraft at its heaviest and least maneuverable approved condition?
  8. What happens after loss of surveillance, command link, positioning, compute, power, or a ground-site connection?
  9. For a remote pilot or fleet supervisor, what workload, alert prioritization, and multiple-aircraft assumptions were evaluated?
  10. Which tests were independent, which were supplier-run, and which claims have been accepted by an aviation authority for the proposed operation?
  11. What installation, calibration, inspection, software-update, cybersecurity, and continued-monitoring obligations remain with the operator?
  12. Which changes to aircraft, sensor, antenna, site, route, airspace, software, or procedures trigger regression testing or a new approval review?

The strongest proposal will answer these with bounded data and traceable reports. A long list of integrations or prior waivers is useful context, but it cannot replace evidence that matches the new operation.

A practical selection sequence

First, define the operation and approval path. Second, model relevant encounters and the aircraft's real avoidance performance. Third, select the least complex surveillance combination that covers cooperative and non-cooperative assumptions with suitable independence. Fourth, allocate a worst-case timing budget across the complete chain. Fifth, verify components, installation, human interaction, and maneuver execution, then anchor broader simulation to those results. Finally, establish configuration control and in-service monitoring before attempting to scale routes or aircraft per supervisor.

That sequence may produce a ground radar network for a repeatable utility corridor, an airborne radar and cooperative receiver for a mobile aircraft, or a carefully bounded passive system for a low-risk remote mission. The defensible choice is not the architecture with the most sensors. It is the architecture whose limits are explicit and whose evidence matches the operation.

Sources and scope

This guide uses U.S. regulations and FAA material as the primary regulatory frame, with current ASTM and RTCA scope pages and cited government-sponsored research for engineering context. The proposed Part 108 provisions are identified as proposals, and contractor findings are attributed to their authors rather than treated as FAA conclusions. Sources were accessed August 31, 2026. This is research-based implementation guidance, not legal advice, an approval finding, or a product certification.