Underpinnings for standardizing Demand Response (DR)

For decades, regulated electricity markets have struggled to deal with volatile energy markets providing to support un-caring customers. Customer’s real-time purchases, called load by the electricity industry, vary throughout the day, and more to the point, co-vary with external events. These issues are not limited to electricity. The “Super-Bowl flush”, which has reached the status of urban legend, names the stresses placed on urban waste water systems as external events synchronize demand.

Public Utilities Commissions defined tariffs to prevent the Super-Bowl flush for decades. Peak use can increase prices for a year. Tiered pricing increases the bill for any amount above a pre-set usage during a month. These approaches pre-date any discussion of smart grid—often they have effects contrary to those desired by the smart grid. The smart grid is smart in that it detects at any time whether there is too little or too much power available, and uses market signals to decrease or increase demand to match supply.

Early efforts at the smart grid focus solely on reduction. When the signal goes out to certain buildings, they reduce their load, or use of electricity, in a pre-defined way. We call this process demand response, and pre-eminent specification for this signal is called Open Automated Demand Response (OpenADR).

Demand response must be more than load reduction. The great wind farms of west Texas, the most successful farms in North America, are, I’m told, able to sell less than 40% of the electricity they generate. The wind generates electricity at times when no one is planning to use it. Even the most inefficient energy storage would be preferable to simply wasting the electricity.

The challenge now is to define signals that common across North America and the world, and that that handle energy surplus as well as deficit. This effort is underway in the OASIS Energy Interoperation Technical Committee.

One problem is that energy market operations have been restricted and confined, both by technology limitations and by public policy decisions. We have discussed DR as a one-way interaction, from utilities to customers. We have tied DR to special tariffs and to direct control systems. Each of these restricts the participants and innovation in DR.

On the Committee, we tried to place electricity in a normal market context. We identified four essential market activities, or services:

  1. There is an indication of interest (trying to flush out offers), when a market operator is seeking partners for a demand response or energy source.
  2. There is an offer of a service whether megawatts or “nega-watts”
  3. There is an execution of a contract (agreement to purchase / supply (b))
  4. There is a call for performance of the contract (c) at the price agreed upon.

We are defining these services so they can be combined to meet today’s tariffs. For example, one of today’s tariffs for interruptible power may offer a lower price all year in return for the right to shed load automatically up to six times a year. Under the Energy Interoperation model, this would be standing contract with 6 time-limited pre-executed response contracts. Automated Demand Response is merely a call for performance on existing contracts at the agreed upon price.

Another model, coming into use, is Price-based ADR. If we assume the traditional utility-centric model, we would see the utility publishing an indication of interest in buying DR at a given price. Business and buildings willing to respond would simultaneously offer and execute a contract to shed load. The performance could be called at the same time or later as contracted.

Emergency or "Grid Reliability" events could look left out by this approach. Grid Reliability events require mandatory participation in today’s markets. These could be set up as standing pre-executed options. A grid operator then need merely call for performance as in any other demand-limiting event.

In this way, we can build all the tariffs and markets out of a few low-level services.

Sometime soon, I will write about the requirements for a pricing service.