NMEA OneNet 2013, already ahead of the curve?
OneNet 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.
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.
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.
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.”
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)?
Of 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 Marine, zapfware, Navico, 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?
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.
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!”
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.
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.
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.
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.
“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.
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.
just standardize on the faster connector unless there is a risk only the marine industry will use it.
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.
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.
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.
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.”
“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:
https://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.
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.
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.
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.
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.
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.
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.
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/
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.
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?
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.
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.
Maybe Andy could take the clarification one step further:
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?
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
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
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!
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…
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.
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.
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?
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.
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
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…
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..:-)
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.
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?
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.
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.
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!
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.
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.
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 😉
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?
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).
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
“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 .
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.
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.
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?
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.
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.
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
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
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?
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.
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
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.
We’re now into Q4/2015 and I didn’t see even a mention of OneNet in Ben’s Baltimore write-up, nor in the timetable for the conference. Has the protocol’s physical layer been changed to tumbleweeds?
The NMEA and all the companies in the working group are working hard to complete the release version documentation by the end of 2015. The change to use IPv6 has significantly delayed its release but that was the correct decision for the long term success of OneNet.
The change to use IPV6 occurred a few years ago, so it was not a recent change.
Andy: That’s great news. Surprised there’s not more publicity around it. Any thoughts on when we might see the first products? From Actisense if no-one else? 🙂
Regarding anonymous’s comment…I mailed Steve Spitzer in January 2013 to ask about the network layer of OneNet as I agreed then with what Andy Campbell is saying: that IPv6 is the way to go. Steve replied that IPv4 was (then) OneNet’s network layer so the change (which I suspect cisco may have influenced) happened between then and the San Diego conference ater that year. The twin problems here are presumably lack of maturity of embedded IPv6 stacks (vs embedded IPv4 stacks) and a general lack of IPv6 skills in the marine electronics industry.
Ya, I would like to see some products; especially a Ethernet-2-N2K gateway.
I have 50+ NMEA 2K devices on my 80′ boat, 3 segments joined by 2 bridges, and a few hundred feet of cable spanning 3 levels, end-to-end.
Hi Keith, OneNet was definitely discussed in Baltimore during the big general meeting and I believe the working group met there for many hours.
Steve Spitzer described how the standard has been reorganized into modules with publishing of the Base, Core, and Physical modules due out by New Years. Planed to come in 2016 are the Security, Gateway, Network, and Advanced modules, as well as beta testing plus certification documentation and tool development.
At any rate, the goals of OneNet haven’t changed as best I can tell, and the schedule has long been vague, so I don’t see where there’s much news here.
PS: I recall that in early 2014, NMEA chairman Johnny Lindstrom announced in the MEJ that OneNet development would be slowed down a bit while they fixed some N2K issues. I believe that a lot of behind the scenes work has now been done on the latter, like a better certification tool, and now OneNet is back on pace.
A significant boost to OneNet could come from the commercial marine industry. However, OneNet will be competing with Modbus over Ethernet.
Modbus sensors have been available for years and cover temperature, voltage, current, frequency, fuel flow/consumption, tank levels, shaft RPM, etc. Their protocols are publically documented and open-source TCP/IP libraries to interface with these sensors are available.
Vendors such as Krill Systems (among others) provide vessel monitoring software thus completing the HW/SW package. Commercial boats such a the WA state ferries, BC Ferries, NOAA, offshore supply vessels, etc. are using Modbus; not N2K. Note is it difficult to find commercial boats with N2K networks.
Without timely OenNet products, the commercial industry will continue to adopt and standardize on Modbus.
Hi Anonymous #1 – as Anonymous #2 kindly said, the change to IPv6 was less than 2 years ago. Sadly almost all of the working group members already have a full-time job so that does limit the time that can be spent on anything else.
Hi Keith – yes, we have considerable experience with gateways, which is why we were asked to join the OneNet working group at the very beginning. We will be helping to drive OneNet from theory in to reality as soon as it is possible.
What makes the birth of OneNet totally different from that of NMEA 2000 is that a OneNet gateway (between NMEA 2000 and OneNet) will immediately create a wealth of data on Ethernet from the very beginning, overcoming the starting inertia.
Once OneNet is established, the marketplace will decide whether it can help to replace some uses of other solutions (such as Modbus). Note however that the ideas OneNet can encompass (e.g. video & infra red cameras, sonars, radars etc.) on top of NMEA 2000, are to my limited knowledge of Modbus (currently) outside its capabilities.
Andy’s got it right. Modbus (aka SCADA protocols) and OneNet are appropriate for their respective requirements / environments. I don’t see a lot of overlap. That said, they will be both be running atop IP. They could co-exist on a properly engineered network.
Reasons for OneNet delays? a) gosh golly a standards effort delay ? b) all of the above cited reasons and then some.
OneNet is progressing at the rate at which its been resourced (people, time, $$$) by its stakeholders.
Coming back to this thread, note that another 10 months have elapsed and there does not seem to be any OneNet products on the market.
Although multiple organizations have shipped new N2K sensors, displays, etc. none have shipped any OneNet products.
Does anyone know if any of the marine electronics manufactures have indicated they have plans to ship OneNet products in the next 12 months?
You have good timing Anonymous as I understand that the NMEA plans on releasing the OneNet standard after the working group meetings at the NMEA Conference this month.
There has been a huge effort over the past 12 months by the NMEA and the various OneNet module working groups to complete the standard, with virtual meetings happening every week for most of that period and at least 5 face-to-face meetings (to my knowledge).
A manufacturer cannot ‘ship’ OneNet product until the complete OneNet standard and more importantly its certification process is in place. As the standard should by all certainty be released this month, that will change soon.
I fear onenet is another example of a botched nmea standard like 2000 was.
They have missed the big players product refreshes e.g. Furuno NXT, Garmin Quantum, Raymarine Fantom.
Having the standard released before / during these product developments would have sped up its adoption by years do you think raymarine, garmin and Furuno will spend effort changing the interfacing of an already developed product.
if you lucky some basic onenet stuff next year, failing that id say 5 years minimum before full adoption.
Once again NMEAFail.com
(A different Anonymous)
Thanks for the update, Andy. I look forward to learning more at the NMEA Conference.
And hate to break it to you, anon2, but I’ve yet to hear any of big manufacturers complaining about the pace of OneNet. I have no idea how quickly it will be adopted and if what you’re hoping for is solid state radars like Garmin Fantom or Raymarine Quantum that can interface with other manufacturer’s software or hardware, that decision really has nothing to do with NMEA.
Good to see this thread come back to life.
I have been struggling with N2K for a while now. I have three network segments on my 80′ powerboat connected with 2 Maretron NBE100 bus extenders supporting > 50 N2K ‘boxes’ from various manufacturers.
I would like to add a few BEP Marine CZone output & switch control interfaces as well as another Maretron FPM100 tank level monitor and another Maretron J2K100 gateway. I am worried about running out power, etc. N2KBuilder tells me I am getting close to the edge.
I originally installed CAT 6A ethernet cable and POE switches at various locations. I would like to start installing new sensors, gateways and displays on OneNet.
My comment is the big brands have already started on new displays that will be the basis of products for the next 4 – 5 years, NMEA have missed the boat in the development cycle.
Geez, even fake names would work better than all these “Anonymous” comments apparently from different people.
What is OneNet intended to replace in today’s marine nav systems? Or is it in addition to the 0183, N2K, and proprietary ethernet we see in all systems today?
Is the vision for N2K to go away as an electrical interconnect?
Or is the vision to extend N2K to wifi and all the other existing IP devices in the world? And if it’s this, how does it relate to SignalK which seems to do the same thing, or to just sending PGNs over UDP as many people already do today in a compatible way?
I’m amused by the comments saying NMEA have missed the big brands releases. Who do you think sits on the OneNet committee? Representatives from most of the big brands. They know exactly what’s happening with OneNet because they’re the ones driving it.
The NMEA is looking for manufacturers willing to Beta test the draft OneNet Standard, all of which is laid out in this PDF:
http://www.nmea.org/Assets/20160928%20imea%20beta%20test%20package.pdf
I think that they are particularly hoping for fresh faces, by which I mean companies not among the many who helped to create the draft standard. (The last “anonymous” got the situation correct.)
Is OneNet turning into a failure?
During 2017 I was looking forward to seeing products launched starting to support this standard, now we find ourselves in 2018 and OneNet has been talked about since 2013.
Is it time to declare OneNet DOA?
How can OneNet be Dead On Arrival if it hasn’t arrived yet?
Seriously, while I too was vaguely hoping to see actual products last year, what does the lack of them of actually mean? I don’t know, and also didn’t get to the 2017 NMEA conference, but I have heard that the OneNet committee is still very much at work.
Hopefully someone more knowledgeable will speak up, but in the meantime here’s an intriquing 11/2016 quote from Rosepoint Navigation founder Brad Christian:
“At the moment, no standard way exists to transfer NMEA 2000 PGs over an Ethernet network. This is one of the primary goals of the NMEA’s upcoming OneNet standard which is just entering a beta testing period. Rose Point is actively involved in helping to define OneNet and I expect that the Nemo Gateway will be one of the first gateways to support the standard. When that happens, any software or device that supports OneNet will be able to receive all of the data from a NMEA 2000 network via the gateway.”
I think the issue is there are already standards in place, take IEC-61162-450, Asterix, SignalK
is OneNet really needed ?
I don’t think that any one person, company, or organization can decide that. I believe that OneNet will materialize eventually, but then it may well take years longer to really see how many marine electronics companies adopt it and also whether the benefits are distinct enough that consumers pay attention.
All these Anonymous posted questions.
To my limited knowledge, none of the stated “Standards” include security, which is fast becoming a vital part of any communication Standard in the marketplace.
The OneNet Beta group members have created OneNet devices to test the OneNet Beta standard. The feedback from this phase will help to create a proven release.
As Steve Spitzer mentions, the NMEA are the only Marine Standards body that believes in Beta testing their standards. All the others Standards are first tested after release when major changes are much harder to make.
It’s obvious that Anonymous is frustrated with the time scales, I think we all are, but getting it right is important.
NMEA has posted the OneNet presentation given at METS last November:
http://www.nmea.org/Assets/20171114%20mets%20trade%20onenet%20update.pptx
Another year has elapsed. Are there any OneNet products available?
It’s Q3 2020. The NMEA web site is saying OneNet is due for publication in Q1 2020. I’ve not seen any products based on draft specifications. No more mention of Actisense’s NOG-1 referenced in an old powerpoint on their website (“Estimated release 2014”). At boat shows (most recently Boot this year) I tend to ask on the major manufacturers’ stands if they have any upcoming OneNet products and am invariably met with blank stares. Where are we with this? Does anyone know of *any* OneNet products ready for release in the next year?
No, I don’t know of any OneNet products about to release, and, frankly, I’d be hesitant to mention one until it really did ship!
On the other hand, there seemed to plenty of OneNet development activity during the annual NMEA Conference last September, including a group working on a OneNet radar interface standard (that will be optional and probably not supported by the major recreational brands).
So I don’t think that OneNet is dead, but it sure blew through a lot of promised release dates.
Such a shame it’s been so delayed. Radar imaging standardization seems the perfect OneNet use case given that it’s the most glaring hole in marine electronics interoperability. A huge benefit for consumers and sufficient reason for early OneNet adoption. Good to hear it’s being worked on but disappointing to know it’s *still* being worked on. Here’s hoping we’ll see something next year. The high level design non-nmea members like myself have seen seemed so promising…