NMEA Failover Data Sources

[goboatingnow]

So maybe redundant failover controllers running a vrrp/master-slave-like mechanism between them?

A solution indeed

dave

[colemj]

It just occurred to me that if I set the Furuno NN3D as the "source" for all data on our other instruments, then all the rest of our instruments would automatically fail over to the secondary sensors/transducers when the Furuno does.

Not a workable solution for us because we often use the rest of the instruments when the Furuno is off.

Mark

[goboatingnow]

Originally Posted by colemj

It just occurred to me that if I set the Furuno NN3D as the "source" for all data on our other instruments, then all the rest of our instruments would automatically fail over to the secondary sensors/transducers when the Furuno does.

Not a workable solution for us because we often use the rest of the instruments when the Furuno is off.

Mark

how can you do that ? how can your MFD be a GPS source?

dave

[colemj]

Maybe I did not say that correctly. I can set the Furuno to repeat data on the network. I can set our other instruments up to get their data from the Furuno instead of the actual sensor/transducer. In other words, the Furuno shows up in the data source page for them, so I can just pick that instead of the actual data source.

Mark

[goboatingnow]

Originally Posted by colemj

Maybe I did not say that correctly. I can set the Furuno to repeat data on the network. I can set our other instruments up to get their data from the Furuno instead of the actual sensor/transducer. In other words, the Furuno shows up in the data source page for them, so I can just pick that instead of the actual data source.

Mark

Its the same system really, If all your receivers can handle multiple sources, then to work they need a failover mechanism, if thats the case just let them failover on the original sensors.

What you are in this case, doing isn't adding anything, not does it solve the issue where there isn't selectable source selection , or where selecting the next source on the list is done automatically , i.e. lots of devices just take the first one and if that fails , they error.

[colemj]

I was just pointing out that if the Furuno was set as the data source for the other devices, then when the Furuno automatically fails over to another source, the other devices will also do so by default because they are seeing the Furuno as their data source.

The other devices in our case do not have the failover feature that the Furuno does.

Or maybe this doesn't work the way I think it does - I have not tried it.

Mark

[DotDun]

Originally Posted by goboatingnow

DHCP is a major single point failure mechanism, distributed address resolution is a better method and is partially implemented in NMEA2k, however it leads to non routable networks.

DHCP can be as redundant as you like, either orchestrated (sharing state) or simply 2 independent DHCP servers serving the same broadcast domain (with different scopes). It's up to the client to chose which server it uses.

Originally Posted by goboatingnow

Requires the logic to be in every receiver , and such logic to be standardised, what about receivers with no UI ( or very simple EI). bringing up a new sender manually requires all receivers to be touched.


Major fight between primaries possible, needs an arbitrator ( i.e. fail over controller) or flight computer voting style logic = complex.

Logic doesn't need to be standardized. The logic can be simple, lowest address is the winner. example: Find 3 devices with GPS capabilities, use the lowest address one, if I suddenly don't like it for some reason, use the next higher address.

Originally Posted by goboatingnow

Yes, but you have no way in an arbitrary assigned addressing scheme m like NMEA2k, to control which address get assigned what.

I don't understand why this matters, a gps is a gps, wind is wind, why does it matter which one of the redundant sensors it comes from? If it matters, then you don't have truly redundant devices.

Originally Posted by goboatingnow

Yes and no , they have specifics for things like ECU failover, because unlike NMEA2k , J1939 has assigned meaning to addresses


for simple historic MFD centric systems yes, how do you handle APs radios, AIS, instruments, fuel flow systems, distributed switching, fly by wire, etc etc



Well after years of proprietary systems, there nothing like the zeal of the converted

The system is fundamentally flawed unfortunately and needs a lot more specification work, I mean look at the time to get the third party gateway specs agreed ( 4 years) and even today the Internet protocol is being still tossed around.

No argument here.

[DotDun]

Originally Posted by colemj

I was just pointing out that if the Furuno was set as the data source for the other devices, then when the Furuno automatically fails over to another source, the other devices will also do so by default because they are seeing the Furuno as their data source.

The other devices in our case do not have the failover feature that the Furuno does.

Or maybe this doesn't work the way I think it does - I have not tried it.

Mark

I don't believe Furuno will repeat N2K data back onto the same network it came from.

[goboatingnow]

DHCP can be as redundant as you like, either orchestrated (sharing state) or simply 2 independent DHCP servers serving the same broadcast domain (with different scopes). It's up to the client to chose which server it uses.

oh I know, but in the context of adding a kind of DHCP system to NMEA2k as an alternative to distributed addressing, it creates a single point of failure. I wasn't commenting on DHCP in large TCP/IP environments etc.

Logic doesn't need to be standardized. The logic can be simple, lowest address is the winner. example: Find 3 devices with GPS capabilities, use the lowest address one, if I suddenly don't like it for some reason, use the next higher address.

I presume you mean the user assigned instance number since you can't actually use nmea addresses as these change all the time.

Yes your approach is fine, it just means that all "receivers" must have a way of implementing the approach exactly the same. This is where we started, equally NMEA2K was designed to be self contained, Now a receiver must have a way of being setup , i.e. have an UI. ( say I have a smart fuel sensor thats uses GPS speed as its sped input, Now my fuel sensor must have an onboard UI to allow me to either enter source selection IDs, or to force failover. In reality this should be a network control function.

Secondly As I said when I started out NMEA should have dealt with the situation as part of the standard. in fact Corrigendum 2-2011 was the first to codify field programmable instance IDs. Uptil then many sensors of the same type couldn't even co-exist!.

even today setting the instance number is a real pain on a multi vendor sensor network

So what I was suggesting was a solution that doesn't require changes to existing devices,

But as you pointed out ( and I did too) the correct way would be to have an automatic fail over strategy, implemented as part of the protocol.

I don't understand why this matters, a gps is a gps, wind is wind, why does it matter which one of the redundant sensors it comes from? If it matters, then you don't have truly redundant devices.

Well a key situation where there might be several sensors, is to ensure that all devices failover to the same instance, You hardly want some devices , say reading one GPS and other devices reading another.

This brings up another interesting issue and that is again in NMEA 2k theres no "soft" way to take the device off the network, gracefully . So say I discover my GPS #2 is giving quirky occasional fixes, today Ive no easy way of removing that device and causing failove, other then taking down the bus and removing it.


Again whats missing in NMEA is an ability to "manage" the network using management tools, rather then either having to invoke propritary software or setups methods. If this management layer had been added, then MFDs and other devices with sophisticated UIs could then act as management consoles for the network


dave

[DotDun]

Originally Posted by goboatingnow

I presume you mean the user assigned instance number since you can't actually use nmea addresses as these change all the time.

I was referring to the capabilities discovery mechanism. If a receiver discovers the capabilities of every device on the network at initialization and when new devices are added, then network addresses are irrelevant. (e.g. = receiver remembers a gps on 56, 94, and 132) Addresses don't change on a device mid-session, only at network initialization..??

FWIW, Furuno does capabilities discovery relentlessly.

Originally Posted by goboatingnow

Yes your approach is fine, it just means that all "receivers" must have a way of implementing the approach exactly the same. This is where we started, equally NMEA2K was designed to be self contained, Now a receiver must have a way of being setup , i.e. have an UI. ( say I have a smart fuel sensor thats uses GPS speed as its sped input, Now my fuel sensor must have an onboard UI to allow me to either enter source selection IDs, or to force failover. In reality this should be a network control function.

Not arguing that a network approach isn't the best, I'm simply saying that lacking that from NMEA, which appears will be the case forever, using a simple algorithm such as capabilities discovery then selecting the lowest network address device would work.

Originally Posted by goboatingnow

Secondly As I said when I started out NMEA should have dealt with the situation as part of the standard. in fact Corrigendum 2-2011 was the first to codify field programmable instance IDs. Uptil then many sensors of the same type couldn't even co-exist!.

even today setting the instance number is a real pain on a multi vendor sensor network

So what I was suggesting was a solution that doesn't require changes to existing devices,

But as you pointed out ( and I did too) the correct way would be to have an automatic fail over strategy, implemented as part of the protocol.




Well a key situation where there might be several sensors, is to ensure that all devices failover to the same instance, You hardly want some devices , say reading one GPS and other devices reading another.

Yes, for some applications (none come to mind right now) that could be a problem. But on a properly operating network (i.e. all packets make it from end to end), if all receivers used my simple algorithm, they should all be using the same sources.

Originally Posted by goboatingnow

This brings up another interesting issue and that is again in NMEA 2k theres no "soft" way to take the device off the network, gracefully . So say I discover my GPS #2 is giving quirky occasional fixes, today Ive no easy way of removing that device and causing failove, other then taking down the bus and removing it.

Removing a drop cable shouldn't take the bus down causing a complete restart, it may corrupt a single transmission.

Originally Posted by goboatingnow

Again whats missing in NMEA is an ability to "manage" the network using management tools, rather then either having to invoke propritary software or setups methods. If this management layer had been added, then MFDs and other devices with sophisticated UIs could then act as management consoles for the network

Agree 100%

[goboatingnow]

I was referring to the capabilities discovery mechanism. If a receiver discovers the capabilities of every device on the network at initialization and when new devices are added, then network addresses are irrelevant. (e.g. = receiver remembers a gps on 56, 94, and 132) Addresses don't change on a device mid-session, only at network initialization..??

FWIW, Furuno does capabilities discovery relentlessly.

Well theres no real capabilities discovery system as standard in NMEA. There is the NAME process. ( which is a bit of a mis -mash). Sorry I should say that there is a Class and function ID system, but that is a very general form of ID. There is nothing that actually lets a 2K device really discover whats out there , It can say "hey Ive found a device thats says its an AP", but in reality it knows nothing about that device.

To my knowledge no system on a NMEA2k network should use the actual source address as an "instance" identifier. If Furuno does, its doing it wrong ( and that wouldn't be the first time they broke 2k rules!!). In a small network address rarely change, but In fact address resolution can occur at many time, including adding and subtracting devices, power up and by devices forcing an address resolution ( name clash etc). The network cannot assume any correlation between a physical device and its address. In reality there are serious shortcomings in some software implementations , where assumptions are made and address are stored. This often leads to aberrant behaviour that is sometimes seen on NMEA 2K networks, especially larger heterogeneous ones.

The correct way is to use the user programmed "instance" number, which is a bit field in the NAME field. This of course requires you to have the requisite setup tools. The instance ID does not change on address resolution, instance #1 remains instance #1.

I can't comment on Furunos discovery capability,( especially in a large heterogeneous network) but expecting all receivers on a NMEA 2k network to have the horsepower and software depth of a serious high end ( Well, OK, it runs Windows XP - LOL ) system like NN3D is not practical.

I susoect Furuno uses instance numbers, anything else is not reliable in that it cannot indicate a particular physical device.
dave

[colemj]

Originally Posted by DotDun

I don't believe Furuno will repeat N2K data back onto the same network it came from.

Well, I haven't tried it yet, but from the manual:

NMEA2000 Data Configuration
This page configures the information that the MFD will output on its own NMEA2000 port. The information embedded in the PGN will be the information coming from the Sensor that will be chosen as the Primary Source (see next paragraph). Enable each NMEA2000 Data PGN that will be sent through the individual MFD’s NMEA2000 port.

Since there is only a single N2K port on the MFD, I assume that this output is back onto the same network it came from.

I do know that at one time I had the GPS output box checked on the Furuno by mistake and the autopilot saw the Furuno as a source in the GPS setup page along with the Maretron GPS.

Mark

[muttnik]

I don't know what if any failover provision exists in OneNet, but I'm gathering that no-one on this thread is holding their breath waiting for it...

[goboatingnow]

Originally Posted by muttnik

I don't know what if any failover provision exists in OneNet, but I'm gathering that no-one on this thread is holding their breath waiting for it...

since its just an encapsulation of NMEA PGNS in TCP?IP no I don't think it will help, nor would I be holding my breath given NMEAs speed, lots of press releases, little actual reality.

Onenet is really just a way for NMEA to stem the transfer to Ethernet issues, I don't think it will work somehow in the long run.

[goboatingnow]

Originally Posted by colemj

Well, I haven't tried it yet, but from the manual:

NMEA2000 Data Configuration
This page configures the information that the MFD will output on its own NMEA2000 port. The information embedded in the PGN will be the information coming from the Sensor that will be chosen as the Primary Source (see next paragraph). Enable each NMEA2000 Data PGN that will be sent through the individual MFD’s NMEA2000 port.

Since there is only a single N2K port on the MFD, I assume that this output is back onto the same network it came from.

I do know that at one time I had the GPS output box checked on the Furuno by mistake and the autopilot saw the Furuno as a source in the GPS setup page along with the Maretron GPS.

Mark

Be surprised it would do this as there would be instance clashes, NAME clashes, etc. even address revolution issues. how would a receiver distinguish between the original PGN and the "spoof" PGN unless furuno did clever remapping, if so they just invented a "failover" controller !