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

 


Help: OASIS Mailing Lists Help | MarkMail Help

smartgrid-interest message

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


Subject: Fw: [smartgrid-interest] Draft Charter - Energy Market Information Exchange



These are very relevant and important observations. As the low level wireless guy (as in lowly PHY/MAC dude) I can add a few bits to this (finally!).  Not sure if it helps, but maybe at least it's a chance to share something I actually know :-).
 
I agree (enthusiastically) that upper layer protocols should be as lean as possible, always.  Overhead creep has a way of happening in each layer, and we must remain aware that at limited speed transports will be used in some parts of our SG network.  Heck, that's just as wise as when Granma said not to put more on your plate than you will actually eat.
 
With 6loWPAN, the underlying constraint from 802.15.4 is the limited frame payload size, not so much the data rate, in our context.  The expected data volume per end-point is modest, and most end-points are idle most of the time (low duty cycle).  In 802.15.4 today the payload limit per 'over the air' frame is 127 octets, which is not ideal for packaging and transporting IP packets (the header of which can be longer than that). As everyone here probably knows, that is why 6loWPAN was initiated. Even with the great efforts that have gone into it, efficient movement of IP traffic is challenging (and uses up more of the modest data rate). Fixing this limit is one key goal of the current "Smart Utility Networking" (SUN) task group in 802.15.4 (TG4g for short); support for a PHY payload of 1500 octets.  With this change and a modest 100kbps data rate, support for IP based upper layer protocols is easier. This allows more the available capacity to be used for moving the application's data.
 
GPRS has been used in end points which forms an experience base.  An issue brought to the 802.15.4 effort from this (and other) experience is the operational complexity of using licensed spectrum and depending on regional service providers. Utilities and vendors want a solution that can be deployed the same nation-wide.  The equipment vendors would like to have one solution globally, and that is even more constrained. In the US there are successful systems using the 902-928 ISM band, and this is a popular approach in proposals heard so far in TG4g.
 
 -Ben
----- Original Message -----
Sent: Tuesday, March 31, 2009 9:24 AM
Subject: RE: [smartgrid-interest] Draft Charter - Energy Market Information Exchange

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,

 

********************************

Michel Kohanim, C.E.O

Universal Devices, Inc.

 

(p) 818.631.0333

(f) 818.708.0755

http://www.universal-devices.com

********************************

 

From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
Sent: Tuesday, March 31, 2009 9:08 AM
To: michel@universal-devices.com
Cc: smartgrid-interest@lists.oasis-open.org; 'Toby Considine'
Subject: Re: [smartgrid-interest] Draft Charter - Energy Market Information Exchange

 

Michel --

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
)

Thanks!

bill cox

Michel Kohanim wrote:

Hi Bill,

 

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 document together.

 

With kind regards,

 

********************************

Michel Kohanim, C.E.O

Universal Devices, Inc.

 

(p) 818.631.0333

(f) 818.708.0755

http://www.universal-devices.com

********************************

 

From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
Sent: Monday, March 30, 2009 7:43 PM
To: smartgrid-interest@lists.oasis-open.org
Cc: Toby Considine
Subject: [smartgrid-interest] Draft Charter - Energy Market Information Exchange

 

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 appropriate.

Thanks!

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax



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