OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emix] Plane of Control vv. Transactional Energy


David / Toby,

Beware of ocean boiling!!!

In my experience building intelligent expert systems - there are a slew of potential inputs and sources of control information and rules.

Within OASIS though - all we can do is focus on core concepts and build that.  I'm sure implementers will find all kinds of value-add features for their products to differentiate themselves in the marketplace.  We don't need wire XML formats to support those!

As an example look at the OASIS emergency work with the CAP spec'.  That is incredibly simple XML constructs - many argue too simple.  Nevertheless - time to market was key for them - so they went with simplest path - and as a result - there is an array of vendors offering all kinds of products - and devices that use CAP messages.

I believe that KISS here for V1.0 is also vital.

DW

<snip>Is the question of “plane of control” the same as “where is the human interface?”, unless (as in the case of the refrigerator) there is no human interface? And in the case of a campus or microgrid there are effectively multiple human inputs that impact a single system. There is the building operator and the human resources office and the Energy management director’s office and the “how green we want to be” CEO office. Each of these impacts decisions about conditions on energy use, and how and when and why. Hopefully they all work together to have a consistent policy for response to price signals and other priorities.

 

It’s the “other priorities” that Toby brought up on the call. Price is not all that matters. Maybe source matters. Maybe local matters—that might be factored in as a price adder on external power. Other priorities might be reflected as exceptions in the policy for a particular system, like “the bowling alley will never go into reduced-power mode when the director has bowling league”.</snip>



Thanks, DW

-------- Original Message --------
Subject: [emix] Plane of Control vv. Transactional Energy
From: "Holmberg, David" <david.holmberg@nist.gov>
Date: Thu, April 15, 2010 1:05 pm
To: "emix@lists.oasis-open.org" <emix@lists.oasis-open.org>

So, I wanted to think more about this “plane of control” concept as it relates to Ed’s doc on TeMIX http://www.oasis-open.org/apps/org/workgroup/energyinterop/download.php/37301/Transactional%20Energy%20White%20Paper%20Draft%20004.pdf
 
A refrigerator can be smart enough to monitor a price and see that the price is higher or much higher than normal and take energy saving measures. It can learn a daily routine and plan accordingly. It really doesn’t need any higher level control, because no human is going to bother to tell it “I have a load of groceries coming this evening with some potentially warm milk, so please pre-cool before 6pm.”
 
A home thermostat can have a pre-programmed schedule that is used to adjust temperature. That is the control plane for the different components of the heat pump/furnace/AC. But the thermostat may pay attention to other inputs, like a door sensor that indicates an occupant’s arrival and need to lower the temp, or certainly an occupants direct override. The thermostat watches the price and the house temp profile may be adjusted accordingly. There may also be DR signals that effectively move the plane of control outside the home (even though the homeowner has essentially contracted some grid-side service partner to handle energy management).
 
A commercial HVAC controller takes this to a higher level, with more sensor and human inputs, and variability in schedules. A building may define common operation modes for different zones. A schedule for facility use determines which modes apply at a given time. The price of electricity will be cross-cutting input, adjusting each of the operation modes, perhaps bumping operation from one mode to another, or into additional cost-saving modes.
 
Microgrids somehow imply local power management: maintaining voltage, managing load/storage/generation, and ability to go “off-grid”. Some microgrid controller may micro-manage these things or instead use a market mechanism to manage. We can have algorithms on the storage that indicate when to store or deliver based on price. The real test is when we lose the big-grid supply and can we manage voltage and phase. It’s not clear to me that price messaging/markets can do that. Besides the electrical challenges, to make the load/gen/storage balance work, we will need significant pre-programmed rules for load flexibility. If some loads must shut down, then we must have rules that say “you go to this mode at this price, and shut down at that price” for all such loads/systems/devices.  
 
Is the question of “plane of control” the same as “where is the human interface?”, unless (as in the case of the refrigerator) there is no human interface? And in the case of a campus or microgrid there are effectively multiple human inputs that impact a single system. There is the building operator and the human resources office and the Energy management director’s office and the “how green we want to be” CEO office. Each of these impacts decisions about conditions on energy use, and how and when and why. Hopefully they all work together to have a consistent policy for response to price signals and other priorities.
 
It’s the “other priorities” that Toby brought up on the call. Price is not all that matters. Maybe source matters. Maybe local matters—that might be factored in as a price adder on external power. Other priorities might be reflected as exceptions in the policy for a particular system, like “the bowling alley will never go into reduced-power mode when the director has bowling league”.
 
Perhaps some of this ought to be discussed in the TeMIX paper.
 
David Holmberg
NIST Building and Fire Research Lab
301-975-6450
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]