Arctic Domain Awareness Digital Twin

Overview

Canada's Arctic is vast, remote, and increasingly busy. This project builds a digital twin of the air and maritime picture over the North using nothing but open data: ADS-B aircraft beacons, AIS ship transponders, and Sentinel-1 synthetic-aperture radar imagery. All three streams flow into one pipeline that maintains a live picture of who is where, and raises flags when something looks wrong.

The two flagship anomaly detectors are dark-vessel detection (a ship that stops transmitting AIS but keeps appearing in radar imagery) and route deviation (an aircraft leaving its filed or historical corridor). Both are classic sovereignty and safety concerns in the Arctic, and both can be prototyped entirely with public data.

This is directly relevant to NORAD modernization and Canada's Arctic sovereignty agenda: the hard part is not sensors, it is fusing heterogeneous feeds into one trustworthy, queryable picture. That is a data-engineering and DevOps problem, and that is what this project practices.

Architecture

Figure 1: sources, streaming backbone, storage, detection, and presentation layers.

Every source gets its own Kafka topic so a slow or broken feed never blocks the others. The stream processor normalises all three into a common track model (id, lat, lon, speed, heading, timestamp, source) and filters to an Arctic bounding box before anything hits storage, which keeps the dataset small and cheap.

Anomaly Detection Logic

Figure 2: dark-vessel detection correlates a silent AIS track with radar-only contacts.

• Dark vessel: AIS gap + SAR contact inside the vessel's drift cone (last position plus max speed times elapsed time) raises a scored alert.
• Route deviation: aircraft tracks are compared against historical corridors; a deviation beyond a configurable distance or a heading inconsistent with the destination airport triggers review.
• Confidence scoring: distance, elapsed silence, weather/ice season, and historical behaviour combine into a 0-100 score so analysts see the most likely anomalies first.

Why an append-only event log is the backbone

Kafka-style logs are the right primitive for this twin because every detector is a stateful function of history, not of the latest message. Partitions are ordered, immutable, append-only sequences; consumers track their own offsets, so a detector can be rewound to last Tuesday and replayed after a logic change, and retention policies keep weeks of raw feed for exactly that. That matters twice here: first, gap detection is "last-seen timestamp vs now", which needs reliable history, and second, scoring a detector against labelled history means re-running it over recorded weeks rather than waiting for new anomalies. Kafka's KRaft mode removes the old ZooKeeper dependency, which makes a single-node broker practical on the homelab cluster for the prototype.

How the twin scores itself against labelled history

The discipline that keeps this honest: every alerting rule is evaluated against labelled history before it is trusted. AIS is self-reported, so "dark vessel" candidates get checked against port-call records and anchorage polygons to weed out vessels that simply docked. Route-deviation rules are tuned on months of corridor history so the false-positive rate is a number, not a feeling. No detection metrics are published yet, and the table below marks that explicitly; the plan is to publish precision and recall per rule once the ingestion connectors are feeding the log.

Stack

How I'm Building It

How Defence Could Implement This

The same architecture scales from my homelab to an operational setting with mostly configuration changes:

• Sensor upgrade, same pipeline: swap or add feeds (military radar, satellite tasking, allied data) as additional Kafka topics. The fusion and detection logic does not change.
• Classification boundaries: the open-data prototype runs on the public internet; an operational version would run on classified networks with the same store-and-forward pattern, bridging via one-way data diodes where required.
• Redundancy for the North: Kafka's replication and Kubernetes rescheduling map directly onto the reality of remote northern sites with intermittent links; regional clusters can buffer locally and sync when links return.
• Auditability: every alert keeps its evidence chain (raw messages, detector version, confidence inputs), which matters for sovereignty reporting and after-action review.

NORAD modernization explicitly calls for better domain awareness in the Arctic. The contribution a system like this makes is not a new sensor; it is a cheap, fast way to turn existing sensors into one shared, alertable picture.

Status & Roadmap

• Done: architecture design, source evaluation, common track model, homelab Kubernetes target.
• In progress: AIS + ADS-B ingestion connectors, geofenced normaliser.
• Next: gap detection, map UI, then Sentinel-1 correlation and confidence scoring.

Designed vs Built vs Measured

This page makes no detection-accuracy claims. The architecture and source evaluation are done, ingestion connectors are in progress, and every "next" item above is a design or a planned validation, not a result.

How I Built It

What You Need

Challenges and Lessons Learned

• AIS silence is ambiguous. A gap can mean a dark vessel, a docked vessel, or a hole in receiver coverage. The lesson: never alert on the gap alone. Correlate with anchorage polygons, port-call records, and SAR imagery before scoring, which is why confidence is a 0-100 blend rather than a yes/no.
• Three feeds, three clocks, three schemas. The common track model had to come first; anything built before it would have needed rewriting once fusion started. One shared schema is the cheapest architectural decision in the whole project.
• Geofence at ingest, not in queries. Filtering to the Arctic bounding box in the stream processor keeps storage and detection costs flat as feeds grow, instead of paying for data you will throw away.
• No detection metrics exist yet, and that is honest. Route-deviation rules need months of corridor history before the false-positive rate is a number instead of a feeling. Publishing precision and recall per rule is a roadmap item, marked as a target until it is measured.

What Is Next

• Finish the AIS and ADS-B ingestion connectors and the geofenced normaliser.
• Gap detection, then the map UI so the pipeline is visible end to end.
• Sentinel-1 correlation and the 0-100 confidence scorer.
• Publish precision and recall per detection rule as measured results.
• Full stack declared in Terraform and Helm for a one-command deploy to the homelab cluster.

Related Builds

• Multi-Domain Common Operating Picture, the fusion layer that would consume these Arctic tracks alongside the hardware sensor builds.
• Counter-Drone Sensor Fusion Simulator, the same Kalman-filter fusion approach applied to synthetic radar, RF, acoustic, and camera tracks.
• Canadian Defence Hardware Program, the program hub with all 11 builds, phased BOMs, and build guides.