Signal K

[muttnik]

With all the Signal K buzz about at the moment...IIRC nohal has a Signal K branch but (possibly due to my inability to fully comprehend github) I couldn't find it.

Anyone got a pointer? I'm interested to know what the plans are. Are we talking converting external Signal K streams to NMEA-0183 for use internally (where equivalent sentences exist) or ultimately trying to change the internal architecture of OpenCPN?

[nohal]

Originally Posted by muttnik

With all the Signal K buzz about at the moment...IIRC nohal has a Signal K branch but (possibly due to my inability to fully comprehend github) I couldn't find it.

Anyone got a pointer? I'm interested to know what the plans are. Are we talking converting external Signal K streams to NMEA-0183 for use internally (where equivalent sentences exist) or ultimately trying to change the internal architecture of OpenCPN?

muttnik...
I had no time to work on this since the very beginning of SignaK when I had a look on how we should implement it, there is nothing to look at in the code I have written so far, will push it to github when there is.
The goal, at least mine, definitely is to change the internal OpenCPN behaviour, NMEA-0183 as our pipeline is IMO not sustainable. = Wherever the core now depends on an NMEA sentence, replace it with a protocol agnostic data structure fed from any protocol specific input connector.
BTW, do you have some library preferences for mDNS and websockets?

Pavel

[muttnik]

Thanks Pavel

Originally Posted by nohal

Wherever the core now depends on an NMEA sentence, replace it with a protocol agnostic data structure fed from any protocol specific input connector.

Good call.

Originally Posted by nohal

BTW, do you have some library preferences for mDNS and websockets?

I'm not the best person to ask ( especially about web-y protocols :-). For mDNS I'm no expert and I am for sure telling you what you already know, but I had a brief look a year ago for my own project (for service discovery / resolution). I'm not using a cross-platform toolkit so was looking at using the bonjour api. That's a bunch of dependencies though. For windows (which kplex fortunately doesn't support) you need bonjour for windows installed. For other non-mac platforms you need avahi with the bonjour compatibility library (I'm not certain of the compatibility library's support status). In the end I dropped it: gofree service discovery in kplex is implemented by parsing the gofree json advertisements and I personally use manually configured avahi to advertise an _nmea-0183._tcp service.

A bit of googling seems to show mDNS supported in Qt and turned up a wx service discover library on github but I have no experience of either, sorry.

That was a very long way of saying "sorry I don't know" :-)

[bcn]

One observation about the SigK debate:
as there is no safety net/safety layer provided for SignalK - which is ok while you are working locally and not with a cloud based approach and your local net is properly encrypted - developers tend to provide a NMEA0183 and/or NMEA2000 gateway as a one-way road until this layer gets defined and implemented. Authentification of data providers and integrity of data will be required.
The SignalK team is working on this.
No injection of SigK data back into the NMEA backbones until then.

Which would not prevent to read SignalK/JSON streams into OPCPN, pass them through the multiplexer (which would have to be modified accordingly) and having plug-ins to work with this data.

This does not resolve the basic architectural challenge Pavel has underlined.

[muttnik]

Originally Posted by bcn

developers tend to provide a NMEA0183 and/or NMEA2000 gateway as a one-way road until this layer gets defined and implemented. Authentification of data providers and integrity of data will be required.
The SignalK team is working on this.
No injection of SigK data back into the NMEA backbones until then.

Whenever I ask "Where was that stated? I didn't see it on the Signal K google group?" The answer is usually "It was discussed on Slack.." so I won't ask :-)

I do appreciate the point: although NMEA protocols are themselves unauthenticated they aren't inherently routable, minimising the threat. Stick a gateway to a routable protocol on there and you have a potential threat.

However is there a difference between an unauthenticated Signal K-to-NMEA gateway and an unauthenticated NMEA-0183-over-IP-to-NMEA gateway as many OpenCPN users use to send data to autopilots already? I'll suggest that there isn't...

In this interview Digital Yacht's CTO states that iKommunicate will probably be made bi-directional in a future firmware update. He seems pretty sanguine about the security threat and says (well this is my interpretation..) that iKommunicate doesn't route off-subnet.

Sorry for being a bit off-topic: the only relevance for OpenCPN here is that there *might* be a point to OpenCPN *transmitting* Signal K before a panacea is found for its security issues.

[bcn]

Absolutely correct. But as SignalK is about communication and the creators do see it in the world of IoT (Internet of Things) the questions about threats (who can push the trigger, who originates a waypoint, can I trust a sounding, a marker..) has to be contemplated by design.

Some points from a discussion we have started at the University here:

SignalK: scenarios to ensure secure communication

The challenge of authentification and data integrity

1. In-ship 1-way
Usage example: Virtual instruments, Glass Bridge
from NMEA0183, NMEA2000 sources (via cable, WiFi, BT) to SignalK clients
via Ethernet or serial protocols (cable, WiFi, BT, NFC) on devices that can display or process SignalK streams
Option: private gateway into WWW for remote monitoring

2. In-ship bi-directional SigK gateway
Usage example: Autopilot and steering, E-throttle, switch from app (IoT onboard)
The same as (1) adding injecting data back into the ship systems.
The physical and COM environment is the same and remains local or enhanced by private remote access

3. Ship to ship (to ship) - closed group WiFi
Usage example: Pilotfish: share relayed soundings or waypoints
Adding communication to third units on other ships - enhanced local private net

4. Ship to cloud to ship - Mobile connection/ fallback to WiFi
Usage examples: Pilotfish: share relayed objects like soundings, General share POIs, waypoints, AIS objects, marker , meteo
Access to public services (public includes closed user groups or applications but integrated into WWW)

5. Ship to shore/shore to ship/ship to ship - Mobile, SatComm, WiFi, VHF
Usage examples: Remote piloting, SAR operations
Restricted non-public operations on public or private channels


Authentification of data originator/source (ad-hoc/permanently)
Integrity of data transmitted
Confidenciality of data transmitted

Invitation for discussion....

Hubert

[Paul_DY]

Hi Everyone,

Hubert kindly forwarded me a link to this thread and I just wanted to say hello and confirm that I am available and willing to help in anyway I can in your Signal K evaluation/implementation.

I would describe myself as a Product Manager rather than a software developer, but I do have 30+ years experience in marine electronics and NMEA interfacing so I should be able to help on the high level conceptual stuff, even if I cannot jump in or understand the code !

Best regards
PAUL SUMPNER CTO of Digital Yacht

[muttnik]

Originally Posted by bcn

SignalK is about communication and the creators do see it in the world of IoT (Internet of Things)
[...]
Invitation for discussion....

With the caveat that I'm happy to be convinced otherwise...

I'll suggest that the canonical Signal K architecture is fundamentally not "IoT". The "Things" in question (autopilots, transducers, GPS receivers, fridges) don't have a direct connection with clients: the Signal K server sits in between. Currently that separation is physical but even for (yet-to-be-produced) devices which speak "native" Signal K, the Signal K server provides *logical* separation between data providers and data consumers. Moreover there aren't many concessions to compactness in the data format in the way that "IoT protocols" are usually geared to low resource use. In the "boat-to-Internet" and "boat-to-boat" scenarios (is the latter scenario really as in-demand as proponents suggest?) it isn't "Things" talking to each other, it's Signal K servers.

The Signal K team want it to be transport agnostic but in practice it really needs a reliable transport and websockets/http seem to be weapons of choice. Anyone planning a Signal K app using a different transport?

There are well-known authentication and encryption options for those transports. Authentication and encryption don't need to be part of the data format any more than they need to be integral to LDIFF (I like my directory server analogy :-). Stop looking for the universal panacea and the problem space shrinks dramatically.

I'll argue that you could secure a Signal K server the same way as you secure a directory server or a web server. If a user has their Signal K server on a closed, secure boat network and want no "social boating" capabilities, unsecured might be acceptable.

Happy to be convinced otherwise but I'll suggest that a 2-way iKommunicate (or similar) on a closed boat network is no more of a security problem than any existing NMEA-to-IP gateway, less if it has no routing, and it would be a shame for functionality to be delayed finding a complex solution to a maybe-less-complicated-than-it-looks problem.

Re-iteration: my mind is easily changed and apologies for getting a little off the OpenCPN topic :-)

[PiXL]

Hi, I'm diggin out this thread because I'm interested in the SignalK stuff, but currently I'm looking for a proper solution to get my waypoint data on OpenCPN to my autopilot on N2k/STng.

I thought about the iKommunicate box as an alternative to the Actisense NGW-1 gateway for this purpose (or, as it's currently done, with a gadgetpool NMEA0183<->Seatalk converter followed by a Raymarine Seatalk<->SeatalkNG converter).

Can it do the multiplexing from NMEA0183 to NMEA2000? Would it accept the NMEA0183 sentences over UDP from OpenCPN?

Other (and probably cheaper) option would be a RasPi with NGW-1 I assume, which could run a multiplexer and Signal K server. If that would work, what difference would it make in terms of SignalK data, if I connect via NGT-1 (where I would miss NMEA0183 data on my boat network as far as I understand)?

Hope my problem is clear and understandable.

[rgleason]

Gadgetpool nmea0183 bidirectional ST converter then Raymarine ST to STng and n2k is a little convoluted. Artisense makes 0183 to n2k devices.

Also if the instruments are ST60 and ST, raymarine makes an ST to STng / b2k converter (a little of topic). At first this seems to be a ridiculous mess of wiring and converters, but they are bidirectional and when the mess is stowed away neatly its not so bad.

It would be nice to have a signal k at the hub of all this, but it seems like the manufacturers are making more and more of these black boxes an stealing the available space!

[PiXL]

Originally Posted by rgleason

Gadgetpool nmea0183 bidirectional ST converter then Raymarine ST to STng and n2k is a little convoluted. Artisense makes 0183 to n2k devices.

Also if the instruments are ST60 and ST, raymarine makes an ST to STng / b2k converter (a little of topic). At first this seems to be a ridiculous mess of wiring and converters, but they are bidirectional and when the mess is stowed away neatly its not so bad.

It would be nice to have a signal k at the hub of all this, but it seems like the manufacturers are making more and more of these black boxes an stealing the available space!

Thanks for the answer, but I don't know what to do with it as it did not answer any of the questions I've had. I agree, two conversions, especially bidirectional, are a bit too much, and it would be better to go directly to n2k from the computer, which is why I'm asking here for feedback.

[bcn]

Have a look at OpenPlotter. They have also a low cost N2K gateway.
And experimenting with SK.
Sailing with free hardware | Sailoog

[PiXL]

Originally Posted by bcn

Have a look at OpenPlotter. They have also a low cost N2K gateway.
And experimenting with SK.
Sailing with free hardware | Sailoog

Sweet, exactly what I need! I've seen navigtrix and follow singalK and canBoat development on github, OpenPlotter brings everything to the same table and adds loads of cheap sensors to fool around with on board. Will definitely give it a try.

[rgleason]

Sometimes bidirectional is very useful especially when the flow can be controlled as in gadgetpool. So I would say that statement is misleading.

[rgleason]

I don't think n2k direct to a PC is possible today without using a manuf black box. I believe the openplotter effort has many possibilities, but does not have full n2k to PC capability at this moment. ---Need all the manuf codes and have to be a member for the documentation. Correct me if I am wrong please.