Hi 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.
Ed, 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 Toby).
With kind regards,
From: William Cox
Sent: Tuesday, March 31, 2009 9:08 AM
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