[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] RE: EMIX Product and Time - Answers and Suggestions needed
This might explain my JIRA comment about
what actually defines the Product in the transaction. It looks like the Product
Description is the identifier? Below are some of the definitions used in
the NAESB PAP03/04/09 Master Data List regarding product:
I definitely do not like banana. Bruce
Bartell Xtensible Solutions From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine 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
From: Toby Considine
[mailto:Toby.Considine@gmail.com] 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
From: Ed Cazalet [mailto:ed@cazalet.com] See
attached. Edward
G. Cazalet, Ph.D. 650-949-5274 cell:
408-621-2772 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]