Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 24-03-2014, 06:30   #1
Moderator
 
Dockhead's Avatar

Cruisers Forum Supporter

Join Date: Mar 2009
Location: Cowes (Winter), Baltic (Summer) (the boat!); somewhere in the air (me!)
Boat: Cutter-Rigged Moody 54
Posts: 19,750
NMEA Failover Data Sources

I have fiddled and fiddled with my network and can't seem to figure out how to set it up so that it will failover to an alternative data source in case the primary one becomes unavailable for some reason.

I have actually two interconnected networks (connected with a Maretron network bridge), which I set up that way so that I could shut down all the cockpit and engine room devices when I'm at anchor. The primary GPS is on the second network, but I have a secondary source of position data on the first network. I wish that when I shut down the second network when I'm at anchor, the network would failover to the secondary data source without requiring me to set up the data sources all over again.

Another case is heading data, which for some reason drops out occasionally. I have a backup source of heading data -- isn't it possible to program the network to use this if the primary source drops out?

Anyone know anything relevant to this question?
__________________

__________________
Dockhead is online now   Reply With Quote
Old 24-03-2014, 07:30   #2
Senior Cruiser
 
colemj's Avatar

Cruisers Forum Supporter

Join Date: Oct 2005
Location: Presently on US East Coast
Boat: Manta 40 "Reach"
Posts: 10,049
Images: 12
Re: NMEA Failover Data Sources

I don't think the "network" cares at all - it is just carrying the data from all sources. The individual components on the network are what chooses which data source to use.

Our Furuno chartplotter can be set to have primary and secondary choices from multiple data sources. If the primary goes down, it moves on to the secondary.

Our Simrad autopilot does not have this ability. If the primary goes down, the secondary has to be chosen manually in the source menu.

I have not played with this on the Tritons, but do not remember any way to set up primary and secondary data sources so that they automatically switch.

Mark
__________________

__________________
www.svreach.com

You do not need a parachute to skydive. You only need a parachute to skydive twice.
colemj is offline   Reply With Quote
Old 24-03-2014, 09:17   #3
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
NMEA Failover Data Sources

Unfortunately NMEA never addressed the issue of automatic source selection , in fact they hardly addressed source selection at all.

This led to the situation that source selection is entirely a function of the destination software. Ie things like MFDs etc. There is no standard or no agreed approach.

It also means that fail overs would have to be set up in all potential receivers individually like APa radios , AIS etc

NMEA 2k unfortunately is a half finished standard not really ready for prime time.

For example a sensor bridge could be designed do as to effectively spoof a GPS from a particular GPS sources, hence failing over to another GPS etc. But right now I don't beleive any like this is on the market.

Dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 24-03-2014, 09:29   #4
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
NMEA Failover Data Sources

To elaborate , what you need is a " automatic failover controller" for NMEA 2k. It would be programmed to effectively spoof transducers back put onto the network as a new source. You would then program in to each device that specific spoof transducer source ( this assumes you have source selection, many simpler devices dont unfortunately ) when the devices actually fail , the fall over controller merely takes data from the alternative source , all devices listening to the spoof address carry on as normal.

The advantage is you don't need destination devices with failover software. Merely source selection

Fancy an " investment " !!!!

Dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 04:18   #5
Moderator
 
Dockhead's Avatar

Cruisers Forum Supporter

Join Date: Mar 2009
Location: Cowes (Winter), Baltic (Summer) (the boat!); somewhere in the air (me!)
Boat: Cutter-Rigged Moody 54
Posts: 19,750
Re: NMEA Failover Data Sources

In other words, it can't be done without reengineering the network.

Bleh.
__________________
Dockhead is online now   Reply With Quote
Old 26-03-2014, 05:50   #6
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,429
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
To elaborate , what you need is a " automatic failover controller" for NMEA 2k. It would be programmed to effectively spoof transducers back put onto the network as a new source. You would then program in to each device that specific spoof transducer source ( this assumes you have source selection, many simpler devices dont unfortunately ) when the devices actually fail , the fall over controller merely takes data from the alternative source , all devices listening to the spoof address carry on as normal.

The advantage is you don't need destination devices with failover software. Merely source selection

Fancy an " investment " !!!!

Dave
Unfortunately, a 'failover device' such as this would be a single point of failure itself, not a good plan.

I'm don't believe the NMEA protocol pundits could handle anything as complicated as vrrp (master/backup devices), etc.

The best plan is for the receiving devices to handle sensor failover, like Furuno does.
__________________
DotDun is offline   Reply With Quote
Old 26-03-2014, 06:11   #7
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by DotDun View Post
Unfortunately, a 'failover device' such as this would be a single point of failure itself, not a good plan.

I'm don't believe the NMEA protocol pundits could handle anything as complicated as vrrp (master/backup devices), etc.
Its not a single point of failure because the original "non-spoofed" sources are still available and can be manually selected

Quote:
The best plan is for the receiving devices to handle sensor failover, like Furuno does.
No the system should have a standardised fail over approach. Otherwise you have to go around programming and pre-programming all the receiving systems, and this includes, instruments, APs, radios, MFDs, and god knows what else is receiving GPS and other sensors these days.

Its a mess. ( NMEA2K is of course a FUBAR of a system, incompletely specified and unsuitable for anything other then trivial installations . I mean look at the configuration mess)

Dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 06:20   #8
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by Dockhead View Post
In other words, it can't be done without reengineering the network.

Bleh.
No , correct , there are all types of issues with NMEA2k that start to appear once you build bigger networks, like you are beginning to see

(A) No gateway or bridging specifications, unlike say J1939, No standardisation of multiple redundant sensors, no standards around source selection, failover, backups , redundancy in general.

(B) No standard configuration methodology, hence the having to buy MFDs to configure specific sensors

(C) reliance on error prone , bus networks, as opposed to alternatives like star systems ( with or without active hubs)

(D) limitations on collision domains size, and cable propagation

(E) NO routable protocols

(F) No agreement on "on the wire" priority of messages, nor no mechanism to tune priorities to the system at hand.

(G) No centralised error handling or reporting like SNMP, making system error consoles very difficult to engineer and difficult to get an overview of all devices operation stats. ( as opposed to just bus monitoring)

(H) Issues with addressing scheme, bus-off technical issues,and other minor specs, that tend to appear in larger networks

(G) of course the well known issues like cable and connector standardisation issues, which stem from undue influence of its members,

(H) the marketing of NMEA compliant as opposed to NMEA certified products by the big four, especially Furuno


NMEA simply doesn't have the resources, nor is it independent of its members ( it is after all a representatives organisation , not a standards one)

If you want to see a proper spec for Can, have a look at the totality of J1939
dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 06:52   #9
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,429
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
Its not a single point of failure because the original "non-spoofed" sources are still available and can be manually selected



No the system should have a standardised fail over approach. Otherwise you have to go around programming and pre-programming all the receiving systems, and this includes, instruments, APs, radios, MFDs, and god knows what else is receiving GPS and other sensors these days.

Its a mess. ( NMEA2K is of course a FUBAR of a system, incompletely specified and unsuitable for anything other then trivial installations . I mean look at the configuration mess)

Dave
We certainly agree that NMEA is a mess, an engineering-standards-development-organization wannabe that underneath is a marketing organization driven more by company profits than best-in-class engineering.

The key to all things on N2k is it's network address (NA), hence when you choose a source inside a receiver, you are choosing it's NA. If that NA stops sending intelligent data, some/most receivers just sit there fat-dumb-happy while lacking data. Since we don't know the failure mode of the sending device, to have a standby device spoof the failed-device NA could be disastrous (2 devices sending conflicting data, control plane or corrupted user data, using the same NA). We really need the failed device to be silent when it fails. There are 2 ways to handle/simulate that, (1) either have an intelligent 'failover controller' receiving multiple sources and retransmitting data from the primary/secondary/tertiary sources using a different NA, or (2) you have a intelligent network protocol where a device participates in the slave role while monitoring the master in-wait to take-over the master's NA (hence the reference to vrrp).

My point above is that #1 in itself would be a single point of failure. #2 works as has been proven in networks for years.

My first-hand experience with Furuno NavNet3D has shown that when a source stops sending data, Furuno will scan for like data from another source and automagically use it, no setup required, hence no need for exotic network mechanism. It does take several seconds, to maybe a minute (or 2), but it does happen. It may not be optimum as a failover architectures are concerned, but better than nothing like others have.

But, since it's obvious NMEA doesn't care about intelligent network architectures, I'm sure we're simply wasting keystrokes...
__________________
DotDun is offline   Reply With Quote
Old 26-03-2014, 07:29   #10
Registered User

Join Date: May 2011
Location: Toronto
Boat: Sandpiper 565
Posts: 2,943
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
...there are all types of issues with NMEA2k that start to appear once you build bigger networks, like you are beginning to see
I recall you weren't so receptive to the idea of NMEA 2k being an open spec. Do you still feel that way? It's hard to imagine it being more dysfunctional if it was.

At it's simplest, the ideal network model might be closest to that of an Ethernet network with a DHCP router: devices are discovered and dynamically assigned a unique address, and receivers on the network can automatically detect and connect to any of the relevent senders.

In the case of multiple senders (eg multiple sources of GPS data), I guess the choices are:

  1. each receiver grabs the first of multiple senders it finds, as long as it appears active
  2. in each receiver you specify, you enter a preference for the primary sender
  3. each sender has a flag that can be set, to proclaim to the receivers that it's to be considered primary.
  4. in the absence of a flag or preference setting, the sender with the lower-numbered address is arbitrarily considered primary?

#1 - not good enough
#3 - seems preferable to me, but it would require the most cooperation from manufacturers to implement
#2 - can be implemented independently by each receiver maker, so it might be the most practical solution, even though you'd have to touch a setting in every receiver.

(I don't know all the J1939 spec; do they have a model for this sort of sender preference?)

DotDun's description of Furuno's NavNet 3D - that seems like sensible behaviour.

I went to the annual Raymarine dealer session this year in our area, and they are pushing NMEA2000 harder this year, and telling us that the answer to any customer question that starts with "How do I connect my NMEA0183 XXX to..." should be "Time to upgrade to NMEA2000". I believe Furuno and Maretron are already singing from that hymnbook. So these N2K dilemmas aren't going away.
__________________
Lake-Effect is offline   Reply With Quote
Old 26-03-2014, 07:48   #11
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
The key to all things on N2k is it's network address (NA), hence when you choose a source inside a receiver, you are choosing it's NA. If that NA stops sending intelligent data, some/most receivers just sit there fat-dumb-happy while lacking data. Since we don't know the failure mode of the sending device, to have a standby device spoof the failed-device NA could be disastrous (2 devices sending conflicting data, control plane or corrupted user data, using the same NA). We really need the failed device to be silent when it fails. There are 2 ways to handle/simulate that, (1) either have an intelligent 'failover controller' receiving multiple sources and retransmitting data from the primary/secondary/tertiary sources using a different NA, or (2) you have a intelligent network protocol where a device participates in the slave role while monitoring the master in-wait to take-over the master's NA (hence the reference to vrrp).

I can rabbit on for days on CAN systems as Ive designed many.

Leaving aside best network practice, which NMEA 2K isn't. your suggestion that failover is best incorporated in say a MFD, like Furuno, is a weak concept , arguably tied to a MFD, centric network design.

Yet today, we are heading towards a proliferation of devices that use sensor data, especially GPS data, ranging from fuel measuring system, VHF, AIS, MFD, sailing instruments, APs, not to mention electronic digital switching and thing alike fly by wire controls.

It simply not practical to solve source failover in an MFD is these situations, furthermore in a multi vendor network, each vendor may implement such failover in a different way, leading to anomalous operations. furthermore is it practical to add failover logic to all "receiver" devices. ( what about receiver devices with simple or no programmable UI )

A central failover controller at least centralises the decision logic, so that when its decides ( by monitoring the integrity etc , or doing master slave comparisons ) , at least the switchover applies to all devices simultaneously, without the need to maintain multiple setups in each receiver of data. Consistently is also assured.

Note if a Furuno MFD can decide to switch sources then a failover controller can to.!

Quote:
My point above is that #1 in itself would be a single point of failure. #2 works as has been proven in networks for years.
#2 yes, it has, but it is not practical for large NMEA style networks.

#1 is not a single point of failure as all original sources are still on the network, its just that manual intervention may be required, but the system at very least , fails-over to the current situation today.

Quote:
My first-hand experience with Furuno NavNet3D has shown that when a source stops sending data, Furuno will scan for like data from another source and automagically use it, no setup required, hence no need for exotic network mechanism. It does take several seconds, to maybe a minute (or 2), but it does happen. It may not be optimum as a failover architectures are concerned, but better than nothing like others have.
Several manufactures have built in failover systems , or more correctly automatic re-selection of similar sources, some do it well others not so. Many have none, they just pick up the first broadcast source address and "assume" thats the system source. Some get confused by multiple sources

But this system is MFD centric and thats no good as the network builds out. Its just not a good solution

dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 08:07   #12
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by Lake-Effect View Post
I recall you weren't so receptive to the idea of NMEA 2k being an open spec. Do you still feel that way? It's hard to imagine it being more dysfunctional if it was.
whether its open or not, tho problem of incomplete specification is a different issue.

Quote:
]At it's simplest, the ideal network model might be closest to that of an Ethernet network with a DHCP router: devices are discovered and dynamically assigned a unique address, and receivers on the network can automatically detect and connect to any of the relevent senders.


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.

Quote:
each receiver grabs the first of multiple senders it finds, as long as it appears active
We all agree thats the worst, what defines "first" for example.

Quote:
n each receiver you specify, you enter a preference for the primary sender
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.

Quote:
each sender has a flag that can be set, to proclaim to the receivers that it's to be considered primary.
Major fight between primaries possible, needs an arbitrator ( i.e. fail over controller) or flight computer voting style logic = complex.

Quote:
in the absence of a flag or preference setting, the sender with the lower-numbered address is arbitrarily considered primary?
Yes, but you have no way in an arbitrary assigned addressing scheme m like NMEA2k, to control which address get assigned what.

Quote:
(I don't know all the J1939 spec; do they have a model for this sort of sender preference?)
Yes and no , they have specifics for things like ECU failover, because unlike NMEA2k , J1939 has assigned meaning to addresses

Quote:
DotDun's description of Furuno's NavNet 3D - that seems like sensible behaviour.
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

Quote:
I went to the annual Raymarine dealer session this year in our area, and they are pushing NMEA2000 harder this year, and telling us that the answer to any customer question that starts with "How do I connect my NMEA0183 XXX to..." should be "Time to upgrade to NMEA2000". I believe Furuno and Maretron are already singing from that hymnbook. So these N2K dilemmas aren't going away.
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.

dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 08:29   #13
Moderator
 
Dockhead's Avatar

Cruisers Forum Supporter

Join Date: Mar 2009
Location: Cowes (Winter), Baltic (Summer) (the boat!); somewhere in the air (me!)
Boat: Cutter-Rigged Moody 54
Posts: 19,750
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
whether its open or not, tho problem of incomplete specification is a different issue.





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.



We all agree thats the worst, what defines "first" for example.



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.



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



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.

dave
If you step back to the point of view of the user, however, N2K works pretty well, mostly. It is a giant leap forward compared to NMEA1083, obviously.
__________________
Dockhead is online now   Reply With Quote
Old 26-03-2014, 08:33   #14
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Re: NMEA Failover Data Sources

Quote:
Originally Posted by Dockhead View Post
If you step back to the point of view of the user, however, N2K works pretty well, mostly. It is a giant leap forward compared to NMEA1083, obviously.
Yes but only for simple systems. as you build it out.... well all the chickens come home to roost as you are finding out.

dave
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 26-03-2014, 08:40   #15
Registered User

Join Date: Jun 2007
Location: SW Florida
Boat: FP Belize, 43' - Dot Dun
Posts: 3,429
Re: NMEA Failover Data Sources

Quote:
Originally Posted by goboatingnow View Post
I can rabbit on for days on CAN systems as Ive designed many.

Leaving aside best network practice, which NMEA 2K isn't. your suggestion that failover is best incorporated in say a MFD, like Furuno, is a weak concept , arguably tied to a MFD, centric network design.
I didn't suggest any such thing. I simply explained current state of affairs, which is lacking a network failover architecture, Furuno has produced a 'fix' that works as designed.

Quote:
Originally Posted by goboatingnow View Post
Yet today, we are heading towards a proliferation of devices that use sensor data, especially GPS data, ranging from fuel measuring system, VHF, AIS, MFD, sailing instruments, APs, not to mention electronic digital switching and thing alike fly by wire controls.

It simply not practical to solve source failover in an MFD is these situations, furthermore in a multi vendor network, each vendor may implement such failover in a different way, leading to anomalous operations. furthermore is it practical to add failover logic to all "receiver" devices. ( what about receiver devices with simple or no programmable UI )

A central failover controller at least centralises the decision logic, so that when its decides ( by monitoring the integrity etc , or doing master slave comparisons ) , at least the switchover applies to all devices simultaneously, without the need to maintain multiple setups in each receiver of data. Consistently is also assured.

Note if a Furuno MFD can decide to switch sources then a failover controller can to.!



#2 yes, it has, but it is not practical for large NMEA style networks.
Hmm, probably requires more discussion. A simple master/slave protocol with timed sync message can scale from very small to very large.

Quote:
Originally Posted by goboatingnow View Post
#1 is not a single point of failure as all original sources are still on the network, its just that manual intervention may be required, but the system at very least , fails-over to the current situation today.
And that's my point, if such a failover controller fails, we are no better (or worse from your POV) than we have today. A single point of failure, i.e. no automatic failover, is what we have today. Yes, the single failover controller could automagically cover the loss of a single sensor, but not a loss of itself.

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

Quote:
Originally Posted by goboatingnow View Post
Several manufactures have built in failover systems , or more correctly automatic re-selection of similar sources, some do it well others not so. Many have none, they just pick up the first broadcast source address and "assume" thats the system source. Some get confused by multiple sources

But this system is MFD centric and thats no good as the network builds out. Its just not a good solution

dave
An academic discussion, without a doubt!
__________________

__________________
DotDun is offline   Reply With Quote
Reply

Tags
nmea

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Help connecting our NMEA data sources offgridcanuck Marine Electronics 1 29-01-2014 12:17
Question About Alternative Data Sources in N2K Dockhead Marine Electronics 1 27-08-2013 06:58
Favorite sources for historic data? thompsonisland Weather | Gear, Reports and Resources 3 03-11-2012 07:07
Interfacing NMEA Data to Computer bobfnbw Marine Electronics 81 07-03-2012 09:46
Data Converter NMEA to Ethernet ticki Marine Electronics 2 21-03-2010 14:37



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 10:01.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.