emix — archive

[David Webber]

All,

I'm still urging for keeping this really simple!

From the perspective of the supplier for the surplus power to push to the storage device - how much precision do you really need!?!?  Frankly I really don't need to know much about the device beyond how much capacity to a ROM (Rough Order of Magnitude).  Why over engineer this - if you can use simple tracking messages to see how you are progressing?  Remember when a 5Mb hard drive was a big deal?!  Expect market to drive demand for low cost buckets of storage in future...

So my real time scenario would run something like this:

1) Power source queries grid for status of existing available storage devices with surplus capacity

2) From responses and my available power - I commit with a couple of them to push power to them

   - to determine this I just need ROM calculations that tell me they can absorb the power at the rate I'm generating it.
   - their availability should be immediate, or time when to commence charging
   - indicate status update refresh period for 20% change in stored power or full - depending on anticipated storage rate - this you can calculate - either from history of previous service to that device - or device itself can give you estimate - if you are off by a % it won't be a big deal.

3) Commence power distribution

4) Receive regular status updates from devices of their new storage level and remaining capacity.

5) Compute decision - continue power supply or loop back to 1)

6) If no storage devices available - then scale back power generation - until receive storage notification from device available.

What I would anticipate is that scenario 6) is really about always having enough storage capacity available to balance demand.  

From our XML perspective - so long as our simple message designs contain enough information to drive the decision making - we don't need more.  E.g. we want minimalistic message design.  People will always think of more and more exotic information that can be added - we want to strongly resist that - and require ONLY the information needed to drive a working process - nothing more.  Remember - the messages do NOT need to contain information that can be obtained elsewhere.  Otherwise you end up with a standard that is extremely tough to implement - and then even worse to have consistent interoperability across vendors.  Plus break the messaging down into small discreet purposes.  For example - I do NOT need to send device profile but once - first time device is available.

DW





Thanks, DW