# Experiencing Commercialized Automated Demand Response Services with a Small Building Customer in Energy Market

Authors: Eun-Kyu  Lee
Journal: International Journal of Distributed Sensor Networks
 (2015)

---

## Abstract

An Automated Demand Response is the most fundamental energy service that contributes to balancing the power demand with the supply, in which it realizes extensive interoperations between the power consumers and the suppliers. The OpenADR specification has been developed to facilitate the service communications, and several facilities offer primitive forms of services in a retail market. However, few researches have reported the details of such a real-world service yet, and thus we are still unaware of how it works exactly. Instead, we rely on our textbooks to design next generations of the ADR service. To overcome the discrepancy of our understanding, this paper shares our hand-on experiences on the commercialized ADR service. In particular, we deploy smart submeters to manage energy loads and install an energy management system in a small commercial facility, helping the owner participate in the ADR service that a local utility offers. The building owner makes a service contract with a qualified load aggregator based on her curtailment rate, a reference point that decides the success of her load curtailment. With the rate, the customer facility participates in three DR events for tests that last for 2, 1, and 3 hours, respectively. Our experimental results are illustrated with discussions on various aspects of the service.


---

## Body

## 1. Introduction

In the current power grid, power suppliers often confront a shortage of power generation capacity during peak-demand periods. The only possible response is to shed electric loads on the demand side, which may cause blackouts. Such a sudden power outage has a huge impact on our economy and individuals’ activities. It is reported that the Northeast Blackout, which hit the Northeast United States in 2002, caused a loss of approximately $6.4 billion [1]. To cope with the shortage, the utility companies offer a Demand Response (DR) service that encourages customers to reduce their energy demand by sending signals, telling the status of the power supply side, to them. As of today, a utility operator calls contracted customers who, then, manually stop their building operations by expecting monetary incentives. However, such manual responses are inconsistent and will not efficiently work with the real-time power pricing that our future power infrastructure is going to adopt.The emerging Smart Grid proposes to resolve the challenge ofautomation in the DR service by leveraging interoperations amongst the service participants on top of information networks [2]. That is, a new Automated DR (ADR) service aims at automating the DR service, without manual intervention, by allowing a utility company (or Independent System Operator, ISO) to transmit DR signals to the customers through a communication network. When an energy management system in a customer facility receives the signals from the utility, it automatically performs a preprogrammed DR control strategy (shedding and shifting energy loads) to achieve the energy curtailment of a service contract. It is worth noting that the strategy is highly required to be invisible. Any control (e.g., turning off) on energy loads minimizes interference with ordinary building operations. Potential inclusion of Electric Vehicle (EV), energy storage, and renewable power generation in the customer facility will play an important role for the invisible DR strategy.To facilitate the ADR service, a communication specification was developed for the delivery of DR signals to customers, named OpenADR version 1.0 [3, 4]. Since its introduction, many research works exploit the specification to develop and demonstrate pilot services. The Lawrence Berkeley National Laboratory (LBNL) has also led many demonstration projects that show the impacts of the OpenADR on various types of customer environment [5–7]. Previous demonstration projects have shown the following properties. First, many of them target large customers such as tall buildings or data centers [8–10]. These facilities usually consume huge amount of energy in total and have solar panels inside generating power. Thus, energy savings from ADR services are distinctively measured under favorable conditions. Next, most projects have been led by large groups that often include national laboratories and local utilities [9, 11–13]. In the projects, a number of energy devices are installed under full control and deployed over large areas. The Pacific Northwest Smart Grid Demonstration Project [11] covers about 60,000 submeters and involves 11 utilities in five states from Idaho to Wyoming. System electricity assets handle more than 112 megawatts which cost approximately $178 million. Third, projects have developed their own testbeds for the main purpose of demonstrating performance of proposed algorithms and protocols [5, 7, 14, 15]. In this way, we have observed smart building testbeds especially on campus where researchers have some degree of controls over a variety of energy resources like lights, circuit breakers, solar panels, and so forth.Unlike previous research, this paper is more interested inpractical use of the ADR service. We first begin by asking a question “Can the ADR service run in my building or my neighbors’ so that the smart grid and the ADR can really benefit me?” To answer the question, we focus on two things. First, this paper examines the feasibility of the ADR in residential or small commercial sectors. As shown in Figure 1, small buildings are contributed to up to 97.5% of shares in the US, and thus we see their opportunities with respect to energy savings once they are well managed. A challenge is the fact that most of small buildings have never installed any energy management system that can run the ADR service. Intuitively, these buildings individually consume much less energy than that in large ones. One expects that energy savings from single small customer and corresponding incentives are small. There is no reason that a small customer installs an energy management system and runs the ADR service in its facility. In general ADR demonstration projects, this motivation factor may not matter much. From a practical market point of view, however, it is one of the most important concerns and still remains a nontrivial challenge. This paper investigates technical solutions for the challenging problem.Figure 1
Opportunity of energy management system in small buildings. 97.5% of buildings in the US are small having less than 5 stories. Most of small buildings have never had any functional energy management systems [41].Next, this paper examines preliminary configurations and setups that are done before running the ADR service in depth. Most previous research has studied the ADR service itself. But customers (or users) of the ADR service are more concerned about how much the service benefits people, which is affected by results from the preliminary processes. This paper records the processes step by step. Overall, procedures for our experiments shown in this paper look similar to those in many demonstration and pilot projects. We coordinate systems and devices required for an ADR service at a customer facility, process customer incentives, run pilot services in a retail market, and measure and assess the load curtailment. The authors in [7] collaborate with a local utility company to experience a commercialized ADR service as a pilot project with emphasis on installation and commissioning of the ADR systems. To validate the system, they present aggregated results from a large group of customers. On the other hand, our work experiences the service from a customer point of view. To this end, we work closely with one customer and identify what she wants to know: if she is eligible for the service, how she can reduce power consumption, how the reduction is measured, and how much she gets incentivized or penalized based on what measurement. To the best of our knowledge, no previous research projects provided microscopic measurements on an ADR service associated with individual customer in the real-world energy market. Throughout experiments and analyses, this paper tries to answer such questions that previous works could not address.The rest of the paper is organized as follows. Section2 reviews the OpenADR version 1.0 specification, which is followed by the description of our implementation of an ADR system in Section 3. We also demonstrate laboratory level experiments in which we deploy a full version of an ADR testbed and realize a dynamic pricing scheme so as to implement a Real-Time Pricing ADR service. In Section 4, we install the ADR system at a customer facility and validate it by participating in an ADR service that a local utility offers. Finally, we conclude the paper in Section 5.


## 2. Open Automated Demand Response

Following the success of the initial version of OpenADR, the OpenADR Alliance [16] is now developing the next version (version 2.0). Included in the Energy Interoperability (EI) [17], it provides several product profile specifications that describe specific implementation related information to build an OpenADR enabled device or system. Unlike the previous version, OpenADR version 2.0 is announced as an official standard for the ADR and includes a certification process to verify the compatibility of industrial products for seamless interoperation. Ghatikar and Koch summarize the evolution of the OpenADR specification from 1.0 to 2.0 in detail [18]. As of today, the OpenADR version 1.0 is a de facto specification, and many utility companies and ISOs in the world have widely adopted it for their ADR services. The utility company that supplies power to our customer also uses it which this section reviews briefly. We refer to [4] for more details.


### 2.1. System Architecture

The OpenADR version 1.0 technically defines communication interfaces and features of a Demand Response Automation Server (DRAS) to transmit DR signals and dynamic pricing in an ADR service. More specifically, it addresses how all the parties in the ADR, such as utilities, ISOs, energy managers, aggregators, and device manufacturers, communicate with and utilize the functions of the DRAS in order to achieve the automation goal of the ADR. Figure2 shows a system architecture that interfaces with the DRAS to manage the actual Automated DR events. The interface functions supported by the DRAS are classified into three groups: (1) utility and ISO function, (2) DRAS client function, and (3) participant function. A utility or an ISO interfaces with the first function through which it initiates and manages DR events and configures the DRAS to support the DR programs. The next DRAS client function supports both a PUSH and a PULL model of interaction that enable the DRAS and a DRAS client (in a customer building) to exchange information concerning DR events. The last function enables to configure participant-related data in the DRAS. For instance, the participant (a building owner or a facility manager on the customer side) may turn on an opt-out state, telling the DRAS that she will not be participating in DR events. Among the functions, this paper concentrates on the DRAS client function, because it actually delivers the contents of DR events and dynamic price to the customers.Figure 2
A system architecture of OpenADR 1.0 with components for the ADR service.


### 2.2. Event Model and Bidding Model

The specification illustrates seven use cases of DR programs, from Critical Peak Pricing (CPP) to generic Real-Time Pricing (RTP) based program [19], that fall into two general categories: event model and bidding model. The event model represents such DR programs that the DRAS transmits DR signals to the DRAS clients of the subscribed participants, when a power-related state on the power supply side changes. The bidding model allows participants to propose their energy capabilities (e.g., curtailment and generation) first to the utility. It automates the bidding and bid acceptance process by exploiting the DRAS functions. We note that this paper focuses on “event” for the ADR, while the scope of “bidding” is saved for future research.


### 2.3. Communications between DRAS and DRAS Client

In the event model, the DRAS transmits anEventState message that represents the state that a DRAS client is in with respect to a particular DR event (EventState is a DR event signal. All the data in OpenADR is represented as XML form, and their schemas are available at [20]). The message is exchanged between the DRAS and the client via two different modes of interaction, PUSH and PULL. In many situations, the client resides behind firewalls or private networks such as NAT, and thus the PULL mode is often preferred. In the mode, theEventState is “pulled” from the DRAS by the DRAS client. That is, the client initiates the DR communications.The DRAS is able to communicate with two different types of DRAS clients, smart and simple. A smart client denotes a system that is sophisticated enough to interpret all the detailed contents in theEventState message and to take actions based on the interpreted contents that associate with a specific DR event. For instance, it extracts power price information from the message directly and turns off building facilities accordingly. On the other hand, there are many cases where a simple DRAS client is needed. Such a client system is assumed to be incapable of processing a wide range of information types. To support the client, the DRAS translates the detailed DR event information into a simplified form and adds it to theEventState message.


### 2.4. Further Discussion of OpenADR

The OpenADR specification has been applied to many research works. The OpenADR protocol is applied to a microgrid system. Frincu et al. develop a campus-level microgrid that consists of heterogeneous energy equipment and an automated building control center [21, 22]. They implement the protocol to run numerous demand response scenarios. In a smart charging approach [23], an EV functions as a load to the distribution grid, a supplier of electricity to the grid, or an energy storage device. A utility company can manage EV charging time and rates, gather EV-detailed meter data, and, thus, implement ADR programs. Authors in [15] integrate communication protocols including OpenADR and IEC 61850 (International Electrotechnical Commission) into a Distributed Energy Resource (DER) system consisting of solar panels and energy storage units. Industrial ADR applications include an ancillary service. Alcoa company, a major consumer and supplier of electricity in the US, participates to an ancillary service in the Midwest ISO (MISO) wholesale market through control of smelter loads [10]. The company reported that revenues from ADR participation allowed paying back the cost of the system (of around $700,000) in 4 months. Some case studies related to Smart Grid pilots and potential ADR programs in the US with quantitative results and metrics are available in [24].There are many research efforts that enhance the OpenADR protocol. Authors in [25] resolve a communication delay problem that occurs when an aggregator gathers power curtailments from a large number of facilities within a few minutes. They propose to use the TRAP push-notification method of IEEE 1888 facility information access protocol. With the proposed solution, a DRAS pushes an occurrence of specific event for which the “TRAP” has been previously set by each client. Wajahat and Kim reduce the network delay in a different manner [26]. They propose to use an XML interchange (EXI) instead of XML. By replacing text-based XML messages with binary representation of the same XML, it is possible to decrease the message size. The OpenADR can run in bandwidth constrained systems. Gökay et al. [27] investigate if the OpenADR protocol can interoperate with other communication protocols. In order to connect the OpenADR to MIRABEL (Microrequest-Based Aggregation, Forecasting, and Scheduling of Energy Demand, Supply, and Distribution), authors propose a mapping logic that maps messages from different protocols so as to flow their operations seamlessly. Security and privacy issues have also caught researchers’ attention. Adversary models based on the OpenADR specification are identified and used to examine that security and privacy goals defined in the specification can be achievable [28]. Research in [29] analyzes security weaknesses in the open source software of OpenADR. The authors use a LDRA testbed tool (http://www.ldra.com/en/software-quality-test-tools/group/by-product-module/ldra-tool-suite) to detect software vulnerabilities that violate secure coding rules of CERT Java and network vulnerabilities that allow data modification.


## 2.1. System Architecture

The OpenADR version 1.0 technically defines communication interfaces and features of a Demand Response Automation Server (DRAS) to transmit DR signals and dynamic pricing in an ADR service. More specifically, it addresses how all the parties in the ADR, such as utilities, ISOs, energy managers, aggregators, and device manufacturers, communicate with and utilize the functions of the DRAS in order to achieve the automation goal of the ADR. Figure2 shows a system architecture that interfaces with the DRAS to manage the actual Automated DR events. The interface functions supported by the DRAS are classified into three groups: (1) utility and ISO function, (2) DRAS client function, and (3) participant function. A utility or an ISO interfaces with the first function through which it initiates and manages DR events and configures the DRAS to support the DR programs. The next DRAS client function supports both a PUSH and a PULL model of interaction that enable the DRAS and a DRAS client (in a customer building) to exchange information concerning DR events. The last function enables to configure participant-related data in the DRAS. For instance, the participant (a building owner or a facility manager on the customer side) may turn on an opt-out state, telling the DRAS that she will not be participating in DR events. Among the functions, this paper concentrates on the DRAS client function, because it actually delivers the contents of DR events and dynamic price to the customers.Figure 2
A system architecture of OpenADR 1.0 with components for the ADR service.


## 2.2. Event Model and Bidding Model

The specification illustrates seven use cases of DR programs, from Critical Peak Pricing (CPP) to generic Real-Time Pricing (RTP) based program [19], that fall into two general categories: event model and bidding model. The event model represents such DR programs that the DRAS transmits DR signals to the DRAS clients of the subscribed participants, when a power-related state on the power supply side changes. The bidding model allows participants to propose their energy capabilities (e.g., curtailment and generation) first to the utility. It automates the bidding and bid acceptance process by exploiting the DRAS functions. We note that this paper focuses on “event” for the ADR, while the scope of “bidding” is saved for future research.


## 2.3. Communications between DRAS and DRAS Client

In the event model, the DRAS transmits anEventState message that represents the state that a DRAS client is in with respect to a particular DR event (EventState is a DR event signal. All the data in OpenADR is represented as XML form, and their schemas are available at [20]). The message is exchanged between the DRAS and the client via two different modes of interaction, PUSH and PULL. In many situations, the client resides behind firewalls or private networks such as NAT, and thus the PULL mode is often preferred. In the mode, theEventState is “pulled” from the DRAS by the DRAS client. That is, the client initiates the DR communications.The DRAS is able to communicate with two different types of DRAS clients, smart and simple. A smart client denotes a system that is sophisticated enough to interpret all the detailed contents in theEventState message and to take actions based on the interpreted contents that associate with a specific DR event. For instance, it extracts power price information from the message directly and turns off building facilities accordingly. On the other hand, there are many cases where a simple DRAS client is needed. Such a client system is assumed to be incapable of processing a wide range of information types. To support the client, the DRAS translates the detailed DR event information into a simplified form and adds it to theEventState message.


## 2.4. Further Discussion of OpenADR

The OpenADR specification has been applied to many research works. The OpenADR protocol is applied to a microgrid system. Frincu et al. develop a campus-level microgrid that consists of heterogeneous energy equipment and an automated building control center [21, 22]. They implement the protocol to run numerous demand response scenarios. In a smart charging approach [23], an EV functions as a load to the distribution grid, a supplier of electricity to the grid, or an energy storage device. A utility company can manage EV charging time and rates, gather EV-detailed meter data, and, thus, implement ADR programs. Authors in [15] integrate communication protocols including OpenADR and IEC 61850 (International Electrotechnical Commission) into a Distributed Energy Resource (DER) system consisting of solar panels and energy storage units. Industrial ADR applications include an ancillary service. Alcoa company, a major consumer and supplier of electricity in the US, participates to an ancillary service in the Midwest ISO (MISO) wholesale market through control of smelter loads [10]. The company reported that revenues from ADR participation allowed paying back the cost of the system (of around $700,000) in 4 months. Some case studies related to Smart Grid pilots and potential ADR programs in the US with quantitative results and metrics are available in [24].There are many research efforts that enhance the OpenADR protocol. Authors in [25] resolve a communication delay problem that occurs when an aggregator gathers power curtailments from a large number of facilities within a few minutes. They propose to use the TRAP push-notification method of IEEE 1888 facility information access protocol. With the proposed solution, a DRAS pushes an occurrence of specific event for which the “TRAP” has been previously set by each client. Wajahat and Kim reduce the network delay in a different manner [26]. They propose to use an XML interchange (EXI) instead of XML. By replacing text-based XML messages with binary representation of the same XML, it is possible to decrease the message size. The OpenADR can run in bandwidth constrained systems. Gökay et al. [27] investigate if the OpenADR protocol can interoperate with other communication protocols. In order to connect the OpenADR to MIRABEL (Microrequest-Based Aggregation, Forecasting, and Scheduling of Energy Demand, Supply, and Distribution), authors propose a mapping logic that maps messages from different protocols so as to flow their operations seamlessly. Security and privacy issues have also caught researchers’ attention. Adversary models based on the OpenADR specification are identified and used to examine that security and privacy goals defined in the specification can be achievable [28]. Research in [29] analyzes security weaknesses in the open source software of OpenADR. The authors use a LDRA testbed tool (http://www.ldra.com/en/software-quality-test-tools/group/by-product-module/ldra-tool-suite) to detect software vulnerabilities that violate secure coding rules of CERT Java and network vulnerabilities that allow data modification.


## 3. Implementation and Preliminary Test

### 3.1. Testbed

In this paper, we develop both the smart and simple DRAS clients that can pull theEventState message from a DRAS following the OpenADR 1.0 specification. To be precise, we implement and deploy an Energy Management and Control System (EMCS) in our laboratory, and the client modules run on top of it. The concept of EMCS includes such systems as Building Automation System (BAS), energy management system (EMS), and/or Home Area Network (HAN) gateway. The DRAS client obtains DR event information from theEventState message and delivers it to the EMCS that automatically performs predefined DR strategies to respond to the associated DR event. Note that a facility manager can develop a DR strategy by registering a set of energy resources and corresponding control actions into the strategy. Figure 3 illustrates the entire system of our testbed that includes the EMCS, the DRAS client, and customer energy resources. In addition to the support for the ADR service, the EMCS communicates with and manages the energy resources of LED lights, solar panels, smart submeters, and so forth, stores historical energy data regarding the resources, and realizes energy service interfaces that allow external systems to read the energy data and/or to control the resources. Figure 4 pictures the exterior of the developed EMCS and two energy resources. We refer to [30, 31] for implementation details on the EMCS and energy resources deployed in the testbed.Figure 3
The entire testbed includes the EMCS, the DRAS client, and customer energy resources.Figure 4
The pictures show the EMCS and two energy resources of a dimmable LED light and a plug load meter.


### 3.2. Laboratory Experiment: Real-Time Price with Smart Client

Exploiting our testbed, this section conducts an experiment of the RTP DR service in a laboratory level. To this end, we additionally deploy a DRAS server system by extending the open source [32]. The DRAS client in the EMCS contacts the server and obtains DR signals periodically. To make sure of the interoperation, the client also communicates with a publicly available DRAS system [33]. Due to the lack of the real-time price in the retail energy market, we develop our own dynamic pricing model by leveraging the wholesale market price provided by California Independent System Operator (CAISO) [34]. More specifically, our DRAS obtains price forecast, Day-Ahead Market (DAM) data from CAISO, that provides an estimated power price of every hour for 24 hours ahead. Box 1 records an example of the original message of DAM data from CAISO. As shown, it tells that the price [US$/MWh] starts with 22.78674 cents and changes every 3,600 seconds. The resource name indicates the location where the price applies.Box 1
<
MessagePayload>
<RTO>
<name>CAISO</name>
<REPORT_ITEM>
<REPORT_HEADER>
<
SYSTEM
>OASIS</
SYSTEM
>
<TZ>PPT</TZ>
<REPORT>PRC_LMP</REPORT>
<MKT_TYPE>DAM</MKT_TYPE>
<UOM>US dollar/MWh</UOM>
<INTERVAL>ENDING</INTERVAL>
<SEC_PER_INTERVAL>3600</SEC_PER_INTERVAL>
</REPORT_HEADER>
<REPORT_DATA>
<DATA_ITEM>LMP_PRC</DATA_ITEM>
<RESOURCE_NAME>0096WD_7_N001</RESOURCE_NAME>
<OPR_DATE>2014-11-16</OPR_DATE>
<INTERVAL_NUM>3</INTERVAL_NUM>
<INTERVAL_START_GMT>2014-11-16T09:00:00-00:00</INTERVAL_START_GMT>
<INTERVAL_END_GMT>2014-11-16T10:00:00-00:00</INTERVAL_END_GMT>
<VALUE>22.78674</VALUE>
</REPORT_DATA>
<REPORT_DATA>
<DATA_ITEM>LMP_PRC</DATA_ITEM>
⋯The DRAS, then, determines the dynamic pricing data for the retail market, after quantizing the price forecast. Figure5(a) illustrates real-time power prices in a wholesale market [$/MWh] and corresponding retail market prices [ȼ/KWh]. The unit retail price is 4 ȼ/KWh, and it changes in the range between 2 and 12 ȼ/KWh within a 24-hour time window. Given the price data, the DRAS generates and delivers a DR signal, that is, anEventState message, to the DRAS client. While omitting the details on the message due to space limitation, we note that the power prices are represented as a type of “PRICE_MULTIPLE” based on the unit price (please see the OpenADR 1.0 spec. [4] for more details of the type).Figure 5
RTP experiment over 24 hours: the testbed obtains power price forecast and adjusts the brightness of a LED light.
(a)
Power price forecasting in a wholesale market in a 24-hour window (from CAISO) and power prices for a retail market
(b)
The adjustment of brightness on LED along the dynamic power prices affects the power consumptionOn the customer side, the EMCS registers one LED light of 60 W to a DR strategy that responds to the RTP event. The corresponding control action adjusts the brightness of the light according to the power price. That is, the EMCS operates a smart DRAS client. When the EMCS turns on the LED, it sets the brightness level of the light to 100%. When the power price is equal to or less than the unit price (i.e., 4ȼ/KWh), the LED is set to 100%. But as the price increases two and three times, 8 and 12 ȼ/KWh, respectively, the EMCS decreases the brightness proportionally (i.e., 50 and 25%). Since the power consumption of a LED light is proportional to its brightness, the changes of the power prices are directly shown in the power usage records. Figure 5(b) demonstrates the measurement of energy usage [Wh] of the LED light over the same time period.


## 3.1. Testbed

In this paper, we develop both the smart and simple DRAS clients that can pull theEventState message from a DRAS following the OpenADR 1.0 specification. To be precise, we implement and deploy an Energy Management and Control System (EMCS) in our laboratory, and the client modules run on top of it. The concept of EMCS includes such systems as Building Automation System (BAS), energy management system (EMS), and/or Home Area Network (HAN) gateway. The DRAS client obtains DR event information from theEventState message and delivers it to the EMCS that automatically performs predefined DR strategies to respond to the associated DR event. Note that a facility manager can develop a DR strategy by registering a set of energy resources and corresponding control actions into the strategy. Figure 3 illustrates the entire system of our testbed that includes the EMCS, the DRAS client, and customer energy resources. In addition to the support for the ADR service, the EMCS communicates with and manages the energy resources of LED lights, solar panels, smart submeters, and so forth, stores historical energy data regarding the resources, and realizes energy service interfaces that allow external systems to read the energy data and/or to control the resources. Figure 4 pictures the exterior of the developed EMCS and two energy resources. We refer to [30, 31] for implementation details on the EMCS and energy resources deployed in the testbed.Figure 3
The entire testbed includes the EMCS, the DRAS client, and customer energy resources.Figure 4
The pictures show the EMCS and two energy resources of a dimmable LED light and a plug load meter.


## 3.2. Laboratory Experiment: Real-Time Price with Smart Client

Exploiting our testbed, this section conducts an experiment of the RTP DR service in a laboratory level. To this end, we additionally deploy a DRAS server system by extending the open source [32]. The DRAS client in the EMCS contacts the server and obtains DR signals periodically. To make sure of the interoperation, the client also communicates with a publicly available DRAS system [33]. Due to the lack of the real-time price in the retail energy market, we develop our own dynamic pricing model by leveraging the wholesale market price provided by California Independent System Operator (CAISO) [34]. More specifically, our DRAS obtains price forecast, Day-Ahead Market (DAM) data from CAISO, that provides an estimated power price of every hour for 24 hours ahead. Box 1 records an example of the original message of DAM data from CAISO. As shown, it tells that the price [US$/MWh] starts with 22.78674 cents and changes every 3,600 seconds. The resource name indicates the location where the price applies.Box 1
<
MessagePayload>
<RTO>
<name>CAISO</name>
<REPORT_ITEM>
<REPORT_HEADER>
<
SYSTEM
>OASIS</
SYSTEM
>
<TZ>PPT</TZ>
<REPORT>PRC_LMP</REPORT>
<MKT_TYPE>DAM</MKT_TYPE>
<UOM>US dollar/MWh</UOM>
<INTERVAL>ENDING</INTERVAL>
<SEC_PER_INTERVAL>3600</SEC_PER_INTERVAL>
</REPORT_HEADER>
<REPORT_DATA>
<DATA_ITEM>LMP_PRC</DATA_ITEM>
<RESOURCE_NAME>0096WD_7_N001</RESOURCE_NAME>
<OPR_DATE>2014-11-16</OPR_DATE>
<INTERVAL_NUM>3</INTERVAL_NUM>
<INTERVAL_START_GMT>2014-11-16T09:00:00-00:00</INTERVAL_START_GMT>
<INTERVAL_END_GMT>2014-11-16T10:00:00-00:00</INTERVAL_END_GMT>
<VALUE>22.78674</VALUE>
</REPORT_DATA>
<REPORT_DATA>
<DATA_ITEM>LMP_PRC</DATA_ITEM>
⋯The DRAS, then, determines the dynamic pricing data for the retail market, after quantizing the price forecast. Figure5(a) illustrates real-time power prices in a wholesale market [$/MWh] and corresponding retail market prices [ȼ/KWh]. The unit retail price is 4 ȼ/KWh, and it changes in the range between 2 and 12 ȼ/KWh within a 24-hour time window. Given the price data, the DRAS generates and delivers a DR signal, that is, anEventState message, to the DRAS client. While omitting the details on the message due to space limitation, we note that the power prices are represented as a type of “PRICE_MULTIPLE” based on the unit price (please see the OpenADR 1.0 spec. [4] for more details of the type).Figure 5
RTP experiment over 24 hours: the testbed obtains power price forecast and adjusts the brightness of a LED light.
(a)
Power price forecasting in a wholesale market in a 24-hour window (from CAISO) and power prices for a retail market
(b)
The adjustment of brightness on LED along the dynamic power prices affects the power consumptionOn the customer side, the EMCS registers one LED light of 60 W to a DR strategy that responds to the RTP event. The corresponding control action adjusts the brightness of the light according to the power price. That is, the EMCS operates a smart DRAS client. When the EMCS turns on the LED, it sets the brightness level of the light to 100%. When the power price is equal to or less than the unit price (i.e., 4ȼ/KWh), the LED is set to 100%. But as the price increases two and three times, 8 and 12 ȼ/KWh, respectively, the EMCS decreases the brightness proportionally (i.e., 50 and 25%). Since the power consumption of a LED light is proportional to its brightness, the changes of the power prices are directly shown in the power usage records. Figure 5(b) demonstrates the measurement of energy usage [Wh] of the LED light over the same time period.


## 4. Experiencing ADR Service in Energy Market

In this section, we deploy our testbed system at a small customer facility, helping the building owner subscribe to an ADR service that a utility company in California offers.


### 4.1. Customer Buildings

The customer facility consists of several buildings and a couple of utility meters. Among them, two buildings of 4 stories are under one utility meter and thus participate in the ADR. Particularly, there are few occupants in the first building, and thus most energy loads can be easily curtailed. Those people understand potential inconvenience due to load curtailment that usually occurs less than 5 times a year. The building owner and the customer facility show a typical customer domain environment. The owner wants to save energy bills but is not well informed of the concepts of Smart Grid and energy management. Thus, the facility is not instrumented with any EMCS, smart submeters, storage, or power generation units. The owner hesitates to purchase this equipment mainly due to a very long Return on Investment (ROI). Fortunately, a government program supports a rebate for the purchase and the installation of an EMCS, but not other equipment. To accommodate the customer’s condition, we try to install as less devices as possible. We deploy one EMCS system and 6 smart submeters [35] in two circuit breaker panels. Three submeters are installed for measurements only, while the EMCS turns on/off energy loads via the other three submeters. Such controllable energy loads mainly are lights and office appliances. The EMCS does not control a Heating, Ventilation, and Air Conditioning (HVAC) system upon the customer’s request, whereas its energy usage is still monitored. It does not control the energy loads in the second building for the same reason.


### 4.2. ADR Service in the Energy Market

Few utilities in North America offer the RTP program for an ADR service for now. Instead, the utilities offer conventional tariffs such as CPP to customers in the ADR service. That is, customers are charged for their energy bills based on the contracted tariffs. Then, an additional incentive is granted based on how much each customer reduces power consumption during a DR event period. More specifically, a customer subscribes to the ADR with a “curtailment rate,” the amount of power that the customer must reduce upon receiving a DR signal from the utility. When succeeding in reduction, she receives an incentive based on the rate. Because a small-sized customer consumes small amount of power (up to several hundreds of KW), she often subscribes to the service with a qualified Load Aggregator (LA) (it is also known as a Curtailment Service Provider (CSP) or DR aggregator). That is, a service contract is made amongst three stakeholders of the customer, the utility, and the LA. The customer agrees on her rate with the LA who then agrees on an aggregated curtailment rate (from all the customers enrolled in the LA) with the utility.Figure6 illustrates the two-tier contracts in the ADR service. LA 1 in the middle of the figure makes a contract of the ADR service with the utility. That is, upon receiving a DR signal from the utility, LA 1 must guarantee to reduce 350 KWh of power in total. LA 1 now collects energy loads from end customers in order to achieve the contract of 350 KWh. Customer A subscribes LA 1’s curtailment service with the rate of 50 KWh. In the same way, Customers B and C subscribe the same service with rates of 200 KWh and 150 KWh, respectively. Note that LA 1 collects 400 KWh that is more than LA 1’s contracts value of 350 KWh, but it is okay that LA 1 collects 350 KWh. This implies that contract 1 (between the utility and LA 1) is independent of contract 2 (between LA 1 and three customers). When receiving a DR signal from the utility, LA 1 generates and sends out a new DR signal to all the subscribers, asking them to reduce energy consumption at the contracted rate. Some subscribers may reduce more energy than the curtailment rates while others do less. Say customers A, B, and C reduce 74 KWh, 178 KWh, and 115 KWh, calculating that LA 1’s subscribers reduce 367 KWh of energy in total. Since the total sum is greater than the contract value of 350 KWh, it is said that LA 1 achieves the requirement of contract. All the subscribers will receive contracted amount of incentive even though two of them fail to reduce the curtailment rates.Figure 6
A two-tier contract among utility, load aggregator, and end customer.A system architecture for the ADR including three stakeholders is represented in Figure7. A DRAS transmits a DR signal to the DRAS client in the customer facility and to the LA. The EMCS, then, controls energy loads to reduce power consumption via smart submeters. Such curtailment is measured in three ways. First, the utility meter measures and communicates an aggregated usage data directly with the utility. Next, the LA deploys a data logger that obtains measurement from the utility meter. Last, the EMCS also measures the usage from the smart submeters. The measurement from the logger and the EMCS is delivered to the building owner (or the facility manager) and the LA.Figure 7
A system architecture for the ADR service in the field, DRAS, DRAS client, EMCS, energy loads, three stakeholders, and information flows amongst elements.


### 4.3. Measurement of Power Usage

As the first step to determine the curtailment rate, we look into the historical data of power usage. To this end, we access a web page through which the utility provides our customer with the power [KW] and energy [KWh] usage data every 15 minutes. At the same time, we access the measurement from the LA’s data logger, which provides the usage data at a finer resolution. Connected to the utility meter directly, the logger is updated with instantaneous power draw every minute. It, then, transmits the raw data to our EMCS every 15 minutes. The raw data is then aggregated and computed together in the EMCS so as to represent the power and energy usage every 15 minutes as shown in Figure8(a). The customer buildings consume 32,296 KWh of energy in total over 7 days with average of 48.06 KWh, maximum of 104 KWh at 11 AM, and minimum of 24 KWh at 7 AM. The figure also shows that the maximum instantaneous power draw in the buildings is 416 KW and occurs in the range of 427 to 434 hours, while the average power draw is 192.24 KW. Figure 8(b) takes and averages the historical data over 1 year and draws the measurements of the maximum power usage every 15 minutes from 10 AM to 6 PM during which a DR event is highly likely to occur. The black solid line in the middle shows the average values over the last 12 months. The red curve at the top (triangle mark) draws average values during the summer season from June to September 10, while at the bottom (square) is power usage during the rest of seasons. The results show that power consumption during the time window of 8 hours is more like constant, but the building consumes 60.6% more power on average in summer than in the off season.Figure 8
We record energy usage and power draw of the customer buildings that are collected from the utility web page and the data logger.
(a)
Energy usage and power draw every 15 min over 7 days in March
(b)
Measurement of peak power draw (KW) from 10 AM to 6 PM (every 15 min). It draws the 12-month data


### 4.4. Customer Baseline Load and Curtailment Rate

Using the historical data, the customer and the LA calculate a Customer Baseline Load (CBL) [36, 37]. The CBL [KW] is a reference point on which the LA determines the amount of power consumption the customer facility reduces. Suppose that the calculated CBL value at 2 PM today is Pc KW, and the maximum instantaneous power draw measured by the meter at the same time is Pm KW. Then, the customer officially reduces power usage by (Pc-Pm) KW. If the difference is greater than a predetermined curtailment rate, then the LA concludes the success of the load curtailment on the customer side. Considering its importance in the ADR service, therefore, the CBL must be carefully calculated. While many papers in the literature investigate the baseline models [38–40], two calculations are widely used for their simple computation, 3/10 CBL and 10/10 CBL. Algorithm 1 shows a pseudocode to calculate k/10 CBL. Fundamentally, it takes historical data of power usage over the last 10 days and then picks and averages the k largest values in order to get CBL data of today. More specifically, t in the code indicates time, say 11 AM, and d represents date, for example, March 20, 2013. The value h represents the frequency of power measurement per one hour. In our experiment, the power data is measured every 15 minutes, and thus h is set to 4. In this sense, the data m183 represents an instantaneous power draw measured at 10:45 AM on March 18.Algorithm 1:
k/10 CBL calculation at time t on date d.
Require: Power measurement mij at time t, where d-11≤i≤d-1 and 1≤j≤h.
(1) /∗ Select maximum power draw within an hour range ∗/
(2)for  i=d-11 to d-1  do
(3)Mi←max1≤j≤h⁡mij
(4)end for
(5) /∗ Select k largest values from M=Mi  ∗/
(6)for  n=1 to k  do
(7)Pn←max1≤n≤10⁡(Mn∖P1,P2,…,Pn-1)
(8)end for
(9) Compute an averageP- from P=P1,P2,…,Pk
(10)return  k/10 CBL ← P-Figure9 takes our measurement data and illustrates both 3/10 CBL and 10/10 CBL for two time windows of 10 AM–6 PM and 2 PM–6 PM over 12 months. It confirms that the buildings consume much more power in summer than in the off seasons. But the gap becomes more apparent. The maximum value in summer in Figure 8(b) is 362.67 KW, while the maximum one in the 3/10 CBL in Figure 9 reaches up to 494.10 KW. This is mainly attributed to the fact that the CBLs take the largest values among all the measurements. In this sense, the 3/10 CBL values are greater than those in the 10/10 CBL, since 3/10 CBL takes three largest values only. The results in the figure also show that there are few differences between two time windows in both calculations. This also confirms previous measurements that power consumption for 8 hours is more like constant.Figure 9
Calculation of 3/10 and 10/10 CBL over 12 months.Given the CBL calculation, the curtailment rate is determined based on additional measurements. To this end, the customer and the LA run an one-hour DR event during which the buildings turn off all the energy loads participating in the ADR. In our experiment, the EMCS shuts off the power of the 3 submeters. Then, the load drop is measured and compared with CBL data. We use a modified 10/10 CBL that the utility offers. It takes the 10/10 CBL data and adjusts it by putting more weights on 4 values the closest to the moment of the DR event. The experimental results are illustrated in Figure10. The bars represent the modified 10/10 CBL from 8 AM to 7 PM that are averaged over the last 10 days, and the line shows measurements of power draw at the event day. During the event (at 3 PM), the CBL is 237.6 KW while the power draw is 120 KW. Then, we determine 100 KW of curtailment rate, after considering a buffer to the actual load drop (= 117.6 KW). Note that the building owner is incentivized for 100 KW.Figure 10
Measurement of peak power draw (KW) during a simulated one-hour DR event (at 3 PM). The curtail rate is determined based on the measurement and the CBL calculation.


### 4.5. Running the ADR Service

The existing DRAS in the utility uses the OpenADR 1.0 specification to transmit DR event signals to the customers. Unlike our previous experiments with the smart DRAS client, however, it only supports a simple client mode in which data is recorded in theSimpleClientEventData entity of theEventState message. A sample signal is shown at Box 2. Note that thesimpleDRModeData represents theSimpleClientEventData entity.Box 2
<
p:simpleDRModeData>
<p:EventStatus>ACTIVE</p:EventStatus>
<p:OperationModeValue>MODERATE</p:OperationModeValue>
<p:currentTime>354.638</p:currentTime>
<p:operationModeSchedule>
<p:modeSlot>
<p:OperationModeValue>MODERATE</p:OperationModeValue>
<p:modeTimeSlot>0</p:modeTimeSlot>
</p:modeSlot>
<p:modeSlot>
<p:OperationModeValue>HIGH</p:OperationModeValue>
<p:modeTimeSlot>3600</p:modeTimeSlot>
</p:modeSlot>
</p:operationModeSchedule>
</p:simpleDRModeData>The specification defines three types of operational states for the simple client, but the existing ADR service uses only two states of Normal or High. Moderate state is considered the same as High state. Thus, our EMCS notices that a DR event occurs only when it receives a DR message containing a moderate or high state. It is worth noting that the existing ADR service uses the DR message in the most simplified format. When the EMCS receives a DR message, it only acquires minimum amount of information about the status in the power grid, the occurrence of a DR event in a time window. The message does not even contain any clue about how urgent the event is. Upon receiving this simple information, the EMCS can perform a simple DR strategy, say it turns on or off all the connected energy loads at once. On the other hand, the DR message used in the preliminary test contains power price changing every hour. Given the message, the EMCS now has more options in the DR strategy. It may only turn off less important energy loads that are consuming the exact amount of energy to be reduced during a DR event. This allows the EMCS to make fine-grained control over energy resources within the facility, which enables to minimize interference with normal building operations.In our experiment, DR events occur three times. During a DR event, the EMCS turns off the smart submeters. The results are illustrated in Figure11, showing that the customer buildings achieve 45%, 172%, and 70% of performance. The huge gap between the achievements is mainly attributed to the simple control strategy. The EMCS simply stops building operations by turning off all the smart submeters. The amount of reduction entirely relies on power consumption of the energy loads currently connected to the submeters. For instance, the load curtailment of 172.4 KW in September in the figure is calculated from (Pc-Pm), where Pc is premeasured CBL value and Pm is measured power from a smart meter. This implies that the building was consuming huge energy when the DR event started and the EMCS shut off all the energy devices connected to the smart meter. On the other hand, 45.2 KW in August indicates that the buildings were consuming much less energy. With such inconsistent performance, the utility cannot ensure that the customer is able to reduce required amount of power consumption on emergency, failing to satisfy the grid needs. To mitigate the risk, especially in small customer facilities, the LA aggregates power reduction from all the enrolled customers and makes the performance more reliable. The mediator role of the LA also benefits the customers. We note that the performance less than 100% does not necessarily mean that the customer gets penalized, because she made a contract with the LA. If other customers under the same LA reduce more than 100% and thus the aggregated reduction is greater than the contracted rate between the LA and the utility, the customer still receives an incentive even though she achieves only 45%. Likewise, her performance of 172% benefits other customers at the second event. We refer to [6] for more discussion on the LA’s role.Figure 11
Three ADR events occur and last for 2, 1, and 3 hours, respectively. The load curtailment is the calculation of(Pc-Pm), and recall that the curtailment rate is 100 KW.


## 4.1. Customer Buildings

The customer facility consists of several buildings and a couple of utility meters. Among them, two buildings of 4 stories are under one utility meter and thus participate in the ADR. Particularly, there are few occupants in the first building, and thus most energy loads can be easily curtailed. Those people understand potential inconvenience due to load curtailment that usually occurs less than 5 times a year. The building owner and the customer facility show a typical customer domain environment. The owner wants to save energy bills but is not well informed of the concepts of Smart Grid and energy management. Thus, the facility is not instrumented with any EMCS, smart submeters, storage, or power generation units. The owner hesitates to purchase this equipment mainly due to a very long Return on Investment (ROI). Fortunately, a government program supports a rebate for the purchase and the installation of an EMCS, but not other equipment. To accommodate the customer’s condition, we try to install as less devices as possible. We deploy one EMCS system and 6 smart submeters [35] in two circuit breaker panels. Three submeters are installed for measurements only, while the EMCS turns on/off energy loads via the other three submeters. Such controllable energy loads mainly are lights and office appliances. The EMCS does not control a Heating, Ventilation, and Air Conditioning (HVAC) system upon the customer’s request, whereas its energy usage is still monitored. It does not control the energy loads in the second building for the same reason.


## 4.2. ADR Service in the Energy Market

Few utilities in North America offer the RTP program for an ADR service for now. Instead, the utilities offer conventional tariffs such as CPP to customers in the ADR service. That is, customers are charged for their energy bills based on the contracted tariffs. Then, an additional incentive is granted based on how much each customer reduces power consumption during a DR event period. More specifically, a customer subscribes to the ADR with a “curtailment rate,” the amount of power that the customer must reduce upon receiving a DR signal from the utility. When succeeding in reduction, she receives an incentive based on the rate. Because a small-sized customer consumes small amount of power (up to several hundreds of KW), she often subscribes to the service with a qualified Load Aggregator (LA) (it is also known as a Curtailment Service Provider (CSP) or DR aggregator). That is, a service contract is made amongst three stakeholders of the customer, the utility, and the LA. The customer agrees on her rate with the LA who then agrees on an aggregated curtailment rate (from all the customers enrolled in the LA) with the utility.Figure6 illustrates the two-tier contracts in the ADR service. LA 1 in the middle of the figure makes a contract of the ADR service with the utility. That is, upon receiving a DR signal from the utility, LA 1 must guarantee to reduce 350 KWh of power in total. LA 1 now collects energy loads from end customers in order to achieve the contract of 350 KWh. Customer A subscribes LA 1’s curtailment service with the rate of 50 KWh. In the same way, Customers B and C subscribe the same service with rates of 200 KWh and 150 KWh, respectively. Note that LA 1 collects 400 KWh that is more than LA 1’s contracts value of 350 KWh, but it is okay that LA 1 collects 350 KWh. This implies that contract 1 (between the utility and LA 1) is independent of contract 2 (between LA 1 and three customers). When receiving a DR signal from the utility, LA 1 generates and sends out a new DR signal to all the subscribers, asking them to reduce energy consumption at the contracted rate. Some subscribers may reduce more energy than the curtailment rates while others do less. Say customers A, B, and C reduce 74 KWh, 178 KWh, and 115 KWh, calculating that LA 1’s subscribers reduce 367 KWh of energy in total. Since the total sum is greater than the contract value of 350 KWh, it is said that LA 1 achieves the requirement of contract. All the subscribers will receive contracted amount of incentive even though two of them fail to reduce the curtailment rates.Figure 6
A two-tier contract among utility, load aggregator, and end customer.A system architecture for the ADR including three stakeholders is represented in Figure7. A DRAS transmits a DR signal to the DRAS client in the customer facility and to the LA. The EMCS, then, controls energy loads to reduce power consumption via smart submeters. Such curtailment is measured in three ways. First, the utility meter measures and communicates an aggregated usage data directly with the utility. Next, the LA deploys a data logger that obtains measurement from the utility meter. Last, the EMCS also measures the usage from the smart submeters. The measurement from the logger and the EMCS is delivered to the building owner (or the facility manager) and the LA.Figure 7
A system architecture for the ADR service in the field, DRAS, DRAS client, EMCS, energy loads, three stakeholders, and information flows amongst elements.


## 4.3. Measurement of Power Usage

As the first step to determine the curtailment rate, we look into the historical data of power usage. To this end, we access a web page through which the utility provides our customer with the power [KW] and energy [KWh] usage data every 15 minutes. At the same time, we access the measurement from the LA’s data logger, which provides the usage data at a finer resolution. Connected to the utility meter directly, the logger is updated with instantaneous power draw every minute. It, then, transmits the raw data to our EMCS every 15 minutes. The raw data is then aggregated and computed together in the EMCS so as to represent the power and energy usage every 15 minutes as shown in Figure8(a). The customer buildings consume 32,296 KWh of energy in total over 7 days with average of 48.06 KWh, maximum of 104 KWh at 11 AM, and minimum of 24 KWh at 7 AM. The figure also shows that the maximum instantaneous power draw in the buildings is 416 KW and occurs in the range of 427 to 434 hours, while the average power draw is 192.24 KW. Figure 8(b) takes and averages the historical data over 1 year and draws the measurements of the maximum power usage every 15 minutes from 10 AM to 6 PM during which a DR event is highly likely to occur. The black solid line in the middle shows the average values over the last 12 months. The red curve at the top (triangle mark) draws average values during the summer season from June to September 10, while at the bottom (square) is power usage during the rest of seasons. The results show that power consumption during the time window of 8 hours is more like constant, but the building consumes 60.6% more power on average in summer than in the off season.Figure 8
We record energy usage and power draw of the customer buildings that are collected from the utility web page and the data logger.
(a)
Energy usage and power draw every 15 min over 7 days in March
(b)
Measurement of peak power draw (KW) from 10 AM to 6 PM (every 15 min). It draws the 12-month data


## 4.4. Customer Baseline Load and Curtailment Rate

Using the historical data, the customer and the LA calculate a Customer Baseline Load (CBL) [36, 37]. The CBL [KW] is a reference point on which the LA determines the amount of power consumption the customer facility reduces. Suppose that the calculated CBL value at 2 PM today is Pc KW, and the maximum instantaneous power draw measured by the meter at the same time is Pm KW. Then, the customer officially reduces power usage by (Pc-Pm) KW. If the difference is greater than a predetermined curtailment rate, then the LA concludes the success of the load curtailment on the customer side. Considering its importance in the ADR service, therefore, the CBL must be carefully calculated. While many papers in the literature investigate the baseline models [38–40], two calculations are widely used for their simple computation, 3/10 CBL and 10/10 CBL. Algorithm 1 shows a pseudocode to calculate k/10 CBL. Fundamentally, it takes historical data of power usage over the last 10 days and then picks and averages the k largest values in order to get CBL data of today. More specifically, t in the code indicates time, say 11 AM, and d represents date, for example, March 20, 2013. The value h represents the frequency of power measurement per one hour. In our experiment, the power data is measured every 15 minutes, and thus h is set to 4. In this sense, the data m183 represents an instantaneous power draw measured at 10:45 AM on March 18.Algorithm 1:
k/10 CBL calculation at time t on date d.
Require: Power measurement mij at time t, where d-11≤i≤d-1 and 1≤j≤h.
(1) /∗ Select maximum power draw within an hour range ∗/
(2)for  i=d-11 to d-1  do
(3)Mi←max1≤j≤h⁡mij
(4)end for
(5) /∗ Select k largest values from M=Mi  ∗/
(6)for  n=1 to k  do
(7)Pn←max1≤n≤10⁡(Mn∖P1,P2,…,Pn-1)
(8)end for
(9) Compute an averageP- from P=P1,P2,…,Pk
(10)return  k/10 CBL ← P-Figure9 takes our measurement data and illustrates both 3/10 CBL and 10/10 CBL for two time windows of 10 AM–6 PM and 2 PM–6 PM over 12 months. It confirms that the buildings consume much more power in summer than in the off seasons. But the gap becomes more apparent. The maximum value in summer in Figure 8(b) is 362.67 KW, while the maximum one in the 3/10 CBL in Figure 9 reaches up to 494.10 KW. This is mainly attributed to the fact that the CBLs take the largest values among all the measurements. In this sense, the 3/10 CBL values are greater than those in the 10/10 CBL, since 3/10 CBL takes three largest values only. The results in the figure also show that there are few differences between two time windows in both calculations. This also confirms previous measurements that power consumption for 8 hours is more like constant.Figure 9
Calculation of 3/10 and 10/10 CBL over 12 months.Given the CBL calculation, the curtailment rate is determined based on additional measurements. To this end, the customer and the LA run an one-hour DR event during which the buildings turn off all the energy loads participating in the ADR. In our experiment, the EMCS shuts off the power of the 3 submeters. Then, the load drop is measured and compared with CBL data. We use a modified 10/10 CBL that the utility offers. It takes the 10/10 CBL data and adjusts it by putting more weights on 4 values the closest to the moment of the DR event. The experimental results are illustrated in Figure10. The bars represent the modified 10/10 CBL from 8 AM to 7 PM that are averaged over the last 10 days, and the line shows measurements of power draw at the event day. During the event (at 3 PM), the CBL is 237.6 KW while the power draw is 120 KW. Then, we determine 100 KW of curtailment rate, after considering a buffer to the actual load drop (= 117.6 KW). Note that the building owner is incentivized for 100 KW.Figure 10
Measurement of peak power draw (KW) during a simulated one-hour DR event (at 3 PM). The curtail rate is determined based on the measurement and the CBL calculation.


## 4.5. Running the ADR Service

The existing DRAS in the utility uses the OpenADR 1.0 specification to transmit DR event signals to the customers. Unlike our previous experiments with the smart DRAS client, however, it only supports a simple client mode in which data is recorded in theSimpleClientEventData entity of theEventState message. A sample signal is shown at Box 2. Note that thesimpleDRModeData represents theSimpleClientEventData entity.Box 2
<
p:simpleDRModeData>
<p:EventStatus>ACTIVE</p:EventStatus>
<p:OperationModeValue>MODERATE</p:OperationModeValue>
<p:currentTime>354.638</p:currentTime>
<p:operationModeSchedule>
<p:modeSlot>
<p:OperationModeValue>MODERATE</p:OperationModeValue>
<p:modeTimeSlot>0</p:modeTimeSlot>
</p:modeSlot>
<p:modeSlot>
<p:OperationModeValue>HIGH</p:OperationModeValue>
<p:modeTimeSlot>3600</p:modeTimeSlot>
</p:modeSlot>
</p:operationModeSchedule>
</p:simpleDRModeData>The specification defines three types of operational states for the simple client, but the existing ADR service uses only two states of Normal or High. Moderate state is considered the same as High state. Thus, our EMCS notices that a DR event occurs only when it receives a DR message containing a moderate or high state. It is worth noting that the existing ADR service uses the DR message in the most simplified format. When the EMCS receives a DR message, it only acquires minimum amount of information about the status in the power grid, the occurrence of a DR event in a time window. The message does not even contain any clue about how urgent the event is. Upon receiving this simple information, the EMCS can perform a simple DR strategy, say it turns on or off all the connected energy loads at once. On the other hand, the DR message used in the preliminary test contains power price changing every hour. Given the message, the EMCS now has more options in the DR strategy. It may only turn off less important energy loads that are consuming the exact amount of energy to be reduced during a DR event. This allows the EMCS to make fine-grained control over energy resources within the facility, which enables to minimize interference with normal building operations.In our experiment, DR events occur three times. During a DR event, the EMCS turns off the smart submeters. The results are illustrated in Figure11, showing that the customer buildings achieve 45%, 172%, and 70% of performance. The huge gap between the achievements is mainly attributed to the simple control strategy. The EMCS simply stops building operations by turning off all the smart submeters. The amount of reduction entirely relies on power consumption of the energy loads currently connected to the submeters. For instance, the load curtailment of 172.4 KW in September in the figure is calculated from (Pc-Pm), where Pc is premeasured CBL value and Pm is measured power from a smart meter. This implies that the building was consuming huge energy when the DR event started and the EMCS shut off all the energy devices connected to the smart meter. On the other hand, 45.2 KW in August indicates that the buildings were consuming much less energy. With such inconsistent performance, the utility cannot ensure that the customer is able to reduce required amount of power consumption on emergency, failing to satisfy the grid needs. To mitigate the risk, especially in small customer facilities, the LA aggregates power reduction from all the enrolled customers and makes the performance more reliable. The mediator role of the LA also benefits the customers. We note that the performance less than 100% does not necessarily mean that the customer gets penalized, because she made a contract with the LA. If other customers under the same LA reduce more than 100% and thus the aggregated reduction is greater than the contracted rate between the LA and the utility, the customer still receives an incentive even though she achieves only 45%. Likewise, her performance of 172% benefits other customers at the second event. We refer to [6] for more discussion on the LA’s role.Figure 11
Three ADR events occur and last for 2, 1, and 3 hours, respectively. The load curtailment is the calculation of(Pc-Pm), and recall that the curtailment rate is 100 KW.


## 5. Conclusion

An Automated Demand Response is the most fundamental service to accomplish the eventual goal of Smart Grid, balancing the power demand with the supply via active interoperation amongst Smart Grid participants. To facilitate the ADR, the OpenADR specification was developed, and several utilities offer the service in a very primitive form in a retail market. But, few articles have reported the details of such a real-world service yet, and we still rely on our textbooks to design next generations of the ADR service. To overcome the discrepancy of our understanding, this paper shares our hand-on experiences on the ADR service. In particular, we implemented an ADR testbed and conducted preliminary experiments in our laboratory. Then, we deployed the testbed at a small commercial facility: we instrumented smart submeters to manage the facility’s energy loads and installed an EMCS system including a DRAS client that receives DR messages from the utility’s DRAS. In order to determine the curtailment rate, we examined the historical data of the customer’s power usage, computed two CBL values based on the data, run a simulated DR event during which the EMCS curtailed energy loads, and measured and compared the power reduction with the computed CBL. With the rate, the customer facility participated in three DR events for tests, each of which lasted for 2, 1, and 3 hours, respectively. Our experimental results were illustrated with additional discussion on the role of the LA. Through a series of experiments and measurements, this paper has tried to answer many questions for the commercialized ADR services, from system installations to incentive for the participation.



---

*Source: 936931-2015-11-25.xml*