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] Ramp intervals


Currently for the pre-performance period, registration exists to the extent that DR programs specify ramp requirements are part of the qualification for membership.  In the case of an asset as messy as a commercial building, the ramping intervals may not make rational sense because they are not consistent from event to event.  Unlike generation ramps, DR ramps depend on so many variables that the asset manager can't know the true response rates until he pulls the trigger.  It's more likely that he would accept the ramp requirements as boundary conditions he knows he can act within.

Return to the status quo ante would be easier to predict since the pre event state is known as are the actions taken to ramp; but again, not as consistent as generation assets.  So to your earlier comment that things just don't shut down, on the demand side, actually, they can.  Perhaps more useful expression might be the notice period within which the asset can achieve advertised performance?

Phil Davis | Senior Manager - Solutions | Schneider Electric Demand Response Resource Center | 3103 Medlock Bridge Road, Suite 100 | Norcross, GA  30071 | 404..567.6090 | phil.davis@us.schneider-electric.com | www.schneider-electric.com | Skype: pddcoo


On Tue, Sep 14, 2010 at 3:16 PM, Toby Considine <Toby.Considine@gmail.com> wrote:

“Because this is part of the registration process, having an instruction within EMIX might be both redundant and confusing.”

 

IF the registration process exists as offering a product to market, then it should be part of the product definition – hence it should be in emix.

 

Say I’m an office building. I can accept a DR request during which I will ramp down by X. By 3:00 (the scheduled DR time) I am at the run rate. At the end of a DR event, I will ramp up, up even higher than the status quo ante until I catch up on [cooling]. This is the three-pat offer that could be advertised by a building offering DR to an open market.

 

I don’t thing we want to need an off-line registration process for that.

 

tc

 


"If something is not worth doing, it`s not worth doing well" - Peter Drucker


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: pddcoo@gmail.com [mailto:pddcoo@gmail.com] On Behalf Of Phil Davis
Sent: Tuesday, September 14, 2010 2:37 PM
To: Toby.Considine@gmail.com
Cc: emix@lists.oasis-open.org
Subject: Re: [emix] Ramp intervals

 

Although these profiles do exist "in the wild", they are sequestered from the polite world by controls systems.  The latter are designed to prevent the release of power onto the grid until a) it achieves the required harmonization characteristics; and b) it has achieved stability doing so.  Generators typically will start their units using the connected grid as a reference signal for those controls.

 

The analogous signaling strategy, I think, involved registering the asset in such a way that the respective control center knows the ramp up/down commitment time for that asset (e.g., 30 minute, 10 minute, etc).  Because this is part of the registration process, having an instruction within EMIX might be both redundant and confusing.

 

Thoughts?


Phil Davis | Senior Manager - Solutions | Schneider Electric Demand Response Resource Center | 3103 Medlock Bridge Road, Suite 100 | Norcross, GA  30071 | 404..567.6090 | phil.davis@us.schneider-electric.com | www.schneider-electric.com | Skype: pddcoo

On Tue, Sep 14, 2010 at 2:19 PM, Toby Considine <Toby.Considine@gmail.com> wrote:

Do we need a construction within EMIX for ramping intervals? I am tieing this to such things as the 3-part generation bids

Consider the case of a long generation cycle followed by a discrete ramp cycle. The whole shape is the electricity produced. Things don’t just shut down, there is some electricity that needs to go somewhere, and if it goes onto the grid, it must be planned for and balanced.

 

The large rectangle on the left is the scheduled generation period. The it may be scheduled for three hours, it may be scheduled for 1, it may be scheduled for 16. The slopey bit on the right  just comes along for the ride.

The shape above is an ugly interval.We could solve it by making an infinite number of intervals, or at least enough so that we can assume that each one was flat. I think it would be an error to recreate intro calculus within EMIX…

WS-Calendar supports separating a scenario like that above, in which the things are split into two linked intervals. It is easy to schedule the interval on the left, to any length, It is the supply of a constant amount of energy for a variable period of time, as per contract. The funny looking shape on the right, comes along for the ride; buying the left is buying the right. This occurs in many scnarios in homes / buildings / energy / …

So in Emix, we have a product, and then we have a ramp. The ramp is a predictable varying, but constant duration (probably) delivery of product. There may be ramp ups and ramp downs.

 

We need to include handling of ramped energy in each EMX product.

 

 


“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.


Toby Considine
TC9, Inc

OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 


________________________________________________________________________
This email has been scanned for SPAM content and Viruses by the MessageLabs Email Security System.
________________________________________________________________________

 


________________________________________________________________________
This email has been scanned for SPAM content and Viruses by the MessageLabs Email Security System.
________________________________________________________________________



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