OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

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


Subject: RE: About example in EMIX doc


We do not know how these elements will be used, nor do we want to constrain future business models.

 

Clearly, in a top-down, full control model, I can specify everything entirely within a sequence of intervals; in such a case, the gluon only serves as a collector of redundant information. For this interaction, the gluon is merely a way to improve the efficiency of expression.

 

In other business models, the invoker may be sending only a link to the existing offer. In the example, the plant has an internal sequence of operations. That sequence may be invariant, and can be offered to the market any number of times. Gluon one is one such offer, and establishes a unique handle for reaching into that sequence.

 

In the example, imagine that this is an industrial site that only occasionally comes to market with its generation resource. On this particular day, say during the quarterly plant shutdown, the plant operators look at their current fuel costs and indicate that they would be willing to run the generation of their particular price is met. Gluon 2, then, happens to be a particular price offer available for one day only. There may be other aspects of that particular offer of a resource, such as minimum run time acceptable, minimum dollars, et al.

 

Gluon 3, then is a scheduling notification from the market. It merely accepts the offer in gluon 2 (by referencing the uri of gluon 2) at the price specified in gluon2 , and specifies a run time only.

 

Not that this does not specify a market rule or a required interaction. Energy markets are free fully re-specify the entire sequence if they want. This example merely demonstrates the expressiveness and capability.

 

BTW, it is noteworthy that in many ISO markets, something very much like gluon 3 is the scheduling communication today. Generation bids express capabilities, lead times, etc, and the scheduling entity invokes those schedules with a run time and size.

 

Note, too, that in the service world, in which internal  processes are properly hidden, The resource may choose not to reveal interval A or interval C: they can be hidden in lead times expressed in the resource advertising.

 

The key thing is to think of service advertisement and invocation, rather than of process integration.

 

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: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: Marty Burns [mailto:burnsmarty@aol.com]
Sent: Saturday, January 08, 2011 11:01 AM
To: toby.considine@gmail.com
Cc: wtcox@coxsoftwarearchitects.com; 'Aaron Snyder'
Subject: About example in EMIX doc

 

Toby,

 

I have been studying and reading emix-1-0-spec-cd-01.doc. I was wondering about the following example figure 4-1:

 

 

Why do you use 3 sequential gluons here rather than one to define the inheritable components? Second, is there a significance to the order of schedule/offer/power product gluons or are they essentially a set of somewhat orthogonal concepts that precede the sequence of intervals?

 

Thanks,

Marty



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