A radar AIS sensor fusion requirements checklist should describe how radar and Automatic Identification System (AIS) sources behave when they agree, conflict or stop updating. Specify input contracts, identity handling, freshness and recovery, together with evidence that a supplier can demonstrate.
A clean combined map is only one test condition. Procurement also needs to establish the local coverage assumptions and who owns the response when a source or association is uncertain.
Which Tracking Tasks Must Survive a Sensor Failure?
State the objective in operational terms before listing interfaces. "Maintain zone occupancy awareness and operator continuity during an automatic identification system (AIS) gap" is specifiable. "Integrate radar" is not.
| Requirement area | What to state | Common omission |
|---|---|---|
| Objective | Tasks that must survive degradation | Naming a technology instead of a task |
| Scope boundary | What the application does not take over | Silent overlap with traffic services |
| Sources in scope | Which feeds, owned by whom | Assuming the feed is available to the project |
| Acceptance basis | How continuity will be demonstrated | No test defined until go live |
Record which responsibilities remain with the vessel traffic service and the vessel master. The request for proposal (RFP) checklist should carry that boundary statement so bidders answer against the same scope.
Identify which anchorage allocation and occupancy workflows rely on tracking. Write continuity requirements around those tasks and the evidence needed to continue them.
Sensor Inventory and Ownership
List every source: AIS feeds and their provider, radar and its tracker, any additional sensors, and the port's own voyage and call records. For each, record the owner, the interface documentation available, whether a test environment exists, and whether commercial or network approval is needed to access it.
An interface described as available frequently needs work by a third-party before it can be used. The cross-supplier interface checklist is where those dependencies become dated actions with named owners rather than assumptions.
Sample Sensor Requirements with Pass Conditions
Illustrative example
These clauses are application requirements. Site coverage, sensor settings and navigational procedures remain with qualified owners; no universal detection or safety threshold is implied.
| ID | Requirement | Supplier Response | Acceptance Test / Evidence |
|---|---|---|---|
| SEN-01 | Each displayed observation shall retain source, observation time and receipt time | State supported behavior, dependency and evidence reference | Replay an old record; original age remains visible |
| SEN-02 | A radar only track shall not display uncorroborated vessel identity as confirmed | State supported behavior, dependency and evidence reference | Remove identity evidence; radar target remains explicitly unidentified |
| SEN-03 | Source loss shall change affected freshness state under the configured policy | State supported behavior, dependency and evidence reference | Stop feed; time stamped alert and owner shown |
| SEN-04 | Ambiguous association shall preserve candidate provenance | State supported behavior, dependency and evidence reference | Converging test targets produce reviewable ambiguity |
| SEN-05 | Recovery shall deduplicate replay and retain manual work | State supported behavior, dependency and evidence reference | Restore duplicate backlog; counts and decision history reconcile |
| SEN-06 | Track identifiers reused after restart shall not inherit an old identity | State supported behavior, dependency and evidence reference | New tracker session with reused identifier creates distinct track key |
| SEN-07 | Coverage and track performance shall be evidenced for the agreed site, targets and conditions | State tested coverage, exclusions and measurement method | Review site-specific results and unresolved blind areas |
| SEN-08 | Only permitted users and consumers shall access or change the scoped sensor records and configuration | Identify authorization boundary and denied-action evidence | Attempt an unauthorized read and rule change; retain denial and unchanged state |
Execute One Combined Loss and Recovery Test
At 10:00, the test vessel has a provisional association between observation A-1 and radar track R-1. At 10:01, the AIS feed stops. After the configured test threshold, the display marks that source stale while R-1 continues as radar derived evidence.
| Action | Pass | Fail |
|---|---|---|
| Inspect R-1 during source loss | Provenance and identity uncertainty visible | Old identity shown as newly confirmed |
| Enter an approved manual note | Actor and time retained separately | Source reconnect overwrites it silently |
| Replay A-1 on recovery | Duplicate recognized; original time retained | New receipt time makes A-1 look fresh |
The evidence bundle contains source records, configuration versions, observed results and the reviewer’s decision for each requirement. A general claim of “sensor resilience” cannot replace these results.
Specify Radar Tracks, AIS Fields, Time and Coordinate References
State whether the source supplies radar tracks or radar video. A track feed already provides target records. Producing tracks from video is separate work that needs its own scope and tests. List the required fields: target identifier, position, course, speed, quality, observation time and source.
- Time base and coordinate reference, stated once and applied to every source
- Update rate and maximum acceptable age per source
- Message or record formats, with sample data available during evaluation
- Identity fields, and which of them may be absent
- Retention of permitted source observations or an agreed audit representation alongside derived tracks, within licensing and retention limits
Application programming interface (API) and interface requirements provide the wider framework for these sensor interfaces, while AIS data integration covers identity fields and their failure modes.
Correlation, Confidence and Provenance
Specify the Operator Visible Result of Uncertain Identity
Ask bidders to show four states: AIS only, radar only, matched sources and conflicting sources. The display should explain how a name was attached to a track and when that match is no longer trusted.
- Association rules stated in operational terms, with edge case behavior
- Configurable preferred source rules, recorded when applied
- Conflict tolerance beyond which disagreement is surfaced
- Loss of correlation behavior, including track split and merge
- Identity reverting to unconfirmed when its correlation ends
radar AIS sensor fusion port operations describes what a complete answer looks like; radar integration anchorage management system covers the interface side of the same requirement.
Degraded Operation, Alarms and Recovery
Specify detection, not just display. The system should alarm on feed loss, on individual track staleness and on source disagreement, each with an owner and an expected response time.
- Named fallback states, visible to the operator without reading a log
- Defined permitted requests, approvals and queue actions while degraded; geofence results qualified or held when positional evidence is insufficient
- Operator confirmation of identity as a recorded, attributed action
- Controlled failback with proposed reattachments the operator can reject
- History and replay evidence of what was displayed and its sources, within agreed licensing and retention rights; identify any resulting evidence gaps
Degraded tracking and recovery sets out these states in detail. Real-time vessel tracking architecture defines the freshness thresholds the alarms depend on.
Security, Performance and Coverage Assumptions
Record the network path, permitted accounts and monitoring owner for each feed. Measure delay from observation to display under an agreed load. Ask which functions slow down first when the load increases and how users can tell.
Treat coverage carefully. Detection depends on site design, sensor placement, environment, clutter, weather, target characteristics and configuration. Ask for the assumptions behind any coverage statement and the conditions under which it was measured. A single range or accuracy number offered without conditions is not an answer.
The International Organization for Marine Aids to Navigation (IALA) G1111-1 guidance for core Vessel Traffic Services (VTS) requirements and the International Maritime Organization (IMO) vessel traffic services overview are appropriate references when writing these clauses.
Evidence, Testing and Support Ownership
Ask for evidence rather than assertion. Sample data, an interface specification, a demonstration against your own scenario list, and a named support boundary for each feed are all reasonable requests during evaluation.
- Simulated AIS loss during a working allocation scenario
- Radar only target handling, including identity confirmation
- Conflicting position reports and the resulting operator experience
- Correlation loss and recovery, with earlier manual identifications resolved
- Feed health monitoring and alarm routing verified end-to-end
Carry these into the demo and proof of concept checklist for selection, the user acceptance testing (UAT) checklist for acceptance, and the vendor evaluation scorecard so sensor resilience is scored rather than assumed. The service level agreement (SLA) and support checklist should state who monitors each feed after go-live and what a source loss incident obliges the supplier to do.
Carry the checklist into procurement as testable clauses: each needs an expected behavior, a source or dependency owner and an acceptance scenario.
Example Requirement Row for a Sensor Loss Test
Illustrative example
The following is a sensor-loss fixture, using a 60-second stale threshold solely for testing software behavior.
| Requirement Field | Completed Sample |
|---|---|
| Identifier / trigger | SEN-03A: T-1 last reports at 10:00:00; T-2 continues reporting |
| Expected display | When T-1 exceeds configured freshness limit T, mark it stale with its actual age; T-2 remains current |
| Workflow boundary | T-1 decisions requiring a fresh position are held; history remains readable |
| Recovery test | Replay T-1’s old report at 10:02:00: age remains 120 seconds; then validate a new report |
| Evidence | Observation IDs, screen timestamps, alarm ALARM-3 and recovery result |
| Owner | acceptance reviewer-2; source and application support roles recorded |
Before adopting the clause, replace the sandbox threshold with the locally approved value and validate the source conditions. Test loss of the whole feed separately from silence on one target. Mark radar specific tests not applicable if radar is outside the agreed scope.
Use the requirements-writing structure to give each sensor obligation a condition, owner and observable passing result.
Final Thoughts
Put source loss, conflicting candidates and recovery into the required demonstration, with observable results and retained records. Verify that identity and freshness change correctly instead of relying on the appearance of the combined display.
Keep local coverage, interface access and responsibility for association explicit in the proposal. Resolve those dependencies before accepting a promise of reliable fusion at the site.
Turn Requirements into a Brief with SDLC Corp
Discuss sensor requirements for the digital anchorage management platform with SDLC Corp through its software consulting services. Bring the source inventory, interface contracts and workflows that must survive degraded data. Request a scoped response covering source access, integration behavior, site evidence, operator acceptance and third-party responsibilities.
Frequently Asked Questions
What Evidence Should a Fusion Supplier Provide?
Request representative inputs, resulting tracks, source contributions and outcomes for conflict, loss and recovery. Include the interface and local coverage assumptions needed to interpret the demonstration.
Must a Fused Track Always Keep Its Vessel Identity?
No. The identity should be qualified or removed when association evidence fails the agreed rules. Test crossing targets and stale sources so a previous match cannot conceal later uncertainty.
How Should Source Loss Be Tested?
Interrupt a permitted test source and record the time to the expected stale state, allowed actions and recovery result. Use the agreed acceptance thresholds, keeping example values separate from local operating requirements.
