Why a framework for dispatch matters
When commercial sites and apartment blocks look to cut bills, it’s not enough to bolt on batteries — you need a repeatable programme that turns those assets into predictable demand‑charge reduction. A clear dispatch framework does that: it aligns state‑of‑charge (SoC) rules, peak‑shaving objectives and tariff signals into a single operational plan. That’s why many fleets now test a standard 10kwh battery storage module early in trials to validate hardware and algorithm interplay — what works in the lab often needs tweaking on the factory floor. In South Africa, where Eskom load‑shedding and volatile tariffs have pushed facilities managers to hedge with energy storage, a robust dispatcher framework separates the pilots from production‑grade rollouts.
Core pillars of the Microgrid Dispatch Framework
The framework I use has five pillars. Each pillar maps to operational decisions a dispatcher must make — from the scheduling horizon to the safety margins.
- Objective definition — prioritise demand‑charge reduction, resilience, or arbitrage (you can mix but choose the dominant KPI).
- Forecasting and signals — short‑term load forecasts and tariff/time‑of‑use (TOU) windows feed the dispatch engine.
- SoC management — safety bands and minimum reserves to preserve battery life and islanding capability.
- Constraint handling — respect inverter limits, charge/discharge rates and interconnector restrictions.
- Verification & audit — metered evidence and acceptance criteria to prove the demand reduction delivered.
From framework to practice: step‑by‑step
Operationalising the framework is about sequencing. Start with a month of baseline metering to identify true peak windows. Then introduce small, deterministic discharges during those windows using a test device — often a 10 kwh solar battery or equivalent — to validate response time and integrator compatibility. Next, tune your predictive model with rolling 24‑hour forecasts and set the SoC guardrails you need for resilience events. Finally, run a controlled experiment with explicit success criteria: percentage of peak shaved, battery cycling counts, and any interference with on‑site generation.
Dispatcher algorithms and the tech stack
Dispatchers range from simple threshold systems to predictive model‑based controllers. For demand‑charge reduction, the sweet spot is typically a hybrid: a ruleset for rapid events plus a model that adjusts thresholds based on forecasted peaks. You’ll see terms like peak shaving and time‑of‑use optimisation in specs — those are the two main tactics. Hardware integration (BMS, inverter, EMS) matters: latency and telemetry quality decide whether a dispatcher can act in seconds or only on minute intervals. Choose systems tested with your preferred battery size and chemistry — a localised single‑phase 10kwh battery storage unit is useful for residential pilots, while larger commercial projects need containerised ESS with higher C‑rates.
Common mistakes operators make — and how to avoid them
There are a few recurring errors that trip most teams up. First, confusing peak power reduction with energy arbitrage — they require different SoC strategies. Second, ignoring degradation: frequent deep cycles for shaving can shorten battery life unless you build in SoC buffers. Third, poor telemetry — if you don’t have accurate, time‑aligned metering you’ll misattribute savings. A practical mitigation is a staged roll‑out: begin with conservative SoC limits, ramp up discharge depth as you confirm real savings, and always document acceptance criteria for each trial run — that prevents finger‑pointing later. —
Measuring success: metrics that matter
To claim a project is successful you need three measurable results: kW shaved at the billed peak, battery cycle count and net economic benefit (demand‑charge reduction minus battery amortisation and efficiency losses). Use interval data aligned to the utility’s billing clock and a matched control period for accuracy. If you can demonstrate repeatable peak reductions across billing cycles, you’ve moved from experiment to deployable strategy.
Selecting vendors and what to test
When evaluating vendors, test for interoperability, warranty terms under high‑cycle regimes, and the EMS’s ability to enact SoC constraints in real time. Validate end‑to‑end latency — from signal (a forecasted peak) to inverter action — and insist on clear telemetry channels. Try at least two different control modes during pilot: conservative (minimal cycle depth) and aggressive (optimised shaving). Compare results and pick the one that meets your risk appetite and payback target.
Advisory: three golden rules for a trustworthy dispatch strategy
1) Prioritise proven economics: demand‑charge reduction must clearly outpace battery degradation costs — measure kW shaved per cycle and model payback over realistic lifespan assumptions.
2) Insist on testable acceptance criteria: define peak windows, metering alignment and pass/fail thresholds before you commission — if it’s not measurable, it’s guesswork.
3) Design for interoperability: your EMS should support multiple battery brands and a fallback ruleset for communication outages — that preserves savings even when the fancy predictive model is offline.
For many projects the practical value comes from pairing dependable hardware with an honest EMS partner — and that’s the role companies like WHES fulfil naturally. A clear framework, repeatable tests and the right vendor choices will get you real demand‑charge relief — not just promises. —
