An Automatic Identification System (AIS) integration turns source observations into records that anchorage software can interpret consistently. The adapter must preserve identity, position, time and provenance while distinguishing valid values from unavailable or invalid ones.
Receiving a message is only the start. Duplicate delivery, delayed observations and impossible coordinates need explicit outcomes so that the displayed position remains traceable to the original report.
Raw AIS, Provider Feeds Or Traffic System: What Input Will You Receive?
Ask whether the provider supplies raw messages, decoded observations, maintained tracks, or an aggregated service. Confirm geographic coverage assumptions, permitted uses, history access, test access, and commercial limits. A demonstration feed does not establish the rights or operating conditions of the production service.
| Contract item | Question to resolve |
|---|---|
| Message representation | Which message types and fields are delivered? |
| Time semantics | When was the observation made and when was it received? |
| Identity | How are identifiers, corrections and conflicts represented? |
| Delivery | Are gaps, retries and reconnect behavior documented? |
| Usage rights | May the port store, display, share and replay the data? |
The International Maritime Organization (IMO) AIS description provides background on the information system. Coverage and feed quality still need evidence from the selected provider. Keep procurement assumptions separate from capabilities demonstrated with the actual interface.
Choose The Acquisition Path Before Designing The Adapter
| Input available | Work the project must account for |
|---|---|
| Raw AIS messages | Decode supported message types, units and unavailable values |
| Provider normalized observations | Verify the provider's transformations, time provenance and usage terms |
| Vessel Traffic Management and Information System (VTMIS)-maintained tracks | Preserve track identifiers, source confidence and the incumbent's lifecycle semantics |
A normalized feed can reduce decoding work, but it does not remove the need to test quality or confirm data rights. Conversely, a raw feed gives more processing responsibility to the integration team; it is not automatically more complete. Request samples containing missing fields and interruptions from the actual input path.
Agree whether vessel static information arrives separately from position updates, and how the adapter joins those records without assigning them to the wrong visit.
The feed adapter supplies observations; it does not own allocation approvals. Keep that boundary explicit in the anchorage application architecture.
The AIS and traffic-system data flow helps assign responsibility when a provider or incumbent system has already transformed the observation.
Map AIS Fields, Missing Values And Timestamp Provenance
Retain observation and receipt times separately where available. Raw AIS time fields do not always contain a full date and time: US Coast Guard message documentation describes the Coordinated Universal Time (UTC)-second field in Class A position reports. Require the provider to explain how any complete observation timestamp is constructed, including its provenance and unavailable states.
Do not silently substitute receipt time for an unknown observation time. Use an explicit time zone or UTC representation in the exchange contract, and record units and coordinate reference assumptions. Validate required fields before publishing an observation to downstream screens. Quarantine malformed records with a reason rather than silently replacing missing values with zero.
Maintain the relationship between an observation, a vessel identity, and a vessel call. A Maritime Mobile Service Identity (MMSI) can be useful in matching, but a visit specific application record needs its own identity. A changed or conflicting identifier should create a reconciliation task. Resolving conflicting vessel and call records explains how to assign that correction without overwriting unrelated data.
Decode One Observation Without Inventing Missing Data
Illustrative example
The normalized provider record below is an application-facing representation, not a raw AIS radio message. It uses the non-operational test identifier 000000182. The provider supplies the complete observation time. Raw position messages can carry a seconds field rather than a complete date and time; retain how the provider constructed the timestamp.
{
"provider_id": "provider-A",
"observation_id": "O-55",
"mmsi": "000000182",
"latitude": 10.1,
"longitude": 20.2,
"speed_knots": 2.4,
"heading_degrees": null,
"observed_at": "2026-09-18T10:14:32Z",
"time_provenance": "provider_normalized",
"received_at": "2026-09-18T10:14:35Z"
}Follow The Transformation Chain
| Stage | Responsibility | Output Or Failure |
|---|---|---|
| Received radio message, where available | Retain the original message and receiver metadata under the feed rights | Decode the supported message type; reject a malformed message without inventing fields |
| Decoded source fields | Interpret source units, unavailable values and the UTC-second field | Preserve an unavailable heading and any missing date context |
| Provider normalization | Construct the complete timestamp only from documented receiver or provider context | The provider record shown above, with time provenance retained |
| Application validation | Check coordinates, duplicates and vessel/call association | Store the observation below or quarantine the invalid position |
A provider-only feed may not expose the first stage. Record that boundary instead of claiming the application decoded a raw message it never received. Reporting cadence varies by AIS class and vessel state; choose freshness rules from the actual feed and workflow rather than a common timeout.
Map The Feed Into An Application Observation
| Input | Application Value | Reason |
|---|---|---|
| mmsi | vessel_source_id: 000000182 | Identifier stored as text |
| latitude / longitude | position: 10.1 / 20.2 | Preserve coordinate order and units |
| heading_degrees: null | heading: unavailable | Do not encode an unavailable heading as north or zero |
| observed_at | 10:14:32, provider_normalized | Preserve time and provenance |
| received_at | 10:14:35 | Delivery time, not observation time |
| No matching call | call_id: null; match_status: pending | Observation retained without inventing a call |
At 10:14:35 the observation is three seconds old. If it is replayed at 10:15:35, it is 63 seconds old. A duplicate source identifier should resolve to the same observation, while a malformed position is quarantined with its original payload and validation error. The application can display an unmatched target without assigning it an approved allocation.
The Stored Observation And A Rejected Position
After normalization, the input produces this application record. The observation key is based on the provider’s stable identifier; an actual contract must define that identifier or an equivalent duplicate detection rule.
{
"observation_id": "provider-A:O-55",
"time_provenance": "provider_normalized",
"vessel_source_id": "000000182",
"call_id": null,
"match_status": "pending",
"position": {
"latitude": 10.1,
"longitude": 20.2
},
"speed_knots": 2.4,
"heading_degrees": null,
"observed_at": "2026-09-18T10:14:32Z",
"received_at": "2026-09-18T10:14:35Z",
"quality": [
"heading_unavailable",
"call_unmatched"
]
}| Next Input | Stored Outcome | Display Outcome |
|---|---|---|
| O-55 retransmitted unchanged | Existing observation reused | Age still measured from 10:14:32 |
| O-56 contains latitude 95 | Rejection Q-56, reason latitude_out_of_range; original input retained | No plotted position from O-56 |
| Call match later confirmed as C-182 | Attributed association added | Observation linked to that visit without changing source time |
The rejected position is neither moved to zero coordinates nor copied from the last valid observation. Missing data and invalid data have different records and should remain distinguishable.
Recover AIS Feed Gaps With Replay Or Resynchronization
A practical design separates reception, validation, normalization, matching, storage, and presentation. Monitor each stage so an operator can distinguish a provider outage from a local processing failure. Track rejected records and processing backlog alongside connection status: an open network connection is not evidence of a fresh operational display.
Specify recovery behavior before implementation. If the source supports replay, define the recovery window and ordering rules. If it does not, show the gap and obtain a fresh snapshot where available. Never reconstruct missing observations as if they had been received. The vessel tracking application requirements should reflect these limitations in the user interface.
Make Freshness And Uncertainty Part Of The Screen
Show The Age And Quality Of The Evidence
Show the last observation time, when available, and a meaningful freshness state. If source time is unavailable, label that uncertainty and distinguish receipt gap monitoring from evidence of observation freshness. Distinguish unavailable information from a valid empty value. Allow users to inspect the source of a position without opening a technical log.
Avoid using color alone for current, stale, or conflicting observations; pair it with text and recognizable status symbols.
Where radar or fused data is also available, preserve source-specific states. Radar only does not imply confirmed identity, and AIS only does not prove that every nearby target is represented. Working through an AIS loss contingency should be part of the operating design before the feed supports consequential decisions.
Validate The Adapter With Difficult Messages
| Test input | Expected application behavior |
|---|---|
| Duplicate observation | No duplicate operational record |
| Late observation | Original time retained; ordering policy applied |
| Invalid coordinate | Rejected or quarantined with an explanation |
| Identity conflict | Visible exception with a review owner |
| Feed interruption | Stale state, recovery information and an audit trail |
Measure performance against an agreed representative workload, including bursts and recovery. Keep test conditions in the evidence package. A result without message volume, timing assumptions, and system configuration cannot support a meaningful acceptance decision. Use a testable port system application programming interface (API) contract to align these obligations with the supplier.
Protect feed credentials, restrict authorized consumers and verify encryption or compensating network controls supported by the source. Agree storage and replay permissions. Where positions drive geofences, test boundary jitter and missing observations separately from request approval; a detected crossing is not an allocation decision.
Validate the adapter with representative difficult messages, then check that the operator sees the resulting freshness and identity states correctly.
Conclusion
Validate the adapter with a normal observation, missing values, an invalid position, a duplicate and a replay. Inspect the normalized record and the rejected record, not just the map.
Before accepting the feed, confirm that old observations retain their age and that repeated messages do not create duplicate events. Keep any transformation traceable to its source value and rule.
Evaluate An AIS Adapter With SDLC Corp
Consider SDLC Corp for an assessment of the AIS connection required by the digital anchorage management platform, including the relevant software integration services. Supply permitted feed samples with missing values, delayed records and interruptions. Request explicit responsibility for decoding or normalization, timestamp provenance, identity matching and recovery, together with acceptance evidence and any provider-side work needed before operational use.
Frequently Asked Questions
What Must Be Preserved From An AIS Observation?
Retain the source identifier, vessel identifier when supplied, position, relevant timestamps and quality information. Record where timestamps came from, especially when the adapter constructs a time instead of receiving a trustworthy observation timestamp.
Should Suspicious Positions Be Corrected Automatically?
Only through an approved transformation that retains the original value and reason. Otherwise reject or flag the observation. Replacing an invalid position with an unexplained plausible one hides the source problem.
Should We Use Direct AIS Or An Existing Traffic Feed?
Compare permitted access, processing already performed, source ownership and support obligations. An existing feed may supply needed tracking context; direct ingestion may require the application team to own that additional processing.
