6.5.19 DC Source Configuration Command 2
Thu, 2023-12-21 15:44 — RV-C Admin
The following additions are proposed to the DC Source status and configuration DGNs
| Attachment | Size |
|---|---|
| 6.5.19 DC Source Configuration Command 2.docx | 30 KB |
OBJECTION:
OBJECTION: DC_SOURCE_CONFIG
Clayton, Thank you for the clarification and addition insight. At this point I wish to register an OBJECTION this submission on the following points:
1. REDUCTION FACTOR: I can see why this would be of interest, but a question is: Is it better to have this 'factor' declared so that each receiving device can decide if to utilize this calculation or not, or to have it applied globally (as suggested by this submission) so that all receiving devices are able to use the same SOC value without needing to calculate. I feel there is kind of a philosophy side here for RV-C, in is it better to keep data pure with receiving devices responsible for decisions to factor in any subsequent modifications, or for such global factors be pre-applied. Perhaps we can get guidance from those with longer history with RV-C
2. Altering Tx / Refresh rate of DC_SOURCE_STATUS_1: Two concerns:
- DC_SOURCE_STATUS_1 (and many of the others in this section) support a wide range of consumers. From User Displays to Process Control. Altering the Tx / Refresh rate to meet the goals of one will likely end up breaking other consumers. Such smoothing functions should be the responsibility of the data receiving device, not the Tx device, so that appropriate smoothing factors can be applied specific to the end use case.
- There has been some conversations around allowing for requests to change Tx rates of DGN. Example: If a DC_SOURCE_STATUS_xx aggregator wishes to use the BATTERY_SOURCE_STATUS_xx messages for raw input, allow a change from the default On-Request only to some defined Tx rate, thereby reducing overall CAN traffic from repeated Request messages. Such a method would be more global vs. this targeted DGN submission. But also some method would be needed to allow other 3rd party nodes to reject a request. Perhaps a more global approach can be investigated, but it would not remove my primary objection that usage-specific smoothing should be the responsibility of the receiving node, not the Tx one.
3. Replicating Data Value: Yes, can clearly see the symmetry of repeating the data, but again, would perhaps ask for those with longer RV-C experience (Martin, you reading??) to comment on the overall philosophy of this situation..
4. Finally, DC_SOURCE_STATUS_xx section has seen a good number of new DGNs added over the past year primary oriented towards SOC/ SOH meters. This submission seems to add a number of addition ones. There is a core conflict in that only one node is allowed to speak for a given DC Data Instance, I can easily see a conflict: A BMS and a 3rd party SOC meter. Allowing the SOC meter to speak introduce danger as the BMS is not longer able to communicate out pending disconnect status, while keeping the BMS as the master would preclude the ability to market and support a 3rd party stand-alone SOC/SOH device. I suggest we investigate moving these DGC proposals, and a good number of the recent DC_SOURCE_STATUS_xx DGNs into a new device class: SOC Meter (or such). This would allow co-existence of both the BMS and a SOC meter, and even allow for a value-add SOC meter to replace the 'Battery SOC' values if a BMS is already producing them. I would suggest existing DC_SOURCE_STATUS_xx messages that are largely SOC related be moved to the new section, but retain their actual DGN numbers so as to remain backwards compatibility
Overall, I think there is a lot of good value in this submission, and can see how it will be a good addition to the RV-C spec, but feel we need to step back some and perhaps consider this in a slightly larger scope.
1) We could remove this if it
1) We could remove this if it is a concern. We hadn’t planned to use it right away so we can deal with it at another point.
2) This has no impact on the Tx rate of the message. They are just clarifying the averaging (smoothing) period used for the broadcast voltage and current measurements and allowing them to be adjustable. Right now, everyone is doing their own undocumented averaging periods, and this would allow them to be standardized. We didn’t see this as concerning but it could also be removed if necessary.
3) Though it could be awkward to not have symmetry here, again we could remove this if necessary. Our opinion was that duplicate data would be the lesser of the two concerns.
4) Though this could be an option, this is a big picture project which likely would need to reconvene the subcommittee and isn’t directly related to this individual submission. Similar submissions have already been added to other sections, and as they are lacking for this purpose, we do need some path forward. If someone can quickly get the power team working on this and come up with a more generic approach that is fine, but without that we need some way to add in missing data so we can keep development moving.
I tend to agree with
I tend to agree with Clayton's perspective for following reasons:
1. Everything in these new DGNs is optional, no one is forced to use any of these features if it doesn't fit their product strategy.
2. From the perspective of any receiving device all DC_SOURCE data is "actual", even if sender has some internal reasons to smooth the data or manipulate the data to achieve some desired effect. Backwards compatibility is not broken because all recievers treat the data as "actual" and act accordingly.
3. Even though battery type is repeated in the status, it is done in a spirit of symmetry generally required across RV-C, so no harm is done. Also, this status message is only sent on demand, as a confirmation of a configuration change, while DC_SOURCE_STATUS_4 is sent regularly as a normal course of charge session control, so these DGNs serve different purposes.
I also agree with Al's point that new DGNs are too specific to SOC meters or Battery Monitors, rather than more generic DC_SOURCE category. For years it was difficult to separate DC_SOURCE from BATTERY as we all know in most cases DC_SOURCE is a battery or a bank of batteries. Then we finally added BATTERY DGNs to match with DC_SOURCE to allow multi-battery banks management.
So, my counterproposal would be to move these new DGNs to the BATTERY category, which is already defined and doesn't need a major group effort.
Initially we matched a BATTERY DGN for every DC_SOURCE DGN, but do we really need to keep doing it? Do these index numbers really mean anything to anyone? In the end we just need a unique DGN number, the label isn't that relevant when we are dealing with dozens of DGNs to cover battery management.
DISCUSSIONS: DC_SOURCE_CONFIG
DISCUSSIONS:
DC_SOURCE_CONFIGURATION_COMMAND 4
1) After defining a 'Reduction Factor (Byte 3), please clarify how SOC should be reported in DC_SOURCE_STATUS_2, when the actual SOC is below a newly defined lower bound. (Assuming 0?). And also, please clarify impact on the factor of TIME Remaining (Byte 5/6): should is be adjusted with respect to the new defined lower limit or be reported with respect to the full battery capacity?
In a like light, does this 'SOC' reserve impact DC_SOURCE_STATUS_3 Relative Capacity and Remaining Capacity (Bytes 1/2, 3/4). Is the intention this value remains true to the actual expected remaining capacity, independent of a SOC lower Reduction Factor. (reference also details in DC_SOURCE_STATUS_11)
2) Please elaborate on, bytes 4/5: Current/Voltage Time Constants. How are these used, and what would be the intended change in a device reporting voltage/current via DC_SOURCE_STATUS_1 ?
"This parameter can be used to change the averaging time constant used for the reported Current measurements in DC_SOURCE_STATUS_1 Resolution is 0.1s, with a range of 0.1 to 25.0 seconds."
3) DC_SOURCE_CONFIGURATION_STATUS_2 Battery Type (byte 7), this is replicate of already defined DC_SOURCE_STATUS_4 (Battery Type, Byte 7), is this something we wish to do?
1) The SOC reduction factor
1) The SOC reduction factor would be an optional modifier and work similar and in addition to the state of health in how it reduces State of Charge, Relative State of Charge and Capacity Remaining. Time remaining for discharge would also be relative to Full Capacity after reduction. The table with DC_SOURCE_STATUS_11 could be updated as follows (sorry for the lack of a formatted table, but this should give the idea):
Example Battery Bank Size (no reduction factor)
Full Capacity: 100 Ah Specified capacity battery was designed to deliver
SOC Reduction Factor: 100% Full capacity is not being reduced by reduction factor
State of Health: 90% Remaining battery capacity due to aging/degradation as a percent of Full Capacity
Present Capacity: 90 Ah Amount of capacity taking into account age and battery degradation
Capacity Remaining: 40 Ah Example battery with 40 Ah of energy remaining until fully discharged
Relative Capacity: 44% Charge relative to present capacity of battery (Accounting for SOH)
State of Charge: 40% Charge relative to its designed capacity (No SOH adjustment)
Example Battery Bank Size (with reduction factor)
Full Capacity: 100 Ah Specified capacity battery was designed to deliver
SOC Reduction Factor: 90% Full Capacity is being reduced to 90% to avoid battery being completely discharged.
Full Capacity after reduction: 90 Ahr SOC reduction factor effectively reduces the Full Capacity
State of Health: 90% Remaining battery capacity due to aging/degradation as a percent of Full Capacity
Present Capacity: 81 Ah Amount of capacity taking into account age and battery degradation, and after SOC reduction.
Capacity Remaining: 40 Ah Example battery with 40 Ah of energy remaining until discharged relative to Full Capacity after reduction
Relative Capacity: 49% Charge relative to present capacity (Accounting for SOH and reduction factor)
State of Charge: 44% Charge relative to Full Capacity after reduction, but with no SOH adjustment
2) If a device supports these parameters, then it would give some control over how responsive the voltage and current values reported by DC_SOURCE_STATUS_1 are to rapid changes in current or voltage. If a very short time constant is used, then the reported voltage and current would be more instantaneous values, which could fluctuate significantly from one DC_SOURCE_STATUS_1 message to the next. Using a longer time constant of a few seconds should smooth out voltage and current transitions, so the values will fluctuate more gradually.
3) It does result in a duplication of the status in DC_SOURCE_CONFIGURATION_STATUS_2 and DC_SOURCE_STATUS_4, but there was no way to set the battery type previously, which is why it was added to DC_SOURCE_CONFIGURATION_COMMAND_2, and if it is there, then it should also be reported in the CONFIGURATION_STATUS message.
One additional note on this.
One additional note on this. The spec currently states:
For batteries, State of Charge, State of Health, Capacity Remaining, Relative Capacity, and Full Capacity are related as follows:
Relative Capacity = State of Charge * State of Health
Capacity Remaining = Relative Capacity * Full Capacity
To match the chart below this comment in the spec, the formulas above are both incorrect. They should have been:
Relative Capacity = State of Charge / State of Health
Capacity Remaining = State of Charge * Full Capacity
Assuming that the reduction factor was added in, the updated section could look like:
For batteries, State of Charge, State of Health, Capacity Remaining, Relative Capacity, Present Capacity, Reduction Factor, and Full Capacity are related as follows:
Relative Capacity = State of Charge / State of Health
Capacity Remaining = State of Charge * Full Capacity * SOC Reduction Factor
Present Capacity = Full Capacity * State of Health * SOC Reduction Factor