OASIS Energy Interoperation TC

Back to discussions
Expand all | Collapse all

Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

  • 1.  Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

    Posted 12-15-2009 03:41 
    EI TC, 

Based on the discussions going on over last few days on the rationale
behind retaining Simple Client information along with the Smart Client
information, LBNL members have prepared this memorandum to cite few key
cases of why the Simple Client information is useful and must be retained.


The terms Simple and Smart Client information originate from OpenADR
Version 1.0 Specification that was donated to OASIS EI TC
(http://www.oasis-open.org/apps/org/workgroup/energyinterop/download.php/33260/cec-500-2009-063.pdf).

We will have a conversation on this at upcoming EI TC meeting on Wed. 12/16
at 8 a.m. PST. I appreciate if you could take a look at it prior to the
meeting. There will be a short presentation based on this document. 

Please let me know if you've questions and/or need more information. 

Thank you,
-Rish 

 -- Girish Ghatikar

The document named Smart_Simple_Client-Information
(Smart-Simple_Clients_20091211.pdf) has been submitted by Girish Ghatikar
to the OASIS Energy Interoperation TC document repository.

Document Description:
LBNL case for retaining Simple Client information as part of one XML
messaging schema along with other related information for DR events. 

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=35585

Download Document:  
http://www.oasis-open.org/committees/download.php/35585/Smart-Simple_Clients_20091211.pdf


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration


  • 2.  RE: [energyinterop] Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

    Posted 12-15-2009 11:16 
    Hi Rish, thank you.

I am not sure if I will be able to attend the meeting on the 16th and, thus, I will have to posit my thoughts here:
1. If one is to use a Bridge Client that bridges between smartness and dumbness then why does one need simple messages?

2. The premise of simplicity in programming does not take into account the complexity in INTEGRATION testing interoperation when the semantics are open to interpretation for each client. This gets even more complicated if we take into account DER (see #3)

3. I do not see any references to DER (Distributed Energy Resources) in which case different resources WILL have different interpretations of the same message. There are two choices here: use well defined messages with well defined semantics [exclusive] OR have the DRAS/Bridge Client interpret events for the permutation of each resource, each DR service provider, and each client

4. I have a hard time tying innovation to interoperability and standardization. What messages are we standardizing? To me, having subjective messages is anything but standardization and promotes many things but interoperation so what is actually being innovated (except for many bridge clients of different flavors)?

It seems to me that what is being proposed is more of a Profile/Preference technique to be applied to DR messages (based on client types) and possibly through a proxy such as Bridge Client.
 
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


  • 3.  Re: [energyinterop] Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf)uploaded

    Posted 12-15-2009 16:19 
    Michel,

I appreciate your comments and we will discuss them with the TC during 
tomorrow's meeting. Toby was planning to submit formal comments to the 
TC and if he can please capture your thoughts in that document, it would 
be helpful to guide the conversation.

Thank you,
-Rish

Michel Kohanim wrote:
> Hi Rish, thank you.
>
> I am not sure if I will be able to attend the meeting on the 16th and, thus, I will have to posit my thoughts here:
> 1. If one is to use a Bridge Client that bridges between smartness and dumbness then why does one need simple messages?
>
> 2. The premise of simplicity in programming does not take into account the complexity in INTEGRATION testing interoperation when the semantics are open to interpretation for each client. This gets even more complicated if we take into account DER (see #3)
>
> 3. I do not see any references to DER (Distributed Energy Resources) in which case different resources WILL have different interpretations of the same message. There are two choices here: use well defined messages with well defined semantics [exclusive] OR have the DRAS/Bridge Client interpret events for the permutation of each resource, each DR service provider, and each client
>
> 4. I have a hard time tying innovation to interoperability and standardization. What messages are we standardizing? To me, having subjective messages is anything but standardization and promotes many things but interoperation so what is actually being innovated (except for many bridge clients of different flavors)?
>
> It seems to me that what is being proposed is more of a Profile/Preference technique to be applied to DR messages (based on client types) and possibly through a proxy such as Bridge Client.
>  
> 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


  • 4.  RE: [energyinterop] Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

    Posted 12-15-2009 19:56 
    Michel & Team:

I see a couple things that should make an interesting discussion.  From
the note below it seems there may still be two levels to clarify.  In
reference to the question posed by Michel:  "What messages are we
standardizing?" and the note about subjective messages & interoperation,
are we all yet in agreement on these two separate concepts:

1 - standardized messages
2 - standardized response 

I'm wondering if we are all yet in agreement on these two basics. Are
some of us thinking these are the same thing?

On a possibly related note ... has anyone else reviewed the white paper
released by AHAM on Monday?  I can forward the PDF and some
notes-n-comment if desired.  It relates to how manufactures of devices
are willing to interface with the smart grid.  

Cheers,
Gale


Gale R. Horst

Electric Power Research Institute (EPRI) 
Office: 865-218-8078
ghorst@epri.com 



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  RE: AHAM doc, was [energyinterop] Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

    Posted 12-15-2009 20:16 
    










    


    Thanks,
Gale.
    


    


    I would love to see it, or a citation.
    


    


    Best,
    


    B.O.  December 15, 2009
    


    


    Robert Old
    


    Siemens Industry, Inc.
    


    Building Technologies
    


    1000 Deerfield Pkwy.
    


    Buffalo Grove, IL 60089-4513
    


    Tel.: +1 (847) 941-5623
    


    Skype: bobold2
    


    bob.old@siemens.com
    


    www.siemens.com
    


    


    



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [energyinterop] Groups - Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf) uploaded

    Posted 12-15-2009 20:47 
    Hi Gale,

Excellent points!

I should've been more clear in my usage of "message". I was using message as
a abstract concept which is used to communicate an event, action, or data
between multiple agents. As such, at a high level, a message could be any of
the following:
1. Request for data
2. Directive ( a command to be executed )
3. Response for a request and/or directive
4. A published Event (something of interest happened and I was notified)

In all cases, though, not having concrete meanings for the message
structures would cause interoperability problems.

And, I would also love to have a peek at that document.

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


  • 7.  Re: RE: [energyinterop] Groups -Smart_Simple_Client-Information (Smart-Simple_Clients_20091211.pdf)uploaded

    Posted 12-16-2009 18:28 
    "... I agreed with a Col. Conant, and some other Gentlemen, that if the British went out by Water, we would shew two Lanthorns in the North Church Steeple; and if by Land, one, as a Signal"  COL. PAUL REVERE circa 1775

The meaning of the signal (and associated action) is pre-arranged by the sending and receiving parties.  In DR, this is typically the utility/ISO (or their agent) and ratepayers.

-Dave Watson
LBNL
 






    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 8.  Signal Types

    Posted 12-17-2009 07:13 
    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


  • 9.  RE: Signal Types

    Posted 12-17-2009 15:35 
    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