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 communicateWhere 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 lowRelative PriceGetBasePrice/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, IncOASIS Technical Advisory Board
TC Chair: oBIX & WS-CalendarTC Editor: EMIX, EnergyInteropU.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  Email: 
Phone: (919)619-2104http://www.tcnine.com/
blog: www.NewDaedalus.com