Signal Types

[Edward Koch <ed@akuacom.com>]

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