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

 


Help: OASIS Mailing Lists Help | MarkMail Help

smartgrid-discuss message

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


Subject: Re: [smartgrid-discuss] Pricing from the NIST TWIKI


This is an excellent model to start with.  Take this, and also take into account the comments about the likelihood of significant change in the pricing and business models, too.  We have a profound chicken and egg dilemma here: the need for different pricing models, in deed, new business models, is clear, as is the need for significant regulatory change, and ultimately usage pattern changes. This means many different things to different people, but when considering all the technological ways we might achieve these changes, we see the need for exchanging information between a lot of different elements built by different people. That can't happen without standardized protocols (using the broad meaning of "standardized", i.e. all participants using some common protocols). So we need to define some communication standards so as to enable new technology development, new pricing models, and new everything else.  Which comes first? Sounds impossible to solve with a traditional top down approach - we can't define "how" until we fully understand "what".  Well, again, software and protocol people should be pretty used to this "y'all start working on it, while I go figure out what the heck they want us to do" paradox.

We're used to this in the wireless world.  What we think are key applications are usually eclipsed by something very different: the "killer app" that has driven (or is driving) wide spread adoption is almost never what we thought when the standard was created.   This has allowed innovative applications to create entirely new markets, and transform existing markets. Likewise new biz models emerge, and established models adapt, and pretty soon we can't tell what is which (is eBay a new biz model, an evolution of an old one, or what? Does it matter which?).
 
The consumer electronics biz has adapted to the "if we build it...some folks somewhere will figure out good stuff to do with it" model for technology development. It has become an evolutionary test: adapt to unforeseen new markets or die off. The "caveat emptor" nature of consumer electronics has a lot to do with it - limited regulation, brutally competitive pricing factors, little or now consumer dependence on particular vendors (thanks to standards ;-), and the fact no one dies when their personal media player doesn't work right. 
 
It is my opinion that smart-grid technologies will be a key enabler of new models for both delivery and consumption. I expect changes in nearly every aspect of the grid. In my view, the key decisions will be made locally, by an energy management entity ultimately under the control of the consumer.  As noted, adoption of new technology must be incremental, but with a very steep positive value to investment curve - front loaded with immediate pay-back AND long term economic benefit to the consumer. And price points are critical: it can't JUST make sense long term, it has to be within reach today. 
 
Everything else we think we know about the technology and consumer habits is up for grabs.  I envision technology enabling solutions to the problems that today prevent consumer control of acquisition of power as well as consumption. Current thinking is that all we masses can control is when we use power and how much: that is a single dimensional view in an no-dimensional universe. Sure, today local generation is rare and economically unfeasible for most consumers, but that's a problem that technology developers (and their sales and marketing teams ;-) are already working to change. There are a LOT more possibilities than what you have seen on Discovery channel ;-). 
 
Gee, it sounds like a simple challenge: we need information exchange standards to enable new business models, which we can't yet predict, and which can be adapted and extended to evolve with the markets. 

Shucks, if it was easy, what would be the fun?
 
-Ben
================================
Benjamin A. Rolfe
Principle Technologist, Blind Creek Associates
Strategic Technology Consulting
Skype: benjamin.rolfe
----- Original Message -----
Sent: Wednesday, December 31, 2008 11:18 AM
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI

 

Electricity systems will be most efficient if consumers, and their appliances, can be induced to consume when there is available generation. An electricity retailer is at the front line for achieving this, as they will be aware of their contracts and or the plant available to them, and will also be aware of forecasts of what will be available from ambient sources. As “real time” approaches their knowledge will increase, and they will wish to influence their customers to fine tune their balance.

Like a supermarket, they can influence consumption by setting the prices. Supermarkets have the luxury of having storage, so do not face the need to keep the balance right at all times. Low cost airlines face a more difficult problem, as they sell their product, the seat, or they lose the revenue from it. If they oversell, then, when it is time to fly, there is grief. For electricity retailers there is only one product, electricity, and the variable is the price at different times in the future. In effect, each period ahead is a different product, and so should have the potential for a different price. Overselling results in somebody (and potentially everybody) losing out in a blackout.

So the question is, how short should be that period? In electricity, I think it should be about 10 seconds. That is the timescale in which circumstances in an electricity grid can change dramatically. If a line breaks, or a generator trips, then the price should start changing very quickly. And soon.

Most of the time, of course, the prices difference between adjacent periods will be small, so there is a gradual transition between price levels. This serves to ensure that there are no sudden tariff breaks, which might serve to encourage sudden changes in load – a great nuisance to electricity grids.

The need to have future prices is to allow devices, such as dishwashers and laundry machines, and battery cars, to plan their consumption, and reveal to their owners how much it is going to cost if they are to need deadline chosen by their users. In running a programme, most appliances have critical activities that it is not sensible to interrupt – it may even be dangerous. This is a problem if they have access only to current prices, but is easy if they are able to see expected future prices. Like generators, they are most efficient if they can run to a schedule.

Of course, these plans can be sent awry by sudden changes in prices, but this is a hazard of operating in the real world. Things happen, and appliances can do little about it. However, they may be able to hedge this risk financially, by doing a deal with their retailer at the expected fixed price. To do this, they will no doubt pay a premium, but will also have to share their expected consumption plan for all the periods ahead. Undoubtedly, this will consume most at times when prices are lowest. They have done a fixed price deal, and so can, in principle, sell their low cost electricity (ie not consume) if the price gets very high. The electricity retailer accepts the risk (for the premium), but is presumably in a much better position to do something about it than an appliance or user.

I think this means that the future price is best expressed as a continuous curve, encoded in some way that allows agreed interpolation between points. It would often be convenient for the curve to have repeating elements, such as daily or weekly, so that it can be extrapolated into the future (and a sensible price can be assumed even if communications break down). There are many ways of doing this, and many systems for interpolation between points that are defined as numbers.

To whom should this price curve be communicated? There are two key answers: to the meter, as this will then be able to do the calculation of consumption in a (short period) times the cost in that period, and so accumulate the consumption element of the invoice. So it is not (just) electricity consumption that is measured, but the total cost – making it a flowcost meter.

The other device that needs to receive the price is appliances, as this allows them to optimise their (perhaps complex) consumption programme. If the price curve changes, they can reoptimise.

If there is to be a fixed price deal, the appliance needs to communicate its consumption plan to the meter. Again, this can be expressed as a curve, but the need for smooth transitions is much less, (and the transitions will often be abrupt anyway) so it can be expressed more simply.

There is no need for the consumption, or the consumption plan, to be communicated back to the retailer. Supermarkets are pretty good as adjusting their product flow without us declaring how many of what things we will buy each trip. Electricity retailers will also be able to use empirical experience to assess what impact a change of price will have on overall consumption, and will not really be able to make much good use of the individual consumption plans sent to them. They will generally have a pretty good indication of what is happening from the gross consumption from meters higher up the electricity network.

This capacity to communicate prices is a critical feature of any metering standard, and also vital from communication between the meter and an appliance. But it is a broadcast signal, not needing 2 way communication. If this is done, it can subsume all sorts of other “derivative” products, like CPP, or TOU, or interruptible tariffs.

But it is a pricing signal, even if it used also by the meter for accounting.

Regards

David

 


From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 31 December 2008 15:26
To: Considine,Toby (Campus Services IT)
Cc: smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI

 

Toby,

 

Solid thoughts.  How about Accounting instead of Pricing?

 

We instinct is to not sweat the billing / fulfillment / delivery stuff - there is so much out there already in that space - we just need to pick something to do that with.  Plenty of choices - UBL, OAGi BODs, EDIFACT, X12, Quicken - and in fact maybe the smart choice is just to provide some guidelines in that area - no need to reinvent this Accounting - instead point to tools people can do that with.

 

What I would say we do need to cover is Contract Agreements.  There really are not good solid mechanisms out there to support Accounting in a robust way.  So much is back in the paper world logic of "I must send everything (again)".  What you really need is lightweight accounting keyed off the Contract.  That way participants establish their contracts (either unilateral or bilateral) - and simply refer to those in the supply/delivery mode.  The accounting can then pick up the terms from the contract and compute billing / credits easily.

 

Focusing on what the contract needs to state specifically to enable grid distribution is then the "plug" that all participants can attach to.  Fulfill those contract requirements in how your system attaches to the grid and you can play.  The accounting simply looks up from the contract the terms, conditions, rates, billing, credits, QOS, et al.

 

Thanks, DW

 

 

-------- Original Message --------
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI
From: "Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>
Date: Wed, December 31, 2008 7:48 am
To: "smartgrid-discuss@lists.oasis-open.org"
<smartgrid-discuss@lists.oasis-open.org>

Perhaps the point that needs to be explicit is this is the Pricing service.

 

Pricing is not the transactional service. We have described the need for a transactional service, the two-way flow meter of what did you use or produce and when. With fungible electrons, *that* service is, as you describe a “count and bill me later “ service.

 

Pricing is the decision support. If I choose to use the grid exactly as I do now, O could opt to never check the price. “Just Bill me” – gets the results from the transactional system.

 

I think you have started a useful fork, what is the transactional system. It needs to be small and tight, to fit in the same space as the current system. It needs to support Time of Day two-way flows (or parallel systems side by side). Does it need to include QOS information? (I am selling you noisy power right now?) I can talk myself into either way…

 

So, we seem to have a

 

1)     Schedule service, a part of the forward sales landscape, including DR

2)     Pricing Service, a way to describe what it is that is being offered or bought. (Do I want coffee this morning or fair trade shade tree coffee this morning?) Perhaps the term Pricing is a poor choice. Propose another name?

3)     Security Profiles, a description of the decoration we want to use for the communications (that discussion broke out yesterday).

 

Others remain to be discovered.

 

There will, alas, be some components of T&D, in some circumstances, but even those should be small and tight.

 

 

 

 

 


"A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift


Toby Considine

Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

blog: www.NewDaedalus.com

 

 

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Wednesday, December 31, 2008 12:23 AM
To: Considine, Toby (Campus Services IT)
Cc: smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI

 

Toby,

 

Yes - that's what all those PIPE XML transactions did (still looking for those spec's BTW).  Well except for the carbon credits!

 

But the general principle still holds.  You don't mix your bidding, credit, contract and supply information along with your transmission control mechanisms - well not unless you want chaos and mega schemas.

 

Separating what is needed to support an eMarketplace ecosystem - that model is pretty well known - from transmission and distribution control. 

 

Small focused information exchange transaction packets that are context and role based - now that's what I like to see!

 

Thanks, DW

p.s. Has any thought about modulating the electricity with an overlaid signal that conveys some of this? Probably answer is yes to that - but how to isolate it is another whole grab bag - I guess we need to stick to the XML and avoid too much on the infrastructure side...

 

 

-------- Original Message --------
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI
From: "Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>
Date: Tue, December 30, 2008 11:35 pm
To: "'David RR Webber (XML)'" <david@drrw.info>
Cc: "smartgrid-discuss@lists.oasis-open.org"
<smartgrid-discuss@lists.oasis-open.org>

True, as long as no one ever makes any bidding decisions and all power is the problem of the power company and there is no symmetric pricing deals and power quality never matters when deciding to use internal sources or power off the grid and no one will ever make a purchase pricing decision based upon their need for carbon credits and the price won’t change based upon the time of day (remember, these are sometimes forward pricing decisions) and there is no need to clear markets because if we run out of power we’ll just brown out everyone in the area  and the day ahead wholesale markets never go negative and no one has any options as to how or where to buy their power…

 

Oh wait. That’s what we have already.

 

tc


"A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift


Toby Considine

Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

blog: www.NewDaedalus.com

 

 

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, December 30, 2008 10:58 PM
To: Michaela Barnes
Cc: smartgrid-discuss@lists.oasis-open.org; Toby Considine
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI

 

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.

o     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.

o     1.2.2.1 Price adjustments can be made in time in up near real time manner.

o     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.

o     1.2.3.1 Power Consumption.

o     1.2.3.2 Peak Availability.

o     1.2.3.3 Relinquishment of prior right (Differential Behavior vs Absolute Consumption).

o     1.2.3.4 Power Quality.

o     1.2.3.5 Carbon Offsets.

o     1.2.3.6 Transmission and Congestion.

·      1.2.4 Pricing should support the decommoditization of power.

o     1.2.4.1 Wind, Distance, Carbon, Triple Bottom Line, and other attributes.

·      1.2.5 Pricing should be time sensitive.

o     1.2.5.1 Time offer made.

o     1.2.5.2 Window for offer.

o     1.2.5.3 Time of acceptance.

o     1.2.5.4 Scheduled Time of consumption.

o     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.

o     1.6.1.1 synchronous request-response pull.

o     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.

o     1.6.4.1 Authentication is often required.

o     1.6.4.2 Guaranteed message delivery shall be supported.

o     1.6.4.3 Non-repudiated message delivery shall be supported.

o     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:
http://www.newdaedalus.com/

 

--------------------------------------------------------------------- To unsubscribe, e-mail: smartgrid-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: smartgrid-discuss-help@lists.oasis-open.org

--------------------------------------------------------------------- To unsubscribe, e-mail: smartgrid-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: smartgrid-discuss-help@lists.oasis-open.org


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