OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [energyinterop] RE: [emix] Prices Absolute, Relative, and Programmed...


OK – but I need actionable information.

 

Questions (1)

 

1)      Is this a proposal that EMIX lose the Program level?

2)      Is this a proposal that EMIX lose the relative price?

 

Question (2)

 

So how do we communicate these things that are event related…

 

3)      Do we create shadow objects to travel alongside EMIX that communicate schedules for program information?

4)      Do we create shadow objects to travel alongside EMIX that communicate schedules for relative price information?

 

For each of the above, we could use WS-Calendar exactly as EMIX does.

 

 

 

It would be straightforward to vote “YES” on all four. Doing so would push the shadow objects into EI and out of EMIX, which could be a good thing.

 

We are at the point in these standards where editors need clean and clear direction…

 

tc

 


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

 

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: Girish Ghatikar [mailto:gghatikar@lbl.gov]
Sent: Wednesday, November 03, 2010 1:12 PM
To: Crimmins, Sean
Cc: Toby.Considine@gmail.com; emix@lists.oasis-open.org; energyinterop@lists.oasis-open.org; Chiu, Albert K
Subject: Re: [energyinterop] RE: [emix] Prices Absolute, Relative, and Programmed...

 

I second Sean.
-Rish

On Wed, Nov 3, 2010 at 9:15 AM, Crimmins, Sean <SCrimmins@caiso.com> wrote:

I would prefer EMIX stay focused on price and product.  If DR needs other types of messages, which it will, it can design those.  Program level and grid condition indicator are indexes that are not always related to a price, they could be used to reduce demand for reliability or in other cases where no price exists.

 

From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Wednesday, November 03, 2010 8:28 AM
To: emix@lists.oasis-open.org; energyinterop@lists.oasis-open.org
Cc: 'Chiu, Albert K'
Subject: [emix] Prices Absolute, Relative, and Programmed...

 

While personally I would like pure economic signals and TEMIX as the model, the OpenSG group provide *strong* guidance on two different approaches to DR in the short term at least.. These are:

 

(1)          Price Relative. Price from 2-3 this afternoon is at 1.75 times the [well known base price] [which may be different for different customers]

(2)          Program level. Appears in OpenADR 1.0 as High / Medium / Low. May need to support “Real High” and “Real Low” as well.

 

Presents two issues: (1) Where to communicate (EMIX or EI) and (2) How to communicate

 

Where to communicate.

 

a)            As We may need to communicate a series of program levels and relative prices varying over time, it must be EMIX.

b)            We need a suite of services to communicate context (Levels are based on a scale of 1-7), (Base Price is $0.30/kWH) . The context service should be in EI. EMIX may need to add context definitions.

 

(b)

How to communicate “Market Calibration”. When I go down to Home Depot and pick up my Home DRmation, I take it home, ask it to discover my house, it asks me (energy provider, customer ID, …) and it queries the Energy Provider / VTN” Tell me my context.

 

Price:

Perhaps it looks like the standard info in the financials page:

Current Price/ 30 day high, 30 day low, normal daily high, normal daily low

 

Relative Price

GetBasePrice/SetBasePrice…

 

Program Levels:

HowManyLevels, NormalLevel, EmergencyCommandLevel  (3,2,null) or (5,17,16)

 

(a)

 

In WD13 of EMIX, price looks like:

 

          <!-- 8.5 Price -->

          <xs:complexType name="type-price">

                   <xs:choice>

                             <xs:element name="absolutePrice" type="xs:decimal"/>

                             <xs:element name="relativePrice" type="xs:float"/>

                   </xs:choice>

          </xs:complexType>

 

It could easily look like:

 

          <!-- 8.5 Price -->

          <xs:complexType name="type-price">

                   <xs:choice>

                             <xs:element name="absolutePrice" type="xs:decimal"/>

                             <xs:element name="relativePrice" type="xs:float"/>

                             <xs:element name="programLevel" type="xs:int"/>

                   </xs:choice>

          </xs:complexType>

 

Alternately, we could create

 

          <!-- 8.5a ProgramSignal -->

          <xs:complexType name="type-programSignal">

                   <xs:sequence>

                             <xs:element name="programLevel" type="xs:int"/>

                             <xs:element name="programMax" type="xs:int"/>

                   </xs:sequence>

          </xs:complexType>

 

And then send fuller information to the customer as in:

 

          <!-- 8.5 Price -->

          <xs:complexType name="type-price">

                   <xs:sequence maxOccurrs="1">

                             <xs:choice>

                                       <xs:element name="absolutePrice" type="xs:decimal"/>

                                       <xs:element name="relativePrice" type="xs:float"/>

                             </xs:choice>

                             <xs:element name="programLevel" type="emix:xemix:type-programSignal" />

          </xs:complexType>

 

Clearly that last XML is not valid, but it is sent as a conversation starter. By defining this as price in this way, it fits into all existing EMIX products. WEQ quadrants can then conform some of these away.

 

Discuss….

 

tc

 


“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.


Toby Considine
TC9, Inc

OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 


*********************************************************************************************
The foregoing electronic message, together with any attachments thereto, is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee(s) and access to the message by anyone else is unauthorized. If you are not the intended recipient of this electronic message, you are hereby notified that any dissemination, distribution, or any action taken or omitted to be taken in reliance on it is strictly prohibited and may be unlawful. If you have received this electronic message in error, please delete and immediately notify the sender of this error.
*********************************************************************************************




--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax]

This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]