Bill, thank you. It does make sense but I was specifically talking about GPRS
and 6LoWPAN systems. GPRS would become too expensive for XML and 6LoWPAN might
not [yet] have capabilities to process pure SOAP messages.
I agree with your statements. Although the document talks about XML
Vocabularies (which is OK), there is no specific mention of the message
formats/encondings. I think we should either make it clear that
everything is XML – and as Bill suggests – and specific systems are in charge
of serialization/compression/binary translation OR we should allow for other
encodings possibly something close to what Brian suggested (thanks
William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
March 31, 2009 9:08 AM
email@example.com; 'Toby Considine'
Re: [smartgrid-interest] Draft Charter - Energy Market Information
Good point for discussion.
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
(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:
is an excellent start and one which I truly believe in.
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
this is an excellent start and thanks for putting the document
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
Comments to me or (preferably) to the list. Please reference
line numbers where appropriate.