OASIS Energy Interoperation TC

Expand all | Collapse all

EI feedback

  • 1.  EI feedback

    Posted 04-29-2011 13:27
      |   view attached
    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 ¨Dover- 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       David Holmberg NIST Engineering Laboratory 301-975-6450    


  • 2.  RE: EI feedback

    Posted 04-29-2011 13:54
      |   view attached
    Great catch, Dave.   Constellation was asking for similar things back in 2008, but somehow it got lost in the avalanche of official SG requests. It may have even made it into the TC formation seminar, never to be seen again.   The closest to this that we have now is                         <!-- 4.3.1 Offer Segment elements   -->                       < xs:element name =" offerCurve " type =" resource:OfferCurveType " substitutionGroup =" emix:baseRequirement "/>                       < xs:complexType name =" OfferCurveType " mixed =" false ">                                               < xs:annotation >                                                                       < xs:documentation > Type of a collection of Offer Segments used to compute cost requirements across a range of power. </ xs:documentation >                                               </ xs:annotation >                                               < xs:complexContent mixed =" false ">                                                                       < xs:extension base =" emix:BaseRequirementType ">                                                                                               < xs:sequence >                                                                                                                       < xs:element name =" offerSegment " type =" resource:OfferSegmentType " maxOccurs =" unbounded "/>                                                                                               </ xs:sequence >                                                                       </ xs:extension >                                               </ xs:complexContent >                       </ xs:complexType >                       < xs:element name =" offerSegment " type =" resource:OfferSegmentType "/>                       < xs:complexType name =" OfferSegmentType ">                                               < xs:annotation >                                                                       < xs:documentation > Type of Marginal offer for Power within a range. Marginal costs must be computed within the context of a range of segments as conformed by the Offer Type </ xs:documentation >                                               </ xs:annotation >                                               < xs:sequence >                                                                       < xs:element ref =" emix:price "/>                                                                       < xs:element ref =" emix:quantity "/>                                                                       < xs:element ref =" power:powerItem "/>                                                                       < xs:element ref =" emix:integralOnly "/>                                               </ xs:sequence >                       </ xs:complexType >     " 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     From: Holmberg, David [mailto:david.holmberg@nist.gov] Sent: Friday, April 29, 2011 9:27 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       David Holmberg NIST Engineering Laboratory 301-975-6450    


  • 3.  RE: EI feedback

    Posted 04-29-2011 13:57
      |   view attached
    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.


  • 4.  RE: EI feedback

    Posted 04-29-2011 23:44
    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






  • 5.  RE: EI feedback

    Posted 05-02-2011 14:30
    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





  • 6.  RE: EI feedback

    Posted 05-02-2011 14:40
    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





  • 7.  RE: EI feedback

    Posted 05-02-2011 15:23
    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