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

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

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


Subject: Re: [energyinterop] RE: EI feedback


David,

In response to the following statement made earlier in this e-mail thread: "This is the only place I know where I have seen written down a request for feedback in some format. The PRD Provider would be someone like an ESP or CSP." I would like to provide more information.

The IRC's interaction diagrams illustrate feedback from DR in several places. Operations and program manuals  specify requirements on the timeliness of feedback. For DR providing real-time services, real-time feedback may be a requirement of participation.

I would also like to point out that in this statement below: "Something akin to a performance rating, wherein less reliability affects market price received." that  it is not the market price that would change, but the payment received as adjusted for performance.

If there are specific areas that you would like the IRC to help clarify, please let us know and we will get the appropriate subject matters experts to provide input. This would be preferred to possible misinterpretations of what happens in wholesale market interactions with demand response. 

Regards,
Donna
 

----- Original Message -----
From: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Monday, May 02, 2011 11:22 AM
To: Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu>; Dave Hardin <dhardin@enernoc.com>; 'Gowri, Krishnan' <krishnan.gowri@pnl.gov>; energyinterop@lists.oasis-open.org <energyinterop@lists.oasis-open.org>
Subject: [energyinterop] RE: EI feedback

Thinking about it some more, seems PJM could use the RequestQuote service (with included estimated prices), and get back the estimated load for those prices. But how does that work when we don't want to use a push interaction from the ISO? Or maybe hosting a server is a reasonable requirement for anyone playing in the wholesale PRD market.

David

-----Original Message-----
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] 
Sent: Monday, May 02, 2011 10:40 AM
To: Holmberg, David; Dave Hardin; 'Gowri, Krishnan'; energyinterop@lists.oasis-open.org
Subject: RE: EI feedback

Good points, all.

1) While today, end nodes are treated not really responsible for results (and thus the legal tender point), I think that aggregators are held to a higher standard.

3) The exact contract, including penalties for non-performance and other market context issues, are out of scope. We can imagine a few components:

a) Something akin to a credit rating, wherein consistent failure to perform affects ability to participate in the market
b) Something akin to a performance rating, wherein less reliability affects market price received.
c) responsibility to make good, wherein the non-performer is responsible for the spot purchases. Such purchases may be expensive in dollars and in "green" ratings
d) simple Non-performance penalties per incident

tc

"It is the theory that decides what can be observed."   - Albert Einstein

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
http://www.oasis-open.org 
blog: www.NewDaedalus.com


-----Original Message-----
From: Holmberg, David [mailto:david.holmberg@nist.gov] 
Sent: Monday, May 02, 2011 10:30 AM
To: Considine, Toby (Campus Services IT); Dave Hardin; 'Gowri, Krishnan'; energyinterop@lists.oasis-open.org
Subject: RE: EI feedback

Toby,

If we follow this approach, then I am making a legal tender, but understand that they will look at all of them and accept none, and rather use them only for estimation purposes without any binding contract, right? I think that fits best with PJM's idea. Then, if I don't perform as I said I would, PJM has contractual arrangement to use direct control to reduce the load. 

What happens when PJM wants more than a "now" forecast of power usage? They will send an estimated forward price curve (using EiQuote schedule, which may consist of guaranteed and/or estimated prices for future hours). Then I want to report back (for that forward price quote) that I will use this much power over the scheduled period. That would be a tender of power use across a schedule, and the schedule can include the estimated prices along with estimated load. But how do I point to the EiDistributeQuote or EiSentquote message from which I got the price estimate (for accounting purposes)?

Thanks,
David


-----Original Message-----
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Friday, April 29, 2011 7:44 PM
To: Dave Hardin; Holmberg, David; 'Gowri, Krishnan'; energyinterop@lists.oasis-open.org
Subject: RE: EI feedback

After meditating on this, how is this anything more than a series of exclusive tenders, submitted simultaneously by the, The processing of these bids, then, is the same as if they were submitted by separate bidders.

The EMIX models spreads information about a product and price  over intervals borrowed from WS-Calendar. In the use cases we have spent the most time on, these are consecutive intervals, linked by relationships between them. Only the designated interval inherits the [starting time] from the external gluon. The gluon holds the invariant information. In this model, the gluon has only a single link to a single interval.

A transactive bid to the market, then looks (in cartoon form) something like:

<emix:temix >
	<xcal:properties/>
	<xcal:components>
		<xcal:interval>
			<xcal:properties>
				<xcal:dtstart>
					<xcal:date-time>20110315T00000000</xcal:date-time>
				</xcal:dtstart>
				<xcal:duration>
					<xcal:duration>PT1H</xcal:duration>
				</xcal:duration>
				<xcal:x-wsCalendar-attach>
					<power:powerProductDescription>Full characterization of product</power:powerProductDescription>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
	</xcal:components>
	<emix:currency>USD</emix:currency>
	<emix:transactiveState>Tender</emix:transactiveState>
	<emix:side>Sell</emix:side>
	<emix:expires>2011-04-19T21:35:00.717</emix:expires>
</emix:temix>

A seller could submit a number of such bids. Because we want them to be exclusive, i.e., we want the buyer to pick only of those offered, we need to bind them together somehow. A gluon could include a common dtStart, duration, and product description for a collection of intervals. With a single interval, the pseudo artifact below expresses the same information as the unbound interval above.

<emix:temix>
	<xcal:properties/>
	<xcal:components>
		<xcal:gluon>
			<xcal:properties>
				<xcal:related-to>
					<xcal:parameters>
						<xcal:reltype>
							<xcal:text>CHILD</xcal:text>
						</xcal:reltype>
					</xcal:parameters>
					<xcal:uid>0214cf38-77ae-4f9f-8a87-8ab26df45ec2</xcal:uid>
				</xcal:related-to>				<xcal:dtstart>
					<xcal:date-time>20110315T00000000</xcal:date-time>
				</xcal:dtstart>
				<xcal:duration>
					<xcal:duration>PT1H</xcal:duration>
				</xcal:duration>
				<xcal:x-wsCalendar-attach>
					<power:powerProductDescription>Full characterization of product</power:powerProductDescription>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:gluon>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-77ae-4f9f-8a87-8ab26df45ec2</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
	</xcal:components>
	<emix:currency>USD</emix:currency>
	<emix:transactiveState>Tender</emix:transactiveState>
	<emix:side>Sell</emix:side>
	<emix:expires>2011-04-19T21:35:00.717</emix:expires>
</emix:temix>

Of course, it is nonsense to use a single gluon/interval pair like that. We could construct a composite (of 5 bids) bid like this. The child relationship points to 5  Inttervals, each of which is therefor "designated". The transactiveState "TenderExclusive" indicates only one of the tenders can be accepted. Each interval would only include a price and a quantity.

<emix:temix>
	<xcal:properties/>
	<xcal:components>
		<xcal:gluon>
			<xcal:properties>
				<xcal:related-to>
					<xcal:parameters>
						<xcal:reltype>
							<xcal:text>CHILD</xcal:text>
						</xcal:reltype>
					</xcal:parameters>
					<xcal:uid>0214cf38-01</xcal:uid>
					<xcal:uid>0214cf38-02</xcal:uid>
					<xcal:uid>0214cf38-03</xcal:uid>
					<xcal:uid>0214cf38-04</xcal:uid>
					<xcal:uid>0214cf38-05</xcal:uid>
				</xcal:related-to>
				<xcal:dtstart>
					<xcal:date-time>20110315T00000000</xcal:date-time>
				</xcal:dtstart>
				<xcal:duration>
					<xcal:duration>PT1H</xcal:duration>
				</xcal:duration>
				<xcal:x-wsCalendar-attach>
					<power:powerProductDescription>Full characterization of product</power:powerProductDescription>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:gluon>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-01</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-02</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-03</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-04</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
		<xcal:interval>
			<xcal:properties>
				<xcal:uid>0214cf38-05</xcal:uid>
				<xcal:x-wsCalendar-attach>
					<emix:price></emix:price>
					<emix:quantity></emix:quantity>
				</xcal:x-wsCalendar-attach>
			</xcal:properties>
			<xcal:components/>
		</xcal:interval>
	</xcal:components>
	<emix:currency>USD</emix:currency>
	<emix:transactiveState>TenderExclusive</emix:transactiveState>
	<emix:side>Sell</emix:side>
	<emix:expires>2011-04-19T21:35:00.717</emix:expires>
</emix:temix>

"It is the theory that decides what can be observed."   - Albert Einstein

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com



-----Original Message-----
From: Dave Hardin [mailto:dhardin@enernoc.com]
Sent: Friday, April 29, 2011 9:53 AM
To: Holmberg, David; 'Gowri, Krishnan'; energyinterop@lists.oasis-open.org
Subject: [energyinterop] RE: EI feedback

I'd like to stress that this is extremely important for demand response to function properly. I know that many folks don't agree with this but feedback is critical for any automated process. I can't stress it's importance enough.


Dave Hardin, PE, PMP, CSDP – Senior Director, SmartGrid Standards EnerNOC, Inc. | 101 Federal Street, Suite 1100 | Boston, MA 02110
o: 617.692.2543 | f: 617.224.9910 | c: 774-571-5386 dhardin@enernoc.com<mailto:dhardin@enernoc.com> | www.enernoc.com<http://www.enernoc.com/>
EnerNOC - get more from energy

________________________________
From: Holmberg, David [david.holmberg@nist.gov]
Sent: Friday, April 29, 2011 9:26 AM
To: 'Gowri, Krishnan'; energyinterop@lists.oasis-open.org
Subject: [energyinterop] EI feedback

Just a note—I was looking at a recent PJM white paper on price responsive demand:
http://pjm.com/~/media/documents/reports/pjm-whitepaper-on-price-responsive-demand.ashx

PJM is stressed about not being able to correctly model price responsive demand (PRD) and thus wants info back from the customer. From page 11-12 I quote (and have highlighted what they expect from the facility). This is the only place I know where I have seen written down a request for feedback in some format. The PRD Provider would be someone like an ESP or CSP.

“In real-time operations, it is essential to understand how much energy will be consumed at or above various prices so that PJM can send out the proper price and dispatch signals to market participants to maintain energy balance and reliability. Without this information PJM may be in a position of ―over- or under-dispatching‖ resources, rather than dispatching the amount necessary to maintain energy balance. The PRD curves submitted by the PRD Provider, which include price-quantity pairs, enable short-term load forecasting to account for reactions to dynamic retail rates. The below figure illustrates what such a PRD curve might look like. PJM Staff Whitepaper Price Responsive Demand March 3, 2011 DOCS# 591114 PJM © 2011 Page 12


[cid:image002.png@01CC064F.87A7B5C0]

David Holmberg
NIST Engineering Laboratory
301-975-6450



This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed.  
This email may contain information that is privileged, confidential or otherwise protected from disclosure.  
Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.

**********************************************************************
The information in this email is confidential and may be legally
privileged against disclosure other than to the intended recipient.
 It is intended solely for the addressee. Access to this email by
anyone else is unauthorized. 

If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful.  Please immediately
delete this message and inform the sender of this error.   
**********************************************************************


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