A layered counter-UAS architecture connects detection, tracking, verification, command and authorized response through defined interfaces. Its strength comes from independent evidence, controlled decisions and graceful degradation—not from adding the largest number of devices.
System engineering begins by defining the protected outcome and working backward. The required warning time determines where observation must begin. The target set and environment determine which observables are useful. The response process determines which evidence and latency are necessary.
This guide presents a reference architecture for fixed and mobile projects. It does not prescribe one universal product list. Instead, it shows what each layer must contribute, how information should move and how the complete workflow can be accepted.
Architecture Begins Before the First Sensor
Layer zero is governance: mission, authority, stakeholders, protected zones, data rules and concept of operations. It determines what the technical system is allowed and expected to do.
The architecture team should define normal activity, target assumptions, required warning time, staffing, interfaces and acceptable degraded modes. It should explicitly separate detection-only functions from functions that require additional authority.
| Layer-zero decision | Required output | Why it controls the design |
|---|---|---|
| Protected outcome | People, operations, assets and consequences to protect. | Prevents sensor coverage from becoming the only project objective. |
| Target profile | Priority targets, behaviors, observables and uncertainty. | Determines which sensors and tests are relevant. |
| Zones and timing | Awareness, assessment and protected zones with decision-time goals. | Connects range, latency, workflow and response. |
| Authority | Permitted detection, data and response actions by role. | Stops product capability from being confused with legal permission. |
| Operating model | Staffing, escalation, partner coordination and evidence requirements. | Shapes interface, alarms, communications and availability. |
Layer 1: Detection and Initial Observation
The detection layer converts physical or electromagnetic observables into time-stamped observations. It can include passive RF sensors, radar, EO/IR cueing, acoustic sensing or cooperative identification data.
Each observation should include source, time, location or bearing where available, quality, classification or signal information, and health context. “No alert” is not enough to determine whether the area is clear if the sensor is offline or outside its operating envelope.
Design detection for complementary observables
RF can provide information about supported links, radar can observe non-cooperative motion, and imagery can support visual assessment. A layered design selects independent evidence that addresses the actual target gaps rather than duplicating the same limitation.
Layer 2: Track Formation and Association
Raw observations become useful when the platform creates coherent tracks. Track formation estimates movement over time. Association decides whether new observations belong to an existing track, a new object or an unrelated event.
This layer needs synchronized time, common coordinates, uncertainty representation and rules for duplicates. A system can appear visually clean while making hidden association errors, so replay and source inspection are important.
| Track function | Required behavior | Failure to test |
|---|---|---|
| Initiation | Create a track from sufficient evidence without excessive delay. | Late warning or too many brief nuisance tracks. |
| Update | Incorporate new observations with quality and time awareness. | Jumping positions or unstable confidence. |
| Association | Link observations to the correct target and preserve provenance. | Merged targets, duplicated tracks or false correlation. |
| Coasting | Handle short observation gaps without inventing certainty. | Premature track loss or misleading continuation. |
| Termination | Close a track using documented conditions and preserve its history. | Persistent stale tracks or incomplete incident records. |
Layer 3: Classification, Identification and Verification
Classification assigns a broad class such as drone, bird or unknown. Identification associates more specific information when reliable data exists. Verification adds independent evidence so the operator can assess relevance.
These terms should not be used interchangeably. An RF signature may suggest a supported model family. Radar may support a motion-based class. EO/IR may show an object consistent with a drone. None of these alone necessarily identifies the operator or establishes intent.
Preserve uncertainty and the unknown class
A system that always produces a confident known label can be less trustworthy than one that retains “unknown.” Buyers should request confidence definitions, representative validation and a confusion matrix for the classes used in acceptance.
Verification is an operational workflow
Verification may involve a camera cue, a second sensor, an authorized-flight check, a patrol observation or coordination with another agency. The platform should show which steps occurred, who performed them and what evidence was available.
Layer 4: Command, Control and the Common Operating Picture
The command layer presents relevant information, manages roles and records decisions. It should prioritize events without hiding source data. Operators need zones, tracks, contributing sensors, imagery, health, confidence, checklists and communications in one controlled workflow.
Integration can connect video management, physical security, GIS, notification or incident-management systems. Each interface should have a documented data owner, protocol, authentication method, time source, failure behavior and version policy.
| Command capability | Minimum requirement | Useful acceptance scenario |
|---|---|---|
| Role management | Least privilege for viewing, configuration, export and response. | Verify operator, supervisor, maintainer and administrator permissions. |
| Alarm management | Priority, acknowledgement, disposition, escalation and closure. | Run simultaneous alarms and an unacknowledged escalation. |
| Evidence | Source, timestamps, history, imagery, user action and export. | Reconstruct an event from detection through closure. |
| Health monitoring | Sensor, server, storage, time and communication state. | Disconnect a sensor and verify visible degraded-state handling. |
| External integration | Secure, versioned interface with quality and error information. | Interrupt and restore the interface without losing control of the workflow. |
Layer 5: Decision and Authorized Response
The decision layer applies the approved concept of operations. The platform can guide and record the process, but it should not turn an uncertain detection into an automatic hostile determination.
Responses may begin with notifications, operational precautions, dispatch and evidence preservation. Only legally authorized organizations should consider active RF, takeover, interdiction or other mitigation, and those functions require separate safety, spectrum, legal and operational controls.
Human control and safe state
Authorized mitigation should require clear user identity, permission, target or sector selection, positive action, status feedback and termination. Define what happens after loss of power, network, command, time synchronization or sensor evidence. The safest behavior may be to prevent or stop an action.
Cross-Cutting Layer: Communications, Time and Data
All functional layers depend on infrastructure that is easy to overlook. Bad timestamps can break fusion. Unstable communications can create stale tracks. Inconsistent coordinate systems can place a target in the wrong zone. Insufficient storage can remove evidence before an incident is reviewed.
- Use a documented time hierarchy and alarms for loss or drift of synchronization.
- Define coordinate reference, sensor orientation, calibration and survey accuracy.
- Size networks for raw and processed data, management, video and failover.
- Prioritize control and health messages when bandwidth is constrained.
- Define local buffering, replay and recovery after a communication outage.
- Set retention by data type and protect the integrity of incident exports.
Cross-Cutting Layer: Cybersecurity and Resilience
Resilience is the ability to continue the required mission when a component fails or the environment changes. Redundancy helps only when common dependencies and failure modes are understood.
A design can use overlapping sensor coverage, local edge processing, redundant power, alternate communications and server recovery. It should also expose degraded state to the operator instead of silently presenting an incomplete picture.
| Failure scenario | Expected degraded behavior | Recovery evidence |
|---|---|---|
| One sensor unavailable | Continue with remaining evidence and mark the affected coverage or confidence. | Alarm, coverage impact, operator message and restoration record. |
| Network interruption | Buffer local data where designed and prevent stale data from appearing current. | Outage status, local operation, resynchronization and no duplicate incident. |
| Server restart | Restore approved configuration and active-state handling safely. | Recovery time, audit continuity, configuration hash and operator notification. |
| Time-source loss | Flag unreliable correlation and prevent silent timestamp drift. | Visible health state, fallback hierarchy and reconciliation after recovery. |
| Storage limit | Protect priority incident data and raise capacity alarms. | Retention policy, overwrite behavior, export and capacity restoration. |
Reference Architecture for a Fixed Site
A fixed site often uses distributed sensors connected to a local or centralized command platform. The design should provide overlapping evidence in priority zones, continuous health monitoring and maintainable installation.
Typical fixed-site flow
Passive RF and radar observations enter edge or central processing. Track management associates evidence. A camera may be cued for verification. The command platform applies site zones and authorized-flight data, then presents an alarm to the operations team. The operator follows the approved escalation and records the outcome.
- Survey terrain, structures, line of sight, RF background, lightning and maintenance access.
- Design sensor placement around required warning time and target geometry, not a decorative perimeter.
- Use secure network segmentation and local recovery appropriate to the site criticality.
- Document calibration, coordinates, orientation and as-built coverage assumptions.
- Plan seasonal and post-construction revalidation.
Reference Architecture for Mobile and Temporary Operations
Mobile and temporary systems trade permanent infrastructure for rapid setup. They need simple configuration checks, portable power, local evidence, reliable communications and a clear method to establish zones at each location.
A mobile architecture may use a handheld RF detector, portable radar or optical observation, a field command display and reach-back communications. The team should record the location, time, configuration and environmental survey for every deployment.
| Mobile requirement | Design response | Pre-operation check |
|---|---|---|
| Rapid setup | Stored profiles with controlled site-specific values. | Coordinates, orientation, time, zone and sensor self-test. |
| Changing RF environment | Local survey and configurable detection plan. | Identify strong local emitters and verify supported bands. |
| Limited power | Power budget, battery health and safe shutdown. | Runtime estimate, spare power and recovery test. |
| Intermittent backhaul | Local processing, buffering and controlled synchronization. | Offline workflow and restoration without duplicate records. |
| Small team | Prioritized alarms, simple roles and concise checklists. | Operator readiness, contact list and evidence export. |
FAT and SAT for a Layered System
Factory acceptance should verify the supplied configuration, interfaces, user roles, logging, sensor simulation or controlled inputs, fault behavior and documentation. Site acceptance should verify installation, coverage, representative targets and the complete operator workflow.
| Test domain | Factory acceptance test | Site acceptance test |
|---|---|---|
| Assets and configuration | Model, quantity, software, licenses, accessories and baseline. | Installed inventory, coordinates, calibration, network and as-built record. |
| Sensor function | Controlled observations, messages, health and failure states. | Representative routes, target types, geometry, clutter and repeatability. |
| Fusion and tracking | Time, association, duplicate handling, replay and uncertainty. | Crossing tracks, sensor handover, partial obstruction and track loss. |
| Command workflow | Roles, alarm rules, evidence, notification and audit. | Real staffing, acknowledgement, escalation, reporting and recovery. |
| Resilience | Restart, update, rollback, storage and communication loss. | Power interruption, network loss, degraded coverage and restoration. |
| Training | Manuals, maintenance procedures and training material. | Operator and maintainer competency with signed handover. |
Architecture Review Questions
A design review should trace every mission requirement through the layers and back to evidence. Unanswered interface and failure questions should be resolved before site construction.
- Which observable supports each priority target, and what complementary evidence exists?
- How does required warning time translate into zones, sensor geometry and latency?
- Where are time, coordinate, confidence and source provenance created and preserved?
- How are unknown, conflicting, duplicated and temporarily lost observations handled?
- Which decisions require human confirmation and which roles have authority?
- What is the safe and visible behavior after each component or infrastructure failure?
- How will software, model, target library and interface changes be regression tested?
- Which FAT and SAT evidence proves each required operational outcome?
Common Layered-Architecture Failure Modes
Many projects look layered in a diagram but remain fragile in operation. The following failure modes are common and preventable.
- Several sensors feed separate screens, leaving the operator to perform manual fusion.
- Tracks have no reliable source, confidence, timestamp or quality information.
- An EO/IR camera is installed but cannot be cued quickly or does not cover the required geometry.
- External integrations exchange alarms but not health, errors or acknowledgements.
- The design has redundant sensors but one shared switch, server, time source or power failure.
- Mitigation is discussed before authority, target verification and safe-state behavior are defined.
- Site acceptance demonstrates one favorable flight instead of the documented mission scenarios.
- Updates change algorithms or target libraries without regression testing or operator notice.
Relevant JianHong System Building Blocks
These products illustrate roles inside a counter-UAS architecture. They are not a universal bill of materials. A project configuration must be based on the target profile, protected area, required warning time, local RF environment, interfaces, environmental conditions and the end user’s legal authority.
Related Technical and Procurement Guides
Frequently Asked Questions
What does layered counter-UAS mean?
It means independent but connected functions for observation, tracking, verification, command, decision and authorized response, supported by common infrastructure and governance.
Does a layered system require every sensor type?
No. Layers describe functions, not a mandatory product count. Select sensors that provide relevant and complementary evidence for the target set and environment.
What is the most important integration requirement?
Reliable time, coordinates, source provenance, confidence, health and documented interface behavior are foundational to trustworthy correlation and operations.
How should a system behave when one sensor fails?
It should visibly declare the degraded state, describe affected coverage or confidence, continue approved remaining functions and record recovery.
Can response be fully automated?
High-consequence responses should follow applicable authority, safety controls and accountable human decision. Automation may assist workflow but should not hide uncertainty or bypass governance.
What is the difference between FAT and SAT?
FAT verifies configuration and function before shipment; SAT verifies installation, site performance and end-to-end workflow in the real operating environment.
Official References and Legal Boundaries
The technical framework in this article should be read together with official guidance. The FAA airport UAS detection, mitigation and response resource states that detection systems cannot determine intent and that airport deployments require coordination. The FAA counter-UAS resource links the U.S. interagency legal advisory. The ICAO UAS intrusion protection material emphasizes a comprehensive, coordinated approach for civil aviation. The U.S. GAO counter-drone technology assessment summarizes technology maturity, opportunities and policy questions.
Active RF interference, takeover, interdiction and other mitigation actions are restricted or prohibited in many jurisdictions. For example, the FCC jammer guidance describes the U.S. prohibition on unauthorized jammer operation and marketing. Buyers must obtain jurisdiction-specific legal, spectrum, aviation, privacy, cybersecurity, import and export advice before acquiring or activating any mitigation function.
Turn Your Requirements into a Layered Architecture
Send the site outline, target priorities, warning-time objective, operating model, integration systems and destination. JianHong can help map detection, tracking, command and system building blocks.