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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

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


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


Agreed that PRICE_MULTIPLE does not have same issues (it's not $ representation in data models). However, it's part of the dynamic pricing offerings for DR. Hence, they should primarily part of EI.

Knowing base price is important if we know the service provider (VTN) provides it. For $x value (weather we know it or now), $y would be the PRICE_RELATIVE that's the adder to the base ($x+$y). This is called in "anticipation" of supply shortage. However, if more is needed, further programs are called -- it's how the particular DR market is structured in a specific service provider's territory.

-Rish

On Fri, Nov 5, 2010 at 3:23 AM, Toby Considine <Toby.Considine@gmail.com> wrote:

I want to understand how “well known” the price is. Clearly a $0.50/kWH uptick is huge if my base price is $0.10. It may be insignificant if my base price is $1.00.

 

If I have an annual consistent hourly price, (or even seasonal, so two price schedules per year), is the uptick based on a formal base price, the hourly base price, or something else?

 

If [PG&E] declared Peak Day Pricing for next Tuesday, and then has an unanticipated shortage (All the solar does not come through), does it deliver an uptick on the original base price, the time of day, on the peak day pricing price, …

 

It is not an answer to say “Well with the tariff we have this year in this state, it only works one way” I want some firmer rules. For the use.

 

 

Oh, and we clear need some agreed on definitions. Relative price as written as what Rish has names Price Multiple…Price Multiple does not have the issue in the first paragraph.

 

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: Thursday, November 04, 2010 6:17 PM
To: Crimmins, Sean; Bruce Bartell

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

 

Sean,
The current interpretation of "PRICE_RELATIVE" is indicative of a price "adder" to whatever price the consumer would be paying under normal conditions (hence there is no likely need to transmit the base price). This price adder is part of a "price event" of a DR program. Under, PG&E, it's Peak Day Pricing, which happens ~12 times a year for certain hours a day and the consumers are notified just as a DR event is notified for reliability program (e.g., load reduction notification). The end goal is the same -- you'll pay more if you don't curtail load and/or the grid will be unstable.

Hence, the clear delineation of communication for dynamic price mechanisms used for DR and those for other areas have to be addressed. There are other dynamic price-related DR notifications as well such as PRICE_MULTIPLE (not transmitting actual $ values) and PRICE_ABSOLUTE, which actually transmits the market price. Of these, what I see the closest resemblance to EMIX is PRICE_ABSOLUTE as it can be continuous prices with no defined DR event. However, we may also want to consider that there might be a need to send a targeted DR event prices (ABSOLUTES) and provide such hooks in EI.

I agree with you that levels (or what we call operation modes) and grid conditions are not price. The levels and grid conditions can be proxy for price.

Hope that helps.

Thanks,
-Rish

On Thu, Nov 4, 2010 at 12:59 PM, Bruce Bartell <bbartell@xtensible.net> wrote:

There is a relative price that is only available as a participant in a DR Program, i.e. x% discount to participate and/or % penalty to not participate. It may be easier to work out as a discussion. I am not aware of a relative price outside of that, maybe Girish knows of some.

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net


From: Crimmins, Sean [mailto:SCrimmins@caiso.com]
Sent: Thursday, November 04, 2010 1:20 PM
To: Bruce Bartell; Toby.Considine@gmail.com; Girish Ghatikar


Cc: emix@lists.oasis-open.org; energyinterop@lists.oasis-open.org; Chiu, Albert K
Subject: RE: [energyinterop] RE: [emix] Prices Absolute, Relative, and Programmed...

 

My view is that relative price is still price so belongs in EMIX.

 

Program level and grid condition indicators are not price.  Do they travel alongside price?  I think it is better that these signals are independent.  Consumers should be able to subscribe to the signals that they’re interested in, having them parse a bucket of info has several problems:

·        They have to parse much more info than they need.

·        The multiple data sets in the payloads change at different times

·        The structure of the payload will change much more frequently potentially forcing redeployment of the services

 

Sean

 

From: Bruce Bartell [mailto:bbartell@xtensible.net]
Sent: Thursday, November 04, 2010 8:09 AM
To: Toby.Considine@gmail.com; Girish Ghatikar; Crimmins, Sean
Cc: emix@lists.oasis-open.org; energyinterop@lists.oasis-open.org; Chiu, Albert K
Subject: RE: [energyinterop] RE: [emix] Prices Absolute, Relative, and Programmed...

 

If the only issue is that these requirements are considered totally DR and hence, EI requirements, then I concur.

We will have to make sure they are included in the EI somewhere. I have not had a chance to look into the items listed in detail and do not expect to be on today’s call. Can we put this into the EI hopper for next week?

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net


From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Wednesday, November 03, 2010 1:32 PM
To: 'Girish Ghatikar'; 'Crimmins, Sean'
Cc: emix@lists.oasis-open.org; energyinterop@lists.oasis-open.org; 'Chiu, Albert K'
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].


*********************************************************************************************
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].




--
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]