Uploaded image for project: 'OASIS Energy Market Information Exchange (eMIX) TC'
  1. OASIS Energy Market Information Exchange (eMIX) TC
  2. EMIX-439

wd28: Clarify purpose/scope of Demand Charge structure.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: wd30
    • Component/s: schema, spec
    • Labels:
      None
    • Environment:

      Anne Hendry

    • Proposal:
      Hide

      Clarify as per description section.

      Show
      Clarify as per description section.
    • Resolution:
      Hide

      Clarified in wd30. Move to resolved.

      Show
      Clarified in wd30. Move to resolved.

      Description

      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>

        Attachments

          Activity

            People

            • Assignee:
              ahendry Anne Hendry (Inactive)
              Reporter:
              ahendry Anne Hendry (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: