An Integrated Architecture forDemand Response Communications and Control

Michael LeMay, Rajesh Nelli, George Gross, and Carl A. GunterUniversity of Illinois Urbana-Champaign

Email: {mdlemay2,rnelli2,gross,cgunter}@uiuc.edu

Abstract

1 In the competitive electricity structure, demandresponse programs enable customers to react dynami-cally to changes in electricity prices. The implementa-tion of such programs may reduce energy costs and in-crease reliability. To fully harness such benefits, exist-ing load controllers and appliances need around-the-clock price information. Advances in the developmentand deployment of Advanced Meter Infrastructures(AMIs), Building Automation Systems (BASs), and var-ious dedicated embedded control systems provide thecapability to effectively address this requirement. Inthis paper we introduce a Meter Gateway Architecture(MGA) to serve as a foundation for integrated controlof loads by energy aggregators, facility hubs, andintelligent appliances. We discuss the requirementsthat motivate the architecture, describe its design, andillustrate its application to a small system with anintelligent appliance and a legacy appliance using aprototype implementation of an intelligent hub for theMGA and ZigBee wireless communications.

Index Terms

Demand Response, Advanced Meter Infrastructure,AMI, ZigBee, Building Automation System, BAS, HomeAutomation, Meter Data Management

1. Introduction

Fluctuations in electrical loads require generationinvestments to enable Electricity Service Providers(ESPs) to provide reliable service around-the-clock.Reducing the peaks in these fluctuations could producesignificant costs savings and reduce risks of outages,thus improving efficiency and reliability of ESPs. In

1. In: Hawaiian International Conference on System Sciences,Waikoloa Hawaii, January 2008.

principle this can be done with demand responsetechniques in which electricity users take measures toreduce demand during times when generation is, or islikely to be, expensive. Unfortunately, these benefitsof demand response have not yet been widely realizedin practice. There are several reasons for this, but oneof the most important is the lack of price-responsivecontrols over important loads. However, new technolo-gies are quickly reaching a stage in which a muchgreater range of loads could support demand response.Three important examples of such new technologiesare are Advanced Meter Infrastructure (AMI), BuildingAutomation Systems (BASs), and embedded controlsystems.

AMI provides intelligent metering based on data net-work communications to facilities. The current driverfor much of the AMI deployment is reduced billingcosts for ESPs, but many AMIs can also support de-mand response by providing Real-Time Pricing (RTP)to load owners. BASs are being deployed in thenext generation of “smart buildings”, which typicallyprovide a network system such as wireline Ethernet tocontrol functions like security and HVAC. A closelyrelated technology for building and home automationbased on wireless communications using ZigBee hasbeen reaching fruition as well. These technologiesprovide communication and control that could be usedto support demand response by transmitting pricinginformation from the AMI to facility load controllers.Finally, advances in networked embedded control de-vices provide an avenue for appliances to carry outtheir own demand response actions based on wirelessmonitoring of electricity prices or react to controlsfrom elsewhere.

Today’s advanced BASs provide excellent capabilityto fine-tune the set points of energy utilization invarious heating, cooling, and lighting loads in edifices.The EnergyPlus simulations at the New York TimesHeadquarters building [1], demonstrate the extensionof BASs for performing direct load control. The sim-

ulation consisted of a demand response event lastingfour hours and produced a maximum demand reductionof 400 kW in the NYT building. Further, a differentdirect load control option available to Energy ServiceProviders (ESPs) is to make use of AMI and remotelydisconnect or cycle loads of customers who sign upfor such programs. For example, the Energy$martThermostatSM pilot program launched by SCE [2]makes use of a two-way programmable thermostatconnected to the internet and controlled via radio totune the set-point of air conditioners in the interval of[2,4] degrees Fahrenheit. The metered data collectedfrom 4600 such thermostats during the tests conductedin the summer of 2003 showed an average energysavings of about 6.0 MWh during the first hour ofthe field trials and a peak demand reduction of 9MW during the initial 15 minutes of the hour, for asetpoint increase of four degrees in all the thermostats.The Grid Friendly Appliance controller developed byPacific Northwest National Laboratory (PNNL) is anexample for the use of an embedded control systemin direct load control. It senses the grid conditions bymonitoring the frequency of the system and providesautomatic demand response to meet system needs. Itcan decrease the residential load by turning householdappliances off for a specified period - typically onthe order of a few minutes, hence raising the gridfrequency so as to return to 60 Hz operation [3].

Although these and other studies show promisefor individual strategies for demand response, nonedescribe or use an integrated approach to allow theirdeployment to effectively and economically implementdemand response on a large scale. The aim of thispaper is to propose and take initial steps to validatean architecture that integrates demand response basedon AMI, BASs, and embedded control systems. Themain technical challenge is to accommodate withinthe same framework the existence of multiple loci ofcontrol for demand response, such as smart appliances,BAS hubs, and centralized authorities like independentenergy aggregators or the electricity supplier itself. Wedescribe an approach in which these can be integratedinto a single architecture. This architecture, which wecall the “meter gateway architecture”, is based onthe deployment of the facility meter as the primarycommunication system linking the BAS to the AMI.

Our demonstration illustrates how incremental adop-tion of demand response can be achieved with existinginfrastructure and embedded devices in such a waythat the resultant system is capable of automaticallyresponding to fluctuating price signals in an intelligentand flexible manner. To this end, we developed a col-lection of prototype demand response systems. They all

respond to fluctuations in real-time prices downloadedfrom the web and metered using AMR, to emulatean AMI solution. The first prototype is a laptop thatmonitors energy prices and uses this information toregulate the times at which it recharges its battery. Thisexplores demand response by intelligent embeddedcontrols and the potential use of storage systems. Asecond prototype is a hub that uses a wireless link toenable demand response to a device that has none onits own. In particular, this system uses an RTP-enabledthermostat to override settings on an air conditioningunit using X10 home automation. This models both“smart thermostats,” which are an area of currentexperimentation, and strategies for creating demandresponse in legacy appliances. We argue that the ar-chitecture provides a general strategy for incrementaladoption of demand response that effectively exploitsthe emerging AMI, BAS, and embedded control tech-nologies. We even provide preliminary evidence thatsuch controls could lead to incremental cost savingsfor individual homeowners that have been difficultto achieve to date due to the past requirement thathomeowners manually respond to price fluctuations.

The paper contains six additional sections. In Sec-tion 2 we motivate demand response and justify theidea that an architecture based on multiple loci ofcontrol is needed. In Section 3 we describe the me-ter gateway architecture that fulfils this requirement.In Section 4 we describe our prototype system andexperiments aimed at validating this architecture. InSection 5 we discuss the implications of the prototypeand experiments with respect to this and other potentialarchitectures in a broad context. Section 6 summarizesrelated work and Section 7 concludes.

2. Motivation

Demand response is the concept that load controllersmay vary their usage levels to accommodate changingelectricity prices or to avert system instability. Fluctu-ations in electricity usage can be substantial in currenthigh-load areas like cities and industrial parks, andthe reserves required to meet peak demands introducesignificant costs, causing the wholesale price of elec-tricity to vary by a factor of two or more from onehour to the next, and a corresponding but dampenedresponse in subsequent day-ahead price estimates. Ifload controllers are aware of this fluctuation, thenthere is an opportunity for significant savings fromdelaying demand or making incremental compromisesin comfort or convenience. For instance, during a peakperiod it may make sense to allow thresholds for airconditioning (a large contributor to peak demands) to

vary outside the usual range by a few degrees. If priceinformation is made available to load controllers andthe owners of these loads are allowed to reap thebenefits of trimming demand during peak periods, thenthere is a strong free market incentive for effectivedemand response. In this section we explore aspects ofthe technological design space to enable this capabilityby describing key aspects of the infrastructure requiredto support it and the likely loci of control for demandresponse that could use this infrastructure.

AMI is an emerging technology growing fromAMR. The main goal of AMR was to reduce thecosts of reading electrical meters but AMI providesthe promise of other capabilities based on bidirectionalcommunications where data can be sent to a meteras well as retrieved from it, and, in some cases, theability to execute control actions (such as shutting offelectricity). AMI can be viewed as a communicationand control link between a Meter Data ManagementAgency (MDMA) and a collection of metered facilities.Advantages of AMI include not only the cost savingsof AMR, but also prospects for increased customercontrol, including demand response. AMI brings todistribution network end users an analog of the digitalcommunications that Supervisory Control and DataAcquisition (SCADA) systems provide for substationsin the distribution and transmission networks. AMRand AMI systems can use a variety of communicationmediums. On one end of the spectrum, a simple type ofAMR uses short range radio links that require readersto drive by facilities in vans to collect readings. At theother extreme, many sophisticated AMI solutions arenow using mesh networks where neighboring meterscommunicate data for one another to route informationto and from the MDMA, which is attached to one ormore nodes on the mesh. Our discussion here assumesthat the AMI is at least capable of sending real-timepricing information to meters and recording powerusage in accordance with this pricing. This rules outthe van-based AMR systems, but includes networksthat use technologies like Power Line Carrier (PLC)communications or cellular links, as well as robustmesh networks.

BAS is an emerging technology for controllingnetworked computers, sensors (like motion detectors)and actuators (like door locks) in facilities. Thesetechnologies fall into two general groups. One is aimedat office and factory facilities, including sophisticatedfeatures like tracking movement of people and objectsor controlling specialized machinery. The second isaimed at residential facilities, where key objectivesinclude controls for appliances, such as light dimmersand emergency monitoring to detect break-ins or fires.

A particular case of interest is “smart” thermostats,which provide a computer that controls the homeHVAC system and are, in some cases, able to commu-nicate with non-HVAC household appliances. A majortrend in the home automation market is the use of shortrange wireless technologies. The mainstream homeautomation space is dominated by the X10 protocol,which was introduced in 1978 and uses in-home PLCto control plug-in modules using binary commandstransmitted at 60bps. X10 has been extended to supportwireless remote controls by using transceivers thatconvert RF control commands into X10 PLC signals.Several alternatives to X10 have been developed, butmost retain backward-compatibility with the basic X10protocol. However, X10 now faces new competitionthat could fundamentally change the communicationsmodel for home automation. ZigBee is a link layerbased on the IEEE 802.15.4 MAC designed for thisapplication space. It improves over technologies likeWiFi (802.11) in power consumption and robustness,and may have a disruptive influence on office andfactory BAS systems, which now are based mainlyon wireline Ethernet, but may in the future use meshnetworks of ZigBee nodes [4].

Another trend is the deployment of smart appliancesthat include some form of embedded control. Thistrend is not new, and, increasingly, appliances likewashing machines and ovens have embedded control.A newer trend is the addition to these devices of anetwork communication link and possibly attachmentto the Internet. An interesting illustration of this is theidea of a networked microwave oven that can read a barcode on a package and download cooking instructionsfrom the Internet for the food in the package [5].The relevance of this type of communication is itspotential to allow the appliance to collect informationfrom outside its own sensor system and exploit thisfor various purposes, such as energy savings throughdemand response. Consider, for example, the idea ofa dish washer that includes in its energy-save mode astrategy for doing the wash when the electricity priceis below average (for example, it might learn how topredict the best moment for washing in the 3 hourinterval following a wash request).

Appliances that have rechargeable batteries providea special opportunity since they can, to some degree,select the right time to draw power from the grid.Our prototype system explores the idea of a laptopthat can take current electricity prices into accountin determining when to charge its battery to fullcapacity. Laptops already include very sophisticatedpower management capabilities, but none of the cur-rent systems exploit electricity prices as part of their

management strategies. Other types of appliances withstorage are likely in the future, such as pluggablehybrid automobiles. Moreover, there are deploymentsof storage systems like flywheels that enable bothbackup electricity generation and an ability to selectwhen power is taken from the grid [6].

In many cases appliances do not have sufficient em-bedded control to carry out their own demand response.This is clearly true of legacy appliances, which did notanticipate any such function, but also of devices, suchas light bulbs, where costs and benefits are too low tomerit individual embedded control. Even sophisticateddevices may not provide demand response capabilitiesthemselves because of the potential subtlety of thesecapabilities. Demand response algorithms are largelyunexplored territory and can be expected to evolve,possibly into quite complex or coordinated strategies.These factors make it likely that many or most demandresponse actions will be controlled by a unified hublikely to be associated with the facility BAS. A unifiedhub provides control for a potentially large number ofindividual loads according to strategies that may bequite specific to the type of load. A general demandresponse architecture must therefore include the con-cept of a hub to control demand response for a rangeof facility loads. The hub and meter form the core ofour demand response architecture.

Although there is a great deal that can be done witha facility hub supporting demand response and price-aware loads, there are limitations to basing demandresponse on the information and negotiating abilitiesat the level of a single facility. It is therefore importantalso to consider the idea of collections of facilitiesbanding together and negotiating their own aggregateddemand response strategies. Let us call the control cen-ter for such coalitions a real-time aggregator. This maybe the utility itself. For instance, the ESP itself mayoffer a discount to users that will ensure that their loadsare capped at a proposed level during peak periods. Or,a real-time aggregator could be an independent partywho delivers a profile of demand response capabilitiesto the ESP. Real-time aggregators could be the solutionto certain worrying possible consequences of basingdemand response on per-facility control. For instance,there is a threat of rebound peaks in which facilitiesdelay their demands to avoid a peak, but cause a newpeak when trying to satisfy delayed demand [7]. Areal-time aggregator may have the ability to schedulethe satisfaction of delayed demand to avoid suchrebound peaks. A general architecture for demandresponse should envision real-time aggregators andenable them to coexist with more localized capabilities.In particular, there must be a strategy for how real-time

aggregators execute control on their loads in a way thatmakes sense even when unified hubs and independentsmart appliances are in use.

3. Architecture

Let us assume that we are given an AMI that pro-vides bidirectional information flows and, in particular,enables demand response based on real-time prices.Let us further assume that this capability is given to afacility that has BAS and/or a collection of intelligentappliances. Our goal is to construct an architecture thatis capable of exploiting these assumptions to providedemand response that can realize incremental gainsbased on inexpensive modifications using control fromany subset of potential control loci, including energyaggregators, BAS hubs, or intelligent appliances.

There are a variety of approaches to this problembased on different communication and control strate-gies. A simple approach is to let the MDMA advertisethe prices on the Internet and let facilities subscribeto this information to plan demand response. This hassome advantages, like simplicity and the exploitationof shared infrastructure, but it also has a variety ofdrawbacks. For instance, not all facilities will have thenecessary Internet access, and there could be signifi-cant latency issues because of infrastructure sharing (soone facility may get its prices at a significantly differ-ent time from another). This problem can be addressedby the use of a network dedicated to delivering real-time pricing and designed to be respectful of uniforminformation distribution to its clients. Because of thegrowth of AMI, such a network is already availableand not a prohibitive expense, so it is possible touse this, provided its facility-based node, the meter,is able to communicate directly with nodes in thefacility. Our approach, the Meter Gateway Architecture(MGA) takes as its premise that the meter is thekey communication link between the MDMA and thefacility demand response controls. Given this premise,there are a few more issues to resolve concerning howcommunication and control are organized around themeter. The main additional element of the MGA is aunified hub that provides central communication andcontrol within the facility and, in particular, is able tocollect information from the facility meter and makeit available thoughout the facility. ZigBee is a rapidlyemerging technology for wireless communication infacilities, and it is ideal for MGA deployment of thishub.

The types of control in MGA are shown in Figure 1.L1 is a “smart” appliance that can provide its owndemand response. An example is a dishwasher with

Figure 1. Types of Control in MGA

an economy delay cycle that waits for cheap power.Here the demand response control C1 for the applianceis located in the embedded control of the appliance,which makes use of a ZigBee wireless link to the hub,where it gets real-time prices. By contrast, L2 is anappliance that delegates its demand response controlsto the hub, which has the control functions C2 forexecuting demand response actions for L2. This mayconsist of putting L2 into a power-save mode at theright time. An example is a control for a refrigerationsystem that tries to optimize the cooling cycles of therefrigerator by varying its cooling range. Here the logicmay better reside on the hub because the function ismore complex than the appliance wishes to handleitself in its own (simple) embedded control. A legacyappliance L3 that has no embedded control of its owncan be hooked to a switch that has control C3 at thehub. This has the disadvantage that it cannot make useof any intelligence in the appliance, but, since manylegacy appliances have no intelligence anyway, theremay be no major loss. Inexpensive loads like lightbulbs will often also be in this category. Finally, L4is an appliance controlled by a real-time aggregator.An example is an ESP that has direct controls overelectrical water heaters and uses this control to disablewater heating in emergency situations. Another is acollection of building owners that garner a good pricefrom the ESP by enabling a power save mode thatreduces load by 15% when requested by the ESP. Inthis case control C4 resides at the hub, and, followingthe MGA concept, the control is relayed to the par-ticipants using the MDMA. The real-time aggregatormay be linked to the MDMA over the Internet or otherconnection, and the meter is linked to the MDMA bythe communication channel provided by the AMI.

The most important elements of MGA are the meterand the hub. We assume the meter is able to get

Figure 2. Hub Architecture Supporting MGA

real-time prices from the MDMA and relay them tothe hub over ZigBee. The architecture of a unifiedhub that supports MGA is shown in Figure 2. Thedevice has a ZigBee interface and an Operating Sys-tem (OS) capable of supporting some partitioning ofprocesses. There are three distinguished processes. TheHub Control process provides basic hub services likeauthorizing and managing the installation and removalof control processes for appliances. The User Portalprovides an interface for the facility owner, such asthe ability to inspect hub values from a PC. The MeterData process provides the price information that theMDMA supplies to the hub, making this available toappliances with embedded control like L1. It acts as alocal agent for the control a real-time aggregator sendsthrough the meter to L2. And, finally, it acts as a datasource for other control processes. The unified hub isa general concept and there is a possibility for it tobe used by a collection of applications different fromdemand response, so we envision it having any numberof isolated controls for assorted sensors and actuatorsin the facility. The unified hub may be an independentelement, or it could be integrated with the meter itself,or it could be integrated with a BAS control element.The main requirement is that it provide support forhub control, user portal, and meter data as illustratedin Figure 2.

This architecture is feasible to build. A meter-integrated version of the unified hub was defined in theattested meter [8], which focused on security featuressuch as remote attestation.

4. Experiments

We now describe our MGA prototype and someexperiments that illustrate its functionality. The test bed

Figure 3. Test Bed

is illustrated in Figure 3. It contains five main com-ponents. The central component is a server computerrepresenting our unified hub. It controls and monitorsthe rest of the system using custom Java software in-stalled on the computer. A USB-connected X10 remotecontrol is attached to the unified hub to actually switchan air conditioner on and off. The second component isa laptop that represents an intelligent appliance capableof performing autonomous demand response basedupon real-time prices provided by the unified hub overan Ethernet link. It also runs a Java application toactually implement the controls, and controls its ownconnectivity to the power mains using a second USB-connected X10 remote control that sends commandsto a simple “appliance module” interposed betweena power outlet and its power supply (Figure 4c).Power management was disabled on the laptop forthis experiment to provide a more predictable powerconsumption profile, and it did not run any inten-sive applications during the experiments. The thirdcomponent in the apparatus is a permanently-installedwindow air conditioner that is also controlled usingan X10 module, although this module was custom-built since the three-phase wiring of the test apartmentprecluded the use of a standard 220V X10 controlmodule. We use a TrendPoint EnerSure electrical sub-meter to measure the power consumption of the airconditioner and the laptop computer (Figure 4d). It isa Modbus device that is connected to the unified hubusing an 802.15.4 wireless link (Figure 4b). 802.15.4is the MAC layer in the ZigBee network protocolstack, so we refer to 802.15.4 network connections asZigBee connections in the remainder of this section.Finally, we developed a custom digital programmablethermostat that is connected to the unified hub using aserial link so that the hub can adjust its high and lowsetpoints in response to price changes (Figure 4a). Theunified hub is responsible for issuing actual control

Figure 5. Test Bed Display of Air ConditionerPower Requirements Over Time

commands to the air conditioner module, due to aphysical limitation of the X10 controller attached to thethermostat, but the unified hub relies on the thermostatto determine when the control commands should beissued. In a commercial implementation it is likely thatthe thermostat and the hub would be merged into asingle unit.

The Java testbench software used to control theexperiment from the two computers is depicted inFigure 5. The left pane contains icons repesentingeach device in the system. The right pane contains agraphical component that can be used to configure ormonitor the currently selected device in the left pane.The software breaks each physical device representedin the left pane into primitive components that canbe handled similarly by the software, even if thephysical devices are quite different. For example, asingle software component is used to configure thesetpoints on the programmable thermostat and X10lamp dimmer modules, since they are both discretelyvariable controls with a wide range of possible settings.

The setting of any primitive component can berecorded over time using a generic data logger com-ponent, as pictured in the right pane of Figure 5.This component attaches itself as a “decorator” tothe component being logged and can maintain both amemory buffer of a limited number of readings as wellas an on-disk file where readings are archived whenthe memory buffer overflows or the recording processis stopped. The archiver can use a standard Comma-Separated Value (CSV) format for easy import intospreadsheets for analysis, or a more compact binaryformat. We archive measurements of the followingvalues with the indicated periods:

1) Ambient temperature of the apartment (period: asshort as possible, typically 1 second).

Figure 4. Test Bed Equipment

2) High and low setpoints of the thermostat (period:as short as possible, typically 1 second).

3) Current electricity price (period: 1 hour).4) Power consumption of the two appliances under

consideration (period: 3-4 seconds).5) Individual bills for each appliance (period: 3-4

seconds).6) Current charge percentage of the laptop’s battery

(period: 10 seconds).7) States of the X10 relays for the laptop and air

conditioner (aperiodic).This information was all logged in CSV format foreasy analysis using spreadsheet tools.

Every control supported in the Java testbench canbe controlled manually or via a functional scriptingengine. To use scripting, it is necessary to first definevariables for each value that will be used in the scriptto determine control settings. To do this, additionaldecorator components are attached to the desired com-ponents in the testbench, and a variable name for eachcomponent is assigned. Our controls are dependentupon the current price of electricity and the chargecapacity of the laptop battery, so it was necessaryto define variables for those two values. Additionally,the thermostat’s high setpoint was dependent on itslow setpoint, so a variable was defined for the lowsetpoint. Finally, the X10 relay controlling the airconditioner simply imitates the actions of a relay on theprogrammable thermostat, so a variable was defined forthe thermostat’s relay.

Using additional decorator components, we can de-fine an expression that will be periodically evaluatedto determine a new value for each control that isto be scripted. We chose Scheme as our scriptinglanguage because a complete Scheme interpreter hasbeen implemented in Java and can be easily embed-ded in Java programs [9]. We simply create a “let”expression associating the current value of each systemelement being watched with the appropriate variable

name, and insert the control value expression for theelement being updated in the surrounding expression.We then evaluate the expression and use the resultas the new setting for the control. Scheme is a veryflexible higher-order language, so sophisticated scriptscan be developed within this environment.

The test bed is installed in an active single-occupancy apartment with approximately 500 squarefeet of air-conditioned floorspace. The apartment ison the north-facing side of a multi-story apartmentcomplex and is a well-insulated unit constructed inthe late 1990s. The apartment is located in Urbana,Illinois, and is served by AmerenIP. It is enrolledin the Power Smart Pricing plan offered by Ameren(the parent company of AmerenIP), which providesRTP support using day-ahead prices in the residentialmarket. However, our experiments aim to suggest thathourly wholesale prices can be used directly to achieveeconomic benefits for an individual consumer, so wedid not use the day-ahead prices in our experiments.Rather, we used historical hourly prices provided onAmeren’s public website to guide our controls. Sincewe are experimenting with an air conditioning system,we selected prices from days that were as similar aspossible to those on which we performed the experi-ments. We compute a bill for the electricity usage ofthe appliances being metered in our experiments usingthose prices. We compare the two bills and estimate thecomfort level of the occupant throughout the trial pe-riod using recorded temperature measurements to eval-uate the general effectiveness of our demand responsesystem. Note, however, that we are not attempting toprove that the particular demand response algorithmswe use are optimal or even suitable for such a task.The works cited earlier demonstrate the usefulness ofdemand response in general, and these experimentsdemonstrate that MGA is suitable for implementingdemand response systems in a flexible manner.

In the first experiment, we allow the air conditioner

(under the control of the unified hub) and power-awarelaptop to optimize their operation in response to real-time prices. We started this experiment at midnight(00:00) on June 11, 2007, and completed it at eleveno’clock in the evening of the same day. June 11and 12 both had high temperatures of 30.6 deg. C.Thus, we selected real-time prices from May 24, whichreached a high temperature of 31.1 deg. C. The averagerate of electricity on that day was 5.332 cents perkWh. To initialize the experiment, we allowed theair conditioner to adjust the ambient temperature ofthe apartment to a fixed setpoint of 24 deg. C beforemidnight.

We define four different expressions for the controlsin our system. Some of them are dependent upon avalue derived from the current and upcoming pricesof electricity to affect the state of loads. This value iscalculated to be the current price of electricity minus50% of the difference between the price of electricityone hour from the current time and the current price ofelectricity. If that price is not available at the time ofthe calculation, a price forecast based upon past pricescan be substituted, or it can be set to 0 to eliminateits effect. In the following discussion we refer to thisvalue as the “effective price of electricity,” which canbe mathematically defined as follows:

P = Pn − (Pn − Pn+1) ∗ 0.5,

where P is the “effective price of electricity,” Pn isthe current price of electricity, and Pn+1 is the priceof electricity during the next unit of time (hour, inthis case). The effect of this adjusted price value is tomake electricity relatively cheaper when a higher-priceperiod is approaching, and relatively more expensivewhen a lower-price period is approaching.

In the first control expression, we allow the laptop’sbattery to run 10% lower before starting to rechargeitself for every 1 cent increase in the effective priceof electricity beyond a nominal low price threshold offive cents, with a minimum threshold of 50%. We thenallow the battery to remain connected to AC poweruntil its capacity is 10% above that threshold. Thethreshold is actually continuously variable, and doesnot typically change in increments of 10%.

The second and third controls apply to the air con-ditioner thermostat setpoints. We define a maximumlow setpoint of 24.5 deg. C., which maintains an actualambient temperature below 27 deg. C as will be shownlater. So as not to negatively affect the occupant’scomfort level, we will show that we can maintain alow average temperature in the apartment while stillachieving a low average price per kWh by lowering

both setpoints during low-price periods and slightlyincreasing both setpoints during peak periods. Wedefine a nominal high-cost threshold of 12 cents perkWh, and decrease both setpoints from their maximumvalues by 0.5 deg. C for every 2 cent decrease in thecost of electricity. We round the resultant setpoint tothe nearest half deg. C, to correspond to the precisionof the thermostat. Mathematically, disregarding issuesof precision, we can represent the low setpoint asfollows:

S = 24.5− Max(0, (0.12− P ) ∗ 25),

where S is the low setpoint, P is the effective price ofelectricity in dollars per kWh, and the function Maxreturns whichever of its arguments is the greatest. Thehigh setpoint is always 2 deg. C greater than the lowsetpoint.

Finally, we must define a control expression to linkthe X10 relay with the thermostat’s relay. We haveassigned the thermostat’s relay state to the variablerelayOn, so we simply specify that variable nameas the expression to be evaluated.

To provide baseline data against which to comparethe results of our first experiment, we initialized theapartment under consideration to 24 deg. C and thenre-ran the experiment outlined above on June 12. Weset the low setpoint of the thermostat to 23 deg. C, andthe high setpoint to 25 deg. C, which together allow theambient temperature in the apartment to range between22.5 deg. C and 25.5 deg. C. We also configured thelaptop to simply keep its battery fully charged, like astandard laptop.

5. Evaluation and Implications of Results

The experiments described above completed suc-cessfully and produced data supporting the claim thatthe meter gateway architecture is a flexible demandresponse paradigm that supports multiple loci of con-trol. In this section, we describe the results and theirimplications.

The results of the price-adaptive controls for a laptopbattery on its charge capacity over time are presentedin Figure 6a. It is obvious that the laptop relied moreheavily on its battery during times of high prices thanduring low-price periods. The effects of taking futureprices into consideration were also dramatic and can beobserved clearly at 08:00, when prices were relativelylow but still much higher than they were one hour inthe future, and at 15:00, when prices were relativelyhigher but still extremely low compared to prices onehour in the future. The laptop consumed a total of783 watthours, which cost 3.768 cents. In contrast,

Figure 6. Experimental results

during the second experiment the laptop consumedonly 763 watthours, indicating a slight inefficiencyin the charge and discharge process, but incurred anelectricity cost of 4.112 cents. Thus, using its ownembedded intelligence, the laptop responded to RTPsignals to achieve a cost reduction of 8.4% withoutever draining its battery below 54% of its full capacity,although the controls did cause a slight increase inpower consumption.

The results of the price-adaptive controls for an airconditioner on the ambient temperature of the apart-ment in the first experiment are presented in Figure 6b.A moving average of the ambient temperature with awindow size of 17 minutes is used to reduce the arti-facts of boundary behaviors in the digital thermostat.The oscillations between 00:00 and 05:00 are due tothe air conditioner’s internal thermostat, which causesit to stop operating for short periods when the air inits immediate vicinity drops below a certain minimumtemperature. It is apparent that the differential of thecurve is directly proportional to the effective priceof electricity at most points. Periods of temperaturereduction correspond to periods of air conditioneroperation, so this indicates that the air conditionerdid in fact operate during periods with relatively loweffective prices, and rested during periods of relativelyhigh effective prices. This demonstrates that the MGAcan be effectively adapted to control legacy appliancesusing retrofit controllers and a central point of controlwe call the unified hub.

Furthermore, the results suggest that price-adaptivecontrols can lead to a decrease in the average price ofthe electricity consumed by the air conditioner. Duringthe first experiment, the air conditioner consumed a

total of 2573 watthours and cost 11.45 cents to operate,while maintaining an average ambient temperature of23.13 deg. C. On the other hand, during the sec-ond experiment the air conditioner consumed only1781 watthours, but cost 9.41 cents to operate andmaintained an average temperature of 23.99 deg. C.Although using fixed setpoints led to a 31.8% reductionin energy consumption, it only reduced costs by 17.8%.

6. Related Work

Various types of demand-response programs havebeen developed over the past decades. Generally, theyhave achieved little success [10]. This is due to severalreasons. First, demand response participants have typi-cally relied upon manual response strategies rather thanusing automation, although automated response tech-nologies are slowly becoming more prominent, par-ticularly in industrial and commercial buildings [11].Manual strategies are difficult to maintain due to signif-icant volatility in real-time prices, requiring continualstrategy adjustments. Programs have also been poorlyadvertised and promoted, and insufficient effort hasbeen allocated to customer education [12]. That studyalso reports that the only demand response partici-pants that have consistently provided significant loadreductions are those with backup generators and thoseenrolled in demand response programs that imposemandatory load curtailment actions. However, manda-tory programs tend to reduce program participationlevels across all sectors, since customers ranging fromhome-owners to manufacturers all experience periodsduring which they are unable to tolerate service in-terruptions [13]. The architecture presented in this

paper provides automation to reduce the burden oncustomers while still permitting them to have ultimateauthority over their energy usage, unless they enroll ina mandatory program and those controls are disabled.

As discussed at the beginning of this paper, Ad-vanced Metering Infrastructure (AMI) is likely toprovide the communications infrastructure for futuredemand response projects. However, AMI systems arepotentially subject to several security vulnerabilitiesthat could impede their deployment or interfere withtheir operation. These vulnerabilities and a securityarchitecture for mitigating them using virtualizationand remote attestation are presented in [8].

7. Conclusion

We have presented the meter gateway architecture,which provides a general paradigm for automatingdemand response and other controls with support formultiple loci of control, ranging from intelligent appli-ances to remote parties on the other side of the meterfrom homes, businesses, and institutions. We evalu-ated the architecture using a prototype implementationbased on reaily-available commercial components, anddemonstrated its flexibility by simultaneously control-ling a legacy appliance and an intelligent appliance inresponse to fluctuating real-time prices. The results ofour experiments demonstrate the effectiveness of thearchitecture, and also suggest that automated demandresponse strategies will allow electricity customersto achieve cost savings using real-time prices thatwere previously unattainable using manual responsestrategies.

Acknowledgements

We would like to thank the TCIP Center team fortheir feedback on this work. This work was sup-ported in part by NSF CNS05-5170 CNS05-09268CNS05-24695, CNS07-16421, ONR N00014-04-1-0562 N00014-02-1-0715, DHS 2006-CS-001-000001and a grant from the MacArthur Foundation. MichaelLeMay was supported on an NDSEG fellowship fromthe AFOSR. The views expressed are those of theauthors only. TrendPoint graciously donated to theIllinois Security Lab an EnerSure electric submeteringdevice which was used in our experiments.

References

[1] S. Kiliccote, M. A. Piette, D. S. Watson, andG. Hughes, “Dynamic controls for energy efficiencyand demand response: Framework concepts and a new

construction study case in new york,” in ACEEE Sum-mer Study on Energy Efficiency in Buildings, PacificGrove, CA, August 2006.

[2] M. Martinez and F. Russell, “Smart thermostats gettingresults at SCE,” Utility Automation & Engineering,July 2007.

[3] D. Hammerstrom, “The grid friendly appliancecontroller,” http://gridwise.pnl.gov/technologies/transactive controls.stm.

[4] D. Egan, “The emergence of ZigBee in building au-tomation and industrial control,” Computing & ControlEngineering Journal, vol. 16, no. 2, pp. 14–19, 2005.

[5] A. Goodloe, M. McDougall, R. Alur, and C. A. Gunter,“Predictable programs in barcodes,” in InternationalConference on Compilers, Architecture, and Synthe-sis for Embedded Systems (CASES ’02). Grenoble,France: ACM, October 2002, pp. 298–303.

[6] I. Iglesias, L. Garcıa-Tabares, A. Agudo, I. Cruz, andL. Arribas, “Design and simulation of a stand-alonewind-diesel generator with a flywheel energy storagesystem to supply the required active and reactivepower,” IEEE Power Eng. Syst. Conf, pp. 1381–1386,2000.

[7] G. Heffner and D. Kaufman, “Distribution substationload impacts of residential air conditioner load control.”IEEE TRANS. POWER APPAR. SYST., vol. 104, no. 7,pp. 1602–1608, 1985.

[8] M. LeMay, G. Gross, C. A. Gunter, and S. Garg, “Uni-fied architecture for large-scale attested metering,” inHawaii International Conference on System Sciences.Big Island, Hawaii: ACM, January 2007.

[9] S. Miller, “SISC: A complete scheme interpreter injava,” Tech. Rep., 2003.

[10] J. D. Kueck and B. J. Kirby, “Demand responseresearch plan to reflect the needs of the californiaindependent system operator,” Consortium for ElectricReliability Technology Solutions, Tech. Rep., 2004.

[11] Neenan Associates, Ernest Orlando Lawrence BerkeleyNational Laboratory, and Pacific Northwest NationalLaboratory, “How and why customers respond to elec-tricity price variability: A study of NYISO and NY-SERDA 2002 PRL program performance,” New YorkState Energy Research and Development Authority,Tech. Rep., 2003.

[12] G. Barbose, C. Goldman, and B. Neenan, “A surveyof utility experience with real time pricing,” ErnestOrlando Lawrence Berkeley National Laboratory, Tech.Rep., 2004.

[13] B. J. Kirby, “Spinning reserve from responsive loads,”Oak Ridge National Laboratory, Tech. Rep., 2003.