Planning for AIS failure and radar fallback starts with one distinction: is the Automatic Identification System (AIS) source down, or has a single target gone quiet? Anchorage software must tell these apart and label affected data with its age.
The rule in short: mark affected data as stale, keep request and allocation records usable, use validated radar for detection but not identity, record manual identity evidence, and close the incident only after returning data and manual work are reconciled.
Continuity also depends on the application and its other services staying available. A reconnected feed is not the same as a recovered operation.
Distinguish AIS Feed Loss, Silent Targets and Stale Reports
These failure modes need different responses. A total feed outage is visible and easy to alarm.
A silent target does not, on its own, prove the vessel has left. Stale data is the most misleading, because the display still looks current.
| Scenario | How It Presents | Required System Behavior |
|---|---|---|
| Feed unavailable | All AIS updates stop | Alarm, switch display state, keep workflows usable |
| Single target silent | One track stops updating | Age the track, mark it, do not delete silently |
| Stale but flowing | Updates arrive with old timestamps | Detect by message age, not by arrival |
| Inconsistent data | Identity or position implausible | Flag for operator confirmation |
Why AIS Targets Go Silent
A silent target has several possible causes, and each means something different operationally:
- Equipment fault or power loss on board.
- The master switching AIS off, which IMO Resolution A.1106(29) permits where continued operation could compromise safety or security.
- The vessel moving out of VHF range or behind terrain.
- Receiver problems or channel congestion at the shore station.
Set Silence Thresholds Against Real Reporting Intervals
AIS reporting rates depend on vessel state. Under ITU-R Recommendation M.1371, a Class A ship at anchor or moored reports about every three minutes, but every few seconds when underway.
A silence threshold shorter than three minutes will therefore flag every anchored vessel as stale. Class B units on smaller craft report less often and less predictably again.
The USCG NAVCEN Class A position report intervals summarize these rates. Set thresholds per source and vessel state; one fixed timeout cannot explain why a target stopped.
Real-Time Vessel Tracking System for Ports covers what the map may show once a threshold passes. How To Integrate An AIS Feed Into Anchorage Software explains the timestamp checks that separate delayed observations from a dead connection.
AIS Failure and Radar Fallback: What Radar Keeps and Loses
Where validated radar coverage and tracking exist, radar can keep supplying detections during AIS loss. What remains depends on coverage, target size, weather and the health of the sensor and tracker.
Radar does not preserve vessel identity. It supplies no name, identifiers, destination or reported status, and that gap decides which workflows degrade and which carry on.
Requests, approvals, queue positions and allocations should be stored independently of the AIS feed. They stay usable during a gap as long as the application and its dependencies stay up; only the automatic confirmation of each vessel's position is lost.
Connecting Radar Track Feeds to Anchorage Software explains how to validate detection evidence and record identity uncertainty during source loss.
Follow a Feed Outage Through Recovery
Illustrative example
The feed stops after its last valid observation. The port sets a local freshness limit for this workflow; when that limit passes, the observation is marked stale.
The fallback procedure allows history viewing and attributed manual notes, but blocks any allocation that needs current position evidence. The rows below follow state changes, not response-time targets.
| Stage | Event | Allowed and Blocked Work |
|---|---|---|
| Feed stops | Last valid observation received | Existing approvals retained |
| Freshness limit passes | Observation marked stale | Stale label and source alarm; fresh-data decisions blocked |
| Operator review | Operator opens call C-182 | History and last known position shown with age |
| Degraded operation | Approved manual note N-7 entered | Attributed note allowed; no automatic allocation rewrite |
| Source returns | Connection resumes with an old backlog | Transport healthy; target may still be stale |
| Validation | New observation validated | Current position available; reconciliation still pending |
Return to Normal Operation
| Check | Passing Result |
|---|---|
| Replay of the last pre-outage observation | Deduplicated; original time preserved |
| Backlog conflicts with N-7 | Review item contains both source and manual evidence |
| Independent radar target remains | Shown as radar-only unless identity is corroborated |
| All affected calls reviewed | Named supervisor closes the recovery task |
The source alarm can clear when the health test passes while call-level reconciliation stays open. Merging those into one green status would hide unfinished operational work.
Make Degraded States Visible to Operators
Separate source states from service states. Radar and AIS Sensor Fusion for Port Operations defines the source states: AIS only, radar only, correlated and conflicting.
Service states are normal, degraded and unavailable. Each combination should change the display in a way an operator notices without reading a log.
Existing call and allocation records can narrow the candidate identities for a radar track, but they do not prove which vessel it is. Require corroboration, and record the uncertainty and the approving operator.
Reconciling VTMIS and Anchorage Records: Which Value Wins? explains how those records stay authoritative when a live feed disagrees with them.
Decide in advance which tasks may continue during source loss, who reviews uncertainty, and how manual updates will be reconciled. Which Anchorage Management System Features Belong in the First Release? helps set that scope.
Keep the Operator in the Loop and on the Record
During a gap, operators may confirm identity by other means: a very high frequency (VHF) radio exchange, an agent's call, a visual check, or a berth or pilot confirmation. Record each as an attributed, timestamped action, not a free-text note.
Alarms need owners and escalation paths, not just visibility. Define who is notified when a feed fails, when it escalates, and what happens if nobody acknowledges.
Manual confirmations carry operational weight, so control who may make and override them. Who Can Approve, Change and Audit an Anchorage Record? covers those roles and the audit trail.
Specify Recovery and Failback
Treat Source Return as a Reconciliation Step
Recovery is where most contingency designs are thin. When AIS returns, the system must re-correlate live tracks with identities operators assigned by hand, resolve disagreements, and show which decisions were taken while degraded.
Failback should be controlled, not automatic and silent. Operators should see when the system proposes to reattach an identity, and be able to reject it.
A retained observation history makes that re-correlation defensible. When Port Systems Need an Event-Driven Architecture describes one way to keep it, though any auditable storage design works.
Write AIS Loss and Recovery Drills into Acceptance
Continuity claims that are never exercised are not continuity. Cut the feed during a working scenario, run degraded operation, restore it, and check that every decision taken in between can be reconstructed. Repeat after major releases.
Then carry the outcome into the contract. Feed health monitoring, alarm response times and degraded-mode expectations belong in the service agreement, not an implementation note.
Anchorage Management SLA and Support Checklist shows how to express source-loss alerting and degraded-mode obligations.
The Anchorage Management Demo and Proof-of-Concept Checklist includes an AIS loss scenario to run with each vendor before selection.
Conclusion
Good AIS failure and radar fallback planning is rehearsed, not assumed. Run an outage with the operating team, note when observations become stale and which tasks must pause, and record any permitted manual work with its source and author.
During recovery, inspect replay and reconcile manual work before closing the incident. A connected feed proves reconnection, not that every operational record is current and consistent.
Review Recovery Workflows with SDLC Corp
Discuss degraded operation and recovery for our Anchorage Management Software, delivered through our Software Integration Services. Bring your source-loss drills, permitted manual procedures and support-owner map.
We will scope a demonstration that preserves existing decisions, exposes identity uncertainty, and reconciles returning observations with manual work before recovery is declared.
Frequently Asked Questions
How Can the System Tell Stale Data from a Quiet Target?
Combine observation age, where its timestamp is trustworthy, with source health and receipt-gap checks. A recently received message can still carry an old observation, so show timestamp provenance explicitly.
Why Does an AIS Target Stop Reporting?
Common causes are equipment faults, the master switching AIS off for security reasons, the vessel leaving VHF range, or shore receiver problems. Each needs a different response, so do not treat silence as departure.
How Often Does AIS Report at Anchor?
Under ITU-R M.1371, a Class A ship at anchor or moored reports about every three minutes. Silence thresholds shorter than that will wrongly flag anchored vessels as stale.
Can Radar Replace AIS During an Outage?
Only for detection, and only where coverage is validated. Radar cannot supply vessel identity, so radar-only targets need corroboration before an identity is attached.
Can Work Continue During an AIS Outage?
Only where the application stays available and the approved procedure permits the action with the remaining evidence. Hold dependent decisions, or use an authorized alternative source and record its provenance.
What Must Be Checked After the Feed Returns?
Verify freshness, duplicate handling and replay effects. Reconcile manual actions and conflicting records from the outage, then confirm outstanding work is resolved or assigned before declaring recovery.
