[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] RE: Signal Types
Good discussion. Some further thoughts which may be obvious: The trusted interval meter is the best tool to reliably measure price or control response across domains. Having a device communicate its response back between the domains is of little value unless the trust in the response is equivalent to that of a sub meter in that the response can be used for billing. Yes, there is value in also confirming that price or control signals are received. This could be verified by having the meter record the price signals received. So if we can only manage what we can measure using a trusted meter or sub meter then there is no value in price or control signals that apply to anything other than what we can measure with a trusted meter or its equivalent. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 ed@cazalet.com www.cazalet.com -----Original Message----- From: Michel Kohanim [mailto:michel@universal-devices.com] Sent: Thursday, December 17, 2009 5:32 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] RE: Signal Types I totally agree. How about confirmation/acknowledgements for the receipt of the message? As David mentioned, I also see an overlap with SEP messages: 1. DRLC = Demand Response Load Control which instructs something to be done at some point in time and for some duration. The consumer has the choice of opting in or out. But, the process of opting in and out requires the responder to actually send a message back with the decision 2. Price which includes tiers, start time, and duration. This message does not require any type of confirmation or acknowledgement (but I think it should) 3. Messages which are text messages with start time and duration. Messages could require a confirmation I do think we have to address this overlap and the sooner we do the better. With kind regards, ******************************** Michel Kohanim, C.E.O Universal Devices, Inc. (p) 818.631.0333 (f) 818.436.0702 http://www.universal-devices.com ******************************** -----Original Message----- From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] Sent: Thursday, December 17, 2009 11:38 AM To: 'energyinterop@lists.oasis-open.org' Subject: RE: [energyinterop] RE: Signal Types I think the answer is "It Depends" If the terms and conditions of *your* agreement with *your* supplier are "When we say Jump, you will turn off your fish tank aerator and we will give you a dollar", then verification that the terms were met, i.e., the aerator was turned off, is required. If the terms and conditions of *your* agreement with *your* supplier are "Price is going to jump from $0.10 cents to $10M at 3:00", then the actual usage through the meter is the only information required. This parsimony is one of many reasons that price-based action is simpler and more secure. tc Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com -----Original Message----- From: Michel Kohanim [mailto:michel@universal-devices.com] Sent: Thursday, December 17, 2009 1:59 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] RE: Signal Types Hi David, Thanks. Are we saying that in some cases verification - or at least a confirmation - is not necessary? With kind regards, ******************************** Michel Kohanim, C.E.O Universal Devices, Inc. (p) 818.631.0333 (f) 818.436.0702 http://www.universal-devices.com ******************************** -----Original Message----- From: Holmberg, David [mailto:david.holmberg@nist.gov] Sent: Thursday, December 17, 2009 10:02 AM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] RE: Signal Types Michel, If I agree to let them, my utility Pepco plans to stick an RF relay on my AC and shut it off as needed on peak days. But if I am in control of acting on the signal, then yes. As for SEP, yes only the application layer. SEP 2.0 is supposed to be divorced from Zigbee and lower layers. David -----Original Message----- From: Michel Kohanim [mailto:michel@universal-devices.com] Sent: Thursday, December 17, 2009 12:17 PM To: energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] RE: Signal Types Ed, If I am interpreting this correctly, #3 is a specialization of #2: they are both instructions/directives; #2 instructs in relative terms and #3 in absolute. David, Wouldn't #3 require at least a V (not the M)? If not, then we are stuck with the same one way issues we have with one way thermostats: the customer can immediately go and change it back to some other settings. As far as SEP, are you referring to SEP's message payload or the full SEP stack with Zigbee as the underlying protocol? With kind regards, ******************************** Michel Kohanim, C.E.O Universal Devices, Inc. (p) 818.631.0333 (f) 818.436.0702 http://www.universal-devices.com ******************************** -----Original Message----- From: Holmberg, David [mailto:david.holmberg@nist.gov] Sent: Thursday, December 17, 2009 7:35 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] RE: Signal Types Ed, Thanks--this is a very useful organization of signals. I think when we agreed to address DR for the utilities as our first priority we agreed to address category #2. But some additional observations and questions before I'm sure on that point. The difference between the PGE CPP program (where we have 3 tiers of price, like 3 levels, but a category #1 collaborative energy message) versus a "go to shed level 2" category #2 command is the contractual response of category #2. An agreed upon response requires M&V. Neither categories #1 or #3 have M&V issues, only cat#2, because the utility has to verify the response per contract. And the M&V is inherently lame since it is reduction from a virtual baseline. And we all recognize, I think, that this is not the future for load response. Even the utilities get that to varying degrees. The other point is the utilities are using SEP for category #3, but they also see SEP serving category #2 for residential--and have C&I in view also (see the recent OpenADE presentation on the PAP10 list http://osgug.ucaiug.org/sgsystems/Shared%20Documents/PAP%2010/PAP%2010%20UCA Iug%20OpenSG%20-%20Customer%20Domain%20Involvement.ppt which shows plans for OpenADE and OpenHAN in the C&I space. And I'd note that SEP already addresses category #2). My point is that it seems that there is scope overlap between Energy Interop and SEP. Does that need to be resolved up front? I don't know. Does OpenSG see SEP being used to communicate to a C&I customer via the ESI? Or do they plan to use it via the meter to large customers? If we think of a multi-tier grid (microgrids and other lower levels), I think Ed's categories represent ownership and control boundaries. Category #2 is the fuzzy one which for C&I is generally within the facility boundary, and might use something like the BACnet Load Control object to send shed level signals. But as the owner, I might choose to use EIX down another level. Or oBIX. Or BACnet WS. Anyway, for residential there typically is no category #2 inside the home since there is no multi-level BAS, and the function of the EMS might exist at the utility in order to serve grid reliability concerns. I'd like to hear from the utility members. Does it matter for EI TC to address category #2 if we are not serving the residential space and SEP is handling category #2 with visions of extending this to C&I where it applies? Or is it, for all EI members, that we want to allow EIX to extend down into lower layers of the grid control hierarchy and serve the use case of contractual load shedding (think microgrids), and/or if and when utilities want to send signals via the ESI? David -----Original Message----- From: Edward Koch [mailto:ed@akuacom.com] Sent: Thursday, December 17, 2009 2:13 AM To: energyinterop@lists.oasis-open.org Subject: [energyinterop] Signal Types All, In order to help structure the discussion on what type of information should be supported in the signals the following categories may prove to be useful. These definitions are gleaned from a paper that Mary Ann and I wrote for Grid Interop. I believe that paper was posted to the TC's web site for anyone interested in reading it. Note that the following analysis is DR centric, but I think the same categories hold for those interactions that are not specifically DR by nature. Note that in the Grid Interop paper we used the notion of a DR Resource as the entity that is consuming the signals that are sent from a Utility or ISO. For the purposes of this TC we may decide to use a different term for that entity, but I think the core concepts still hold. Obviously all signals may contain many common attributes such as schedules, etc., but when you look at the core information that is contained in a signal it can be categorized as one of the following: (1) Supply State (2) DR Resource Instructions (3) Load Controller Commands Each of these is covered in more detail below. Supply state refers to information about conditions concerning the supply of electricity that may affect a DR Resource's load profile. Such information may include the following among others: * Price of electricity (e.g. absolute price, price tiers, rate multipliers, etc.) * Source of generation (e.g. hydro versus coal) * Carbon content * Reliability of supply The nature of this information is such that it does not include any specific instructions for how the load profile of the DR Resource is supposed to change. All decisions as to what the desired load profile should be in response to the information within the signal are entirely within the DR Resource itself. The most typical example of this type of DR signal is real-time or dynamic electricity prices that may be sent to a DR Resource. DR Resource Instructions refers to information that specifies what the load profile of the DR Resource should be as a result of receiving the signal. Examples of this type of information include the following among others: * Consumption levels, e.g. specific shed amounts such as 100KW, tiered shed levels, etc. * Dispatch instructions, e.g. ramp rates, etc. * Load profile specifications This type of information is more specific than Supply State in that it specifies what the load profile of the DR Resource should be. It does not specify how individual loads of the DR Resource should be controlled and thus the intelligence for determining how to control individual loads is entirely within the DR Resource itself. Typical examples of this include dispatch instructions that may be sent from an ISO to an aggregator or facility. Load Controller Commands refers to specific commands sent to the controller of a load that specifies the state that the load should be in, e.g. on/off. Examples of this include existing DR programs such as AC cycling in which air conditioners within residences are turned on and off. This is the type of information that is used for Direct Load Control. Clearly (1) is a collaborative interaction and (3) is a managed interaction. I've seen discussions on both sides as to whether (2) is managed or collaborative. Clearly (1) is within the scope of this TC and if we agree that direct load control is out of scope then we can eliminate (3). Other than the recent discussions on the simple levels there hasn't been much discussion about the information types in (2). Clearly there are a lot of DR programs that use signals of type (2) so in my opinion we will need to support at least some if not all signals of that type, but without a further enumeration of the different data types in (2) it would be premature for me to make a blanket statement. Note that in OpenADR we specifically supported (1) and (2), but not (3). Comments, suggestions? -ed koch --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]