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

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.
    • 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: 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

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