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 <> 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
" target="_blank"> | www.xtensible.net
From: Crimmins, Sean
[mailto:]
Sent: Thursday, November 04, 2010
1:20 PM
To: Bruce Bartell;
; Girish Ghatikar
Cc: ;
; 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:]
Sent: Thursday, November 04,
2010 8:09 AM
To: ; Girish Ghatikar; Crimmins, Sean
Cc: ;
; 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
" target="_blank">
| www.xtensible.net
From: Toby
Considine [mailto:] On
Behalf Of Toby Considine
Sent: Wednesday, November 03,
2010 1:32 PM
To: 'Girish
Ghatikar'; 'Crimmins, Sean'
Cc: ;
; '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:
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com
From: Girish Ghatikar [mailto:]
Sent: Wednesday, November 03,
2010 1:12 PM
To: Crimmins, Sean
Cc: ;
; ; 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 <> 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:]
On Behalf Of Toby Considine
Sent: Wednesday, November 03,
2010 8:28 AM
To: ;
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:
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
| +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
| +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].
