Smart charging implementation through SteVe -> Limiting charging current

[ashupani10]

Hi SteVe Team,

First of all, thank you very much for the prompt support in the Elvi EVBox connectivity thread which not only helped me solve the issue but also allowed me to get a lot of new insights on OCPP implementation. I have been using SteVe for my project for the past few days and I must say amazing work with the ocpp platform. It is really helpful for someone like me who is new to OCPP, Smart charging and EV charging and would like to try and develop hands-on things without commercial software. Thank you again!

Having said that, I come to you again with some more questions regarding the implementation of Smart Charging through SteVe.

1. Suppose I want to limit the charging power (say every 't' seconds) in real-time by taking into account the power limits of the line, existing load on the line, and present EV charging power, say with the help of a script. First of all, is there a way to extract the present EV charging power from the GetCompositeSchedule command?

2. Second, if I get the present charging power and the I calculate the allowed charging power with my script, how do I send this charging command every 't' seconds with the help of txDefaultProfile or txProfile or chargePointMaxCurrent options on SteVe?

3. Does this use case require changes in the source code of SteVe or is there an API?

4. Can OCPP handle such a use case?

I have been engaged in reading the ocpp 1.6 documentation and internet searches for some insights. Please let me know if I can refer to some other sources as a starting point. Thank you very much for your guidance and help.

Regards,

Ashutosh

[JeremyWhaling]

For point 1, use meter values sent by the charger. You can change the cadence of meter values using change configuration for meter value sample interval. Depending on the charging station, some (most?) will send power out, and/or current and voltage directly. The meter value "values" are called measurands, power into the vehicle under the name Power.Active.Import.

OCPP can handle such a use case as you describe, but I don't know if or how smart charging profiles are implemented in SteVe. Hope this helps!

[JeremyWhaling]

Forgot to add, you could also trigger meter values when you want them by using trigger message, but I don't know if Steve supports trigger messages.

[goekay]

hey @JeremyWhaling thanks for your valuable input!

@ashupani10 as a starter, please look at an earlier comment of mine and the issue referenced there.

in short: steve indeed implements charging profiles of ocpp. but they are not smart, because these are static: you can define profiles with time periods and associated charging rates. they do not dynamically react to real-time changes.

[ashupani10]

Thank you for your answers @JeremyWhaling and @goekay,

I have tried to implement @chuck-h Loadmanager for SteVe, but I am having some problems to implement it. I have asked him too in his fork. However, I wanted to ask if SteVe provides some API to interact with in order to send charging profiles and receive status notifications?

Thanks

[goekay]

However, I wanted to ask if SteVe provides some API to interact with in order to send charging profiles and receive status notifications?

no, it does not.

[ashupani10]

Thanks,

Would you happen to know the formal steps to set up the database in @chuck-h repository: https://github.com/chuck-h/SteVe-SC? I have mentioned the specific problems on his fork but I believe I am making a mistake in setting up. This looks very promising to my use case. If anyone happens to know about it, it would be really helpful. Thanks

[chuck-h]

This issue resurfaces a recurring discussion on "smart charging" with SteVe. In North America this is called "Electric Vehicle Energy Management System" (EVEMS) or "Electric Vehicle Load Management System". There may be other terminology in Europe and the rest of the world. EVEMS are recognized by the Electrical Code, and can allow a user to

• add an EV charger to an existing residence without upgrading the service size (because the car charges only when other house loads are low)
• install a group of EV chargers in a parking area, but install an electrical service and feeder sized at much less (e.g. 20%) of the total rated charging station capacity
• arrange that EVs charge when electric rates are low ("time of use" rates, TOU) or when encouraged by the utility ("automatic demand response", ADR).

The benefits in reduced construction cost and lower stress on the utility distribution system are significant and seem to be moving this practice into the mainstream. However the available commercial products are "closed" systems where the energy management controller only works with charge stations from the same supplier. OCPP enables open-system EVEMS.

The benefits of EVEMS come from algorithms which control which vehicles charge at which times and and which power rates (see references at end of comment). These algorithms vary among providers and use cases.

In previous issues (e.g. #520 #92), @goekay has expressed the firm opinion that EVEMS support is so use-case-specific that it is unreasonable for the SteVe project to invest time in any particular implementation. After all, any user is free to fork SteVe and insert new code supporting their version of energy management into it. In my mind, this is a pretty big undertaking, especially if one intends to keep up with improvements & bug-fixes from the upstream project. Sevket offered an outline for making extended versions of SteVe at #23.

Another approach is to build the energy management logic as a separate application which communicates with SteVe over an API. @goekay has considered this, too (#103), and finds it unattractive. I gather that the experience with maintaining https://github.com/RWTH-i5-IDSG/steve-plugsurfing became somewhat unpleasant. Maintaining a complete API for a project like SteVe is a big resource sink.

What makes sense to me (and perhaps others implementing small EVEMS) is to add a very limited set of APIs to SteVe, but no new logic. Energy management logic would be implemented in a companion application which communicates over the API. In working on a "proof of concept" at https://github.com/chuck-h/steve, I have these comments on the minimum API set for dynamic energy management.

• 1. We must have a facility to set current limit values from an external program (e.g. https://github.com/chuck-h/steve/commit/4498e88)

If the EMS has independent means of measuring current (e.g. current transformers [CT] on the individual stations and the main electrical service -- as in some commercially-available EVEMS) then feature i. is sufficient for a basic EVEMS scenario.

• 2. If SteVe is able to export station current data ("meter values") to the external application (e.g. https://github.com/chuck-h/steve/blob/master/src/main/java/de/rwth/idsg/steve/service/MeasurementExportServiceImpl.java), then a CT at the station is unnecessary. Many use cases will still require external CTs on the shared service wires.
• 3. It may be helpful for SteVe to export data from the startTransaction service which allows the EVEMS to associate the charge station with a user; the algorithm for optimally allotting time windows and power level among connected vehicles may need to know this.

I do not have the software expertise to make a robust implementation of this. However I would love to participate in a group effort.

Background information on EVEMS. The Power of Sharing Final.pdf https://www.csagroup.org/wp-content/uploads/CSA-RR_ElectricVehicle_WebRes.pdf

@followthebeast

[TLS1000]

we are also on the lookout for some ability to interact with STEVE from an EMS for smart charging, either for load balancing pupose, or for optimizing the use of renewable energy at any given time.

[retrocoder-78]

This is a great recap @chuck-h. Thinking a bit about SteVe and how 'smart' charging might fit into the project. While there are many use cases, which are most prevalent? What I keep running into over and over again (the most prevalent, most common use case I suppose) really revolves around 2 evse's and their need to power down when both are plugged in. Then when one is unplugged for the remaining unit to go back to full power. This is a very generic scenario that could be applied to many different use cases.

Given how generic that scenario is, this seems like a functionality that could be a framework within SteVe. Any further work outside of this generic scenario would be development outside of SteVe.

Variables,

boxid 1 and boxid 2

charge profile 1 (full power) and charge profile 2 (half power)

Status Notification, Available (unplugged) > Preparing (plugged in) > Charging (a transaction has started)

The logic would react given the confines of the box id's and the status notifications of those box id's.

Maybe I am missing something here. Or, there's more to the conversation I have not read?

Thoughts?

This issue resurfaces a recurring discussion on "smart charging" with SteVe. In North America this is called "Electric Vehicle Energy Management System" (EVEMS) or "Electric Vehicle Load Management System". There may be other terminology in Europe and the rest of the world. EVEMS are recognized by the Electrical Code, and can allow a user to

• add an EV charger to an existing residence without upgrading the service size (because the car charges only when other house loads are low)
• install a group of EV chargers in a parking area, but install an electrical service and feeder sized at much less (e.g. 20%) of the total rated charging station capacity
• arrange that EVs charge when electric rates are low ("time of use" rates, TOU) or when encouraged by the utility ("automatic demand response", ADR).

The benefits in reduced construction cost and lower stress on the utility distribution system are significant and seem to be moving this practice into the mainstream. However the available commercial products are "closed" systems where the energy management controller only works with charge stations from the same supplier. OCPP enables open-system EVEMS.

The benefits of EVEMS come from algorithms which control which vehicles charge at which times and and which power rates (see references at end of comment). These algorithms vary among providers and use cases.

In previous issues (e.g. #520 #92), @goekay has expressed the firm opinion that EVEMS support is so use-case-specific that it is unreasonable for the SteVe project to invest time in any particular implementation. After all, any user is free to fork SteVe and insert new code supporting their version of energy management into it. In my mind, this is a pretty big undertaking, especially if one intends to keep up with improvements & bug-fixes from the upstream project. Sevket offered an outline for making extended versions of SteVe at #23.

Another approach is to build the energy management logic as a separate application which communicates with SteVe over an API. @goekay has considered this, too (#103), and finds it unattractive. I gather that the experience with maintaining https://github.com/RWTH-i5-IDSG/steve-plugsurfing became somewhat unpleasant. Maintaining a complete API for a project like SteVe is a big resource sink.

What makes sense to me (and perhaps others implementing small EVEMS) is to add a very limited set of APIs to SteVe, but no new logic. Energy management logic would be implemented in a companion application which communicates over the API. In working on a "proof of concept" at https://github.com/chuck-h/steve, I have these comments on the minimum API set for dynamic energy management.

• 1. We must have a facility to set current limit values from an external program (e.g. chuck-h@4498e88)

If the EMS has independent means of measuring current (e.g. current transformers [CT] on the individual stations and the main electrical service -- as in some commercially-available EVEMS) then feature i. is sufficient for a basic EVEMS scenario.

• 2. If SteVe is able to export station current data ("meter values") to the external application (e.g. https://github.com/chuck-h/steve/blob/master/src/main/java/de/rwth/idsg/steve/service/MeasurementExportServiceImpl.java), then a CT at the station is unnecessary. Many use cases will still require external CTs on the shared service wires.
• 3. It may be helpful for SteVe to export data from the startTransaction service which allows the EVEMS to associate the charge station with a user; the algorithm for optimally allotting time windows and power level among connected vehicles may need to know this.

I do not have the software expertise to make a robust implementation of this. However I would love to participate in a group effort.

Background information on EVEMS. The Power of Sharing Final.pdf https://www.csagroup.org/wp-content/uploads/CSA-RR_ElectricVehicle_WebRes.pdf

@followthebeast

[kosli]

I just stumbled over this thread but also over the EVerest Framework of the Linux Foundation. -> "The primary goal of EVerest is to develop and maintain an open source software stack for EV charging infrastructure." Has somebody had already a look at it and how it could be combined/interoperate with SteVe?

[ahzf]

EVerest is on the charging station side, while SteVe is the charging station management system side.

[Anmirazik]

Has anyone tried implementing smart charging with everest ? Lets say for example to limit the amount of amps of the charging station to 10 A , how does the procedure of doing that thru steve using everest sil , has anyone tried that ? Thank you