Architectural re-think for load management

[chuck-h]

This project has been idle for a few years, but I have started thinking about it again.

The situation now

The basic architecture of this "EVEMS" (electric vehicle energy management system) is that SteVe manages the database of charge stations, users, etc. and handles all OCPP communications with the EVSE. A companion application, LoadManager, handles the logic of dynamically assigning a current limit to each active charging session. It is a goal to minimize the amount of modified code in SteVe.

One reason for this goal is that this author @chuck-h is intimidated by the scale of the SteVe code base and is not familiar with its coding style.

In the first iteration of SteVe-SC I chose to base the LoadManager on the same framework SteVe uses and to establish communication through custom APIs that I intended to write. This was a bad choice because of my unfamiliarity with SteVe's framework. I wrote a basic SteVe API to issue TxDefault profiles. No LoadManager development has happened.

A new plan I now intend to discard the existing java LoadManager and begin rapid prototyping its functionality in Python, which is more accessible to me.

The communication with SteVe will work on two levels.

1. In cases where a LoadManager decision requires OCPP commands to be issued or the SteVe database to be updated (e.g. dynamically setting a current limit) the existing API (https://github.com/chuck-h/steve/commit/4498e88) will be retained as a model.
2. In cases where a LoadManager decision requires information in SteVe's database (e.g. current meter readings), the existing API approach (https://github.com/chuck-h/steve/commit/cdbb7c325) will be abandoned. Instead, a read-only connection will be established with SteVe's database and the needed information will be read directly from it.

LoadManager should probably have a web interface for monitoring and management, but this is low on my priority list because I am not a web developer and for my in-house development I can work from the console.

[chuck-h]

I am collecting use cases for prototyping. If you are interested in implementing load management over OCPP, please find the closest configuration(s) in the attached document and reference it in this issue.

My @chuck-h application is most similar to Fig. E-4 in the attached document.

I have included these users because of past postings on the RWTH-i5-IDSG/steve project. Apologies if this feels like spam to you. @ashupani10 @TLS1000 @followthebeast @retrocoder-78

Note The document below makes a lot of references to Canadian electrical code, which is not specifically relevant to this question. However if you have any knowledge of electrical code requirements in other jurisdictions, that would be of interest to me.

EVEMS Annex E (CH) (rejected) Apr 28.pdf

[retrocoder-78]

This is great! With the landscape of 1.6J implementation on most evse's in the market place, automated load management would be of value! Very cool!

[TLS1000]

with automated charge-power management you can hit two birds with one stone: autoconsumtion of renewable energy,and load balancing so the circuit breakers don't trip. a real pitty that STEVE doesn't have a API or mqtt plugin. OCCP1.6J allows for realtime adjustment of chargepower though.

[retrocoder-78]

load balancing so the circuit breakers don't trip.

This piece is huge for running multiple evse's on single circuits. Now, from all my research into load sharing and charge profiles, a charge session (transaction) needs to stop, a new charge profile loaded, then start a new transaction with that new profile. Lets call this real time load management. I don't believe there's another way with 1.6J to accomplish load sharing. Maybe I am wrong. OCPP 2.0.1 is a different story. But, the overwhelming majority of OCPP 'compliant' evse's in the market are 1.6J....

A mqtt plugin / API would be awesome. But, I understand the scope of the Steve software. It's not trying to be anything to anyone and a rock solid implementation of OCPP 1.6J. And it really is very well done. With that said through, there is nothing stopping development of what you describe.... 🤔

[chuck-h]

@retrocoder-78 you can change current in the middle of a transaction, according to the OCPP 1.6 specification

@retrocoder-78 @TLS1000 Please note that the Steve fork in this repository already does implement an API for setting charging current, and it has passed a limited amount of testing with real hardware. (https://github.com/chuck-h/SteVe-SC/issues/4#issuecomment-825157936 )

As this project "re-awakens", I will be pulling from upstream and trying to stay current with the main Steve package. I don't know much about MQTT but I would be open to adding that interface to this project. Any volunteers to do the java coding?

[TLS1000]

I've also been digging into the OCCP1.6J spec and confirm you can change the charge profile while the charging session is in progress. If that is not possible, I call it 'dumb' charging :-). I have no JAVA coding abilities unfortunate.

[retrocoder-78]

I've also been digging into the OCCP1.6J spec and confirm you can change the charge profile while the charging session is in progress. If that is not possible, I call it 'dumb' charging :-). I have no JAVA coding abilities unfortunate.

Interesting. Just through Doing some testing with Steve, I would start a charge season and load a new profile. Not until that session had ended did the new profile take affect. And you could see that watching the log file and with get composite schedule.

Code can be written to monitor a transaction and adjust profiles base on a set of variables. So, the logic can be added. If anyone reading has seen a 1.6J evse change charge rate in real time without stop a transaction that would be interesting information....

[retrocoder-78]

@retrocoder-78 you can change current in the middle of a transaction, according to the OCPP 1.6 specification

@retrocoder-78 @TLS1000 Please note that the Steve fork in this repository already does implement an API for setting charging current, and it has passed a limited amount of testing with real hardware. (https://github.com/chuck-h/SteVe-SC/issues/4#issuecomment-825157936 )

As this project "re-awakens", I will be pulling from upstream and trying to stay current with the main Steve package. I don't know much about MQTT but I would be open to adding that interface to this project. Any volunteers to do the java coding?

Great information. I am going to look into this further....

[TLS1000]

https://www.oasis-open.org/committees/download.php/58944/ocpp-1.6.pdf

page 27, or browser-page 33

[chuck-h]

In this fork the current-limit API https://github.com/chuck-h/steve/blob/master/src/main/java/de/rwth/idsg/steve/web/controller/CurrentLimitController.java is hardcoded to use TxDefaultProfile type, and does a Clear Profiles before sending the updated one. I'm pretty sure I checked that this works dynamically in the middle of a charging session with my Delta AC Mini, but I can't double check it right now because my car is fully charged!

[retrocoder-78]

In this fork the current-limit API https://github.com/chuck-h/steve/blob/master/src/main/java/de/rwth/idsg/steve/web/controller/CurrentLimitController.java is hardcoded to use TxDefaultProfile type, and does a Clear Profiles before sending the updated one. I'm pretty sure I checked that this works dynamically in the middle of a charging session with my Delta AC Mini, but I can't double check it right now because my car is fully charged!

Very cool. Yes, took a look at the oasis document. I think it's possible during my testing I was not overwriting the same charge profile but with a reduced current for example. Therefore got a result that wasn't a real time change in current flow. Based on how the j1772 stand is written and how ev chargers (in the actual vehicles) operate, there's no reason why current couldn't change in the fly. I must have missed this in the ocpp documentation. So, am glad it has been brought up! 😊

[chuck-h]

FYI there is a more recent version of the ocpp1.6 standard (edition 2) available for download at https://www.openchargealliance.org/

[TLS1000]

Yes indeed very cool. But I'm a bit anxious using this forked repo because I don't see a lot of activity on it. Why is this not integrated into the STEVE master branch?

[followthebeast]

@chuck-h This is great. I think as a first attempt, what we can do is to assign the grid current limit manually. When a car arrives we send a charging profile, this can be added in the status notification response (when a car arrives, we can see the status turn to Preparing). This profile is based in the existing informations about the car who's already in a Charging Status and the limit of the grid. Also, make a loop every 20 seconds to check a smart charging strategy, for example if a car has been charged with more than 3kWh we Suspend the charging process by sending a charging profile to do that and at the same time we send a charging profile for another charge point that has been suspended (for example in status notification, if adding a charge point will exceed the value of current limit per phase, we set this charge point in hold whenever another charge point has offered more than 3kWh we put it in hold and start charging the first charge point).

This is one of the strategies that i can think about, but my programing skills are limited. I don't know really if i could help you.

[chuck-h]

Basic framework for load manager program to cooperate with SteVe https://gist.github.com/chuck-h/c6a430ee671d5d26e598d4ff31161c17 Proof of concept to be written in Python 3

We get the status of connected charging stations from SteVe's database (stevedb) We get the measured currents in the feeders from external measurements (e.g. via modbus) We collect all this relevant info into data structure oids We call @ashupani10 's scheduler (optimizer) to determine the charge station current limits for next time step Scheduler returns data structure oods Based on oods contents we issue commands to set new current limits by calling SteVe current limit API (the API part of this fork; it's not currently supported by the main SteVe branch)

[chuck-h]

@ashupani10 I've updated the gist at https://gist.github.com/chuck-h/c6a430ee671d5d26e598d4ff31161c17 with a vision of the data that would be provided to the scheduler/optimizer. What do you think?

[retrocoder-78]

@ashupani10 I've updated the gist at https://gist.github.com/chuck-h/c6a430ee671d5d26e598d4ff31161c17 with a vision of the data that would be provided to the scheduler/optimizer. What do you think?

Cool. Taking a look now. 😊

[ashupani10]

Sorry for the late reply @chuck-h, Have been completely busy all week. I will take a look and get back asap.

Thanks

[ashupani10]

Hi @chuck-h,

I read through the gist. I must say pretty organized and well thought out.

The general overview of the load balancing algorithms by differencing the loads from a limit looks good! Just to be sure, I am a bit confused regarding some terminologies used, if you could clarify on that then that would be great.

1. Could you please give me an example of Circuit and Load on Circuit? From what I understood, A circuit can have many loads connected to it like EVcharging loads from multiple charge points and other uncontrollable loads say like building loads, elvator etc. Am I correct?
2. Could please elaborate on the measured_amps and limit_amps and why do you use these statements : if Load has measured_amps: estimated_amps += measured_amps else: estimated_amps += limit_amps

I will also try to search and think of optimization routines that we could implement in the meantime.

Thanks and warm regards

[chuck-h]

@ashupani10 Here are some example system diagrams which may make it clearer.

In the first picture we have 10 controllable loads and 3 uncontrollable loads on one circuit (Garage Feeder circuit). The load manager (a.k.a. EVEMS = Electric Vehicle Energy Management System) is limiting the circuit load to 80 amps. (The circuit breaker is shown as 100 amps. In North America, electrical code usually allows only 80% of the circuit breaker rating as continuous loading.) There is an actual current measurement on the circuit (CT = Current Transformer), so the optimization can be based on actual current.

If there is no measurement, the optimizer must estimate the total circuit load. The controlled loads (EVSE) are reporting their internally-measured current draw, but for safety the system must assume that the uncontrolled loads are drawing their maximum rated values. In this example we assume the total rated uncontrolled load (lighting and ventilation) is 60 amps. The feeder circuit breaker is rated 175 amps, setting the circuit limit at 80% = 140 amps. The optimizer assumes that only 80 amps are available for EVSE.

Finally, this example shows a hierarchical ("multi-tier") arrangement in which one Circuit feeds two other Circuits. Thus each EVSE Load contributes to two Circuits (one Circuit with a 60 amp breaker and one Circuit with a 100 amp breaker).

[hackex]

Very interesting concept and implementation. So if I understand correctly, with this Steve fork, I can send Amp limits to OCPP 1.6 charging points. I am mainly interested in PV surplus charging but find load management use case as important as well.

Is it correct that this function worms already in this fork? So I install Chuck's fork of SteVe instead of SteVe and then I get some Smart Charging functionalities on top of all the other SteVe functions? How do I include MQTT messages to be used as Amp Limits to the charging point?

Thank you so much for the effort! Great project

[retrocoder-78]

Ah, this was the information I was looking for @chuck-h. Our projects slowed in the load management area. So, am getting back up to speed with all this. What's the current status of this project? Any comments?

[chuck-h]

I have done no work on this project since that gist last May. I probably won't pick it up again, either; here's the back story:

I live in a cohousing community (23 households) and started looking for a way to implement load managed EV charging several years ago, anticipating that we will have more and more residents with EV's. The stuff that was on the market was all proprietary, cloud-based, and involved ongoing subscription fees; that just didn't make sense to me. You know, "I could do that!".

This all changed last year when I discovered that a small Canadian company has designed a system that does what we need. The OCPP control is "beta" right now and we are an early adopter. So my motivation for working on this project has disappeared. The company is https://www.variablegrid.net/ .

For your amusement, here is the project that is currently soaking up my coding attention: https://github.com/JoinSEEDS . Save the world!! ;)

[retrocoder-78]

@chuck-h Really appreciate this information! So, is variablegrid doing what it needs to do in the way that you need it? Have you seen the ocpp portion for your needs or was it the black box solution that worked and you decide to just let it do it's thing? Still interested in a simple load management solution. Like you have mentioned, there's still no simple off the shelf opensource implementation to go with.

Appreciate the amusement. Glad your having fun! :)