RE: [smartgrid-discuss] Pricing from the NIST TWIKI

["David RR Webber \(XML\)" <david@drrw.info>]

Just coming to this discuss.  Phew - lesson learned from UBL is that this needs to be SEPARATE from the on-the-wire exchanges.  UBL has created mega schema bloat trying to cram all the pricing, tax, et al into the exchanges. Logically from the modelling perspective this does NOT make sense.

 

Each consumer has their own contracts which determine payments and billing.  All the transactions need to do is express the quantity of power used in neutral units consumed.  Then backend billing systems can sort out the costing by applying time-of-day, contract and currency details.

 

This BTW is how telephone switches work too (not that I'm offering that as a perfect model - but I did once write a complete telephone billing system that read call logs off 16" magnetic tapes - those were the days!).

 

Thanks, DW

 

 

-------- Original Message --------
Subject: Re: [smartgrid-discuss] Pricing from the NIST TWIKI
From: "Michaela Barnes" <michaela.barnes@gmail.com>
Date: Tue, December 30, 2008 3:12 pm
To: "Toby Considine" <Toby.Considine@gmail.com>
Cc: smartgrid-discuss@lists.oasis-open.org

This list is silent on language, alphabet or currency of the messages and pricing. Was that intentional (as in that's handled elsewhere in the process)? Or, should there be a requirement that any framework should not assume only English, Latin characters, and US dollars?

Michaela Barnes

On Tue, Dec 30, 2008 at 5:59 AM, Toby Considine <Toby.Considine@gmail.com> wrote:

Marty Burns, Bill COx, and I put this together on the NIST TWIKI a week ago. Is this sufficient to begin discussing what a smartgrid price service looks like?

===================================
Pricing

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.

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.

________________________________________
"When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us." -- Alexander Graham Bell
________________________________________
Toby Considine
Chair, OASIS oBIX TC http://www.oasis-open.org
Co-Chair, OASIS Technical Advisory Board
Toby.Considine@gmail.com
TC9, Inc
Phone: (919)619-2104
blog: www.NewDaedalus.com