[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [energyinterop] Thinking about Constraints and Market Context
Someone told me that this email did not go
through to the list so I’m sending it again. From: Koch, Edward All, I won’t be able to attend the conference
call on the constraints issue today, but that is probably OK from my
perspective. I actually don’t feel a burning desire to get into the
details. Since I spoke up on this topic in the EI meeting yesterday let
me just take a few moments to state my personal position on this topic. From a technical/structural point of
view I really don’t care if the schemas for constraints are defined in EMIX or
EI, BUT that being said from a process and procedural point of view I “might”.
We in EI have requirements for constraints. The folks in EMIX have told us they
will define constraints in their schemas that we can use. I’m not involved in
EMIX, nor do I want to be, so to that I reply fine - here’s what we need in EI
and let me see what you produce and hopefully we can use it. Where I
start to object is whenever the topic of constraints comes up in EI there is a
knee jerk reaction that whatever we are going to do with constraints in EI
somehow MUST come from EMIX and if what we need in EI is not covered then we
MUST go over to EMIX and fix their spec. It’s hard for me not to question that
position when I start hearing dissention among the EMIX people on the topic of
constraints within their spec. It naturally raises the questions of whether EI
should be relying on EMIX to define constraints. My recommendation is simple. The EMIX
folks should get their act together on this topic so the EI folks can review
what they produce and judge its usefulness. Furthermore if their specs are
lacking in some respect the EI folks should be free to derive extensions to them
to suit their needs without having to wade into EMIX and insist they change
their spec accordingly. Thanks, -ed Koch From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine Sent
to EMIX as well. I
think that I created considerable confusion by falling into a specification
honeypot, seizing on semantics from EI, applying them to EMIX, and causing
confusion to both groups. Thanks to Rish and Ed C, who spent considerable time
straightening me out yesterday. What
follows is a narrative of my confusion. If you want to cut to the chase, skip
down to the heading “PROPOSAL:” At
the beginning of the year, we had twice as many schemas in EMIX as now, and the
relationships between them were muddy, or “not properly normalized”. In
particular, the information types in power and resource were repetitive, overly
particular, and not evolvable. I returned to the CIM market interfaces, and
reviewed carefully the non-control and non-technology market characteristics of
bids offered into the generation market. I used the generation market because
it included the most expansive elaborations in the CIM. These information
elements had some common issues that varied from market to market. Notification
time is the poster child for this. Every market has some sort of required time
which the seller requires after notification to be able to deliver, and every
market as some sort of required time within which the seller must deliver to be
acceptable. In
January, Anne Hendry pointed me to the NIEM guidelines for extensibility and
evolvability, and I began rather mechanically sub-typing across all the
schemas. One schema led to another, and then the next and soon I was wondering
what to call those market requirements or market characteristics or performance
expectations. At the end of January, we were running through service
definitions at a high level in Energy Interoperation, relying primarily, IIRC,
OpenADR 1.0 and the IRC contributions. A critical term appearing in those schema-fee
services was the word constraints. This was when I drove into the ditch. In a
somewhat schizophrenic manner, I called everything in the emix-requirements.xsd
“constraints”. This has caused trouble ever since. Let’s call them kumquats for
now instead. These
things are properly part of product definition. 4 second responsive power gets
sold at considerably higher prices than does 20 minute responsive power. Some
power can be sold for long times, and other products must stop and recharge
after only brief use. These are characteristics of the product, or of the
service offered. They are identical for generation or DR resources. Most of
them are the same for power products as they are for natural gas, high pressure
steam, low pressure steam, chilled water, or … Here
I point out that the EMIX TC has created 3 schemas. EMIX describes the basic
market information needed to describe any product in which there is a tight
link between production and delivery, and between value and time of delivery.
This characterizes many energy markets, not just the electrical power market.
This purpose is explicitly called out in the TC charter. Kumquats properly
belong in EMIX not in POWER. The
Charter also calls out the explicit needs of the Electrical Power Market. The
Power Schema extends base types defined in the EMIX schema and adds information
specific to Power. For the first time Real Power and Real Energy are introduced
to the semantic model. If a product is tendered with a maximum duration of 10
minutes, that kumquat is defined in the emix-requirements portion of the
emix-schema. If the same produce has a maximum real-power, that cannot be
described within EMIX without creating a loop referring up to POWER for the
definition. Instead, power-specific kumquats are defined inside the power
resources schema as an extension of the base kumquat class. This dual location
is appropriate if we mean to keep the severability of schemas, necessary for
evolution and re-use, but has confused a few. At
the same time, my appropriation of the word constraints for the kumquats left
out a critical elements of the OpenADR constraints. In OpenADR 1.0, no
constraint is complete until the Constraint Behavior is defined. The meant that
I was presenting again and again something called constraints that did not meet
the larger requirements of Constraints as defined in OpenADR. PROPOSAL For
EMIX The
base-type formerly-known-as-baseConstraint (the kumquat) should be renamed
marketRequirement or marketExpectation or something similar. The names of each
instance of a [kumquat] should be reviewed to remove confining references to
particular markets, i.e., maximumResponseDuration, that create false
dichotomies between DR, Generation, and DER. For
EI YAC’s
(yet another citrus) are published describing how to apply a [kumquat] within a
market context. Maybe the YAC is still a constraint, maybe it’s a marketRule.
When the smart toaster gets brought home from the store, it queries the VEN to
find a Market Context and gets the YACs. Once it knows the YACs, the Toaster
can determine whether to offer its capabilities into the market, and how to
configure its user interface. That decision, and that interface, are, of
course, left to the markets to determine. A
YAC consists of: ·
A kumquat ·
A Constraint Behavior ·
A kumquat processing rule. This is
cruder than the ConstraintBehaviors. It includes such directives a as
“MustUnderstand”, “MustIgnore” YACs
describe the expectations for both sides. OpenADR,
then defines a very specific set of kumquats that it respects. TEMIX limits
itself to a very small set of kumquats (MinimumNotificationDuration?) that it
respects. The Toaster can plug in, query the market context, and adjust its
communication style to OpenADR 2.0, TEMIX, or other markets not yet named. A
future market could create a new market [kumquat] within EI or even in a
private schema, and publish a YAC “mustUnderstand”, and be ready to go. One
aspect that got brought into all Tenders in EMIX was a side, “BUY” or “SELL”.
These become critical to understanding YACs and kumquats. When a SELL publishes
a MinimumNotificationDuration of 5 minutes, it means “5 minutes or greater”.
When a BUY publishes a MinimumNotificationDuration of 5 minutes, it means “5
minutes or less”. I think YACs are always published from the perspective of the
“BUY”, but that could be an interesting set of discussions. tc “The
single biggest problem in communication is the illusion that it has taken
place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]