Oracle Utilities Support for Demand Response

Summary

Demand Response (DR) Programs are emerged as one of the keys to Smart Grid implementations. DR programs generally carry a financial incentive to customers to motivate their participation. The Incentives could either a special utility supplied service which requires participation in DR events or providing specific tariff which exposes the customer to fluctuations in wholesale energy prices.  DR is a crucial element of operating the smart grid as well as creating the value added services that lead to consumer efficiency, economic viability and grid reliability.

This paper explores the features and functionality provided by Oracle Utilities product suits to support Demand Response programs in Smart Grid implementations. This white paper is derived from the wealth of information pertaining to Oracle utilities product operational, implementation and administration manuals and various smart grid implementation case studies.

What is Demand Response

Demand Response encourages consumers to take set of actions to reduce their electricity consumption during peak load periods in response to economic signals or emergency requests from Utilities. Demand response programs are achieved by increased customer energy usage awareness, new rate struc­tures (real-time pricing, time-of-use, critical peak price and interruptible rates) and modern technologies such as smart thermostats and in-home displays.

Customers can decide what loads to control and for how long in response to an economic or price signals or special requests from utility. Demand response leads to reduction of consumer energy usage, increases system reliability, and supports infrastructure op­timization. It can also potentially defer the utility’s investment in energy generation.

Typical Demand Response examples are: Shedding load or shifting electricity usage to off-peak hours, reducing the duty-cycles of HVAC and water heaters and turning on the onsite back-up generation, etc.

Demand Response Enabling Technologies:

Advanced Metering Infrastructure (AMI): It is an integrated system of smart meters, communications networks, and data management systems that enables two-way communication between utilities and customers.

Distribution Automation: Distribution automation (DA) refers to an intelligent distribution system that is fully controllable and flexible to help operating the grid more efficiently. Utilities have been applying DA to improve reliability, service quality and operational efficiency. Now-a-days, DA is being applied to perform automatic switching, reactive power compensation coordination.

Load Controllers:  An outdoor computer installed next to a breaker panel and connected to appliances like air-conditioning units, clothes dryers, water heaters, and electric spa heaters. It measures the usage of power in the home and controls peak demand energy usage by defaulting to a preset level. As demand increases, the load controller shuts off lower priority appliances to maintain a user preset demand level.

Home Area Networks (HAN): A home network or home area network (HAN) is a local area network which facilitates communication among digital devices present inside or within the close vicinity of a home.
   
Home/Building Energy Management: Home energy management systems (HEMS) offer monitoring and control of selected devices for residential buildings to reduce overall energy usage.

Demand Response Programs

Demand response programs are designed to bring changes in customer’s electricity consumption patterns. Some demand response programs are implemented through approved utility tariffs or through contractual arrangements in deregulated markets by price variation over time to motivate customers to change their consumption patterns. This approach is termed price based demand response. Other demand response programs reward customers for reducing their electric loads upon request or for giving the program administrator some level of control over the customer’s electric equipment. These are termed incentive or event-based demand response.

DR programs are broadly classified according to the customer motivation methods (i.e., direct control or market price) and the criteria with which load reduction “events” are triggered or initiated (i.e., emergency or economic programs). The following program types are widely followed by the utilities based on price-based and event-based categories.

Program Type	What does it Mean?
TOU rates	Rates with fixed price blocks that differ by time of day. A well-designed TOU rate may encourage customers to make long-term investments that would reduce peak demands.
CPP (Critical Peak Pricing)	Rates that include a pre-specified extra-high rate which is triggered by the utility. It is in effect for a limited number of hours. Critical Peak Pricing is the rate structure designed to encourage reduced consumption during periods of high wholesale market prices or system contingencies by imposing a pre-specified high rate for a limited number of days or hours.
RTP (Real Time Pricing)	Rates that vary continually (typically hourly or half-hourly) in response to wholesale market prices.
Direct load control	Customers receive incentive payments for allowing the utility to have a degree of control over certain eclectic equipment.
Emergency demand response programs	Customers receive incentive payments for load reductions when needed to ensure reliability of the grid system.
Ancillary services market programs	Customers receive payments from a grid operator for committing to curtail load when needed to support operation of the electric grid (i.e., ancillary services).

    

How Demand Response Programs Works

Demand Response Programs are often outsourced by utilities to third-party providers called Aggregators or Curtailment Service Providers (CSP).  With the advent of the Smart Grid and its enabling technologies such as Advanced Metering Infrastructure (AMI) and Home Automation Networks, utilities are increasingly bypassing Aggregators and beginning to provide Demand Response services themselves directly.

Load reduction events are rare and are only called when the stress on the electric grid is significant. Demand Response Programs ask the consumer to stand ready to cater to such rare electrical crisis situations. In return, consumers are paid for their efforts based on the amount of energy saved during the DR period. 

The below steps depict how typical demand response program works.

1.       Install smart meters at customer’s premise to track electricity usage in real time. This is to collect and access interval data to verify the reduction in electricity usage during DR time period.

2.       Utilities or third-party providers will work with customer to develop load reduction action plans so that the customer is well-informed on future DR procedures.

3.       The electric grid experiences a crisis or predicts a shortage in supply for expected demand in near future.

4.       The electric grid operator or utility company alerts customer of the need for an emergency DR event.

5.       When an event is called, the utility will notify the customer and will implement the agreed load reduction action plan.

6.       Customer’s performance will be measured by the amount of reduction in electric demand from a calculated baseline. It will be measured against customer’s demand during peak hours from the previous year or average demand over the previous weeks, like days, etc.

7.       After the conclusion of the demand response season, customer will receive incentive payment for the kW reduced for all such DR event calls during the season.

Oracle Utilities Supports Demand Response:

TOU Rate: Rates with fixed price blocks that differ by time of day. Some Utilities do not consider TOU rates to be a dynamic demand response option because the rating periods and prices are fixed and utilities typically do not regard customers on TOU as a resource that can be dispatched similar to a generator when needed to support grid operations. A well-defined TOU rate might induce customers to make long-term investments that reduce peak demands.

TOU prices are designed to encourage consumers to shift energy use from high price periods (on peak) to lower price periods (shoulder peak and off peak).  They are developed as part of the Regulated Price Plan (RPP) for customers having smart meters. Oracle MDM provides the utilities as many as different views of the Time of Use Data for their analysis and decision making processes. 

The pictographs show Oracle MDM capability to analyze the energy consumption pattern of a customer with respect to different time of use periods and seasons (on-peak winter, off-peak winder, shoulder peak winter and holiday). The energy consumption with respect weather pattern (temperature data) of the customer’s geography could also be compared and analyzed.

As smart meters are capable of measuring the interval data, they are configured to records energy consumption of a customer at a defined regular interval (For example, every 60, 30 and 15 minutes). Oracle MDM has the ability to define different TOU (Time of Usage) codes to denote on-peak, shoulder peak and off-peak energy consumption. Using TOU mapping feature, the interval consumption are accumulated under the respective TOU category.  

Based on the interval data, MDM accumulates interval usages in to Pre-defined TOU bucket quantities. MDM uses usage groups and usage rule feature to compute TOU based usage when the billable usage is requested or needed by billing systems. 

The picture shows a 3-time (On-Peak, Off-Peak, Shoulder Peak) Usage Transaction generated by Oracle MDM. 

Billing system will apply fixed TOU based price for customer’s energy consumption. Oracle CC&B uses ‘Bill Factor’ feature to store fixed TOU price data. The accumulated energy consumption per each TOU bucket will be multiplied by the respective TOU price data to compute customer’s bill amount.

 

Oracle CC&B (v2.4) new rate engine uses calculation group and calculation rule feature to apply the fixed TOU bucket rate to the corresponding TOU bucket service quantities consumed by the customer.

The below CC&B bill segment calculation lines shows how the TOU billable usage received from MDM is multiplied by the fixed TOU price data to derive customer’s bill amount.

CPP (Critical Peak Pricing): Critical Peak Pricing is the rate and/or price structure designed to encourage customers to reduce consumption during periods of high wholesale market prices or system contingencies by imposing a pre-specified high rate or price for a limited number of days or hours.

When utilities observe or anticipate high wholesale market prices or power system emergency conditions, they may call critical events during a specified time period (e.g., 3 p.m.—6 p.m. on a hot summer weekday). The price for electricity during these time periods is substantially raised. Two variants of rates are applied in such cases: (1) where the time and duration of the price increase are predetermined when events are called, (2) where the time and duration of the price increase may vary based on the electric grid’s need to have loads reduced.

CPP Using Dynamic Option Type: Oracle MDM uses Dynamic Option feature to implement such demand response programs. Utility can define dynamic option types for Critical Peak Price, Ancillary Service, Interruptible and Demand bidding programs, etc.  

 

Dynamic Option:  Dynamic Options specify terms that override how usage is normally calculated, such as a critical peak period that affects the TOU based usage of interval consumption.

There are circumstances during which the rules for creating TOU map data might need to be calculated differently than according to the utility’s standard rules. Examples of this might include critical peak periods, curtailment requests or other demand response events. During these types of events, the TOU rules defined for a TOU map may be overridden. This is done through the use of dynamic options and dynamic option events.

Dynamic options allow flexibility for ad-hoc and special events that might impact how usage calculations are performed within MDM. For example, if a utility requests that its customers curtail their usage for a specific time period, a dynamic option and corresponding dynamic option event could be used to represent the curtailment request. During the time period of the curtailment request, usage might be calculated differently (with a different set of TOU periods), which in turn might impact how the customer's bill is calculated.

 

Dynamic Option Events: Dynamic Option Events are specific periods of time during which a dynamic option is applicable.

Examples of this might include critical peak periods, curtailment requests or other demand response events. During these types of events, the TOU rules defined for a TOU map may be overridden. This is done through the use of dynamic options and dynamic option events.A dynamic option may have many dynamic option events over time. Attributes used to define dynamic option events include the following:

Status: The status of the DR event  

Start Date/Time: The start time for the period during which the dynamic option is in effect 

Stop Date/Time: The stop time for the period during which the dynamic option is in effect

Dynamic Option and Dynamic TOU Map setup: Oracle MDM usage calculation rules can be configured to use a specific TOU maps for generating usage transactions. This TOU map data will be used when summarizing the interval data for each TOU period (On-peak, shoulder peak, off-peak).

 

TOU maps can also have dynamic options defined for them. These dynamic options will be used to override normal TOU map data creation for specific date/time ranges (defined as dynamic option events). Each dynamic option defined for a TOU map has a related alternative TOU map used to create TOU map data during the period of the dynamic option event. For example, assume a schedule defined for a TOU map template specifies that the period on weekdays from 10 AM to 8 PM falls into On-Peak. A dynamic option could be defined to overrides this for a certain period of time (specified in a dynamic option event) during which the period on weekdays from 4 PM to 7 PM falls into Critical-Peak (or some other TOU).

The Time period when the Demand response program is initiated is computed using a different TOU Map. This will override the normal TOU map and will use a different TOU Code (eg: Critical Peak) so that the billing system can apply a special (increased rate) for the energy consumed during the CPP event period.

Real time pricing (RTP): “Interval Meters” measure electricity usage in intervals usually every 60, 30 and 15 minutes period. As customers will be charged based on "Spot Market Pricing", they pay the more for electricity during peak hours of the day and pay less for electricity during the off peak hours. This is why it is important to understand interval data and be able to make informed decisions for load shifting and controlling the demand.

“Spot Market Energy Pricing” changes from hour to hour, day to night, from season to season, and for short periods in response to high levels of demand or sudden changes on the grid. Customers with an interval meter are billed for their interval energy consumption against the interval price, which is set hourly or half-hourly by the Independent Electricity System Operators (IESO). 

As demand increases, more expensive offers from generators are accepted, which raises the price of electricity. As demand drops, only the less expensive offers are accepted, which reduces the price. Customers are able to respond to changes in prices by shifting some of their demand to off-peak periods.

Oracle CC&B support the interval billing in two ways. (1) Interval Price data is loaded into Oracle CC&B on daily basis or at a specific frequency as they arrive from the operators. CC&B Interval data upload feature can be used to directly upload such interval consumption data into system and (2) Interval consumption data can be pulled on-demand from MDM when CC&B needs such data for billing computation. The customer’s bill amount will be computed by multiplying the interval energy consumption by the interval price data.

If interval consumption data is directly interfaced with Oracle CC&B, interval data set and interval data storage mechanism will be used to load and store them. If the interval data is pulled from MDM on-demand, then it will be stored as billable service quantities and used for customer’s bill computation.

Emergency Demand Response, Direct Load Control, Ancillary services market programs:  The utilities can have DR programs where customers can optionally participate, so that utility can declare a DR event for any upcoming time span or to response to an emergency situation. When a DR event starts, the system sends specific smart meter messages to turn off the customer's equipment. When the DR event concludes, the system sends another smart meter message to turn on the customer's equipment. The utility will measure the amount of consumption conserved during these events.

 

Oracle Utilities Smart Grid Gateway (SGG) enables two-way communication between utilities systems and AMI head end systems and any other smart device/network communication systems.  With Oracle SOA technology stack, new business processes can be easily implemented with minimal extensions.

Oracle SOA, BPM and BEPL enables orchestrating new business processes to send and receive demand response events and smart meter messages between Oracle Utilities SGG and AMI head end systems. This would give greater flexibility to quickly implement new DR events and customized two-way communication to be sent and receive from smart meters and sensor.

With the advent of latest AMI capabilities and/or SCADA real-time network monitoring feature at substation, feeder and distribution transformer level, health parameters of electrical network equipment could be monitored in real time. If any such parameters indicate that network equipment reaches its threshold limits (For example, a distribution transformer reaches 98% of its maximum load capacity), a real time event can be triggered at the transformer and it will be sent to SCADA or AMI system in real time. The events are intern forwarded to MDM / NMS for further investigation and appropriate action. 

Utilities systems (MDM and/or NMS) can analyze the real time event data coming from AMI and SCADA systems, and can take appropriate actions. For example, MDM can search the customers under a particulate distribution transformer who are enrolled to participate in Demand Response programs and could initiate relevant DR events to those customers. This would potentially help to control the load at the transformer and thus ensures the reliability of grid system.

Conclusion

The objectives served by Demand Response are:

Energy Efficiency programs reduce overall electricity consumption during peak demand periods.

Price response programs shift energy consumption from high price time period to lower price time period (real time pricing or time of use). This will help to address transmission distribution congestion management.

Peak saving programs (Critical Peak pricing) require more response during peak hours and focus on reducing peaks on high system load days or time period.

Reliability response (Emergency demand response) requires the faster and shorter duration response. Such Response is only required during power system “events.”