Back to Journal

Managing Charging Load Through the Evening Peak

Peak-hour load balancing cover

In October 2025, a pilot network operator received a formal notice from BESCOM (Bangalore Electricity Supply Company). It cited repeated breaches of sanctioned demand from 6 to 10 PM at a commercial property with a 22-unit AC charging bay in basement parking. The property's sanctioned load was 150 kW. On 11 days in September, measured 15-minute demand topped 155 kW, including two readings above 165 kW. Under the Karnataka Electricity Regulatory Commission tariff order and the site's supply agreement, demand above the sanctioned limit triggered an excess demand charge of 1.5x the standard rate on every kWh consumed.

None of the chargers exceeded rated capacity. The issue was simultaneous draw from all 22 units, adding roughly 22 x 7.4 kW = 163 kW to the building's baseline. The 150 kW sanction predated the charging bay, and nobody had formally requested an enhanced load sanction from BESCOM.

This pattern is common. Operators add chargers to existing properties without recalculating aggregate demand. A connection sufficient for the building alone becomes the constraint for the building and charging bay during peak hours.

Demand Charges in the Indian DISCOM Context

Most HT (high-tension) and LT (low-tension) commercial connections in India have two billing elements: an energy charge per kWh and a demand charge based on the billing cycle's peak 15-minute average kW. DISCOMs track that peak with a maximum demand indicator (MDI), which records the month's highest 15-minute average.

Demand charges differ by DISCOM and tariff category. For a typical commercial LT connection in Karnataka, they may account for 20 to 35% of the total electricity bill. Crossing the sanctioned demand limit adds penalties. When electricity is an operator's largest cost after property lease, managing demand charges directly affects revenue, not abstract grid citizenship.

This differs from load shedding, where the DISCOM curtails supply. Demand charges are a billing tool that favors steady consumption and penalizes sharp peaks. Spreading 163 kW of EV charging across 6 hours costs the same energy-wise as drawing it in 90 minutes, but the latter incurs much higher demand charges.

Why 6 to 10 PM Matters

The evening peak combines two effects. EV drivers returning from work or evening activities reach sites with depleted batteries and urgent charging needs. Session starts typically peak between 6:30 and 8 PM at most commercial and mixed-use sites. At the same time, HVAC and lighting loads approach their daily highs as buildings fill with returning occupants.

From a demand standpoint, 6 to 10 PM is when charger and building loads combine at their highest. If chargers draw 80 kW and the building uses 60 kW, the simultaneous peak is 140 kW. When utilization reaches 15 out of 22 chargers, chargers alone draw 111 kW, and the building load pushes the total beyond most commercial sanctioned limits.

Load Balancing as the Response

In OCPP, SetChargingProfile lets a CSMS send a ChargingProfile that caps a charger's maximum power. In OCPP 1.6, a ChargePointMaxProfile can run during set time windows. In OCPP 2.0.1, the smart charging functional block adds finer control, including site-level profile stacking.

For a 22-charger site with a 150 kW sanction and a 60 kW building baseline, peak-hour charging headroom is 90 kW, calculated as 150 kW minus 60 kW. Allowing for measurement variation, use 80 kW. Across 22 chargers, that gives 3.6 kW per charger during constraint hours. A 7.4 kW unit therefore loses 49% of its power. Charging a typical 40 kWh EV battery from 20% to 80% takes roughly 7.5 hours at 3.6 kW, versus 3.5 hours at 7.4 kW. Drivers expecting a full evening charge will notice.

Operators must manage this trade-off directly. Load balancing protects the DISCOM relationship and lowers the electricity bill, but lengthens sessions and can reduce driver satisfaction. The setting depends on site utilization. At 40% utilization, a soft power limit usually still meets most demand. At 80%, lower connector power lengthens sessions, delays connector turnover, and creates queues. At high utilization, demand-charge savings come at the expense of throughput.

Smart Throttle vs Hard Shutoff

Cutting power entirely to some chargers while leaving others at full output is a poor response to demand exceedance risk. It gives some drivers fast charging and others none. Zero-power connectors still count in utilization metrics while generating no revenue.

Proportional throttling is preferable: lower every active charger by the same percentage to remain within the demand envelope. All drivers keep charging at a reduced, non-zero rate, making complaints and refund requests less likely.

When evening demand is predictable, as it is at most commercial real estate sites on weekdays, a scheduled ChargingProfile is easier to maintain than a live response. Start it at 6 PM and end it at 10 PM. Validate the schedule for one week against peak-demand readings, then adjust if needed. Automation beats a manual intervention at 7 PM when conditions change.

The DISCOM Application Process

Software load balancing is an operational patch, not a replacement for the correct sanctioned demand from your DISCOM. If a charging bay regularly needs its full capacity, request an enhanced load sanction from BESCOM or another DISCOM. LT applications typically take 4 to 8 weeks and need updated electrical drawings showing the added load. The process is inconvenient, but operating below charger capacity indefinitely to fit an outdated sanction costs more over time under the demand charge penalty structure.

This does not mean load balancing software is a bad choice. It was built for a different constraint: temporary control while provisioning is corrected, plus fine-grained response to unusually high building load or unexpected driver demand. Both tools are necessary at a professionally operated charging site.

Kazam EV Platform

Work through this with your operator data

Book a session. We will walk through the platform against your actual use case.