AIS Static and Dynamic Data Verification

This article applies to yachts that carry AIS equipment or distribute AIS data to radar, ECDIS, conning displays, VDR, owner dashboards, monitoring systems, fleet portals, or bridge data gateways.

Applicability depends on flag state, class, yacht size and GT, private or commercial use, SOLAS applicability, AIS class, operating area, whether AIS is statutory equipment, whether AIS data is recorded by VDR, and whether the AIS feed is used outside the bridge.

AIS should be treated as safety-of-navigation and vessel-identification infrastructure. It is not only a screen icon or a tracking feature for guests. Incorrect AIS data can mislead other vessels, VTS, port authorities, search and rescue services, pilotage teams, and the yacht's own bridge systems.

AIS broadcasts information about the yacht to other AIS users. Some of that information is fixed or semi-fixed. Some of it changes with the voyage. Some of it comes from connected sensors.

The problem is that AIS can look "on" while still transmitting poor information.

Common examples include:

• wrong vessel dimensions after a refit,
• incorrect antenna reference point,
• old destination left from the previous passage,
• wrong navigation status,
• missing heading input,
• stale GNSS input,
• incorrect draught,
• incorrect call sign or MMSI after ownership or registration changes,
• duplicated or mismatched AIS data on radar and ECDIS,
• owner-dashboard AIS feeds presented without context.

None of these necessarily create an obvious alarm. The AIS may transmit, targets may appear, and the bridge team may assume it is correct. Verification is the step that turns that assumption into evidence.

Start by separating the three main groups of AIS information.

Static data identifies the vessel. It normally includes MMSI, vessel name, call sign, IMO number where applicable, vessel type, and dimensions.

Voyage-related data changes with the passage. It may include destination, ETA, draught, cargo or hazardous-cargo category where relevant, and navigation status.

Dynamic data comes from sensors and the AIS unit itself. It can include position, course over ground, speed over ground, heading, rate of turn, and time.

These groups fail in different ways. Static data may be wrong after a flag, ownership, equipment, or refit change. Voyage data may be stale because nobody updated it before departure. Dynamic data may be wrong because a sensor, interface, antenna, serial feed, Ethernet gateway, or configuration has failed.

Static data should be checked after installation, replacement, flag or ownership changes, name changes, refit changes that affect dimensions, antenna relocation, AIS service work, and periodically as part of bridge readiness.

Check:

• MMSI,
• vessel name,
• call sign,
• IMO number where applicable,
• vessel type,
• overall length and beam,
• AIS antenna reference point,
• GNSS antenna or positioning reference if configured,
• draught field where used,
• unit serial number and approval/service record where applicable.

The dimension fields deserve attention. AIS dimensions are not only brochure dimensions. They help other systems and users understand where the reported position sits relative to the hull. If an antenna is moved or the yacht has been extended, the AIS configuration should be reviewed.

Do not let the AIS become a museum of the yacht's previous identity. Old names, old call signs, old dimensions, and old MMSI records create confusion precisely when reliable identification matters.

Voyage data should be part of the bridge departure routine, especially before port entry, coastal passages, traffic separation schemes, pilotage, restricted visibility, or busy waterways.

Check:

• navigation status,
• destination,
• ETA,
• draught where required or operationally useful,
• route-related expectations where the bridge team uses integrated displays,
• whether the entry format is clear enough for other users to understand.

The navigation status should match reality. A yacht at anchor, underway using engine, constrained, not under command, moored, or aground must not be represented casually. The bridge team should follow the vessel's procedures and applicable rules; the technical team should make sure the AIS unit allows the correct entry and that officers know where to update it.

Destination and ETA fields are often neglected on yachts. Even when not treated as the most important AIS information, stale entries reduce confidence in the data. If the AIS still says the yacht is bound for last week's marina, it suggests the rest of the bridge data may not be under disciplined control.

Dynamic data should be checked against independent bridge sources.

Compare:

• AIS position against GNSS/ECDIS position,
• course over ground against GNSS or ECDIS,
• speed over ground against GNSS and speed log where relevant,
• heading against gyro, THD, or compass display,
• rate of turn where fitted,
• timestamp and position freshness,
• AIS target display on radar and ECDIS,
• VDR input where AIS is recorded.

Do not only check that numbers are present. Check that they are plausible and current.

A frozen heading, stale GNSS feed, or missing sensor input may not stop AIS transmission. It may simply degrade what others receive. If AIS data is also fed to VDR, dashboards, conning displays, or monitoring systems, bad source data can spread beyond the AIS unit.

AIS should be checked both at the transmitter and at the displays that use its data.

Confirm:

• own-ship AIS status on the AIS unit,
• AIS data on radar,
• AIS data on ECDIS or chart display where integrated,
• target correlation behaviour where radar and AIS are associated,
• AIS feed to VDR where applicable,
• AIS feed to bridge gateways or owner dashboards where used,
• alarms or fault messages,
• interface status for NMEA 0183, NMEA 2000, IEC 61162, or Ethernet feeds.

Be careful with owner dashboards and guest-facing displays. They should be treated as secondary, non-authoritative displays. They should not create pressure to rebroadcast bridge data casually into guest or AV networks, and they should not be used as proof that the bridge system is correct.

Where practical, verify how the yacht is seen externally.

Useful checks include:

• nearby vessel or tender confirmation where safe and appropriate,
• VTS or port feedback where operationally suitable,
• class or service engineer test equipment,
• controlled shore-side AIS receiver check,
• comparison with expected static data in official records.

Internet AIS websites can be useful for a rough sanity check, but they are not authoritative proof. They may be delayed, filtered, incomplete, or based on shore receiver coverage. Do not treat a public tracking page as the primary verification source for statutory bridge equipment.

AIS verification should be repeated after work that touches bridge electronics or networked data.

Trigger events include:

• AIS replacement,
• GNSS antenna work,
• heading sensor work,
• ECDIS or radar integration changes,
• VDR interface work,
• bridge network changes,
• serial or Ethernet gateway replacement,
• vessel name, MMSI, call sign, flag, or ownership changes,
• hull extension or major external modification,
• migration to a new dashboard or fleet-monitoring platform.

Service completion should not be accepted only because the AIS powers on. The evidence should show static data, voyage fields, sensor inputs, bridge display behaviour, and any relevant downstream feeds.

A yacht completes a refit that includes a new mast arrangement and an updated bridge dashboard. AIS appears normal on the bridge, and the yacht prepares for a busy coastal passage.

During a routine check, the ETO notices that the AIS antenna reference point still reflects the old installation. The bridge team also finds that the destination field is left from the previous delivery passage. Radar and ECDIS show AIS targets, but the owner dashboard receives AIS through a gateway that has not been documented.

The immediate fix is straightforward: correct the voyage data and have the approved technician or responsible bridge electronics provider update and verify the static configuration where required. The wider lesson is more important. A refit can change the relationship between sensors, antennas, displays, and data exports. If the verification only asks "is AIS on?" it misses the real risk.

The closeout should include updated AIS records, interface notes, bridge screenshots, and confirmation that secondary displays remain read-only and non-authoritative.

Keep a short verification record with:

• date and time,
• person checking,
• AIS make, model, and serial where useful,
• static data checked,
• voyage data checked,
• sensor inputs checked,
• radar/ECDIS display check,
• VDR or gateway feed check where applicable,
• screenshots or photos where appropriate,
• defects or corrections,
• follow-up owner,
• captain or officer acknowledgement where required by procedure.

This is not paperwork for its own sake. It helps the next bridge officer, service engineer, manager, or investigator understand what was checked and when.

Do not assume AIS is correct because targets appear on radar or ECDIS.

Do not leave destination, ETA, draught, or navigation status unchanged from the previous passage.

Do not ignore antenna position after refit, mast work, or equipment relocation.

Do not treat internet AIS tracking as formal verification.

Do not export AIS data into owner or guest systems without understanding the gateway and network boundary.

Do not let one service visit change AIS, GNSS, radar, ECDIS, VDR, or bridge gateway interfaces without an updated interface record.