Next in thread → Next in month →

RE: EMIX Product and Time - Answers and Suggestions needed

From
Sean Crimmins <>
Date
2010-11-11T01:27:00+00:00
ID
Thread
RE: EMIX Product and Time - Answers and Suggestions needed
I’m not entirely sure I’m
following you, but I’ll try anyway.  We have a product that is independent
of time or location, e.g. Energy.  When we incorporate time and location
we could be talking about a tender, a schedule or an award.  Simply adding
a time (sequence) doesn’t make it anything.



Sean







From: Toby Considine
[mailto:] On Behalf Of Toby Considine

Sent: Wednesday, November 10, 2010 1:52 PM

To: 

Subject: [emix] RE: EMIX Product and Time - Answers and Suggestions
needed







I just had a long conversation with Ed on some of his issues
and concerns. One set of them centers on the use of the word Product throughout
the specification. As it is now, There is a Product Description and a Product.
A product is defined as a Description applied to a [WS-Calendar] Sequence. Ed
feels this is confusing, and he convince me that it is as well. Let’s
call it a Banana.



Let’s say that we have a Product Description and a
Banana. A banana is a Product Description applied to a Sequence. The Banana may
be used to in a Tender. A Banana may be proffered as a resource into a bid. A
Banana may be schedule for Generation. A Banana may be a report of Energy Usage
coming back from a metering point. Calling all those Bananas
“Product” causes confusion.



A Banana may be a single interval of time, with the Product
Description, Duration, Price, and Quantity fully specified. A Banana may be a
load shape over a series of intervals, sharing a Product Description, and a
common Duration, although the Quantity varies for each Interval. A Banana may
be a representation of an hourly pricing tariff, sharing a Product Description,
and a common Duration (hour), with a Price that varies for each Interval; no
quantity is specified.



This comes to the question: What do we call a Banana? Only
sometimes is it what we normally call a Product.



Ed suggested that we call it a Packaged Product (or
productPackage). We also decided to throw it before the TC.



A Product Description applied to a Sequence is called
a:_____________



tc























"If something is not worth
doing, it`s not worth doing well" - Peter Drucker












































 
  
  Toby Considine

  TC9, Inc
  TC Chair: oBIX &
  WS-Calendar
  TC Editor: EMIX, EnergyInterop
  U.S. National Inst. of
  Standards and Tech. Smart Grid Architecture Committee
  
  
    
  
  
  Email: 

  Phone: (919)619-2104
  http://www.tcnine.com/

  blog: www.NewDaedalus.com
  
 












From: Toby Considine
[mailto:]

Sent: Wednesday, November 10, 2010 2:41 PM

To: 

Subject: FW: EMIX Product and Time







Excellent question, Ed.



The real question, underneath,
has to do with ramps, and perhaps with my understanding of them (which is
getting better, now).



I had a concept of a ramp
interval, i.e., an interval during which power varied but all other aspects
were constant. This required me to have an interval with a (Begin power / end
power) as opposed to a “normal” interval which had a single power.
As at that time, all quantities were in the interval, and this was external to
the product (resources had not really come together then), I needed another way
to handle it.



What I did at the time was
sub-class the EMIX interval, itself an instance of a WS-Calendar Interval, into
an interval that was either constant or ramp power. This sub-class, then, with
a choice if ramp or constant, can exist anywhere a an EMIX interval does, which
includes as any member of an EMIX Sequence. 



So, it is not really an
additional interval, but a redefinition for use in Power.



The CIM handles this by having
“steps” of constant power instead. It then deals with the predicted
variance between actual power and stepped power by having a market rule
requiring the resource to “make good” on the difference with spot
purchases.



I was concerned that such tacit
“everyone knows how this works” assumptions break down as we move
into common definitions for generation resources, distributed resources, and
distributed generation. A key goal is to make all the tacit assumptions
explicit in the interfaces, a goal as strong as that of hiding unnecessary
technical detail.



The use of ramp rates in
Resources has perhaps reduced the need for such intervals, meaning perhaps we
can fall back to the un-elaborated, un-redefined bare emix sequence. If not, as
your question indicates, then the Power Sequence warrants a couple paragraphs,
perhaps in Chapter 5, as it is an underpinning structure throughout the other Power-based
interfaces.



As always, we need to support
the present and the future, rather than perfect the past. A good quick
discussion?



Sean? Donna? Bruce? Phil? Ruchi?
Brian? Bill  S? Each of you has chimed in on aspects of this subject.



tc

























"If something is not worth
doing, it`s not worth doing well" - Peter Drucker




















































 
  
  Toby Considine

  TC9, Inc
  TC Chair: oBIX &
  WS-Calendar
  TC Editor: EMIX, EnergyInterop
  U.S. National Inst. of
  Standards and Tech. Smart Grid Architecture Committee
  
  
    
  
  
  Email: 

  Phone: (919)619-2104
  http://www.tcnine.com/

  blog: www.NewDaedalus.com
  
 












From: Ed Cazalet
[mailto:]

Sent: Tuesday, November 09, 2010 11:45 PM

To: 'William Cox'; 

Subject: EMIX Product and Time







See attached.



Edward G. Cazalet, Ph.D.

101 First Street, Suite 552

Los Altos, CA 94022

650-949-5274

cell: 408-621-2772



www.cazalet.com














*********************************************************************************************
The foregoing electronic message, together with any attachments thereto, is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee(s) and access to the message by anyone else is unauthorized. If you are not the intended recipient of this electronic message, you are hereby notified that any dissemination, distribution, or any action taken or omitted to be taken in reliance on it is strictly prohibited and may be unlawful. If you have received this electronic message in error, please delete and immediately notify the sender of this error.
*********************************************************************************************
Next in thread → Next in month →