[Ovmsdev] BMS voltage series validity check

[Michael Balzer]

Everyone,

TL;DR: I've extended the BMS cell voltage processing to check for 
inconsistent / broken series and skip the deviation analysis and alerts 
on such.

After implementing the BMS cell sensor queries for the e-Up / Mii / Go, 
we got lots of cell alerts even on brand new batteries.

These were caused by a combination of a) our need to query each sensor 
value separately via OBD request, i.e. 84 (or 102 in case of the former 
model) OBD requests to retrieve the voltages, and b) the vehicle BMS 
probably not caring about taking a synchronized snapshot and holding 
that before beginning to overwrite the data with the next measurements. 
Or maybe it's actually got some snapshot/hold feature we just don't know 
how to use yet.

Either way, we're seeing the effect of sudden load changes on the cell 
voltages clearly within a series run, even though all 84/102 requests 
are done within a few milliseconds.

Example:



This is the effect of a low load being present when cells 1-27 were 
queried, and an increased load being present afterwards.

The cell deviation analysis would see a high deviation here e.g. on 
cells 15-17 and 75-77 and trigger an alert.

The green line shows the linear regression gradient. In case of a series 
like this, or vice versa (high → low load during query run), the 
regression gradient is a clear sign of an inconsistent series. We also 
see series like this:



In this case, the regression doesn't help. To cover these as well, I've 
added a test for a sudden offset in the stddev level from the previously 
observed average.

Note: the average is built as a running average with smoothing over 5 
samples. The first 5 series taken after a reboot will not be checked for 
deviations to get an initial average.

For both gradient and stddev deviation, thresholds can be defined. 
Defaults can be given by the vehicle (added to the 
BmsSetCellDefaultThresholdsVoltage() API call), and users may overwrite 
these as needed (these may need some more explanation though). The 
system defaults I've chosen from my tests are:

  * Max gradient: 10 mV (= voltage drop/rise over the full series)
  * Max stddev deviation: 10 mV

These may be wrong for batteries with drastically different sensor 
(pack) layouts.

I've also reinterpreted the warning & alert thresholds as "exceeding the 
stddev level" (used to be absolute deviations from the average voltage 
level).

The max. stddev deviation must not be chosen too low, or chances are we 
won't catch faulty cells anymore. If a faulty cell causes a high change 
in the standard deviation, it may cause the series to be considered 
invalid now. I assume a faulty cell will not fail completely within a 
measurement cycle, but degrade slowly over time. In that case, it should 
still be detected.

I've done some tests with artificial faults and seen some warnings 
getting triggered from actual data, so I think the defaults should work.

The gradient is published to a new metric (v.b.p.voltage.grad), which is 
also shown now in the battery monitor.

I've also added a configuration to enable logging the cell voltages on 
demand, so you can load your actual data series into a spreadsheet from 
a log excerpt. To enable logging, set config vehicle 
bms.log.voltage.interval to e.g. 1 to check for new data every second – 
it will only log the series when changed.

The logging feature is also available for temperatures, but temperatures 
are slow movers.

Please test and report any issues. If you see issues, please send me 
your voltage logs for analysis.

If you haven't had false alerts yet, chances are your BMS has a 
synchronized snapshot of the cell voltages. In that case, you can set 
the gradient and stddev deviation thresholds to some high values to 
effectively disable the validity check.

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/4fc1fe87/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lodpcigdbhlnjnmn.png
Type: image/png
Size: 25595 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/4fc1fe87/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abhfaaigmphlgaen.png
Type: image/png
Size: 23974 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/4fc1fe87/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/4fc1fe87/attachment-0001.sig>