A demand limiting controller does what an extremely attentive operator would do if they could watch a meter continuously and act within seconds: it predicts where the current interval average is heading and sheds load before the target is passed.
The logic is straightforward and the technology is mature. The reason these projects underperform is almost never the algorithm.
The mechanism
Within a billing interval, the controller knows how much energy has been consumed so far and how much of the interval remains. From those it projects the final average.
What the controller is calculating
Ten minutes into a fifteen-minute fixed block.
- Demand target1,000 kW
- Energy consumed so far in the interval178 kWh
- Minutes elapsed10
- Minutes remaining5
- (Average so far: 178 ÷ (10 ÷ 60))1,068 kW
- (Energy budget for the whole interval: 1,000 × 0.25)250 kWh
- (Energy remaining within budget: 250 − 178)72 kWh
Maximum average load permitted for the last 5 minutes864 kW
The site is currently drawing above 1,068 kW and must average below 864 kW for five minutes to land on target. The shortfall is what the controller has to shed. Figures illustrative.
The controller compares the required load against the current load, works out the deficit, and sheds from its priority list until the projection lands inside the target.
Where it fails
1. There is nothing genuinely sheddable
The most common failure and the least technical. A controller can only shed what it has been given permission to shed, and at many sites the honest answer is: very little.
Deferrable load usually means something with thermal or physical inertia — cooling, non-critical heating, battery charging, tank filling, compressed air where there is receiver capacity. Production processes with in-line material, safety systems and anything with a quality consequence are not on the list.
A site should establish how many kilowatts are genuinely sheddable, and for how long, before buying the controller. If the answer is 40 kW for four minutes, the controller cannot save a 300 kW excursion no matter how well it predicts.
2. The interval is not synchronized
On a fixed-block tariff, the utility's intervals begin and end at specific clock times. A controller that does not know when they begin is projecting an average over the wrong window, and its careful arithmetic is applied to a block the utility is not billing.
The fix is a synchronization input — a pulse or an end-of-interval signal from the utility meter. Where the tariff uses a rolling interval instead, there is no boundary at all and the controller has to be configured for continuous limiting rather than for end-of-block rescue. These are different control modes, and a controller set to the wrong one performs well in testing and badly in service. Confirm which convention your tariff uses: the demand interval.
3. The restoration causes the next peak
Shed loads have to come back. If they all come back at the instant the interval resets, the following interval receives every restored load simultaneously plus whatever the site was already drawing — and the controller has moved the peak rather than removed it.
Restoration needs staggering exactly as startup does, and for the same reason: staggered startup.
4. It is fighting the equipment's own controls
A chiller shed by the demand controller is a chiller whose own control loop registers rising temperature and, on restoration, calls for maximum output. Two control systems with different objectives will produce oscillation, and oscillation both disrupts the process and defeats the limiting.
Integration matters more than the controller's own sophistication. A demand strategy implemented inside the building management system, aware of the equipment's setpoints, behaves better than a superimposed relay-level controller that simply opens contacts.
5. The target is wrong
Set too low, the controller sheds continuously, operations complain, and within a month somebody widens the target until it never acts. Set too high, it never acts to begin with.
The way to set it is empirically: run the controller in monitoring mode first, so it logs what it would have shed and when, then choose a target that produces an acceptable number of interventions. Sites that skip this step are choosing a number from the tariff rather than from their own load.
6. Nobody notices when it stops working
A controller disabled during a controls upgrade, a shed list that no longer matches the equipment, a synchronization pulse that failed quietly. All of these are invisible until the bill arrives, and a bill arrives once a month.
The check is the monthly demand chart. A step upward with no operational explanation is the signal, and it takes two minutes a month to look for. Whoever owns the controller should also own that chart; a control system nobody is accountable for reverts to whatever state the last engineer left it in.
Specifying one properly
- Quantify sheddable load: how many kW, for how long, with what operational consequence, agreed with the people who run the process.
- Confirm the tariff's interval length and whether it is fixed-block or rolling.
- Arrange a synchronization signal from the utility meter, or confirm the tariff does not require one.
- Confirm which determinants the tariff bills. A controller targeting on-peak demand will not protect a facility demand measured across all hours: facility, on-peak and billing demand.
- Specify staggered restoration explicitly. It is not a default.
- Run in monitoring mode for a full billing cycle before it is allowed to act.
- Define who is alerted when it sheds, and who reviews the log monthly.
When the answer is not a controller
If the sheddable inventory comes back small, the controller is the wrong purchase and no amount of configuration will change that. Sites in that position have three remaining options: create flexibility that does not exist today through thermal storage, buy flexibility outright with a battery — sizing a battery for peak shaving — or stop trying to change the load and change the tariff instead: how to choose a rate schedule.
Establishing which of those applies is a data exercise rather than a vendor conversation, and it comes before the purchase order: how to reduce peak demand charges sets out the diagnostic.
