Implement idealized battery

[AHaumer]

I would like to implement an idealized battery with no-load voltage dependent on state of charge and inner resistance. Such a simple model is used over and over again in (simple) models of electric vehicles. Furthermore, it could be a trigger to start developemnt of more advanced battery models with effects like:

• temperature dependency
• self-discharge
• RC-elements to model dynamic response on current peaks
• constructing a battery stack of series and parallel connected cells with different behaviour
• ageing
  The ElectricalEnergyStorage Library was intended to address these goals, but it has been overdone - the library is too complicated and it is not in a good state.
  As a starting point, I would place an "IdealizedBattery" in Modelica.Electrical.Analog.Sources.
  I have prepared a PR but I would like to discuss where to place the component.
  @christiankral , @christophclauss , @kristinmajetta what is your opinion?

[AHaumer]

For many tasks such a simple model would be sufficient, especially for teaching.
I've attached small lib (still based on 3.2.3) to give an idea.
Battery.zip

[AHaumer]

To start the discussion early ;-) with a positive argument:
Yes even such small enhancements and new models attract new users, helping them to solve their problems with low effort using Modelica (and nothing like Mb/Sk, ...). It also supports teaching and students working on their thesis. Therefore I don't judge such implementations as "contaminating the MSL with applications specific models".

[christiankral]

I am very much in favor of having simple battery models in the Modelica Standard Library (MSL). The proposed model is based on a table based OCV versus SOC curve. This makes a lot of sense for many applications. However, over and under charging the battery (SOC > 1 and SOC < 0) shall somehow be handled with asserts.

Additionally an even much simpler battery model might be included in the MSL, based on a purely linear OCV versus SOC curve. In this case a linear capacitor model can be used. Then the upper and lower voltage limit and the nominal charge of the battery determine the capacitance.

For now I can think of three places where such battery models can be placed:

1. Modelica.Electrical.Analog.Sources because this where I would look for an electric energy source
2. Modelica.Electrical.Analog.Batteries in case we want to distinguish ideal electrical sources from rechargeable batteries and we plan to include up to approx. 10 different battery models
3. Modelica.Electrical.Batteries in case we have plans to include more than approx. 1-10 models in the near future.

[AHaumer]

@christiankral the purely linear OCV versus SOC is included in the table based model; just specify two points for the table {0, 0; 1, 1}
The asserts should be triggered by the table, but you're right asserts with more specific text are helpful!
Battery overcharged (SOC > SOCmax) - Battery exhausted (SOC < SOCmin)

Where to place:

1. Modelica.Electrical.Analog.Sources is questionable if we get some more battery models
2. Modelica.Electrical.Analog.Batteries is fine for the simpler battery models (including self discharge, simple temperature dependency and RC-elements for dynamic behaviour).
3. Modelica.Electrical.Batteries is absolutely necessary for building stacks from cells, but it could inherit the simpler battery models from Modelica.Electrical.Analog.Batteries. This would take some time and resources, but it would enable work on cell balancing and similar topics.

So I'll create a PR for option 2. (Modelica.Electrical.Analog.Batteries) - ok?
Maybe by default a linear SOC-OCV-dependency with some explanations, including self discharge and an optional heat port, but no RC-elements yet.

[AHaumer]

see PR #2959

[christiankral]

@christiankral the purely linear OCV versus SOC is included in the table based model; just specify two points for the table {0, 0; 1, 1}

On my opinion it makes sense to have an additional model for the linear case. We also have a voltage source model for constant, step and ramp voltages, even though the a ramp model covers all three cases.

In order to avoid parameterization errors for new Modelica users the linear model shall have the addition parameter Vmin and the model could internally propagate {[0, Vmin / V0; 1, 1]} with fixed = true -- which already shows how easy it is to introduce parameterization errors...

[AHaumer]

ok implemented with Boolean parameter useLinearSOCDependency=true

[AHaumer]

I'm glad that we have these few models in MSL 4.
However, I got some result of two Master thesis at my University, and this ends in a meaningful extension of the battery model.
I would like to incorporate these extensions, too. However, now it seems to make sense to split off the Battery package from Analog and shift it (with the extensions) to Electrical.Batteries.
I'll come up with a PR.

[christiankral]

Yes, I think it is good that with some more elaborated models the package moves from Electrical.Analog.Batteries to Electrical.Batteries.

[saer1994]

Hi everyone, I' m trying to simulate BatteryDischargeCharge model but the following error occurs: "Error: Class or component 'extrapolation' not found in CombiTable1Ds combiTable1Ds". How can I fix this error?
Thanks in advance.

[AHaumer]

Which version of MSL? Which simulation tool?
Just checked with master and Dymola2021, works without any complaints.
Would be usefull if you open a new issue.

[saer1994]

Thank you for your quick response, I will open a new issue.