A pricing Service for Electricity

in , , ,

What price structures are necessary to enable fully symmetric negotiations over power purchase and sale? Over at the NIST TWIKI, Marty Burns, Bill Cox, and I ironed out the requirements for a pricing service for electricity. Comments are welcome.

What are the requirements for communicating price across the smart grid? What pricing structures are in use or under development now? How do we move to a common information element, common whatever else needed for prices?

Note: It is important to emphasize that these are requirements for a solution set for pricing services. Therefore all the following requirements are not necessarily simultaneously applied to any particular single service based on the ensuing model.

Due to potentially [rapidly] changing roles, we use the terms supplier and consumer rather than utility and customer. With aggregators, these terms are still more general.

This page was created and modified by Marty Burns, Toby Considine, and William Cox, for discussion among the DEWGs.

Pricing Requirements

Dynamic pricing enables dynamic power management and includes both:

1) the realtime response of automation systems to "realtime" grid pricing and

2) the managed response of consumer management and planning systems to supplier/grid price forecasts.

  • 1.1 Regulatory/Policy

    •  

    • 1.1.1 Metering, Billing, and Collections are separate processes / services from power delivery.
    • 1.1.2 Aggregation and Delegation should be explicitly permitted for all operations.
    • 1.1.3 The pricing model is not explicitly tied to any particular regulatory environment.
    • 1.1.4 Barriers to symmetric operations should be eliminated.
      • 1.1.4.1 Suppliers and consumers may exchange roles at frequent intervals.
    • 1.1.5 Businesses willl handle traditional business processes as they do now.
  • 1.2 Business Objectives
    • 1.2.1 Suppliers are able to provide automated dynamic pricing information to consumers.
    • 1.2.2 Pricing is able to support active power management and optimization.
      • 1.2.2.1 Price adjustments can be made in time in up near real time manner.
      • 1.2.2.2 Prices may include commitment enforcement in support of a variety of scenarios, including both minimum and maximum commitments.
    • 1.2.3 Pricing should be available for a variety of deliverables.
      • 1.2.3.1 Power Consumption.
      • 1.2.3.2 Peak Availability.
      • 1.2.3.3 Relinquishment of prior right (Differential Behavior vs Absolute Consumption).
      • 1.2.3.4 Power Quality.
      • 1.2.3.5 Carbon Offsets.
      • 1.2.3.6 Transmission and Congestion.
    • 1.2.4 Pricing should support the decommoditization of power.
      • 1.2.4.1 Wind, Distance, Carbon, Triple Bottom Line, and other attributes.
    • 1.2.5 Pricing should be time sensitive.
      • 1.2.5.1 Time offer made.
      • 1.2.5.2 Window for offer.
      • 1.2.5.3 Time of acceptance.
      • 1.2.5.4 Scheduled Time of consumption.
      • 1.2.5.5 Actual Time of Aggregation.
  • 1.3 Business Procedures
    • 1.3.1 A set of core processes and transactions will be defined.
    • 1.3.2 A service to support each core process will be defined.
    • 1.3.3 A common service framework will be defined to support all services.
    • 1.3.4 Market operations should support unidirectional price announcements.
    • 1.3.5 Market operations should support bidirectional bidding.
  • 1.4 Business Context
    • 1.4.1 Legacy pricing models need not be supported by the new interfaces.
    • 1.4.2 Legacy business processes need not flow through new interfaces.
    • 1.4.3 Requirements to continue traditional business processes may be met outside of the new interface.
  • 1.5 Semantic Understanding
    • 1.5.1 Must accommodate wide range of Pricing Models.
    • 1.5.2 All Pricing Models should contain a common set of properties.
    • 1.5.3 Many Pricing Models may be in effect concurrently.
    • 1.5.4 Pricing Models will change over time and must be discoverable.
  • 1.6 Interaction Model.
    • 1.6.1 All intereactions will be messaging based.
      • 1.6.1.1 synchronous request-response pull.
      • 1.6.1.2 asynchronous publish-subscribe push.
    • 1.6.2 Symmetry should be supported at all interfaces.
    • 1.6.3 Best Efforts message delivery shall be supported.
    • 1.6.4 Security and Privacy must be designed into the model.
      • 1.6.4.1 Authentication is often required.
      • 1.6.4.2 Guaranteed message delivery shall be supported.
      • 1.6.4.3 Non-repudiated message delivery shall be supported.
      • 1.6.4.4 Private message delivery shall be supported.
    • 1.6.5 Delegation of message handling shall be supported.

    •