|
David has a point which I think is valid -- inducing
the consumers to cooperate with the electric retailers assumes an active
response and interaction not seen today within homes or commercial buidlings.
While there are changes being implemented that allow for smart appliances, it'll
be a while before the world's supply of "nonintelligent" appliances is
exhausted. Defining future protocols and business models for pricing can be
difficult with technology and social changes playing havoc on attempts to
standardize systems. Additionally, the push to divorce cost of kWh from the
current system (electricity without
price control paradigm @ energypulse ) which
results in utilities being less inclined to make changes price-wise will add to
the mix of issues. Future consumers may choose among electric
retailers for the best price options on the market and therefore make many
schemes being now implemented and decided completely obsolete. Automated
systems AMI/HAN technologies may also make some of the argument that pricing
should be based on anything but TOU a mute point since these systems would
be interactive with the pricing markets. Net Zero solutions also can have an
impact on pricing schemes even though today that is not the case with regulated
pricing.
Bill
Melendez, CTO
HEMS
Technology
Cell:
817-932-0047
www.hemstech.com
This message (including any attachments) contains
confidential information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should delete this
message. Any disclosure, copying, or distribution of this message, or the taking
of any action based on it, is strictly
prohibited.
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
|