Reference Design for Residential Information Gateways

Document Sample
Reference Design for Residential Information Gateways Powered By Docstoc
					Draft Document: Not for Distribution.

    Reference Design for Residential Information Gateways
                             Phase I: Draft Design
 Note: This document is currently a "straw man" design created for discussion
and clarification. It contains many omissions and assumptions that need further
                                     work.

                                                         Updated: September 29 2009


Table of Contents
Introduction ................................................................................................................................................3 
Home Energy Management System Elements ...........................................................................................3 
   The Advanced Meter ...................................................................................................................................... 4 
   Appliances ...................................................................................................................................................... 4 
   Local Power Generation ................................................................................................................................. 6 
   In-Home Communications ............................................................................................................................. 6 
   Outside World Source of Information ............................................................................................................ 7 
   The Gateway .................................................................................................................................................. 7 
   User Interface ................................................................................................................................................. 7 
   Measuring Instruments for Power Usage, Temperature, etc. ......................................................................... 8 
Ownership ..................................................................................................................................................9 
Related Work ..............................................................................................................................................9 
   Pulse Energy ................................................................................................................................................... 9 
   ZigBee Alliance .............................................................................................................................................. 9 
   Control4........................................................................................................................................................ 10 
Appliance Manufacturers' Perspectives ...................................................................................................10 
   Avante SmartBoxx Technologies ................................................................................................................. 11 
   EcoFactor ..................................................................................................................................................... 11 
   General Electric ............................................................................................................................................ 11 
   Intel .............................................................................................................................................................. 12 
   Tendril .......................................................................................................................................................... 12 
Utilities' Perspectives ...............................................................................................................................12 
   Southern California Edison (SCE) ............................................................................................................... 12 
System Hierarchy .....................................................................................................................................13 
Gateway Design .......................................................................................................................................13 
   Requirements................................................................................................................................................ 14 
   Gateway Hardware ....................................................................................................................................... 14 
   Gateway Operating System .......................................................................................................................... 15 
   Application Software Language ................................................................................................................... 15 
   Software Framework .................................................................................................................................... 16 
   Communication Protocols ............................................................................................................................ 17 
   Reference Design Test Bed .......................................................................................................................... 18 
Bibliography.............................................................................................................................................19 

                                                                                           
                                                                         Page 1 
                                                                                           
Appendix A – Summary of Notes from Gateway Kickoff .......................................................................20 
Appendix B – A Brownout Anecdote.......................................................................................................25 




                                                                              
                                                               Page 2 
                                                                              
    Introduction
Residential electrical load management is a critical part of much of the functionality proposed for the
upcoming "smart grid." (United States Department of Energy Smart Grid Initiative) The United States
Department of Energy’s Smart Grid Initiative places substantial emphasis on consumer inclusion and
resident energy education as part of this effort. With essentially nothing in place at present to
implement residential load management, this project is focused on putting a functional reference design
together that can demonstrate that such a system is technically, economically, and socially feasible.
The Gateway will function as the hub for the Home Energy Management System (HEMS).

When completed, the vision is that such a system would be able to:
  • Communicate with an outside entity to determine the current and/or future cost of electricity
      and system status (normal, emergency, partial curtailment, etc.)
  • Know from previous communication with the resident(s) how to prioritize various load usages
      against price, time-of-day, day-of-the-week, weather, etc.
  • Communicate with an electric meter (either the revenue meter or a separate meter) to determine
      current whole-house electricity usage.
  • Communicate with electrical loads (appliances) to control or suggest current and/or future
      operation.
  • Communicate with loads to determine power usage.
  • Display relevant information to residents.
  • Accept input from residents to change (override) current operating conditions.

Currently, no current residential loads are equipped for this type of communication. In addition, the
"advanced metering infrastructure" (AMI) initiative is just starting so the nature of AMI meters is not
fully known, and there is no infrastructure in place for communication with appropriate outside entities.
For that reason, this project has been divided into two phases. In this, the first phase, the goal is to draft
a design that feasibly approximates the Gateway functionality and communications protocols. In the
second phase, a reference implementation will be constructed to evaluate the strengths and weaknesses
in the draft design and to act as a model for commercial implementations. Given how slowly the
housing stock turns over, assuring that the design will be suitable for future retrofit use as well as for
new construction is a high priority.

While this project is focused on management of residential electrical energy usage, the same concepts
could be applied to other residential utilities such as gas, oil, and water usage as well. In fact, other
household functions such as security and alarms would be good candidates for inclusion in its
functionality as well.

    Home Energy Management System Elements
The envisioned Home Energy Management System (HEMS) consists of:
   • An advanced (AMI) meter
   • Appliances, including HVAC, washing machine, drier, televisions, computers, cooking
      equipment, space heaters, etc.
   • Power generation such as local solar-electric or wind
   • In-home communications

                                                              
                                                  Page 3 
                                                              
     •   An "outside world" source of information, primarily current and future price information, but
         also information about grid status that could require actions in the house
     •   A gateway
     •   User (resident) interface(s)
     •   Measuring instruments for power usage, temperature, etc., as needed

The Advanced Meter
The advanced meter is essential to most smart grid proposals so that electricity can be charged on a
time-of-use basis as well as total usage. (Pacific Gas and Electric Company, 2009). By "meter" what is
meant here is a revenue qualified device from which charges can be derived. Other means of measuring
power may be used, but they would generally not be qualified for revenue use.

From the residence's point-of-view, the advanced meter contains valuable information about current
and past power usage. Current residential meters being installed by PG&E read electricity information
on an hourly basis and transmit this information via RF signals to a network device. The network
device aggregates information from multiple residences and communicates with PG&E access portals
through the cellular phone network. RF communication between the meter and the local network relay
is 2 way. (Pacific Gas and Electric Company, 2009) While the PG&E meter transmits information
hourly; it is likely that the meter will probably maintain a finer granulation internally, at least for short
periods of time, and, it might also have instantaneous power usage information (depending on how it is
making its measurements; the meter is concerned with energy usage in certain time slots rather than
power usage per se). For the purposes of this project, it is necessary to determine exactly how much of
the aforementioned information will be made available on a current basis (as distinct from after-the-fact
information that comes as part of the billing process) and how this information is to be accessed.

Given the availability of 2-way RF communication to the PG&E advanced home energy meter, it is
likely that the Gateway will support RF as a primary means of communication. However, each of the
investor-owned utilities in California is pursuing its own path to AMI so it is equally likely that neither
the communication means nor the information available will be uniform across the state. Other
wireless channels of communication, perhaps ZigBee, must be considered.


    Appliances
It is envisioned that, at some point, appliances will have the ability to communicate with the Gateway.
HVAC (heating, ventilating and air conditioning) affects moment-to-moment comfort of the occupants
and is generally the largest energy user in the house. Also unique from the perspective of the Gateway
project, HVAC systems are the only appliances that have an "open" user interface and for which the
user interface (the thermostat) is usually sold separately.

There are a variety of ways to categorize other appliances. For example, by function:

     •   Cooking and food related
     •   Entertainment
     •   Hot water
     •   Auxiliary HVAC (electric blanket, space heater, window air conditioner, fan)

                                                              
                                                  Page 4 
                                                              
    •   Communication and computing (beginning to overlap heavily with entertainment)
    •   Other

On the other hand, appliances can be categorized by how they are used:

    •   Turned on and off by user (TV, computer, stove, oven, fan, space heater)
    •   Turned on by user, but turn off automatically (Clothes and dish washers, clothes drier,
        microwave oven)
    •   Operate all the time (but most use energy intermittently; refrigerator, hot water heater)

Not all of these appliances are purely electric; wherever large amounts of heat are needed there are
alternatives that operate on gas or oil (hot water heaters, for example). The current Gateway project is
primarily concerned with managing electricity usage; nothing in this work, however, will preclude
managing other energy types as well.

Some appliances can be turned on or off at will, with no serious consequences other than comfort or
inconvenience; others can have safety consequences or could cause damage if turned on or off at
arbitrary times. Air conditioning is a good example of an appliance that falls mostly into the first
category (comfort, convenience) but, at its limits, can have significant safety or damage issues. A
refrigerator, on the other hand, while it can be turned off briefly without any significant consequence,
causes both safety and damage consequences if the temperature rises too high.

An interesting load category that has no significant role in today's electricity usage is the electric or
partially electric automobile. Also known as Plug-in Hybrid Electric Vehicles (PHEVs), the
incorporation of hybrid and electric cars into American consumer culture is thought to make a
substantial impact on electricity demand in the future. (National Energy Technology Laboratory) This
would represent a relatively large load, but one that for the most part could be used at times when other
electricity usage is low — overnight. However, this is also a time when solar power is never available
so could require "undesirable" energy sources if a substantial part of the automobile fleet were replaced
with cars that needed to be recharged at home. The National Energy Technology Laboratory predicts a
5 – 10% increase in energy demand if PHEVs eventually replace 50% of the cars on the road in
America. (National Energy Technology Laboratory). NETL also considers PHEVs as a potential
energy source in the event of large scale brown/blackouts. In this case, these vehicles would represent
a large distributed network of batteries which could be tapped in the case of an emergency.

Many, if not most, modern appliances have a base or "standby" electrical load. The base load can be to
support some function of the device (such as the filament heater on CRT TVs or time or event detection
in devices such as video recorders), or can be associated with how the device gets its power (the "wall
wart" power supply, for example, draws some power even when the device it is connected to is turned
off). Of course, the residential gateway of this project will be an always-on device and thus also
contribute to the base load along with the communications components in many of the appliances.
Reducing base electric load in the house can yield significant savings.

As appliances are where the electric power goes, a major part of this project will be in defining the
appropriate interactions between the residential gateway and various appliances. There will have to be
considerable variation here. Appliance manufacturers will probably be very reluctant to allow direct

                                                             
                                                 Page 5 
                                                             
control of their products by an external controller (with the exception of HVAC equipment which
already allow that). At a minimum, there are liability concerns that must be faced in giving up control.
For these types of appliances, the gateway would provide "advice," or, in process control terminology,
supervisory control. On the other hand, it may be possible to directly control some appliances, for
example, through external power switches, without compromising safety. What information an
appliance will return is also important to the gateway design. Will information on current power usage,
status, time to next power event, etc., be available to the gateway? Then there are legacy appliances.
Like the automobile fleet and the housing stock, appliances are slow to turn over. If it is not safe to
control a legacy appliance with an external power switch, advice can be given to the user in the form of
a display local to that appliance (red, yellow, green lights, small text display, etc.).


    Local Power Generation
If locally generated power, presumably mostly solar-photovoltaic, becomes common it will be the job
of the residential gateway to manage that power and incorporate it into the home’s energy supply, or
sell that excess power back to the utility. At present, solar-voltaic power could well become a reality,
but there is no sign of electricity storage on the horizon that would be safe and economical for
residential use in a size capable of storing several hours of solar-generated electricity. Thus, solar
power will probably have to be used as it's produced. The same problem the grid-based electrical
system has, but on a smaller and more immediate scale.

The interesting decision process with local solar power (local meaning part of the same residence) is
using it to offset grid power during high cost periods. In California that is largely summer air
conditioning, also a good time for solar power. The match is reasonably good as air conditioning can be
shut off on short notice if the solar power dips due to cloud cover. The minimum on time (if that
restriction exists on the AC unit) could require the purchase of high cost grid power for short periods
until shut-off is allowed. Likewise, a minimum off-time would require use of solar power for
something else or sending it to the grid. It will also be interesting to see what price will be available for
sending excess power to the grid during peak price periods.


    In-Home Communications
In-home network communication is almost certainly dominated currently by Ethernet, either wired for
single-room networks or wireless (Wi-Fi) for wider coverage. Ethernet-over-power-line exists for
multi-room configurations, but does not command much of the market. Telephone connections are even
more widely installed, but in-home telephone connections are still almost entirely analog (not packet
based) so do not qualify as network connectivity. Mobile (cell) phone connectivity is also broader, and
is packet based, but requires external infrastructure to operate.

Most talk of in-home networks for energy management focuses on much lower powered wireless than
Wi-Fi. The most common standard for that is IEEE 802.15.4 ("Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-
WPANs)"). ZigBee is the best known standard built on top of 802.15.4. The California investor owned
utilities (PG&E, SCE, SDG&E) have all indicated that they will use ZigBee for communication
between their meters and the in-house gateway.


                                                              
                                                  Page 6 
                                                              
Since 802.15.4 only specifies the MAC and PHY layers for the network, many protocols can be used
for the upper layers. In particular, in a convergence attempt, 6LoWPAN builds Ethernet upper layers on
top of 802.15.4 lower layers. These low power standards are very important where network nodes that
must be self-powered are used. Most of the connections anticipated to the gateway would be from line
powered devices so there is no need for long-term battery or parasitic power sources. However, if
measurements such as distributed temperatures are needed, these low-power connections could be
important.

It seems unlikely that all of the manufacturers of devices that could be connected to the gateway would
agree on a single communication standard. Thus, it is expected that the gateway would have to be able
to communicate internally using multiple protocols and media.


    Outside World Source of Information
The traditional model for residential energy pricing, constant cost per energy unit ($/kwhr), is
inconsistent with the wholesale electrical energy market in which pricing varies widely, depending on
demand and supply conditions. Concepts for the "smart grid" include some degree of realignment of
retail pricing to wholesale reality which would have to include some form of variable pricing. The
gateway's ability to communicate with the outside world is primarily for it to get current and future
pricing information. In addition, grid operational issues such as emergency conditions could also be
communicated along with suggested (or mandatory) responses. More general communication would
also allow the gateway to get information such as weather forecasts that it could use in managing
energy usage.

A number of mechanisms for external communication exist or could be activated relatively easily.
These include:
   • Radio Data System (RDS, or Radio Broadcast Data System, RBDS, the official name in the
       U.S.). This is a one-way, low bandwidth system that utilizes an FM radio subcarrier to embed
       text-based information.
   • Internet connection. This could be achieved via cable, DSL, wireless connection (such as Wi-
       Max if it ever builds out), or the cell phone network (which will soon overlap very much with
       Internet-oriented wireless media such as Wi-MAX).
   • Pager systems. Perhaps becoming obsolete, but still available for one or two way connection.
   • Connection to the meter, acting as a communication center to the electricity provider (probably
       by ZigBee, see above).


    The Gateway
The Gateway is the main focus of this project so it has its own section.


    User Interface
The Department of Energy considers user involvement/education as a key pillar of the future Smart
Grid in the US. (United States Department of Energy Smart Grid Initiative) The only user interface
most residential electric customers have today is the monthly bill. This aggregates all usage for the

                                                            
                                                Page 7 
                                                            
month, so the user has no way of knowing what the power was used for and, by extension, how to use
energy more effectively. The gateway's user interface must play the roles of both informing the user of
how energy is being used in the house and, in a manner consistent with the usage and cost information
that is presented, allow the user to make choices about priorities for energy usage during periods when
prices are higher than that household is willing to pay.

This view is widespread as evidenced by Google's introduction of its "Power Meter" and Microsoft's
Hohm.

From Google:

       " "If you cannot measure it, you cannot improve it." — Lord Kelvin

       "How much does it cost to leave your TV on all day? What about turning your air conditioning
       1 degree cooler? Which uses more power every month — your dishwasher or your washing
       machine? Is your household more or less energy efficient than similar homes in your
       neighborhood?

       "It's nearly impossible to make informed choices about electricity. ... Studies show that access to
       your household's personal energy information is likely to save you 5–15% on your monthly bill.
       ..."
       (from http://www.google.org/powermeter/)

From Microsoft:

       "With Microsoft Hohm you can better understand your home energy usage, get
       recommendations to conserve energy and start saving. As with any recommendation engine,
       Hohm will provide increasingly more accurate and relevant suggestions for energy conservation
       as its users contribute home energy input and feedback."
       (from http://mshohm.orcsweb.com/)

The physical form the user interface will take, however, is likely to be very fluid. The gateway could
have a conventional, dedicated user interface, but it could also be accessed from a personal computer or
from a mobile phone. An interface to Google's Power Meter would be logical as well.

A clear conclusion is that the gateway must support a wide variety of user interfaces, from very simple
interfaces, not much more than a standard thermostat, to interfaces allowing sophisticated user
interaction, and also information-based interactions with third-party interfaces such as those of Google
and Microsoft.


Measuring Instruments for Power Usage, Temperature, etc.
A wide range of measurements would be useful to the gateway in managing electrical energy usage.
Very low powered wireless networks (such as IEEE 802.15.4) have opened up possibilities for such
measurements by removing the prohibitive costs of wiring associated with making measurements in the
home. The two measurements that would probably be most useful are power consumption for

                                                            
                                                Page 8 
                                                            
appliances that do not report their usage (that would be all legacy appliances) and occupancy.
Following close behind is temperature measured at various places in the house.


    Ownership
The utility delivering power clearly owns the meter; the resident clearly owns the appliances. The
gateway is in the middle and some design decisions will depend on its ownership. The operational issue
involved is whether the utility in its interaction with the gateway will be making direct control
decisions (e.g., turn thermostat up by X degrees) or whether the pricing will come from the utility but
actual control decisions will be controlled by the gateway based on user preferences, or directly
controlled by the user through overrides. "Load switch" programs, in which utilities install switches
that can limit air conditioner use and directly control those switches, are examples of direct utility
control of appliances. (SCE Summer Discount Program, 2009)

The major difference that ownership would make is control of the software in the gateway. The
gateway has one essential external connection -- to the source of pricing information, and one
important external connection -- to the meter for power usage information. If the utility controls these
to the extent that only authorized software could be used, that would be very closely equivalent to
utility ownership of the gateway. Intermediate situations are also possible where authorization is only
extended to part of the software, for example, the security package, but other aspects of the software
are open.

For the purposes of this project ownership will be considered to be with the resident, with no
restrictions on the software that can be used in the gateway.


    Related Work
Pulse Energy
Pulse Energy provides web based energy management software which can quickly collect and
distribute building energy data to building occupants, management and the building manager.
Information can be accessed easily by logging into a generic website. Information transferred via the
web is analyzed via Pulse Energy servers, which are more computationally powerful than a local
desktop. (Pulse Energy , 2009)

This type of web based analysis has several advantages, as it allows users to compare their building’s
energy usage data with that of other buildings on the Pulse Energy network. Data is collected via the
Pulse Energy servers, normalized to provide several benchmarks then published via the Pulse Energy
web portal. Building energy information is stored at a maximum value of once per minute for some
devices.


ZigBee Alliance
The ZigBee Alliance (www.zigbee.org) currently provides a product entitled Smart Energy, which
gives utilities and energy service providers a HAN dedicated to managing energy in light commercial

                                                            
                                                Page 9 
                                                            
or residential applications. (ZigBee Alliance, 2009) Smart Energy purportedly gives users access to
thermostat controls and dominion over other smart appliances. Smart Energy is currently being
implemented in wired and wireless forms in a partnership between the ZigBee Alliance and the
HomePlug Alliance. (ZigBee Alliance, 2009)

Smart Energy provides metering support for multiple quantities, including gas, electric, water and
thermal. It is powered either via batteries or the main. With regard to energy metering specifically,
Smart Energy can measure load profiles, power factors, demand, etc. Measured data is also logged for
future analysis purposes. Smart Energy can provide real-time generation/consumption information
(provided local generation exists). (ZigBee Alliance, 2009)

With regard to demand response and load management, Smart Energy allows for the scheduling of
multiple events (or load scenarios), and provides the ability to individually target specific groups of
devices (lighting, HVAC, water heating, etc.). Customer control is guaranteed via a built in override
support.

Security is provided via network registration, similarly to Wi-Fi networks, via pre-installed keys or
standard public key cryptography. Data encryption is also supported. Smart Energy also supports text
messaging features to relay information to the resident. A list of products which support the Smart
Energy HAN can be found on the ZigBee website:
(http://www.zigbee.org/Products/CertifiedProducts/ZigBeeSmartEnergy/tabid/271/Default.aspx).


Control4
Control4 Energy Systems provides a bundled product known as the Energy Management System
100™. The package includes home energy controller, the EC-100, a wireless, programmable
thermostat, the WT-100, the Control4® Network Management and Energy Analytics software
packages. (Control4, 2009)

All products within the bundle have connectivity via the HAN (ZigBee in this case). The Energy
Management System 100™ communicates in real time with utility load management software (LMS).
Consumers can then set the EC-100 home energy controller to control devices during peak times or act
on demand response events. The EC-100 can also perform functions outside the realm of demand
response/load management, including checking the weather, downloading podcasts and displaying
pictures. (Control4, 2009)

The WT-100™, the wireless programmable thermostat communicates via ZigBee to the EC-100™ and
runs on battery power (2-3yr lifespan). Control4 claims the installation of the programmable
thermostat is a simple process. The bundle supports (in addition to ZigBee) Wi-Fi 802.11b/g and USB.
More information regarding the Energy Management System 100™ can be found on the Control4
website (http://www.control4.com/energy/energy-products/).


    Appliance Manufacturers' Perspectives
The following information was compiled from notes taken from the Reference Design for Residential
Gateway meeting, held on July 24th, 2009.
                                                            
                                                Page 10
                                                            
Avante SmartBoxx Technologies
    •   Essential Gateway functions include communication of pricing information. The Gateway must
        also be capable of initiating demand response functions.
    •   The Gateway should use standard in-home communication methods to communicate with
        residential devices (Wi-Fi).
    •   External communications could be accomplished inexpensively using cellular networks
    •   All communications/transmission protocols must allow for data transmission
    •   The Gateway should support connectivity to a limited number of HAN communication
        protocols (ZigBee, HomePlug, or hardwired connections).
    •   Gateway residential load management automation should be scalable to eventually include
        other automation functions: security, energy, medical.
    •   The Gateway should be non-intrusive to the user/resident.
    •   Gateway should be compatible with fixed income devices used in HANs.
    •   The Gateway should allow for customer remote access (PDA, cell phone, web site, etc.)
    •   Gateway should have expandable ports (wired/wireless) for increased functionality.
    •   Allow utility companies to issue automatic load management
    •   Communicates energy savings to end user


EcoFactor
    •   The Gateway should address what customers want, and what they are willing to purchase.
    •   We need to architect Gateway to allow internet applications to be implemented, similarly to
        iPhone and Facebook Apps. This would encourage a developer community to grow around the
        Gateway.
    •   In order to encourage an App development community to grow, we need to build web service
        capabilities into the core Gateway architecture.
    •   With a plethora of Apps to choose from, the user can choose which Apps he/she wants to
        implement on the Gateway (an App store).
    •   The Gateway should not rely on consumer Wi-Fi configuration for broadband access.
    •   The Gateway should not require configuration once purchased, simply plug and play operation.
    •   Gateway should be low-cost and have user-friendly security


General Electric
    •   Should the Gateway wish to accommodate a variety of adaptors (U-SNAP, USB), the
        administration of these adaptors will burden utilities and vendors, and frighten consumers.
    •   Network registration of the Gateway will be difficult for residents/users. It would be best if the
        Gateway were Plug and Play.
    •   Which entity will have ownership of the Gateway? The user or utility company?
    •   Security issues must be addressed. If 2 residences next door to each other both have a Gateway,
        we need to ensure that appliances and meters do not cross communicate. We also need to
        securitize data.

                                                            
                                                 Page 11
                                                            
     •   In order to implement rate structures load management, the Gateway will need a real-time
         signal and periodic connection to the advanced meter.
     •   The Gateway should be able to translate consumer preferences into load control strategies.
     •   The consumer must be able to override the Gateway load management. Lack of control will
         scare consumers.
     •   The Gateway should be a low-cost product which can adapt to all HAN protocols as an
         interface to Smart Appliances.


Intel
     •   Consumer empowerment is paramount. The Gateway should serve to give the consumer
         choices.
     •   The Gateway should always be available (low-power state, dynamic power management) and
         be able to be managed remotely.
     •   The REG should be highly programmable to allow for software updates.
     •   The Gateway should be able to manage less intelligent devices.
     •   The Gateway should be able to process multiple real-time streams of data.
     •   The Gateway should process variable rate information published by utility companies and real-
         time energy usage data published by the AMI.
     •   Gateway communications protocols must include: AMI, broadband internet, and a
         communications module slot that would enable connections 2 way narrow band
         communications through utility meter (ZigBee or HomePlug), or a 1 way transmission via radio
         broadcast.


Tendril
     •   The Gateway needs to maintain sufficient security levels in other networks if they tie into
         utility-related data.
     •   We believe the Gateway should adopt the distributed intelligence model, which has the
         following advantages: reducing IP traffic, managing FW upgrades locally, and interact with
         other home networks.
     •   With regard to other network interaction, should the Gateway should interact with other home
         energy networks and make decisions on a neighborhood scale?
     •   We need to address how the Gateway will handle multiple energy service providers (ESPs).


    Utilities' Perspectives
Southern California Edison (SCE)
SCE’s new advanced meters have built-in wireless radio chip which will enable communications with
smart appliances and thermostats within the home, allowing the user/resident to program these devices
independently. SCE also desires that the advanced meters communicate electrical usage information to
the resident. The UI responsible for allowing the user thus type of access is not specified by SCE. This
is a role the proposed residential Gateway could fill nicely.

                                                           
                                                Page 12
                                                           
With the new AMI being capable of receiving TOU pricing and other demand response information, it
might not be necessary for the Gateway to obtain this information independently from the internet.
Such information could be relayed to the meter directly by the utility company, and then beamed over
radio to the Gateway for action or display to the user. (Southern California Edison, 2009)


    HEMS System Hierarchy
The system hierarchy, Figure 1, shows the abstraction level of various system components. The purpose
of the hierarchy is to define command and communication interactions. Information (blue) can be
exchanged with components at the same level and with components one level up and down from a
given component. Commands (or requests for actions, shown in red) can be issued to components one
level down in the hierarchy.




Following the hierarchical rules makes system design much more modular and reduces the instance of
unpredictable system behaviors. Modular design for the gateway system will be very important because
the system will have to evolve as new modes of operation are devised and as the collection of
appliances in a house change.


    Gateway Design
Much debate remains as to whether the Gateway functionality should be a centralized or distributed
system. A fully distributed system could realize most or all of the functionality described in the
introduction. The major disadvantages to a fully distributed system are that:
    • There is no possibility for optimization within a residence.
    • Appliances must all be capable of communicating directly with the outside world. With no
       guarantee that a single communication standard will emerge nationwide this will increase the
       complexity for all appliances rather than just for the gateway.
    • There is no central user (resident) interface. Each appliance would have its own. Setting user
       preferences (how to respond to price changes, for example) would require running around to all
       of the appliances and using a different user interface in each for that purpose. Something like
       running around the house to change clocks for daylight-standard time switches.

                                                          
                                               Page 13
                                                          
     •   The lack of a central user interface would greatly reduce user education possibilities, generally
         regarded as an important part of modern energy management.

Given the above constraints, we feel that the incorporation of the Gateway into a fully or at least
partially centralized device within the residence is of critical importance to the success of this project.

    Requirements
The reference design is intended as a proof-of-concept that a residential gateway can be effective and
economical. As such, it has to:

     •   Have all of the major components that a commercial gateway would need,
     •   Show that it operates and performs the energy management functions needed for "smart grid"
         concepts currently being developed,
     •   Run on a computationally modest enough platform to prove economic viability for a
         commercial product,
     •   Have strong modularity so various organizations can work independently,
     •   Demonstrate connectivity using several networking media,
     •   Provide for secure operation,
     •   Be field upgradeable for core software upgrades as well as addition of new modules,
     •   Provide flexibility for various user interface options.


    Gateway Hardware
The closest model to the residential gateway for energy management is the home router used to manage
access to the Internet from a home network and to manage the interconnection of computers in a home
network (it is also called a residential gateway, see http://en.wikipedia.org/wiki/Router, for example).
These are relatively low cost devices ($50 to $150 depending on features, speed, etc.) but have
considerable internal complexity. They have been very successful commercially.

The home routers are built on a base processor capable of supporting standard operating systems (such
as Linux). Linksys home routers (or at least some of them), for example, use MIPS family processors
(http://en.wikipedia.org/wiki/Linksys_WRT54G_series ). They generally have much less memory and
mass storage than general purpose computers; flash memory is used for mass storage.

The energy management residential gateway differs in a number of ways from the home router, but
there are enough similarities to use the home router as a starting point for a reference design. On the
one hand, the home router has a more limited function -- it only has to provide local and wide area
network connectivity whereas the energy manager has to deal with a wide variety of appliances, several
network media, and quite sophisticated interaction with the user (most people who own home routers
have probably never looked at its user interface!). On the other hand, the time constraints on the energy
manager are much looser. The home router has to deal with up to hundreds of packets per second
(home routers can handle up to 1 Gbit/sec networks) while time constraints in the order of seconds or
minutes are more the norm for the energy management gateway.

A commercial residential (energy) gateway would probably have a design similar to the home router,

                                                              
                                                  Page 14
                                                              
except with more memory and mass storage. For this project, developing a reference design, designing
a custom board for the proof-of-concept computer is not an option (due to time and cost). Thus, a fully
functional, off-the-shelf system is needed as a reasonable substitute. The class of computer called a
"Netbook" fits that bill nicely (http://en.wikipedia.org/wiki/Netbook). They are computationally much
less capable than a standard PC, but can run most of the same operating systems. They are low enough
cost ($250-$500) so that a custom design based on the reference design could be well within cost
constraints of a residential gateway for energy management.


    Gateway Operating System
For computing systems produced in large quantities and not requiring "desktop" access by users, a
royalty-free operating system is a logical choice. The major candidates for that, following the home
router model are Linux (used by Linksys and others,
http://en.wikipedia.org/wiki/Linksys_WRT54G_series ) and freeBSD (used by Juniper,
http://www.enterprisenetworkingplanet.com/news/article.php/3759876 ). Cisco, the largest supplier in
the router market, uses an internally developed operating system for its larger routers; Cisco owns
Linksys which serves as its home router division. Linksys also uses a commercial real time operating
system for some of its home routers, VxWorks, made by Wind River Systems.

Using a Netbook as the platform for the residential gateway reference design, Linux would be a good
choice as the operating system since many Netbooks can be purchased with Linux already loaded.
However, some of the communication interfaces, such as ZigBee, may not be available for Linux or
may be more difficult to use. If that is the case, a Windows based Netbook could be used. The
application software would then have to be done in a way that it could be easily ported to Linux or
freeBSD.


    Application Software Language
Strong opinions abound on which language is "best." The first part of the decision is what level of
language should be used. For a project such as this one, the choice is between compiler-type languages
(C, C++, C#, and Java are the main choices there) and scripting languages (PHP, JavaScript, Python are
a few of the choices). Scripting languages are generally simpler to use (that is, to write programs) but
execute much less efficiently and are not as well organized as compiler languages. Script languages are
most commonly used for client-side computing in browser-to-server web interactions. Compiler
languages are used as core code in large numbers of computer applications of all sorts.

The residential gateway most resembles a core computer application and computing efficiency will be
an issue since commercial versions will have to be cost optimized. For those reasons, a compiler
language is a reasonable choice. Of those widely available, C++, C#, and Java are object-oriented; C is
not. Object-oriented design generally produces cleaner, more readable programs so should be the
choice here. Of the three left, C++, C#, and Java, Java is the most portable while C++ probably
produces the most efficient execution and smallest footprint. In terms of language, C++ is more
primitive and harder to use because it evolved from C and contains C as a subset. C# and Java are more
modern in construction and more efficient for programmers. Because the code produced in this project
could well be used on a variety of platforms (for example, see the Windows-Linux discussion, above),
portability is a very large factor. Because the reference design has a short time-line and limited budget,

                                                            
                                                Page 15
                                                            
programmer productivity is very important.

Putting all of this together, Java appears to be a good choice. In addition to the factors listed above,
there is a very large developer community and many packages for mathematics, graphics, user
interface, networking, etc., are openly available.


    Software Framework
While it is possible (and common) to write the application software “from scratch,” using various
packages as needed for specific functionality, it might be hard to accomplish all of the goals listed in
the introduction. In particular, the goals associated with modularity and field upgradeability are
difficult to achieve with written-from-scratch applications.

A software framework for Java applications is available that purports to specifically solve these
problems. The OSGi Alliance maintains a specification for “The Dynamic Module System for Java”
(from http://www.osgi.org as are subsequent quotes in this section; thanks to Ed Koch for suggesting
OSGi). The initials come from “Open Services Gateway initiative,” a term no longer used, but the
initials remain. According to their web site, some of the primary benefits are (OSGi Alliance, 2009):

     •   Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi
         components. Bundles are modules. They hide their internals from other bundles and
         communicate through well defined services.
     •   The OSGi framework is dynamic. It can update bundles on the fly and services can come and
         go. … For example, a service could model a device in the network. If the device is detected, the
         service is registered. If the device goes away, the service is unregistered.
     •   The OSGi component model is a dynamic model. Bundles can be installed, started, stopped,
         updated, and uninstalled without bringing down the whole system.
     •   The OSGi component model is designed from the ground up to allow the mixing and matching
         of components.
     •   Overall, OSGi likely provides one of the most secure application environments that is still
         usable ...

Historically, OSGi was intended for use in the home automation market so is likely to be applicable to
the residential energy management gateway. This quote (also from their web site) shows how they
claim to deal with the some of the same design problems this project has identified:

         "For example, you have a home server that is capable of managing your lights and appliances. A
         component could allow you to turn on and off the light over a web page. Another component
         could allow you to control the appliances via a mobile text message. The goal was to allow
         these other functions to be added without requiring that the developers had intricate knowledge
         of each other and let these components be added independently."

OSGi is available in several open versions, Apache Felix (http://felix.apache.org/site/index.html),
Eclipse Equinox (http://www.eclipse.org/equinox/), and Knopflerfish (http://www.knopflerfish.org/).
In addition, the OSGi framework is currently supported by a wide variety of companies and continually
increasing in popularity. A list of companies who currently support the OSGi framework can be found

                                                              
                                                  Page 16
                                                              
here: http://www.osgi.org/About/Members.

To date, we have experimented a great deal with the Eclipse Equinox implementation of OSGi. Eclipse
supports an OSGi bundle creation wizard which facilitates the incorporation of the OSGi framework
into larger programs. There is also substantial literature on the web on the web to support the
development of OSGi bundles (a synonym for plug-ins in JAVA) in Eclipse Equinox. Further
investigation is necessary to determine if such a support community exists for Apache Felix and
Knopflerfish as well.
Eclipse Equinox also implements the OSGi runtime environment directly into its IDE. This runtime
server supports the dynamic incorporation of OSGi bundles without the need to restart the IDE. OSGi
bundles can be installed, uninstalled, updated, and executed independently of one another (unless their
dependency is specified), without interrupting other running bundles. This environment would serve as
an excellent platform for the Gateway to register external services (such as appliances) without the
need to restart itself. The OSGi runtime can also be run independently of Eclipse, as a standalone
server.

In order to connect to the OSGi runtime, bundles will need to implement a standardized interface and
publish a MANIFEST.MF file (which contains configuration parameters read by the OSGI runtime).
Outside of the Eclipse IDE, which implements the Equinox OSGi, it appears that using the OSGi
framework to create bundles is not overly complicated, and could be performed without needing a
wizard. This would allow OSGi bundles to be created without being restricted to a particular IDE, such
as Eclipse.

    Communication Protocols
Networked communication protocols are customarily described by a layered model, the OSI Seven-
Layer model being the most commonly cited. For purposes of this project, however, the focus is on the
upper layers, often called the application layer. For the lower layers, existing protocols and standards
will be used. The sister project to this one, "Establishment of a 7-Layer OSI Stack Basis For
Developing and Testing Interchangeable 2-Way Narrowband Wireless Communications," will be
working to reconcile protocols suitable for very low powered devices with the very commonly used
TCP/IP protocols. Any result from that project will be incorporated into the gateway reference design
work as appropriate.

The top layer protocols are what establish the character of applications. They are perhaps the most
sensitive part of this project in the sense that for commercial implementations, all of the players must
agree on a set of protocols otherwise systems will devolve into proprietary islands. Ultimately, such
standards will have to be the product of an alliance of interested parties. One such standard that has
been promulgated is from ZigBee, "ZigBee Smart Energy Profile Specification" (ZigBee Document
075356r12ZB, Feb. 22, 2008, see also the section on Related Work, above; a new version of this is due
out shortly). ZigBee however, is a closed alliance in the sense that it supports only a single low-level
technology and there are membership and license fees associated with using its standards. These
standards would not apply, for example, to appliance manufacturers who chose some communication
technology other than ZigBee.

The communication protocols have both “vocabulary” and a “syntax” components. The syntax part
describes how communications are constructed and what rules apply so that various parts of a
                                                            
                                                Page 17
                                                            
communication, e.g., target, command, parameters, can be extracted from a communication. The
vocabulary describes the content, what the communication says. Both of these components require
broad approval if the system is to remain open.

A major goal of this project will be to use whatever information is available to develop a simplified set
of protocols that can support the reference design. Developing a full, commercially usable protocol set
is beyond the scope of this project.

    Reference Design Test Bed
The test bed is the demonstration facility to show that the gateway is operating properly. It should be
capable of exercising the gateway in many different scenarios with the capability to document behavior
and test for correct behavior, automatically, where possible. The test bed is also the “museum” for the
project, so anybody who is interested in the work can get a quick, graphic overview of what it does and
how it does it. The software architecture should also allow for stakeholders to add modules to the
gateway to demonstrate behavior of their aspect of the system.

The gateway does not directly control any physical systems; rather, it communicates with systems that
themselves have computer based controllers. Thus, the initial test bed can be fully simulated. The
simulation can be run on a standard PC, running Windows or Linux, as convenient. The simulation
would start with a house model. The model currently being developed under the CIEE project,
“Development of an HVAC Load Model for Aggregates of Homes,” will be a good starting point
although it will probably need to be converted from C to a more convenient language (D. Auslander is
also PI of that project). For this project, the models for the appliances would be expanded to include
communication and some kind of intelligent controller for new appliances designed for interaction with
an energy manager.

The next test bed step would be to include some real equipment along with the simulation (a mixed
configuration often called "hardware in the loop" in control system simulation). Which equipment to
include would depend on what factors appear to be most critical from the pure simulation testing.




                                                            
                                                Page 18
                                                            
Bibliography
Control4. (2009). Control4 Energy Management System 100 (TM). Retrieved September 22, 2009,
from Control4 Energy Systems: http://www.control4.com/energy/energy-products/

National Energy Technology Laboratory. (n.d.). A Systems View of the Modern Grid: Advanced
Components. Retrieved August 24, 2009, from United States Department of Energy:
http://www.netl.doe.gov/moderngrid/docs/Advanced%20Components_Final_v2_0.pdf

OSGi Alliance. (2009). Benefits of Using OSGi. Retrieved August 24, 2009, from OSGi:
http://www.osgi.org/About/WhyOSGi

Pacific Gas and Electric Company. (2009). SmartMeter - How The System Works. Retrieved August 24,
2009, from Pacific Gas and Electric Company:
http://www.pge.com/myhome/customerservice/meter/smartmeter/howsystemworks/

Pulse Energy . (2009). How It Works. Retrieved September 22, 2009, from Pulse Energy - Energy
Management Software: http://www.pulseenergy.com/product/how-it-works/

SCE Summer Discount Program. (2009). Summer Discount Plan. Retrieved July 2009, from Southern
California Edison: https://www.sce.com/NSD/EventStatus.aspx

United States Department of Energy Smart Grid Initiative. (n.d.). Modern Grid Systems View: Appendix
2. Retrieved August 18, 2009, from The Modern Grid Initiative:
http://www.netl.doe.gov/moderngrid/docs/Motivates%20and%20Includes%20the%20Consumer_Final
_v2_0.pdf

ZigBee Alliance. (2009). ZigBee Smart Energy. Retrieved September 22, 2009, from Zigbee.org:
http://www.zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergyOverview/tabid/431/Default.a
spx

ZigBee Alliance. (2009). ZigBee Smart Energy Features. Retrieved September 22, 2009, from ZigBee
Smart Energy:
http://www.zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergyFeatures/tabid/430/Default.as
px




                                                         
                                              Page 19
                                                         
Appendix A – Summary of Notes from Gateway Kickoff

09/24/2009
Introduction – Ron Hofmann
    •   Smart Grid compatibility: interoperability of proposed gateway is paramount 
    •   Gateway application: residential/home or light commercial space energy management 
    •   This project will be related to the Smart Grid center being established at Sac State. 
    •   Gateway Reference Design: NOT A PRODUCT, the reference design will help industry develop 
        commercially available devices 
    •   The purpose of this research project is to outline the reference design 

Introduction – Ron Hofmann’s Image of AMI-HAN Interface
    •   Ron’s perspective: consumer/customer choice is paramount.  The gateway will inform the customer 
        and enhance their ability to make more intelligent choices about home energy management. 
    •   Communication with utility companies to home accomplished via PLC or WIFI 
    •   Communications protocols: Gateway communication must be able to communicate with the 45+ 
        potential home energy networks available today. 
 
Gateway Goals – Dave Auslander 
   • Phase 1: Pick reasonable set of possibilities for Gateway functionality, determine economic feasibility 
      and develop design specifications. 
   • Phase 2: Build a functioning model of the Gateway (simulation first, then hardware) 
   • Companies will utilize the reference design to create successful products 
   • Gateway must have all components a commercially available gateway would need 
   • Gateway must perform all operations required for interaction with Smart Grid 
   • Software must function on a computationally modest platform 
   • Gateway must have strong modularity 
 
Gateway Requirements/Components – Dave Auslander 
   • Gateway must demonstrate connectivity using several networking media 
   • Provide for secure (encrypted?) application 
   • Must be field upgradeable 
   • Must provide flexibility for various user interfaces 
   • Hardware: residential internet router 
   • OS: Linux for prototype, windows/Linux for development 
   • Application software: JAVA 
   • Software framework: OSGi?  This framework is purported to provide increased modularity 
   • Communications protocols: must be kept reasonably simple given the time limit of this project 
   • Test Bed: Develop simulation with live communications and then add hardware. 
 
Company Presentations 

                                                               
                                                  Page 20
                                                               
Avante SmartBoxx Technologies 
   • Essential Gateway functions include communication of pricing information.  The Gateway must also be 
       capable of initiating demand response functions. 
   • The Gateway should use standard in‐home communication methods to communicate with residential 
       devices (Wi‐Fi). 
   • External communications could be accomplished inexpensively using cellular networks 
   • All communications/transmission protocols must allow for data transmission 
   • The Gateway should support connectivity to a limited number of HAN communication protocols 
       (ZigBee, HomePlug, or hardwired connections). 
   • Gateway residential load management automation should be scalable to eventually include other 
       automation functions: security, energy, medical. 
   • The Gateway should be non‐intrusive to the user/resident. 
   • Gateway should be compatible with fixed income devices used in HANs. 
   • The Gateway should allow for customer remote access (PDA, cell phone, web site, etc.) 
   • Gateway should have expandable ports (wired/wireless) for increased functionality. 
   • Allow utility companies to issue automatic load management 
   • Communicates energy savings to end user 
        
EcoFactor 
   • The Gateway should address what customers want, and what they are willing to purchase. 
   • We need to architect Gateway to allow internet applications to be implemented, similarly to iPhone 
       and Facebook Apps.  This would encourage a developer community to grow around the Gateway. 
   • In order to encourage an App development community to grow, we need to build web service 
       capabilities into the core Gateway architecture. 
   • With a plethora of Apps to choose from, the user can choose which Apps he/she wants to implement 
       on the Gateway (an App store). 
   • The Gateway should not rely on consumer Wi‐Fi configuration for broadband access. 
   • The Gateway should not require configuration once purchased, simply plug and play operation. 
   • Gateway should be low‐cost and have user‐friendly security 
        
General Electric – Charlie Smith 
   • Should the Gateway wish to accommodate a variety of adaptors (U‐SNAP, USB), the administration of 
       these adaptors will burden utilities and vendors, and frighten consumers. 
   • Network registration of the Gateway will be difficult for residents/users.  It would be best if the 
       Gateway were Plug and Play. 
   • Which entity will have ownership of the Gateway?  The user or utility company? 
   • Security issues must be addressed.  If 2 residences next door to each other both have a Gateway, we 
       need to ensure that appliances and meters do not cross communicate.  We also need to securitize 
       data. 
   • In order to implement rate structures load management, the Gateway will need a real‐time signal and 
       periodic connection to the advanced meter. 

                                                            
                                                Page 21
                                                            
    •   The Gateway should be able to translate consumer preferences into load control strategies. 
    •   The consumer must be able to override the Gateway load management.  Lack of control will scare 
        consumers. 
    •   The Gateway should be a low‐cost product which can adapt to all HAN protocols as an interface to 
        Smart Appliances.  
 
Intel – John Thomas 
    • Consumer empowerment: consumer should have choices in load management. 
    • Gateway should adopt international IP standards 
    • Gateway should ensure interoperability, security, manageability 
    • Low‐power mode, fast wakeup 
    • Remote management (via internet or smart phone) 
    • Field upgradeable via software push, 3‐5yr lifespan 
    • Can receive and process real‐time data (utility variable rate information) 
    • Communications: must support broadband and AMI 
    • 2‐way narrow band communications: RF, PLC 
    • 1 way communication broadcast: pager or local radio 
    • Hardware interfaces to include USB 
    • Gateway should enable Home Energy Management System (HEMS) to have some centralized storage 
         and distributed control/execution. 
 
Tendril – Tim Hughes 
    • Concerned with security when exchanging utility type data 
    • IP/HAN communications: 802.15.4 
    • Distributed intelligence model: reduce IP traffic within HEMS, would be easier to manage firmware 
         upgrades 
    • Gateway should interact with other home energy networks and make decisions on neighborhood scale 
         (load management for communities). 
    • How will the gateway manage multiple ESP (energy service providers)? 
    • Will the gateway be extended to manage gas and water utilities? 
 
Q&A 
 
Ed Koch 
    • Concerned with cost of installation.  We should attempt to keep installation costs low. 
    • Use cell phones as a method to communicate with user 
 
Carl Brown 
    • Tie in gas and water meters to gateway 
    • How serious are we about light commercial spaces? 
 

                                                              
                                                  Page 22
                                                              
Kirk Oatman: I’m In Control 
    • Is the gateway going to allow utility to come in and do direct control of will it support increased 
        competition in market of control for companies? 
    • Would this competition limit consumer options? 
    • Are we defining sets of functionality for the HEM, or are we providing a communications portal for all 
        home devices and utilities? 
    • We need to have a set of specs for appliances manufacturers and HEN providers within 1 year MAX. 
 
Chuck McParland: LBNL 
    • We should perform a literature search of Gateways in development, to prevent loss of engineering 
        hours. 
    • As Gateway systems evolves into control systems, will they be reliable? 
 
Nate Ota (phone) Trilliant 
    • We need a standardized definition of the Gateway 
    • Should we pay attention to NIST standards?  What about ZigBee, ISO 15045? 
    • Is the gateway going to be a utility owned device which will plug into/communicate with user owned 
        devices? 
    • Does the gateway need to be a standalone device?  Could it be a software package embedded in a 
        thermostat, for example? 
    • Whatever core functionality the gateway provides, it must be available in all deployment areas (areas 
        with low broadband internet availability, low cell availability, etc.). 
 
Erich Gunther: Enernex 
    • Physical embodiment shouldn’t matter 
 
John Thomas: Intel 
    • Open IP stack model, evolution of ZigBee, HomePlug. 
    • Universal modularity for communications protocols. 
 
Chuck Erlich: Building Intelligence 
    • We need to develop series of use cases to test the Gateway 
    • Specifically we need limiting use cases for areas and neighborhoods 
    • CEC, utilities can provide open contribution to use case collection 
 
John Lin: Wireless Glue 
    • Will the Gateway be owned by the consumer? 
    • What about network ownership extension into the realm of the thermostat people? 
 
Subra Subramanian: Cyberknowledge 
    • Would OSGi be a good starting framework for this project? 

                                                               
                                                  Page 23
                                                               
    •   Is the cost/overhead associated with OSGi too high given the scope/timeframe of this project? 
    •   3‐5yr lifespan quoted by Intel too short.  Utility companies are more interested in 10‐20yr lifespan. 
 
James Pace: Silver Spring Networks 
    • 802.15.4 endorsed by NIST 
    • What is going on with Professor Auslander’s sister project? 
 
Barry Haaser: U‐SNAP Alliance 
    • This group should take a close look at the U‐SNAP protocols posted on the website.  This is in 
        development, but will eventually include thermostat support and some other appliances. 
    • What about micro grid renewable energy generation?  PHEV? 
 
John Thomas: Intel 
    • Use case recommendation: Residential energy gateway should aggregate data into micro grid 
 
Erich Gunther: Enernex 
    • Virginia Tech team won DOE smart grid clearing house project to collect use cases in the future. 
    • (phone disconnected for the remainder of Erich’s comment) 
 
Phone DISCONNECTED @ 1050. Remaining comments local only. 
 
Charles Glorioso: Davis Engineering 
    • Cell phone connectivity becoming more viable (GPRS, EDGE) 
    • Providers beginning to price for low data rate devices 
    • Software and hardware upgradeability – support for evolving devices (card slot, etc.) 
 
Mike Kulmann: RCS 
    • User installation versus utility or manufacturer installation 
 
Bob Friday: Cisco 
    • Business model for the gateway is important 
 
Ron Hofmann: CIEE 
    • Utility business model is rate based 
    • CEC is interested in consumer choice, consumer protection 
 




                                                                 
                                                    Page 24
                                                                 
Appendix B – A Brownout Anecdote
Introduction 

        I began work for Professor Auslander in July of 2009, the summer before I began my PhD.  Still living in 
southern California at the time, I worked from home until August when I would re‐locate to the San Francisco 
Bay Area.  It was very hot that week, with daytime temperatures in the 90‐100*F range.  With my computer on 
throughout the day, heating up my apartment, I used air conditioning.  Throughout that week, I was the victim 
of several power outages during the mid‐day heat which left me without the use of my computer, but perhaps 
more importantly, without the use of my precious air conditioner.  I was experiencing, at least I thought, 
brownouts. 

        Simi Valley, California, zip code 93065, is a desert disguised by a community of over 100,000 people 
who plant trees, water lawns and use air conditioning to pretend their chosen environment is something other 
than what it truly is, very hot.  This was my first summer in Simi, I had moved in with my fiancée from San 
Diego, where I had not used air conditioning in seven years.  After expressing my discomfort with power 
outages to Professor Auslander during a phone conversation, he suggested I investigate the problem further.  
Intrigued by his proposal, I proceeded to learn all I could about brownouts. 

         In my mind, the periodic brownouts made sense: I was now living in an arid, hot and dry community, 
and when the heat spiked so did the Southland’s use of air conditioning.  This sharp increase in demand of 
electricity overwhelmed the available supply and the utility company initiated brownouts to prevent 
widespread power outages.  This theory, I later discovered, was essentially correct.  However, I had no idea of 
the complicated infrastructure which operated behind the scenes of my utility bill, which would conspire 
during hot days to rob me of a very comfortable air conditioned apartment.  My research into brownouts 
taught me a great deal about the path electrons take from the power plant to my computer AC adaptor and 
the complicated economy in which these electrons are so intertwined. 

Southern California Edison 

My Power Bill 

        I decided to begin my research with a thorough look at my power bill.  Usually, my interest in bills 
begins and ends with a set of numbers preceded by a dollar sign.  However, in this case, my latest utility bill 
seemed like a good place to start. 

         The bill itself is 2 pages.  The first page contains some account information, my address and the amount 
I owe the utility company.  The second page details the specifics of the charges which accumulate into my 
monthly bill.  Also included is a bar graph displaying the trend of power usage over the past year.  To my 
delight, my fiancée and I had consumer less power in June than in the preceding 4 months, and my bill was 
$25.  One item I noticed, which I had not seen before, was “Rotating Outage: Group A014.”  This item, surely, 
could help explain the specifics of how brownout affected me.  I decided to search the internet for more 
information. 



                                                                  
                                                     Page 25
                                                                  
SCE Website 

         Once I navigated to the Southern California Edison website, I quickly discovered a section entitled 
“Rotating Outages Information.”  This page provided a simple explanation of SCE’s brownout policy.  Simply 
put, SCE defines a rotating outage, or brownout, as “a controlled power outage which lasts approximately 1 
hour.”  (SCE, 2009)  Such outages are employed during emergency electrical conditions to avoid widespread or 
uncontrolled blackouts.  Given this information, my initial assumption regarding the nature of brownouts was 
correct.   

         On further investigation of the website, I learned that SCE divides all users within their area of 
responsibility into 7 groups, denoted by the following letters: A, M, R, S, X, N and EXEMPT.  Groups A, M, R, S 
and X are subjected to rolling blackouts (brownouts) times of short supply, while groups N and EXEMPT are 
not.  In addition, all seven groups are further divided into subcategories denoted via a 3 digit number postfixed 
to the letter, for example A001 or X057 (SCE, 2009).  This information helped to clarify my designation into 
Group A014. 

SCE Air Conditioner Cycling 

        On further navigation of the SCE website yielded an interesting find; during the summer, SCE offers a 
discount to customers who are wiling/able to participate in an air conditioner cycling program.  (SCE Summer 
Discount Program, 2009)  Participants in this program will have a small remote installed on their air 
conditioning units, which can be activated by SCE via radio to temporarily shut off the unit.  This type of direct 
control by SCE over an individual residence’s air conditioning system is to only occur during a power 
emergency.  (SCE Summer Discount Program, 2009)   

       SCE provides further specifics of what warrants the cycling of air conditioning systems.  During a 
statewide drop in electrical reserves of 5% or more (classified as a Stage 2 emergency) the California 
Independent System Operator (CA‐ISO) will notify SCE to reduce the electrical load on their system by a specific 
amount.   CA‐ISO can call for this action 24 hours a day, 7 days a week. 

       I had never before heard of this entity CA‐ISO.  Whoever or whatever they are, they wield a great deal 
of power in influencing controlled outages throughout California. 

CA‐ISO 

Overview 

         According to their frontpage, CA‐ISO is a non‐profit public‐benefit corporation charged with operating 
the majority of California’s high voltage power grid.  CA‐ISO functions as the link between the power 
generation plants and the utility companies.  Perhaps among the most important functions of the CA‐ISO is the 
following, “The ISO provides equal access to the grid for all qualified users and strategically plans for the 
transmission needs of this vital infrastructure.” (CA‐ISO, 2009)  This statement would seem to indicate that CA‐
ISO is responsible for planning brownouts “strategically” to ensure widespread availability of electricity and to 
prevent uncontrolled power outages.  More than distribution system, CA‐ISO also functions as a market place 
where wholesale electricity and transmission can be bought and sold. 

                                                                  
                                                     Page 26
                                                                  
       CA‐ISO operators monitor the electricity grid in California, portions of 11 western US states, British 
Coloumbia, and Northern Mexico.  (CA‐ISO Reliability, 2009).  Shifts of 15 operators are on duty 24 hours a day, 
365 days a year.  These operators monitor the status of the transmission system every 4 seconds. 

The Electron Superhighway 

          Power generated at power plants can be located great distances from its’ intended destination.  In a 
broad sense, CA‐ISO is responsible for getting this power generated from plants to your home.  Utility 
companies use their own power plants or negotiate contracts with independent power plants for electricity 
delivery.  Now that the utility companies have the necessary supply of electricity, they contact CA‐ISO and to 
schedule the delivery of this electricity.  Utility companies who schedule power delivery in this manner are 
known as “Scheduling Coordinators,” or SCs.  CA‐ISO operates the long distance, high voltage transmission 
system necessary to transport electricity from power plants to local substations.  This transmission system is 
realized in the 100ft – 150ft tall metal transmission towers cris‐crossing the state, linking power plants to 
substations.  Once electricity has reached the substation, its’ voltage is stepped down and further distribution 
is handled by the local utility company (via traditional wooden post electrical lines).  This fact explains why local 
utility companies, such as PG&E or SCE, routinley service downed power lines in your neighborhood; CA‐ISO is 
only responsible for the transmission system between power plants and substations.  Power delivery from 
substations to your home falls within the domain of the local electric company.  (CA‐ISO Transmission Network, 
2009) 

How CA‐ISO Operates 

        Managing the high voltage transmission of electricity throughout the state of California is a large 
responsibility.  CA‐ISO estimates the number of users served via their system to be in the neighborhood of 30 
million people.  (CA‐ISO Transmission Network, 2009)  The following is an overview of how the CA‐ISO operates 
the high voltage transmission system (CA‐ISO Operations): 

    •   The CA‐ISO creates a forecast via the internet for power consumption 24 hours in advance of 
        scheduled delivery. 

    •   CA‐ISO acts as a clearing house for the wholesale trading of electricity, with over 15,000 market 
        transactions between buyers and sellers every hour. 

    •   Using information from Scheduling Coordinators and energy trades being made on the CA‐ISO market, 
        CA‐ISO runs through a power delivery simulation in order to mitigate congestion and ensure an 
        adequate amount of electrical reserves is available. 

    •   CA‐ISO monitors electrical consumption across the grid every 4 seconds to ensure electrical supply is 
        adequate for the demand.  Simply put, CA‐ISO controlls how much power can flow at all of the input 
        and output points along the high voltage grid. 

    •   If demand for power increases suddenly and unexpectedly, CA‐ISO can incorporate production from 
        plants within and outside of California to meet demand.  This supplimental power can be purchased 
        utility companies via the CA‐ISO market to offset high demand.   

                                                                   
                                                      Page 27
                                                                   
    •   CA‐ISO can also instruct local utility companies to decrease the electrical load on their systems in the 
        event of supply shortfalls. 

The CA‐ISO Market 

         The CA‐ISO market acts as a clearing house for the purchase and sale of electricity, although never 
buying or selling electricity itself.  This type of market allows the ISO to adjust its’ power deliveries to meet 
changes in electricity demand.  Although less than 10% of California’s electricity is traded on CA‐ISO’s 3 
markets, the availability of this resource allows for utility companies to purchase additional power in an 
emergency.  (CA‐ISO Operations),  (CA‐ISO Electricity Market, 2009)  The 3 markets aforementioned are the 
Ancilliary Market, the Transmission Market, and the Real‐Time Imbalance Market.   

        The CA‐ISO Ancilliary Market serves to adjust the flow of electricity should a plant go offline or a 
sudden spike in electrical demand occur.  Electrical capacity purchased here can be dispatched to its’ indended 
destination anywhere from seconds to hours ahead of consumption.  Purchase of power on the Ancilliary 
market are made the the day ahead or the hour ahead of when power is scheduled to be delivered.  There are 
4 types of electricty for sale on the ancilliary market: 

    •     Regulation ‐‐ Generation that is already up and running (synchronized with the power grid) and can be 
          increased or decreased instantly to keep energy supply and energy use in balance.  
    • Spinning Reserve ‐‐ Generation that is running, with additional capacity that can be dispatched within 
          minutes.  
    • Non‐Spinning Reserves ‐‐ Generation that is not running, but can be brought up to speed, within ten 
          minutes.  
    • Replacement Reserves ‐‐ Generation that can begin contributing to the Grid within an hour.  
          The Transmission Market manages the space on the transmission network on which electricity can 
flow.  It is bought and sold the day and/or hour ahead of when electricity is to be delivered.  Should electron 
congestion occur, CA‐ISO can request that individual scheduling coordinators reduce electrical load in their 
areas of responsibility. 

       The Real‐Time Imbalance Market houses the quick sales of electricity to accommodate energy use 10 
minutes prior to its delivery.  In this market, Scheduling Coordinators can receive payments for extra supply 
generated and sold, or can be billed for purchasing supplimental electricity. 

CA‐ISO and Brownouts – The Big Picture 

        If demand for electricity exceeds supply, or if reserve levels drop, operators in the CA‐ISO operations 
center issues a stage 1 emergency and calls on local utilities to increase generation of electricity.  This 
supplimental power can now be bought and sold on the CA‐ISO markets to offset the defecit in supply.  CA‐ISO 
simultaneously issues news releases and public calls for conservation. 

          If reserve levels drop below 5% of available supply, the ISO issues a stage 2 emergency and call on local 
utilities to voluntarily reduce electrical load.  If such voluntary measures are not enough to prop up dropping 
reserves, the ISO can instruct utility companies to begin involuntary load reduction, via rotating outages.  In the 


                                                                   
                                                      Page 28
                                                                   
event of a stage 2 emergency, the ISO states that it is the perrogative of the utility companies to determine 
how to reduce their individual loads. (CA‐ISO Reliability, 2009) 

        CA‐ISO provides real time power consumption/demand readings on the high transmission network in 5 
minute intervals posted via the following website.  
http://www.caiso.com/docs/2005/09/26/2005092612591621973.html 

The Residential Home Energy Gateway 

         In my opinion, it appears that both the utility companies and CA‐ISO could use another method of 
communication with individual users of grid electricity, both residential and commercial.  In the case of CA‐ISO, 
during a stage 1 or 2 emergency, the ISO would publish public calls for reduction in electricity.  These warnings 
would only be able to indirectly reach indiviudal users, via media like the news, radio or internet.  If the ISO had 
the ability to contact users directly to inform them of the need for voluntary load reductions, users could learn 
of this impending event and react quicker.  The same could be said of utility companies under a stage 2 
emergency, where CA‐ISO has called for involuntary load reductions.  In this case, the utility companies would 
pick one or several rotating outage groups to “turn off” and would simply post news of the outage on their 
website.  A more preferred method of communication would be direct to a user’s home.                




                                                                  
                                                     Page 29
                                                                  
Appendix B: Works Cited 
CA‐ISO. (2009). CA‐ISO Home Page. Retrieved August 2009, from California Independent Systems Operator: 
http://www.caiso.com/ 

CA‐ISO Electricity Market. (2009). CA‐ISO, Why Markets? Retrieved August 2009, from California Independent 
Systems Operator: http://www.caiso.com/docs/2005/09/23/2005092315310610481.html 

CA‐ISO Operations. (n.d.). CA‐ISO, How It Works. Retrieved August 2009, from California Independent Systems 
Operator: http://www.caiso.com/docs/2005/10/28/200510280935129951.pdf 

CA‐ISO Reliability. (2009). CA‐ISO Reliability. Retrieved August 2009, from California Independent Systems 
Operator: http://www.caiso.com/docs/2005/09/23/2005092315320110803.html 

CA‐ISO Transmission Network. (2009). How Power Flows in California. Retrieved August 2009, from California 
Independent Systems Operator: http://www.caiso.com/1c28/1c28afc63bc40.pdf 

SCE. (2009). Rotating Outages Information. Retrieved July 2009, from Southern California Edison: 
http://www.sce.com/PowerOutageCenter/Rotating/default.htm 

SCE Summer Discount Program. (2009). Summer Discount Plan. Retrieved July 2009, from Southern California 
Edison: https://www.sce.com/NSD/EventStatus.aspx 




                                                                
                                                   Page 30
                                                                

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:2/15/2012
language:
pages:30