I thought this conversation, below, from the smart grid
discussion list, is in good dialog with Brian’s note from this morning…
I am delighted the 6LOPAN and Zigbee issues ar4e coming to the
"A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
From: William Cox
Sent: Tuesday, March 31, 2009 12:08 PM
Cc: email@example.com; 'Toby Considine'
Subject: Re: [smartgrid-interest] Draft Charter - Energy Market
Good point for discussion.
My view is that the key interactions are the home/business/internet side, and
that for bandwidth-limited devices/networks the important thing is to have a
consistent information model of what is exchanged, whether it's the messages
(which may or may not have additional content) or more information.
So if the information model as expressed in the XML is consistent with
smaller/slower connections, the information can be communicated and acted on in
a consistent way across homes, buildings (in general, suggesting non-homes),
industrial facilities, and so forth.
There are a number of alternate serializations of XML that take less bandwidth,
and a communications aggregator/gateway could do a variety of things with the information
streams. Small embedded devices can implement an entire web services stack, and
may be usable in the future in home control/gateway environments -- the lesson
from the DMTF (Distributed Management Task Force) is that a fairly complex
management stack is now implemented in every NIC/ethernet card at a cost
differential of roughly $1.
The full information model may be (initially) of less use in the Home to Grid
space, but some of my talks and papers discuss use of forward price information
and bids for homes, so additional information from the EMIX model will be
useful in the future.
(see, for instance, my presentation (and paper with Toby Considine) from
Grid-Interop 2008 on the page at http://www.grid-interop.com/2008/default.asp#session_712
. The presentation PDF seems messed up, at least on a Macintosh - font
issues - but can be found from http://www.coxsoftwarearchitects.com/Pages/C_Energy.html
and directly at http://www.coxsoftwarearchitects.com/Resources/Grid-Interop2008/Cox%2BConsidine%20Grid-Interop%202008%20Slides.pdf
Michel Kohanim wrote:
This is an excellent start and one which I truly believe in.
One comment though: this document assumes that all transactions
will be done using XML/SOAP/Web Services (I understand the connection to
OASIS). In this respect, we are already assuming that each actor has enough
bandwidth to support such transactions, right? What are the provisions for
bandwidth constrained actors?
Again, this is an excellent start and thanks for putting the
With kind regards,
I've attached a draft charter for the proposed OASIS Energy
Market Information Exchange (eMIX) Technical Committee.
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 Energy Interoperation
TC/OpenADR work here, 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.
I invite you to participate in a discussion on how to improve this charter, as
well as the sorts of characteristics that are important to energy markets.
If you would like to be listed on the charter when submitted as a supporter,
please contact me or Toby Considine.
Comments to me or (preferably) to the list. Please reference line numbers where