Panbo

NMEA OneNet 2013, already ahead of the curve?

... written for Panbo by Ben Ellison and posted on Dec 9, 2013

2013_NMEA_OneNet_Committee_courtesy_NMEA.jpgOneNet is the NMEA's ongoing effort to create a subset of Ethernet and Internet Protocol (IP) standards for marine electronics. It won't be fully released for two more years, but I liked what I heard (and could understand) in a September seminar delivered by NMEA Technical Director Steve Spitzer. When I first wrote about OneNet, for instance, some skeptical commenters could only envision it as a way for the major manufacturers to keep small developers out and profits up. But that seems paranoid when you consider the wide variety of organizations who are volunteering time and expertise to create OneNet...

The team working on OneNet ranges from numerous small companies up thru the Big Four (Furuno, Garmin, Navico and Raymarine) and on to IP giants like Cisco and Microsoft.  Also included are Coast Guard groups interested in general marine safety and the safe, efficient performance of their own fleets, as well as the forward-looking engineers I met at South Korea Maritime U. last June.

NMEA_OneNet_2013_Ahead_of_the_Curve_NMEA.jpg
Spitzer began his presentation rather boldly, with first this slide suggesting that OneNet is "Staying Ahead of the Curve" and then another stating that "The World has finally caught up with the Marine Electronics Industry"!  He seemed to be grinning -- at the skeptics? -- as he said that, but I can't think of a similar technology niche that's trying to integrate its specialized data and environmental conditions into IP standards like this. You can download the OneNet slide show PDF at the NMEA.org (along with other 2013 Conference goodies), but I'll try to cover Spitzer's main points below.  

NMEA_OneNet_2013_IoT_NMEA.jpg

Steve spent a lot of time discussing the Internet of Things (IoT), which is sometimes alternately called the Industrial Internet or M2M (machine to machine). No matter what it's called, it's getting pretty obvious that all sorts of devices are going to get on the Internet one way or another -- like 50 billion by 2020 in Cisco's estimate --and Spitzer also had some startling numbers like the brontobyte to describe what that will mean in terms of needed IP storage, unique addresses, etc.  All of which is vastly more complicated in the world of marine electronics where major systems must keep on working when not connected to the outside world, or with much reduced bandwidth...and in damp dynamic conditions.

NMEA_OneNet_why_IPv6_courtesy_NMEA.jpg

All the IoT talk seemed, at least in part, a justification for NMEA's decision to skip IPv4 altogether in favor of the rapidly emerging IPv6  protocol. I don't know much about the intricacies of IP, and Wikipedia claims there's only 2% Google IPv6 access right now, but Spitzer seemed to make a good case for how well IPv6 will work in the boat world. Plus, 2% is not actually a small number if it's four times more than the year before, which I guess is a reason why a OneNet standard that won't hit the docks until 2015 can still be "ahead of the curve."  

NMEA_OneNet_cables_connectors_courtesy_NMEA.jpg

The proposed waterproof OneNet connectors and cables are a lot easier to understand, and they look good, I think. You can already find d-coded M12 Ethernet cable that will be standard for less-than-100Mbs OneNet. Like NMEA 2000 DeviceNet cables, they're not cheap, but also like N2K cables, they're both rugged and reusable, and there is a competitive marketplace. Plus, you can always adapt to regular RJ45 Ethernet cabling if you want. X-coded m12 Ethernet cabling is more exotic, and it's still only a OneNet "Recommend" mainly because the IEC hasn't yet elevated it higher, but committee member Molex makes x-code sound very capable
    While I think "recommend" does mean that a manufacturer could use a proprietary OneNet connector on their device, NMEA probably has time to come up with a "Standard" high-speed OneNet connector and besides, I doubt any manufacturers will make the same mistake some made with NMEA 2000.  Afterall, there's only two proprietary N2K cabling systems still in production - Raymarine's SeaTalkNG and Fusion Audio's - and I'm not sure either company is happy with the situation (though adapter cables can handle both). At any rate, isn't it nice to think of a future where you could buy, say, an IP navigation camera and have it plug'n'play with whatever OneNet gear you already have on board (and possibly older Ethernet gear that's been updated to OneNet)?

NMEA_OneNet_2013_Internet_Apps_NMEA.jpgOf course there's more to plug'n'play than connector compatibility, but Steve Spitzer had good news on the software front as well. In fact, the committee is hopeful that OneNet will be the first, or one of the first, to support both leading "Discovery Services" at once.Thanks to sharp marine developers at Vesper MarinezapfwareNavico, and PocketMariner, I've already experienced how nice and easy it is to connect iPad apps to boat hardware with Apple's Bonjour version of zero-configuration networking. Apparently, Microsoft and other non-Apple companies tend to use the Simple Service Discovery Protocol (SSDP) and/or Universal Plug'n'Play (UPnP) with similar results, and -- blessed be! -- NMEA wants OneNet to work with all the software ecologies.

OneNet's main goal, though, remains the safe passage of NMEA 2000 data messages and commands (aka PGN's) out to a boat's OneNet (Ethernet) system and beyond, plus moving data in the opposite direction. I think I'm already enjoying the "Internet of Things" when Gizmo's Siren Marine system sends me an email and text every morning reporting on temperature and battery states (that's how I know that the solar panels are trickle charging through white shrink wrap). What the heck will it be like when every OneNet device on our boats has its own Web page like the one proposed below?

NMEA_OneNet_proposed_device_Web_page_courtesy_NMEA.jpg

Comments

I don't know why the Committee is trying to come up with proprietary X-coded M12 connectors. They only need to look in their Digi-Key catalogue to see that there are several kinds of water resistant connectors that are compatible with standard RJ45 cables. Unless the equipment is being installed in a submarine, installations don't require a waterproof connector. Water resistant, or in most cases, standard cable connectors are sufficient. My Rogue Wave uses a standard (read low cost) RJ45, and has been trouble free for over three years.

Ben, can you tell us why the Committee thinks that a new cable and connector design is necessary.

Posted by: Rick R at December 9, 2013 8:54 PM | Reply

Rick, what makes you think that x-coded M12 connectors are proprietary? That's certainly not what I meant to convey in the entry. What Steve Spitzer said at the seminar was that NMEA didn't want to reinvent any wheels, and that all the components to OneNet (aside from how to handle boat data) will be commonly available from multiple sources. X-coded M12 apparently is not quite common enough yet, which doesn't make it proprietary but does mean that NMEA is not yet willing to make it anything more than a recommended at this point.

As for standardizing OneNet on RJ45, that's just not going to happen and it shouldn't happen. I too have had a regular RJ45 cable work fine for 3 years to a Rogue Wave WiFi booster, but I would have hated to see that same connection on my radar. And Gizmo is a cruising boat, not a commercial or USCG boat going out in most any conditions.

I also think I've tried about every style of waterproof RJ45 connectors used in marine electronics, and none of them look as reliable and as easy to install as those M12 connectors. The cable itself also appears tougher and better shielded than even the outdoor grades of Cat 5 associated with RJ45.

In my view, the marine high-speed data standard should definitely favor the highly rugged and waterproof end of the cable and connector spectrum. OneNet to RJ45 adapter cables will be plentiful and anyone can step down, but, as with NMEA 2000 data cabling, I think this is a poor area of a boat to go cheap (and the dollar difference relative to most boats is pretty trivial). If I might coin a new phrase: "It's your DATA, matey!"

Posted by: Ben in reply to Rick R at December 9, 2013 10:21 PM | Reply

Rick, it turns out that there are already multiple manufacturers of x-coded M12 Cat6 industrial Gigabyte Ethernet cable, besides Molex:

http://www.metz-connect.com/en/connecting-cables-m12/x-coded

http://www.harting-usa.com/news/news/press-releases/washington-post_10875/

So I doubt it will be too long before NMEA feels comfortable with this as the non-proprietary fast OneNet standard connector.

Posted by: Ben in reply to Rick R at December 9, 2013 10:42 PM | Reply

Both these types of connectors are standard solution for industrial Ethernet applications, while "sealed RJ45" (as well as USB in the same cylindrical casing) is just something lame - it's too easy to brake the socket or to make socket and plug unusable with just a piece of dirt or debris. And M12 industrial connectors are twice smaller.
Just look at this: http://www.heilind.com/marketing/images/products/Omron_xs5.gif

If someone wants to use RJ45 - adapters are already available on market.

Personally, I'd use even smaller, M8 version of these connectors in case if there was no existing infrastructure. I was using it in my GPS measurement projects and got 100% satisfaction unlike with consumer-type RJ45 and USB.

Posted by: Bushman at December 10, 2013 12:02 AM | Reply

Having worked with the nmea-2000 connectors, those D and X coded connector choices look terrific, except I don't see how you can have a ethernet hub that easily supports devices at different speeds if physically they can't share the same connector as does RJ45 supporting 10,100, or 1000.

Posted by: Dan Corcoran (b393capt) at December 10, 2013 12:08 AM | Reply

Hopefully, they will stick to existing standards for the physical, data link and network layers of the stack (with the exception of the more robust connector). Compatibility with existing silicon and existing network stacks would make it vastly easier for new companies to get to market. If a vendor could take an existing 16-port GigE switch, give it a waterproof case and M12 connectors, and have it work out of the box, that would be great.

I am glad to see that IPv4 will be omitted; allowing it would only invite legacy cruft that will lead to expensive clean-up in a few years.

I would have hoped for a single connector for all speeds; X-M12 does look like a good choice and the cable vendors will follow where the committee leads. Part of the beauty of Ethernet is that any cable will work with any device, the higher speeds being auto-negotiated if both devices support it and if the signal integrity is good enough. (I have, in testing, pulled 1Gbps over short runs of ancient Cat5.) I would not object at all if D-M12 is poorly adopted and quietly dies out once X-M12 becomes readily available.

Posted by: Matt Marsh at December 10, 2013 7:35 AM | Reply

"Hopefully, they will stick to existing standards for the physical, data link and network layers of the stack (with the exception of the more robust connector)."

I believe that's the goal, Matt, and that the D-coded M12 is considered a standard (even if lots of boaters like me haven't ever seen it). X-M12 seems on its way to becoming a standard for industrial Ethernet.

Dan, if you Google "M12 switch" you'll see that there are lots available, most quite heavy duty looking and probably quite expensive. But also note that the OneNet presentation shows an M12-to-RJ45 adapter cable (above) and a proposed Ethernet switch that uses RJ45. So I think future OneNet vessels will be able to go either way, depending on duty level.

Actually, that's similar to how it is now, with some boats using conventional Ethernet switches in dry locations and others using better-protected manufacturer-specific switches. With OneNet I think both light and heavy duty options will get some marine standards and should work across brands.

Posted by: Ben at December 10, 2013 8:40 AM | Reply

Ben, I have to call out on the connectors. While I agree, a super cool connector is a good idea at the radome, it is unneeded and unwarranted for many applications inside the boat. Expense of fancy connectors may be a problem for some, but the issue runs deeper for a professional installation.

1. Size. 15mm OD for a 5mm cable? Running pre-terminated cables in many instances can be time consuming or impossible = adding cost for the customer and / or sub-optimal cable routing.

2. Field termination. A clean, well organized and mechanically efficient installation requires the the option for the installer to terminate cables to length. Prefab cables fall into the "one size fits most" category, not "all". As we have seen with N2k, the prefab cable scheme makes it easy for anyone to make connections, but it also leads to some really bad decisions where to put those connections... your cable not long enough, just put an extension on it. Often, those cable unions are buried in wire looms through the (wet) belly of the boat. In the case of N2k, we have also seen many Ts and manifolds (with unprotected unused ports) buried in the boat.

3. Metal to metal connector housings are a problem waiting to happen. Nickle plated male to female threaded connectors will be a blob of green crud in years to come. The contacts inside may be in good condition, but you will never see them with the outer shells rotted together.

4. Connector depth is very often a problem when mounting a piece of equipment. M12 connectors and the industrial strain boots they come with make for a very big bend radius from the back of the equipment.

5. Are RJ45s bad? Really? I find it ridiculous to orphan a connector that has served so many so well. Spears are thrown, but countless industrial applications use RJ45s. Sure, you need to keep it dry etc. In a wet and / or high vibration environment (e.g. at your radome), use a better connector! In the field, we need flexibility - like terminating a Cat5 cable at a MFD to length by installing a RJ45, probably with some sort of housing or pass through gland on the equipment to offer some protection.

6. Adapter cables - just what we need, more points of failure. My 30 years in marine electronics supports findings from others: that 80% of on-board failures are connection related. The equipment is really quite reliable.

I applaud Steve and the working group for moving onenet along, but I would urge focus on the stuff that brings the most value to our industry. I also encourage the working group to get the old tool bag out and participate from start to finish with a refit of an average 40'er (40' being a median popular size boat). I say refit, because it is harder to do an install around existing infrastructure (new construction is typically easier) and more refits are done annually than new boats are built.

Posted by: Eric at December 10, 2013 10:50 AM | Reply

just standardize on the faster connector unless there is a risk only the marine industry will use it.

Posted by: rob in reply to Matt Marsh at December 10, 2013 11:04 AM | Reply

Matt wrote "just standardize on the faster connector"

That sounds like a good solution. If that was the direction we could also "stay ahead of the curve" with a choice to use the faster rated cable in our boats with the slower devices. Then in the future, if there was a version of a device, we could re-use the same wire we carefully ran through our conduits for the slower device.

Posted by: Dan Corcoran (b393capt) in reply to rob at December 10, 2013 3:19 PM | Reply

In regards to the proposed OneNet Device Web Page Interface .. it would be far better if it was designed to be used with a smaller width smartphone from the start.

I see a future where all our marine software is on tablets and smartphones. When one of our smartphones reaches replacement age, we re-purpose them for use on our boats sans cellular subscription, to configure and maybe even monitor our marine electronics.

Posted by: Dan Corcoran (b393capt) at December 10, 2013 3:24 PM | Reply

I would agree with Matt to stay with just one connector. However the discussion is suggesting OneNet functionally replacing the territory of NMEA-2000 today. Steve's pitch focused so much on IPv6 .(which is a good thing) however I would have liked more on a typical vessel system architecture combining NMEA-2000 and OneNet.

Maybe a typical OneNet implementation will see a single NMEA-2000 to OneNet bridge for the bi-directional traffic accompanied with a standard Router/WLAN/3G (9-32 VDC) device to do the IoT deal. I imagine that IP cameras and other IoT devices will simply hook up to the router. MFD's wanting access to such devices simply connect to the router (OneNet not required here).

I can not imagine OneNet connecting to any of the low bandwidth product that NMEA-2000 services very well today.

Maybe my take on this not quite right and I'm missing something. I am hopeful that NMEA can provide some real world implementation examples so that our feedback can be better directed. My apology if they already exist and I just haven't found them.

Posted by: outbackgary in reply to rob at December 10, 2013 4:20 PM | Reply

No problem, Eric, but I think you're seeing this more black and white than it really is. For instance, if you search around the M12 connector sites you'll find that there are field-attachable models and there are also non-metal models (though I'll add that my boat has lots of metal-to-metal N2K connections that only show surface tarnishing after years of use).

Besides, it seems clear that installers who want to use RJ45 for large portions of a OneNet install will be able to. The real question is what connector(s) is standard on certified OneNet devices. I favor the M12 type and tend to agree with Matt that settling on the high speed x-coded design might be the way to go.

But please remember that all I know is what I think I heard in a one hour presentation. For instance, maybe OneNet will have more flexible connector standards for devices like gateways and switches that are typically install in well protected locations.

At any rate, imagine the day when one radar cable might last a boat's lifetime, regardless of changes in radar hardware and brand. It seems hard to argue that at least the exposed device connector standard should be anything less than the best, especially when you gave us this memorable quote:

"My 30 years in marine electronics supports findings from others: that 80% of on-board failures are connection related."

Posted by: Ben in reply to Eric at December 10, 2013 4:30 PM | Reply

"the discussion is suggesting OneNet functionally replacing the territory of NMEA-2000 today"

I'm not sure where you're seeing that in the discussion, Outback, and it's certainly not NMEA's intent. Gateways from regular NMEA 2000 networks to OneNet are an essential concept. There's an overall system diagram in Steve's presentation that's also at the bottom of my first OneNet entry:

http://www.panbo.com/archives/2012/08/onenet_nmea_finally_creates_a_marine_ethernet_standard.html

You'll see not only N2K to OneNet Gateways but also NMEA 0183 to OneNet Gateways. One thing I learned in San Diego is that this diagram dates back to 1994! In other words, a standard multi-manufacturer way to integrate NMEA 2000 and Ethernet/IP has been on the burner for a long time.

Posted by: Ben in reply to outbackgary at December 10, 2013 4:48 PM | Reply

As a former Naval Architect for 10+ years, and now a network consulting engineer with Cisco Systems, let me begin by saying these comments are my own and don't represent any company I work for or have worked for.

I personally think the use of modern networking technologies on boats is one large step in the right direction. The IoE is only going to grow everyday, and boats will need to stay connected to stay relevant. The advent of Apps to control marine electronics, and the use of networks to interconnect devices (NMEA 2000 or Ethernet) is a step in the right direction.

My opinion is that some of the technologies seem to be years old and way more expensive. Looking deeply, I believe companies use actual "hubs" on Ethernet networks, or at best unmanaged switches.

I echo the thoughts of people on here about keeping the physical, data-link, and network layers based on standards. I think the use of industrial grade equipment (M14 switch) only increases expense and cost in many ways that could be solved by other techniques.

The beauty of the modern intelligent network is its redundancy and self healing. With things like Etherchannel, link failure detection techniques, and even spanning tree ... you could have a network that heals itself when a cable is cut or link goes down. VLANs, QoS, and even Multicasting will allow data to get from the right source to the right destination on the network without effecting other traffic. As more advanced technologies, such as SDN and even FabricPath/TRILL filter down in the coming years, an even greater controllable and healing network can emerge.

I think RJ45 connectors are fine (add the rubber cap around if you must) with cables from CAT 5, to 5e, to 6, to 6A, and even to 7 and 7A, especially if used as STP (Shielded Twisted Pair), should move data around fine, and cost $10 or less per cable (Amazon current prices), allowing one to buy and build redundant interconnections at low cost. I even think the ever lowering costs on multimode SFP fiber is as cheap or cheaper than some of the 30m $150 proprietary networking cables used today.

My biggest issue, is the expansion of 802.11 wireless wifi on the boat. In the most simple understanding, there is really only 3 frequency spectrums. In some sense, if you have more than 3 wireless networks onboard (MFDs, access points, etc.) you most likely have wireless interference (lets not even talk about at the dock). If we move to a fully redundant wired architecture, one single access point could give access to every piece of data (internet, MFDs, monitoring, etc.) from tablet, phone, etc. (no more switching networks)

Wired redundant networks are also more secure and could ultimately give rise virtualization onboard, with devices that could instantaneously recover from errors, segment processes (i.e. NMEA 2000 engine monitoring on an different and segmented process than navigation), etc.

I think modern networking can solve every problem thrown at it by the boating community and more, so there is very little reason to re-invent, typically with old technologies, network devices (switches, routers, cables) simply to use in the marine network. Invest in making the MFD, Radar, GPS, or transducer better, not the cables / network to connect them.

Finally, with modern PoE standards, much like NMEA2000, I can power most of your devices and don't even run into some of the CANBUS architecture issues.

Posted by: Matthew Sunderland at December 10, 2013 4:48 PM | Reply

Thanks for the link Ben - if I recall the diagram is the same as what Steve used at his MET's presentation.

The diagram prompts the question as to what the difference is between a "OneNet" switch and a standard Ethernet switch? As I understand it there isn't any difference unless the OneNet switch is simply a standard switch with OneNet physical connectors. Some clarification on this would be helpful.

If that were the case, then the only real OneNet item in the diagram is the OneNet to NMEA-2000 gateway. So where in the diagram/OneNet architecture are the OneNet devices scattered around the vessel in harsh environments? Which is why I was making a point on "the discussion is suggesting OneNet functionally replacing the territory of NMEA-2000 today".

If the Switch is just that, then why wouldn't a standard switch with RJ45 connectors work great. If NMEA want to create a waterproof/harsh environment switch then fine. Just don't force us to use it when we are mounting the switch in a weatherproof environment.

If there is the occasional OneNet device that needs to be located in a harsh area, then the M12 connector sounds a good compromise for a reasonably compact solution that is still field connectable. Just don't force it on us where RJ45 already does a good job.

And to clarify, the NMEA-0183 to OneNet gateway has no need to exist if it is already catered for as an existing NMEA-2000 gateway device.

So for me the real question is what makes a OneNet switch OneNet and maybe NMEA can update the 9 year old diagram.

Posted by: outbackgary in reply to Ben at December 10, 2013 6:20 PM | Reply

Gary, the slide for the proposed OneNet Ethernet Switch states that it will be Layer 2 Managed and that it will support 15W or 30W Power over Ethernet (PoE) with the IEEE standards for each referenced. Like so much else of OneNet it appears to be a specific subset of existing Ethernet standards.

The 19-year-old diagram does show numerous OneNet devices but was apparently created with a ship in mind. So the devices are Integrated Bridge System, VDR, Monitoring System, AIS, etc. On a contemporary boat I believe the OneNet devices would be all the critical modules that now use proprietary Ethernet -- like MFDs, radar scanners, and black box sonars -- plus PoE nav and security cameras, and the like.

The diagram also shows a firewalled link to "Administrative Networks." In the recreational world I think that means possibly less secure systems on and off the boat. Security is a high priority, and apparently another reason for using IPv6, but so is connectivity with apps and so forth.

Posted by: Ben in reply to outbackgary at December 10, 2013 6:54 PM | Reply

Some arguments against M12 connectors could be easily eliminated just by reading the specifications and blueprints.
- there are M12 connectors with full-plastic and stainless steel housing instead of chrome-plated one mentioned above;
- typical outer diameter of IP67 M12 connector with plastic housing is 20mm while outer circle for bare RJ45 plug is 15mm (bare receptacle is 17-20mm);
- typical IP67 RJ45 compatible connector has 33mm outer diameter;
- there are, at least, d-coded connectors for no-soldering termination (with screws) and there are no obstacles for making crimped connectors if there will be significant demand.

Posted by: Bushman at December 10, 2013 7:41 PM | Reply

Thanks for the clarification Ben. That sounds like existing Ethernet Switches could meet the proposed specification except for the connector?

It is probable then that early OneNet systems could simply employ a NMEA-2000 gateway device and a specific off the shelf switch? This would immediately satisfy what I think most readers want in a system that provides open TCP/IP connectivity - and then we will see some worthwhile development I'm sure in iOS and Android apps as a certified gateway should effecively open up the development effort.

I can imagine the challenge faced with the "big four" working out a common standard for MFD/Radar/Sounder connections. I'm sure it will be worth the wait but it would be really nice if they could get the NMEA-2000 Gateway sorted out earlier.

Posted by: outbackgary in reply to Ben at December 10, 2013 8:15 PM | Reply

At least in the first years, the majority of OneNet devices will not need bandwidth above 100 Mbits so will use the standardised D-coded M12 connector. For the few devices that do need higher bandwidth, the X-coded M12 does offer that option. Forcing every device to use the X-coded M12 will noticeably increase device cost so having two connectors will help reduce cost - which is normally a focus point in the marine industry.

An installer will only need to stock two types of M12 to RJ45 cable. That doesn't sound onerous.

OneNet switches can have either the M12 or RJ45 connectors on them - typically for switches in secure locations they will use RJ45 connectors. Any standard off-the-shelf Ethernet switch that meets the OneNet protocol and PoE requirements can be certified as a OneNet switch.

The intelligent, bi-directional NMEA 2000 to OneNet Gateway will probably be the first product to market - allowing OneNet to explode forward with a wide range and depth of data from day one.

Posted by: Andy Campbell at December 11, 2013 5:17 AM | Reply

I have no issue with there being two different connectors. Andy is right, D-coded M12 is expensive enough; there's no point in using an X-coded M12 if it's not needed. I expect most installers will opt to pull cable factory terminated with an M12 on one end and then crimp a standard RJ-45 on the other and use a COTS switch. I know I would.

I hope to see a standard like this adopted by every device on a boat from the speedo transducer all the way up to big glass bridge displays. Single cable install and PoE for every device.[1] Use it for lighting too! Addressable LED lighting that can be controlled from your smartphone and is dimmable and maybe multicolored too (if that's your thing). But here ends my enthusiasm.

Unfortunately, it looks like this will just be proprietary N2K messages encapsulated in IP packets. And therein lies the rub. No access for the hobbyist or open source worlds. Locking out the very people who made the Internet what it is, who could unlock the true potential of OneNet. I am not a member of NMEA, but I could be. Financially it's not out of reach for me, although I think the price for the standards is a bit high. I am not a member of NMEA because of the NDA. It is stupidly restrictive. A business model for another age. You might argue that NMEA couldn't exist without the revenue from selling copies of these standards. I will point you to the Internet Engineering Task Force (IETF)[2] and the Modbus Organization[3]. They seem to manage without NDAs and standards locked behind a paywall.

That said, I am not opposed to paying a reasonable sum for a copy of the standards, I am opposed to not being able to publish the source code to software which implements a full N2K stack and which correctly interprets all the NMEA 2000 PGNs.

What the industry needs is an NMEA who can embrace open source and openly available standards. There is nothing open about information which can only be shared and discussed by a select group (even if membership in that group is open).

[1] If you're concerned about standby current consumption, interfacing with the network switch to tell it to shut down a particular devices port should not be very difficult.
[2] http://www.ietf.org/
[3] http://www.modbus.org/

Posted by: tim in reply to Andy Campbell at December 11, 2013 11:47 AM | Reply

You're right, the NMEA would not exist if it was not for the companies and individuals joining the NMEA and purchasing the NMEA documents. They depend on that income to survive and it would be a poorer world without the NMEA that's for sure.

Unfortunately I cannot see a way to marry your acceptance of paying for the NMEA 2000 documentation and your desire to release open-source software that is in essence the distilled contents of that documentation. Once that software is released, the need to purchase the documentation disappears, the NMEA no longer has its vital revenue stream and the NMEA goes bankrupt.

Someone always has to pay to create a new standard, and that cost is normally born by manufacturers and a 'governing body'. If the resulting standard's documentation is freely distributed then you have to accept that the 'governing body' is being financed in some other way: directly by the manufacturers or some other method.

Comparing the 'R & D' budgets of marine electronic manufacturer's with that of giants such as Cisco and Microsoft that create Ethernet standards is not constructive in my eyes. Both of those giants can easily afford to spend millions of dollars on the engineering time required to create those standards without even noticing it, whereas such a drain would bankrupt most marine electronic manufacturers. Furthermore, the volume of product sales in the consumer and marine markets is vastly different so the cost of that standard per product is also vastly different.

If anyone has an alternative method for everyone who benefits from the NMEA's standards to help pay to keep them operating, I think we would all listen. Alas, the only workable one I can see is for manufacturer's to pay more per year/per product and pass that cost on in their products to the end customer. Personally, I don't think that would be acceptable to most end customers but perhaps I'm wrong.

Posted by: Andy Campbell at December 11, 2013 12:30 PM | Reply

For some perspective, compared to automotive and IT products the marine market is like a drop of water, if not a few grains of sand in a bucket. Yet the hardware and software engineering overhead to develop a marine product is the same or somewhat higher given the harsh mechanical and electrical environment. Do those not involved in product development and manufacturing truly understand the exceptional value of today's marine electronic products, yet alone the challenge of bringing any product to market?

Maybe a small NMEA licensing fee attached to each certified NMEA product sold could supplement the existing fee structure? But for this to be effective, the sales volume of NMEA certified products would need to dramatically increase.

Can the hobbyist and commercial developers have free and open access to the internet side of certified OneNet gateway products? Is so, the increased demand for other certified NMEA-2000 products would drive prices down and drive a significant NMEA revenue stream.

Surely NMEA intend open application development without certification on the internet side of the gateway as a means of driving demand of product on the closed or secure side? I would think that a significant part of the Gateway product development is to come up with an API protocol that gives the Gateway manufacturer his competitive edge. The certification would look after the security side of things.

Might someone in the know clarify how the Gateway is supposed to work from both a manufacturer and user perspective?

Posted by: outbackgary in reply to Andy Campbell at December 11, 2013 4:30 PM | Reply

I think the understanding of what a OneNet Gateway is and what a OneNet device is needs to be cleared up.

An NMEA 2000 Gateway is a requirement for a PC software program to physically interface to an NMEA 2000 network and receive data from it. A PC does not come out-of-the-box with an isolated CAN bus port already on it so the NMEA 2000 Gateway creates that physical port. It does far more than that as it acts as a firewall and protocol interface too, but for the purpose of this comparison it is just a physical interface.

A OneNet Gateway is required to share data between an NMEA 2000 (Can bus) network and a OneNet (Ethernet) network - it is a physical protocol converter. Again, in reality it is far more complicated that that would suggest, but in essence that is its only job. A PC -does- come out-of-the-box with the required Ethernet interface necessary to connect to a OneNet network - there is no need for a physical gateway to create this interface.

A PC connected to a OneNet network is -NOT- a OneNet device - instead, the software application running on the PC is the OneNet device. That's a big point to understand. Therefore the software application operates exactly the same as a hardware OneNet product and so it is tested and certified in exactly the same way - there is no difference between the two.

Posted by: Andy Campbell in reply to outbackgary at December 12, 2013 6:28 AM | Reply

IPv6 actually does make sense. Even though there are a lot of added functions, and much much larger address space, the core protocol is more simple and flexible than IPv4. Thus it is easier to implement (although certainly there are a number of tried and true IPv4 implementation).
Some of the functions, like autoconfiguration, makes it easy and robust to build and operate local nets, without much supervision or manual configuration.
QoS functions, while not used very much on the Internet, are useful in local net, where traffic priority and bandwidth management is needed.

Posted by: szigi at December 13, 2013 4:39 AM | Reply

Maybe Andy could take the clarification one step further:

  • Is it feasible that a manufacturer of a certified NMEA-2000 to OneNet gateway could source a certified API that would then provide a simplified protocol for bidirectional communication with NMEA-2000 devices?

  • Could API's be provisioned for various target platforms like Windows, Linux, iOS, and Android?

  • Or is their an alternative way to give the OneNet gateway that capability and skip the target specific API's?

The objective would be to let entrepreneurial individuals have secure and safe access to the NMEA-2000 and OneNet devices on a vessel without the barrier of NMEA certification. Application development could then focus on the Internet of Boat Things. As said in a previous post, the most likely result would be for a sharp increase in demand for NMEA sensors and the like.

I can imagine hundreds of technically savvy individuals taking an interest in developing some real world applications. Surely this would be good initiative for NMEA, manufacturers and boat owners?

Posted by: outbackgary at December 13, 2013 3:34 PM | Reply

Commenting on last year's onenet article I used "mandated support for IPsec" as a pro-IPv6 argument but later realised that that argument was a bit bogus: If the NMEA control the whole stack they can just mandate that NMEA certified IPv4 stacks implement IPsec (as well as the supported crypto algorithms): Windows, Linux, MacOS etc have supported IPsec with IPv4 for years. I agree that IPv6 is the way to go, but what are the the security advantages Ben refers to the NMEA claiming for it, and if IPsec is to be used for authentication and/or encryption (as might be inferred from the onenet presentation slides) are there any details on the key management scheme or other meat required to leverage the IPsec framework? I still haven't seen any clues to a working scheme to ensure that the cruise liner's GPS data is from the unit it's supposed to be from rather than Mallory's laptop

Posted by: Keith at December 15, 2013 3:37 PM | Reply

Matthew,

I think you have it exactly right.

Onenet appears to be nmea trying to get a proprietary shoe wedged into the already existing open standard, maybe in order to stay relevant in these days of tablets, apps and networks that can already do all of it for a lot less cost.

Cheers

Posted by: Anonymous in reply to Matthew Sunderland at December 16, 2013 3:59 PM | Reply

Well done, anonymous! Sorry to be snide, but I think you missed the goals of OneNet completely.

If you went aboard most any medium size vessel today you'll probably find a completely proprietary Ethernet navigation network. That includes the connectors since there is no marine standard for waterproof Ethernet cabling. If you want to change a boat's primary nav system from one brand to another, you'll have to replace the cabling or frig around with splicing. OneNet's goal of standardizing on one or two of the already standard industrial Ethernet connectors and cable types (with provisions to use familiar RJ45 where appropriate) will help with this.

But even on OneNet, many specific navigation tools like radar will remain proprietary to same brand displays on the network. The manufacturers, not NMEA, are in control of that situation (and we all might do the same thing if we were in their shoes). OneNet does plan to select existing non-marine standards for devices like IP cameras (which will be good for boaters), and it may encourage some company to offer, say, a radar that's available to charting software developers but only time will tell.

On some boats you will also find gateways that move open standard NMEA 2000 data to Ethernet (and WiFi), but there is no standard for how to do that so no one gateway works with all the charting, monitoring, and system configuration software that would like to see a boat's N2K data. OneNet will definitely change that situation.

In short, your idea of "these days of tablets, apps and networks that can already do all of it for a lot less cost" hardly applies to boat navigation at all. Plus your agreement with Matthew Sunderland has almost nothing to do with what he wrote!

Posted by: Ben in reply to Anonymous at December 16, 2013 5:21 PM | Reply

I'm sorry but all attempts at replacing NMEA 0183 is futile, it will do for the leisure market but for all serious commercial applications NMEA 0183.

Why does Offshore 100 million dollar MPVs/AHTSs/PSVs
with DP2 still employ the old 0183 standard over RS232/422?
Because unmultiplexed unit-to-unit end-to-end 232/422 is the only thing you can really count on 100% It works every time, it syncs and it's realtime, it's human readable which means you can find errors easy. There's one cable for each function which makes searching failures easy as a charm.

There is a reason why theses are sold by the thousands in the Scandanavian shipping industry:
http://www.sea-master.dk/cms-assets/documents/41579-959024.databufferuk.pdf

NMEA 2000 is a joke and any other subsequent attempts at creating a predescessor will also be a joke...

Use RS 232 and live happily ever after...

Posted by: PaRaDoX at December 17, 2013 3:45 PM | Reply

Paradox, you seem to ignore whole swathes of commercial applications already using NMEA 2000 , a simple search shows up several , http://www.marinplus.com/solutions/solutions-for-commercial-vessels

0813 is fine for simple stuff, but completely falls over for high end integrated instruments.

of course millions of CAN based cars.

Most high end leisure vessels actually have automation well in excess of whats available on commercial vessels, which are largely controlled by standards and regulatory bodies. Where high end integrated bridges are used the integration is generally proprietary and high end. hence 0183 plays no part either.

-----break----

The interesting question here is whether IP will bypass NMEA 2K and go direct to the sensors. I suspect over time , we may see IP networks rather then CAN net works at the sensor level.

Posted by: madscientist in reply to PaRaDoX at December 18, 2013 12:29 PM | Reply

Actually, we don't have to wait long, because TCP serial server currently could be built-in into the RJ45 connector. Just look at Lantronix XPort, for example.

Posted by: Bushman in reply to madscientist at December 19, 2013 11:16 PM | Reply

But, Bushman, what's the point when there is still no standard way to package NMEA 2000 data over IP?

Regarding the "whether IP will bypass NMEA 2K and go direct to the sensors" question, why has this happened so infrequently to date? It makes obvious sense to use Ethernet between radar scanners and MFDs and every manufacturer has already done that with at least some of their scanners. But none I know of use Ethernet even from fishfinder transducers to their MFDs or black boxes, let alone from wind ducers and the like. They all had the freedom and ability to make such connections. Why didn't they?

Posted by: Ben in reply to Bushman at December 20, 2013 9:43 AM | Reply

Garmin radar uses RJ45 connectors behind a waterproof boot. Mine has worked fine for years. For the recreational and light commercial market that is adequate, but there is nothing wrong with having better connectors available for applications that require them. It is kind of interesting to see the industry trying to leapfrog existing technology; IPV6 and >100mbps are definitely overkill for anything that I imagine being part of a yacht's navigation system.

I think that this is a good (although belated) step in the right direction. I hear that there is this thing called "wi-fi" that might be interesting also.... :)

Going to real ethernet brings a lot of new possibilities. I am having trouble with my VHF antennas due to the fairly long runs and some failing joins. As I tear my hair out over this issue, I wonder why I can't have a VHF/AIS receiver built into the antenna or in a box on the radar arch, with an ethernet connection down to the "radio" box in the pilothouse.

Posted by: George at December 20, 2013 10:45 AM | Reply

Hi George,

If you Google "Garmin radar cable problems" you'll find out that not everyone has the experience you have, and that includes a friend of mine who couldn't figure what was wrong until a visiting Garmin tech found a connector issue where the cable met his radome.

And why settle for 'adequate' anyway, especially when we have deeply experienced pros like Eric Steinberg reporting that "80% of on-board failures are connection related"?

Here's an interesting discovery. A 40 foot Garmin Ethernet cable costs $55

http://www.wmjmarine.com/c16790.html

While a standard waterproof 10 meter D-Coded M-12 extreme environment Ethernet cable with gold plated copper alloy contacts and other nice specs cost $46:

http://www.productsforautomation.com/mencom-ethernet-cordset-4pole-male-straight-10m-mde45p4mp10m.aspx

I believe the latter meets the proposed OneNet standard for

This sure looks like a good marine Ethernet cabling standard to me, and let's hope that the x-Coded super high speed stuff can get close to this affordability. But let's also remember that even if the cabling is more expensive it's quite possible that it will last the life of a boat, like NMEA 2000 cabling and unlike all the proprietary stuff.

Posted by: Ben in reply to George at December 20, 2013 12:05 PM | Reply

You can't replace CAN 422/485 with TCP/IP/Ethernet etc simply because it is not reliable for mission critical applications.

CANBus over RS 422/485 is realtime, TCP is flawed for any realtime application since it is constructed for packet handling, buffering, packet loss, packet re-retrieval etc.

If you have for example an inertial navigation system with fiberoptic Ring-Laser Gyros, Accelerometers etc placed in different parts of a nuclear submarine measuring 6DoF alterations of the Vessel and all this realtime data is sent to and processed by an Inertial navigation algorithm in central computer. If you would send these data over TCP you won't be able to perfectly sync the data fed into the MRU/IMU processor. Since you are down to relativistic accuracy where even the length of the cables matter and must be taken into account, TCP won't cut it.

Same goes for example a DP3 drilling rig in the Arctic where you have 3 DTG gyros, 3 wind sensors, 3 StarPack GCR-HGPSs etc all going into the Kongsberg/Navis DP-computer. You cannot have delays, you can't resend packages etc. Everything must be in perfect sync...

Posted by: PaRaDoX in reply to madscientist at December 20, 2013 1:37 PM | Reply

Paradox, even though CANbuss is "realtime", it's moving at 250 kBps, and you can't start a new data frame until the one now running is done - the same issue addressed by TCP's packetizing, retrys, etc. In other words, you can't push data through it faster than the basic system data rate minus overhead. But 100 MBps Ethernet using TCP, even with it's higher overhead would seem to be able to accomplish LOTS of retrys of a failed/lost frame/packet before a single frame on CANbuss has completed. If you can get 1 GBps rates, the ability of ethernet would seem so far ahead of the 250 kBps CANBuss they can't be compared?

It's certainly true that the buss transceivers for TCP have to be smarter than the CANBuss ones - but it strikes me this tech is available - and cheap.

In the exotic situations you describe, I can see that you might need some specialized networking solutions - but somehow I don't see that as being a realistic problem for 99.99% of marine users. And I bet those setups aren't running 38 KBps NMEA0183, either..:-)

Posted by: Hartley in reply to PaRaDoX at December 20, 2013 7:27 PM | Reply

I'm not an industry expert, just an engineer, so I can't speak for those people who make decisions regarding standards etc. But I can tell about a couple of situations:
- in automotive industry, CAN buses rule the world and everybody like it, except third-party hardware makers, who needs to reverse protocols just to be able to read fuel consumption, for example;
- in geodetic hardware industry, we had these proprietary radio modems connecting base stations and rovers, but now it's gone, because it's easier to transmit NTRIP, RTCM and stuff over the conventional TCP protocol. No kidding - even regular teenager can tie up a bunch of Ethernet-enabled serial IO devices to some hub device (say, geodetic RTK rover or some hypothetic MFD) in case all these devices are speaking in the same serial "language".

Lower levels (from CAT5 or WiFi to TCP) of OSI model are supported by tons of certified hardware. Using that is bad only for those vendors who making their profit from selling ten cents cables for fifty bucks. And if we have something wrapped in TCP protocol, it could be routed in any way you need and like, from Ethernet CAT5 cable to those wonderful ZigBee or Class 1 Bluetooth transmitters.

Then, we are speaking just about upper level protocols and good will of vendors and makers of standards. I'll say it again - I'm not a businessman, so it's not easy for me to see financial or political effects this technology.

Speaking of realtime applications - in case of TCP, it depends on lower levels bandwidth redundancy. And, finally, we are not talking about Tomahawk missile autopilot. I do remember the famous "640 kBytes should be enough" phrase, but until marine vessels are not flying over the water at 300 mph, 1000Base-TX will be enough for that. Then, if it will not be enough, it's easy to switch to optic cables.

That's easy to count - for example, RAW readings from GPS receiver, suitable for RTK phase differential measurements are filling the 115200 bps bandwidth when set to 10 Hz update rate. And it's just 14 kBytes/s while maximum bandwidth of GbitE is over 110000 kBytes/s (yes, Fast Ethernet has just 11000 kBytes). I see no problems for marine applications until you will not route your HDTV movies from onboard DLNA server with the same router.

Posted by: Bushman in reply to Ben at December 21, 2013 3:20 AM | Reply

And I'd like to follow that statement about connection problems. There is some good experiment anyone could reproduce: put "nmea 2000 tester" in Google image search, then do the same with "ethernet tester" and compare the results.

In terms of hardware connection debugging, any kind of Ethernet devices and cabling could be tested with thousands of tools, from simple testers with blinking LEDs to complex devices, showing you the content of packets. Isn't it useful to be able to know exact distance to short/break in cable, for example?

Posted by: Bushman at December 21, 2013 3:47 PM | Reply

Sorry, Bushman, hard to imagine what your 'experiment' proves. Do you realize that Ethernet networks outnumber NMEA 2000 networks by at least 100,000 to 1? Or that many MFDs and gateways can show you what N2K devices are working on your network and what data they're sending? They aren't called testers but they can be used that way.

The NMEA 2000 version of CANbus is appropriate to boats for the same reasons it's used on land vehicles. I'm not sure where you got the idea that third parties have to reverse engineer it because SAE J1939 is a open CAN car and truck standard quite like N2K and it includes fuel rate. Look at the "Features" tab at this site to sse a list of J1939 PGNs that can be converted to NMEA 2000 data on a boat:

http://www.maretron.com/products/j2k100.php

Incidentally, I installed a Maretron fuel flow system on Gizmo this fall and just about every brand display I'm testing can read the results. It seems amazingly accurate, and I'll be writing about it soon.

Posted by: Ben in reply to Bushman at December 21, 2013 6:08 PM | Reply

MFDs can show devices and data, but it does not show the distance to broken point on the cable. My "experiment" clearly shows that hardware troubleshooting for OpenNet will be much easier with all that tools of any kind.

CAN bus on vehicles is standardized, but any maker can add some proprietary messages or variations, and they do that sometimes.

Posted by: Bushman in reply to Ben at December 21, 2013 11:01 PM | Reply

Wow, nice debate. The future looks good. I don't understand why NMEA0183 is the bullet proof reliable standard? I have had great luck with NMEA2000, albeit with the exception of wind data going through an ST-70 converter (from an ST-60 headunit), a B&G unit won't pickup the data, seems to be an ST2 issue. Going to OneNet is a great step ahead... the rest of the world is there and the point that the marine market is tiny, really tiny, should be the first clue that it needs to use mainstream solutions or price itself out of existence. I fear folks will buy $10 apps for their iPads to replace good equipment (iRegattaPro vs. a B&G Zeus2), and connectivity on boats will become a thing of the past. I can't help but think price will drive all of this. Basic function come cheaply, particularly in areas volume can drive development (i.e. GPS, CANBUS derived sensors/system controls), then widely used marine functions (radar, AIS, radios), and finally professional applications where lower volumes and specific needs drive development. And no this isn't new... look at the widest marine application - depth sounders/sonar, cheap as dirt and innovation galore that everyone uses, compared to wind instruments... finally Garmin has introduced a wireless N2K unit, not ready until 2014 and basically N2K put on a 3 year old wireless unit... low demand, and high price... killers for wide spread adoption. Panbots, embrace IP/OneNet, it will save us all! The winner item will be a universal OneNet, N2K, NMEA0183 bridge/coverter unit, put it in your existing system and have full forwards/backwards compatibility for everything - much like our telephone system... the two wires in the house have gone from rotary phones to DSL without much fuss!

Posted by: Anonymous at December 22, 2013 10:07 AM | Reply

Several people have questioned use of TCP for real time data. Two comments. Firstly, has there been any mention of TCP as the only transport layer (or even *a* transport layer) and second, the press release from last year explicitly stated that Onenet would not entirely replace NMEA 2000 for exactly the real time reason. Anyone seen anything that changes that? Not being an nmea member I might well have missed info on that.

As with some of the comments from last year's article, I actually question whether data centre ethernet technologies (ie 802.1Qbb and pals) couldn't be leveraged to provide reliable lossless transmission, especially in conjunction with IPv6 flow lables at the network layer. That's the beauty of "owning" the whole stack :-). Also provides product differentiation for the marine electronics manufacturers: Leisure users can use ordinary commodity switches/routers but if you want something that does full onenet data prioritisation and bandwidth reservation it needs to be an NMEA certified product.

UDP or a custom transport layer on top of IPv6 over reliable lossless ethernet would presumably be a more viable time-critical data approach rather than TCP if they did decide to address that stuff in Onenet.

Running an N2K *and* a Onenet network for any reason other than legacy support seems a sub-optimal design.

Posted by: Keith at December 25, 2013 9:32 AM | Reply

To second Keith's comment ... Garmin's Proprietary networking is based on Ethernet and using UDP for most of the communications. UDP over a reliable local network clearly works great to display your Garmin Radar on your MFD.

On the topic of Openness ... The Auto's are already opening their CAN networks to developers and starting to put WiFi and other open networks into vehicles. Ford has a spreadsheet that lists all the OBDII (CAN) sentences in the vehicles. See https://developer.ford.com/pages/openxc and https://docs.google.com/a/salesforce.com/spreadsheet/ccc?key=0Ajz-75u_7nEydFJxUG4yOVZ1NXJlcjNvdzdSTDdyY0E#gid=0

GM is on a similar path. see: https://developer.gm.com/index.php and of course they are on the forefront of in-vehicle networking. Every GM vehicle will have 4G networking. http://media.gm.com/media/us/en/onstar/news.detail.html/content/Pages/news/us/en/2013/Feb/0225_4g-lte.html

Openness always wins. No matter how many smart members there are in NEMA there will always be many more smart people outside of NEMA. The IETF is a great example of a standards body which is not built on proprietary "standards" and the NEMA needs to figure out how to update their business model. Charging for testing and certification of standards compliance is a great model. This is the WiFi alliance model. There also is a model where you are a registrar of device IDs ...

Over time the winners are the people whom have built the biggest community. More users = More Ideas for product = more products sold. Getting people with great ideas the capability to try them out and share them is a way to get more users. Most marine manufactures are still scared of this business model as they can see a day when a standard android tablet replaces their $5000 MFD. The manufactures need to embrace openness and rely on the value of an IPX7 device which is purpose built for rugged use. Let the tinkers tinker and provide cutting edge ideas and then supply the masses with leading edge bullet proof technology.

Posted by: Pat McQueen at December 26, 2013 10:31 AM | Reply

Thanks, Pat, but I think you're confused...or maybe I'm confused by your comment.

First of all, it's "NMEA" not "NEMA" and the acronym stands for National Marine Electronics Association. NMEA's 0183, 2000, and OneNet are all open standards that can be used by any manufacturer. NMEA finances its standards making and maintenance processes by charging for documentation and certification.

So I don't understand why you think that NMEA needs a new business plan or a more 'open' attitude. In fact, I think that if you look closely you'll find that the NMEA standards model is a lot like what the SAE (Society of Automotive Engineers) does with their CANbus standards.

Actually, I think there's an argument that NMEA 2000 is functionally more 'open' than automobile CANbus systems. Remember that it's perfectly possible to build a closed system using open standards, and that's what most of us are driving on the road.

Your examples of the automobile industry "opening their CAN networks" looks like stuff that's been happening on boats for a while. For instance, now that my engine sensors are outputting NMEA 2000 every MFD on board can serve as gauges ( http://goo.gl/rKNegz ) and there is a world of third party devices and apps that can log my engine data and warn me early of problems.

The Ford and GM specific initiatives sound a whole lot like Navico's GoFree ( http://goo.gl/DV3Eof ), which makes all sorts of data and some control available to third party apps developers. Navico may make more MFDs than any other company and they don't seem scared about the day "when a standard android tablet replaces their $5000 MFD."

I don't see that day coming either. Nor the day when tablets will replace a car's dashboard. Integrate with, accessorize, abet...yes to all that, as is happening on boats...but not replace.

Finally, I think what Keith was saying is that TCP can be used for real time data the way CANbus is in vehicles and boats. He may be right but I think the real question is "why bother"?

Ethernet works great for high bandwidth applications like radar and every major manufacturer has adopted it. CANbus/N2K works great for lower bandwidth data and every major manufacturer has adopted it. Hence Ethernet and NMEA 2000 are working together on most every mid-size recreational vessel with up-to-date electronics, usually with the MFDs serving as the gateways.

The intent of OneNet is just to improve on what's already happening. Manufacturers will still be able to keep their radar proprietary if they want, but there will be a multi-manufacturer standard for cabling, video, and gatewaying N2K messages into TCP. Which should be like GoFree on steroids. Maybe the SAE is working on a similar way to make third-party app development for cars easier ;-)

Posted by: Ben in reply to Pat McQueen at December 26, 2013 5:33 PM | Reply

No I'm not suggesting TCP is a good choice for real time data. As others have said: it isn't. With apologies and not wishing to teach anyone to suck eggs but recognizing that this is a marine electronics site some of whose readers may be more familiar with traditional marine data comms than computer networking...TCP is is a protocol which sits on top of IP in the network stack to provide reliable lossless delivery. It is not the only transport protocol commonly sitting on top of IP. Radar and sonar data for example are often transmitted over (multicast) UDP which is just a simple container without all the retransmission and bandwidth throttling overhead of TCP. You'll also see multicast UDP cropping up in IEC 61162 and it is what is used for GoFree service announcements (although the subsequent GoFree NMEA-0183 connections are then over TCP).

The recent NMEA OneNet publicly-released presentation has made a big deal over the network layer being IPv6, but I haven't seen any detail on what transport layers will be used and for what: obviously TCP for http access to the device information pages but what about NMEA-0183-over-IP delivery? Common apps using current ad-hoc non-standards for this over IPv4 are doing it either with TCP or with UDP broadcast. Broadcast is (thankfully) not present in IPv6 but (way more sensible) multicast is.

My previous post was suggesting that intelligent use of IPv6 flow lables (in the IPv6 header) working in conjunction with modern layer 2 (ethernet in this case) data center technologies for prioritisation and bandwidth reservation could compete with N2K for near-realtime deliver with an appropriate transport layer (Not TCP: that would be unnecessary and redundant overhead in the scenario I'm suggesting). This does not preclude use of TCP on the same network for less time-critical data delivery.

Why do everything on one cable? Running two cables and supporting two technologies seems a little wasteful in terms of cost and complexity. If you're running a second cable it would be better done (imho) for high availability/redundancy.

However, I still haven't seen details of what transport layers (ie the layer above IP) are being proposed and for what. Can anyone point me at anything with more meat than what has been shown so far?

Posted by: Keith at December 27, 2013 5:30 AM | Reply

As suggested as the obvious choice, NMEA OneNet will use UDP multicast for all data messages and TCP/IP for the device's webpage (to allow device configuration and display of device specific information).

Posted by: Andy Campbell at January 2, 2014 5:38 AM | Reply

I think the main reason that to date Ethernet has not been run to the sensors has been the lack of an agreed protocol. I don't believe there is any technical impediment. Its not a bouts as cheap and actually easier to embed ethernet into a embedded system then CAN, and ethernet opens up Wireless, whereas CAN has no dealt wireless equivalent.

Once we have an agreed protocol , I think well see the emergence of Ethernet over CAN, thats what has tended to happen in industrial equipment


Posted by: madscientist in reply to Ben at January 2, 2014 7:55 AM | Reply

"Finally, I think what Keith was saying is that TCP can be used for real time data the way CANbus is in vehicles and boats. He may be right but I think the real question is "why bother"

I think the answer is that (a) Its now easier to build ethernet connectivity at the embedded level, (b) The market understands Ethernet and TCP/IP and ( c) The part played by smartphone and tablets will grow and these are inherently TCP/IP devices

The real time issues is really bunkum for the most, most boats have "near real" time applications , not pure " real time" I don't believe we are seeing throttle or steering systems integrated in NMEA2K, and even so its easy to dedicated these systems to their own network segment anyway .

Posted by: madscientist at January 2, 2014 8:07 AM | Reply

I think NMEA with OneNet have grabbed the dog by a hair on its tail and are now trying to wag the dog...

For NMEA2000, CAN had vulnerabilities and the data on the network was predominately NMEA data with some proprietary stuff - so NMEA driving the network design made sense.

However, for the Ethernet network the situation is totally opposite - theres a large install base of existing proprietary marine data (radar,sonar and database synching

etc) and that new but not so little thing called the Internet + a tiny bit of NMEA2000 data in future.

So looking at it from this perspective are NMEA really the right organisation to be defining network hardware or network naming when their data only forms such a small (and diminishingly small) part of it?

Absolutely we need a standardized protocol for NMEA2000 data over ethernet and requiring IPv6 is a good move that will avoid future integration problems and encourage marine manufacturers to adopt IPv6 sooner rather than later.

As for the proposed connectors - NMEA should have a look at what connector types the major industry players are using for there own systems. Overwelmingly they prefer quarter-turn type connectors and for good reason:

- they are quick to connect/disconnect which is important for bracket mount products
- they give the user positive mechanical feedback about when the connector is properly engaged.
- have higher on/off connection count rating.
- they are less fiddly to connect - you can't cross-thread them.
- they don't bind up with salt or corrosion.
- are generally lower cost and work much better than plastic threaded equivalents.

So why-o-why do NMEA insist on promoting threaded connectors?

Rather than requiring a specific connector type + other HW bits (and making poor choices - again) would they be better of just issuing guidelines for creating a reliable network in a marine environment. e.g all hardware components need to meet EN60945 environmental requirements. ?

Please NMEA have a re-think...and just specify what is really needed to send NMEA data from many A's to many B's reliably.

Posted by: Anonymous at January 5, 2014 3:52 AM | Reply

Geez, anon, did you even glance at the first slide and paragraphs of this entry? OneNet is not being imposed on "major industry players" by some little entity called NMEA. OneNet is being created by all the major marine electronics manufacturers plus many smaller developers and interested third parties like the USCG, all under the auspices of their standards-making organization the NMEA.

And the only thing that will be truly unique about OneNet is how NMEA 2000 messages -- standard and/or proprietary, since both are supported by the protocol -- are gatewayed to IP. The goal is to select every other aspect of OneNet from existing Ethernet standards, which is probably why a quarter-turn connector has not been proposed.

Sorry, Anon, but your hair of the tail of the dog thing just doesn't make any sense.

Posted by: Ben in reply to Anonymous at January 5, 2014 9:20 AM | Reply

Apologies if I missed the answer to this somewhere in the article or comments but the important question is...OneNet may be ahead of the "curve" but how is it doing with the release schedule? 2012's press release promised a draft by the end of 2013, beta testing in 2014 and final standardization by the end of this year. Are we still on track?

I have doubts, based on (1) lack of awareness of reps from the major marine electronics companies staffing the stands at boat shows (Southampton 2013, London 2014) that OneNet even exists, let alone when we'll be seeing products supporting it and (2) The fact that the IPv6 decision must have been taken relatively recently (less than a year ago) which, whilst I applaud it for many reasons, is sure to present some challenges to marine electronics companies who only just seem to be finding their way with IPv4.

If the timescales have indeed slipped, is there a revised schedule?

Posted by: Keith at January 9, 2014 5:53 AM | Reply

Do we need NMEA 2000 binary data packets on ethernet? With the available ethernet bandwidth NMEA-0183/ IEC61162 ASCII readable messages would surely not cause any latency issues. The obvious advantage of the NMEA-0183 ASCII based protocol is that it is human readable, making testing and debuging a system much simpler. Also for the number of boat owners using open source software most of these are quite capable of decoding NMEA-0183 sentences so only a simple IP to virtual serial port driver would be required for these to operate.

We also already have an marine ethernet standard IEC 61162-450 Ed.1:
Maritime navigation and radiocommunication equipment and systems –
Digital interfaces – Part 450: Multiple talkers and multiple listeners – Ethernet interconnection.

As far as the cabling is concerned maybe it would be good to have a smaller M12 connector, the RJ45 water tight parts are quite bulky especially when fitted to the rear of a unit. Standard RJ45 connectors are ok in the office but no good in salt mist environments.

Posted by: David at January 9, 2014 1:33 PM | Reply

The volume of information available in NMEA 2000 PGNs is far, far bigger than what could ever be sent using NMEA 0183 sentences - and the gap is increasing all the time. The '450 protocol was primarily created to to help build an AIS network and is a stop gap until a more capable protocol is developed.

Using a diagnostic tool that can break down each individual field inside an NMEA 2000 PGN in to human readable values may help to remove some of your worries about debugging an NMEA 2000 network.

Posted by: Andy Campbell at January 10, 2014 4:27 AM | Reply

Hello Ben,
you are talking over nmea one net like we have a new century .....
you write only over "commercial" NMEA-institution , which does not become any open door in commercial market! Please lookup the standard IEC 61162-450 which is available since 2 years as official marine lightwidth ethernet standard for navigation data. it is more usefull for any body, no specific connectors or special telegrams which are not
readable for normal technican...

what the Nmea do is only, every 5 years new "standards" ( standards for the recreational market), that the sport boot industry can make better money.. and the NMEA too.

users! lookup the real standard , which are free
for ex. the specification of the IEC 61162-450 costs
250$ on the IEC and you can develop what ever you want without any licence fee!

regards
manny

Posted by: manny at January 11, 2014 7:12 PM | Reply

You're confused, Manny:

* NMEA does not charge license fees to developers or users of their open standards. They do finance the standard making process by charging for documentation like the IEC does.

* The OneNet standard is not competing with IEC 61162-450 Light Weight Ethernet (LWE). In fact, I think it could have been called Heavy Weight Ethernet.

* NMEA (and IMEA) work closely with the IEC, which is why IEC 61162-1, -2, and -3 are based on NMEA 0183, 0183HS, and 2000.

Marintek, the Norwegian research institution that seemed to play a big part in developing LWE for shipping, has a good explanation of all this here:

http://www.mits-forum.org/network.html

Posted by: Ben in reply to manny at January 12, 2014 1:21 AM | Reply

Sorry to push the point (to Andy, Ben or anyone party to the OneNet standards committee) but are the OneNet timescales unchanged from the last info we had? Was the draft indeed released at the end of 2013? Are we still on for full standardization by the end of 2014?

Posted by: Keith at January 14, 2014 10:15 AM | Reply

Keith, the "It won't be fully released for two more years" at the beginning of the entry came from notes I took during the NMEA presentation. I haven't seen it in print, but if true then anticipated OneNet delivery has slipped from the original "late 2014" to Q4 2015.

I'm not sure what you mean by a "draft release" as I imagine the committee has worked with numerous drafts and I've never seen anything about a public release.

Maybe someone has more information but I'm not sure I'd bank on any 'operational' date that far out and involving so many moving parts. I trust we'll know more in a year or so.

Posted by: Ben in reply to Keith at January 14, 2014 10:52 AM | Reply

Ben.

thanks for your reply. By "draft release" I meant the initial written release scheduled for 2013 referenced in press release which promoted your 2012 onenet article.
http://www.nmea.org/Assets/nmea%20introduces%20onenet.pdf
My understanding from the timeline cited there was that this would be the document that members would use to code their initial products which would be beta tested during the course of 2014, with any issues arising from that being used modify the standards document before a final "public" release at the end of 2014. This would be consistent with products available to end users hitting the shelves in 2015. One interpretation of "fully released" would be "products available". Another would be "Vendors given the green light to release products". I guess it's the latter.

Interesting times. IP-based products will be well entrenched in the market by 2016. It will be interesting to see whether the current closed protocol approach so incomprehensible to those with backgrounds in IP networking will be able to reclaim a niche in the leisure market

Posted by: Keith at January 14, 2014 4:10 PM | Reply

I see what you mean now, Keith. The plan in 2012 was:

Completion of the written standard by the end of 2013
Completion of beta testing by the end of 2014
Publication of the standard by the end of 2014

But, sorry, I don't know where steps 1 & 2 are at with #3 apparently pushed to late 2015.

Posted by: Ben at January 14, 2014 5:44 PM | Reply

Leave a comment