Unsafe AIS oversight

[Jammer]

I would like to thank W5PAD for reporting the problem in detail.

It requires attention to detail to note such a problem, and considerable work to isolate it to the specific set of circumstances indicated here. We are fortunate that W5PAD has cared enough to share this information with us, as well as alerting manufacturers to this potential safety defect.

[conachair]

Just to add a little info....

Ages ago I set up node red on a raspberry pi to record every AIS message received to a txt file. Then left it running and forgot about it.
There re nerly 300,000 messages in there now.

I've just started feeding them back into Opencpn using node-red at and can confirm there are messages with an undefined COG. 4 so far out of 301 targets. No way of telling the unit they were sent from. If anyone wants the file or part of it to try to replicate the issue please ask, I'll send it.

OpenCpn seems to display these vessels just fine.

Never been so busy in this Portuguese lagoon

[W5PAD]

Originally Posted by btrayfors

What about AIS-enabled aids to navigation (ATONs). Do these show up, or are they ignored because they're not moving?

https://nauticalcharts.noaa.gov/publ...avigation.html

Bill

Bill,
Very good question and one I hadn't thought of. I was going to see if there were any AtoN nearby. But decided to look at the specifications for AtoN in the ITU as my first step. Good news, AtoN uses a dedicated message, which is message 21. The only GPS information transmitted in message 21 is position accuracy, lat, & lon. Message 21 does not send SOG and COG. So AtoN are not subject to this issue.

[W5PAD]

Originally Posted by Jammer

I would like to thank W5PAD for reporting the problem in detail.

It requires attention to detail to note such a problem, and considerable work to isolate it to the specific set of circumstances indicated here. We are fortunate that W5PAD has cared enough to share this information with us, as well as alerting manufacturers to this potential safety defect.

You're welcome.
My motivation was born in the fact that I have one of the AIS units that doesn't show on all MFDs. What good is it to have an AIS and not be seen by everyone?

[W5PAD]

Originally Posted by conachair

No way of telling the unit they were sent from.

If you look deep into message 24, part B you'll see two words for Vendor ID. One is 7 characters and the other is 3 charters. Sometimes it's fairly easy to figure out the vendor. Some examples I've found are WESTMAR = West Marine, AMC = AMEC, NVC=Navico, DYACTH = Digital Yacth, and VESPAR = Vespar. I'm using a free windows program titled AisDecoder to see these details.

[fadonatto]

"What about AIS-enabled aids to navigation (ATONs)."

The SH 300i will display the ICON on the MFD of a virtual buoy. As W5PAD described.

[W5PAD]

An update. For the last couple days I noticed a nearby Class A pleasure craft that had both COG and Heading set to undefined. I checked with the previous SH and Garmin MFDs and it was also not displayed on the chart but was in the AIS list.
So this issue isn't limited to Class B vessels, it applies to Class As as well.

[continuouswave]

Is this problem believed to be due to a failure of the AIS transmitter to comply with required specifications? That would be a serious concern for regulatory agencies to investigate, because behavior of AIS transmitters must conform to international specifications

If the problem is that a few chart plotters don't properly display AIS targets, that is not a problem for regulatory agencies because in general a recreational grade chart plotter is not required to conform to any particular specification for display of any data--at least not that I know about.

[W5PAD]

Originally Posted by continuouswave

Is this problem believed to be due to a failure of the AIS transmitter to comply with required specifications? That would be a serious concern for regulatory agencies to investigate, because behavior of AIS transmitters must conform to international specifications

I don't know if the suspect AIS units are not fully compliant with required specifications. The deepest I've dug is reading ITU-R M.1371-1 which states for Message 18, Class B position report, "Course over ground in 1/10° (0-3599). 3600 (E10h)=not available=default; 3601-4095 should not be used". I'm unaware of any other requirements regarding the outputs for Class B AIS units. As you can see, this requirement is silent on when to use Not Available or Default.
If it were up to me I would ONLY use Not Available or Default when the unit does not have a GPS fix, otherwise use values between 0-3599. I would argue that if there is a GPS fix then COG is Available, regardless if the computed value is meaningless (i.e., NaN when SOG=0). In this case a simple COG=0 would suffice. By the way, this is done by most other AIS manufacturers.

Does anyone know of other requirements that go beyond whats stated in ITU-R M.1371-1?

[tanglewood]

Originally Posted by W5PAD

I don't know if the suspect AIS units are not fully compliant with required specifications. The deepest I've dug is reading ITU-R M.1371-1 which states for Message 18, Class B position report, "Course over ground in 1/10° (0-3599). 3600 (E10h)=not available=default; 3601-4095 should not be used". I'm unaware of any other requirements regarding the outputs for Class B AIS units. As you can see, this requirement is silent on when to use Not Available or Default.
If it were up to me I would ONLY use Not Available or Default when the unit does not have a GPS fix, otherwise use values between 0-3599. I would argue that if there is a GPS fix then COG is Available, regardless if the computed value is meaningless (i.e., NaN when SOG=0). In this case a simple COG=0 would suffice. By the way, this is done by most other AIS manufacturers.

Does anyone know of other requirements that go beyond whats stated in ITU-R M.1371-1?

First, awesome job tracking this down!!

I think the only open question re the AIS device is whether an invalid (=3600) COG is supposed to also invalidate the target. It doesn't sound like it does, and the fact that the MFDs still list the targets and alarm on the targets says they haven't invalidated them either.

So this seems like a straight forward bug in some number of MFDs where they are incorrectly qualifying display of targets.

Keep after the vendors and don't let them blow this off. Maybe give them an A/B example of two sentences, one that displays and one that doesn't where the only difference is the COG value When I have done similar, many vendors are very grateful and fix the issues. Other don't give a crap, and then you know who not to do business with anymore.

[joehersey]

Originally Posted by W5PAD

... The deepest I've dug is reading ITU-R M.1371-1 which states for Message 18, Class B position report, "Course over ground in 1/10° (0-3599). 3600 (E10h)=not available=default; 3601-4095 should not be used". I'm unaware of any other requirements regarding the outputs for Class B AIS units. As you can see, this requirement is silent on when to use Not Available or Default....

Does anyone know of other requirements that go beyond whats stated in ITU-R M.1371-1?

Class A MSG 1,2,3 and Class B MSG 18 use identical data definitions for COG "Course over ground in 1/10° (0-3599). 3600 (E10h)=not available=default; 3601-4095 should not be used". See https://www.navcen.uscg.gov/?pageName=AISMessagesB for Class B message definitions and https://www.navcen.uscg.gov/?pageName=AISMessagesA for Class A. (BTW AIS ATON message definitions are there too). These definitions are specified in ITU-R M.1371-5, the most recent update to the ITU-R AIS standard.

For Class A AIS, COG is input externally. Unlike Class B, COG is not derived from the internal GPS except as a backup to that external input. IEC 61993-2 6.10.2.2 Monitoring of functions and integrity specifies an integrity alarm for own ship "AIS - no valid COG information" and an alarm when "SOG is greater than 5 kn and the difference between COG and HDT (heading true) is greater than 45 deg for 5 min".

The Class B standard IEC 62297-1 specifies that "The Class B "CS" AIS shall have an internal GNSS receiver as a source for position, COG and SOG". Perhaps the answer can be found in the GPS standard, IEC 61108-1Ed2, para 4.13.12.1 Accuracy of COG which states:

"The error in the COG (the path of the antenna position over ground) due to the actual ship’s speed over ground shall not exceed the following values:

....................Table 2 – Accuracy of COG
Speed range (knots).................Accuracy of COG output to user

0 to ≤1 knot..............................Unreliable or not available
>1 to ≤17 knots...........................................±3 °
>17 knots............................................. ......±1°"

"Due to the limitations of GPS receivers of this standard, it is not appropriate to include requirements for COG errors attributed to high dynamic movement. Such limitations shall be in the manufacturer’s operational manual."

So for Class B AIS, it seems to me that a COG value of "3600 (E10h)=not available=default" is entirely possible for speeds less than 1 knot. Disappearing targets may be more a fault of the display than the AIS itself.

[jeffrobbins]

That's correct Joe. It depends on the GPS receiver but in general if you aren't moving then the GPS returns an unavailable COG. Each of the Class A and B AIS position report messages provides an encoding (3600) for this. AIS transponders will vary on when COG is unavailable, is zero or even random when you are stationary and that depends on the GPS receiver as well as fix quality.

Unless the AIS is transmitting an unavailable COG when it shouldn't (eg. you are moving) then the problem is in the MFD.

[josky65]

Hi, long time stalker but now registered as i found this thread beeing in the same ballpark as my worrying discovery.
I recently put in Zeus3, with wind, speed, depth and a Triton display and a V50 VHF. In addition i put in a emB200 AIS transiever, but currently not connect to other than it's own GPS ant (waiting for 1more N2K cable).

So i do have ais reseption through the VHF and it seems to work fine BUT:
Yesterday i passed a cruiseship that did not show on my AIS (100meters away) and started to find out why. It showed on the list, and it turned out it was reported to be still where it had been moored 30 minutes earlier) i called them and a freind in the area. Cruiseship(coastal steemer) said they would check, but my freind could see it all the time. I rebooted the zeus and it appered. Later i saw the local rescuevessel by eyesight but not on the AIS, this time i also checked the TRiton and i could see it there on the simple AIS display.
The one thing in common for these 2 is class A and that they actively use navigation status, meening they set status to moored, underway using engine and towing astern (rescuevessel) e.t.c. I also know that the rescuevessel does not have headinginfo on AIS.
(i am one of the voluteer captains).
So have any of you (who seem to know your stuff) experianced anything similar?
Wondering if changing status when in range causes the problem

[tanglewood]

Originally Posted by josky65

Hi, long time stalker but now registered as i found this thread beeing in the same ballpark as my worrying discovery.
I recently put in Zeus3, with wind, speed, depth and a Triton display and a V50 VHF. In addition i put in a emB200 AIS transiever, but currently not connect to other than it's own GPS ant (waiting for 1more N2K cable).

So i do have ais reseption through the VHF and it seems to work fine BUT:
Yesterday i passed a cruiseship that did not show on my AIS (100meters away) and started to find out why. It showed on the list, and it turned out it was reported to be still where it had been moored 30 minutes earlier) i called them and a freind in the area. Cruiseship(coastal steemer) said they would check, but my freind could see it all the time. I rebooted the zeus and it appered. Later i saw the local rescuevessel by eyesight but not on the AIS, this time i also checked the TRiton and i could see it there on the simple AIS display.
The one thing in common for these 2 is class A and that they actively use navigation status, meening they set status to moored, underway using engine and towing astern (rescuevessel) e.t.c. I also know that the rescuevessel does not have headinginfo on AIS.
(i am one of the voluteer captains).
So have any of you (who seem to know your stuff) experianced anything similar?
Wondering if changing status when in range causes the problem

Most displays have features to filter out AIS targets that aren't moving. I would check the settings in your display.

[josky65]

Originally Posted by tanglewood

Most displays have features to filter out AIS targets that aren't moving. I would check the settings in your display.

Thanks for replying, yes i am aware of filters and these were set to "show all". Also the ship was steaming at 13 knots and the rescue vessel 30 knots, so should not be affected.

/j