[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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]