[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-discuss] RE: Introduction: The Demand Side
Hi Ed, This writeup and your paper/presentation
at Grid Interop are excellent. The paper described several DR messaging
scenarios which I feel can be addressed through the composition of a handful of
message payloads with a DR event model and a dynamic pricing model at the core.
These I believe could be augmented with other services such as a bidding
service, etc. By abstracting away and delegating the direct device control to
domain specific systems, these models can adapt to the wide range of application
scenarios that you described. I also feel that we need to separate the
discussion of DR event and DP information models from transport at this time. I
clearly see several transport pipes needed to move these events and data
through the many layers and systems within the SG based upon specific application
requirements. I feel that it’s a little premature to discuss how we’re
going to move the data before we understand and define what data we’re
going to moveJ. Great discussion thread!! Dave Dave Hardin, PE, PMP, CSDP, MCAD Invensys Global Development (w) 508-549-3362 (c) 774-571-5386 From: Edward Koch
[mailto:ed@akuacom.com] 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] 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 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]