[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Introduction: The Demand Side
|
In the spirit of helping bring people up to speed, let
me drill down a little more and add the following comments concerning the type
of activities that people perform on the demand side so we can get a better
understanding of what may be affected by more intelligent/sophisticated
interactions with the grid.
The most obvious activity is that people buy power from
the grid and consume it. With the advent of distributed generation there
is also the possiblity for people to generate (or possibly store) their own
electicity and sell it back on to the grid. These general activities seem
pretty obvious so let me drill down further and try to catagorize the load
management activities. Much if this is based upon current models and may
change with the advent of more sophisticated interactions, but in general I like
to broadly categorize the range of load management acitivites that people
engage in on the demand side in the following way:
(1) Energy efficiency performed every day which is
targeted towards reducing the overall baseline of
consumption.
(2) Daily load shaping which is
specifically targeted towards fluctuating energy prices. Many businesses
are already enrolled in dynamic pricing tariffs in which the price of their
electricity goes up every afternoon. Usually the price rises are part of a
fixed tarrif, but over time the prices are expected to be more closely tied to
the wholesale market, so called Real Time Pricing (RTP).
(3) Day before Demand Response (Slow DR). Demand
Repsonse is specifically an event based mechanism that currently occurs
infrequently (about 12 times per year for a typical DR program) and is used by
the Utility/ISO to reduce the supply side requirements during times when either
the grid is under stress or when prices on the wholesale market rises too
high. The events typically last for about 4 hours. Day before DR
refers to the fact that participants are typically notified a day before the
event to give them time to repsond. Typcially the responses are load
reductions that are achieved through turning things off or shifting loads.
With on site generation the response may include producing power at the
participant site.
(4) Day of DR (Fast DR, i.e. ancillary services).
This is also DR but typcially called by the Utility/ISO for a different reason,
i.e. relaibility of the grid. The grid is undergoing some stress that
requires an immediate response in terms of load reduction (or adding load
capacity in the case of distributed generation). Since these DR events
require a more immediate response there are constaints on how the participant
can respond (e.g. load shifting may not be possible) and increased requirements
on the reliability of the response.
(5) On site generation of electricity, both for use on
site and to be sold back onto the grid.
Although 3 and 4 are both event based DR mechanisms
that are initiated on the grid side, I think it is important to make the
distinction between them because I believe that when dynamic pricing becomes
more prevalent item (3) may become more like item (2), but (4) will not since it
is more closely tied to grid reliability.
It is also important to note that today most of the DR
programs are not automated, but those that are typcially use a mechanism
that is called "Direct Load Control" (DLC). In these programs the
Utility/ISO directly controls the state of loads within a facility.
Although it is recognized that a more preferrable method is to send business
level information (i.e. prices and/or shed levels) to a participant and
let them decide how to respond, there will most likely always be a place for DLC
becasue it gives a more predictable and reliable response. In the coming
weeks you will no doubt hear more about OpenADR which is an attempt to sepcify
an interaction model and message exchange mechanism for
DR.
Things start to get even more complicated when you
start adding in the various intermediaries (i.e. aggregators, ESCO's, etc.) that
are involved in managing people's consumption of electricty. I won't go
into that here, but I will point you to a paper I presented at Grid Inter-op
that discusses interrmediaries within the the domain of DR.
-ed koch
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] Sent: Thursday, December 11, 2008 9:57 AM To: smartgrid-discuss@lists.oasis-open.org Subject: [smartgrid-discuss] Introduction: The Demand Side I am continuing to frame the subject some for those new to
power here with a few stage-setters, here and on my blog. http://www.newdaedalus.com/articles/2008/12/11/smartgrid-basics-the-demand-side-problem.html Again, apologies to some who will feel I missed some nuances,
as I know I have. My goal is to help some get up to speed quickly… Consider this
an educational cartoon… Smartgrid Basics: The Demand Side Problem Building systems have traditionally been invisible and
uncontrollable. They have been managed to reduce costs with no real focus on the
service they are providing. They have grown up in sandboxes, using their own
peculiar protocols. These protocols are deep and technology specific, and often
without effective interface. These systems are operated, when they are operated
by process specialists. Building occupants rarely have a precise understanding of how
these systems affect their business. They may know exactly what a too-hot or
too-cold call costs. They know that tenant dissatisfaction may lead to
un-renewed leases. They may suspect that under ventilation may lead to sleepy
occupants, but can rarely put any exact price tag on that. This makes them
conservative about making changes in building operations. Demand Response (DR) is emerging a critical tool for dealing
with peak load management. Peak loads are by far the most expensive and dirtiest
electricity we have; their costs, on both bottom lines, swamping others. Demand
response is moving from direct control to economic incentives, but underneath,
today’s integrations are process centric rather than service oriented. Energy
providers order or pay energy customers to turn off things on just a few days a
year, to manage the peak. We encourage only the crudest, least effective energy
savings, while denying the market the energy signals that would cause better.
At the commodity system level, DR is already moving to
services and agents. Agents defend their own mission while responding to the
outside world. Washing machines know not to respond to grid signals until they
determine that the current laundry is not soaking in bleach. Refrigerators know
not to respond if they have just finished a defrost cycle. These systems know
and understand what services they provide and so are ready to be responsive.
Building systems are not. We will get larger DR when we talk to the building occupant.
We will get better participation when the occupant remains in control. The
occupant will not allow DR when the in-laws are coming for the weekend. The
occupant knows the family overspent at Christmas and is willing to respond to
any and all incentives. The access control system may know that only three
people on the fourth floor came to work today. Human resources knows that the
sales force is on a retreat. Together, they can choreograph far greater response
from the building systems then ever will be permitted as an automatic response
from control communications. Demand Response must be about economic signals to a business
entity. When thought of in this way, there is no need for different signals to
Industry and to Business (and to home and to vehicle). The business may choose
to automate this. The business may benefit from templates for response, whether
developed by EPRI or by ASHRAE, which reduce the risk of considering
participation. These choices and these templates are not part of the interface.
The interface should not does not concern itself with the
underlying technology and control protocols. It should not be based upon BACnet,
or OPC, or LON any number of other low level control system protocols. The
interface must be one that enables business decisions. Control systems should
offer up service interfaces for choreographed response. Whatever offer and
counter offer DR requires, whether amount of load shed or maximum load used or
time to respond must be in the interface, but no deep process. The smartgrid to building/industry/home interface is about
how the Service Oriented Building can respond to the Service Oriented Grid. Just
as in other services, the underlying processes should be hidden. tc "It is the theory that decides what can be observed." - Albert
Einstein
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]