iKommunicate

People in Tha Middle

Last friday a post on the Signal K google group announced a kickstarter campaign for the first commercial NMEA-to-signal-K gateway to be announced.  The iKommunicate has been prototyped by Digital Yacht, a company whose track record includes being one of the earliest to market with NMEA-to-wireless-IP converters.  iKommunicate features an NMEA-2000 interface, two NMEA-0183 interfaces and an ethernet interface.  NMEA data are converted to Signal K format which is then available for Signal K client applications to query.

Paul Sumpner is Digital Yacht's CTO.  We had talked about Signal K at the London Boat Show in January and when I read the iKommunicate announcement I mailed him to ask if he'd mind answering a few questions about it.  He very kindly agreed.....

Digital Yacht and Signal K

Paul, Digital Yacht were instrumental in popularising the use of “NMEA-0183-over-IP” with their NMEA-to-wifi bridges. What do you believe will be the most significant driver for Signal K supplanting this as data format of choice for app developers?

NMEA-0183 over IP was a good initial solution and for some people will be quite satisfactory, but for the developer there is still the issue of getting the NMEA0183 information, the cost of the spec and NMEA membership puts a lot of developers off and also they have to support a relatively specialist and old protocol.  

The driver for Signal K will be the NMEA2000 data that is not supported in NMEA0183, such as Engine data which until now has been inaccessible to all but a very few developers and once developers get their hands on this data, I think we will see some really interesting and innovative apps.

There are currently very few apps which can use Signal K data and almost none which can only use Signal K as a data source. Who do you see as the early adopters who will buy the first tranche of iKommunicates?

I think once a couple of apps that have a large user base, such as Active Captain or OpenCPN fully release with Signal K support (both have beta releases) then I think iKommunicate will be in demand. Michael Zapf the developer of the popular NMEARemote Instrument App is the first iOS developer to support SK and we will be contacting other iOS and Android App developers about Signal K and iKommunicate.

A kickstarter campaign is an unusual method for an established business like Digital Yacht to fund a new product and your $20,000 target surely can't cover development costs. Did you take this approach to mitigate risk in building a product with unknown demand, to create a pre-release buzz or for another reason?

It is very easy to look at Kickstarter and just see it as a way of getting funding for start-ups but I think any company can benefit from using this medium. If you are developing a completely new and unique product or trying to break in to a new market, then Kickstarter is a great way to promote your new initiative, gain feedback on whether there is a market for your new product/service and to get directly in contact with the early adopters in that market 

Apart from the time and effort in setting up the campaign, there are no other costs and if it turns out that no one likes your new product/service and you do not achieve funding, then you have avoided wasting a lot more time and effort developing a product/service that no one will buy. This is our first Kickstarter campaign and we would certainly use it again.

The kickstarter campaign was launched only days ago but you are more than a quarter of the way to achieving funding (I will be surprised if it's not at least “half” by the time you receive this). In the unlikely event that you don't meet your target, what would be the trigger for Digital Yacht to revisit iKommunicate in future?

You are right, as I am writing this answer, we have just broken the 50% funding target, so fingers crossed we will reach and hopefully exceed our original $20,000 target. Even if we do not reach our target, we hate wasting development time and effort, so we will probably regurgitate the work we have done in to some other new product in the future, but it would be a real shame as I think what Signal K is trying to achieve would be good for our industry.

Even at the full $299 SRP, the iKommunicate is competitively priced compared with some other NMEA-to-IP bridge products. Is it worth buying for its N2K/NMEA-0183 ethernet bridging and multiplexing capabilities alone?

Absolutely, we have really tried to make iKommunicate competitively priced and straight out of the box it will be a very powerful NMEA2000 and NMEA0183 to ethernet bridge, supplying data to many existing apps and software packages over TCP or UDP. Then as Signal K becomes more and more established, iKommunicate can simultaneously supply other devices on the network with the Signal K data.

iKommunicate Product Details

Does iKommunicate implement a complete Signal K server, and if so were compromises needed to make it run in only 1MB memory?

The differences between a Signal K server and a Signal K gateway are somewhat blurred and some Signal K developers would argue that there should be no difference between them. I don't entirely agree with this and designed iKommunicate to be primarily a gateway but also capable of being a basic Signal K server. 

My own view is that in a smaller boat, you will probably just have an iKommunicate and some Apps (Signal K "consumers") that will use the data. So in this instance, iKommunicate is the Signal K server. 

On a larger boat, you may have an iKommunicate and a Signal K server where iKommunicate is just a gateway converting the NMEA data in to Signal K but the server is taking this data, managing it and then serving it up to the apps or sending it to the cloud. 

iKommunicate has been designed to be a very efficient gateway and a low power server, capable of hosting some simple web apps, but not capable of running sophisticated apps, with charts, messaging, logging, etc. We are not running LINUX on iKommunicate, just native C code on an ARM M4 Cortex processor and currently we are not even using half of the 1MB of memory, even when receiving 300+ AIS targets. 

So rather than compromises, we feel that a number of new and different design decisions were taken with iKommunicate and I am very happy with how our "proof of concept" has performed and been received. 

I think a full blown Signal K server needs to run an OS, which is an overhead that requires a faster processor and more memory, but you get access to loads of software services and utilities, making it so much easier to do really powerful and innovative functions and features. That is why the Raspberry Pi, Beagle Board and other COTs hardware solutions have been initially used as the basis for Signal K servers.

Does iKommunicate store vessel state (gleaned from NMEA inputs) in an internal data model, or simply dynamically translate NMEA PGNs/sentences into delta format with Signal K context which are then supplied to all websocket clients? And are there any static data supported/query-able in the initial release?

iKommunicate has a Signal K namespace memory in which it retains the latest values of all the NMEA data that has been received including AIS data (other Vessels). When a NMEA sentence of PGN is received, it updates the namespace and sends out a Signal K delta file. If an HTTP: restAPI GET request comes in, then this is extracted from the namespace and output as SIgnal K HTTP.

We will have an option in the iKommunicate web config page called "Manage Own Data" or similar and this will make the iKommunicate responsible for populating all of the Signal K "Self" data. The static Own/Self data will be populated where possible automatically from the NMEA data or the user can enter the data manually like Boat Name, Dimensions, MMSI, etc.

What (if any) are the major differences between Digital Yacht's Signal K server implementation and the reference open source server?

The main differences are:

1. iKommunicate connects directly to the NMEA2000 network, rather than via a 3rd party NMEA2000 to USB gateway.
2. iKommunicate is a LAN rather than a WAN device and another server or app is required to handle the external transmission and reception of the Signal K data in to the internet.   
3. iKommunicate (at least in Version 1) does not support subscription websockets, it simply sends all "delta" files through the websocket i.e. every time a new NMEA PGN or Sentence is received it transmits a Signal K "delta" file. The idea with subscriptions is that the app asks for specific data and the server remembers what data the app is interested in and only sends this data when it changes

Is the flow of information through iKommunicate “one-way” or can data be passed back to the NMEA side, e.g. to control an autopilot?

In Version 1 of iKommunicate there is only data flowing from the NMEA networks to Signal K, apart from the minimum NMEA2000 network
interaction i.e. address claiming, heartbeat PGN, etc. We will be adding bi-directional NMEA communication though in a future firmware release, which by the way is designed to be really easy to update; either by uploading an update via its built-in web interface, downloading directly from the internet or copying it to the internal SD card.

Security is something that has been discussed more than directly implemented in Signal K. What (if any) security challenges will iKommunicate address in its initial implementation and what do you intend to address in future firmware updates?

The security of the "Internet of Things" in general is being discussed ad infinitum by many, many technology companies and organisations and still has some way to go before the procedures, tools and mechanisms are in place for a secure "IoT" world. The Signal K team could have wasted a lot of time and effort on security and it was felt that, at least for Version 1 of Signal K and iKommunicate, that the issue of security should be left with the Apps and Services that were taking Signal K data from the boat and transmitting it in to the internet. 

In reality every boat has a large and very good security "firewall", the open sea they are sailing on, and for the vast majority of Signal K users, the data will stay firmly on the boat, at least until more apps and services become available. On larger commercial vessels and super yachts, there will already be a secure and protected network onboard which Signal K can hide behind, as after all it is just normal network data. 

We are following closely how the security of the "IoT" is progressing outside of the marine world, in particular open source initiatives such as Let's Encrypt (https://letsencrypt.org/) to create free SSL certificates. As and when a clear security solution for "IoT" appears, we will aim to include it in Signal K.

Future Direction

At this stage Signal K complements rather than replaces NMEA protocols, with products like iKommunicate providing the necessary bridge. How much harder / more expensive (if at all) would it be to implement a sensor (e.g. GPS, Heading) outputting “native” Signal K (in its current form) than one which outputs NMEA-0183 or N2K (or, dare I mention, OneNet?)

Any "smart" sensor that has a microprocessor, rather than just a transducer inside, could in theory be a Signal K sensor. In component cost terms there is a bit of a step up from NMEA0183 to Signal K, but the difference between an NMEA2000 interface and a Signal K interface is very small and in fact it might actually be cheaper to do a Signal K interface. 

You would really want the Signal K sensor to use PoE (Power over Ethernet) which will add some additional component cost but it is not completely out of the question, I am not sure it will be Digital Yacht, but I am sure we will see Signal K sensors before too long.

If iKommunicate proves successful, what other Signal K products are Digital Yacht considering?

We intentionally did not include Wi-Fi in the first version of iKommunicate, as we felt that most early adopters would be pretty technical users and most likely have their own wireless network onboard already, but a wireless iKommunicate would be useful for smaller boats, so that is definitely on our future product roadmap, as is a J1939 version for direct connection to engines that do not natively use NMEA2000. As for anything else, assuming Signal K is the success we hope it will be, let us just say "watch this space" !

As well as implementing Signal K in its products, do you see Digital Yacht (and indeed other commercial organisations) taking an active role in Signal K development?

I hope so and Digital Yacht certainly intend to be an active contributor to Signal K. There are challenges for commercial companies to be involved in "Open Source" projects and I am sure, a certain level of dis-trust from the purist Open Source community members, but there are benefits for both sides and as long as commercial companies put in as much (or more) as they take out, then successful results can be achieved.

Many thanks to Paul for taking the time to share this.  As I write this, just 5 days into the kickstarter campaign and with 47 days still to go iKommunicate has reached nearly 4 times its funding target with more than 340 units spoken for and the number climbing all the time.  Seems like iKommunicate will be a real product and Signal K does have a commercial market.

Signal K revisited (part 2)

Talking 'Bout a Revolution

Signal K isn't what I was looking for last year when seeking an "NMEA protocol alternative". The problem to be solved is how to interface software with sensors and devices on a boat when those sensors and devices use a closed communications protocol whose owners want a (to many independent developers prohibitively high) fee for its use and forbid its use in free software. Wireless networks, tablets and smart phones are now commonplace on boats.  A good solution opens the gateway to even more applications, potentially revolutionising the way many people interact with their vessels.

I believed the solution was a new protocol satisfying the constraints of current NMEA implementations (compact, friendly to resource-limited devices and low-powered networks, easily implemented in low level languages) but running over Internet Protocol and free and open rather than proprietary.  I was initially disappointed that Signal K isn't that thing but I started to like it a lot more once I accepted that and appreciated it for what it is.

Communications Breakdown

Signal K addresses the same problem in a different way.  It's a way of representing the state of a vessel and a format for transfer of all or part of that state to a client application.  It isn't oriented to minimal resource on low powered devices.  Instead it is built to provide data to applications running on consumer devices over full-fat wifi or ethernet networks and is geared towards functionality rather than minimalism.

A "Signal K server" is an entity which acts as an aggregator for information inputs which can come from a variety of sources using any protocols which the Signal K server understands. It uses these data and static information which the user has manually input to create a model of the "state" of the boat and potentially other vessels around it.  In early iterations of Signal K, client applications would update themselves on boat data by regularly transferring the server's internal data model.  As Signal K progressed a method of transferring only new data was adopted (the "delta format") and a method of "subscribing" to updates of particular data.  The transport by which data are transferred is not mandated, although there is now a method of querying the available transports (over http).  A reliable transport is occasionally assumed and the de facto standard transport as used in the reference server implementation seems to be websockets.

What back-end protocols does a Signal K server understand? This is implementation dependent.  The Signal K project defines the architecture and provides a reference implementation (in java and javascript) but the architecture could be implemented by others differently.

The reference server includes providers which can interpret NMEA-0183 and the output of the canboat  analyzer, the latter enabling those with a method of reading NMEA-2000 PGNs (the Actisense NGT-1) to interpret some N2K data.

You're Not the One (I was looking for)

I don't care for monolithic central server architectures, nor of putting extra steps between data producers and data consumers but the data model I initially disliked has many practical advantages.  Although the security implementation is a little sketchy at present it offers the potential for sophisticated access control (like a directory server) allowing detailed specification of who has access to what.  It allows clients to specify how often they want to update their data rather than being passive consumers.  The reality is also that for a while yet our sensors and other marine devices are still going to be talking (a variety of) proprietary protocols rather than open ones so translation will be needed, and the Signal K server provides a straight forward pluggable architecture for that.  I'm not a fan of the (to my mind) unnecessary overhead of http / websockets but this is not a concern in the typical Signal K use case, it simplifies coding in the higher level languages that most app developers use, and the Signal K developers would argue that those transports are not required (despite them being de facto standards).

Picture This

There's currently plenty of details which aren't currently filled in with Signal K.  The most common data have standard representations but much does not.  In many cases this is just a matter of time and work which but much of this needs to be done for Signal K to realise its potential. It is frequently argued that Signal K's JSON format makes it infinitely extensible but it is not without some challenges.

A problem for current NMEA protocols is that they have no standard way of representing imaging data from RADAR and Sonar, relying instead on individual manufacturer's proprietary protocols.  Signal K doesn't yet solve this.  Representing image data in a text-based protocol generally requires encoding which makes high bandwidth data even more bloated.  One proposal to address this has been to use Signal K only to transport the URL of a binary imaging data source which would then be connected to by other means.

Signal K has had many of its rough edges smoothed in the past six months, but it is still a work in progress.

Safe From Harm

Security doesn't feature much in traditional marine data communications.  Most people are aware that that has to change as marine devices become accessible from outside the closed environment of a boat's internal wiring.  There are many aspects to "security" including authentication (proving something says what it says it is), authorisation (saying who can do or see what) and encryption (concealing things from prying eyes).  Using a Signal K server rather than devices publishing data directly to the network allows for a great deal of control over who has access to what.  This potential is not yet well realised, but the architecture should be well suited to it.

Authentication and encryption are the more glamorous aspects of "security" and have been extensively discussed on the Signal K google group but with no definitive mechanisms yet mandated.  The use of web protocols should allow a huge range of well-proven systems to be leveraged but possibly due to a reticence to mandate transports for Signal K, reliance hasn't been put on readily available security mechanisms associated with those transports. I can't help but wonder if standardising on the transports which people are currently using Signal K with and restricting the problem space might result in a more full-featured solution for the common use case rather than an unconstrained but less well defined product.

Welcome to the Machine

Signal K still has a few details to be filled in but it certainly has great potential in its primary use case: providing data from NMEA devices to mobile and web applications and enabling such applications to communicate with each other using the same, extensible format. I feel confident that it will gain considerably popularity over the next year.  It lacks compactness and the tight specification to be ideal as a replacement for NMEA protocols but that's not where it is targeted. It is a complement to those protocols.  The biggest initial driver to adoption is likely to be the ability to represent NMEA-2000 data, much of which can't be represented in the currently popular "NMEA-0183-over-IP" format.  Due to CAN interfaces (as used by NMEA-2000) being less trivial than RS-422 interfaces (as used by NMEA-018) and only part of NMEA-2000 having been reverse engineered, this is where commercial NMEA-to-Signal K gateways (whose vendors have access to the complete NMEA-2000 specification) come in as part of the architecture now embraced by the Signal K team and the NMEA alike.  The average user will need to buy such a device to link their Signal K applications to their boat network.

The big news this week is that Digital Yacht have just announced potentially the first commercial NMEA-to-Signal-K gateway: the iKommunicate   Even more exciting (well, for me anyway), Digital Yacht CTO Paul Sumpner has kindly agreed to answer some questions on the new product and Signal K.  Stay tuned!