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
http://www.oasis-open.org
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!
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.
"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.
- 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.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.
- 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: 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
|