[Ovmsdev] MS_V_BAT_SOH

Fri May 25 09:55:10 HKT 2018

> If the car provides its own SOH value, then we should report it,

Yes. That fits in with our approach of trying to show remotely what the car is showing on it’s own screens.

> If the car does not provides its own SOH value directly, then maybe
> it's better not to fake it; just show whatever values are available.
> Or perhaps it could be user preference which value best serves their
> particular purpose: total capacity depletion, cell imbalance ...
> or some combination.

I think we can show our own value. Up to vehicle modules how ‘tunable’ this is. The working data should be shown (and that is what v.b.health is for).

We are seeing many Tesla Roadsters now start to experience battery failure. What is happening is that one or more bricks in the battery gradually limit its ability to take a charge. The displayed SOC falls, while the difference between SOC MIN and MAX increases. Cycling the battery makes things worse. With my current approach in the Tesla Roadster code, that should appear as a rapid reduction in the displayed v.b.soh. Very clear and easy to see for even a novice user.

> Having a way to report cell imbalance is a good idea, but trying to
> express it as two percentage values seems rather crude.
>  Also, the distribution of
> voltage values for the modules is often tightly grouped, with just a few
> outliers, so just picking the lowest and highest is a bit too simplistic.
> A better way would be to report all the cell voltage measurements
> directly, or at least some basic statistics (n, average, stddev).

I just eMailed a reply to Michael with my thinking on this. Fundamentally, regarding balance, the only two things that matter are the lowest and highest voltage levels. You can’t drain the pack lower than the sub-module with the lowest voltage, and you can’t charge it higher than the sub-module with the highest voltage. Balancing means draining all sub-modules above MIN until they reach that MIN. These are what we are trying to represent with sub-module soc MIN and MAX. Standard deviation, average, etc, are also desirable.

Regarding imbalance, and battery health, I agree that for more technically capable users (and for engineers/technicians working on the car), it is also useful to know the details of the imbalance. While standard deviation, average, etc, will help with that, fundamentally sub-module voltages are the most informative and we should definitively make those available if at all possible. But that is the detail. We still need something simple that an end user can grasp. Two numbers - lowest and highest - are pretty simple to understand. A single percentage indicator of health is even easier.

> The Leaf can
> report voltage for every cell, but (as far as I know) does not indicate
> the nominal voltage value (and I wouldn't be surprised if these differ
> between the three(?) generations of chemistry already in circulation), so
> converting each one to a % would be arbitrary.

Cell or sub-module? Or is a cell the same as a sub-module in the Leaf? The roadster, for example, has more than 6,831 individual battery cells but can only report 99 voltages (expressed as 9 bricks in each of 11 sheets, with each brick composed of 69 individual cells). Model S, X and 3 have a similar arrangement.

If we know how many sub-modules are in the pack, and their arrangement (serial, parallel), and we know the voltages of each sub-module, then surely we know the overall pack voltage, and the pack SOC? My eMail to Michael regarding this has more information on this approach.

> How widely are such detailed values available for other vehicles?

Fundamentally, these sub-module voltages must be available on all vehicles. Without it, the car can’t balance the pack.

On the Tesla Roadster, they are not shown on even the engineering diagnostic screens (but we have some idea how to find them directly on the ESS bus, as they are reportedly available to the engineering tools running on connected laptops). The Model S has them on the CAN bus.

We definitely need some way to make these available in a standard way. I’m not sure that vehicle metrics is the correct way for that, though. Just too many numbers (99 for Tesla Roadster, for example) and maybe not available real-time (need to poll for them). Perhaps a standardised command would be a better approach for this?

Regards, Mark.

> On 24 May 2018, at 10:28 PM, Robin O'Leary <ovmsdev at caederus.org> wrote:
> 
> On Wed, May 23, 2018 at 10:42:32PM +0800, Mark Webb-Johnson wrote:
>> What is MS_V_BAT_SOH used for?
> ...
>> Which is it?
>> An overall indication of battery health? 100% being perfect, and 0% a brick?
>> Or battery capacity (100% being a new car, and 50% being one who’s range is only half that of a new car)?
> 
> If the car provides its own SOH value, then we should report it, even if
> we don't know exactly what it means.  In some cases, it may be important
> for warranty claims.
> 
> For the Leaf, the BMS-reported SOH seems more complicated than just a
> percentage of new capacity; e.g. increased internal resistance and cell
> imbalance are also factors.
> 
> If the car does not provides its own SOH value directly, then maybe
> it's better not to fake it; just show whatever values are available.
> Or perhaps it could be user preference which value best serves their
> particular purpose: total capacity depletion, cell imbalance ...
> or some combination.
> 
> ...
>> Nissan Leaf uses:
>> StandardMetrics.ms_v_bat_soh->SetValue(ah / newCarAh * 100);
> 
> You may recall, we had a recent discussion in favour of changing the
> Leaf's ms_v_bat_soc and ms_v_bat_soh to report the values directly from
> the BMS.
> 
> We do now report SOC as both direct-from-car and scaled-to-new values
> in Leaf-specific metrics ("m_soc_instrument" and "m_soc_new_car")
> and we have a config preference for which one to copy to ms_v_bat_soc
> (defaulting to the instrument value).
> 
> We have not yet done that for SOH, but hopefully will do so soon, adding
> "m_soh_instrument" for the BMS value and moving the above calculation to
> "m_soh_new_car" .
> ...
>> Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack.
>> 
>> Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?
> 
> Having a way to report cell imbalance is a good idea, but trying to
> express it as two percentage values seems rather crude.  The Leaf can
> report voltage for every cell, but (as far as I know) does not indicate
> the nominal voltage value (and I wouldn't be surprised if these differ
> between the three(?) generations of chemistry already in circulation), so
> converting each one to a % would be arbitrary.  Also, the distribution of
> voltage values for the modules is often tightly grouped, with just a few
> outliers, so just picking the lowest and highest is a bit too simplistic.
> A better way would be to report all the cell voltage measurements
> directly, or at least some basic statistics (n, average, stddev).
> 
> How widely are such detailed values available for other vehicles?
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev