Automated Demand Response: Which Loads Are Safe to Flex Without a Human Watching

Photo by Dmitrijs Safrans on Unsplash.

Search “automated demand response” and the page that comes back is written for utilities, aggregators, and standards bodies. GridPoint explains what ADR is. The OpenADR Alliance documents its own protocol. Wikipedia has the history. A chiller vendor pitches ADR-ready controls as a product feature. Academic papers from Lawrence Berkeley and IEEE work through the grid economics. All of it treats the building as the far end of a signal path: the thing that receives an instruction and, in theory, acts on it. None of it asks the question that decides whether that instruction should be allowed to act on anything without a person checking first.

We covered the manual side of this question in demand side response: which loads a building can flex when a person decides, event by event, whether to respond. Automated demand response removes that person. An OpenADR signal arrives, a VEN client on the BMS receives it, and a load sheds, precools, or curtails on its own, with nobody in the building confirming it’s safe first. That’s the entire appeal of automation: no missed events, no manual scramble, faster response times that qualify for the better-paying fast-response programmes. It’s also why getting the underlying question wrong, is this specific load actually safe to shed right now, gets more expensive, not less.

This piece picks up where that one left off. Not what OpenADR is, the Alliance documents that precisely. Not how to enroll in an automated programme, GridPoint and the aggregators already cover that ground well. What has to be true about a load before it’s safe to let a standing automated instruction touch it unattended.

Automated demand response asks more of a building than manual DSR does

In a manual DSR event, a bad call gets caught. An operator sees the notice, checks the plant, and decides the chiller isn’t a good candidate today because it’s already running warm. The event proceeds without that load, or the operator flags it and moves on. The mistake, if there is one, stops at the point someone reviews it.

Automation removes that checkpoint by design. That’s the value proposition: the response happens in seconds, not in whatever time it takes a person to notice an event notice, log in, and act. But it means a load that’s marginal today, and fine to include on a day when someone’s watching, executes anyway on the day nobody’s watching, because nobody has to be. The same mistake that would have been caught once in a manual programme now repeats on every event until someone notices the pattern, usually after a comfort complaint or a process issue, not before it.

That’s the real distinction between manual and automated DR, and it’s not about which is better. It’s that automation changes what counts as sufficient evidence before a load goes on the list. A load that’s flexible most of the time, with occasional exceptions a person would catch, is a reasonable manual DSR candidate. The same load is a liability as an automated one unless the exceptions are also accounted for in the automation logic itself, not left for someone to notice.

OpenADR at a working level: what a VTN, a VEN, and a signal actually do

OpenADR (Open Automated Demand Response) is a communication standard, maintained by the OpenADR Alliance, that defines how automated DR signals are structured and exchanged. It doesn’t decide which loads to shed or how a building should respond; it standardises the messaging so a utility, grid operator, or aggregator on one side and a building’s automation system on the other can talk to each other without a custom integration for every pairing.

The model has two sides. A VTN (Virtual Top Node) is the signal sender, typically run by a utility, grid operator, or aggregator, and it issues events: a start time, a duration, a signal level or price, and usually an opt-out window before the response is binding. A VEN (Virtual End Node) is the signal receiver, a client running on or alongside a building’s BMS or energy management system, and it’s responsible for translating that signal into an actual local response, whichever loads its programming has assigned to that signal level.

What the standard leaves entirely to the building side is the harder part: deciding which loads that VEN should actually be allowed to touch, under which conditions, and with what confidence that touching them won’t cause a problem the signal itself has no way of knowing about. OpenADR moves the instruction reliably. It has no opinion on whether the instruction is safe to execute in a specific building on a specific day, and it isn’t designed to. FrostLogic doesn’t implement, run, or certify a VEN client; that’s BMS and automation-vendor territory. What Explore does is answer the question the standard leaves open.

Which loads are actually safe to automate, and which still need a human first

The load types worth automating are largely the ones already identified as flexible in demand side response, but the bar for automating one is higher than the bar for offering it manually once. A load is a good automation candidate when its flexibility holds across a range of conditions, not just the one day it happened to be tested.

HVAC precooling and setpoint flex automate reasonably well, provided the automation logic itself enforces the thermal buffer, not a fixed schedule that assumes the same buffer exists every day. A precool sized for a mild shoulder-season afternoon and left running unattended into a hot, fully occupied day borrows more thermal inertia than the building has to give back, and nobody catches it until the complaints start.

Non-critical process loads, VFD pumps with slack, batch compressors, equipment with real schedule flexibility, are often the best automation candidates precisely because a missed or wrong shed rarely causes anything worse than a schedule shift. Refrigeration defrost timing automates well within its usual minutes-scale window, as long as the automation checks current case temperature against the food-safety threshold before shifting, rather than shifting on a fixed timer regardless of where the case actually is.

Chiller sequencing needs more caution automated than manual. A lead-lag plant with confirmed headroom on the lag machine is a fine manual candidate on days an operator checks it. Automating that same shed means the automation has to know, every time, whether the headroom that existed during testing still exists today, under today’s occupancy and outdoor conditions, not assume it from a one-time evaluation. Loads tied to occupancy-linked ventilation, life-safety systems, or any process where interruption cost exceeds the flexibility payment stay off the automation list entirely, for the same reasons they’re off the manual DSR list in the first place.

Manual DSR versus automated, OpenADR-triggered ADR

Where FrostLogic’s evidence layer ends and automated dispatch begins

None of the above makes FrostLogic Explore part of the automated dispatch chain, and it isn’t built to be. Explore identifies which loads in a building are actually safe to automate, forecasts the impact of shedding them with confidence bounds, and evidences that decision so it holds up under conditions the initial test didn’t cover. That work runs on the same energy management software Explore already provides for a building’s everyday cost and consumption picture; automation readiness is one more question it answers, not a separate system bolted on for OpenADR specifically.

What Explore does not do is send an OpenADR signal, run a VEN client, trade flexibility into a market, or settle a DSR payment. That execution layer sits with the BMS’s own VEN client, and with the aggregators that run the market and dispatch side at a scale a sensor-analytics platform has no reason to try to duplicate, among them Drax, E.ON, Enel X, and GridBeyond, the same aggregators handling manual DSR enrollment. The handoff is the evidence: which loads, under what conditions, with what confidence. What an aggregator or a BMS vendor does with that evidence, wiring it into a VEN’s automation rules, structuring which signal levels trigger which loads, is their domain.

The same compliance overlap that applies to manual DSR applies here too, and arguably matters more: an automated shed that touches metered consumption feeding a sustainability or energy-performance disclosure doesn’t pause for anyone to notice the overlap before it executes. Where that intersection needs handling, it belongs with a building’s existing compliance work, not treated as something OpenADR participation introduces on its own.

FAQ

What is automated demand response?
Automated demand response (ADR) is demand response where a signal, usually sent by a utility, grid operator, or aggregator, triggers a building’s equipment to shed, shift, or curtail load automatically, without a person deciding in the moment. It’s distinct from manual or scheduled DSR, where an operator reviews an event notice and chooses whether to respond; see our piece on demand side response for that side of the picture.

What is open automated demand response (OpenADR)?
Open Automated Demand Response is a communication standard, maintained by the OpenADR Alliance, that defines how automated demand response signals are structured and exchanged between a grid-side sender (a VTN) and a building-side receiver (a VEN). “Open” refers to the standard being open and interoperable across vendors, not to FrostLogic’s role in it; FrostLogic doesn’t implement or certify OpenADR communications.

What are automated demand response programs?
Utility- or aggregator-run programmes that pay a building for automated participation, typically at better rates or faster response tiers than manual DSR because the response is contractually guaranteed rather than dependent on an operator acting in time. Enrollment and programme selection are handled by aggregators such as Drax, E.ON, Enel X, and GridBeyond, not by FrostLogic.

Does FrostLogic dispatch automated demand response signals?
No. FrostLogic Explore identifies which loads are safe to automate, forecasts the impact of shedding them with confidence bounds, and evidences that decision. It does not dispatch OpenADR signals, run a VEN client, trade flexibility, bid into grid markets, or settle DSR payments. That execution layer sits in the BMS’s VEN client or with an aggregator.

Which loads are safe to automate without a human in the loop?
Loads with headroom that holds across a range of conditions, not just the one day they were tested, for example non-critical process loads with genuine schedule slack, refrigeration defrost within its temperature margin, or chiller sequencing with confirmed lag-machine headroom. Loads where safety depends on a condition that changes day to day, occupancy-linked ventilation or a chiller already running hot, need a person checking before automating, not just before enrolling.

What’s the difference between manual DSR and automated ADR?
Manual DSR gives a person a window to review an event notice and decide whether to respond, so a bad call gets caught before or during the event. Automated ADR removes that check: a VTN signal executes a preprogrammed response the moment it arrives, every time, with no one vetoing a shed that turns out to be unsafe on that particular day.

Can an automated shed cause a comfort or safety problem if a load isn’t actually ready?
Yes, and the failure mode is worse than the manual equivalent because it isn’t caught in the moment. A precool pushed past the building’s thermal buffer, or a chiller shed sequenced without real headroom, produces the same comfort complaint or process disruption a manual mistake would, except it repeats automatically on every future event until someone notices and fixes the automation logic.

Do I need a BMS with an OpenADR VEN client already installed to use FrostLogic Explore?
No. Explore’s forecasting and evidence work runs on a building’s existing meters and BMS or sensor data independent of whether OpenADR is deployed yet. The VEN client question only matters once you’re ready to act on Explore’s findings by wiring an aggregator or BMS-side automation to execute the shed.