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.