Skip to content

3) TOU + Seasonal Rate Design #96

@sherryzuo

Description

@sherryzuo

Objective

Design and justify a time-of-use (TOU) + seasonal rate structure specifically for heat pump (HP) customers that:

  1. Reflects hourly cost causation principles
  2. Incentivizes load flexibility and peak demand reduction
  3. Maintains revenue neutrality and affordability
  4. Quantifies bill impacts with and without enabling technologies

Primary Research Questions:

  • What TOU + seasonal rate structure scores best in terms of operating costs and allocative fairness?
  • How do bills change for different customer types under the proposed rate?

1. Methodology Dimensions

Two axes of methodology:

  • Axis 1: Analysis Complexity

    • Easy: Static comparative statics; cost allocation using Cambium data.
    • Difficult: Capacity expansion + dispatch modeling; behavioral response simulation.
  • Axis 2: Rate Ambition

    • Justifiable Rate: Rate design that is cost-based, defensible, and better than current flat/TOU rates.
    • Optimal Rate: Rate design that explicitly minimizes a welfare or cost misalignment objective, subject to constraints.

The combination produces four possible approaches:

Justifiable Rate Optimal Rate
Easy Analysis Quick TOU + seasonal design justified by Cambium marginal costs; static bill impact analysis. Solve for rates that minimize misalignment (e.g., squared error between bills and allocated costs) using static Cambium data.
Difficult Analysis Capacity-expansion-informed TOU design; rates reflect updated system costs as HP adoption grows; customer impact analysis with stylized responses. Full optimization of TOU periods and prices using system modeling + behavioral response; rates maximize alignment, minimize cross-subsidies, and preserve revenue neutrality.

2. Methodology Options


Easy + Justifiable (Baseline Benchmark)

  • Core idea: Develop a simple, defensible seasonal + TOU rate structure grounded in Cambium marginal costs, without formal optimization.
  • Inputs: Cambium hourly MEC (marginal energy cost), MCC (marginal capacity cost), and MPC (marginal portfolio cost).
  • Steps:
    1. Aggregate Cambium cost data to compute average winter vs. summer marginal costs.
    2. Identify peak vs. off-peak hours using simple heuristics (e.g., top-N load hours or fixed evening/midday windows).
    3. Assign rates that reflect these cost averages (e.g., higher $/kWh in winter peak, lower in summer off-peak).
    4. Apply to static load profiles of HP and non-HP customers to simulate annual bills.
  • Use case: Provides a transparent benchmark for regulators and stakeholders — “good enough” and cost-justified, but not optimized.

Easy + Optimal (Static Optimization)

  • Core idea: Use the same Cambium data as the Easy + Justifiable version, but apply optimization methods to set rates more precisely.
  • Inputs: Cambium MEC, MCC, MPC (hourly), plus static HP/non-HP load shapes.
  • Steps:
    1. Define an objective function: minimize the difference between customer bills and their allocated system costs (e.g., squared error or absolute deviation)
    2. Optimize rate levels for each TOU × seasonal block, subject to constraints:
      • Revenue neutrality (total bills = total system cost).
      • Practicality (rates remain within a feasible range).
    3. Compare optimized rates against simple heuristic rates from Easy + Justifiable.
  • Use case: Produces the most “cost-aligned” static rate design possible without running a capacity expansion model or modeling behavioral feedback.

Difficult + Justifiable (System-Informed, Heuristic Rate)

  • Core idea: Capture system evolution as HP adoption grows by running a capacity expansion model, but still design rates heuristically rather than optimally.
  • Inputs: Capacity expansion + dispatch model outputs (e.g., GenX, Switch) under scenarios with different HP penetration (10%, 25%, 50%).
  • Steps:
    1. Run the capacity expansion model to identify resource buildout and dispatch patterns under each adoption level.
    2. Extract hourly marginal cost profiles (MEC, MCC, MPC) that reflect the new resource mix and peaks.
    3. Define TOU periods heuristically:
      • Cluster high-cost vs. low-cost hours.
      • Explicitly separate winter vs. summer periods.
    4. Assign rates to recover seasonal cost shares, maintaining revenue neutrality.
    5. Apply to customer segments (HP vs. non-HP, with/without enabling tech) with stylized behavioral response assumptions (e.g., partial shifting).
  • Use case: Provides a system-consistent, future-looking rate design that reflects changing peaks, without the added complexity of optimization.

Difficult + Optimal (System + Behavioral Optimization)

  • Core idea: Combine system modeling with optimization of both rate levels and TOU window definitions, incorporating customer behavioral responses.
  • Inputs: Capacity expansion + dispatch results, customer load profiles, and behavioral response models.
  • Steps:
    1. Use clustering algorithms (e.g., k-means on hourly marginal costs) to define TOU windows that best capture cost variability.
    2. Optimize rate levels across all TOU × seasonal periods to minimize misalignment between bills and system costs.
    3. Include behavioral scenarios explicitly:
      • No shifting (status quo).
      • Partial shifting (bounded rationality).
      • Full optimization (tech-enabled load flexibility).
    4. Evaluate distributional impacts across customer groups and across HP penetration scenarios.
  • Use case: Delivers the most precise, cost-reflective, and forward-looking TOU + seasonal rates. Useful for long-term policy design, though complex and data-intensive.

3. Deliverables

  • Rate Design Outputs:

    • Tables of TOU + seasonal rates ($/kWh by season and period, fixed charges).
    • Justification of whether rates are justifiable (cost-based heuristic) or optimal (formal optimization).
  • Customer Impact Outputs:

    • Bill comparison charts (baseline vs. proposed rate).
    • Distributional impacts by group (HP vs. non-HP, with/without enabling tech, LMI vs. non-LMI).
    • Sensitivity results across behavioral cases (only in Difficult versions).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions