search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
91 stars 69 forks source link

RFC 0008: Placement of Alternator details #331

Open thomasonw opened 7 years ago

thomasonw commented 7 years ago

RFC 0008: Placement of Alternator details

Summary

Handling of Alternators is currently part of the propulsion schema - which brings with it several limitations. This RFQ is intended to discuss how Alternators may be address in a more generic way.

Motivation

AlternatorVoltage was added to /propulsion/engine/ specification by https://github.com/SignalK/specification/pull/153. Matching well with NMEA-2000 PGN127489 - which natively contains an Alternator Voltage value. However, Alternators are not restricted to propulsion engines. Nor is it uncommon for engines (propulsion, or not) to have associated with them more then one alternator. In some situations, alternators are even placed in vessels without any associated engine (shaft drive alternators for example).

There are many data values associated with alternators which should be reported via SignalK beyond voltage. Some examples include: Temperature(s), amperage, field % excitement/current, rotation (often used to calculate RPMs of driving source, providing the pulley ratio is known). Additional parameters can be foreseen, charing source priority (Solar has higher priority then engine driven alternators), status / condition (Self diag, faults, off-line), charge profiles, and likely more as time continues. By discretely reporting information it opens the possibility for fault checking software, some potential examples: A notable delta/change between Alternator RPM and Engine RPM could be an indication of worn drive belts. A notable delta/change in Alternator Voltage and Battery Voltage could likewise foreshadow a wiring issue.

There is also an issue of how a non NMEA2000 source would produce a propulsion/engine/alternator Voltage message. Specifically, how will a stand-alone alternator regulator know how to create a propulsion signalK message to report Alternator Voltage?

It is the intention of this RFQ that Alternators should be moved from propulsion/engine to electrical/DC. The existing Alternator Voltage should be renamed to indicate propulsion engine voltage as measured at the propulsion engine.

Detailed design

Github Specification pull request #330 (https://github.com/SignalK/specification/pull/330) contains a framework for Alternator information, being represented in the electrical/DC schema. It includes a start of additional alternator parameters and values which are available in modern alternators.

   "alternator": {
+      "description": "Data about a Alternator charging device",
+      "patternProperties": {
+        "(^[A-Za-z0-9]+$)": {
+          "type": "object",
+          "title": "Alternator",
+          "description": "Mechanically driven alternator, includes dynamos",
+          "allOf": [{
+            "$ref": "#/definitions/dcQuantities"
+          }, {
+            "properties": {
+              "meta": {
+                "allOf": [{
+                  "$ref": "#/definitions/identity"
+                }, {
+                  "properties": {
+                    "chargingAlgorithm": {
+                      "enum": [
+                        "trickle",
+                        "two stage",
+                        "three stage",
+                        "four stage",       
+                        "constant current",
+                        "constant voltage",
+                        "custom profile"
+                      ]
+                    }
+                  }
+                }]
+              },
+              "mode": {
+                "type": "object",
+                "description": "Charging mode i.e. float, overcharge, etc.",
+                "properties": {
+                  "value": {
+                    "enum": [
+                      "charging bulk",
+                      "charging acceptance",
+                      "charging overcharge",
+                      "charging float",
+                      "charging equalize",
+                      "unknown",
+                      "other"
+                    ]
+                  },
+                  "timestamp": {
+                    "$ref": "../definitions.json#/definitions/timestamp"
+                  },
+                  "source": {
+                    "$ref": "../definitions.json#/definitions/source"
+                  }
+                }
+              },
+              "revolutions": {
+                "description": "Alternator revolutions per second (x60 for RPM)",
+                "$ref": "../definitions.json#/definitions/numberValue",
+                "units": "Hz"
+              },
+              "voltageSetpoint": {
+                "description": "Goal voltage",
+                "$ref": "../definitions.json#/definitions/numberValue",
+                "units": "V"
+              },
+              "fieldDrive": {
+                "description": "% (0..100) of field voltage applied",
+                "$ref": "../definitions.json#/definitions/numberValue",
+                "units": "%"
+              },
+              "regulatorTemperature": {
+                "description": "Current temperature of critical regulator components",
+                "$ref": "../definitions.json#/definitions/numberValue",
+                "units": "K"
               }
               }
             }
             }
           }]

The existing propulsion/engine/alternator/voltage should be changed to represent voltage as measured at the engine. This will allow some bridging for PGN127489 sourced data - and still retains the concept that if the engine reports out a voltage issue, one needs to look at the engine.

Drawbacks

There are several drawbacks to this change, some of which include:

Alternatives

  1. Alternator's could be added to the electrical/DC specification and Alternator Voltage could be left unchanged in the propulsion section.
  2. Alternator details could be expanded in the Engine section.

Alternative #1 leaves the question of how to correlate the two representation of the same data. Alternative #2 creates the issue of replication when reporting of Alternators on non-propulsion engines. Both alternatives do not address the issue of how a non-NMEA2000 source would populate the propulsion values.

Unresolved questions

How to associate the mechanical driver with an Alternator is still unclear (though it may have been resolved, I am just not aware of the mechanism). A clear 1st need it how to link a propulsion engine to a given alternator - though perhaps the source meta-data could be used by the application to accomplish that. As well as the 'name' which may have been given during a devices installation. There may be other considerations for alternator used outside of propulsion engine (e.g., generator engines, shaft drive, wind/water driven??)

sumps commented 7 years ago

I would define an alternator object in the electrical group and state that this is for ancillary alternators not directly fitted to and monitored by an engine management system.

thomasonw commented 7 years ago

Seems that would limit primary alternators to only Voltage (At present - unless the engine spec is expanded replicating these details). Even NMEA2000's PGN:127506 can be used today to provide a little more detail then that.

It is common to upgrade alternators - would such upgrades be considered ancillary? Creates kind of an issue in which 'alternator' an app look at to report out the engine alternator? Or still be limited to the propulsion.alternator limitations.

I think is is more important to structure Signalk in a logical way as opposed to around what the data source is - and engine management system handler could easily create the electrical.alternator JSON strings at the same time it crates the other engine details via propulsion.engine.

rob42 commented 7 years ago

Keep in mind that the signalk tree is only one representation of the data. Using the unix filesystem as a model see hard links: https://en.wikipedia.org/wiki/Hard_link

So its possible to have the alternator in both places. In a simple server you would copy the data to both locations, in a smarter one the keys in either location point to the same variable, so if either path is edited the data is updated in both locations.

To define the schema this way and avoid duplication, place the alternator in a definitions section, and use a $ref to refer to it. Then you can add the same definition to the engine, and to electrical.

thomasonw commented 7 years ago

Now that is interesting, specifically "... in a smarter one the keys in either location point to the same variable, so if either path is edited the data is updated in both locations."

Some questions if I may. With the above approach would the providers need to know about the different paths? Specific example: If alternator.voltage came into the signalK server via the NMEA2000 provider with engine PGN127489, and also came in for the same alternator from data created by an external regulator (say via an serial port) - you are saying the Signalk server would be able to representing them as the same device?

rob42 commented 7 years ago

Dont really know the answers, its one of those options we have to try out to understand better. The providers shouldnt need to know about other, and its not practical to advise them. I guess an app like instrumentpanel would show two alternators today, we would need some way to indicate they were one (UUID?), and the panel to compensate. Same when we receive data, if both are reading alternator.voltage then they would handle them as multiple values, same as for position, with multiple gps units.

For me this option seems a useful way to have a single physical device in two different collections of data. The reason thats useful is if you are ONLY concerned with engines (you still want to know about the alternator), or ONLY concerned with electrical (you want to know all the sources and sinks). So the first has tools that look at *.engine.* and the second looks at *electrical.*. SImpler than trying to get all the alternators from all the various places.

Or we just keep it simple and assign these devices to one predictable place in the tree, and take that into account in apps.

thomasonw commented 7 years ago

I agree it would be tough to configure each provider with the same ID - even if all providers/devices allowed configuration of such. But it does seem this would perhaps be one approach for addressing the issue of how to associate one device with another (engine with its alternator in this case). Not clear to me how extendable it is to other 'association' situations (ala- the power source for a water-maker RO HP pump, or a hydraulics power head, suspect there are others).

Coming back to the alternators, I would say there are are three common associations:

  1. Propulsion engine primary alternator
  2. Propulsion engine 2nd alternator (perhaps directed to house battery)
  3. Some examples of alternators on generators (for its starter battery)

One will also occasionally see 'DC' alternators associated with:

  1. Output side of DC generator
  2. Shaft driven alternators
  3. Wind turbines? (If we generalize 'alternators' as something that transforms rotations mechanical energy to DC electrical energy)
  4. Hydraulics driven alternators
  5. Old 'shark bait' tow behind water turbines (And yes, ignoring that the generator head of an AC generator is really an alternator ..)

Myself, I think it is not desirable for apps (like instrument panel) to be showing two alternators when there is in fact only one. It comes back largely to the association question. Can this be done inside Signal-K? Or does it indeed need to be pushed up to the apps to make any associations. And I do think there is value in being able to poll all alternators via say *.electrical.* as opposed to having to try and guess which other devices might happen to have a charging source - would be a nightmare trying to summarize the electrical system. At the same time, I also see value in the idea of begin able to poll the *.engine.* and see everything associated with it (Alternators, transmissions, hydraulics pumps, crash-pumps, RO pumps, heat-exchangers for hydronic heat source!..)

Would be interesting to hear input from consumers out there. Sumps, do you have any feeling / thoughts on this approach?

sumps commented 7 years ago

Let us look at what is available in the market, but not lose sight of what might be possible in the future.

No alternators that I am aware of have a digital output so we are limited to existing voltage and current measurement sensors, of which the NMEA 2000 ones are the most prevalent BUT due to their price only seen on a fairly small percentage of medium to large pleasure boats.

These sensors Output an instance number that identifies them, but unlike engines there is no "standard" way of using these instances to link them together and in most cases these sensors measure the battery bank rather than a single alternator.

On larger installs with multiple DC generators/chargers, multiple battery banks, etc. the install will be done by a professional dealer/installer who will set the various instances and then link them together and display them in a specialist software package.

Maybe we are looking at the electrical system in the wrong way by placing too much emphasis on the devices and forgetting that the only things that are important in an electrical system are; voltages, currents and connections.

sumps commented 7 years ago

How about a Signal K "tag" for linking things together that can be added by the owner, installer, dealer or boat builder that can be added to any Signal K object to link it together? An object could have multiple tags i.e. Battery1 and FreshWater2 to link a pump to an electrical circuit and a plumbing system.

sumps commented 7 years ago

This allows linking and searching outside of the very powerful URL RestAPI mechanism that's Signal K is built on.

tkurki commented 7 years ago

So its possible to have the alternator in both places.

For http access this is correct and I think a restructured REST API with multiple methods to access the data is the way out of the full SK model is a single JSON document mindset.

But we need to consider the delta messages as well - there needs to be a way to identify the values sent in a delta.

thomasonw commented 7 years ago

Clearly there is a need to providing linkage between different devices - the REST API, tags, installed.location field?? Putting the burden on the installer who really is the only one who can provide these linkages.

N2K is a good spec with limitations. But I think we need to use a critical eye when making architectural decisions. There is a reason vendors have created extensions to NMEA2000. Victron’s VE.net, Raymarine Sea-Talk, just to name a few.

alternatorVoltage contained inside propulsion.engine is a prime example. Despite what NMEA2000 would like to see in its pgn:127489 - unless one has installed an analog engine monitor device - this data value is often in fact the system voltage present at the ECU. Most assuredly with J1939 to NMEA2000 adapters for engines from CAT, Yanmar, Volvo and the like. I would offer it would make more sense to rename alternatorVoltage to perhaps ECU_Voltage or engineVoltage - Is a missing quantity at present, would accurately describe the actual data, and lets the installer make an informed decision on how they wish to present it to the user.

Oh, and not aware of an alternator regulator which natively is capable of producing status digitally? I am : - )

sumps commented 7 years ago

What is the difference between the alternator Output and the ECU voltage ? What components are in between that make these voltages different ?

thomasonw commented 7 years ago

Voltage drop across the power cables. I have seen almost a volt delta when using high power alternators - even with large cables back to the battery. Less but still notable (300-400mV depending on battery SOC) with more modest sock alternators and internal wiring harness - as they tend to use minimally acceptable wiring sizes.

Depending on where the feed wire into the ECU is picked up from, it would see this as well.

natecostello commented 3 years ago

No alternators that I am aware of have a digital output so we are limited to existing voltage and current measurement sensors, of which the NMEA 2000 ones are the most prevalent BUT due to their price only seen on a fairly small percentage of medium to large pleasure boats.

Not sure if this issue is still actually open, but...Now days there are products like the Wakespeed 500 that provide significant details of operation via CAN.

tkurki commented 3 years ago

Funnily enough the same Al Thomason who created this issue went on to create Wakespeed if I am not mistaken!

thomasonw commented 3 years ago

Teppo, You are correct! Not only was that original statement not true when it was made, but today we are seeing great interest in the reporting capabilities of the WS500 -- including a couple who have been asking about Signal-k.

Now, folks might also recall that I did the bridge between the predecessor of the WS500 (the VSR), but it is based on USB attachment.

https://github.com/thomasonw/signalk-parser-OSEnergy

And truth be told, was well outside my skill-set (I asked a lot of basic questions back then). If there is some resource who would be interested in tackling a CAN based bridge, I am more than here to assist from the CAN / RV-C / OSEnergy side...

On Fri, Dec 25, 2020 at 8:30 AM Teppo Kurki notifications@github.com wrote:

Funnily enough the same Al Thomason who created this issue went on to create Wakespeed if I am not mistaken!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/331#issuecomment-751269160, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACC5NDT4VAXZPRJTWPEUXWTSWS42ZANCNFSM4C7M4I5Q .

thomasonw commented 3 years ago

Sorry, replied to this issue via Email without looking back at the history on Github ... bridge comment is out of context I know...

My apologies.

-al-

natecostello commented 3 years ago

If there is some resource who would be interested in tackling a CAN based bridge, I am more than here to assist from the CAN / RV-C / OSEnergy side...

@thomasonw, this is high on my todo list once I get a handle on signal K in general.

thomasonw commented 3 years ago

@natecostello Nice. Reach out to me when you get closer. There is another chap looking at Signal-K as well, perhaps between all can get something going. (If you are not able to dig out an Email for me via Github, drop an Email from the wakespeed website and mention 'Al / Signal-K')