AIS Data Integration: Preserving Meaning in Maritime Reports

AIS data integration brings Automatic Identification System reports into a shared data model so that vessel information can be compared, displayed and analysed. Its quality depends on preserving what each report actually says, including missing values, time assumptions and limits on interpretation. A valid message can still become misleading data if an unavailable heading becomes a number or a receipt timestamp is presented as the time of an observation.

This second article in the SynapseCommand adapter series examines that semantic handoff. The public AIS implementation provides a concrete example, while the AIS adapter reference remains the source for detailed support coverage.

At a glance

The International Maritime Organization's AIS overview explains the system's information-sharing purpose. The software baseline and declared evidence status are recorded in the release-pinned AIS manifest.

An AIS feed carries several kinds of information

AIS is a family of messages, not one complete vessel record repeated at every update. The U.S. Coast Guard's message catalogue distinguishes position reports, static and voyage-related data, base-station reports, aids-to-navigation reports and other message types.

That distinction shapes the receiving application. A position update does not automatically refresh every attribute previously associated with the vessel. Combining reports into a continuing record requires rules about identity, age and the source of each field.

In the published SynapseCommand AIS implementation, one supported message becomes an Entity and an Event. This represents the reported object and the occurrence of the report separately. It does not mean the translator has established a complete or independently verified picture of the vessel.

The integration question is therefore more specific than “does this system accept AIS?” It is which messages cross the interface, what each contributes and where information from separate reports is combined. The interoperability catalogue identifies the relevant adapter; the feed contract must define the actual delivery format.

Four data states that a maritime system should keep separate

For downstream review, we propose four distinct states. This is an editorial framework for reasoning about data quality, not a new AIS standard or an additional SynapseCommand schema.

These states can look identical in a poorly designed interface. A blank field might mean unknown, unsupported, not supplied or deliberately withheld. Filling every blank with zero makes the record easier to store while making its meaning harder to recover.

AIS provides concrete examples. The Coast Guard's Class A field reference distinguishes a heading value of 511, meaning unavailable, from valid headings. It also distinguishes a speed encoding of 1023, meaning unavailable, from 1022, meaning 102.2 knots or higher. A zero draught value in the static and voyage report represents unavailable information.

The adapter's sentinel handling turns these unavailable indicators into absent canonical fields and records which fields the source marked unavailable. It preserves a reportable speed floor as a floor. It also preserves a legitimate zero-latitude, zero-longitude coordinate rather than treating every zero as missing.

The benefit is practical: downstream software can ask whether it lacks a measurement before attempting to interpret that measurement. The same discipline applies to the position-accuracy flag. The implementation retains that flag without turning it into a measured error in metres. A category and a quantified uncertainty are different information.

The timestamp needs a source, too

The Coast Guard's field reference describes the UTC-second field in Class A position reports. Values from 0 to 59 identify a second within a minute; special values indicate unavailable time or positioning conditions. This field alone does not identify the day, hour or minute.

The published adapter uses different time paths according to the message. A valid full UTC date and time from a base-station report can be used directly. For supported reports with a usable UTC second, it selects the matching instant nearest reception. Where the message supplies no observation time, it uses receipt time and records that basis. A receiver timestamp in a supported NMEA TAG block can supply the reception instant; otherwise the injected clock supplies it.

This behaviour has an important integration implication. Selecting the nearest matching second assumes that the reception context is appropriate. A buffered, replayed or delayed feed needs a deliberate timestamp policy. An old report should not silently acquire the appearance of a fresh observation because it entered a new process today.

That is a design question for the complete data path, not evidence of a reported deployment defect. The handover should state whether a timestamp came from the source, a receiver annotation or the receiving application, and whether any reconstruction occurred.

One complete message is the translation boundary

AIS delivery also has a framing boundary. The implementation can receive a complete supported message across multiple sentences within one payload. It does not maintain a fragment-reassembly buffer across separate payloads.

That makes “multi-sentence support” different from “stateful stream assembly”. A feed collector must deliver the complete message in the expected form. The translator can then operate on that payload without silently depending on fragments received earlier.

Keeping the boundary explicit helps isolate failures. A missing fragment, an unsupported message and a valid message containing an unavailable measurement are different conditions. Treating all three as a blank vessel attribute would hide where the problem arose.

The platform architecture provides the wider context for separating input translation from downstream processing. A declared boundary is useful only when the surrounding integration honours it.

From vessel reports to a usable maritime picture

Consider a synthetic example. A position report supplies a usable location but marks heading unavailable. A separate report provides voyage-related information. A later process compares the reports with another authorised information source.

Three conclusions would be premature: assigning a heading simply because one is needed by a display, assuming the voyage information was refreshed with the position, or treating disagreement between sources as proof of intent. The appropriate response is to preserve the distinct observations and make any later interpretation visible.

This example illustrates a general handoff principle. Translation should not silently become enrichment. A consumer may legitimately estimate, correlate or classify, but it should retain the evidence and assumptions behind that result. The field-coverage document helps reviewers distinguish the adapter's mappings from information retained for subsequent use.

A common operational picture benefits from that separation: a shared symbol should not erase differences in freshness, source or confidence. In maritime and subsea-infrastructure protection, this supports review of reported behaviour against other evidence. It does not make an AIS report an independent verification of identity or make missing AIS data proof of hostile activity.

The related ADS-B integration analysis addresses the distinction between translation evidence and deployed acceptance. AIS adds a particularly visible semantic problem: an apparently ordinary numeric field may explicitly state that no measurement is available.

What bidirectional AIS translation can preserve

Bidirectional software support means supported inputs can be translated into the canonical model and supported canonical objects can be expressed in the output format. It does not imply that every canonical fact fits into an AIS message.

For the message types implemented here, the adapter source identifies canonical information that its AIS output cannot carry, including internal identifiers, track quality and the full provenance block. That information needs to remain available through an appropriate accompanying record if the receiving workflow requires it.

This is a scoped limitation of the implemented translation. It should not be broadened into a claim that AIS has no application-specific messages: the Coast Guard catalogue lists additional message families outside this adapter's subset. Nor does sentence generation establish a radio broadcast service or approval of installed marine equipment.

A fixture round trip needs an equally precise description. The AIS manifest records byte-level round-trip evidence for published fixtures, with TAG-block fixtures compared against the declared reference that excludes the receiver annotation. That is narrower than claiming every delivered envelope is reproduced unchanged.

Reading the current implementation evidence

The synapse-cdm 3.3.0 release, published on 8 October 2026, provides this article's software baseline. AIS is an existing adapter within that release, not a newly announced capability.

Its manifest declares L3 and VERIFIED as scoped evidence labels. The preservation basis is a value-presence heuristic, rather than a path-bound field ledger. These declarations do not establish universal losslessness, a named-system integration or operational acceptance. The published AIS tests let engineers inspect cases covering sentinels, fragments, timing and round trips.

Standards currency is a separate question. ITU lists Recommendation ITU-R M.1371-6, dated February 2026. The SynapseCommand manifest leaves its targeted format edition unspecified. The existence of that newer recommendation must not be converted into a claim that this adapter fully implements it.

The open-source integration layer makes these boundaries inspectable. Evaluation should use the actual supported subset, source mappings and release-matched evidence rather than infer coverage from the name of the standard alone.

A practical handover for integration teams

The following handover model is our synthesis for technical review. It is not an additional certification scheme or a claim that a deployed system has passed these checks.

For a maritime data pipeline, preserving uncertainty is part of preserving information. A useful integration lets the receiving team distinguish what was reported, what was unavailable and what was inferred later. That is the foundation for analysis that remains explainable when a vessel record changes, sources disagree or a decision is reviewed.

Discuss an AIS integration with the feed format, timestamp policy and downstream information requirements identified.