NMEA 2000 network Alert PGNs seem great, so why are they hardly used?
Most of us get to see the NMEA 2000 data sharing standard doing good on our boats, like how the N2K output of a GPS receiver — or heading sensor, or AIS transponder, etc. — can be seen and used by almost any network display regardless of brand. But I’m sorry to report that most of us have also been missing out on a valuable NMEA 2000 feature that’s been available for over a decade.
I’m talking about the set of Alert PGNs — i.e. bundles of subject-specific data and command fields known by their Parameter Group Numbers — that theoretically permit any N2K device to send standard or custom alerts to any display, which in turn can silence or otherwise control the alert on all other displays.
In fact, the Alert PGNs seem quite well designed for sophisticated network alarming, but “theoretically” is the keyword because very few marine electronics developers have adopted the PGNs. I had a sense that Alerts weren’t all they could be, but the disappointing dimensions of the problem weren’t clear until I read the following Digital Yacht news blog entry by their chief technical officer Paul Sumpner, who is also a member of the NMEA 2000 Alerts working group.
At Panbo we think the issue is important enough to republish Paul’s essay in full. And at least this Ben will have lots to say about it in the comments section, and hopes that readers — N2K developers included — join in…
*********************************************************************************
NMEA 2000 Alerts
By Paul Sumpner, Digital Yacht
In the summer of 2012, the NMEA Organisation published a set of new NMEA 2000 PGNs that added powerful and important Alert/Alarm functionality to the NMEA 2000 standard.
Until that point individual PGNs had handled specific alarm conditions by having a custom, “hard coded” alarm enumeration field, where a list of predefined alarms were decided when the PGN was developed. For instance, the list built into PGN 127489 Engine Parameters Dynamic includes common notifications like low oil pressure and high coolant temperature. But changes or updates to these custom alarm lists were extremely rare, as all existing equipment would need to be updated for the new alarm to be supported.
To overcome this shortcoming of the original PGN alarm field method, a completely new Alert system was designed with six new PGNs and a massive database of predefined Alert IDs, encompassing all areas of marine equipment operation and use. Recognising that any such database would always need updating and expansion, the system was designed so that new custom alerts could be added at any time. Compatible equipment would support any future custom Alert with no change to the receiving equipment’s firmware. Figure 1 shows how a Garmin MFD will display an NMEA 2000 Alert.
This new system allows Alerts to be transmitted in English or in the local language, and also supports real-time acknowledgement, silencing and escalation if the alert condition is not cleared. This is functionality that the PGN alarm field method could never hope to support.
In terms of interoperability, the NMEA 2000 Alert PGNs allow any alarm system or MFD (regardless of manufacturer) to receive a safety critical alert and immediately display and sound an alarm, with full details of which device created the alert and what type of alert has been triggered. The same device can silence or clear the alert and all other devices on the network will see this interaction and take appropriate action. A typical Alerts Status monitor screen is shown in Figure 2.
Hundreds, if not thousands, of industry expert man-hours went into the design of this NMEA 2000 Alert system, and it is intended to play an important part in NMEA 2000 development, impacting the design of future PGNs. NMEA 2000 technical working groups and committees, tasked with designing new NMEA 2000 functionality, are relying on the Alerts system to take care of any alarm or error communication. In addition, Alerts will also be supported by OneNet gateways to allow low-level alerts on NMEA 2000 devices to be communicated to high-level OneNet systems.
So it might come as a shock to discover that implementation by manufacturers of the NMEA 2000 Alerts, has been very low. With the exception of Garmin, none of the large MFD manufacturers support the Alert PGNs and only a few manufacturers are building products that transmit or receive these Alerts.
During our investigation and tests, we only managed to get Garmin MFDs to display and control Alert PGNs, which is good news for Garmin but not for boat owners wishing to use other makes or MFDs. Earlier this year, we got excited when we found that Raymarine were declaring that their LightHouse V4 supported the Alert PGNs, but their implementation appears to be fairly restricted and we were unable to get them to receive any alerts from our NAVAlert unit.
When you have an NMEA 2000 network with Alert compatible devices on it, good things can start to happen. Alerts generated by one manufacturer’s device, can immediately trigger safety critical alarms on devices from other manufacturers, even for alerts that those devices have no knowledge of or that were invented years after the MFD was developed. Additional network devices can centrally manage, log and control, all of the alerts that occur on the network, sound their own alarm buzzer and even send an SMS message to your phone, if you are away from the boat.
It is not uncommon for manufacturers to only implement some of the available NMEA 2000 PGNs and if this issue was just related to some systems having extra functionality and gaining an advantage over their competition, then supporting Alert PGNs would not be so important. But when manufacturer lethargy limits effective alarming for new NMEA 2000 networked technologies – like electric propulsion, cybersecurity, bow/stern thrusters, etc. – then it becomes a critical threat to our industry.
Support for Alerts in OneNet is mandatory for any manufacturer wishing to develop and certify a OneNet product and with hindsight, it might have been better if the same had happened in NMEA 2000 when Alerts were first published, but we are where we are and there is no going back.
It is time for manufacturers to wake up to how important NMEA 2000 Alerts are for the sake of our industry, and to develop a timely and effective implementation plan for their current and future products to support NMEA 2000 Alerts. The user benefits are clear and compelling and failure to include support for Alerts, will ultimately affect the performance of all future NMEA 2000 and OneNet networks.
I don’t think that the pitifully low industry support for N2K Alerts is motivated by ill intent, or the result of simple lethargy. I suspect it’s more because even the ‘big’ marine electronics companies aren’t actually that big, and they all have lots on their development roadmaps. Plus there’s a negative network effect, as in “Why support brand agnostic Alerts if no one else is?”
But maybe there are valid reasons not to support Alerts? Developers, please speak up.
That said, the state of Alerts described by Paul seems damn sad to me. I know for a fact that a boat can be more reliable and easier to operate if any critical system can alert me about an abnormality or alarm me about a real problem. More to come.
The reason I’m so confident about the value of flexible N2K alerts and alarms is that I’ve had them on my boat for years thanks to various Maretron sensors and displays. For instance, I keep a temp sensor bolted to the main engine block set to a value slightly above normal operating conditions so I get warned about overheating way before the engine’s high coolant temperature alarm goes off. This is so important to my Volvo Penta — which has twice blown large exhaust manifold O rings and lost almost ALL coolant in minutes — that I have an alarm set up to activate very loud Maretron ALM100 alarm modules at both helms.
And like DY’s nifty NavAlert, the Maretron DSM displays allow me to set up alerts or alarms on any value on the N2K network. However, Maretron designed this system before the standard NMEA 2000 Alert PGNs were published, so in many ways it’s a closed system, and sadly remains so. Checking recent manuals I see that Maretron alert PGNs are still all proprietary and thus won’t even pop up on a Garmin MFD.
Moreover, if the standard Alert PGNs had already been widely adopted, the various Vesper AIS transponders I’ve tested over the years could have sent their valuable collision and anchor drag alarms to Gizmo’s ALM100s instead of me having to rig a less effective relay-driven audio alarm. In fact, I think there’d already be a lot more choices in alarm/alert organizers like the Maretron DSMs and NavAlert, and also loud N2K-powered sound alarms, if the MFD screens would do the right thing and spell out what the alert or alarm is about, and then offer to control it across the system.
So I plan to search the PGN lists in the back of manuals for 126983 Alert, 126984 Alert Response, 126985 Alert Text, 126986 Alert Configuration, 126987 Alert Threshold, and 126988 Alert Value. And you can too. Maybe a list of who does and does not support Alerts would be motivating 😉
Incidentally, I’ve known Paul Sumpner for many years and consider him a highly trusted source. That also means that I have an educated guess about the vessel using the unusual NavAlert alarms seen in Figure 2 above. I believe it’s the Sumpner family’s fascinating electric narrowboat Old Nick: https://thesumpnersafloat.com/
Definitely a chicken/egg situation. I was browsing the SignalK specs and their support for alert appears non-existent as well. Garmin can display them, but if nobody is sending them… I’ve noticed a similar dearth of support for the Anchor chain PGN’s which have also been around for quite some time. Again, Garmin can display them but nobody sends them.
derp. It looks like signalK does support alerts via the /vessels//notifications/ path.
A Google search on “PGN 126983” returns a frustrating low number of products….
1) Airmar with their latest SmartBoat product
2) BM21 Lithium Cranking/Trolling battery… https://lithiumbatterysource.com/products/lithium-pros-12v-215ah-marine-starting-battery-with-nmea-2000
3) Xantrex Freedom X Inverters… https://xantrex.com/products/inverters/freedomx/
4) ComNav G series Satellite Compasses
5) LXNav E Series MFDs
6) JMA-3400 Series Radars
Yike. I think It’s great that Lithium Pros is trying to use NMEA 2000 well, but how will a user know that the promised battery alerts are not showing on their MFD (if it’s not a Garmin)? In fact, they footnote “The BM-21 embedded battery monitor… is “plug and play” with all NMEA 2000 multi-function displays” with this warning: “Check MFD’s documentation to insure it recognizes at least PGNs 127506 and 127508 for minimum compatibility.”
However, while a user would likely see that 127506 DC Detailed Status and 127508 Battery Status were not showing in normal use, a 126983 Alert won’t go to their MFD unless something is going wrong. Lawsuits waiting to happen, and not really Lithium Pros’ fault?
https://lithiumpros.com/products/n3110-s-12v-110ah-marine-starting-battery-with-nmea-2000
https://youtu.be/ouyiuJ4-yA8
For a public list of all standard NMEA 2000 PGNs as of March 2023, download the PDF at the bottom of this web page: https://www.nmea.org/nmea-2000.html
The list includes field descriptions like the PGN 126983 Alert fields you can see in the screenshot I used at the top of this entry.
It’s my understanding that NMEA does not require manufacturers to transmit or receive any specific data PGNs, and that their certification process is mainly about validating proper network protocols. Like Paul, I can certainly see an exception for Alerts — and am tentatively glad that’s the case for OneNet — but I can also see that adding Alerts may be a significant burden for the developers.
On the other hand, I’m pretty sure that NMEA 2000 certification does require manufacturers to clearly state which PGNs are transmitted and received, info that’s usually found in the back of the manual.
Hi all three (including Paul),
To add a comment, being a manufacturer, thank you for putting the spotlight on this under used feature!
Garmin highlighted the same to us. And I was and still am convinced: super useful.
Its on our list to implement, has been for quite a while, and we’re – slowly – getting closer to being able to work on it.
R&D capacity is still our scarcest resource; in the midst of an abundance of pending ideas and improvements.
Now, having learned from the article that only Garmin supports them, I might decide to move them a bit further down on the list ;o). (Thats a joke).
Have a good day!
Thanks, Matthijs, you already improved my day!
It’s excellent news that you have already recognized the potential value of these standard Alert PGNs. And as a manufacturer/developer who has already impressed a lot of vessel owner/operators — particularly those of us who appreciate good electric power monitoring and alerting — you could really help make Alert PGN support more widespread.
For instance, if I could configure my Cerbo GX to output selected alarms to my boat’s N2K network, Furuno would hopefully become more motivated to support the Alert PGNs on their TZ series MFDs. Because then customers like me could get a clear notification like “Victron Cerbo: House Battery SoC below 20%” on the big screen we pay most attention to when underway. And of course the alert could be much more specific to a boat’s particular electric system and hence much less likier to ever be supported within brand by an MFD manufacturer.
Moreover — if I understand the Alert PGNs correctly — Victron GX could also serve well as an Alert receiver. If, say, my N2K network included an N2K alert/alarm manager like Digital Yacht’s NavAlert, they could pop up on my GX Touch screen. Perhaps better yet, the alerts could get to me anywhere via my already rich VRM site ( https://vrm.victronenergy.com/installation/105905/share/ea38a0bd ). As Ben Stein just wrote in a side conversation: “…the remote aspect of those alerts would be a huge value add. Plus, potentially logging all those alerts and having a record…” Wow!
Not that I’m pushing you to move Alerts up the Victron “pending ideas” list 😉
I wouldn’t be a bit surprise to find that some lawyer decided that implementing the alert but then having it fail to be delivered for some reason once it became relied upon would result in a huge lawsuit. There are instances of such “exposure prevention” risk management in other domains.
Hi all !
I am happy to report that our company has started using the NMEA Alert in new NMEA certified products. One of our product, the Interact DCM (https://www.sportsmanboatsmfg.com/seastar-interact-dcm-digital-switching-system) has supported it for a couple years to show faults such as low fluid level, open/short circuit, thank kind of things.
It is a bummer that not more MFD support the system natively. Because of that, we support a simplified version of it (acknowledgement and fault history only) in our HTML page that can show on all big MFD brands.
But it is definitively a round about way to do it !
Tom, I’m glad to hear that Dometic is adopting the N2K Alert standard, and thanks for reporting it here.
I’m also glad to add more good news gleaned at METS:
* Raymarine is purportedly adding full Alert PGN support to its MFD software.
* Support for the standard Alert PGN’s is on Maretron’s “to do” (though they developed their own very capable alerting PGNs before the standard ones were created).
* The emerging NMEA OneNet standard requires developers to support Alert PGNs whether they originate in OneNet or arrive via NMEA 2000 gateway.
The going may be slow, but I’m optimistic for widespread Alert interoperability eventually.