OASIS Energy Interoperation TC

  • 1.  RE: [energyinterop] Notification vs. Request vs. Order

    Posted 09-15-2009 13:09
    K.I.S.S. is good, but things can only be so simple.  Devices need to be smart enough to handle the contemplated programs.  
     
    Your example could refer to a Direct Load Control command to a Programmable Communicating Thermostat in a residential application.  Or it could be a curtailment request to a large building.  
     
    For a PCT, the command might include a program ID, an event ID, event type (increase setpoint on AC), a start time and duration, and perhaps a priority of importance over other possible programs.  The PCT needs to acknowledge, non-repudiably (if that's a word,)  that it agrees to respond as required by the program.  Perhaps it already knows that it is exempt from particular responses and it sends that response (can't turn off invalid's air conditioning completely.)  
     
    Perhaps an hour ahead of the scheduled event the resident decides not to participate because they're hosting a child's birthday party and are willing to pay any price to keep the kids happy.  They push a button on the PCT which signals the utility and opts-out of that event.
     
    For a C&I consumer, the command might include a utility/aggregator ID, program ID, and event ID, event type (request for curtailment,) baseline below which you must curtail in order to get credit, a start time and duration, and perhaps a priority of importance over other possible programs.  The ESI acknowledges, non-repudiably, and perhaps includes an estimate of the amount of demand below the baseline that can be curtailed.  After the event, the utility/aggregator and the ESI both acquire the meter data relevent to the event.  The utility/aggregator uses it for settlement of the transaction, the ESI uses it to verify the settlement and perhaps refine it's model of building behavior.
     
    Undoubtably, the contract between the building operator and the utility/aggregator specifies the terms and conditions for opting out of an agreemement.
     
    I'm not sure things can be made simple, due to the large scale of the application.  I've always heard that if you want to do Electric Utilities applications, you have to be able to do at least a million.
     
    Best,
    B.O.  September 15, 2009
    --
    Robert Old, System Architecture, bob.old@siemens.com
    Siemens Building Technologies, Inc., HVAC Products
    1000 Deerfield Pkwy., Buffalo Grove, IL 60089-4513  USA
    Phone: +1(847)941-5623, Skype: bobold2
    
    
    ________________________________
    
    From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
    Sent: Mon 9/14/2009 7:13 PM
    To: 'energyinterop@lists.oasis-open.org'
    Subject: RE: [energyinterop] Notification vs. Request vs. Order
    
    
    
    I'm with Gale
    
     
    
    If I have a contract with you that says "I may respond", then you need to notify me.
    
    If I have a contract that "I must respond" then you need to notify me.
    
    Notification is notification.
    
     
    
    But I do have a question. What is the interaction to tell [relatively dumb device] the contract #[must respond] ids in place, so device knows that a manadatory response is required tomorrow. Worrying about this is what keeps me from a simple price & notification only model...
    
     
    
    tc
    
     
    
    ________________________________
    
    "A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift
    
    ________________________________
    
    Toby Considine
    
    Chair, OASIS oBIX TC
    Facilities Technology Office
    University of North Carolina
    Chapel Hill, NC
    
      
    
    Email: Toby.Considine@ unc.edu 


  • 2.  RE: [energyinterop] Notification vs. Request vs. Order

    Posted 09-15-2009 15:19
    Thanks to everyone commenting on my email on this subject.  I've been
    reading all the replies with great interest.
    
    I want to build on some of the comments. My thoughts follow quotes from
    some of the emails (mine prefixed "DCW:").
    
    M. Kohanim >> without the use-cases [...] these messages may change
    dramatically depending on the actors.
    
    DCW: Good point, see Gale's last comment below. 
    
    Gale Horst >> regulatory and contractual obligations should not be tied
    to the messages but should be enabled and supportable by the messages.
    
    DCW: Agreed.  The messages should be support the different commercial
    agreements.
    
    Gale Horst >> I have a difficulty separating a notification from a
    request.  If you don't intend to motivate a response, why would you send
    a notice?  
    
    DCW:  The small distinction I tried to communicate is that the ESI needs
    to support a building response that differentiates between "I got your
    message" and "This is my reaction to your message".  
    
    Toby >> What is the interaction to tell [relatively dumb device] the
    contract #[must respond] ids in place, so device knows that a mandatory
    response is required tomorrow. Worrying about this is what keeps me from
    a simple price & notification only model...
    
    DCW: I think to be widely adopted the by commercial buildings, the ESI
    should include a schedule-less option.  The utility / OpenADR "Program
    Notifier" should not expect that the building will be able to schedule
    the event.  
    
    Bob Old >> Your example could refer to a Direct Load Control command to
    a Programmable Communicating Thermostat in a residential application.
    Or it could be a curtailment request to a large building.  
    
    DCW:  To both Bob & Toby's point with dumb devices.  Maybe one option is
    that the Notifier sends a count down. "Event in T -27 hours"...."Event
    in T -8 hours"..."Event now".  This allows a dumb device to simply be
    configured for the amount of lead time it needs to begin responding.
    
    Gale >> If peer-to-peer is desired, then the DRAS would represent the
    end use node and be considered the "peer" that responds to the "order".
    
    DCW: Wow! That was a very helpful statement!  I have been struggling
    with reconciling the DRAS design and the NIST interface list.  I've been
    playing "pin the DRAS on the roadmap" without much mental success (NIST
    Interface diagram link below).  Mostly I was trying to determine how far
    the DRAS penetrated the customer domain.  I didn't consider that maybe
    the entire DRAS is inside the customer domain.  Maybe the Grid
    Operations to Customer (NIST terms) interface is the Utility to DRAS
    interface (OpenADR terms). For example the "Utility Program Notifier
    creates and initiates Base Interruptible Program Event" use case shown
    in OpenADR figure D12 (see URL below). 
    
    NIST Interface diagram
    http://www.oasis-open.org/apps/org/workgroup/energyinterop/document.php?
    document_id=34213
    
    OpenADR Base Interruptible Program Use Case Picture (Figure D12)
    http://www.oasis-open.org/apps/org/workgroup/energyinterop/document.php?
    document_id=34212
    
    =======
    
    Again, thanks to everyone for the lively discussion!  I will attempt to
    carry on the Actors / Roles conversation in a separate thread.
    
    Regards,
    Dave
    
    Office: +1.651.407.4168
    Mobile: +1.612.741.2759
    Email: davidcwilson@trane.com