[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Notification vs. Request vs. Order
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 <mailto:Toby.Considine@fac.unc.edu> Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com From: Horst, Gale [mailto:ghorst@epri.com] Sent: Monday, September 14, 2009 11:45 AM To: Wilson, David C (St. Paul); energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Notification vs. Request vs. Order Team: Those are interesting comments. I don't recall if we have discussed this before. But it begs questions about whether there are smart grid messages in this space that are tied to contractual obligations as described by the "Orders" classification Dave mentions. My first impulse is that regulatory and contractual obligations should not be tied to the messages but should be enabled and supportable by the messages. I think this discussion may fall under the header of project scope. Although I see the difference, 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? If the message is an "Order", the real difference is that you are not only wanting a grid-impacting change, you are counting on it. But it would seem that OpenADR DRAS should be able to accommodate this difference in a way that enables a clean one-to-many message rather than peer-to-peer. 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". My 2-cents, Gale Gale R. Horst Electric Power Research Institute (EPRI) Office: 865-218-8078 ghorst@epri.com ________________________________ From: Wilson, David C (St. Paul) [mailto:DavidCWilson@trane.com] Sent: Monday, September 14, 2009 9:16 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Notification vs. Request vs. Order Hi EI folks, In reflecting on Ed Koch's presentation last week, I start to think about the semantics of "Notifications", "Requests", and "Orders". Especially in the context of normal business transactions (Purchase Orders, Requests for Quotes, Price Notifications. I think part of what Ed was saying (and Ed I'd like to hear your thoughts) is that the presence of price information in the ESI messages don't identify the nature (i.e. sender's intent) of the message. I think it would be good if the ESI message/information is clearly identified as "Notifications", "Requests", or "Orders". Here is how I think of them: From the sender's perspective: Notifications: Here is some information. I want to be sure you received it because that is my responsibility. I don't care what you do with it (I might care what the majority of recipients do). Requests: I'd like you to do XYZ. Please let me know if you will do it or that you did it and maybe what the results are. Orders: We agreed that I could tell you to do XYZ. I may want you to confirm that you will and/or have. I might only care to learn after the fact that you did not do XYZ because I need to punish you. I may or may not be able to do anything with the knowledge that you plan to defy our agreement. Part of the difficulty I have in reconciling the CA OpenADR and the concept of the ESI is that the paradigm in my head for the DRAS is one system (Server, Client). I imagine the ESI "interface" to be between two systems ("Peer to Peer"). Not sure if that makes much of a difference at the Type level. I am advocating that the ESI we define have clear options for distinguishing between "Notifications", "Requests", and "Orders". Thoughts? Dave David Wilson Enterprise Solutions Portfolio Manager Trane Commercial Systems Ingersoll Rand Office: +1.651.407.4168 Mobile: +1.612.741.2759 Email: davidcwilson@trane.com <mailto:JSmith@trane.com> www.trane.com <http://www.trane.com/> The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]