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