Integration
Counter-UAS integration: connecting radar, EO/IR and effectors
A counter-UAS system is not a pile of cameras, radars and effectors on one network. Integration means a shared track, a known latency, an agreed command path and a recorded result.
Contents
Start with the track, not the device listFive interfaces that need a written definitionLatency is a system propertyWhere the operator fitsA staged integration planFailure modes the project must testAcceptance criteria for the whole chainMany counter-UAS projects look integrated because every device appears on the same screen. In practice, the screens may be showing different tracks with different timestamps. The radar may know that something is moving, the camera may know what it looks like and the effector may need a third coordinate frame. If those data are not reconciled, the operator gets a busy display instead of a decision.
Start with the track, not the device list
A track should carry identity, position, velocity, source, confidence and time. The integration layer must decide whether two tracks from different sensors describe the same target. That is not just a map overlay; it requires coordinate transformation, time alignment and a rule for conflicting evidence.
Five interfaces that need a written definition
| Interface | What to define | Typical failure |
|---|---|---|
| Time | Clock source and maximum skew | Tracks arrive out of order |
| Coordinates | Datum, units and transformation | Camera looks at the wrong point |
| Track identity | Fusion rule and confidence threshold | One target appears as several |
| Effector cue | Aim point, field of view and latency | Beam or interceptor starts too late |
| Operator action | Roles, confirmation and override | No one knows who is allowed to act |
Latency is a system property
Every stage adds delay: sensor exposure, detection, tracking, network transfer, fusion, operator confirmation and effector slew. A low-latency camera does not compensate for a slow command path. Ask the supplier to measure the end-to-end time from target appearance to a valid cue at the effector.
Inject a target track from each sensor separately, then together. Measure the resulting single-track accuracy, time to cue and operator workload. A successful lab test with one sensor does not prove the site configuration.
Where the operator fits
Integration does not eliminate the operator. It changes what the operator has to do. Define who confirms identity, who authorizes an effector, who can stop an engagement and what happens when communications fail. The command path should be visible on the screen and recorded in the log.
A staged integration plan
- Connect one sensor and verify timestamps, coordinates and health status.
- Add the second sensor and measure track association and conflicts.
- Add the command display and test operator overrides.
- Add the effector cue with the laser or interceptor disabled.
- Run live engagement scenarios only after the cue path is proven.
- Record failures and define who repairs which subsystem.
Failure modes the project must test
- Stale track. The display updates after the target has moved beyond the effector field of view.
- Split identity. Two sensors create two tracks for one target and the operator engages the wrong one.
- Wrong coordinate. The camera and radar use different reference points or units.
- Network loss. The sensor keeps working but the command layer no longer knows its health.
- Ambiguous authority. The system recommends an action, but no role is assigned to approve it.
Acceptance criteria for the whole chain
The acceptance test should begin with a known truth track and finish with a visible cue at the effector. Record time, position error and operator actions at each stage. If the result fails, the log must make it possible to identify the responsible subsystem rather than blaming the whole platform.
| Test | Pass condition | Evidence |
|---|---|---|
| Sensor time alignment | Tracks remain ordered under load | Timestamped track log |
| Coordinate conversion | Cue falls inside the defined tolerance | Measured target offset |
| Track fusion | One target produces one operational track | Fusion event log |
| Effector cue | Cue arrives within the agreed time | End-to-end latency record |
| Recovery | System returns to a known state after a fault | Fault injection report |