How will this one differ from Charging.TimeToComplete?

Is it remaining time or time stamp it is supposed to continue?

TimeToComplete is related to ChargeLimit. And the one I have proposed is always related to full charge of current net capacity. I will add comment here.

What is the difference between "capacity" and "net capacity"? How come that it varies? I think a comment explaining difference would be good.

I think i did here mistake with naming.

This seesm something between a "technical" value (i.e. when wen the concept is, that the raw data is in VSS and an UI may want to modify how to represent it to the user), and a pure HMI info (e.g. when we modfelled somehwere else whether speed is displayed in km/h or mph)

For example, I guess charging to 100% is sort of a corner case, where most users probably charge to 90% or whatever default a vehicle has. And as a user (if that is what "displayed" means, I am interested when my charging process finishes (i.e 50%; 19%, 100%, "until I am ready to go again", whatever I have chosen in UI).

Maybe I misunderstood what is meant with this datapoint, but then I would still argue either the name or the description is wrong

Would not Charging.TimetoFull or something similar fit better Charging.Displayed does not say much what the signal contain

I have used same logic as we have for SoC. Current vs Displayed

One can argue that the term StateOfCharge is a well known characteristic of battery, i.e. if you see a signal name like Vehicle.Powertrain.TractionBattery.StateOfCharge.Displayed then quite many people would be able to guess what unit/range the signal has. I am not as sure that Vehicle.Powertrain.TractionBattery.Charging.Displayed is as easy to understand.

But we maybe should take a step back and look at the scenarios. We have Charging.ChargeLimit which indicates max-limit, like if we reach it charging shall stop automatically, and Charging.TimeToComplete is the time to that limit. In the meeting yesterday we rather talked about charging that shall continue after reaching the target, and two times/durations are needed, one for remaining time until target and one for remaining time until full. Now I assume that it is the "real" value we want to show - the reason for having two signals for StateOfCharge (StateOfCharge.Displayed and StateOfCharge.Current) is that by some reasons OEMs does not want to show the real value.

If we assume that we need to support two scenarios:

• The user/driver can specify a minimum limit. When charging has reached that limit the user will be informed in his app, but charging will continue
• The user/driver can specify a maximum limit (or it is decided by vehicle, possibly fixed at 100%). When charging has reached that limit the user will be informed in his app, and charging will stop.

Then we maybe need four signals (names can be discussed):

• Charging.ChargeLimit to be replaced with Charging.MinimumChargeLimit and Charging.MaximumChargeLimit
• Charging.TimeToComplete to be replaced by Charging.TimeToMinimumChargeLimit and Charging.TimeToMaximumChargeLimit

But which time that will actually will be shown in the vehicle or in the app may vary, I assume. If you just want enough charge to be able to drive home then I assume Charging.TimeToMinimumChargeLimit is what you are most interested in.

I think i will change setup and use existing time information with modification on ChargeLimit with default value to 100. Then it should cover use-cases.
@erikbosch but also your proposal is good with adding more signals. Maybe I can add those as well, I would not add TimeToMinimum as an actuator. It is hard to say what is the minimum for driver. Or you have some scenario in mind?

ChargeLimit is what customer defines as an input, actuator. e.g. 70%
TimeToMinimumChargeLimit I see as a value that could be proposed to customer, sensor.

Regarding:

The user/driver can specify a minimum limit. When charging has reached that limit the user will be informed in his app, but charging will continue

Would it make sense for the app to inform the user based on its own monitoring of the charge level, as opposed to pushing the decision and monitoring into the vehicle? What if there are multiple applications each with their own minimum and maximum charge limits for the same vehicle (two partners sharing a vehicle)?

If a limit is set using Charging.MinimumChargeLimit, what is the signal that is triggered by reaching this limit? As well, from what direction is this limit monitored? Charging (as implied by the name) or discharging (where the user may want to be informed when the charge level reaches this limit while discharging)?