A vessel-tracking application should let operators find a target, inspect its source and age, connect it to the correct call and understand what remains uncertain. When a source fails or an identity changes, the operator needs a visible exception and a controlled route to review history and resolve the association.
Position display, identity evidence and call decisions must stay distinguishable. A fresh coordinate does not prove a vessel identity, and a known call does not prove continuous sensor coverage.
Follow The Operator From Target To Decision
Start in the worklist or map, locate the target and open its linked call. Show contributing sources and their observation times before asking the operator to act. If the source goes stale, preserve the last known evidence with its age and expose the permitted fallback.
On recovery, let the operator compare new observations with the history and any manual evidence recorded during the gap. If the association is disputed, show the candidates and the policy governing resolution. The application should preserve the old association in history rather than silently attach the call to a different track.
Test this journey with operators: find a target, explain its freshness, inspect the related call, handle a staged source loss, review the returned evidence and complete the permitted resolution. Evaluate whether the next action is understandable without reading a technical log.
Vessel, Call, Observation And Track: Keep Four Records Distinct
Give every maintained track a stable local identifier and retain its contributing sources. Keep identity attributes separate from motion observations so an uncertain match does not become a permanent fact. A vessel call should reference the track where appropriate without making its administrative status depend on every positional update.
| Object | What it represents | What it must not imply |
|---|---|---|
| Observation | A measurement or report at a time | A confirmed operational decision |
| Track | A maintained target estimate | Certain identity in every state |
| Vessel record | Known or claimed identity attributes | A unique visit to the port |
| Call record | A particular operational visit | Continuous sensor coverage |
Use the anchorage workflow boundary to decide which track events merely inform the operator and which can propose a workflow action.
Specify The Map And List Together
Keep The Visual Position And The Work Item Connected
The map should support selection, inspection, filtering, and a clear legend. The companion list should expose the same targets and exceptions through keyboard accessible controls. Preserve the user's selection during updates. A refresh must not move focus or dismiss the detail panel while an operator is reviewing a conflict.
Show source, freshness, identity confidence, and the relationship to the active call. Provide text labels for automatic identification system (AIS)-only, radar only, correlated, stale, or conflicting states where relevant. Do not encode all meaning in marker color. Designing actionable port dashboards adds the work queue and supervisor views that tracking alone does not provide.
Four Records For One Displayed Target
Illustrative example
The vessel, visit, track and observation retain separate identifiers.
| Record | Sample | Relationship |
|---|---|---|
| Vessel | V-18, test vessel A | Stable application identity |
| Call | C-182, arrival date 18 September | One visit by V-18 |
| Track | T-9, source tracker-1 | Current track associated with V-18, subject to review |
| Observation | O-55, 10:00:00, position 10.1/20.2 | One measurement contributing to T-9 |
Loss, Recovery And Replay
The demonstration uses a 60-second freshness window solely to test software behavior. Source-specific operational thresholds require local validation.
| Time | Input | Expected Screen And Record |
|---|---|---|
| 10:00:00 | O-55 received | Target current; call C-182 shown separately |
| 10:01:01 | No newer observation | T-9 marked stale; last observation time remains 10:00:00 |
| 10:03:00 | Connection returns with replay O-55 | Duplicate ignored; stale state persists |
| 10:03:02 | New O-56 observed at 10:03:01 | Freshness restored after validation |
| 10:03:03 | Source proposes identity change | Association review opens; call is not silently reassigned |
Passing recovery means O-55 was not counted twice, the stale interval remains visible in history, and O-56 did not overwrite the allocation decision. A green connection indicator alone is insufficient: it says the transport is open, not that the target has a fresh observation.
Store The Relationships, Not One Combined Status
This record keeps the visit, track and observation identifiers separate. Reassigning a track does not rewrite the vessel’s earlier call history.
{
"vessel": {
"id": "V-18"
},
"call": {
"id": "C-182",
"vessel_id": "V-18"
},
"track": {
"key": "tracker-1:session-6:T-9",
"vessel_id": "V-18",
"association_state": "provisional"
},
"observation": {
"id": "O-55",
"track_key": "tracker-1:session-6:T-9",
"observed_at": "2026-09-18T10:00:00Z",
"position": {
"latitude": 10.1,
"longitude": 20.2
}
}
}If the tracker restarts and reuses T-9 in session-7, its key becomes tracker-1:session-7:T-9. The new track begins without inheriting V-18 automatically. O-55 still belongs to session-6, and call C-182 retains its approved allocation regardless of the new association review.
The radar track-feed contract explains why a source session and track identifier must not be treated as a permanent vessel identity.
Measure Observation To Screen Latency Under Realistic Load
Define the observation to display path and measure each stage. Network delivery, validation, correlation, storage, and rendering all contribute to delay. Agree acceptable behavior with operators under representative traffic, burst updates, and recovery conditions. Avoid a universal latency promise that ignores the intended use and available sensors.
Require the supplier to show backlog and dropped or rejected updates. The screen should degrade predictably when the system cannot keep up. A reduced update cadence with visible freshness is easier to evaluate than a responsive map quietly displaying old data. The AIS feed validation design is one part of this performance chain.
A Reference Path From Sensor To Screen
Trace reception, validation, track processing or incumbent track consumption, storage, screen delivery and rendering as separate stages. The application may consume an existing tracking service instead of owning correlation itself. Put that choice in the architecture so a slow display can be investigated without assuming the sensor caused it.
Define observation to display age only where observation time is trustworthy. Also measure receipt to display processing delay, which answers a different question. Report the proportion of updates within the agreed target, tail delays, load conditions and clock assumptions. A fast average can hide bursts that leave some tracks visibly old.
During recovery, specify whether the system first restores the current picture and then historical detail, or uses another agreed sequence; replayed history must not appear as new live observations.
Replay Vessel Tracks With Source And Identity History
History should preserve source changes, identity corrections, and the time range being replayed. Make replay visually distinct from live operations. Users must not mistake a historical position for a current one, and replay controls should not modify the operational call record.
Agree retention, access, and export requirements with the relevant owners. If data licensing restricts storage or redistribution, resolve that before promising a replay feature. Record the difference between observed history and any estimated trajectory. An estimate may support analysis, but it should not be presented as a received observation.
Test Track Loss And Recovery
Test this source loss sequence: a target is visible, one contributing source stops, the track becomes less certain, and the source returns. Check whether the user can identify the change, inspect remaining evidence, and understand any new correlation. Include two nearby targets to test an ambiguous match.
| Scenario | Evidence to request |
|---|---|
| Source loss | State transition and affected target visibility |
| Identity correction | Traceable history without silent replacement |
| Duplicate target | A controlled resolution process |
| Reconnection | Explained recovery and unresolved conflicts |
The International Organization for Marine Aids to Navigation (IALA) core Vessel Traffic Services (VTS) requirements guidance is a reference point for traffic system requirements. Apply the relevant guidance alongside local procedures and equipment documentation. Multi source track correlation requires its own acceptance scenarios if it is included in scope.
Include access checks for tracking history and exports, feed licensing, and application availability in procurement. Test alerts and geofence events under uncertain positions. Compare consuming an incumbent tracking service with building track processing; each option needs an explicit support owner and recovery test.
Evaluate The Operator Experience With Real Tasks
Ask an operator to find an uncertain target, identify the stale source, locate its request, inspect its history and explain the next permitted action. Observe errors and unnecessary navigation through source loss and recovery. Use those task results as acceptance evidence rather than judging only whether the interface looks modern.
Use a scripted call so evaluators can compare the same task across designs. Begin with a target whose identity is uncertain. Ask the operator to inspect observation age and source, then decide whether the evidence supports linking it to an existing vessel call. Record what remains unconfirmed.
Next, remove one contributing source and introduce a second possible identity match. The operator should find the conflict, inspect the remaining evidence and avoid treating a suggested association as a confirmed identity. Restore the source and replay the interval. Check that historical playback is visibly separate from live information and retains the correction history.
Finish by asking the operator to explain what the display establishes and what still needs external confirmation. Evaluate that explanation, navigation effort and mistakes against agreed acceptance criteria. A system passes this task when the evidence and limits are understandable, not simply when every target has a name.
Conclusion
Review the tracking screen while a source is healthy, stale, lost and recovering. In each state, the operator should see the last observation time, identity basis and any restriction on using that information.
Include a tracker restart in acceptance. Confirm that reused identifiers, delayed messages and replay cannot silently change the identity attached to a call or rewrite its allocation history.
How SDLC Corp Can Help
Discuss the operator journey for the anchorage management software with SDLC Corp, including any custom software development services needed for the proposed views or record model. Bring representative tasks and source-loss scenarios. Ask how users will inspect freshness, identity uncertainty, call history and recovered evidence, and request a scoped demonstration before accepting claims about usability or continuity at your port.
Frequently Asked Questions
Why Keep Vessel, Track And Call Records Separate?
The vessel is an identity, the track is a source's sequence of observations, and the call represents a visit. Separating them prevents repeated visits or restarted tracks from merging unrelated operational records.
What Should Happen When Updates Stop?
Mark the affected track with its age and the agreed stale or lost state. A last known position may remain useful context, but the display must distinguish it from a fresh observation.
Can A Tracker Reuse A Track Number?
The application should be designed for that possibility. Combine the number with source and session context, and verify identity again where continuity is uncertain rather than transferring the previous association automatically.
