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.