OASIS Energy Interoperation TC

Bill,

Some comments on the proposed charter for an OASIS Energy Market 
Information Exchange TC:

This is vastly improved from the March 30 version.  I think it still 
much too verbose for a
charter, but now the purpose section clearly speaks to price and energy 
product
information.

The scope still overlaps with the EI TC in the two bullets:
- Dynamic price information (EI TC uses the term Dynamic price signals)
and
- Bid information (EI TC - Communication of market participation 
information such as bids)

I presume that the intent is that EI TC will simply use (and possibly 
extend) what the EMIX TC defines
for these things where needed in describing DR (and possibly DER) 
message information.  This
seems to be what you are describing in your email.  Perhaps the 
paragraph at lines 300 - 302 could be
modified to make this slightly more clear.  Something like changing
"Demand Response interactions may be used to deliver Dynamic Price 
information;" to
"Demand Response and other energy use and production interactions may 
make use of Dynamic Price
and Bidding information;"

It would be better to make this more explicit (and not just in your 
email), but I guess this would require
altering the charter for the EI TC.?  This brings up another question.  
Why create two TCs for these efforts? 
Why not use EI for all of this, and create SCs to focus on particular 
areas such as pricing and bidding?

Thanks for a greatly improved charter.

-Evan

Evan K. Wallace
Manufacturing Systems Integration Division
NIST


> Energy Interop TC members --
>
> This is related to the work of our TC. I've also posted this on 
> smartgrid-discuss, b2g, i2g, and to a number of individuals.
>
> The attached charter for the OASIS Energy Market Information Technical 
> Committee is ready for submission to OASIS to formally create the TC 
> after a review period.
>
> If you would like to be added as a supporter, please contact me 
> (wtcox@CoxSoftwareArchitects.com)  and Toby Considine 
> (Toby.Considine@gmail.com) immediately; I'll be sending reconfirmation 
> emails to those on my list in the next 24 hours or so.
>
> This work addresses portions of the price cross cutting issue and 
> priority action plan in the NIST Smart Grid program, though the 
> genesis predates that work. See section 6.2.1 of the Interim Roadmap 
> at 
> http://www.nist.gov/smartgrid/InterimSmartGridRoadmapNISTRestructure.pdf 
> and the Priority Action Plan (a living document) at 
> http://collaborate.nist.gov/twiki-sggrid/bin/view/_SmartGridInterimRoadmap/PAP09DRDER 
> .
>
> Background information from the first draft charter (message at 
> http://lists.oasis-open.org/archives/smartgrid-interest/200903/msg00003.html 
> ). Thanks to the many reviewers; all remaining errors are mine.
>
> This TC is intended to address the prices, market characteristics, and 
> other information for energy trading, buying, and selling. I was 
> inspired to start working on this from discussions in and around the 
> NIST Building-to-Grid and Industry-to-Grid Domain Expert Working 
> Groups, and continued interest from first round reviewers and from 
> people attending GridEcon 2009 in Chicago (http://www.gridecon.com -- 
> slides are available on line at the agenda link).
>
> >From my perspective as an enterprise software architect, this fits 
> into a simple three layer stack with interoperation protocols (*/how/* 
> to communicate) as the fundamental layer. I put the OASIS Energy 
> Interoperation TC/OpenADR work here 
> (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop 
> ), with parts of the message payload in the next layer.
>
> The middle layer is /*what */is communicated -- for markets, things 
> like price, quantity, units, time (of use), and characteristics of the 
> energy sold -- from source (e.g. gas-fired plants, coal, solar, coal 
> plant with scrubbers, wind) to derived information (e.g. carbon data), 
> and also trading information (is this a bid, a price quote, an 
> accepted transaction?).
>
> The goal is to create an XML vocabulary that can be used in a broad 
> range of market exchanges with minimal differences (and where there 
> are differences, arranged in a simple way) for the various consumers 
> of the information.
>
> The third layer is the market design and definition; since markets 
> have varying degrees of complexity I'm leaving this alone for now :-). 
> This is a potentially complex area, and an interesting one. 
> Accordingly, I'd like to carefully define the EMIX work to focus on 
> layer two.
>
> Thanks for your interest.
>
> bill cox
> -- 
> *William Cox*
> Email: wtcox@CoxSoftwareArchitects.com 
> 

Evan

I think what you suspect is exactly right. EnergyInterop is developing a
series of interactions, many of which include something that, depending upon
your viewpoint, looks like either a fully qualified price or like a product
with terms and conditions. All prices/products include an element that is a
schedule/interval. Many of them may also have a schedule element.

EMIX's goal is to make the price/product definition. The current plan (as
far as an unformed committee can have a plan) is that it will use the Web
Services calendar object, promised for completion by year end (by the
Calendar Consortium, CalConnect) as its schedule/interval component. 

Current discussion w/i Energy Interoperation is to use the EMIX object as
its price/product element, freeing up the committee to focus on the
interaction and messages of DR and then DER. (See unapproved minutes)

http://www.oasis-open.org/committees/download.php/33683/EnergyIntropMinutes2
0090805.htm

The TC also anticipates using the CalConnect objects.

tc


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

Toby Considine
TC9, Inc
Chair, OASIS oBIX Technical Committee
OASIS Technical Advisory Board

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.oasis-open.org 
blog: www.NewDaedalus.com





                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Evan Wallace [mailto:ewallace@cme.nist.gov] 
Sent: Thursday, August 06, 2009 3:31 PM
To: William Cox
Cc: energyinterop@lists.oasis-open.org; Toby Considine
Subject: Re: [energyinterop] Energy Market Information Exchange Charter -
supporters wanted; ready for submission to create technical commitee


Bill,

Some comments on the proposed charter for an OASIS Energy Market 
Information Exchange TC:

This is vastly improved from the March 30 version.  I think it still 
much too verbose for a
charter, but now the purpose section clearly speaks to price and energy 
product
information.

The scope still overlaps with the EI TC in the two bullets:
- Dynamic price information (EI TC uses the term Dynamic price signals)
and
- Bid information (EI TC - Communication of market participation 
information such as bids)

I presume that the intent is that EI TC will simply use (and possibly 
extend) what the EMIX TC defines
for these things where needed in describing DR (and possibly DER) 
message information.  This
seems to be what you are describing in your email.  Perhaps the 
paragraph at lines 300 - 302 could be
modified to make this slightly more clear.  Something like changing
"Demand Response interactions may be used to deliver Dynamic Price 
information;" to
"Demand Response and other energy use and production interactions may 
make use of Dynamic Price
and Bidding information;"

It would be better to make this more explicit (and not just in your 
email), but I guess this would require
altering the charter for the EI TC.?  This brings up another question.  
Why create two TCs for these efforts? 
Why not use EI for all of this, and create SCs to focus on particular 
areas such as pricing and bidding?

Thanks for a greatly improved charter.

-Evan

Evan K. Wallace
Manufacturing Systems Integration Division
NIST


> Energy Interop TC members --
>
> This is related to the work of our TC. I've also posted this on 
> smartgrid-discuss, b2g, i2g, and to a number of individuals.
>
> The attached charter for the OASIS Energy Market Information Technical 
> Committee is ready for submission to OASIS to formally create the TC 
> after a review period.
>
> If you would like to be added as a supporter, please contact me 
> (wtcox@CoxSoftwareArchitects.com)  and Toby Considine 
> (Toby.Considine@gmail.com) immediately; I'll be sending reconfirmation 
> emails to those on my list in the next 24 hours or so.
>
> This work addresses portions of the price cross cutting issue and 
> priority action plan in the NIST Smart Grid program, though the 
> genesis predates that work. See section 6.2.1 of the Interim Roadmap 
> at 
> http://www.nist.gov/smartgrid/InterimSmartGridRoadmapNISTRestructure.pdf 
> and the Priority Action Plan (a living document) at 
>
http://collaborate.nist.gov/twiki-sggrid/bin/view/_SmartGridInterimRoadmap/P
AP09DRDER 
> .
>
> Background information from the first draft charter (message at 
>
http://lists.oasis-open.org/archives/smartgrid-interest/200903/msg00003.html

> ). Thanks to the many reviewers; all remaining errors are mine.
>
> This TC is intended to address the prices, market characteristics, and 
> other information for energy trading, buying, and selling. I was 
> inspired to start working on this from discussions in and around the 
> NIST Building-to-Grid and Industry-to-Grid Domain Expert Working 
> Groups, and continued interest from first round reviewers and from 
> people attending GridEcon 2009 in Chicago (http://www.gridecon.com -- 
> slides are available on line at the agenda link).
>
> >From my perspective as an enterprise software architect, this fits 
> into a simple three layer stack with interoperation protocols (*/how/* 
> to communicate) as the fundamental layer. I put the OASIS Energy 
> Interoperation TC/OpenADR work here 
> (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop 
> ), with parts of the message payload in the next layer.
>
> The middle layer is /*what */is communicated -- for markets, things 
> like price, quantity, units, time (of use), and characteristics of the 
> energy sold -- from source (e.g. gas-fired plants, coal, solar, coal 
> plant with scrubbers, wind) to derived information (e.g. carbon data), 
> and also trading information (is this a bid, a price quote, an 
> accepted transaction?).
>
> The goal is to create an XML vocabulary that can be used in a broad 
> range of market exchanges with minimal differences (and where there 
> are differences, arranged in a simple way) for the various consumers 
> of the information.
>
> The third layer is the market design and definition; since markets 
> have varying degrees of complexity I'm leaving this alone for now :-). 
> This is a potentially complex area, and an interesting one. 
> Accordingly, I'd like to carefully define the EMIX work to focus on 
> layer two.
>
> Thanks for your interest.
>
> bill cox
> -- 
> *William Cox*
> Email: wtcox@CoxSoftwareArchitects.com 
> 

  


Evan --


Yes to your comments on scope overlap.  I'll make the changes roughly
as you suggest.


There isn't a real overlap - Price 1.0 is a number in openADR; price 2
is more complex and more useful. Again, the submitted charter should
make it clear.


The charter goes in Thursday, so there's still time if you want to be
listed as a supporter (this is addressed to all).


Thanks!


bill

--

William Cox

Email: wtcox@CoxSoftwareArchitects.com

Web: http://www.CoxSoftwareArchitects.com

+1 862 485 3696 mobile

+1 908 277 3460 fax



Evan Wallace wrote:
4A7B2F5B.10505@cme.nist.gov" type="cite">

Bill,


Some comments on the proposed charter for an OASIS Energy Market
Information Exchange TC:


This is vastly improved from the March 30 version.  I think it still
much too verbose for a

charter, but now the purpose section clearly speaks to price and energy
product

information.


The scope still overlaps with the EI TC in the two bullets:

- Dynamic price information (EI TC uses the term Dynamic price signals)

and

- Bid information (EI TC - Communication of market participation
information such as bids)


I presume that the intent is that EI TC will simply use (and possibly
extend) what the EMIX TC defines

for these things where needed in describing DR (and possibly DER)
message information.  This

seems to be what you are describing in your email.  Perhaps the
paragraph at lines 300 - 302 could be

modified to make this slightly more clear.  Something like changing

"Demand Response interactions may be used to deliver Dynamic Price
information;" to

"Demand Response and other energy use and production interactions may
make use of Dynamic Price

and Bidding information;"


It would be better to make this more explicit (and not just in your
email), but I guess this would require

altering the charter for the EI TC.?  This brings up another question. 
Why create two TCs for these efforts? Why not use EI for all of this,
and create SCs to focus on particular areas such as pricing and
bidding?


Thanks for a greatly improved charter.


-Evan


Evan K. Wallace

Manufacturing Systems Integration Division

NIST



  
Energy Interop TC members --


This is related to the work of our TC. I've also posted this on
smartgrid-discuss, b2g, i2g, and to a number of individuals.


The attached charter for the OASIS Energy Market Information Technical
Committee is ready for submission to OASIS to formally create the TC
after a review period.


If you would like to be added as a supporter, please contact me
(wtcox@CoxSoftwareArchitects.com)  and Toby Considine
(Toby.Considine@gmail.com) immediately; I'll be sending reconfirmation
emails to those on my list in the next 24 hours or so.


This work addresses portions of the price cross cutting issue and
priority action plan in the NIST Smart Grid program, though the genesis
predates that work. See section 6.2.1 of the Interim Roadmap at
http://www.nist.gov/smartgrid/InterimSmartGridRoadmapNISTRestructure.pdf
and the Priority Action Plan (a living document) at
http://collaborate.nist.gov/twiki-sggrid/bin/view/_SmartGridInterimRoadmap/PAP09DRDER
.


Background information from the first draft charter (message at
http://lists.oasis-open.org/archives/smartgrid-interest/200903/msg00003.html
). Thanks to the many reviewers; all remaining errors are mine.


This TC is intended to address the prices, market characteristics, and
other information for energy trading, buying, and selling. I was
inspired to start working on this from discussions in and around the
NIST Building-to-Grid and Industry-to-Grid Domain Expert Working
Groups, and continued interest from first round reviewers and from
people attending GridEcon 2009 in Chicago (http://www.gridecon.com --
slides are available on line at the agenda link).


>From my perspective as an enterprise software architect, this fits
into a simple three layer stack with interoperation protocols (*/how/*
to communicate) as the fundamental layer. I put the OASIS Energy
Interoperation TC/OpenADR work here
(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop
), with parts of the message payload in the next layer.


The middle layer is /*what */is communicated -- for markets, things
like price, quantity, units, time (of use), and characteristics of the
energy sold -- from source (e.g. gas-fired plants, coal, solar, coal
plant with scrubbers, wind) to derived information (e.g. carbon data),
and also trading information (is this a bid, a price quote, an accepted
transaction?).


The goal is to create an XML vocabulary that can be used in a broad
range of market exchanges with minimal differences (and where there are
differences, arranged in a simple way) for the various consumers of the
information.


The third layer is the market design and definition; since markets have
varying degrees of complexity I'm leaving this alone for now :-). This
is a potentially complex area, and an interesting one. Accordingly, I'd
like to carefully define the EMIX work to focus on layer two.


Thanks for your interest.


bill cox

-- 

*William Cox*

Email: wtcox@CoxSoftwareArchitects.com
<mailto:wtcox@CoxSoftwareArchitects.com>

Web: http://www.CoxSoftwareArchitects.com

+1 862 485 3696 mobile

+1 908 277 3460 fax