<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">a) Can we agree on a slightly different naming scheme?<br class="">I suggest adding an indicator for the cell level semantics to the "soc.min" and "soc.max" names, e.g.<br class=""></div></blockquote><div class=""><br class=""></div>Yes, something like that is better. I did consider it, but couldn’t come up with a good name.<div class=""><br class=""></div><div class="">These min/max limiting values are normal at some sort of sub-module level. Cells grouped into sub-modules, sub-modules grouped into modules, and modules making up the battery pack. Voltages are normally available at the sub-module level, not individual cell.</div><div class=""><br class=""></div><div class="">In the Tesla Roadster these are called cells, bricks, sheets, and ESS.</div><div class="">In the Tesla Model S/X/3 these are called cells, bricks, modules, and ‘pack’.</div><div class=""><br class=""></div><div class="">How about v.b.m.soc.[min|max] (with the ‘m’ denoting module)? Or is ‘cell’ ok, even though we are not really talking about individual cells but bricks/sub-modules?</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">b) What is the technical definition of the "soc.min" metric?<br class="">Normally I would expect "soc.min" to be identical to the overall pack SOC -- the Roadster certainly doesn't allow cells to be discharged below 0% SOC?<br class="">What are typical values for "min" and "max" in reference to the overall SOC and voltage?<br class="">I mean, if that's really a normalized cell voltage level, we shouldn't name it "soc".</div></blockquote><div><br class=""></div><div>Very good question. I wish I knew the answer. Here is an example from a Tesla Roadster:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">OVMS# metrics list v.b</span></font></div><div><span style="font-size: 18px; font-family: "Andale Mono";" class="">v.b.cac 156.988Ah</span></div><div><span style="font-size: 18px; font-family: "Andale Mono";" class="">v.b.health CAC 156.99Ah SOC 75% LIM 68% MIN 68% MAX 70%</span></div><div><span style="font-size: 18px; font-family: "Andale Mono";" class="">v.b.soc 75%</span></div><div><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">v.b.soc.max 70%</span></font></div><div><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">v.b.soc.min 68%</span></font></div><div><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">v.b.soh 95.1741%</span></font></div></div></blockquote><div class=""><div><br class=""></div><div>Firstly: SOC LIM vs SOC. In it’s diagnostics screen, the Tesla Roadster displays these as “<span style="font-family: "Andale Mono"; font-size: 18px;" class="">SOC: LIM 68% MIN 68% MAX 70%</span>”, separately from the SOC displayed to the user. I guess the user SOC is dependent on current mode (primarily standard or range), and the SOC LIM/MIN/MAX is normalised to always be in one mode? 68% vs 75% is about 10% which seems about right for standard vs range mode.</div><div><br class=""></div><div>So, let’s just concentrate on SOC LIM/MIN/MAX. SOC LIM is the limiting SOC. For a discharge, the limit is based on SOC MIN, and for a charge it would be SOC MAX. But I am not sure if SOC LIM tracks that, or just always shows the minimum? I’ve only really looked at it after a charge has been completed (discharge mode), but have never seen it show anything other than SOC MIN. Anyway, we don’t publish SOC LIM.</div><div><br class=""></div><div>Fundamentally, SOC MIN/MAX is supposed to give us an indication of the imbalance in the pack. That will limit how high the pack can be charged, and how low it can be discharged.</div><div><br class=""></div><div>The overall goal here is to come up with a standard framework into which all cars can fit (and we can display in the Apps in a standard way). Individual car modules can also produced extra information they have available, but that doesn’t have to apply to all car types.</div><div><br class=""></div><div>I suggest we start from the premise that the car is measuring voltage to determine SOC (a simplification, I know, but let’s go with it). So in a simplified ideal car with 100 cells in series making up the pack, and a voltage range 300v (empty) to 400v (full), that would result in 0% to 100% SOC. 350v would be 50% SOC. Let’s assume those cells are grouped into bricks of 10 cells (again in series) and we can measure those, so we’d end up with brick voltages of 30v to 40v. We can then determine 10 brick SOCs (30v or less is 0% brick SOC, 40v is 100% brick SOC, and 35v is 50% brick SOC). We can then determine brick SOC MIN and MAX, as well as LIM (depending on charging/discharging). So, I think the technical definitions are:</div><div><br class=""></div><div><ul class="MailOutline"><li class="">v.b.soc is the overall state of charge of the entire battery pack. It should show 0% for an empty, and 100% for a full pack.</li><li class="">A sub-module soc is the state of charge of an individual sub-module in the pack. It should show 0% for an empty, and 100% for a full sub-module.</li><li class="">v.b.m.soc.min is the sub-module soc of the sub-module with the lowest soc. This is the limiting factor for discharging. The SOC displayed to the user is based on this.</li><li class="">v.b.m.soc.max is the sub-module soc of the sub-module with the highest soc. This is the limiting factor for charging.</li><li class="">v.b.soh is an overall indicator for the health of the entire battery pack. It should show 100% for a new pack, and 0% for a completely dead and unusable pack. It should give some idea of the health, lifetime used, and degradation of the pack.</li></ul></div><div><br class=""></div><div>Does that work?</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 25 May 2018, at 12:59 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Mark,<br class="">
<br class="">
two questions…<br class="">
<br class="">
<br class="">
a) Can we agree on a slightly different naming scheme?<br class="">
<br class="">
I suggest adding an indicator for the cell level semantics to the
"soc.min" and "soc.max" names, e.g.<br class="">
<br class="">
<tt class="">v.b.cell.soc.min</tt><tt class=""><br class="">
</tt><tt class="">
v.b.cell.soc.max</tt><br class="">
<br class="">
…or abbreviated…<br class="">
<br class="">
<tt class="">v.b.c.soc.min</tt><tt class=""><br class="">
</tt><tt class="">
v.b.c.soc.max</tt><br class="">
<br class="">
That way we can add further cell related metrics (e.g. ".cnt",
".soc.stddev") in a consistent name space.<br class="">
<br class="">
<br class="">
b) What is the technical definition of the "soc.min" metric?<br class="">
<br class="">
Normally I would expect "soc.min" to be identical to the overall
pack SOC -- the Roadster certainly doesn't allow cells to be
discharged below 0% SOC?<br class="">
<br class="">
What are typical values for "min" and "max" in reference to the
overall SOC and voltage?<br class="">
<br class="">
I mean, if that's really a normalized cell voltage level, we
shouldn't name it "soc".<br class="">
<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 24.05.2018 um 04:20 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:14DBCC0C-DEF1-44E1-9A00-4EDC7CD9A93C@openvehicles.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Michael,
<div class=""><br class="">
</div>
<div class="">Thanks for the explanation. That makes good sense.</div>
<div class=""><br class="">
</div>
<div class="">Given that at least three vehicles support SOC MIN
and MAX, I’ve gone ahead and made standard metrics for those. I
haven’t modified all the vehicle modules to store them, but
think that can be done for at least Roadster, Kia Soul and Twizy
(and maybe Nissan Leaf). Can the maintainers of those modules
set appropriately? Should be very simple.</div>
<div class=""><br class="">
</div>
<div class="">I’ve also created a generic textual v.b.health
metric that can be used to record a textual indication of
vehicle health (perhaps the calculations behind v.b.soh). Very
vehicle specific.</div>
<div class=""><br class="">
</div>
<div class="">I’ve then modified the Tesla Roadster module to
store v.b.soc.min and v.b.soc.max, and to calculate v.b.soh
(based on %cac remaining x %soc inbalance). Maybe tune it later,
but I think it should give a pretty good rough indication of
health. That is all in an edge release ready to go out tonight.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 24 May 2018, at 12:12 AM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Mark,<br class="">
<br class="">
I introduced this originally, it's meant to be (1), the
overall indication of battery health.<br class="">
<br class="">
As the wikipedia article says, there is no general
industry definition on how to calculate this.<br class="">
<br class="">
On the Twizy, the SOH is given by the BMS, while the CAC
is calculated by the OVMS by monitoring the charge
process and counting coulombs. The BMS SOH is the
(normally invisible) limit for the usable capacity, as
the Twizy always shows a range of 0-100% SOC regardless
of the SOH. It's also the base for any warranty
replacement of the battery (if it's rented you'll get a
new one when SOH is below 75%).<br class="">
<br class="">
The BMS is proprietary and without any available
documentation, it's a complete mystery how it calculates
the SOH.<br class="">
<br class="">
While the capacity would normally be the major factor in
a SOH, the Twizy BMS (LG Chem) has actually other ideas
on this. For example it's been at 100% for the first
three years, then at 99% for another two years, while my
CAC value showed the actual degradation (long term
linear with cycles). It's then begun to drop rapidly
over a short period of time and is now close to my CAC
level. My cells are still pretty good balanced under
load as well as open circuit, the balance also degraded
more or less linearly. There are also no obvious
temperature indications that could explain the SOH
curve.<br class="">
<br class="">
<br class="">
Generally I recommend to use this for the value the car
provides, if any.<br class="">
<br class="">
If the car doesn't provide an SOH, any calculation that
fits…<br class="">
<br class="">
<blockquote type="cite" class="">
<ol class="MailOutline">
<li class="">An overall indication of battery
health? 100% being perfect, and 0% a brick?</li>
</ol>
</blockquote>
<br class="">
…will do.<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<div class="">Kia Soul seems to be closest to the
implementation I was thinking of. Find out the
difference between SOC LIM MIN and LIM MAX, and use
that as an indication of imbalance in the pack. But
Nissan Leaf seems to be more like (CAC/160)*100
(where 160 is the CAC for a brand new vehicle).</div>
<div class=""><br class="">
</div>
<div class="">Or should we just add SOC_MIN and
SOC_MAX if these are used in many cars? Or an
imbalance percentage?</div>
<div class=""><br class="">
</div>
<div class="">Or should we combine the both (so
CAC/160*100 gives us percentage capacity loss, and
SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the
pack, then we perhaps multiply the two together to
give an overall indication of health)?</div>
</blockquote>
<br class="">
If breaking down SOC into the peak min and max cell
values I suggest also adding the average and peak
standard deviation, plus either the average cell SOC or
the number of cells to derive that.<br class="">
<br class="">
Interior resistance of cells would be another option for
standard metrics of cell health, but seems to be rarely
available (and needs a reference).<br class="">
<br class="">
I've got the cell module voltages and temperatures on
the Twizy. I record their peak values and deviations
under load and calculate the standard deviation. This
monitoring shows only a minor difference against the
values I recorded five years ago. I'm pretty sure if I
also had the internal resistance, that would give a much
clearer image.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 23.05.2018 um 16:42
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:AB7F1501-2FBD-4944-82FC-65C086F87A5B@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div class=""><br class="">
</div>
What is MS_V_BAT_SOH used for?
<div class=""><br class="">
</div>
<div class="">For Tesla Roadster, as well as SOC, we
have SOC LIM MIN and SOC LIM MAX. I want to make
those available.</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Kia Soul seems to use:<br class="">
<br class="">
StdMetrics.ms_v_bat_soh->SetValue( 110 - (
m_b_cell_det_max->AsFloat(0) +
m_b_cell_det_min->AsFloat(0)) / 2 );<br class="">
<br class="">
</li>
<li class="">Nissan Leaf uses:<br class="">
<br class="">
StandardMetrics.ms_v_bat_soh->SetValue(ah /
newCarAh * 100);<br class="">
<br class="">
</li>
<li class="">Twizy uses:<br class="">
<br class="">
CAN_BYTE(5) on ID 0x424</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Which is it?</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">An overall indication of battery
health? 100% being perfect, and 0% a brick?</li>
<li class="">Or battery capacity (100% being a new
car, and 50% being one who’s range is only half
that of a new car)?</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">The definition here seems to lean
towards #2 (capacity related), but seems arguable:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none;
padding: 0px;" class="">
<div class=""><a href="https://en.wikipedia.org/wiki/State_of_health" class="" moz-do-not-send="true">https://en.wikipedia.org/wiki/State_of_health</a></div>
<div class=""><br class="">
</div>
<div class=""><b class="">State of health</b> (SoH)
is a figure of merit of the condition of
a battery (or a cell, or a battery pack), compared
to its ideal conditions. The units of SoH are
percent points (100% = the battery's conditions
match the battery's specifications).<br class="">
<br class="">
Typically, a battery's SoH will be 100% at the
time of manufacture and will decrease over time
and use. However, a battery's performance at the
time of manufacture may not meet its
specifications, in which case its initial SoH will
be less than 100%.</div>
<div class=""><br class="">
</div>
<div class="">As SoH does not correspond to a
particular physical quality, there is no consensus
in the industry on how SoH should be determined.
The designer of a battery management system may
use any of the following parameters (singly or
in combination) to derive an arbitrary value for
the SoH.<br class="">
<br class="">
<div class="">
<ul class="MailOutline">
<li class="">Internal resistance / impedance /
conductance</li>
<li class="">Capacity</li>
<li class="">Voltage[2]</li>
<li class="">Self-discharge</li>
<li class="">Ability to accept a charge</li>
<li class="">Number of charge–discharge cycles</li>
</ul>
</div>
<div class=""><br class="">
</div>
In addition, the designer of the battery
management system defines an arbitrary weight for
each of the parameter's contribution to the SoH
value. The definition of how SoH is evaluated can
be a trade secret.</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Kia Soul seems to be closest to the
implementation I was thinking of. Find out the
difference between SOC LIM MIN and LIM MAX, and use
that as an indication of imbalance in the pack. But
Nissan Leaf seems to be more like (CAC/160)*100
(where 160 is the CAC for a brand new vehicle).</div>
<div class=""><br class="">
</div>
<div class="">Or should we just add SOC_MIN and
SOC_MAX if these are used in many cars? Or an
imbalance percentage?</div>
<div class=""><br class="">
</div>
<div class="">Or should we combine the both (so
CAC/160*100 gives us percentage capacity loss, and
SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the
pack, then we perhaps multiply the two together to
give an overall indication of health)?</div>
<div class=""><br class="">
</div>
<div class="">Thoughts?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark</div>
<div class=""><br class="">
</div>
<!--'"--><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<!--'"--><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>