Electricial: Handling of additional charging sources

Generic charging source vs. discreet definitions.

Currently there is only one charging source defined, looking much like an AC charger. But there are a whole host of other devices, say Solar, etc.. To expand there are perhaps two options:

1) Create a new definition for each type, e.g.: to add Solar create a Solar def:

Solar.name: Solar MPPT
dcQualities = House DC Bus…

2) Reuse the existing Charger definition, adding a type (or Energy Source if you will) :

Charger.name: Solar
- Type: Solar
- dcQualities = House DC Bus…

The problem I see with approach #1 is it introduces a lot of repetitiveness in the spec with the need to create a new definition for each and every type of charging device. I think approach #2 is better. ‘Type’ might start as: AC, Solar, Wind, Water, Alternator, DC Generator, Fuel Cell; as new charging devices are created Type could be expanded. The idea here is to reuse as much as we can. Using this approach to add the main alternator to the mix:

Charger.name: Engine Alternator #2
Type: Alternator
dcQualities = House DC Bus…

I am good with approach 2. The type should naturally be an enum.

Btw in a very N2K way Signal K has alternatorVoltage under propulsion, associated with the engine/propulsion unit: https://github.com/SignalK/specification/blob/master/test/data/electrical.json#L160

If we would deprecate that in favor of electrical.chargers.X we must be able to retain the engine association, to for example present automatically panels with tacho + voltage meters grouped together per engine.

I am not comfortable with deprecating the current Alternator solution. An alternator is an integral component of the engine and should stay with the engine group as the data is coming in the same PGN as the other engine data.

At the moment we have a nicely defined solution that is automatically configured from the N2K data, I am worried that if we start modifying the schema to match theoretically perfect models, that we will end up with something that requires so much manual setting up that it is impossible for the average boater to setup.

By all means allow alternators to be linked to an electrical charger object but don't start deprecating things that are "very N2K", as it will be the N2K backbones that drive a lot of the Signal K data.

In reality, if the boat owner wants to properly monitor the alternator charger, then it will be necessary for them to fit an additional voltage and current sensor close to the battery banks it will be charging. This data could be mapped to an electrical charger object, but please don't deprecate the propulsion alternator voltage.

I think before addressing some of the other issues I opened today this one here perhaps best illustrated a fundamental point which could use clarification. What IS the objective of SignalK? Is it a modern open data format ‘…compatible with NEMA0183 and NMEA2000’, or one as Sumps stated: “… optimised for efficient and effective integration with the equipment that the majority of boats have, which rightly or wrongly is 95% NMEA0183, NMEA2000 or J1939 based.”

Clearly there is a heavy influence of NMEA2000 currently in SingalK. Basing architectural decisions to optimize for NMEA2000 PGNs (in effect, carry them forward) does makes it simpler to create the NMEA2000 front end. I can clearly see that in the NMEA2000 provider code, it is rather elegantly implemented and optimized – but seems to do little in the way of translation or processing information, in effect simply passing data through. However this approach also exposes the backend applications to the same disconnects inherent in NMEA2000. The alternator is perhaps one example. By including it in the engine schema it makes the translation of NMEA2000 messages simple. But it also brings some limitations: Where is the alternator temperature? Current? % utilization? In the case of two alternators on one engine the end user application is complicated by two entirely different APIs: one is through the engine, while the other is through Electrical. Do we mitigate this by requiring the engine alternator to replicate its information in two places, one in the engine and one via the electrical schema? And if so, where is this done? And how does the application sort this out?

And I am not trying to be disrespectful here, it is clear a lot of work has gone into this effort – and it could very well be that might not have happened w/o the N2K focus. So I would like to get a clear answer: Is it the goal of SignalK to be in effect a NEMA front end with a modern API? Where architectural decisions / definitions are guided primarily to carry forward in a rather transparent manner the underlying NMEA standard (including its limitations). Or is SignalK intended to be more neutrally architectured – with an optimization more toward a clear and consistent application API.

Or perhaps said another way with this example: Do we leave the engine’s primary alternator in the propulsion section, or move it to the electrical section – with a back reference to associate it with a given engine.

To be honest, I can see ++ and - - to either overall direction. Just need to know the field we are playing on.

I agree with Al completely, I never liked or understood the alternatorVoltage field in propulsion. It just doesn't belong, it's not propulsion.

What we do need – as @tkurki says above – is some way to link an engine with an alternator or alternators. It's really not all that uncommon to have more than one alternator. I think Steve Dashew's latest boat has 3 on an engine. This is something that no current standard provides. Engines linked to alternators, solar panels linked to regulators, regulators and alternators linked to distribution busses, battery banks and load panels linked to load panels, and circuits linked to load panels. Ultimately, that sort of systems-level linkage would be carried in to plumbing, hydraulics, steam, compressed air, etc. You see this sort of thing in industrial control systems, where control panel UIs are schematic representations of the machine being controlled. If we include that information in Signal K, instrument panels can self-configure to it.

If we would deprecate that in favor of electrical.chargers.X we must be able to retain the engine association, to for example present automatically panels with tacho + voltage meters grouped together per engine.

I think we can deprecate it and do something like this (new schema group):

{
  // not in love with this name
  "associations": {
    // Arrays are OK here, because I think the relationship is transitive
    "engine0": [
      "propulsion.engine0",
      "electrical.dc.sources.alternator0",
      "electrical.dc.sources.alternator1"
    ],
    "engine1": [
      "propulsion.engine1",
      "electrical.dc.sources.alternator2",
      "electrical.dc.sources.alternator3"
    ],
    "startbatt0": [
      "electrical.dc.sources.alternator0",
      // storage may be better than batteries, what if you have fuel cells?
      "electrical.dc.storage.battery0"
    ],
    "startbatt1": [ "... similar to above ..." ],
    // The concept of a bus is important, and it might exist elsewhere for
    // monitoring and such
    "maindistribuitonbus": [
      "electrical.dc.sources.alternator1",
      // chargers (and inverters) are chimeric beasts, and perhaps live in
      // `electrical.ac.loads` as well
      "electrical.dc.sources.charger0",
      "electrical.dc.sources.solarmptt0",
      // you might have individual cell monitoring, but it doesn't need
      // mentioning here
      "electrical.dc.storage.battery1",
      "electrical.dc.loadpanel0"
    ]
  }
}

This would go on and on, describing what circuits are attached to each load panel (or distributed switching box), perhaps which lights are connected to which dimmer. We describe the entire system.

An alternator is an integral component of the engine and should stay with the engine group as the data is coming in the same PGN as the other engine data.

I've said before that I disagree with this. Alternators are attached to engines, no more. What about engine driven refrigeration, is that integral to the engine? It was a mistake on the NMEA's part to group alternator voltage with other engine parameters. It's the odd duck.

What IS the objective of SignalK?

Signal K should be compatible with existing standards, in as much as we define a two-way translation between them. It should also be more than the existing standards, or what's the point? Saying, "hey, we've achieved parity with a standard from the early 80s and another circa 1998" is not much of a flag to wave in 2016, especially with OneNet on the horizon.

Furthermore, carrying forward n2k or n0813 decisions should not be the goal of Signal K. Organizing data in structured and logical way is. It's not any more difficult to split up a PGN into different parts of the Signal K tree than it is to keep the values together. We cannot afford to blindly repeat decisions made under the constraints of a protocol very different to our own.

Where is the alternator temperature? Current? % utilization?

In the current implementation, these would be right next to alternatorVoltage under propulsion. Which further makes propulsion the odd man out, because elsewhere we'd have these grouped together under an alternator topic.

In the case of two alternators on one engine the end user application is complicated by two entirely different APIs: one is through the engine, while the other is through Electrical.

This right here should be reason enough to deprecate the existing alternatorVoltage.

Do we mitigate this by requiring the engine alternator to replicate its information in two places, one in the engine and one via the electrical schema?

As much as it pains me to say: yes. It breaks a core tenet of Signal K, which is that no data exists in more than one place. However, it's done and it cannot be undone, at least until v2.0.

And if so, where is this done? And how does the application sort this out?

The bigger question you should be asking is how do you decide which one gets to be propulsion..alternatorVoltage (or maybe you are asking that ... it's late). As for display apps, I think we just make it clear that they should use the values in electrical and pretend the ones in propulsion don't exist.

I think Tim answered the question about Signal K's mission very well:

Signal K should be compatible with existing standards, in as much as we define a two-way translation between them. It should also be more than the existing standards.

We started off with a clean slate, but our drawing equipment has been traditional and has affected the outcome. Finding homes for NMEA data has naturally affected the data model.

alternatorVoltage is where it is because electrical subschema was nowhere functional at the time and as pointed out there is clear value in representing the relationship to the engine.

The fact that a PGN has several values is not really a driver here: you map each value to a distinct path and it doesn't matter technically if value A goes to electrical and value B in the same PGN goes to environment or any other path.

We also started off with a single hierarchical JSON structure as the hammer in hand and the foundation to build on. I think that foundation is now showing cracks: there are interconnections that do not fit well into the hierarchical structure. Everything can be solved with extra indirection layers, but pretending that there is just one hierarchical view of things is keeping us back.

In the case of two alternators on one engine the end user application is complicated by two entirely different APIs: one is through the engine, while the other is through Electrical.

Is that a complication or a flexibility? If the app is interested in all things electrical it can query .../electrical, if engines .../propulsion and finding an alternator in the electrical section it should be able to retrieve the data for the associated engine.

If you consider the hierarchical data model a structured API and not a single JSON document where everything has a single home I think we can start making better progress. Yes, implementation will be more complex, but life is...

Btw the current model does support more than one alternatorVoltage with the multiple values mechanism. A practical example is that InstrumentPanel will show two voltage gauges if you send alternatorVoltage from two sources. Less than perfect, I know, as it doesn't really model the fact that you have multiple alternator devices, but so far we have been more about having single, predictable homes for sensor values. I guess we need to move beyond that.

All that said we do need to take care now: there is software and hardware out there and we do need to take care of backwards compatibility - or be clear about lack of it.

Closing this issue. The original question of Enum vs. Discreet has been resolved (using Discreet).
There still is an issue of associating devices across the schema's, but that is a different issue.

SignalK / specification

Electricial: Handling of additional charging sources #262