Parallel control by CSMS and EMS with OCPP 1.6J?

[colmgful]

Does anyone know of a solution to achieve parallel control by a CSMS and EMS with OCPP 1.6? This topology is supported in OCPP 2.0.1 as follows:

One possible solution would be to use the EMS as a proxy between the CSMS and Charge Point. However, this requires more complex OCPP handling on the EMS than simply implementing smart charging functionalities. Are there other approaches that can be taken? It seems waiting on adoption rates of OCPP 2.0.1 to improve will still not solve the problem for any chargers that will not support this newer version.

[proelke]

In the past when dealing with this issue, typically the CSMS would query/receive info from the EMS and set the charging profile of the charger to correspond with the desired charging rate.

[colmgful]

@proelke Are there any standard implementations of the comms between CSMS and EMS?

[proelke]

I think it depends on scope. You have OpenADR and another standard I am struggling to remember built around energy grids. At a local site level, I think it would depend on the EMS in use whether it would be modbus or some kind of REST API. The OCA is pushing OSCP but I don't think there is much traction with it.

[andcan86]

I think the OCPP protocol is not suitable for parallel control, even if they say so (both OCPP 1.6 and > 2.0 have several severe flaws to this respect). However, if the real Charge Point allows for >1 websocket connections, then nothing prevents you from instantiating two python clients pointing at the same physical CP and good luck.

If you do this because you are attempting smart charging..it can work under very special circumstances, but under real world circumstances it has no chance to work.

[splatch]

If you do this because you are attempting smart charging..it can work under very special circumstances, but under real world circumstances it has no chance to work.

I think it has chances to work cause EMS and CSMS are interested in different events. With a bit of work it is possible to route events to multiple participants. From EMS point of view you need to feed and update energy limit while CSMS is interested in authentication events (who) and meter values (how much). Complexity lie in keeping and coordinating update interval cause for smart charging controlled by EMS you will get high frequency updates while CSMS is fine with energy counter update every 5 or 10 minutes.

I haven't looked at OCPP 2 yet and what local proxy is, but looking at 1.6 and its events - it might fly.

[andcan86]

In the most simple case the EMS simply sets dynamically the max power to the wallbox in order to avoid local overloading of the domestic grid. On top of this, you can still integrate your wallbox with a CSMS/OCPP, but this is not "parallel control" in my opinion. The EMS rules first, and the CSMS/OCPP comes second. You can have a look at the flyer of the ABB Terra AC Wallbox, which explains more or less this (I declare no conflict of interest). On the contrary, the OCPP protocol allows the use of the "stackLevel" in the SetSmartChargingProfile, suggesting that there are many possible OCPP clients connected at once with a single wallbox. This part is what I believe is mostly flawed and unsound in the OCPP protocol for smartcharging (V 1.6, still have to check 2.0 and 2.0.).

[splatch]

In the most simple case the EMS simply sets dynamically the max power to the wallbox in order to avoid local overloading of the domestic grid.

That's indeed a point I am trying to make, the EMS can't control authentication but can issue available power to optimize ie. PV yield allocation. From what I found so far chargers are connecting to ocpp "server" hence they become clients and usually (by design) will have only one connection at the time. At the same time most of nowadays chargers are complex enough to support over-the-air updates so they have more communication and management interfaces, hence there might be a space for another one used by grid operator to somehow announce own things (this I haven't tracked and don't know much).

Because chargers do not care (much) of what ocpp server is doing, as long as it is behaving inline with the protocol, it makes possible to perform a bit smarter routing of messages. With some middle man between charger and rest of systems it is possible to implement functionality to communicate with management/billing system and and EMS at the same time. Its beside CSMS, charger and (probably) EMS as well and boils down to making an OCCP server which forwards requests from charger to two other servers. This I believe is described in 2.0 spec under "local proxy" section.

[andcan86]

yes, but at this point the CSMS has no idea of the "reserve of flexibility" related to its local resource, which is a little bit the point of doing smart control