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!