The GPSd project has developed a protocol for transmission of GPS and AIS data. It is based on JSON (Javascript Object Notation) which offers a number of advantages.
- It is human readable which is widely regarded as being beneficial when debugging systems
- It is extensible
- It is easily assimilated into many modern high-level languages, facilitating rapid application development
On the downside it requires more space to transmit than a binary format, requires more processing to parse and most significantly requires dynamic memory allocation which is resource inefficient and complicates processing, although much of that will be hidden from programmers in higher level languages. GPSd imposes some additional constraints on its JSON messages to allow for compact and efficient processing, notably a fixed maximum array size and disallowing the use of the NULL character: legal in JSON but traditionally a string termination character in C and some derived languages.
GPSd is currently maintained by Eric Raymond, one of the biggest names in the Open Source movement whose work in publicising the details of NMEA-0183 has facilitated much of the software development which has leveraged that still-technically-closed protocol. It has a very large existing user base and would seem ideal as a starting point for a general NMEA-alternative protocol.
GPSd as it stands is not a general purpose marine data communications protocol and direct OneNet alternative. Most significantly the protocol only documents GPS and AIS related information although extending to other types of data would seem entirely feasible. The protocol is transport-agnostic. The gpsd program itself implements a tcp server although an add-on program (gps2udp) can distribute gpsd data via UDP. Being unconcerned by lower layers is certainly good software architecture design and poses no problem for the general use case of gpsd but it may not be ideal in a network of autonomous sensors providing updates over multicast UDP as advocated in a previous post. Here the imposition of limits on message length in order to fit into a single datagram may increase reliability and simplify processing.
Other features not relevant to the core functionality of GPSd which might be considered desirable in a complete marine protocol suite would include a standard authentication method which does not require a connection-oriented link and some kind of service discovery mechanism.
Looking further to investigate whether anyone was working on a more generalised communications protocol I was pointed in the direction of the SignalK project. SignalK, named after the single-flag signal Kilo ("I wish to communicate with you") is a concept being developed by a group which includes the developers of some popular open source marine projects. It is, however, not a communications protocol but a data model for representing all information relating to a vessel and its environment. It proposes the use of JSON to convey information between SignalK systems but conceptually this is not a standalone protocol but a native method of sharing data in the common model. Although an example of the data representation envisaged for SignalK in the form of a GNSS object is given, the bulk of detail in the model has yet to be filled in with much of the discussion currently focusing on higher-level concepts. The project seems geared towards the idea of a central server holding a data representation which can be communicated to other servers locally or on other vessels as well as client applications. Project participants have argued that this does not preclude the concept of a distributed network of sensors providing independent asynchronous data updates but that area does not seem to be of primary concern.
Does SignalK contain the protocol I'm looking for? It's too early to tell. The project is intended to be far more than a drop-in replacement for proprietary NMEA protocols but could this ultimately be a hinderance to adoption? Marine data communications has traditionally been very engineering-oriented. Implementation of high level object-oriented data models are facilitated by high level languages and communications abstractions (typically over connection-oriented links) but are such concepts going to be readily adopted by those programming limited-resource embedded systems in C? The future would appear to contain sensors with direct network attachment. Not all anemometers or GPS units are on boats. Should the way they communicate with the network be based on their place in a marine-specific data model?
SignalK is certainly an interesting project with some very capable programmers as participants but it is not a simple OneNet alternative and perhaps this may ultimately be a hinderance to wider adoption.
GPSd is currently maintained by Eric Raymond, one of the biggest names in the Open Source movement whose work in publicising the details of NMEA-0183 has facilitated much of the software development which has leveraged that still-technically-closed protocol. It has a very large existing user base and would seem ideal as a starting point for a general NMEA-alternative protocol.
GPSd as it stands is not a general purpose marine data communications protocol and direct OneNet alternative. Most significantly the protocol only documents GPS and AIS related information although extending to other types of data would seem entirely feasible. The protocol is transport-agnostic. The gpsd program itself implements a tcp server although an add-on program (gps2udp) can distribute gpsd data via UDP. Being unconcerned by lower layers is certainly good software architecture design and poses no problem for the general use case of gpsd but it may not be ideal in a network of autonomous sensors providing updates over multicast UDP as advocated in a previous post. Here the imposition of limits on message length in order to fit into a single datagram may increase reliability and simplify processing.
Other features not relevant to the core functionality of GPSd which might be considered desirable in a complete marine protocol suite would include a standard authentication method which does not require a connection-oriented link and some kind of service discovery mechanism.
Looking further to investigate whether anyone was working on a more generalised communications protocol I was pointed in the direction of the SignalK project. SignalK, named after the single-flag signal Kilo ("I wish to communicate with you") is a concept being developed by a group which includes the developers of some popular open source marine projects. It is, however, not a communications protocol but a data model for representing all information relating to a vessel and its environment. It proposes the use of JSON to convey information between SignalK systems but conceptually this is not a standalone protocol but a native method of sharing data in the common model. Although an example of the data representation envisaged for SignalK in the form of a GNSS object is given, the bulk of detail in the model has yet to be filled in with much of the discussion currently focusing on higher-level concepts. The project seems geared towards the idea of a central server holding a data representation which can be communicated to other servers locally or on other vessels as well as client applications. Project participants have argued that this does not preclude the concept of a distributed network of sensors providing independent asynchronous data updates but that area does not seem to be of primary concern.
Does SignalK contain the protocol I'm looking for? It's too early to tell. The project is intended to be far more than a drop-in replacement for proprietary NMEA protocols but could this ultimately be a hinderance to adoption? Marine data communications has traditionally been very engineering-oriented. Implementation of high level object-oriented data models are facilitated by high level languages and communications abstractions (typically over connection-oriented links) but are such concepts going to be readily adopted by those programming limited-resource embedded systems in C? The future would appear to contain sensors with direct network attachment. Not all anemometers or GPS units are on boats. Should the way they communicate with the network be based on their place in a marine-specific data model?
SignalK is certainly an interesting project with some very capable programmers as participants but it is not a simple OneNet alternative and perhaps this may ultimately be a hinderance to wider adoption.
SignalK is a nice initiative but in my opinion it will never be accepted by the professional marine industry because of using JSON. It will receive a much higher acceptance level if they would have chosen XML. There are industry accepted marine XML schema's available, so why re-invent the wheel?
ReplyDeleteThanks for the heads up on that. Is this what you're referring to?:
ReplyDeletehttp://www.metoc.gov.au/products/xml_schema/marine_xml_schema.html
Is it widely used?
I definitely agree with not re-inventing the wheel but with JSON being used by GPSd, Navico's GoFree service announcements and gaining traction in the IoT space it seemed like that was where the traction was. What I'm not fond of is the object model Signal K seems to impose is a rather javascripty way (not that the Signal K developers would argue that it doesn't). I'll definitely look further into how people are using xml