Maritime domain awareness C2: fusing AIS, radar, and patrol data

The sea looks empty from a single sensor and crowded from all of them at once. A coastal radar sees position without identity. An AIS receiver sees identity without independent verification. A patrol boat sees one hull at close range but nothing over the horizon. Maritime domain awareness (MDA) command and control is the software discipline of fusing those incomplete, contradictory feeds into one authoritative picture – a single track database in which every vessel in the area of interest carries a position, an identity, an assessed intent, and a confidence value. This article walks through how a naval MDA C2 system is architected: how cooperative and non-cooperative sources are ingested, how they are correlated into unified tracks, how anomalies and dark vessels are detected, and how the resulting picture is shared with allied command structures.

What maritime domain awareness means in software terms

Maritime domain awareness is defined doctrinally as the effective understanding of anything in the maritime domain that could affect security, safety, the economy, or the environment. That definition is operationally useful but architecturally vague. In software, MDA reduces to a concrete deliverable: a fused maritime picture that is authoritative, current, and shared. Authoritative means there is one canonical track per real-world vessel, not one track per sensor. Current means tracks age visibly and are dropped or flagged when their supporting reports go stale. Shared means every console – and every interoperating allied system – renders the same database rather than maintaining a private copy.

The hard part is not the map. Charting libraries and electronic navigational charts solve display. The hard part is the fusion: collapsing thousands of raw reports per minute from heterogeneous sensors into a clean track list where each track means exactly one vessel. The same architectural principle that governs a land-force common operational picture applies at sea – one fusion engine writes the authoritative tracks, every display is a read-only consumer – but the maritime sensor mix and the dark-vessel problem give it a distinct shape.

Cooperative data: AIS as the backbone and its limits

The Automatic Identification System is the backbone of the maritime picture because it is the only source that volunteers identity. An AIS transponder broadcasts the vessel's MMSI, name, IMO number, type, and dimensions (static data, ITU-R M.1371 message type 5) alongside its position, speed over ground, course over ground, heading, and navigational status (dynamic data, message types 1, 2, 3, and 18). Class A transponders, mandatory on most commercial vessels over 300 gross tonnes, report dynamic data as often as every two seconds when underway.

Terrestrial AIS receivers cover roughly 40 nautical miles from the antenna; beyond that, satellite AIS fills the open-ocean picture at the cost of latency and message collision in dense traffic. A robust MDA ingest stage decodes both feeds into one canonical track schema, validates MMSI ranges, and timestamps every report against the receiver clock so the fusion engine can reason about staleness.

The limitation is structural: AIS is self-reported and trivially defeated. A transponder can be switched off, set to broadcast a false MMSI, or fed a spoofed position. AIS therefore cannot be the sole source for security MDA – it must be cross-checked against sensors a vessel cannot opt out of. That cross-check is the entire reason a maritime C2 system fuses radar and electro-optical data on top of AIS rather than simply plotting the transponder feed.

Non-cooperative data: radar, electro-optical, and satellite SAR

Non-cooperative sensors observe a vessel whether or not it cooperates. Coastal surveillance radar and shipboard radar produce position plots with no identity attached; electro-optical and infrared cameras add a visual classification at shorter range; satellite synthetic aperture radar (SAR) provides wide-area detection independent of weather or daylight and independent of any transponder. Each of these is processed at a sensor adapter that applies clutter rejection and track-before-detect filtering, then emits plausible plots in the same canonical schema used for AIS, each carrying the sensor's measured position-error covariance.

That covariance is not a formality. The fusion engine uses it to decide whether a radar plot and an AIS track describe the same hull. A coastal radar might localise a vessel to within 50 metres; a satellite SAR detection might carry a 200-metre uncertainty; an AIS GPS position is typically accurate to within 10 metres. Correlation has to account for all three, which is why the adapters must report honest error estimates rather than nominal datasheet figures.

Sensor fusion: turning plots into unified tracks

Fusion is where MDA software earns its keep. The objective is to maintain one track per vessel that absorbs reports from every sensor that can see it. The production approach is a multi-sensor tracker built on a Kalman filter per track, with a data-association layer that decides which incoming plot belongs to which track.

The association cycle runs on every incoming plot or batch. The tracker predicts each existing track forward to the plot's timestamp using the track's motion model – for ships, a constant-velocity or constant-turn model is usually sufficient given their low dynamics. It then forms a validation gate around the predicted position, sized from the combined covariance of the track and the incoming sensor. Plots that fall inside the gate are candidates for association; the assignment itself is solved with global nearest neighbour for sparse traffic, or joint probabilistic data association where traffic is dense and gates overlap.

The defining maritime case is correlating an AIS track with a radar plot. The engine predicts the AIS track to the radar plot time, gates it against the radar covariance, and – if the radar plot falls inside – fuses them into a single identified track that now carries both the AIS identity and the radar's independent position confirmation. That is the strongest track state the system can produce: a named vessel whose reported position is corroborated by a sensor it cannot spoof.

Track confidence and source tagging

Every fused track must record which sources contributed to it. A watch officer needs to distinguish, at a glance, an AIS-only track (identity but no independent confirmation), a radar-only track (a position with no identity), and a correlated track (both). Source tagging is not cosmetic – it drives the anomaly logic, the display symbology, and the decision about whether a track warrants investigation. A track that has been radar-only for twenty minutes in a shipping lane is a very different object from a correlated track that has just lost its AIS report.

Dark-vessel tracking and anomaly detection

A dark vessel is one that a non-cooperative sensor can see but that is not broadcasting AIS – or is broadcasting AIS that contradicts its observed behaviour. Dark vessels are the central security concern of maritime domain awareness, covering smuggling, sanctions evasion, illegal fishing, and pre-hostility reconnaissance. The detection mechanism falls directly out of the fusion architecture: because the engine maintains radar and SAR tracks independently of AIS, any persistent non-cooperative track with no AIS correlation is, by definition, a candidate dark vessel.

Anomaly detection generalises that idea into a rule set evaluated continuously against every fused track:

AIS gaps. A vessel that was transmitting AIS goes silent while a radar track of the same hull persists – the classic indicator of a transponder switched off to obscure activity in a sensitive area.

Identity inconsistency. Two hulls broadcasting the same MMSI, an MMSI that teleports an implausible distance between reports, or an AIS position that diverges steadily from the radar position of the correlated hull – all signatures of spoofing or identity swapping.

Behavioural anomalies. Loitering or an unexplained stop in a transit lane, a low-speed rendezvous between two vessels offshore (a ship-to-ship transfer indicator), or a speed and course inconsistent with the vessel's declared type. A bulk carrier behaving like a fast patrol craft is worth a second look.

Zone violations. Entry into a restricted area, a territorial boundary, or a declared exclusion zone – a geometric check that fires regardless of identity.

Each anomaly is scored by severity and confidence and surfaced to the watch officer with the supporting track history attached, so adjudication takes seconds rather than minutes. The pairing of an independent radar picture against the cooperative AIS feed is the same cross-checking logic explored for the air and surface picture in the article on AIS and ADS-B tracks in the COP.

Patrol reporting and the human-in-the-loop source

Sensors detect; patrols confirm. When an anomaly is adjudicated as worth investigating, the watch floor tasks the nearest patrol vessel, helicopter, or maritime patrol aircraft. The result of that tasking – a visual identification, a boarding report, a photograph of a hull number – is itself a data source, and a high-confidence one. A well-architected MDA system folds patrol reports back into the fusion engine as a source that can override or confirm identity and intent on the relevant track.

This closes the loop. A radar-only dark track becomes a named, confirmed vessel once a patrol boat reads its hull; an AIS-spoofing vessel is reclassified once a patrol confirms the mismatch between broadcast identity and observed hull. Treating patrol reports as a first-class fused source – rather than free-text notes pinned to a track – means the picture improves with every physical contact and the audit trail records who confirmed what, and when.

Interoperability: sharing the maritime picture

A national maritime picture rarely stands alone. Coalition operations, allied task groups, and combined patrol arrangements all require the picture to be exchanged in formats other systems understand. The established track-exchange formats are OTH-Gold and Link 16 for naval and joint C2; where the maritime picture must be shared with land forces or a broader joint multi-domain operations view, Cursor on Target or NFFI carry the tracks into the tactical picture. Long-range identification and tracking (LRIT) and fishing-fleet vessel monitoring systems (VMS) supplement coverage inside the exclusive economic zone.

The interoperability requirement reaches back into the architecture. If the canonical track schema is designed from the start to map cleanly onto OTH-Gold and Link 16 fields, sharing is a serialization step. If it is not, every coalition exercise becomes a bespoke adapter project. The lesson is the same one that governs every fused C2 picture: choose the canonical model with the output formats in mind, and never let a vendor-specific sensor format leak past the ingest adapters.