The problem
Commercial drones now threaten airports, critical infrastructure, public events and borders.
Traditional counter-drone detection relies on expensive, specialised hardware, so wide-area,
layered coverage is hard to afford and hard to scale.
Single sensors are noisy. RF alone, acoustics alone or radar alone each generate false alarms,
and operators are flooded with unfused, unexplained detections they cannot act on with
confidence. Fusion is the answer.
Integration with existing systems
DroneWatch is the fusion and AI layer above a customer's sensors. The design ingests real detectors and pushes a scored track into the operator's command system through recognised standards. Being exact about the stage: only the ADS-B feed is implemented and live today. The table below is the integration path a pilot would work through, not a list of finished connectors.
| Domain | Interfaces |
|---|
| Identification | Remote ID (ASTM F3411), ADS-B |
| Air / drone traffic | ASTERIX, U-space / UTM |
| Military C2 | STANAG 4586 / 4609, Link 16 / STANAG 5516 |
Where this applies
A small drone creates the same problem for a forward site and for a regional airport: single sensors are noisy, and an operator flooded with unfused alerts cannot act on any of them with confidence. The fusion approach is the same in both domains, which is what makes this a dual-use software layer. So is the stage: everything below is where this would apply, not where it is deployed.
| Setting | What the fusion layer would address |
|---|
| Defence and national security | Layered early warning across sites and borders, where wide-area coverage from dedicated hardware alone is hard to afford |
| Airports and airfields | Separating registered traffic on ADS-B and Remote ID from an unregistered contact near an approach path |
| Energy, water and industrial sites | Long perimeters and dispersed assets, where one radar per site does not scale |
| Ports and logistics | Large open areas with constant legitimate movement, so the false-alarm rate decides whether an alert is trusted at all |
| Stadiums and public events | Temporary coverage at short notice, assembled from sensors already on site |
| Prisons and secure facilities | Small, low, short-duration flights that any single sensor class routinely misses |
Privacy, stated up front. Civil sites carry data-protection obligations a military perimeter does not, because RF and acoustic sensing happens around the public. Two things are true of the demonstrator today. It consumes normalised detection events from sensors, meaning a source, a coarse zone, a confidence value, a bearing and a timestamp, rather than audio recordings or raw RF captures, and the only positional data it handles is public ADS-B aircraft telemetry. And it has not been assessed against GDPR for any real deployment, because there has not been one. What a real installation must do depends on the sensors a partner brings, and that assessment belongs in the pilot, before anything is switched on.
Civil applicability does not change export control. Dual-use means usable in both domains, which is what places technology inside the rules rather than outside them. Any future supply of technology would be assessed under EU Regulation 2021/821 and national export-control law first.
For partners
We bring the software intelligence layer, the AI correlation, the operator console and the
integration engineering. A partner brings real sensors, an accreditation path and a customer
channel. EU Defence Innovation (EUDIS) and European Defence Fund calls fund exactly this dual-use software layer.
First step: a pilot at one real site with one or two real sensor types plus the live feeds,
to measure the real-world false-alarm rate. Built by a former Army Engineer (Military Technical
Academy, Bucharest) who deploys and operates production AI systems on his own infrastructure.
Project stages
Where the project actually is,
and what each step requires. Phases 1 and 1.5 are built and running. Everything beyond them needs a
partner, real sensors, and a site.
| Stage | Status | What it covers |
|---|
Phase 1
Prototype | BUILT |
Multi-source ingestion, fused event stream, two-tier correlation, explainable threat assessment, operator console, live ADS-B, alerting. Running on simulated threat signals plus live public data. |
Phase 1.5
Persistence | BUILT |
Durable recorded history of every assessment and alert, surviving restarts. After-action replay of any time window, showing what each source reported, what the rules computed, and why. Operator adjudication of every alert as real, false or unknown, and a report that turns those verdicts into a false-alarm rate. No rate is claimed yet: this is the instrument a pilot needs, built before the pilot rather than after it. |
Phase 2
Real sensors | Needs a partner |
Integration with real RF, acoustic and radar hardware over the standard interfaces. A pilot at one site to measure the real false-alarm rate, the number that actually matters. The measurement and adjudication tooling for it is already built and running. |
Phase 3
Learned detection | Planned |
Machine learning on flight patterns and signatures, tuned against real measured data to cut false positives further. |
Phase 4
Operations | Planned |
Multi-site command picture, role-based operator workflows, accreditation and on-premise or air-gapped deployment. |
Phase 5
Distributed grid | Long term |
Wide-area and edge sensing across many sites, federated into a single early-warning picture. |
