OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (EMIX-439) wd28: Clarifypurpose/scope of Demand Charge structure.



     [ http://tools.oasis-open.org/issues/browse/EMIX-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated EMIX-439:
-----------------------------

    Fix Version/s: wd30
       Resolution: Clarified in wd30. Move to resolved.  (was: Clarified.)

> wd28: Clarify purpose/scope of Demand Charge structure.
> -------------------------------------------------------
>
>                 Key: EMIX-439
>                 URL: http://tools.oasis-open.org/issues/browse/EMIX-439
>             Project: OASIS Energy Market Information Exchange (eMIX) TC
>          Issue Type: Improvement
>          Components: schema, spec
>         Environment: Anne Hendry
>            Reporter: Anne Hendry 
>            Assignee: Anne Hendry 
>             Fix For: wd30
>
>
> The scope and purpose of the current Demand Charge structure and how it would be used to calculate a Demand Charge is unclear.
> Is it provided to calculate peak demand (eg. kW) only,
> or to calculate the cost ($) per unit (eg. kW) of demand only,
> or calculate the cumulative demand charge you will be billed in any billing period,
> or all the above,
> or?
> Taking a typical (and probably simplified) example such as in:
> http://smud.apogee.net/comsuite/content/ces_ud/?utilid=smud&id=2486 ...
> Given the complexity of multiple pricing schedules and historical-based pricing methods with which Peak Demand is calculated before price schedules are applied, along with adjustment factors, I don't see how the following structure accommodates the complexity of accounting for historical-based pricing, or multiple pricing programs/tiers, or other factors used to calculate a demand charges.  It seems heavy on the time periods (duration) and light on other information that would be needed to effectively complete calculations of demand charges.
> For instance, I don't see where you would store the value for the actual quantity that is Peak Demand (peak kW) yet we have several different time value types dedicated to determining that Peak Demand number (measurementInterval, collectionInterval, etc).
> Perhaps some of this may be out of scope for EMIX, and if so, we should be clear about the EMIX scope being presented here.  For instance, if the majority of calculations are expected to be done outside of EMIX, and EMIX simply sends final determined demand price with 'descriptive' information, then we could remove several of these elements and just convey peak demand quantity and price in any single measurement time period.  If the calculations to determine demand charges are attempting to be done within EMIX, I believe we'd need more elements to hold pricing, quantity, and other calculation method information.
> Demand Charge structure from schema (with element datatypes in parens to right):
>    <xs:element name="demandCharge" type="power:DemandChargeType" substitutionGroup="power:baseCharge"/>
> − <xs:complexType name="DemandChargeType" mixed="false">
>    − <xs:complexContent mixed="false">
>       − <xs:extension base="power:BaseChargeType"> (abstract class, no units)
>          − <xs:sequence>
>            <xs:element name="demandChargeUnits" type="power:PowerItemType"/
>                                                                                                                       (Description(string)+Units(string)+SIScale(string),
>                                                                                                                                      +Attributes(hz,volt,ac -- decimal/boolean))
>            <xs:element name="demandChargeFloor" type="emix:QuantityType"/>        (float)
>            <xs:element name="demandChargeRate" type="emix:PriceBaseType"/>     (abstract class (no units);
>                                                                                                                                                    should it be PriceType (value: decimal)?)
>            <xs:element name="measurementInterval" type="xcal:DurationPropType"/> (relative time period)
>            <xs:element name="collectionInterval" type="xcal:DurationPropType"/>         (relative time period)
>            <xs:element name="collectionPeriod" type="xcal:DurationPropType"/>          (relative time period)
>             <xs:element name="chargeDuration" type="xcal:DurationPropType"/>          (relative time period)
>          </xs:sequence>
>       </xs:extension>
>    </xs:complexContent>
> </xs:complexType>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]