[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: We need this sort of use cases we need from the buildings / obix world as well
See below for WS-Calendar perspective
-----Original Message-----
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby
Considine
Sent: Tuesday, February 23, 2010 11:00 AM
To: 'Paul Tischhauser'
Subject: RE: WS Calendar proposal 00_1
It's close.
One of the specific call-outs of the NAESB use cases was that we specify
precision of response. For humans attending meetings in many organizations,
plus or minus 5 minutes is the rule. In other organizations, you better be
there at 9:30 sharp. This has been handled by social knowledge by ICalendar
users.
In industrial and energy response, there is a need to know the precision
required. Today, Industrial sites, Commercial Buildings, and homes are
expected to have widely varying degrees of precision in their response times
to grid signals. Back-end generators are requested to come on line more
precisely than any of the above. In today's energy market, more precise
response times are rewarded with higher prices. In discussions in NAESB, we
were imagining that any Schedule negotiation would include a precision
field.
I also do not wish to blend two issues in one of the use cases. A back-end
generator might agree to run all day at half power on the hottest day of the
year. It expects to be paid for being on stand-by for xxx hours (a). Within
that contracted period, this spun-up generator must be ready to go to full
power and sending electricity onto the grid (b). Be must occur with the
agreed upon precision of response. Both (a) and (b) must be paid for. The
contract might pay for (a) and set a price for (b) if needed. Later on,
there might be a request to honor that contract at the approved rate (B)
starting in, ohhh... five minutes.
Hope this makes sense of that use case...
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine
TC9, Inc
Chair, OASIS oBIX Technical Committee
OASIS Technical Advisory Board
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.oasis-open.org
blog: www.NewDaedalus.com
-----Original Message-----
From: Paul Tischhauser [mailto:paultis@microsoft.com]
Sent: Tuesday, February 23, 2010 10:42 AM
To: Toby.Considine@gmail.com
Subject: RE: WS Calendar proposal 00_1
Toby - These scenarios are exactly the feedback I was looking for - it helps
to have a concrete example of how a power contract might be established.
Much of what you detail below seems to be already represented by XCalendar,
but I do see a couple of differences that I want to confirm with you:
Regarding data requirements it seems like the scenario below would require
XCalendar to do a few things it wouldn't support today:
- Define an "event" that has a duration but not a fixed start time
(consumer wants to buy 30 minutes of power sometime between 3 and 4 p.m.)
- Define an "event" that has a variable duration and variable start
time (provider can provide up to 20 minutes of power starting up to 0.5 s
past 10 a.m.)
It also sounds like you want WS-Calendar to address the following aspects of
scheduling logic:
- Propose an event to another party and require that they respond
within a particular time window if they agree.
- Require another party to "confirm" their previous acceptance by
some time , otherwise the original acceptance is not valid.
Does that sound accurate?
Paul
-----Original Message-----
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby
Considine
Sent: Thursday, February 18, 2010 2:51 PM
To: Paul Tischhauser
Subject: RE: WS Calendar proposal 00_1
It is a very interesting start. It handles today's business well, but
handles the reach issues, i.e., the new business models less well. Those are
difficult to see from the NAESB report - which Is why I hope we can have
some ongoing interaction from the CalConnect Team in the WS-Calendar group
as it fires up.
Not sure when the best time to explore those issues is. These might include
coexistence with one or many xml contracts, i.e., specifications of agreed
upon behaviors. For example, a BPEL workflow, or an oBIX contract might be
invoked to in operation by 2:30 and to run until 3:30. As we go further
into the smart grid, a certain call and response effect and recursions might
take place
(1)
(This proposal is good between 3 - and 4 this afternoon <== wsc element
(What would you bid for me to give up my pre-purchased tights to power
( 1/2 Hour at 2:00 this afternoon) <== wsc element
)
)
Receive bids, possible from more than one intermediary, for those negawatts
Execute a contract for the selected bid. <== wsc element
(This proposal is good between 3 - and 4 this afternoon <== wsc element
(I wish to buy power in the following load profile
[consecutive power contracts]
(1/2 hour of 20 KW) <== wsc element
(1/2 hour of 50 KW) <== wsc element
(1/2 hour of 50 KW) <== wsc element
(1/2 hour of 50 KW) <== wsc element
(1/2 hour of 50 KW) <== wsc element
(1/4 hour of 15 KW) <== wsc element
[end of consecutive power contracts])
(I want bid for this power to be delivered in any of the following
schedules
(Weekday evenings starting at 6 beginning may 1 for 6 weeks) <==
wsc element
(Weekday mornings starting at 4 beginning April 15 for 6 weeks)
<== wsc element
(Saturday Mornings mornings starting at 8 beginning April 15 for
15 weeks) <== wsc element
)
)
Market participant may propose some alternate profiles based upon special
knowledge Manufacturer then selects which of the three schedules to use
based on price, existing union contracts, etc.
Execute a contract for the selected bid. <== wsc element
(If you call on me
(any day this week before 10:AM <== wsc element
(I can respond with 50 MW of power
(within half a second but for no more than 20 minutes <== wsc
elements
)
)
(But you must inform me /reserve that power / submit a bid
(by Friday afternoon at 4:30) <== wsc elements
)
)
Simple Calendar is a good start, but it is just a start. We will be looking
for profiles of these elements that define how systems negotiate sequences
of behaviors and market decisions to support those behaviors using a common
semantic set based on XCalendar...
Not sure if this makes it clearer, but I tried to create a notation above
that indicates that when time and schedule of a response is the esences of
the transaction, ICalendar derived information may appear several times in
the negotiation.
There are some very good parallel cases in Data Center Management in which
the calendar elements would be subsumed into WSDM or WSM.
There is also the set of requirements for standardizing enterprise /
building interaction.
Ranging from:
(Conference Room B, 13 Occupants, tomorrow 3:00 - 4:00) (MSX to Building
Systems)
To the more complex
(Poll each of the building elements, each of whom is aware of the schedules
and requirements as in the prior contract
(Ask them how much power they could give up in 15 minutes)
) and then formulate a bid for the smart grid outside...
One of the variants of this on a campus would be a large document from the
registrar's office at the beginning of the semester
(for the next 15 weeks
(M-W-F 9-10, 150 people Room 107, Smith Building)
(M-W-F 11-12, 120 people Room 107, Smith Building)
(Tu-Th 9:30-11, 90 people Room 107, Smith Building)
)
Should that type of request be delivered a One document per course, or
should it be, grouped by semester (next 15 weeks) or by classroom, or by
time of day across all buildings, or...
WS-Calendar does not need to solve all of that, but it should create a set
of expectations on how to handle such scenarios. These communications then
become the basis for moving to autonomous choreography of actions rather
than to centralized hierarchical control. If the meter management system
gets the same assertion, then the cost of classes and schedules could be
compared. (At UNC, we figure half of the tuition after state subsidy is
Energy Dollars, so understanding how classroom decisions and volatile energy
prices intersect is very interesting.
I hope these pseudo-messages clarify some of the issues.
Of course, when the TC begins meeting in a couple weeks,, *then* the starter
work must be "contributed" to the TC.
Thanks
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine
TC9, Inc
Chair, OASIS oBIX Technical Committee
OASIS Technical Advisory Board
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.oasis-open.org
blog: www.NewDaedalus.com
-----Original Message-----
From: Paul Tischhauser [mailto:paultis@microsoft.com]
Sent: Thursday, February 18, 2010 4:14 PM
To: Mike Douglass; Toby.Considine@gmail.com
Cc: tc-xml-l@lists.calconnect.org
Subject: WS Calendar proposal 00_1
Mike/Toby - Here's a very rough cut at WS Calendar interface based on the
smart grid use case around creating and publishing a rate schedule.
Comments?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]