This guide explains how to implement smart charging backoffice using OCPP.
Smart charging infrastructure is becoming a cornerstone of modern electric vehicle (EV) ecosystems, enabling efficient and reliable charging for a growing fleet of electric cars. However, the complexity of developing a smart charging backoffice (also known as charger manager, dynamic load manager) can often appear daunting for Charge Point Operators (CPOs) and their development teams. This guide aims to simplify the process by focusing on the implementation of an average charging algorithm using the Open Charge Point Protocol, with an emphasis on practical steps and strategies for overcoming common challenges.
The essence of smart charging lies in its ability to manage the power flow to EV chargers, ensuring the sum of the chargers' power does not exceed a grid limit so more chargers can be installed on a given electrical connection. This guide introduces a simple yet effective algorithm: average charging. In this method, every charger is allocated an even share of the available power.
While this guide is written with reference to OCPP 1.6, OCPP 2.0.1 smart charging functionality is very similar.
This foundational strategy serves as a stepping stone to exploring more complex algorithms in future discussions. Time dependent grid limits, prioritization and energy cost optimization will also rely on some of these basics.
To implement smart charging the backoffice will manage the charging transactions, monitor the measured power each charger is using, and send ChargeProfiles to each charger specifying how much power it can use, so the sum of the power stays below a predefined grid limit. This process is repeated in a loop as vehicles arrive and depart, change their power demand and the grid limit changes.
At the heart of a smart charging system is the backoffice, which can be implemented in Python using the https://pypi.org/project/ocpp/ library. A minimal setup requires the server to support for several key OCPP commands:
- StartTransaction
- StopTransaction
- BootNotification
- MeterValues (crucial for control)
- Heartbeat
- Authorize
- StatusNotification
In practice, further functions will be needed for billing, maintenance and access control. The system must actively read MeterValues and manage transactions with unique IDs for smart charging. Running the smart charging algorithm itself can be triggered by new data or executed at regular intervals.
Initially, a very low power TxDefaultProfile should be set to prevent immediate charging when a vehicle connects, and preventing exceeding the overall grid limit, alternatively this could be included in the StartTransaction acknowledgement.
A very basic average algorithm would simply take the available power and divide it equally between all the running chargers without feedback. This won’t make the best use of the available power if one charger cannot use all the power it is allocated, since that power could be given to other chargers. A key design decision is whether to allocate power based on a percentage of need, of capacity, or distribute it evenly as shown here. The algorithm follows these basic steps:
1. Assess the requested power from each charger (see below)
2. Allocate an equal share of the remaining available power to each request, capped at the lesser of the remaining available power share or requested power for that charger.
3. Repeat 2 with any remaining available power which has not been allocated, until all the available power is allocated.
These power allocations can then be put into ChargingProfiles and sent to the chargers.
Chargers usually don’t report the requested power directly, so it needs to be estimated. Using an estimated requested power allows power to be reallocated quickly when for example one vehicle disconnects freeing up power for others. Once a ChargingProfile limit is set then it won’t be apparent if the vehicle could use more power than the limit if the limit is increased. The measured MeterValue will be either near or below the power set in the ChargingProfile. The requested power estimate for each transaction usually starts with the maximum power the charger can deliver, then is reduced as measurements show lower power use. It is possible that power acceptance can increase as a battery warms up. To allow for this increase the request limit should be set slightly higher than the measured power. If the charger power increases, the request and ChargingProfile will increase with each subsequent iteration when there is grid power available.
The maximum power a charger can deliver is a property of the charger. It is available in the device model in OCPP2.0.1. A simple trick to get the maximum power is to send a getCompositeSchedule request before any other profiles are set. According to the specifications, this should return a profile at the charger maximum power, though few chargers implement this properly. The maximum power could also be configured as part of commissioning the backoffice.
A critical aspect of smart charging is the sequencing of sending setChargingProfile commands. To avoid surpassing grid limits, it is vital to sequence the decrease power commands before any commands increasing power. If a command to increase power is sent before one to decrease power, there is a risk the grid limit is violated which could lead to throwing a breaker or getting a high peak demand cost penalty. Even if they are sent very quickly in sequence, there is a risk of a communication problem causing a charger not to accept a reduced power ChargingProfile. Depending on how critical the grid limit is, and your experience with the chargers you are using, you might provide an extra level of certainty by verifying the lower power output is confirmed via a MeterValue measurement instead of just assuming the charger follows the ChargingProfiles on acceptance. This is especially important for AC chargers which need to relay the power level to the vehicle itself, which then reduces the power consumption. Sending the decreasing power commands first, and waiting for the MeterValue to show the lower consumption will slightly reduce the power delivered, but provide much better certainty that the grid limit is not violated.
Repeatedly sending the same ChargingProfile if there is no change can cause excess wear on the charger memory. ChargingProfiles need to be written to flash memory in case the charger is reset. Flash memory usually has a finite cycle life, which could be approached over the lifespan of a charger with very frequent ChargingProfile updates.
Tools like ChargeSim eVirtuFleet can significantly speed up the development and testing process, providing a robust environment for refining smart charging solutions by letting you instantly start repeatable tests with multiple vehicles and chargers. It is essential to always do some checks with your real hardware since even standards compliant chargers sometimes behave differently.
Implementing a smart charging backoffice with OCPP does not have to be an overwhelming challenge. By starting with a straightforward average charging algorithm and incrementally addressing the complexities of power management, development teams can build a reliable and efficient smart charging infrastructure.
This is not intended as financial or technical advice and ChargeSim accepts no liability for actions taken based on it. Always consult a professional about your specific situation.