How to Field-Test and Accept a Drone Detection Radar System

10:47

A drone-detection radar should be accepted against the buyer’s approved target set, site geometry and response workflow—not against a supplier-controlled demonstration alone. The test plan must distinguish product function, project coverage and end-to-end operational performance, then retain enough data for the result to be independently reviewed. Use the parent Drone Detection & Low-Altitude Surveillance Radar Procurement Guide for the approved procurement baseline and the RFI/RFP guide for the controlled supplier response and evidence schedule.

1. Freeze the Site Basis and Coverage Assumptions

Before the first test run, freeze the exact site configuration that the result will represent: installed sensor coordinates and heights, software and algorithm versions, active zones, clutter maps, camera calibration, network path, time source and approved coverage drawing. Acceptance evidence is invalid if these inputs change without a controlled record.

The test baseline should also identify every provisional assumption inherited from design, including temporary obstructions, incomplete civil works, weather limitations, unavailable interfaces and sectors that cannot yet be exercised. Classify each item as an accepted limitation, a test precondition or a defect requiring closure.

Record a configuration hash or controlled export for radar, camera and platform settings where the equipment permits it. At minimum, preserve dated configuration files and screenshots so a later retest can reproduce the accepted state.

2. Define the Test Stage and Decision

Stage	Primary decision	Typical location
Proof of concept	Can the proposed architecture address the threat and interface concept?	Supplier or representative site
Pre-award field trial	Can the offered configuration perform under buyer-relevant targets and conditions?	Buyer site or technically representative site
Factory acceptance test	Was the contracted configuration built, configured and documented correctly?	Supplier facility
Site acceptance test	Does the installed system meet the contracted project requirements?	Deployment site
Operational acceptance period	Is performance sustainable during routine operation?	Deployment site over an agreed period

A successful proof of concept does not replace SAT, and a supplier-site demonstration does not prove the buyer’s coverage. State which decision each stage supports and which unresolved risks remain after it.

3. Build the Representative Field-Test Plan

A field trial should test the proposed system against the buyer’s operating conditions. A demonstration at a supplier-controlled site can confirm basic function, but it does not prove coverage or false-alarm performance at the deployment site.

The test plan should define the target, route, altitude, speed, approach direction, weather, system settings, ground truth, success criteria, data to be recorded and procedure for retesting. It should also distinguish a proof of concept, factory acceptance test, site acceptance test and operational acceptance period.

Test Scenario	What to Measure	Example Contract Output
Nominal approach	Detection, track initiation and stable tracking on a representative route	Range and continuity report with ground-truth comparison
Hover / slow movement	Low-velocity behavior and track retention	Maximum permitted drop duration and reacquisition behavior
Crossing and receding paths	Aspect sensitivity and track continuity	Track completeness across defined sectors
Multiple simultaneous targets	Track separation, ID stability and capacity	No unacceptable track swaps or duplicate tracks
Bird and environmental activity	False alerts, classification output and operator workload	Measured performance over an agreed observation period
EO/IR slew-to-cue	Coordinate conversion, latency and target acquisition	Target appears within the agreed camera field of view and time
Degraded communications	Buffering, failover, alarm and recovery behavior	Defined recovery without silent data loss
Sensor or server fault	Health monitoring, redundancy and event logging	Fault detected, reported and handled according to the SLA
Night / adverse conditions	Performance under relevant visibility and weather conditions	Recorded limitations and accepted operating envelope

Do not copy generic thresholds into the contract without validating them against the site and response workflow. A requirement such as “target in frame within five seconds” may be appropriate for one camera geometry and too slow or unrealistic for another. The acceptance criterion should be derived from the operational need and demonstrated with the proposed equipment.

All test data should be retained in an agreed format. The buyer should receive event logs, tracks, timestamps, ground-truth records, configuration settings and a signed test report. A pass/fail statement without underlying evidence is not sufficient for a complex surveillance project.

How to Field-Test and Accept a Drone Detection Radar System

4. Define Targets, Routes and Ground Truth

The target schedule should identify the representative multirotor or fixed-wing class, physical dimensions or agreed RCS basis, payload condition, speed, altitude, route, approach direction and operating mode. Include radial, tangential, crossing, receding, hovering and low-clutter or high-clutter cases where they are operationally relevant.

Ground truth can be established through surveyed waypoints, GNSS telemetry, synchronized video, independent tracking equipment or a combination of methods. Define the authoritative clock, permitted offset and uncertainty before testing. Preserve the ground-truth source, raw timestamps and synchronization evidence; otherwise detection range, latency, cueing error and track accuracy cannot be assessed defensibly.

5. Measure Detection, Tracking and Classification Separately

Performance stage	What to record
Initial detection	First valid detection time and range under the agreed confirmation rule
Track initiation	Time and position at which a tentative or confirmed track is created
Stable tracking	Track continuity, permitted losses, reacquisition and update rate
Classification	Class label, confidence, latency, unknown handling and error cases
Alarm generation	Zone logic, alarm delay, suppression and operator acknowledgement
Data export	Timestamp, identity, coordinates, update rate and external-platform receipt

A brief weak return should not be counted as stable tracking. Define the confirmation rule, permitted gap, reacquisition behaviour and track-quality threshold before testing.

6. Observe False Alarms Under Real Operating Conditions

False-alarm performance should be observed with the normal site activity present: birds, vehicles, vegetation, machinery, waves, precipitation and authorized aircraft where applicable. Record the observation duration, active zones, sensitivity settings, software version and operator interventions. A laboratory classification percentage is not a substitute for nuisance-alarm performance at the site.

7. Test Radar-to-Camera and External-Platform Integration

The integration test should measure the complete chain from radar track creation to target presentation in the camera and command platform. Verify coordinate frames, terrain or height assumptions, timestamps, network latency, PTU motion and settling, boresight calibration, field-of-view selection, handover, event mapping and track identity. A statement that the radar can export coordinates is not an acceptance result. Use the radar-vision fusion architecture as the adjacent system reference for interface and cueing scope.

Integration checkpoint	Acceptance evidence
Track message	Captured message with identity, time, coordinates and quality fields
Coordinate conversion	Known-point or representative-track error record
Camera cueing	Target-in-frame result at defined range and field of view
Video and metadata	Synchronized recording with event and track association
Failure handling	Documented behaviour during sensor, network or service interruption
External platform	Alarm, track and acknowledgement visible in the proposed operational client

8. Define Repeatability, Retest and Exception Rules

The plan should state how many runs are required, whether results are evaluated per run or across a defined series, and what constitutes an invalid run. Define retest rights for weather interruption, target deviation, equipment fault and buyer-observed anomaly. A failed scenario should not be replaced by an easier route or different system setting without a controlled change record.

If the supplier tunes clutter filters, classification thresholds or alarm zones during the trial, record the change, time and reason. The final accepted configuration should be exported and protected as the baseline for later FAT, SAT or operational monitoring.

How to Field-Test and Accept a Drone Detection Radar System

9. Retain the Evidence Package

Approved test plan, site drawing, target schedule and configuration baseline.
Raw tracks, event logs, original video, interface captures and ground-truth records.
Weather and environmental observations, software versions and system settings.
Pass/fail calculation, exceptions, retests and corrective actions.
Signed report with responsible parties and unresolved limitations.

10. Link Contract Milestones to Measurable Outputs

Payment milestones should be tied to controlled deliverables such as approved design documents, successful FAT, delivered equipment, completed installation, passed SAT and closure of agreed punch-list items. Avoid milestones based only on shipment or power-on when the contract objective is an integrated surveillance capability.

11. Include an Operational Acceptance Period Where Risk Justifies It

A short SAT may not expose seasonal clutter, intermittent network faults, operator workload or performance drift. For high-value sites, define an operational acceptance period with the approved configuration locked, routine maintenance recorded and representative alarm statistics reviewed. The period should identify permitted corrective actions, software-change control, uptime calculation, unresolved-defect handling and the evidence required for final closure.

Operational acceptance should not silently introduce new requirements. It verifies sustained delivery of the contracted capability and closes defects that could not be evaluated during the scheduled test window.

Conclusion

A defensible field test is repeatable, target-specific, site-aware and evidence-backed. It separates initial detection from stable tracking, measures false alarms and integration, records synchronized ground truth and retains the underlying data. The resulting acceptance decision can then be incorporated into the contract without relying on brochure language or an undocumented demonstration.

FAQ

Should testing be performed only at the supplier site?

No. Supplier-site testing can confirm basic function, but project coverage, clutter and integration must be verified at the deployment site or a technically representative location.

How long should false alarms be observed?

The period should represent the site’s normal activity and risk. Define the duration and operating conditions in the test plan rather than using an undocumented short demonstration.