[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-discuss] RE: Introduction: The Demand Side
|
Dave,
I agree completely that we should seperate the transport
from the discussion. I agree with you in that I think we would
be successful if we were able to analyze Auto DR in conjunction with other
applications such that we could devise a set of core services and/or data models
that when bundled together comprise what we might consider an Auto DR
interaction. This should be done completely independent of transport or
communications technology.
One of the differences I've seen between the folks at the
UCA and OASIS in trying to characterize the entities that should be standardized
is that the UCA folks tend to focus on the data objects and their models and the
OASIS folks tend to think in terms of services. At the end of the day we
can all hopefully agree that entities such as price should have the same model
and semantics (if not syntax) whether that information is being transported as
part of a web service over the internet or sent as a message over a proprietary
AMI system.
-ed koch
From: Hardin, David [mailto:david.hardin@ips.invensys.com] Sent: Thursday, December 11, 2008 12:46 PM To: Edward Koch Cc: smartgrid-discuss@lists.oasis-open.org 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]