The Problem Nobody Talks About
If you spend enough time in the control room or reviewing utility tariffs, you eventually realize that “Demand Response” (DR) and “Interruptible Load” are often used interchangeably by marketing departments, yet they are fundamentally different animals in the eyes of a protection engineer.
Marketing sells DR as a “virtuous partnership” where your facility helps the grid during peak hours. In reality, it is a contractual obligation to dump load. Interruptible load, conversely, is a blunt instrument—a binary state change that often carries severe penalties for non-compliance. The failure to distinguish between these two in your facility’s control logic leads to one place: the “oops” moment where your critical process trips because your SCADA system couldn’t distinguish between a voluntary market-based curtailment signal and an involuntary utility-directed load shed.
I recall a site in the Midwest where the facility manager signed up for an “Aggregated Demand Response” program. They assumed the aggregator’s software would gracefully ramp down their HVAC and non-essential lighting. They forgot that the utility’s underlying interruptible load contract—signed ten years prior for a rate discount—had a hard-wired undervoltage/underfrequency relay override that didn’t care about the aggregator’s “soft” signal. When the grid frequency dipped, the utility’s primary relay executed a hard trip on the main breaker. The facility lost two weeks of production because the automation system wasn’t designed to handle a sudden, uncommanded loss of power that followed a “polite” request to shed load.
Technical Deep-Dive
To understand the difference, we have to look at the hierarchy of control. Demand Response is typically a Market-Based Resource. It operates at the application layer of the grid’s control architecture. You receive a signal—often via API or a dedicated gateway—to reduce consumption. This is a negotiated, voluntary event where you have a “curtailment window” and, usually, a financial incentive.
Interruptible load is a System-Reliability Resource. It is physically or logically tied to the grid’s protection and control schemes. It is non-negotiable. If the grid operator triggers an interruptible load event, they aren’t asking for your cooperation; they are shedding load to prevent a cascading failure.
graph TD
A["Grid Reliability Event"] -->|"Frequency/Voltage Threshold"| B["Interruptible Load Relay"]
A -->|"Market Price Signal"| C["Demand Response Gateway"]
B -->|"Hard Trip / Contactor Open"| D["Critical Load Shed"]
C -->|"PLC/BMS Adjustment"| E["Soft Load Reduction"]
D -->|"Immediate Impact"| F["System Downtime"]
E -->|"Gradual Impact"| G["Operational Efficiency Loss"]
The technical threshold between these two often comes down to latency and protocol. DR signals usually travel over standard IP-based networks, susceptible to jitter and latency. Interruptible load signals are often hard-wired to the utility’s SCADA system or delivered via high-priority, low-latency teleprotection channels. If you are designing for demand-response-issues-in-smart-grid, you must ensure your local controllers can differentiate between these signals. A “curtailment request” should never be allowed to trigger a hard breaker trip if a soft-load shed is available.
Implementation Guide
For the senior engineer, the implementation of these resources requires a robust Energy Management System (EMS). You cannot rely on a single gateway to manage both types of load shedding.
- Segregate the Control Loops: Your PLC or distributed control system (DCS) must maintain two distinct registers for load shedding. The DR register should be mapped to variable-frequency drives (VFDs) and non-critical environmental controls. The interruptible load register must be mapped to your main distribution switchgear or critical sub-feeders.
- Protocol Verification: Ensure your DR gateway is not just a black box. If it’s using OpenADR, verify the security certificates and the polling interval. If it’s using a proprietary utility protocol, ensure you have a fail-safe that defaults to “stay closed” if the link drops, unless you are specifically in an interruptible load contract that requires a fail-safe trip.
- Hardware Interlocks: Never allow the DR signal to bypass your local protective relays. Even if the aggregator sends a “shed” command, your local relay settings (e.g., IEEE 59/81 over/under voltage/frequency) must remain the ultimate authority.
Failure Modes and How to Avoid Them
The most common failure mode is Control Loop Oscillation. If your DR system is configured to respond to price signals by shedding load, and that shed causes a local voltage fluctuation that triggers an interruptible load relay, you have created a positive feedback loop.
The “Ghost Trip” Scenario
I once audited a plant where the DR system was programmed to shed a large compressor bank when the price exceeded a certain threshold. The sudden loss of that reactive load caused a momentary voltage spike. The utility’s secondary protection relay—which was monitoring the feeder for interruptible load compliance—interpreted this spike as a fault condition and tripped the main. The plant went dark.
How to avoid this:
- Implement Hysteresis: Ensure your load-shedding logic has significant time delays and deadbands.
- Reactive Power Compensation: If you are shedding significant inductive loads, ensure your capacitor banks or STATCOMs are coordinated to prevent voltage transients.
- Sequence of Operations (SOE): Your SCADA system must record the SOE with millisecond precision. If you cannot distinguish between a DR shed and a utility-initiated interruptible load trip in your logs, you cannot debug the system.
When NOT to Use This Approach
Do not attempt to integrate interruptible load into your facility if your production process has a high Restart Penalty. If your equipment requires a long, complex startup sequence—like a large-scale chemical reactor or a high-precision manufacturing line—the financial cost of an unplanned trip due to a utility-initiated load shed will always outweigh the tariff discount.
Furthermore, if your facility’s electrical infrastructure is aging, avoid aggressive DR participation. Every time you cycle a large breaker or contactor for a DR event, you are accelerating mechanical wear. If you don’t have a formal predictive maintenance program for your switchgear, you are essentially trading future reliability for current cash flow.
Finally, if your facility lacks a dedicated, redundant communication path for grid signals, do not participate in automated DR. Relying on a standard office-grade internet connection to receive curtailment signals is a recipe for a communication timeout, which some utilities treat as a non-compliance event.
Conclusion
Demand response and interruptible load are not just financial line items; they are operational risks. The engineer’s role is to ensure that the facility’s internal logic is robust enough to handle both the voluntary requests of the market and the involuntary mandates of the utility. Treat every load-shedding signal as a potential system trip. If you design your control logic with the assumption that the signal might be wrong, delayed, or malicious, you’ll likely keep your plant running when the grid gets shaky.
*This article is intended for informational purposes only for experienced electrical engineers and equipment procurement professionals. All specific technical parameters, protocol compliance thresholds, and performance specifications mentioned must be independently verified against the applicable standard revision, equipment datasheet, and site-specific engineering studies before any design, procurement, or operational decision is made. GridHacker and its authors accept no liability for misapplication of the content herein.*
Hero image: Close up of an aircraft thrust lever.. Generated via GridHacker Engine.
