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
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.
-------- 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…
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
Chair, OASIS oBIX
TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
|
|
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
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!
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.
"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
Chair, OASIS oBIX
TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
|
|
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!).
-------- 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
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.
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.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.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.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 |