RE: Signal Types

["Holmberg, David" <david.holmberg@nist.gov>]

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%20UCAIug%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