Radar and AIS sensor fusion for port operations decides whether a radar track and an Automatic Identification System (AIS) report describe the same vessel. Time alignment, position, movement and source quality all count; proximity alone is not evidence.
The rule in short: align both sources in time and space, associate using position, motion and history, label every target as AIS only, radar only, correlated or conflicting, and downgrade an identity as soon as the evidence stops supporting it.
Radar and AIS Sensor Fusion for Port Operations: Consume or Build?
Decide the output before the algorithm. A fused track that drives zone occupancy has different requirements from one that only informs a display. List each downstream consumer and what it does when confidence drops.
| Consumer | What It Needs from Fusion | Behavior When Confidence Is Low |
|---|---|---|
| Zone and geofence logic | Position of sufficient quality; identity where the rule requires it | Qualify or hold events under the confidence policy |
| Queue and allocation views | Reliable association to a vessel call | Hold state, mark as unconfirmed |
| Operator map | Position plus source provenance | Show contributing sources |
| Audit and replay | Contributing evidence and fused output | Retain provenance within data rights |
The boundary between Vessel Traffic Services (VTS), the Vessel Traffic Management and Information System (VTMIS) and anchorage applications matters here. Integrating VTMIS With An Anchorage Application explains where that boundary usually sits.
Two Implementation Scopes to Compare
Consuming an existing fused feed needs an interface contract, confidence-state mapping and validation of the supplied track lifecycle. This is track-to-track fusion done upstream.
Building fusion adds time alignment, association logic, state estimation, conflict handling and representative sensor testing. Ask which of these the incumbent tracker already delivers and which would be new work.
In either scope, test one target becoming ambiguous near another. Record the identity shown to the operator, the source states, linked call behavior and preserved history.
A visually smooth track does not prove a correct association. Measure detection, association and identity quality separately, so a good result in one does not hide a failure in another.
Normalize Time and Space First
Correlation cannot work until observations share a time base and coordinate reference. Record each source's latency, update interval, transformation and residual uncertainty.
Keep the original observation time separate from receipt time. Align observations to a defined fusion epoch, and document any interpolation or extrapolation and the uncertainty it adds.
State how long the system extrapolates between updates. A track that keeps moving on screen long after its last observation creates false confidence.
The fusion layer should inherit freshness thresholds from Real-Time Vessel Tracking System for Ports rather than override them.
How Position, Motion and History Inform Track Association
Association decides whether two observations describe the same vessel. It usually combines proximity, consistency of course and speed, the history of the pair and any identity information available.
Common approaches start with a gate that removes clearly incompatible candidates, then choose among the rest. Nearest-neighbour, global nearest-neighbour and covariance-based statistical distance are typical methods. A provider should explain which it uses in plain operational terms.
The edges decide whether operators trust the system: two vessels close together at low speed, a vessel that stops transmitting mid-track, a reflection that produces a false target, and a large vessel returning as more than one contact.
What AIS Brings to the Match
AIS is not a continuous position feed. Under ITU-R Recommendation M.1371, a Class A ship reports every few seconds when underway but only every three minutes when at anchor or moored.
In an anchorage, the AIS half of a pair is therefore often minutes old while radar updates every antenna rotation. Association logic must allow for that age instead of treating it as a conflict.
AIS also reports the position of the ship's GNSS antenna, while radar returns the reflection centroid. On a large vessel these can sit tens of meters apart, which is expected and should not break an association.
How To Integrate An AIS Feed Into Anchorage Software covers the other AIS failure modes. Fusion must never assume the AIS half is always correct.
Trace Association States Without Universal Physical Gates
Illustrative example
The test compares radar candidates R1 and R2 with one AIS observation at a common evaluation time. Each source keeps its original timestamp and uncertainty.
No fixed distance, age or heading gate transfers between sites. Thresholds must be validated with installation data, taking error estimates, update behavior, motion and competing targets into account.
| Evidence Condition | Required Policy Decision | Operator Record |
|---|---|---|
| R1 is compatible; R2 is inconsistent with the motion evidence | Apply the confirmation or tentative-state rule | Candidate evidence, policy version and association state |
| Both become plausible within their uncertainty | Reassess confirmation; do not transfer identity silently | Ambiguity, competing candidates and previous state |
| AIS evidence becomes stale for this task | Apply the downgrade, retention or split rule | Source age, qualified identity and permitted use |
| New evidence supports another candidate | Re-evaluate under lifecycle rules | New decision with the prior association kept in history |
A confirmed association must not stay confirmed once the evidence stops supporting it. The response may be a tentative association, reduced confidence, identity removal, candidate separation or a broken association, and these states are not interchangeable.
Make the Association Policy Inspectable
Ask the provider how measurement uncertainty, maneuvering, sensor configuration and target density affect each decision.
Where covariance estimates exist, document how they are used; where they do not, validate the alternative quality model.
The IALA Guideline G1111-3 on radar requirements discusses tracking and correlation with other sources. Use it alongside installation evidence when assigning responsibility for the tracker and its acceptance tests.
Follow the Ambiguity to a Reviewed Outcome
| Stage | Candidate Set and State | Allowed Interpretation |
|---|---|---|
| Initial comparison | R1 compatible; R2 inconsistent; association to R1 tentative | Possible identity, awaiting corroboration |
| Targets converge | R1 and R2 both plausible; confirmation withheld | Preserve both candidates; do not silently move the identity |
| Additional evidence arrives | R2 becomes inconsistent; R1 keeps compatible history | Re-evaluate against the site policy |
| Authorized resolution | Conditions met for R1; confirmation and reason recorded | Display confirmed association; keep the ambiguous interval in history |
If new evidence still leaves both candidates plausible, the final row never happens. Keep the qualified state and its workflow restrictions until the resolution conditions are met.
Make Confidence and Conflict Visible
Explain the Source State Behind the Displayed Identity
Every fused track needs a state an operator can read: AIS only, radar only, correlated or in conflict.
When sources disagree on position, course or speed beyond a defined tolerance, the system should say so rather than quietly preferring one. Preferred-source rules are legitimate, but they must be explicit, configurable and recorded.
A radar track that acquires a name through correlation should record how it got that name. If the correlation later breaks, mark the identity unconfirmed instead of letting it persist as fact.
Reconciling VTMIS and Anchorage Records: Which Value Wins? applies the same discipline to voyage and call records.
Handle Loss of Correlation and Track Lifecycle
Correlation ends as well as begins. Define what happens when a fused track loses one source: whether it reverts to a single-source state, how long it persists and what the operator sees.
Define split and merge behavior too. Both create audit problems if the system silently moves history from one track to another.
Keep contributing observations and fused output as far as source licenses and retention policy allow, and record any evidence gaps. An auditable event history lets an incident review reconstruct what was displayed and why.
Test Crossing Targets, False Contacts and Source Dropouts
A demonstration on clean data proves little. Build the acceptance set from difficult cases, and score the system on whether the operator could tell what was happening, not just whether the track eventually settled.
- Simulated AIS dropout on one vessel while others continue.
- Two targets converging at low speed.
- A false radar contact near a real vessel.
- A large vessel at anchor with AIS and radar positions far apart.
- Conflicting position reports, then correlation loss and recovery.
- A period of degraded network availability.
Include performance: latency from observation to display under representative load, and what degrades first under pressure. The IALA Guideline G1111-1 on core VTS system requirements gives terminology for writing these tests into a specification.
Ask for one continuous demonstration from correlation through conflict, source loss and recovery, then inspect what the operator saw and what history kept.
Carry accepted tests into the Radar and AIS Sensor Fusion Requirements Checklist. Keep Connecting Radar Track Feeds to Anchorage Software and AIS Failure and Radar Fallback for Vessel Tracking in scope so the full continuity path is tested.
Conclusion
Evaluate radar and AIS sensor fusion for port operations with time-aligned observations, then introduce crossing targets, conflicting reports and source loss. Check when the system keeps, qualifies or removes a match, and what the operator sees.
If an existing traffic system already owns fusion, assess consuming its output before building another association process. Either way, keep source contributions and show why an identity is uncertain.
Discuss Fusion Requirements with SDLC Corp
Use SDLC Corp's Software Integration Services to set the fusion boundary around our Anchorage Management Software. Bring your track contracts, uncertainty fields and site association policy.
We will separate consuming an existing fused output from building association logic, with ambiguity, provenance and lifecycle evidence agreed before scope or acceptance is confirmed.
Frequently Asked Questions
Is a Nearby Radar Track Enough to Match an AIS Report?
No. Apply timing, position, movement and quality checks, and consider competing candidates. Validate those checks with installation data, because no fixed physical gate works at every site.
How Often Does AIS Report at Anchor?
Under ITU-R M.1371, a Class A ship at anchor or moored reports its position about every three minutes, compared with every few seconds when underway. Fusion must allow for that age.
Why Does AIS Position Differ from the Radar Target?
AIS reports the GNSS antenna position, while radar measures the reflection centroid. On large vessels these can be tens of meters apart without indicating a conflict.
Does Fusion Guarantee a More Accurate Position?
No. Combining observations does not remove their errors or guarantee a correct association. Test position and identity behavior with representative cases, including conflicts, and keep each source's contribution.
What Should Happen When a Fused Track Loses AIS?
The track should revert to a radar-only state with its identity marked unconfirmed, persist only as long as the defined rule allows, and keep the earlier association in history.
Should Anchorage Software Perform Fusion Itself?
First assess whether an existing traffic system provides a supported fused picture. Decide by sensor ownership, available interfaces, required behavior and the team's ability to maintain and validate association rules.
