BESS Dispatch Optimisation in India: From Forecast to Setpoint

Learn how a BESS EMS converts forecasts, contracts and equipment limits into feasible schedules and real-time setpoints for Indian projects.

By Madhusudan Chakrapani · Power Markets · 13 minute read

BESS Dispatch Optimisation in India: From Forecast to Setpoint

Optimisation must produce an executable instruction

A dispatch optimiser is useful only if its schedule can be executed by the battery, accepted at the grid connection and reconciled with the commercial obligation. A high theoretical revenue that ignores state of charge, auxiliary load, ramp limits or schedule rules is not an operating plan.

In a practical BESS EMS, optimisation connects five stages: forecast, constraints, objective, schedule and closed-loop execution.

Define the objective before selecting an algorithm

The objective may be energy shifting, renewable firming, peak reduction, capacity availability, deviation reduction, ancillary response or a combination. Each service has a different measurement interval, response requirement and opportunity cost. Multi-use operation requires an explicit priority and reservation policy; the same MW and MWh cannot be promised twice.

The Indian-grid BESS use-cases guide explains why location and contract determine which value streams are real.

Build a complete constraint set

At minimum, a schedule should respect:

Degradation should be represented in a way that matches the operating decision. A throughput charge is simple but may miss the effect of depth of discharge, C-rate, temperature and time at high state of charge. More detailed models should be validated against warranty definitions and field data.

Forecasts and uncertainty

Solar, wind, load and price forecasts should include issue time, horizon and uncertainty. The UrjaForecast platform provides these inputs; the optimiser still needs a policy for forecast error. Options include reserve margins, scenario optimisation, rolling re-dispatch and penalties for failing to restore state of charge.

Optimisation should run on a rolling horizon. As measurements and forecasts change, it recalculates the remaining plan without repeatedly reversing the battery for marginal value.

From schedule to site setpoint

The cloud or central optimiser typically sends a time-bounded schedule or target. Site controls validate it against current BMS and plant limits, then coordinate the PPC and PCS. Fast safety and equipment controls remain local. The cloud-edge architecture guide describes this separation.

Every interval should retain the requested setpoint, accepted setpoint, limiting reason and delivered response. Constraint reason codes—SOC high, SOC low, rack unavailable, temperature limit, point-of-connection cap—make under-delivery explainable.

Backtesting and acceptance

Backtest on time-aligned historical forecasts, prices, instructions and equipment states. Avoid perfect-foresight results unless they are clearly labelled as an upper bound. Compare the optimiser with a defined baseline and include transaction costs, losses, degradation and unavailable periods.

Acceptance tests should cover feasible schedules, missed data, extreme prices, unavailable racks, communications loss, manual override and reproducibility from archived inputs. Commercial teams should be able to reconcile an interval result without access to optimiser source code.

References