OASIS Energy Market Information Exchange (eMIX) TC

The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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    

When defining the problem think of Time of Use Intervals as tiers that encapsulate consumption blocks (which are defined in emix as blockPowerFullRequirements). This is the Zigbee slide in the link I provided.   I do not understand enough about what you are proposing to say if it will work. It needs to be reflected in EiQuote somehow. The SE2 Price message I provided does not attempt to get slick with recurrences. They just publish a schedule that looks like above but with dates and times.   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: Thursday, July 28, 2011 12:13 PM To: emix@lists.oasis-open.org Subject: [emix] Tiered Pricing   The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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    

Bruce and all -- Some management-style3 questions... Much of this is structured for the California block and tier tariffs, is it not? How much is SEP2 information model to reflect that? How fluid is that information model? Is it a moving target?  Is it anchored (at least for 2.00) by the block and tier tariffs above? Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 7/28/11 12:30 PM, Bartell, Bruce wrote: 11A10A3E358E18449E81E08CB2AC312A024FB4D8@mail.twacs.com type= cite > When defining the problem think of Time of Use Intervals as tiers that encapsulate consumption blocks (which are defined in emix as blockPowerFullRequirements). This is the Zigbee slide in the link I provided.   I do not understand enough about what you are proposing to say if it will work. It needs to be reflected in EiQuote somehow. The SE2 Price message I provided does not attempt to get slick with recurrences. They just publish a schedule that looks like above but with dates and times.   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: Thursday, July 28, 2011 12:13 PM To: emix@lists.oasis-open.org Subject: [emix] Tiered Pricing   The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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    

Answers embedded below.   Bruce Bartell Xtensible Solutions Mobile : +1.321.258.6500 bbartell@xtensible.net      www.xtensible.net From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com] Sent: Thursday, July 28, 2011 3:26 PM To: Bartell, Bruce Cc: Toby.Considine@gmail.com ; emix@lists.oasis-open.org Subject: Re: [emix] Tiered Pricing   Bruce and all -- Some management-style3 questions... Much of this is structured for the California block and tier tariffs, is it not? >This is not just for California . BC Hydro used the same structure along with other utilities in different states. How much is SEP2 information model to reflect that? >It is fully modeled in the SEP2. How fluid is that information model? Is it a moving target?  Is it anchored (at least for 2.00) by the block and tier tariffs above? >The SEP 2.0 pricing model is based on IEC61968 which is a stable model although its 2nd release is still in circulation for comments. In the current SEP 2.0 model, block tiers are contained by TOU but the original CIM model can deal with the other way around (i.e., block to contain tou tiers)     Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 7/28/11 12:30 PM, Bartell, Bruce wrote: When defining the problem think of Time of Use Intervals as tiers that encapsulate consumption blocks (which are defined in emix as blockPowerFullRequirements). This is the Zigbee slide in the link I provided.   I do not understand enough about what you are proposing to say if it will work. It needs to be reflected in EiQuote somehow. The SE2 Price message I provided does not attempt to get slick with recurrences. They just publish a schedule that looks like above but with dates and times.   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: Thursday, July 28, 2011 12:13 PM To: emix@lists.oasis-open.org Subject: [emix] Tiered Pricing   The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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    

Any changes needed to the fragment I sent yesterday?   tc     " It is the theory that decides what can be observed ."   - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC    Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com     From: Bartell, Bruce [mailto:bbartell@xtensible.net] Sent: Friday, July 29, 2011 10:31 AM To: William Cox Cc: Toby.Considine@gmail.com; emix@lists.oasis-open.org Subject: RE: [emix] Tiered Pricing   Answers embedded below.   Bruce Bartell Xtensible Solutions Mobile: +1.321.258.6500 bbartell@xtensible.net      www.xtensible.net From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com] Sent: Thursday, July 28, 2011 3:26 PM To: Bartell, Bruce Cc: Toby.Considine@gmail.com; emix@lists.oasis-open.org Subject: Re: [emix] Tiered Pricing   Bruce and all -- Some management-style3 questions... Much of this is structured for the California block and tier tariffs, is it not? >This is not just for California. BC Hydro used the same structure along with other utilities in different states. How much is SEP2 information model to reflect that? >It is fully modeled in the SEP2. How fluid is that information model? Is it a moving target?  Is it anchored (at least for 2.00) by the block and tier tariffs above? >The SEP 2.0 pricing model is based on IEC61968 which is a stable model although its 2nd release is still in circulation for comments. In the current SEP 2.0 model, block tiers are contained by TOU but the original CIM model can deal with the other way around (i.e., block to contain tou tiers)     Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 7/28/11 12:30 PM, Bartell, Bruce wrote: When defining the problem think of Time of Use Intervals as tiers that encapsulate consumption blocks (which are defined in emix as blockPowerFullRequirements). This is the Zigbee slide in the link I provided.   I do not understand enough about what you are proposing to say if it will work. It needs to be reflected in EiQuote somehow. The SE2 Price message I provided does not attempt to get slick with recurrences. They just publish a schedule that looks like above but with dates and times.   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: Thursday, July 28, 2011 12:13 PM To: emix@lists.oasis-open.org Subject: [emix] Tiered Pricing   The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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    

That table is very useful.   That table is (I believe) represented by the attached fragment…   tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you."   - Fredrich Nietzche 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: Bartell, Bruce [mailto:bbartell@xtensible.net] Sent: Thursday, July 28, 2011 12:31 PM To: Toby.Considine@gmail.com; emix@lists.oasis-open.org Subject: RE: [emix] Tiered Pricing   When defining the problem think of Time of Use Intervals as tiers that encapsulate consumption blocks (which are defined in emix as blockPowerFullRequirements). This is the Zigbee slide in the link I provided.   I do not understand enough about what you are proposing to say if it will work. It needs to be reflected in EiQuote somehow. The SE2 Price message I provided does not attempt to get slick with recurrences. They just publish a schedule that looks like above but with dates and times.   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: Thursday, July 28, 2011 12:13 PM To: emix@lists.oasis-open.org Subject: [emix] Tiered Pricing   The solution I believe is to use power:blockPowerFullRequirements (which has tiers) inside each interval through the day. In this way we can state what the tiers are for each hour of the day and have the size (of the tiers) and or prices (for each tier) vary within that interval.   If we are communicating day-ahead communication of tiers, that is all we need.   As a further issue, there may be a desire to template the communications, i.e., to state weekdays vs weekends (assuming they had different price tiers). This we could accomplish by: 1)       Building two unscheduled sequences, as above. 2)       Sending 5 gluons (for M-F) starts referencing one sequence, and two gluons (for Sa-Su) starts.   Alternately, one could want to announce that a particular tiered pricing in in place during the summer months. This could be done by a Gluon with two vavailabilitys (weekdays and weekends), and having each vavaialbility reference the appropriate sequence.   Do we need more than that?   tc       “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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     <?xml version="1.0"?> <!--EMIX 1.0 Full Requirements with Tiers--> <emix:product xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0" xmlns:scale=" http://docs.oasis-open.org/ns/emix/2011/06/siscale" ; xmlns:xs=" http://www.w3.org/2001/XMLSchema-instance" ; xmlns:power=" http://docs.oasis-open.org/ns/emix/2011/06/power" ; xmlns:res=" http://docs.oasis-open.org/ns/emix/2011/06/power/resource" ; xmlns:emix=" http://docs.oasis-open.org/ns/emix/2011/06" ;> <xcal:components> <xcal:gluon> <xcal:properties> <xcal:uid> <xcal:text>1a092f29-4d2c-4a88-8c1d-7fcf89dd7838</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>Pacific Daylight Time</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-05-28T00:00:00</xcal:date-time> </xcal:dtstart> <xcal:x-wsCalendar-attach> <emix:productDescription xs:type="power:blockPowerFullRequirements"> <power:productType>FullRequirementsPowerBlockPricing</power:productType> <power:serviceDeliveryPoint> <power:node>xxxnode.idxx</power:node> </power:serviceDeliveryPoint> <power:unitEnergyPrice> <emix:price> <emix:value>0.12</emix:value> </emix:price> <power:energyReal> <power:itemDescription>RealEnergy</power:itemDescription> <power:itemUnits>Wh</power:itemUnits> <scale:siScaleCode>k</scale:siScaleCode> </power:energyReal> </power:unitEnergyPrice> <power:powerReal> <power:itemDescription>RealPower</power:itemDescription> <power:itemUnits>W</power:itemUnits> <scale:siScaleCode>k</scale:siScaleCode> <power:powerAttributes> <power:hertz>60</power:hertz> <power:voltage>220</power:voltage> <power:ac>true</power:ac> </power:powerAttributes> </power:powerReal> <power:maximumPower>1000</power:maximumPower> <power:minimumPower>0</power:minimumPower> <power:priceTiers> </power:priceTiers> </emix:productDescription> </xcal:x-wsCalendar-attach> </xcal:properties> <xcal:components/> </xcal:gluon> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>bddd505a-f497-4b77-bbc8-c1094793e6d7</xcal:text> </xcal:uid> <xcal:duration> <xcal:duration>PT6H</xcal:duration> </xcal:duration> <xcal:x-wsCalendar-attach> <emix:productDescription xs:type="power:blockPowerFullRequirements"> <power:productType>FullRequirementsPowerBlockPricing</power:productType> <power:priceTiers> <power:blockPowerPrice> <emix:price> <emix:value>0.05</emix:value> </emix:price> <power:maximumEnergyQuantity>400</power:maximumEnergyQuantity> </power:blockPowerPrice> <power:blockPowerPrice> <emix:price> <emix:value>0.12</emix:value> </emix:price> <power:maximumEnergyQuantity>4000</power:maximumEnergyQuantity> </power:blockPowerPrice> </power:priceTiers> </emix:productDescription> </xcal:x-wsCalendar-attach> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>d87ec942-0e0c-40b7-a457-a1afb9e4251c</xcal:text> </xcal:uid> <xcal:related-to> <xcal:uid>bddd505a-f497-4b77-bbc8-c1094793e6d7</xcal:uid> </xcal:related-to> <xcal:duration> <xcal:duration>PT9H</xcal:duration> </xcal:duration> <xcal:x-wsCalendar-attach> <emix:productDescription xs:type="power:blockPowerFullRequirements"> <power:productType>FullRequirementsPowerBlockPricing</power:productType> <power:priceTiers> <power:blockPowerPrice> <emix:price> <emix:value>0.10</emix:value> </emix:price> <power:maximumEnergyQuantity>400</power:maximumEnergyQuantity> </power:blockPowerPrice> <power:blockPowerPrice> <emix:price> <emix:value>0.17</emix:value> </emix:price> <power:maximumEnergyQuantity>4000</power:maximumEnergyQuantity> </power:blockPowerPrice> </power:priceTiers> </emix:productDescription> </xcal:x-wsCalendar-attach> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>cb5069b4-9198-434e-8ee7-d81f00fe8ebe</xcal:text> </xcal:uid> <xcal:related-to> <xcal:uid>d87ec942-0e0c-40b7-a457-a1afb9e4251c</xcal:uid> </xcal:related-to> <xcal:duration> <xcal:duration>PT5H</xcal:duration> </xcal:duration> <xcal:x-wsCalendar-attach> <emix:productDescription xs:type="power:blockPowerFullRequirements"> <power:productType>FullRequirementsPowerBlockPricing</power:productType> <power:priceTiers> <power:blockPowerPrice> <emix:price> <emix:value>0.20</emix:value> </emix:price> <power:maximumEnergyQuantity>400</power:maximumEnergyQuantity> </power:blockPowerPrice> <power:blockPowerPrice> <emix:price> <emix:value>0.27</emix:value> </emix:price> <power:maximumEnergyQuantity>4000</power:maximumEnergyQuantity> </power:blockPowerPrice> </power:priceTiers> </emix:productDescription> </xcal:x-wsCalendar-attach> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>a52ae263-4c58-4970-a1c0-24cf14447c9a</xcal:text> </xcal:uid> <xcal:related-to> <xcal:parameters> <xcal:reltype> <xcal:text/> </xcal:reltype> </xcal:parameters> <xcal:uid>cb5069b4-9198-434e-8ee7-d81f00fe8ebe</xcal:uid> </xcal:related-to> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>b17a4ef1-b734-458e-ba59-cb361740a5d1</xcal:text> </xcal:uid> <xcal:duration> <xcal:duration>PT4H</xcal:duration> </xcal:duration> <xcal:x-wsCalendar-attach> <emix:productDescription xs:type="power:blockPowerFullRequirements"> <power:productType>FullRequirementsPowerBlockPricing</power:productType> <power:priceTiers> <power:blockPowerPrice> <emix:price> <emix:value>0.05</emix:value> </emix:price> <power:maximumEnergyQuantity>400</power:maximumEnergyQuantity> </power:blockPowerPrice> <power:blockPowerPrice> <emix:price> <emix:value>0.12</emix:value> </emix:price> <power:maximumEnergyQuantity>4000</power:maximumEnergyQuantity> </power:blockPowerPrice> </power:priceTiers> </emix:productDescription> </xcal:x-wsCalendar-attach> </xcal:properties> </xcal:interval> </xcal:components> <emix:uid/> <emix:transactiveState>Publication</emix:transactiveState> <emix:currency>USD</emix:currency> <emix:marketContext/> <emix:side>Buy</emix:side> <emix:terms/> </emix:product>