[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-discuss] Pricing from the NIST TWIKI
Messaging standards such as JMS provide different qualities of service,
QoS, to meet different business requirements. Both "best effort" and
"guaranteed" have their place depending upon the situation, for example:
Guaranteed in situations where messages have significant legal
implications and services such as non-repudiation (mentioned below) are
appropriate.
Best effort in advisory type messages.
Larry
-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com]
Sent: Tuesday, December 30, 2008 11:23 AM
To: Toby Considine
Cc: smartgrid-discuss@lists.oasis-open.org
Subject: Re: [smartgrid-discuss] Pricing from the NIST TWIKI
Two comments and one suggestion:
1) 1.6.3 says "Best Efforts message delivery shall be supported",
while 1.6.4.2 says "Guaranteed message delivery shall be supported".
These are contradictory requirements; only one should be specified.
2) Was "Privacy" (1.6.4) and "Private" (in 1.6.4.4) meant to mean
"Confidentiality" and "Confidential"? Privacy implies policies
related to individuals' rights, whereas confidentiality is more
prosaic and, perhaps, more appropriate for business communications?
3) While it might seem unnecessary, it might be useful to consider
pricing power in a "universal currency" rather than in country-
specific monetary specifications. This is analogous to the "UTC"
(Coordinated Universal Time) notation used by all computers to
depict events in a single, internationally-understood measure of
time. UTC retains the same value anywhere on the globe, but can
be "translated" into local time by just adding/subtracting the
time-difference between the UTC zone and the calculating zone.
While power is not sold across continents (today - to the best of
my knowledge), data does travel across continents. To simplify
pricing and economic models, it might be useful to create a
"Universal Power Currency" (or "Universal Currency for Power" - to
avoid confusion with the abbreviation for Universal Product Code)
that will have the same value worldwide, but can be "translated"
by multiplying the "UPC/UCP" with the appropriate exchange rate
in the nation.
The advantage is that all nations can use the same currency unit
for measuring the cost of power (making it easier on software
developers and markets), while only the localized portion of the
display needs to convert the universal currency to local currency.
Have a great new year.
Arshad Noor
StrongAuth, Inc.
Toby Considine 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 <mailto:Toby.Considine@gmail.com>
> TC9, Inc
> Phone: (919)619-2104
> blog: www.NewDaedalus.com <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]