Factory acceptance testing, or FAT, is the buyer’s opportunity to prove that a drone detection radar system is complete, configured, and behaving as expected before it leaves the manufacturer or integration facility. It is not a substitute for site acceptance testing, but it can remove many avoidable risks before equipment reaches the field.
For counter-UAS projects, a good FAT should answer a disciplined question: is the delivered radar system ready to be shipped, installed, connected, and tested on site? It should not claim that the system has already proven real site coverage, because buildings, terrain, clutter, mounting height, weather, and local RF conditions only become real after installation.
Define the FAT Scope Before the Test
The first FAT requirement is an agreed test plan. Without one, the session can become a demonstration instead of an acceptance test.
The plan should state:
- which hardware units are included;
- which firmware, software, and configuration versions are under test;
- which functions are mandatory pass/fail items;
- which functions are demonstrations only;
- what test equipment or simulators are allowed;
- how deviations will be recorded;
- and who has authority to accept, reject, or defer an item.
This scope is especially important for radar because some performance questions cannot be fully tested indoors or at a factory range. The FAT should be clear about what it proves and what must remain for SAT.
Confirm Hardware Build and Configuration Control
Before running functional tests, verify that the delivered system matches the order and the design baseline. This usually includes radar head, antenna or array, pedestal or mounting adapter, processor, power supply, cables, network equipment, weatherproof enclosures, connectors, spare parts, and required accessories.
Each item should be checked against serial numbers, model numbers, labels, and packing lists. Firmware and software versions should be recorded. Configuration files should be saved as the FAT baseline so the team can later tell whether a site issue comes from the environment or from an undocumented configuration change.
This step is easy to underestimate. Many commissioning problems start with mismatched versions, missing accessories, informal configuration changes, or unclear naming conventions.
Verify Basic Radar Health
A drone detection radar FAT should confirm that the radar powers on correctly, reports healthy status, communicates with its processor or platform, and maintains stable operation for the agreed test duration.
Useful checks include:
- power-on sequence and boot time;
- status reporting and fault messages;
- antenna or array self-checks;
- cooling, fan, or thermal status where relevant;
- compass, GNSS, inclinometer, or alignment sensor status where used;
- time synchronization and system clock behavior;
- network connectivity and data throughput;
- graceful restart and recovery after power interruption.
These tests do not prove operational detection range, but they prove that the system is stable enough to proceed to field installation.
Test Radar Detection Behavior With Controlled Inputs
Factory testing should include controlled ways to verify that the radar processing chain is functioning. Depending on the product and facility, this may involve a radar target simulator, loopback test, calibration fixture, controlled moving target, chamber test, or outdoor factory test area.
The goal is not to exaggerate range claims. The goal is to confirm that the radar can produce expected detections and tracks under known conditions.
The FAT should check:
- range, azimuth, elevation, or velocity reporting where applicable;
- track creation and track persistence;
- target ID or track numbering behavior;
- update rate and latency;
- alarm trigger behavior using test zones;
- behavior when a target appears, disappears, or crosses a boundary;
- and logging of test events.
If the factory test uses simulated targets, the report should clearly say so. Simulated inputs are useful for repeatability, but they do not replace live site validation.
Validate Track Output and Platform Integration
A counter-UAS radar usually becomes useful when its tracks appear correctly in a command platform, sensor-fusion layer, or customer security system. FAT should therefore include interface validation, not only radar stand-alone checks.
The team should verify:
- track data format and fields;
- coordinates, altitude, speed, heading, and timestamp behavior;
- sensor naming and unit identification;
- map display and zone alignment;
- alarm rules and event priorities;
- API, SDK, VMS, or C2 integration where required;
- export formats such as logs, CSV, KML, GeoJSON, or vendor formats;
- and whether the receiving platform handles loss, reconnect, and duplicate data correctly.
If EO/IR cueing is part of the delivery, FAT can test camera handoff using simulated or controlled tracks. The final accuracy of installed cueing still belongs in SAT, because real mounting geometry and calibration matter.
Check Cybersecurity and Access Basics
FAT is also a good time to verify basic security hygiene. This does not replace a formal cybersecurity audit, but it can prevent obvious deployment problems.
Useful checks include:
- account roles and password policy;
- disabled default credentials;
- network ports and services;
- encrypted access where required;
- audit logs and operator activity records;
- backup and restore procedures;
- firmware update method;
- and how remote support access is enabled or disabled.
For critical sites, these items should be part of the acceptance record rather than informal setup notes.
Review Documentation and Handover Materials
A radar can pass a technical demonstration and still fail as a deliverable if the documentation is incomplete. FAT should include a documentation review.
At minimum, check:
- final bill of materials;
- serial number list;
- firmware and software version list;
- configuration baseline;
- interface control document;
- installation drawings or mounting guidance;
- power, grounding, and network requirements;
- maintenance instructions;
- spare parts and packing list;
- FAT report template and raw logs;
- open issues and corrective action list.
These materials help the site team install and test the same system that passed FAT.
Decide What Must Wait for SAT
A mature FAT explicitly states its limits. It should not pretend to prove the installed system’s full operational performance.
The following should normally remain for SAT:
- real site coverage and blind spots;
- low-altitude line of sight;
- local clutter and false alarm behavior;
- performance against representative live targets;
- camera cueing accuracy after final alignment;
- real network latency and redundancy;
- operator workflow under site procedures;
- alarm escalation with security and public-safety partners;
- environmental behavior in the installed position.
This separation protects both buyer and supplier. The supplier is not blamed for site variables before installation, and the buyer does not accept site performance based only on a factory demonstration.
Build a Clear FAT Result
At the end of FAT, every test item should have a status: pass, fail, conditional pass, deferred to SAT, or not applicable. Deviations should include owner, due date, and evidence required for closure.
The final FAT package should include:
- signed test checklist;
- photos or screenshots where useful;
- test logs and data exports;
- version and configuration baseline;
- deviation list;
- corrective action plan;
- packing approval;
- and the agreed SAT carryover list.
This package becomes the bridge between factory testing and site commissioning.
Conclusion
Factory acceptance testing for drone detection radar is not a ceremonial milestone. It is the point where the buyer and supplier prove that the system is correctly built, configured, documented, and ready for site deployment.
The best FAT plans are specific about what the factory can prove: hardware completeness, radar health, controlled detection behavior, track output, interface readiness, alarm logic, security basics, and documentation. They are just as specific about what the factory cannot prove: real installed coverage, clutter behavior, line of sight, and operator performance in the live site. When that boundary is clear, FAT reduces project risk and makes SAT faster, fairer, and easier to interpret.