This can be a long post, but this is something we at Batteritechnikum, KIT have been cooking up for a while now. I hope the community is the best place to approach other ESS control experts and get some feedback and also discuss pros and cons on what we think could be an Advanced ESS Control nature.
As of now, the ESS components are mapped with natures such as ManagedSymmetricEss, … This is actually perfect in terms of integration to a system, and also for controlling the ESS effectively, thanks to the ALLOWED_CHARGE_POWER, ALLOWED_DISCHARGE_POWER,… channels and its respective functions.
But when we want to implement some advanced forecast based algorithms to define operation stratergies on multiple ESSs together (parallel operation), things becomes a little complicated. I am writing this post keeping in mind a hirarchical control concept where we have: Unit commitment (runs once in an hour) → Economic dispatch (runs every 15min) → Realtime regulator (runs every OpenEMS Cycle) → ESS impl. So in this concept the target power point is finally defined by the Realtime regulator through the ESS impl, based on various decisions made by Unit Commitment and then slightly corrected/further optimized by Economic dispatch. Operation strategies ususally define when the system have to be switched on/off, and what could be its optimum operation point (not necessarliy Max charge/discharge power), what is the maximum/minimum energy/SOC the EMS takes in/out from the ESS (in a given optimization period such as 15min) and others. When i want to define all such parameters for each ESS and use them for controlling the system, as of now i must do it in a single code snippet, which makes my code so big that i dont wish to scroll anymore!.
I am a big fan of the modularity of OpenEMS, and how the natures enable modularity. So we came up with an idea why not make a nature to define these control parameters. In this way we can also break the advanced controller (Unit commitment + Economic dispatch + Realtime regulator) into individual modules and connect them through APIs/Natures.
Based on this we tried to note down what channels could be required for advanced control in addition to various channels available through multiple ESS natures of OpenEMS:
Online SOC limits
Channel to define Max and min allowed SOC
Interesting for precise Energy Optimization
Online power limits
As of now the power limiters are already available, but these are only Static Constraints.
What we propose is a channel that limis the max allowed charge or discharge power as per the optimization.
Operation state of ESS
Each ESSs are different and they have different operation states.
But we can in general define the following ?:
OFF : Ess is offline and needs start up to be able to be used.
STARTING_UP: ESS is starting up. It cannot be used for the moment
This could be 0 seconds for technologies such as lithium ion, but upto a minute for Redox flow batteries for example
STANDBY: ESS is not operating, but is ready and can accept a control signal
RUNNING: ESS is currently being opeated and can also accept new control signals
LIMITED: ESS is opeartable but limited due to activation of some static constraints
FAULTY: ESS has an error and cannot be operated at the moment
Priority of ESS: 1,2,3…
This i am not sure if this could be generalized for all applications, but could be interesting when it comes to power distribution among multiple ESSs.
To give an example: when there is PV surplus of 50 kW and there are 3 ESS with max charging capactiy of 20 kW each, then ESS with Priority 1 would receive 20kW, ESS with priority 2 would receive 20kW and ESS with priority 3 would receive 10kW.
We forsee that this priority would be set by the Unit Commitment
I would not be surprised if others have thought about something like this or have already implemented it. But i would be still happy to connect and discuss.
Maybe you have already found out what I am writing now, but maybe it helps you or others.
Re 2:
You can set constraints at runtime if your controllers write to the channels SET_ACTIVE_POWER_LESS_OR_EQUALS and SET_ACTIVE_POWER_GREATER_OR_EQUALS.
Re 4:
You can combine the ESSs to an EssCluster. When a power is set to the cluster, it will distribute the power to its ESSs. In the Ess.Power object (which is automatically generated), you can choose among some solver strategies, which determine how the cluster distributes the power. If you play around, maybe that helps solving problem 4. Or you can write your own solver strategy to solve it if you find time.
Thanks for your reply. I was hoping that someone has already thought/ was working on what i pointed out.
Point 2 → I knew these channels existed but somehow it slipped out of my thought process, that it already does what i wanted with online power limitation.
Point 4 → Thanks for the tip. After a quick search i found out the different Strategies that you mention. I think i can work out a new strategy based on my requirements here. Is there any example controller which works with ESS Clusters? I did a quick search but couldnt find something like that? Or are you working it out on a Fork? Would be really glad to know what you are working on in this area
Hi Laksh,
There is no particular controller for an ESS cluster (as far as I know), you simply take the existing ESS controllers, and the solver together with its strategy does the rest. For example (you can try that with simulated ESSs), you have three ESSs (ess0, ess1, ess2) and combine them to an ESS cluster (ess3). Now you activate the controller “Fix active power” and set 3000W to ess3 (the cluster), and choose the solver strategy “OPTIMIZE_BY_KEEPING_ALL_EQUAL”. Then ess0, ess1 and ess2 will all discharge with 1000W.
So generally speaking, the ESS cluster is treated like an ESS by the controllers.
I was working on the topic of the Priority of ESSs, which was the deciding factor for choosing the order in which ESSs must charged or discharged. The prioritizing was done based on the SoC of the respective ESSs in an ESS cluster.
The logic is to identify ESSs with low SoC and the ones with comparatively higher SoC, so that a better
Charging/Discharging will be executed on the individual ESSs within the ESS Cluster.
The first step was to categorize the cluster based on the maximum difference in SoCs between the ESSs.
The concept of Homogeneous and Heterogeneous Clusters was introduced to identify an ESS Cluster.
The ESS cluster with its individual ESSs having much lesser SoC differences is termed a Homogeneous Cluster in this logic.
And an ESS cluster with its individual ESSs having reasonable SoC differences will be taken as a Heterogeneous Cluster.
This above-mentioned categorization was done based on a pre-defined “Threshold difference SoC” value.
But, one thing here, as you said the code becomes bigger
I was working on a controller (Not solver strategy) which takes Ess cluster as input and this controller is configured as a priority controller.
This controller is almost the same as a “fixActivepower” controller which takes “ESS cluster” as a parameter and a static “Charge or Discharge power”,
But the difference (in my controller) also has the logic(i do not call it strategy) to distribute power to individuals Ess in the cluster, based on the calculated priority of the ESS.
Thank you @tsicking for pointing to the strategies. You are also right, that the ESS Cluster haves just like any other ManagedSymmetricEss. Internally the “EssPower” uses a linear equation system, that creates coefficients for:
Sum of ActivePower of all inverters
ActivePower of each individual inverter (Sum of three phases)
ActivePower L1/L2/3 of each individual inverter
… (the same for Reactive Power)
This file illustrates how the linear equation system is built:
After all Constraints are collected for one Cycle, the Solver executes and tries to distribute the power among the inverters according to the set Strategy.
The current approach works well in principle, but it also has some known limitations:
The equation system itself, all constraints and the target function can only be linear. We managed to model the MaxApparentPower as linear constraints, which is ok. But having a quadratic target function would be make it much easier to write proper target functions. Currently those are only following a naive approach.
EssPower only covers the power of Energy Storage Systems/Inverters. In future it should also cover other manageable loads like Electric Vehicle Charging Stations (EVCS).
The equation system is solved many times per Cycle at the moment. This is a problem when dealing with many ESS in a Cluster or when doing computationally intensive optimizations. We are discussing a way to optimize ‘long-term’ Schedules which covers e.g. 15 minutes periods and only do the concrete optimization in real-time.
Reffering to point 1 from my original post, i think this is already solvable. Maybe similar to how @Justin.Joseph has already did it, but more or less defining the power constraint by checking the SOC at the Unit Commitment and/or at the Economic Dispatch level. Then this constraint would have to be only added to the ESS with EssPower.addConstraint() dynamically during the run.
This was already closed. It can be done with SET_ACTIVE_POWER_LESS_OR_EQUALS and SET_ACTIVE_POWER_GREATER_OR_EQUALS
Reffering to my third point, this is maybe again specific for my scenario. The idea behind knowing these states were diverse. For example: intelligently shut down or switch on the systems according to the operation strategy, thus saving the standby consumption, etc.
